Code review and rewriting
This commit is contained in:
Gregory Trullemans
parent
c15e05349d
commit
a88f1854a0
|
|
@ -1,6 +1,7 @@
|
|||
\chapter{Administration}
|
||||
|
||||
Cette partie est tellement puissante et performante, qu'elle pourrait laisser penser qu'il est possible de réaliser une application complète rien qu'en configurant l'administration. C'est faux.
|
||||
Cette partie est tellement puissante et performante, qu'elle pourrait laisser penser qu'il est possible de réaliser une application complète rien qu'en configurant l'administration.
|
||||
C'est faux.
|
||||
|
||||
L'administration est une sorte de tour de contrôle évoluée, un \emph{back office} sans transpirer; elle se base sur le modèle de données programmé et construit dynamiquement les formulaires qui lui est associé.
|
||||
Elle joue avec les clés primaires, étrangères, les champs et types de champs par \href{https://fr.wikipedia.org/wiki/Introspection}{introspection}, et présente tout ce qu'il faut pour avoir du \href{https://fr.wikipedia.org/wiki/CRUD}{CRUD} \index{CRUD} \footnote{\emph{Create-Read-Update-Delete}, c'est-à-dire le fonctionnement par défaut de beaucoup d'applications}, c'est-à-dire tout ce qu'il faut pour ajouter, lister, modifier ou supprimer des informations.
|
||||
|
|
@ -32,7 +33,8 @@ Elle se base sur plusieurs couches que l'on a déjà (ou on va bientôt) aborder
|
|||
|
||||
\section{Le modèle de données}
|
||||
|
||||
Comme expliqué ci-dessus, le modèle de données est constité d'un ensemble de champs typés et de relations. L'administration permet de décrire les données qui peuvent être modifiées, en y associant un ensemble (basique) de permissions.
|
||||
Comme expliqué ci-dessus, le modèle de données est constité d'un ensemble de champs typés et de relations.
|
||||
L'administration permet de décrire les données qui peuvent être modifiées, en y associant un ensemble (basique) de permissions.
|
||||
|
||||
Si vous vous rappelez de l'application que nous avions créée dans la première partie, les URLs reprenaient déjà la partie suivante:
|
||||
|
||||
|
|
@ -147,7 +149,6 @@ class Meta:
|
|||
\end{minted}
|
||||
|
||||
\begin{enumerate}
|
||||
|
||||
\item
|
||||
Le titre:
|
||||
|
||||
|
|
@ -155,9 +156,7 @@ class Meta:
|
|||
\item
|
||||
Soit en modifiant le template de l'administration
|
||||
\item
|
||||
Soit en ajoutant l'assignation suivante dans le fichier
|
||||
\texttt{urls.py}:
|
||||
\texttt{admin.site.site\_header\ =\ "SuperBook\ Secret\ Area}.
|
||||
Soit en ajoutant l'assignation suivante dans le fichier \texttt{urls.py} : \texttt{admin.site.site\_header\ =\ "SuperBook\ Secret\ Area}.
|
||||
\end{itemize}
|
||||
\item
|
||||
Prefetch
|
||||
|
|
@ -167,23 +166,16 @@ class Meta:
|
|||
|
||||
\url{https://medium.com/@hakibenita/things-you-must-know-about-django-admin-as-your-app-gets-bigger-6be0b0ee9614}
|
||||
|
||||
En gros, le problème de l'admin est que si on fait des requêtes
|
||||
imbriquées, on va flinguer l'application et le chargement de la page. La
|
||||
solution consiste à utiliser la propriété \texttt{list\_select\_related}
|
||||
de la classe d'Admin, afin d'appliquer une jointure par défaut et et
|
||||
gagner en performances.
|
||||
En gros, le problème de l'admin est que si on fait des requêtes imbriquées, on va flinguer l'application et le chargement de la page.
|
||||
La solution consiste à utiliser la propriété \texttt{list\_select\_related} de la classe d'Admin, afin d'appliquer une jointure par défaut et et gagner en performances.
|
||||
|
||||
\subsection{admin.ModelAdmin}
|
||||
|
||||
La classe \texttt{admin.ModelAdmin} que l'on retrouvera principalement
|
||||
dans le fichier \texttt{admin.py} de chaque application contiendra la
|
||||
définition de ce que l'on souhaite faire avec nos données dans
|
||||
l'administration. Cette classe (et sa partie Meta)
|
||||
La classe \texttt{admin.ModelAdmin} que l'on retrouvera principalement dans le fichier \texttt{admin.py} de chaque application contiendra la définition de ce que l'on souhaite faire avec nos données dans l'administration. Cette classe (et sa partie Meta)
|
||||
|
||||
\subsection{L'affichage}
|
||||
|
||||
Comme l'interface d'administration fonctionne (en trèèèès) gros comme un
|
||||
CRUD auto-généré, on trouve par défaut la possibilité de :
|
||||
Comme l'interface d'administration fonctionne (en trèèèès) gros comme un CRUD auto-généré, on trouve par défaut la possibilité de :
|
||||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
|
|
|
|||
|
|
@ -4,15 +4,13 @@
|
|||
\url{https://news.ycombinator.com/item?id=30221016\&utm_term=comment} vs
|
||||
Django Rest Framework
|
||||
|
||||
Expliquer pourquoi une API est intéressante/primordiale/la première
|
||||
chose à réaliser/le cadet de nos soucis.
|
||||
Expliquer pourquoi une API est intéressante/primordiale/la première chose à réaliser/le cadet de nos soucis.
|
||||
|
||||
Voir peut-être aussi
|
||||
\url{https://christophergs.com/python/2021/12/04/fastapi-ultimate-tutorial/}
|
||||
|
||||
Au niveau du modèle, nous allons partir de quelque chose de très simple:
|
||||
des personnes, des contrats, des types de contrats, et un service
|
||||
d'affectation. Quelque chose comme ceci:
|
||||
Au niveau du modèle, nous allons partir de quelque chose de très simple: des personnes, des contrats, des types de contrats, et un service d'affectation.
|
||||
Quelque chose comme ceci:
|
||||
|
||||
\begin{minted}{python}
|
||||
# models.py
|
||||
|
|
@ -89,17 +87,13 @@ touffue. Il convient de:
|
|||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Configurer les sérialiseurs, càd. les champs que nous souhaitons
|
||||
exposer au travers de l'API,
|
||||
Configurer les sérialiseurs, càd. les champs que nous souhaitons exposer au travers de l'API,
|
||||
\item
|
||||
Configurer les vues, càd le comportement de chacun des points de
|
||||
terminaison,
|
||||
Configurer les vues, càd le comportement de chacun des points de terminaison,
|
||||
\item
|
||||
Configurer les points de terminaison eux-mêmes, càd les URLs
|
||||
permettant d'accéder aux ressources.
|
||||
Configurer les points de terminaison eux-mêmes, càd les URLs permettant d'accéder aux ressources.
|
||||
\item
|
||||
Et finalement ajouter quelques paramètres au niveau de notre
|
||||
application.
|
||||
Et finalement ajouter quelques paramètres au niveau de notre application.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Serialiseurs}
|
||||
|
|
|
|||
|
|
@ -24,7 +24,6 @@ Les principes SOLID, introduit par Robert C. Martin dans les années 2000 pour o
|
|||
\end{enumerate}
|
||||
|
||||
Des équivalents à ces directives existent au niveau des composants, puis au niveau architectural:
|
||||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Reuse/release équivalence principle,
|
||||
|
|
@ -40,14 +39,12 @@ Des équivalents à ces directives existent au niveau des composants, puis au ni
|
|||
|
||||
\subsection{Single Responsility Principle} \label{SRP}
|
||||
|
||||
Le principe de responsabilité unique conseille de disposer de concepts ou domaines d'activité qui ne s'occupent chacun que d'une et une seule
|
||||
chose.
|
||||
Le principe de responsabilité unique conseille de disposer de concepts ou domaines d'activité qui ne s'occupent chacun que d'une et une seule chose.
|
||||
Ceci rejoint (un peu) la \href{https://en.wikipedia.org/wiki/Unix_philosophy}{Philosophie Unix}, documentée par Doug McIlroy et qui demande de "\emph{faire une seule chose, mais de le faire bien}" \cite{unix_philosophy}.
|
||||
|
||||
Selon ce principe, une classe ou un élément de programmation ne doit donc pas avoir plus d'une seule raison de changer.
|
||||
|
||||
Plutôt que de centraliser le maximum de code à un seul endroit ou dans une seule classe par convenance ou commodité \footnote{Aussi appelé
|
||||
\emph{God-Like object}}, le principe de responsabilité unique suggère que chaque classe soit responsable d'un et un seul concept.
|
||||
Plutôt que de centraliser le maximum de code à un seul endroit ou dans une seule classe par convenance ou commodité \footnote{Aussi appelé \emph{God-Like object}}, le principe de responsabilité unique suggère que chaque classe soit responsable d'un et un seul concept.
|
||||
|
||||
Une manière de voir les choses consiste à différencier les acteurs ou les intervenants: imaginez disposer d'une classe représentant des données de membres du personnel; ces données pourraient être demandées par trois acteurs:
|
||||
|
||||
|
|
@ -342,7 +339,8 @@ Petit exemple pratique: si nous définissons une méthode \texttt{make\_some\_no
|
|||
\end{listing}
|
||||
|
||||
Le principe de substitution de Liskov suggère qu'une classe doit toujours pouvoir être considérée comme une instance de sa classe parente, et \textbf{doit pouvoir s'y substituer}.
|
||||
Dans notre exemple, cela signifie que nous pourrons tout à fait accepter qu'un lion se comporte comme un canard et adore manger des plantes, insectes, graines, algues et du poisson. Miam !
|
||||
Dans notre exemple, cela signifie que nous pourrons tout à fait accepter qu'un lion se comporte comme un canard et adore manger des plantes, insectes, graines, algues et du poisson.
|
||||
Miam !
|
||||
Nous vous laissons tester la structure ci-dessus en glissant une antilope dans la boite à goûter du lion, ce qui nous donnera quelques trucs bizarres (et un lion atteint de botulisme).
|
||||
|
||||
Pour revenir à nos exemples de rendus de documents, nous aurions pu faire hériter notre \texttt{MarkdownRenderer} de la classe \texttt{XmlRenderer}:
|
||||
|
|
@ -396,7 +394,7 @@ Si nous décidons à un moment d'ajouter une méthode d'entête au niveau de not
|
|||
import markdown
|
||||
return markdown.markdown(document.content)
|
||||
\end{minted}
|
||||
\caption{... et il a mal à l'entête}
|
||||
\caption{\ldots~ et il a mal à l'entête}
|
||||
\end{listing}
|
||||
|
||||
Le code ci-dessus ne porte pas à conséquence \footnote{Pas immédiatement, en tout cas...}, mais dès que nous invoquerons la méthode \texttt{header()} sur une instance de type \texttt{MarkdownRenderer}, nous obtiendrons un bloc de déclaration XML (\texttt{\textless{}?xml\ version\ =\ "1.0"?\textgreater{}}) pour un fichier Markdown, ce qui n'aura aucun sens.
|
||||
|
|
@ -690,14 +688,12 @@ Pour créer un nouveau \emph{middleware}, il nous suffirait d'implémenter de no
|
|||
|
||||
Dans d'autres projets écrits en Python, ce type de mécanisme peut être implémenté relativement facilement en utilisant les modules \href{https://docs.python.org/3/library/importlib.html}{importlib} et la fonction \texttt{getattr}.
|
||||
|
||||
Un autre exemple concerne les bases de données: pour garder un maximum de flexibilité, Django ajoute une couche d'abstraction en permettant de
|
||||
spécifier le moteur de base de données que vous souhaiteriez utiliser, qu'il s'agisse d'SQLite, MSSQL, Oracle, PostgreSQL ou MySQL/MariaDB \footnote{\url{http://howfuckedismydatabase.com/}}.
|
||||
Un autre exemple concerne les bases de données: pour garder un maximum de flexibilité, Django ajoute une couche d'abstraction en permettant de spécifier le moteur de base de données que vous souhaiteriez utiliser, qu'il s'agisse d'SQLite, MSSQL, Oracle, PostgreSQL ou MySQL/MariaDB \footnote{\url{http://howfuckedismydatabase.com/}}.
|
||||
|
||||
D'un point de vue architectural, nous ne devons pas nous soucier de la manière dont les données sont stockées, s'il s'agit d'un disque magnétique, de mémoire vive, ... en fait, on ne devrait même pas savoir s'il y a un disque du tout.
|
||||
D'un point de vue architectural, nous ne devons pas nous soucier de la manière dont les données sont stockées, s'il s'agit d'un disque magnétique, de mémoire vive, \ldots~ en fait, on ne devrait même pas savoir s'il y a un disque du tout.
|
||||
Et Django le fait très bien pour nous.
|
||||
|
||||
En termes architecturaux, ce principe autorise une définition des frontières, et en permettant une séparation claire en inversant le flux
|
||||
de dépendances et en faisant en sorte que les règles métiers n'aient aucune connaissance des interfaces graphiques qui les exploitent ou desmoteurs de bases de données qui les stockent.
|
||||
En termes architecturaux, ce principe autorise une définition des frontières, et en permettant une séparation claire en inversant le flux de dépendances et en faisant en sorte que les règles métiers n'aient aucune connaissance des interfaces graphiques qui les exploitent ou desmoteurs de bases de données qui les stockent.
|
||||
Ceci autorise une forme d'immunité entre les composants.
|
||||
|
||||
\section{Composants}
|
||||
|
|
@ -750,7 +746,7 @@ Il est nécessaire de projeter la capacité d'adaptation, en minimisant la maint
|
|||
Un des problèmes est qu'à la première demande, l'architecture pourrait avoir pris une mauvaise direction, sans aucune malléabilité.
|
||||
|
||||
Une bonne architecture va rendre le système facile à lire, facile à développer, facile à maintenir et facile à déployer, l'objectif ultime étant de minimiser le coût de maintenance et de maximiser la productivité des développeurs.
|
||||
Un des autres objectifs d'une bonne architecture consiste à se garder le plus d'options possibles, et à se concentrer sur les détails (le type de base de données, la conception concrète, ...) le plus tard possible, tout en conservant la politique principale en ligne de mire.
|
||||
Un des autres objectifs d'une bonne architecture consiste à se garder le plus d'options possibles, et à se concentrer sur les détails (le type de base de données, la conception concrète, \ldots) le plus tard possible, tout en conservant la politique principale en ligne de mire.
|
||||
Ceci permet de délayer les choix techniques à «~plus tard~», ce qui permet également de concrétiser ces choix en ayant le plus d'informations possibles \cite[pp.137-141]{clean_architecture}
|
||||
|
||||
Derrière une bonne architecture, il y a aussi un investissement quant aux ressources qui seront nécessaires à faire évoluer l'application: ne
|
||||
|
|
@ -786,37 +782,25 @@ yet still not know how the system is delivered.
|
|||
--- Robert C. Martin Clean Architecture
|
||||
\end{quote}
|
||||
|
||||
Le point soulevé ci-dessous est qu'un framework n'est qu'un outil, et
|
||||
pas une obligation de structuration. L'idée est que le framework doit se
|
||||
conformer à la définition de l'application, et non l'inverse. Dans le
|
||||
cadre de l'utilisation de Django, c'est un point critique à prendre en
|
||||
considération: une fois que vous aurez fait ce choix, vous aurez
|
||||
extrêmement difficile à faire machine arrière:
|
||||
Le point soulevé ci-dessous est qu'un framework n'est qu'un outil, et pas une obligation de structuration.
|
||||
L'idée est que le framework doit se conformer à la définition de l'application, et non l'inverse.
|
||||
Dans le cadre de l'utilisation de Django, c'est un point critique à prendre en considération: une fois que vous aurez fait ce choix, vous aurez extrêmement difficile à faire machine arrière:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Votre modèle métier sera largement couplé avec le type de base de
|
||||
données (relationnelle, indépendamment
|
||||
Votre modèle métier sera largement couplé avec le type de base de données (relationnelle, indépendamment
|
||||
\item
|
||||
Votre couche de présentation sera surtout disponible au travers d'un
|
||||
navigateur
|
||||
Votre couche de présentation sera surtout disponible au travers d'un navigateur
|
||||
\item
|
||||
Les droits d'accès et permissions seront en grosse partie gérés par le
|
||||
frameworks
|
||||
Les droits d'accès et permissions seront en grosse partie gérés par le frameworks
|
||||
\item
|
||||
La sécurité dépendra de votre habilité à suivre les versions
|
||||
\item
|
||||
Et les fonctionnalités complémentaires (que vous n'aurez pas voulu/eu
|
||||
le temps de développer) dépendront de la bonne volonté de la
|
||||
communauté
|
||||
Et les fonctionnalités complémentaires (que vous n'aurez pas voulu/eu le temps de développer) dépendront de la bonne volonté de la communauté
|
||||
\end{itemize}
|
||||
|
||||
Le point à comprendre ici n'est pas que "Django, c'est mal", mais qu'une
|
||||
fois que vous aurez défini la politique, les règles métiers, les données
|
||||
critiques et entités, et que vous aurez fait le choix de développer en
|
||||
âme et conscience votre nouvelle création en utilisant Django, vous
|
||||
serez bon gré mal gré, contraint de continuer avec. Cette décision ne
|
||||
sera pas irrévocable, mais difficile à contourner.
|
||||
Le point à comprendre ici n'est pas que "Django, c'est mal", mais qu'une fois que vous aurez défini la politique, les règles métiers, les données critiques et entités, et que vous aurez fait le choix de développer en âme et conscience votre nouvelle création en utilisant Django, vous serez bon gré mal gré, contraint de continuer avec.
|
||||
Cette décision ne sera pas irrévocable, mais difficile à contourner.
|
||||
|
||||
\begin{quote}
|
||||
At some point in their history most DevOps organizations were hobbled by
|
||||
|
|
@ -832,11 +816,7 @@ to survice, but also to thrise and win in the marketplace.
|
|||
\cite[182]{devops_handbook}
|
||||
\end{quote}
|
||||
|
||||
Ceci dit, Django compense ses contraintes en proposant énormément de
|
||||
flexibilité et de fonctionnalités \textbf{out-of-the-box}, c'est-à-dire
|
||||
que vous pourrez sans doute avancer vite et bien jusqu'à un point de
|
||||
rupture, puis revoir la conception et réinvestir à ce moment-là, mais en
|
||||
toute connaissance de cause.
|
||||
Ceci dit, Django compense ses contraintes en proposant énormément de flexibilité et de fonctionnalités \textbf{out-of-the-box}, c'est-à-dire que vous pourrez sans doute avancer vite et bien jusqu'à un point de rupture, puis revoir la conception et réinvestir à ce moment-là, mais en toute connaissance de cause.
|
||||
|
||||
\begin{quote}
|
||||
When any of the external parts of the system become obsolete, such as
|
||||
|
|
@ -846,30 +826,25 @@ elements with a minimum of fuss.
|
|||
--- Robert C. Martin Clean Architecture
|
||||
\end{quote}
|
||||
|
||||
Avec Django, la difficulté à se passer du framework va consister à
|
||||
basculer vers «~autre chose~» et a remplacer chacune des tentacules qui
|
||||
aura pousser partout dans l'application.
|
||||
Avec Django, la difficulté à se passer du framework va consister à basculer vers «~autre chose~» et a remplacer chacune des tentacules qui aura pousser partout dans l'application.
|
||||
|
||||
A noter que les services et les «~architectures orientées services~» ne
|
||||
sont jamais qu'une définition d'implémentation des frontières, dans la
|
||||
mesure où un service n'est jamais qu'une fonction appelée au travers
|
||||
d'un protocole (rest, soap, \ldots\hspace{0pt}). Une application
|
||||
monolotihique sera tout aussi fonctionnelle qu'une application découpée
|
||||
en microservices. \cite[p. 243]{clean_architecture}
|
||||
A noter que les services et les «~architectures orientées services~» ne sont jamais qu'une définition d'implémentation des frontières, dans la mesure où un service n'est jamais qu'une fonction appelée au travers d'un protocole (rest, soap, \ldots\hspace{0pt}).
|
||||
Une application monolotihique sera tout aussi fonctionnelle qu'une application découpée en microservices. \cite[p. 243]{clean_architecture}
|
||||
|
||||
\section{Inversion de dépendances}
|
||||
|
||||
Dans la partie SOLID, nous avons évoqué plusieurs principes de
|
||||
développement. Django est un framework qui évolue, et qui a pu présenter
|
||||
certains problèmes liés à l'un de ces principes.
|
||||
Dans la partie SOLID, nous avons évoqué plusieurs principes de développement.
|
||||
Django est un framework qui évolue, et qui a pu présenter certains problèmes liés à l'un de ces principes.
|
||||
|
||||
Les \href{https://docs.djangoproject.com/en/2.0/releases/2.0/}{Releases Notes} de Django 2.0 date de décembre 2017; parmi ces notes, l'une d'elles cite l'abandon du support d'\href{https://docs.djangoproject.com/en/2.0/releases/2.0/\#dropped-support-for-oracle-11-2}{Oracle 11.2}.
|
||||
En substance, cela signifie que le framework se chargeait lui-même de construire certaines parties de requêtes, qui deviennent non fonctionnelles dès lors que l'on met le framework ou le moteur de base de données à jour.
|
||||
Réécrit, cela signifie que:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Si vos données sont stockées dans un moteur géré par Oracle 11.2, vous serez limité à une version 1.11 de Django
|
||||
\item Tandis que si votre moteur est géré par une version ultérieure, le framework pourra être mis à jour.
|
||||
\item
|
||||
Si vos données sont stockées dans un moteur géré par Oracle 11.2, vous serez limité à une version 1.11 de Django
|
||||
\item
|
||||
Tandis que si votre moteur est géré par une version ultérieure, le framework pourra être mis à jour.
|
||||
\end{enumerate}
|
||||
|
||||
Nous sommes dans un cas concret d'inversion de dépendances ratée: le framework (et encore moins vos politiques et règles métiers) ne devraient pas avoir connaissance du moteur de base de données.
|
||||
|
|
@ -902,9 +877,12 @@ Avec cette approche, les composants seront déjà découplés au mieux.
|
|||
Les composants peuvent être découpés au niveau:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Du code source}, via des modules, paquets, dépendances, ...
|
||||
\item \textbf{Du déploiement ou de l'exécution}, au travers de dll, jar, linked libraries, ..., voire au travers de threads ou de processus locaux.
|
||||
\item \textbf{Via la mise à disposition de nouveaux services}, lorsqu'il est plus intuitif de contacter un nouveau point de terminaison que d'intégrer de force de nouveaux concepts dans une base de code existante.
|
||||
\item
|
||||
\textbf{Du code source}, via des modules, paquets, dépendances, \ldots
|
||||
\item
|
||||
\textbf{Du déploiement ou de l'exécution}, au travers de dll, jar, linked libraries, \ldots, voire au travers de threads ou de processus locaux.
|
||||
\item
|
||||
\textbf{Via la mise à disposition de nouveaux services}, lorsqu'il est plus intuitif de contacter un nouveau point de terminaison que d'intégrer de force de nouveaux concepts dans une base de code existante.
|
||||
\end{itemize}
|
||||
|
||||
Cette section se base sur deux ressources principales \cite{maintainable_software} \cite{clean_code}, qui répartissent un ensemble de conseils parmi quatre niveaux de composants:
|
||||
|
|
@ -916,11 +894,12 @@ Cette section se base sur deux ressources principales \cite{maintainable_softwar
|
|||
\item Et des conseils plus généraux.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Au niveau des méthodes et fonctions}
|
||||
|
||||
\subsection{Au niveau des méthodes et fonctions}
|
||||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Gardez vos méthodes/fonctions courtes}. Pas plus de 15 lignes, en comptant les commentaires.
|
||||
\textbf{Gardez vos méthodes/fonctions courtes}.
|
||||
Pas plus de 15 lignes, en comptant les commentaires.
|
||||
Des exceptions sont possibles, mais dans une certaine mesure uniquement (pas plus de 6.9\% de plus de 60 lignes; pas plus de 22.3\% de plus de 30 lignes, au plus 43.7\% de plus de 15 lignes et au moins 56.3\% en dessous de 15 lignes).
|
||||
Oui, c'est dur à tenir, mais faisable.
|
||||
\item
|
||||
|
|
@ -929,13 +908,13 @@ A nouveau, si une méthode présente une complexité cyclomatique de 15, la sép
|
|||
\item
|
||||
\textbf{N'écrivez votre code qu'une seule fois: évitez les duplications, copie, etc.}: imaginez qu'un bug soit découvert dans une fonction; il devra alors être corrigé dans toutes les fonctions qui auront été copiées/collées.
|
||||
\item
|
||||
\textbf{Conservez de petites interfaces et signatures de fonctions/méthodes}. Quatre paramètres, pas plus.
|
||||
\textbf{Conservez de petites interfaces et signatures de fonctions/méthodes}.
|
||||
Quatre paramètres, pas plus.
|
||||
Au besoin, refactorisez certains paramètres dans une classe ou une structure, qui sera plus facile à tester.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Au niveau des classes}
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Privilégiez un couplage faible entre vos classes}.
|
||||
|
|
@ -947,9 +926,8 @@ La classe appellante n'aura alors que les méthodes offertes par l'interface com
|
|||
|
||||
Dans la même veine, faites en sorte que les dépendances aillent toutes "dans le même sens", ce qui limitera l'effet spaghetti associé au code, tout en améliorant sa lisibilité et l'intuitivité de sa compréhension.
|
||||
|
||||
|
||||
\subsection{Au niveau des composants}
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Tout comme pour les classes, il faut conserver un couplage faible au niveau des composants} également.
|
||||
|
|
@ -957,10 +935,8 @@ Une manière d'arriver à ce résultat est de conserver un nombre de points d'en
|
|||
Pour une architecture n-tiers par exemple, la couche d'abstraction à la base de données ne peut être connue que des services; sans cela, au bout de quelques semaines, n'importe quelle couche de présentation risque de contacter directement la base de données, "\emph{juste parce qu'elle en a la possibilité}".
|
||||
Vous pourriez également passer par des interfaces, afin de réduire le nombre de points d'entrée connus par un composant externe (qui ne connaîtra par exemple que \texttt{IFileTransfer} avec ses méthodes \texttt{put} et \texttt{get}, et non pas les détailsd'implémentation complet d'une classe \texttt{FtpFileTransfer} ou \texttt{SshFileTransfer}).
|
||||
\item
|
||||
\textbf{Conserver un bon balancement au niveau des composants}: évitez qu'un composant \textbf{A} ne soit un énorme mastodonte, alors que le
|
||||
composant juste à côté ne soit capable que d'une action.
|
||||
De cette manière, les nouvelles fonctionnalités seront mieux réparties parmi les différents systèmes, et les responsabilités seront plus faciles à
|
||||
gérer.
|
||||
\textbf{Conserver un bon balancement au niveau des composants}: évitez qu'un composant \textbf{A} ne soit un énorme mastodonte, alors que le composant juste à côté ne soit capable que d'une action.
|
||||
De cette manière, les nouvelles fonctionnalités seront mieux réparties parmi les différents systèmes, et les responsabilités seront plus faciles à gérer.
|
||||
Un conseil est d'avoir un nombre de composants compris entre 6 et 12 (idéalement, 12), et que chacun de ces composants soit approximativement de même taille.
|
||||
\end{itemize}
|
||||
|
||||
|
|
@ -968,8 +944,7 @@ Un conseil est d'avoir un nombre de composants compris entre 6 et 12 (idéalemen
|
|||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Conserver une densité de code faible}: il n'est évidemment pas possible d'implémenter n'importe quelle nouvelle fonctionnalité en
|
||||
moins de 20 lignes de code; l'idée ici est que la réécriture du projet ne prenne pas plus de 20 hommes/mois.
|
||||
\textbf{Conserver une densité de code faible} : il n'est évidemment pas possible d'implémenter n'importe quelle nouvelle fonctionnalité en moins de 20 lignes de code; l'idée ici est que la réécriture du projet ne prenne pas plus de 20 hommes/mois.
|
||||
Pour cela, il faut (activement) passer du temps à réduire la taille du code existant: soit en faisantdu refactoring (intensif), soit en utilisant des librairies existantes, soit en explosant un système existant en plusieurs sous-systèmes communiquant entre eux.
|
||||
Mais surtout, en évitant de copier/coller bêtement du code existant.
|
||||
\item
|
||||
|
|
|
|||
|
|
@ -8,10 +8,10 @@ Accrochez-vous, le sujet peut être tendu lors d'une première exploration.
|
|||
\section{Utilisateurs}
|
||||
|
||||
Dans les spécifications, nous souhaitions pouvoir associer un utilisateur à une liste (\textbf{le propriétaire}) et un utilisateur à une part (\textbf{le donateur}).
|
||||
Par défaut, Django offre une gestion simplifiée des utilisateurs (pas de connexion LDAP, pas de double
|
||||
authentification, ...: juste un utilisateur et un mot de passe.
|
||||
Par défaut, Django offre une gestion simplifiée des utilisateurs (pas de connexion LDAP, pas de double authentification, \ldots~: juste un utilisateur et un mot de passe.
|
||||
Pour y accéder, un paramètre par défaut est défini dans votre fichier de settings : \texttt{AUTH\_USER\_MODEL}.
|
||||
|
||||
|
||||
Toute modification de la modélisation des utilisateurs exige qu'un modèle personnalisé existe.
|
||||
|
||||
La première difficulté est que toute modification en cours de route de la modélisation des utilisateurs
|
||||
|
|
@ -19,7 +19,6 @@ La première difficulté est que toute modification en cours de route de la mod
|
|||
\section{Mécanisme d'authentification}
|
||||
|
||||
On peut schématiser le flux d'authentification de la manière suivante :
|
||||
|
||||
En gros:
|
||||
|
||||
\begin{enumerate}
|
||||
|
|
@ -43,12 +42,9 @@ En résumé (bis):
|
|||
\item
|
||||
Une personne souhaite se connecter;
|
||||
\item
|
||||
Les backends d'authentification s'enchaîne jusqu'à trouver une bonne
|
||||
correspondance. Si aucune correspondance n'est trouvée, on envoie la
|
||||
personne sur les roses.
|
||||
Les backends d'authentification s'enchaîne jusqu'à trouver une bonne correspondance. Si aucune correspondance n'est trouvée, on envoie la personne sur les roses.
|
||||
\item
|
||||
Si OK, on retourne une instance de type current\_user, qui pourra être
|
||||
utilisée de manière uniforme dans l'application.
|
||||
Si OK, on retourne une instance de type current\_user, qui pourra être utilisée de manière uniforme dans l'application.
|
||||
\end{enumerate}
|
||||
|
||||
Ci-dessous, on définit deux backends différents pour mieux comprendre les différentes possibilités:
|
||||
|
|
@ -141,16 +137,15 @@ On peut résumer le mécanisme d'authentification de la manière suivante:
|
|||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Si vous voulez modifier les informations liées à un utilisateur, orientez-vous vers la modification du modèle. Comme nous le verrons ci-dessous, il existe trois manières de prendre ces modifications en
|
||||
compte. Voir également \href{https://docs.djangoproject.com/en/stable/topics/auth/customizing/}{ici}.
|
||||
Si vous voulez modifier les informations liées à un utilisateur, orientez-vous vers la modification du modèle. Comme nous le verrons ci-dessous, il existe trois manières de prendre ces modifications en compte. Voir également \href{https://docs.djangoproject.com/en/stable/topics/auth/customizing/}{ici}.
|
||||
\item
|
||||
Si vous souhaitez modifier la manière dont l'utilisateur se connecte, alors vous devrez modifier le \textbf{backend}.
|
||||
\end{itemize}
|
||||
|
||||
\section{Modélisation}
|
||||
|
||||
Dans un premier temps, Django a besoin de manipuler \href{https://docs.djangoproject.com/en/1.9/ref/contrib/auth/\#user-model}{des instances de type \texttt{django.contrib.auth.User}}. Cette classe implémente les champs suivants:
|
||||
|
||||
Dans un premier temps, Django a besoin de manipuler \href{https://docs.djangoproject.com/en/1.9/ref/contrib/auth/\#user-model}{des instances de type \texttt{django.contrib.auth.User}}.
|
||||
Cette classe implémente les champs suivants:
|
||||
\begin{itemize}
|
||||
\item
|
||||
\texttt{username}
|
||||
|
|
@ -166,17 +161,25 @@ Dans un premier temps, Django a besoin de manipuler \href{https://docs.djangopro
|
|||
\texttt{date\_joined}.
|
||||
\end{itemize}
|
||||
|
||||
D'autres champs, comme les groupes auxquels l'utilisateur est associé, ses permissions, savoir s'il est un super-utilisateur, \ldots\hspace{0pt} sont moins pertinents pour le moment. Avec les quelques champs déjà définis ci-dessus, nous avons de quoi identifier correctement nos utilisateurs. Inutile d'implémenter nos propres classes, puisqu'elles existent déjà.
|
||||
D'autres champs, comme les groupes auxquels l'utilisateur est associé, ses permissions, savoir s'il est un super-utilisateur, \ldots\hspace{0pt} sont moins pertinents pour le moment.
|
||||
Avec les quelques champs déjà définis ci-dessus, nous avons de quoi identifier correctement nos utilisateurs.
|
||||
Inutile d'implémenter nos propres classes, puisqu'elles existent déjà.
|
||||
|
||||
Si vous souhaitez ajouter un champ, il existe trois manières de faire.
|
||||
|
||||
\subsection{Extension du modèle existant}
|
||||
|
||||
Le plus simple consiste à créer une nouvelle classe, et à faire un lien de type \texttt{OneToOne} vers la classe \texttt{django.contrib.auth.User}. De cette manière, on ne modifie rien à la manière dont Django authentife ses utlisateurs: tout ce qu'on fait, c'est un lien vers une table nouvellement créée, comme on l'a déjà vu au point {[}\ldots\hspace{0pt}voir l'héritage de modèle{]}. L'avantage de cette méthode, c'est qu'elle est extrêmement flexible, et qu'on garde les mécanismes Django standard. Le désavantage, c'est que pour avoir toutes les informations de notre utilisateur, on sera obligé d'effectuer une jointure sur le base de données, ce qui pourrait avoir des conséquences sur les performances.
|
||||
Le plus simple consiste à créer une nouvelle classe, et à faire un lien de type \texttt{OneToOne} vers la classe \texttt{django.contrib.auth.User}.
|
||||
De cette manière, on ne modifie rien à la manière dont Django authentife ses utlisateurs: tout ce qu'on fait, c'est un lien vers une table nouvellement créée, comme on l'a déjà vu au point {[}\ldots\hspace{0pt}voir l'héritage de modèle{]}.
|
||||
L'avantage de cette méthode, c'est qu'elle est extrêmement flexible, et qu'on garde les mécanismes Django standard.
|
||||
Le désavantage, c'est que pour avoir toutes les informations de notre utilisateur, on sera obligé d'effectuer une jointure sur le base de données, ce qui pourrait avoir des conséquences sur les performances.
|
||||
|
||||
\subsection{Substitution du modèle}
|
||||
|
||||
Avant de commencer, sachez que cette étape doit être effectuée \textbf{avant la première migration}. Le plus simple sera de définir une nouvelle classe héritant de \texttt{django.contrib.auth.User} et de spécifier la classe à utiliser dans votre fichier de paramètres. Si ce paramètre est modifié après que la première migration ait été effectuée, il ne sera pas pris en compte. Tenez-en compte au moment de modéliser votre application.
|
||||
Avant de commencer, sachez que cette étape doit être effectuée \textbf{avant la première migration}.
|
||||
Le plus simple sera de définir une nouvelle classe héritant de \texttt{django.contrib.auth.User} et de spécifier la classe à utiliser dans votre fichier de paramètres.
|
||||
Si ce paramètre est modifié après que la première migration ait été effectuée, il ne sera pas pris en compte.
|
||||
Tenez-en compte au moment de modéliser votre application.
|
||||
|
||||
\begin{minted}{python}
|
||||
AUTH_USER_MODEL = 'myapp.MyUser'
|
||||
|
|
@ -186,28 +189,32 @@ Avant de commencer, sachez que cette étape doit être effectuée \textbf{avant
|
|||
Notez bien qu'il ne faut pas spécifier le package \texttt{.models} dans cette injection de dépendances: le schéma à indiquer est bien \texttt{\textless{}nom\ de\ l’application\textgreater{}.\textless{}nom\ de\ la\ classe\textgreater{}}.
|
||||
|
||||
\subsection{OAuth}
|
||||
|
||||
OAuth est un standard libre définissant un ensemble de méthodes à implémenter pour l'accès (l'autorisation) à une API. Son fonctionnement se base sur un système de jetons (Tokens), attribués par le possesseur de la ressource à laquelle un utilisateur souhaite accéder.
|
||||
|
||||
Le client initie la connexion en demandant un jeton au serveur. Ce jeton est ensuite utilisée tout au long de la connexion, pour accéder aux différentes ressources offertes par ce serveur. `wikipedia \textless{}\url{http://en.wikipedia.org/wiki/OAuth\%3E\%60_}.
|
||||
Le client initie la connexion en demandant un jeton au serveur.
|
||||
Ce jeton est ensuite utilisée tout au long de la connexion, pour accéder aux différentes ressources offertes par ce serveur.
|
||||
`wikipedia \textless{}\url{http://en.wikipedia.org/wiki/OAuth\%3E\%60_}.
|
||||
|
||||
Une introduction à OAuth est \href{http://hueniverse.com/oauth/guide/intro/}{disponible ici}. Elle
|
||||
introduit le protocole comme étant une \texttt{valet\ key}, une clé que l'on donne à la personne qui va garer votre voiture pendant que vous profitez des mondanités. Cette clé donne un accès à votre voiture, tout
|
||||
en bloquant un ensemble de fonctionnalités. Le principe du protocole est semblable en ce sens: vous vous réservez un accès total à une API, tandis que le système de jetons permet d'identifier une personne, tout
|
||||
en lui donnant un accès restreint à votre application.
|
||||
Une introduction à OAuth est \href{http://hueniverse.com/oauth/guide/intro/}{disponible ici}.
|
||||
Elle introduit le protocole comme étant une \texttt{valet\ key}, une clé que l'on donne à la personne qui va garer votre voiture pendant que vous profitez des mondanités.
|
||||
Cette clé donne un accès à votre voiture, tout en bloquant un ensemble de fonctionnalités.
|
||||
Le principe du protocole est semblable en ce sens: vous vous réservez un accès total à une API, tandis que le système de jetons permet d'identifier une personne, tout en lui donnant un accès restreint à votre application.
|
||||
|
||||
L'utilisation de jetons permet notamment de définir une durée d'utilisation et une portée d'utilisation. L'utilisateur d'un service A peut par exemple autoriser un service B à accéder à des ressources qu'il
|
||||
L'utilisation de jetons permet notamment de définir une durée d'utilisation et une portée d'utilisation.
|
||||
L'utilisateur d'un service A peut par exemple autoriser un service B à accéder à des ressources qu'il
|
||||
possède, sans pour autant révéler son nom d'utilisateur ou son mot de passe.
|
||||
|
||||
L'exemple repris au niveau du \href{http://hueniverse.com/oauth/guide/workflow/}{workflow} est le suivant : un utilisateur(trice), Jane, a uploadé des photos sur le site faji.com (A). Elle souhaite les imprimer au travers du site beppa.com (B). Au moment de la commande, le site beppa.com envoie une demande au site faji.com pour accéder aux ressources partagées par Jane. Pour cela, une nouvelle page s'ouvre pour l'utilisateur, et lui demande d'introduire sa "pièce d'identité". Le site A, ayant reçu une demande de B, mais certifiée par l'utilisateur, ouvre alors les ressources et lui permet d'y accéder.
|
||||
L'exemple repris au niveau du \href{http://hueniverse.com/oauth/guide/workflow/}{workflow} est le suivant : un utilisateur(trice), Jane, a uploadé des photos sur le site faji.com (A).
|
||||
Elle souhaite les imprimer au travers du site beppa.com (B).
|
||||
Au moment de la commande, le site beppa.com envoie une demande au site faji.com pour accéder aux ressources partagées par Jane.
|
||||
Pour cela, une nouvelle page s'ouvre pour l'utilisateur, et lui demande d'introduire sa "pièce d'identité".
|
||||
Le site A, ayant reçu une demande de B, mais certifiée par l'utilisateur, ouvre alors les ressources et lui permet d'y accéder.
|
||||
|
||||
\section{Templates}
|
||||
|
||||
Ce qui n'existe pas par contre, ce sont les vues. Django propose donc
|
||||
tout le mécanisme de gestion des utilisateurs, excepté le visuel (hors
|
||||
administration). En premier lieu, ces paramètres sont fixés dans le
|
||||
fichier `settings
|
||||
\textless{}\url{https://docs.djangoproject.com/en/1.8/ref/settings/\#auth\%3E\%60_}.
|
||||
Ce qui n'existe pas par contre, ce sont les vues.
|
||||
Django propose donc tout le mécanisme de gestion des utilisateurs, excepté le visuel (hors administration).
|
||||
En premier lieu, ces paramètres sont fixés dans le fichier `settings \textless{}\url{https://docs.djangoproject.com/en/1.8/ref/settings/\#auth\%3E\%60_}.
|
||||
On y trouve par exemple les paramètres suivants :
|
||||
|
||||
\begin{itemize}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
\chapter{Context Processors}
|
||||
Mise en pratique: un \emph{context processor} sert \emph{grosso-modo} à peupler l'ensemble des données transmises des vues aux templates avec des données communes.
|
||||
Un context processor est un peu l'équivalent d'un middleware, mais entre les données et les templates, là où le middleware va s'occuper des données relatives aux réponses et requêtes elles-mêmes.
|
||||
|
||||
Un \emph{context processor} sert \emph{grosso-modo} à peupler l'ensemble des données transmises des vues aux templates avec des données communes. Un context processor est un peu l'équivalent d'un middleware, mais est situé entre les données et les templates, là où le middleware va s'occuper des données relatives aux réponses et requêtes elles-mêmes.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
\chapter{Debian}
|
||||
|
||||
La première étape pour la configuration de notre hôte consiste à définir les utilisateurs et groupes de droits. Il est faut absolument éviter de faire tourner une application en tant qu'utilisateur \textbf{root}, car la moindre faille pourrait avoir des conséquences catastrophiques.
|
||||
La première étape pour la configuration de notre hôte consiste à définir les utilisateurs et groupes de droits.
|
||||
Il est faut absolument éviter de faire tourner une application en tant qu'utilisateur \textbf{root}, car la moindre faille pourrait avoir des conséquences catastrophiques.
|
||||
|
||||
Une fois que ces utilisateurs seront configurés, nous pourrons passer à l'étape de configuration, qui consistera à:
|
||||
|
||||
|
|
@ -15,7 +16,9 @@ Une fois que ces utilisateurs seront configurés, nous pourrons passer à l'éta
|
|||
Configurer un proxy inverse, qui s'occupera d'envoyer les requêtes d'un utilisateur externe à la machine hôte vers notre serveur applicatif, qui la communiquera à l'un des travailleurs.
|
||||
\end{enumerate}
|
||||
|
||||
La machine hôte peut être louée chez Digital Ocean, Scaleway, OVH, Vultr, ... Il existe des dizaines d'hébergements typés VPS (\textbf{Virtual Private Server}). A vous de choisir celui qui vous convient \footnote{Personnellement, j'ai un petit faible pour Hetzner Cloud}.
|
||||
La machine hôte peut être louée chez Digital Ocean, Scaleway, OVH, Vultr, \ldots~
|
||||
Il existe des dizaines d'hébergements typés VPS (\textbf{Virtual Private Server}).
|
||||
A vous de choisir celui qui vous convient \footnote{Personnellement, j'ai un petit faible pour Hetzner Cloud}.
|
||||
|
||||
\begin{verbatim}
|
||||
apt update
|
||||
|
|
@ -33,8 +36,7 @@ La machine hôte peut être louée chez Digital Ocean, Scaleway, OVH, Vultr, ...
|
|||
\item
|
||||
On crée un groupe pour les communications via sockets
|
||||
\item
|
||||
On crée notre utilisateur applicatif; ses applications seront placées
|
||||
dans le répertoire \texttt{/home/gwift}
|
||||
On crée notre utilisateur applicatif; ses applications seront placées dans le répertoire \texttt{/home/gwift}
|
||||
\item
|
||||
On crée le répertoire home/gwift
|
||||
\item
|
||||
|
|
@ -44,10 +46,7 @@ La machine hôte peut être louée chez Digital Ocean, Scaleway, OVH, Vultr, ...
|
|||
\section{Dépendances systèmes}
|
||||
|
||||
|
||||
La version 3.6 de Python se trouve dans les dépôts officiels de CentOS.
|
||||
Si vous souhaitez utiliser une version ultérieure, il suffit de
|
||||
l'installer en parallèle de la version officiellement supportée par
|
||||
votre distribution.
|
||||
La version 3.6 de Python se trouve dans les dépôts officiels de CentOS. Si vous souhaitez utiliser une version ultérieure, il suffit de l'installer en parallèle de la version officiellement supportée par votre distribution.
|
||||
|
||||
Pour CentOS, vous avez donc deux possibilités :
|
||||
|
||||
|
|
@ -69,45 +68,38 @@ Ou passer par une installation alternative:
|
|||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Attention !} Le paramètre \texttt{altinstall} est primordial.
|
||||
Sans lui, vous écraserez l'interpréteur initialement supporté par la
|
||||
distribution, et cela pourrait avoir des effets de bord non souhaités.
|
||||
Sans lui, vous écraserez l'interpréteur initialement supporté par la distribution, et cela pourrait avoir des effets de bord non souhaités.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Base de données}
|
||||
|
||||
|
||||
On l'a déjà vu, Django se base sur un pattern type
|
||||
\href{https://www.martinfowler.com/eaaCatalog/activeRecord.html}{ActiveRecords}
|
||||
pour la gestion de la persistance des données et supporte les principaux
|
||||
moteurs de bases de données connus:
|
||||
On l'a déjà vu, Django se base sur un pattern type \href{https://www.martinfowler.com/eaaCatalog/activeRecord.html}{ActiveRecords} pour la gestion de la persistance des données et supporte les principaux moteurs de bases de données connus :
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
SQLite (en natif, mais Django 3.0 exige une version du moteur
|
||||
supérieure ou égale à la 3.8)
|
||||
SQLite (en natif, mais Django 3.0 exige une version du moteur supérieure ou égale à la 3.8)
|
||||
\item
|
||||
MariaDB (en natif depuis Django 3.0),
|
||||
\item
|
||||
PostgreSQL au travers de psycopg2 (en natif aussi),
|
||||
\item
|
||||
Microsoft SQLServer grâce aux drivers {[}\ldots\hspace{0pt}à
|
||||
compléter{]}
|
||||
Microsoft SQLServer grâce aux drivers {[}\ldots\hspace{0pt}à compléter{]}
|
||||
\item
|
||||
Oracle via
|
||||
\href{https://oracle.github.io/python-cx_Oracle/}{cx\_Oracle}.
|
||||
Oracle via \href{https://oracle.github.io/python-cx_Oracle/}{cx\_Oracle}.
|
||||
\end{itemize}
|
||||
|
||||
Chaque pilote doit être utilisé précautionneusement ! Chaque version de Django n'est pas toujours compatible avec chacune des versions des pilotes, et chaque moteur de base de données nécessite parfois une
|
||||
version spécifique du pilote. Par ce fait, vous serez parfois bloqué sur une version de Django, simplement parce que votre serveur de base de données se trouvera dans une version spécifique (eg. Django 2.3 à cause
|
||||
d'un Oracle 12.1).
|
||||
version spécifique du pilote.
|
||||
Par ce fait, vous serez parfois bloqué sur une version de Django, simplement parce que votre serveur de base de données se trouvera dans une version spécifique (eg. Django 2.3 à cause d'un Oracle 12.1).
|
||||
|
||||
Ci-dessous, quelques procédures d'installation pour mettre un serveur à disposition.
|
||||
Les deux plus simples seront MariaDB et PostgreSQL, qu'on couvrira ci-dessous.
|
||||
Oracle et Microsoft SQLServer se trouveront en annexes.
|
||||
|
||||
Ci-dessous, quelques procédures d'installation pour mettre un serveur à disposition. Les deux plus simples seront MariaDB et PostgreSQL, qu'on couvrira ci-dessous. Oracle et Microsoft SQLServer se trouveront en
|
||||
annexes.
|
||||
|
||||
\subsection{PostgreSQL}
|
||||
|
||||
On commence par installer PostgreSQL.
|
||||
|
||||
Dans le cas de debian, on exécute la commande suivante:
|
||||
|
||||
\begin{verbatim}
|
||||
|
|
@ -138,8 +130,8 @@ Finalement, on peut créer la DB:
|
|||
|
||||
\subsection{MariaDB}
|
||||
|
||||
Idem, installation, configuration, backup, tout ça. A copier de grimboite, je suis sûr d’avoir
|
||||
des notes là-dessus.
|
||||
Idem, installation, configuration, backup, tout ça.
|
||||
A copier de grimboite, je suis sûr d’avoir des notes là-dessus.
|
||||
|
||||
|
||||
\section{Préparation de l'environment utilisateur}
|
||||
|
|
@ -173,6 +165,7 @@ suivantes:
|
|||
=config.settings_production
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\section{Configuration de l'application}
|
||||
|
||||
\begin{verbatim}
|
||||
|
|
@ -191,8 +184,8 @@ suivantes:
|
|||
connexion à la base de données.
|
||||
\end{itemize}
|
||||
|
||||
\section{Création des répertoires de logs}
|
||||
|
||||
\section{Création des répertoires de logs}
|
||||
|
||||
\begin{verbatim}
|
||||
mkdir -p /var/www/gwift/static
|
||||
|
|
@ -200,6 +193,7 @@ suivantes:
|
|||
|
||||
\section{Socket}
|
||||
|
||||
\section{Socket}
|
||||
Dans le fichier \texttt{/etc/tmpfiles.d/gwift.conf}:
|
||||
|
||||
\begin{verbatim}
|
||||
|
|
@ -212,6 +206,7 @@ Suivi de la création par systemd :
|
|||
systemd-tmpfiles --create
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\section{Gunicorn}
|
||||
|
||||
\begin{verbatim}
|
||||
|
|
@ -239,10 +234,11 @@ Suivi de la création par systemd :
|
|||
--log-file=-
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\section{Supervsion, keepalive et autoreload}
|
||||
|
||||
Pour la supervision, on passe par Supervisor. Il existe d'autres
|
||||
superviseurs,
|
||||
Pour la supervision, on passe par Supervisor.
|
||||
Il existe d'autres superviseurs,
|
||||
|
||||
\begin{verbatim}
|
||||
yum install supervisor -y
|
||||
|
|
@ -311,8 +307,8 @@ l'aide de la commande \texttt{supervisorctl}:
|
|||
gwift: started
|
||||
\end{verbatim}
|
||||
|
||||
\section{Firewall}
|
||||
|
||||
\section{Firewall}
|
||||
\begin{verbatim}
|
||||
et 443 (HTTPS).
|
||||
\end{verbatim}
|
||||
|
|
@ -331,8 +327,14 @@ l'aide de la commande \texttt{supervisorctl}:
|
|||
Et le port 443 (forcément).
|
||||
\end{itemize}
|
||||
|
||||
\section{Reverse proxy}
|
||||
|
||||
\section{Reverse proxy}
|
||||
\begin{verbatim}
|
||||
yum install nginx -y
|
||||
usermod -a -G gunicorn_sockets nginx
|
||||
\end{verbatim}
|
||||
|
||||
On configure ensuite le fichier \texttt{/etc/nginx/conf.d/gwift.conf}:
|
||||
|
||||
\begin{verbatim}
|
||||
yum install nginx -y
|
||||
|
|
@ -362,6 +364,29 @@ l'aide de la commande \texttt{supervisorctl}:
|
|||
gzip_types gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
|
||||
|
||||
|
||||
location /static/ {
|
||||
access_log off;
|
||||
expires 30d;
|
||||
add_header Pragma public;
|
||||
add_header Cache-Control "public";
|
||||
add_header Vary "Accept-Encoding";
|
||||
try_files $uri $uri/ =404;
|
||||
}
|
||||
|
||||
location / {
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header Host $http_host;
|
||||
proxy_redirect off;
|
||||
|
||||
client_max_body_size 4G;
|
||||
keepalive_timeout 5;
|
||||
|
||||
gzip on;
|
||||
gzip_comp_level 7;
|
||||
gzip_proxied any;
|
||||
gzip_types gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
|
||||
|
||||
|
||||
location /static/ {
|
||||
access_log off;
|
||||
expires 30d;
|
||||
|
|
@ -379,6 +404,7 @@ l'aide de la commande \texttt{supervisorctl}:
|
|||
proxy_pass http://gwift_app;
|
||||
}
|
||||
}
|
||||
}
|
||||
\end{verbatim}
|
||||
|
||||
\begin{itemize}
|
||||
|
|
@ -394,7 +420,6 @@ l'aide de la commande \texttt{supervisorctl}:
|
|||
\end{itemize}
|
||||
|
||||
\section{Mise à jour}
|
||||
|
||||
\begin{verbatim}
|
||||
u - <user>
|
||||
source ~/.venvs/<app>/bin/activate
|
||||
|
|
@ -425,13 +450,11 @@ l'aide de la commande \texttt{supervisorctl}:
|
|||
}
|
||||
\end{verbatim}
|
||||
|
||||
Puis on démarre logrotate avec \# logrotate -d /etc/logrotate.d/gwift
|
||||
pour vérifier que cela fonctionne correctement.
|
||||
Puis on démarre logrotate avec \# logrotate -d /etc/logrotate.d/gwift pour vérifier que cela fonctionne correctement.
|
||||
|
||||
|
||||
\section{Sauvegardes}
|
||||
|
||||
Les sauvegardes ont été configurées avec borg:
|
||||
\texttt{yum\ install\ borgbackup}.
|
||||
Les sauvegardes ont été configurées avec borg : \texttt{yum\ install\ borgbackup}.
|
||||
|
||||
C'est l'utilisateur gwift qui s'en occupe.
|
||||
|
||||
|
|
@ -443,7 +466,6 @@ borg create gwift.borg::{now} ~/bin ~/webapps
|
|||
\end{verbatim}
|
||||
|
||||
Et dans le fichier crontab :
|
||||
|
||||
\begin{verbatim}
|
||||
0 23 * * * /home/gwift/bin/backup.sh
|
||||
\end{verbatim}
|
||||
|
|
|
|||
|
|
@ -24,18 +24,15 @@ Dans le cas de Django, et après avoir activé l'environnement, nous pouvons à
|
|||
Ici, la commande \texttt{pip\ install\ django} récupère la \textbf{dernière version connue disponible dans les dépôts \url{https://pypi.org/}} (sauf si vous en avez définis d'autres. Mais c'est hors sujet).
|
||||
Nous en avons déjà discuté : il est important de bien spécifier la version que vous souhaitez utiliser, sans quoi vous risquez de rencontrer des effets de bord.
|
||||
|
||||
L'installation de Django a ajouté un nouvel exécutable: \texttt{django-admin}, que l'on peut utiliser pour créer notre nouvel espace de travail. Par la suite, nous utiliserons \texttt{manage.py}, qui constitue un \textbf{wrapper} autour de \texttt{django-admin}.
|
||||
|
||||
Pour démarrer notre projet, nous lançons
|
||||
\texttt{django-admin\ startproject\ gwift}:
|
||||
L'installation de Django a ajouté un nouvel exécutable: \texttt{django-admin}, que l'on peut utiliser pour créer notre nouvel espace de travail.
|
||||
Par la suite, nous utiliserons \texttt{manage.py}, qui constitue un \textbf{wrapper} autour de \texttt{django-admin}.
|
||||
|
||||
Pour démarrer notre projet, nous lançons \texttt{django-admin\ startproject\ gwift}:
|
||||
\begin{verbatim}
|
||||
$ django-admin startproject gwift
|
||||
\end{verbatim}
|
||||
|
||||
Cette action a pour effet de créer un nouveau dossier \texttt{gwift},
|
||||
dans lequel nous trouvons la structure suivante:
|
||||
|
||||
Cette action a pour effet de créer un nouveau dossier \texttt{gwift}, dans lequel nous trouvons la structure suivante :
|
||||
\begin{verbatim}
|
||||
$ tree gwift
|
||||
gwift
|
||||
|
|
@ -48,36 +45,25 @@ dans lequel nous trouvons la structure suivante:
|
|||
-- manage.py
|
||||
\end{verbatim}
|
||||
|
||||
C'est dans ce répertoire que vont vivre tous les fichiers liés au
|
||||
projet. Le but est de faire en sorte que toutes les opérations
|
||||
(maintenance, déploiement, écriture, tests, \ldots\hspace{0pt}) puissent
|
||||
se faire à partir d'un seul point d'entrée.
|
||||
C'est dans ce répertoire que vont vivre tous les fichiers liés au projet.
|
||||
Le but est de faire en sorte que toutes les opérations (maintenance, déploiement, écriture, tests, \ldots\hspace{0pt}) puissent se faire à partir d'un seul point d'entrée.
|
||||
|
||||
L'utilité de ces fichiers est définie ci-dessous:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\texttt{settings.py} contient tous les paramètres globaux à notre
|
||||
projet.
|
||||
\texttt{settings.py} contient tous les paramètres globaux à notre projet.
|
||||
\item
|
||||
\texttt{urls.py} contient les variables de routes, les adresses
|
||||
utilisées et les fonctions vers lesquelles elles pointent.
|
||||
\texttt{urls.py} contient les variables de routes, les adresses utilisées et les fonctions vers lesquelles elles pointent.
|
||||
\item
|
||||
\texttt{manage.py}, pour toutes les commandes de gestion.
|
||||
\item
|
||||
\texttt{asgi.py} contient la définition de l'interface
|
||||
\href{https://en.wikipedia.org/wiki/Asynchronous_Server_Gateway_Interface}{ASGI},
|
||||
le protocole pour la passerelle asynchrone entre votre application et
|
||||
le serveur Web.
|
||||
\texttt{asgi.py} contient la définition de l'interface \href{https://en.wikipedia.org/wiki/Asynchronous_Server_Gateway_Interface}{ASGI}, le protocole pour la passerelle asynchrone entre votre application et le serveur Web.
|
||||
\item
|
||||
\texttt{wsgi.py} contient la définition de l'interface
|
||||
\href{https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface}{WSGI},
|
||||
qui permettra à votre serveur Web (Nginx, Apache, \ldots\hspace{0pt})
|
||||
de faire un pont vers votre projet.
|
||||
\texttt{wsgi.py} contient la définition de l'interface \href{https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface}{WSGI}, qui permettra à votre serveur Web (Nginx, Apache, \ldots\hspace{0pt}) de faire un pont vers votre projet.
|
||||
\end{itemize}
|
||||
|
||||
Indiquer qu'il est possible d'avoir plusieurs structures de dossiers et
|
||||
qu'il n'y a pas de "magie" derrière toutes ces commandes.
|
||||
Indiquer qu'il est possible d'avoir plusieurs structures de dossiers et qu'il n'y a pas de "magie" derrière toutes ces commandes.
|
||||
La seule condition est que les chemins référencés soient cohérents par rapport à la structure sous-jacente.
|
||||
|
||||
Tant que nous y sommes, nous pouvons ajouter un répertoire dans lequel nous stockerons les dépendances et un fichier README:
|
||||
|
|
@ -139,7 +125,6 @@ Nous faisons ici une distinction entre un \textbf{projet} et une \textbf{applica
|
|||
\end{itemize}
|
||||
|
||||
Pour \texttt{gwift}, nous aurons :
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics{images/django/django-project-vs-apps-gwift.png}
|
||||
|
|
@ -148,13 +133,11 @@ Pour \texttt{gwift}, nous aurons:
|
|||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Une première application pour la gestion des listes de souhaits et des
|
||||
éléments,
|
||||
Une première application pour la gestion des listes de souhaits et des éléments,
|
||||
\item
|
||||
Une deuxième application pour la gestion des utilisateurs,
|
||||
\item
|
||||
Voire une troisième application qui gérera les partages entre
|
||||
utilisateurs et listes.
|
||||
Voire une troisième application qui gérera les partages entre utilisateurs et listes.
|
||||
\end{enumerate}
|
||||
|
||||
Nous voyons également que la gestion des listes de souhaits et éléments aura besoin de la gestion des utilisateurs - elle n'est pas autonome -, tandis que la gestion des utilisateurs n'a aucune autre dépendance
|
||||
|
|
@ -179,8 +162,7 @@ Le projet s'occupe principalement d'appliquer une couche de glue entre différen
|
|||
\subsection{manage.py}
|
||||
|
||||
Le fichier \texttt{manage.py} que vous trouvez à la racine de votre projet est un \textbf{wrapper} sur les commandes \texttt{django-admin}.
|
||||
A partir de maintenant, nous n'utiliserons plus que celui-là pour tout
|
||||
ce qui touchera à la gestion de notre projet:
|
||||
A partir de maintenant, nous n'utiliserons plus que celui-là pour tout ce qui touchera à la gestion de notre projet :
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
|
|
|
|||
|
|
@ -29,28 +29,19 @@ ressources pourraient vous aider:
|
|||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Pour les débutants},
|
||||
\href{https://automatetheboringstuff.com/}{Automate the Boring Stuff
|
||||
with Python} \cite{boring_stuff}, aka. \emph{Practical
|
||||
Programming for Total Beginners}
|
||||
\textbf{Pour les débutants}, \href{https://automatetheboringstuff.com/}{Automate the Boring Stuff with Python} \cite{boring_stuff}, aka. \emph{Practical Programming for Total Beginners}
|
||||
\item
|
||||
\textbf{Pour un (gros) niveau au dessus} et pour un état de l'art du langage, nous ne pouvons que vous recommander le livre Expert Python Programming \cite{expert_python}, qui aborde énormément d'aspects du langage en détails (mais pas toujours en profondeur): les différents types d'interpréteurs, les éléments de langage avancés, différents outils de productivité, métaprogrammation, optimisation de code, programmation orientée évènements, multithreading et concurrence, tests, ...
|
||||
\textbf{Pour un (gros) niveau au dessus} et pour un état de l'art du langage, nous ne pouvons que vous recommander le livre Expert Python Programming \cite{expert_python}, qui aborde énormément d'aspects du langage en détails (mais pas toujours en profondeur): les différents types d'interpréteurs, les éléments de langage avancés, différents outils de productivité, métaprogrammation, optimisation de code, programmation orientée évènements, multithreading et concurrence, tests, \ldots
|
||||
A ce jour, c'est le concentré de sujets liés au langage le plus intéressant qui ait pu arriver entre nos mains.
|
||||
\end{itemize}
|
||||
|
||||
En parallèle, si vous avez besoin d'un aide-mémoire ou d'une liste
|
||||
exhaustive des types et structures de données du langage, référez-vous
|
||||
au lien suivant:
|
||||
\href{https://gto76.github.io/python-cheatsheet/}{Python Cheat Sheet}.
|
||||
En parallèle, si vous avez besoin d'un aide-mémoire ou d'une liste exhaustive des types et structures de données du langage, référez-vous au lien suivant: \href{https://gto76.github.io/python-cheatsheet/}{Python Cheat Sheet}.
|
||||
|
||||
\section{Protocoles de langage}
|
||||
|
||||
Le modèle de données du langage spécifie un ensemble de méthodes qui
|
||||
peuvent être surchargées. Ces méthodes suivent une convention de nommage
|
||||
et leur nom est toujours encadré par un double tiret souligné; d'où leur
|
||||
nom de "\emph{dunder methods}\index{dunder}" ou "\emph{double-underscore methods}". La
|
||||
méthode la plus couramment utilisée est la méthode \texttt{init()}, qui
|
||||
permet de surcharger l'initialisation d'une instance de classe.
|
||||
Le modèle de données du langage spécifie un ensemble de méthodes qui peuvent être surchargées.
|
||||
Ces méthodes suivent une convention de nommage et leur nom est toujours encadré par un double tiret souligné; d'où leur nom de "\emph{dunder methods}\index{dunder}" ou "\emph{double-underscore methods}".
|
||||
La méthode la plus couramment utilisée est la méthode \texttt{init()}, qui permet de surcharger l'initialisation d'une instance de classe.
|
||||
|
||||
\begin{listing}[!ht]
|
||||
\begin{minted}{python}
|
||||
|
|
@ -83,7 +74,7 @@ Les points principaux à présenter ci-dessus:
|
|||
\item item()
|
||||
\item getitem() - pour utiliser les []
|
||||
\item len() - pour connaître la longueur d'un objet
|
||||
\item ...
|
||||
\item \ldots
|
||||
\end{enumerate}
|
||||
|
||||
Le langage autorise nativement plus d'une cinquantaine d'opérateurs différents:
|
||||
|
|
@ -94,7 +85,7 @@ Le langage autorise nativement plus d'une cinquantaine d'opérateurs différents
|
|||
\item Opérateurs de comparaisons
|
||||
\item Opérateurs d'identité
|
||||
\item Opérateurs de comparaison bit à bit
|
||||
\item ...
|
||||
\item \ldots
|
||||
\end{enumerate}
|
||||
|
||||
Par exemple, la méthode \texttt{add()} est responsable de l'implémentation de l'opérateur \texttt{+}, la méthode \texttt{sub()} s'occupe de la soustraction ()\texttt{–}), tandis que \texttt{mul()} gère l'opérateur \texttt{*}.
|
||||
|
|
@ -156,11 +147,11 @@ Nous pouvons donc utiliser ces mêmes \textbf{dunder methods} (\textbf{double-un
|
|||
\section{Guide de style}
|
||||
|
||||
La première PEP qui va nous intéresser est la PEP8.
|
||||
Elle spécifie comment du code Python doit être organisé ou formaté, quelles sont les conventions pour l'indentation, le nommage des variables et des classes, ...
|
||||
Elle spécifie comment du code Python doit être organisé ou formaté, quelles sont les conventions pour l'indentation, le nommage des variables et des classes, \ldots
|
||||
En bref, elle décrit comment écrire du code proprement, afin que d'autres développeurs puissent le reprendre facilement, ou simplement que votre base de code ne dérive lentement vers un seuil de non-maintenabilité.
|
||||
|
||||
Dans cet objectif, un outil existe et listera l'ensemble des conventions qui ne sont pas correctement suivies dans votre projet: flake8. Pour l'installer, passez par pip.
|
||||
Lancez ensuite la commande \texttt{flake8} suivie du chemin à analyser (\texttt{.}, le nom d'un répertoire, le nom d'un fichier \texttt{.py}, ...).
|
||||
Lancez ensuite la commande \texttt{flake8} suivie du chemin à analyser (\texttt{.}, le nom d'un répertoire, le nom d'un fichier \texttt{.py}, \ldots).
|
||||
Si vous souhaitez uniquement avoir le nombre d'erreur de chaque type, saisissez les options \texttt{-\/-statistics\ -qq} - l'attribut \texttt{-qq} permettant simplement d'ignorer toute sortie console autre que les statistiques demandées).
|
||||
|
||||
\begin{listing}[!ht]
|
||||
|
|
@ -196,12 +187,12 @@ Toute fonction dans la complexité est supérieure à cette valeur sera considé
|
|||
|
||||
Python étant un langage interprété fortement typé, il est plus que conseillé, au même titre que les tests unitaires que nous verrons plus bas, de documenter son code.
|
||||
Ceci impose une certaine rigueur, tout en améliorant énormément la qualité, la compréhension et la reprise du code par une tierce personne.
|
||||
Ceci implique aussi de \textbf{tout} documenter: les modules, les paquets, les classes, les fonctions, méthodes, ... ce qui peut aller à contrecourant d'autres pratiques \cite{clean_code}{53-74} ; il y a donc une juste mesure à prendre entre "tout documenter" et "tout bien documenter":
|
||||
Ceci implique aussi de \textbf{tout} documenter: les modules, les paquets, les classes, les fonctions, méthodes, \ldots ce qui peut aller à contrecourant d'autres pratiques \cite{clean_code}{53-74} ; il y a donc une juste mesure à prendre entre "tout documenter" et "tout bien documenter":
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Inutile d'ajouter des watermarks, auteurs, ...
|
||||
Inutile d'ajouter des watermarks, auteurs, \ldots
|
||||
Git ou tout VCS s'en sortira très bien et sera beaucoup plus efficace que n'importe quelle chaîne de caractères que vous pourriez indiquer et qui sera fausse dans six mois,
|
||||
\item
|
||||
Inutile de décrire quelque chose qui est évident; documenter la méthode \mintinline{python}{get_age()} d'une personne n'aura pas beaucoup d'intérêt
|
||||
|
|
@ -219,7 +210,7 @@ Il existe plusieurs types de balisages reconnus/approuvés:
|
|||
\item Google Style (parfois connue sous l'intitulé \texttt{Napoleon})
|
||||
\end{enumerate}
|
||||
|
||||
... mais tout système de balisage peut être reconnu, sous réseve de respecter la structure de la PEP257.
|
||||
\ldots mais tout système de balisage peut être reconnu, sous réseve de respecter la structure de la PEP257.
|
||||
|
||||
\subsection{PEP 257}
|
||||
|
||||
|
|
@ -234,7 +225,7 @@ Elle contient des conventions, pas des règles ou
|
|||
-- Tim Peters on comp.lang.python, 2001-06-16
|
||||
\end{quote}
|
||||
|
||||
Ainsi, les conventions sont décrites; chaque format propose ensuite son propre balisage (ReStructuredText, Numpy, Napoleon, ...).
|
||||
Ainsi, les conventions sont décrites; chaque format propose ensuite son propre balisage (ReStructuredText, Numpy, Napoleon, \ldots).
|
||||
A priori, vous pourriez tout à fait utiliser le vôtre, sous réserve que les conventions de la PEP-257 soient respectées.
|
||||
|
||||
\subsection{RestructuredText}
|
||||
|
|
@ -483,7 +474,7 @@ Cet élément peut être:
|
|||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Une ligne de code}
|
||||
\item \textbf{Un bloc de code} - une fonction, une méthode, une classe, un module, ...
|
||||
\item \textbf{Un bloc de code} - une fonction, une méthode, une classe, un module, \ldots
|
||||
\item \textbf{Un projet entier}, en spécifiant la non-prise en compte au niveau du fichier \texttt{.pylintrc}, qui contient
|
||||
\end{enumerate}
|
||||
|
||||
|
|
@ -496,7 +487,7 @@ Cet élément peut être:
|
|||
|
||||
\section{Formatage de code}
|
||||
|
||||
Nous avons parlé ci-dessous de style de codage pour Python (PEP8), de style de rédaction pour la documentation (PEP257), d'un vérificateur pour nous indiquer quels morceaux de code doivent absolument être revus, ...
|
||||
Nous avons parlé ci-dessous de style de codage pour Python (PEP8), de style de rédaction pour la documentation (PEP257), d'un vérificateur pour nous indiquer quels morceaux de code doivent absolument être revus, \ldots
|
||||
Reste que ces tâches sont parfois (très) souvent fastidieuses: écrire un code propre et systématiquement cohérent est une tâche ardue.
|
||||
Heureusement, il existe plusieurs outils pour nous aider au niveau du formatage automatique.
|
||||
Même si elle n'est pas parfaite, la librairie \href{https://black.readthedocs.io/en/stable/}{Black} arrive à un très bon compromis entre
|
||||
|
|
|
|||
|
|
@ -9,7 +9,9 @@ Nothing within in the system depends on the tests, and the tests always depend i
|
|||
-- Robert C. Martin, Clean Architecture
|
||||
\end{quote}
|
||||
|
||||
Your tests are your first and best line of defense against software defects. Your tests are more important than linting \& static analysis (which can only find a subclass of errors, not problems with your actual program logic). Tests are as important as the implementation itself (all that matters is that the code meets the requirement -- how it's implemented doesn't matter at all unless it's implemented poorly).
|
||||
Your tests are your first and best line of defense against software defects.
|
||||
Your tests are more important than linting \& static analysis (which can only find a subclass of errors, not problems with your actual program logic).
|
||||
Tests are as important as the implementation itself (all that matters is that the code meets the requirement -- how it's implemented doesn't matter at all unless it's implemented poorly).
|
||||
|
||||
Unit tests combine many features that make them your secret weapon to application success:
|
||||
|
||||
|
|
@ -21,13 +23,15 @@ Unit tests combine many features that make them your secret weapon to applicatio
|
|||
\item
|
||||
Test your developer understanding: Does the developer understand the problem enough to articulate in code all critical component requirements?
|
||||
\item
|
||||
Quality Assurance: Manual QA is error prone. In my experience, it's impossible for a developer to remember all features that need testing after making a change to refactor, add new features, or remove features.
|
||||
Quality Assurance: Manual QA is error prone.
|
||||
In my experience, it's impossible for a developer to remember all features that need testing after making a change to refactor, add new features, or remove features.
|
||||
\item
|
||||
Continuous Delivery Aid: Automated QA affords the opportunity to automatically prevent broken builds from being deployed to production.
|
||||
\end{enumerate}
|
||||
|
||||
Unit tests don't need to be twisted or manipulated to serve all of those broad-ranging goals. Rather, it is in the essential nature of a unit test to satisfy all of those needs. These benefits are all side-effects
|
||||
of a well-written test suite with good coverage.
|
||||
Unit tests don't need to be twisted or manipulated to serve all of those broad-ranging goals.
|
||||
Rather, it is in the essential nature of a unit test to satisfy all of those needs.
|
||||
These benefits are all side-effects of a well-written test suite with good coverage.
|
||||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
|
|
@ -38,6 +42,7 @@ of a well-written test suite with good coverage.
|
|||
|
||||
Traduit grossièrement depuis un article sur \url{https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d\#.kfyvxyb21\%3E\%60_}:
|
||||
|
||||
% TODO : Finir le verbatim ci-dessous : "ils sont.... ??????"
|
||||
\begin{verbatim}
|
||||
Vos tests sont la première et la meilleure ligne de défense contre les défauts de programmation. Ils sont
|
||||
\end{verbatim}
|
||||
|
|
@ -48,8 +53,7 @@ Les tests unitaires combinent de nombreuses fonctionnalités, qui en fait une ar
|
|||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Aide au design: écrire des tests avant d'écrire le code vous donnera
|
||||
une meilleure perspective sur le design à appliquer aux API.
|
||||
Aide au design: écrire des tests avant d'écrire le code vous donnera une meilleure perspective sur le design à appliquer aux API.
|
||||
\item
|
||||
Documentation (pour les développeurs): chaque description d'un test
|
||||
\item
|
||||
|
|
@ -98,10 +102,13 @@ Si nous rencontrons une condition, elle passera à 2, etc.
|
|||
Cette complexité est liée à deux concepts:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{La lisibilité du code}: au plus la complexité cyclomatique sera élevée, au plus le code sera compliqué à comprendre en première instance. Il sera composé de plusieurs conditions, éventuellement imbriquées, il débordera probablement de la hauteur que votre écran sera capable d'afficher
|
||||
\item \textbf{Les tests unitaires}: pour nous assurer d'une couverture de code correcte, il sera nécessaire de couvrir tous les embranchements présentés. Connaître la complexité permet de savoir combien de tests devront être écrits pour assurer une couverture complète de tous les cas pouvant se présenter.
|
||||
\item
|
||||
\textbf{La lisibilité du code}: au plus la complexité cyclomatique sera élevée, au plus le code sera compliqué à comprendre en première instance. Il sera composé de plusieurs conditions, éventuellement imbriquées, il débordera probablement de la hauteur que votre écran sera capable d'afficher
|
||||
\item
|
||||
\textbf{Les tests unitaires}: pour nous assurer d'une couverture de code correcte, il sera nécessaire de couvrir tous les embranchements présentés. Connaître la complexité permet de savoir combien de tests devront être écrits pour assurer une couverture complète de tous les cas pouvant se présenter.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Lisibilité du code}
|
||||
|
||||
Il est important de noter que refactoriser un bloc, par exemple en extrayant une méthode, n'améliore pas la complexité cyclomatique globale de l'application.
|
||||
|
|
@ -195,14 +202,12 @@ Idéalement, chaque fonction ou méthode doit être testée afin de bien en vali
|
|||
Cela permet d'isoler chaque bloc de manière unitaire, et permet de ne pas rencontrer de régression lors de l'ajout d'une nouvelle fonctionnalité ou de la modification d'une existante.
|
||||
Il existe plusieurs types de tests (intégration, comportement, ...)
|
||||
|
||||
Avoir des tests, c'est bien. S'assurer que tout est testé, c'est mieux.
|
||||
Avoir des tests, c'est bien.
|
||||
S'assurer que tout est testé, c'est mieux.
|
||||
C'est ici qu'il est utile d'avoir le pourcentage de code couvert par les différents tests, pour savoir ce qui peut être amélioré, le but du jeu consistant simplement à augmenter ou égaler le pourcentage de couverture de code existant avant chaque modification.
|
||||
Gitlab permet de visualiser cette information de manière très propre, en l'affichant au niveau de chaque proposition d'intégration.
|
||||
La couverture de code est une analyse qui donne un pourcentage lié à la
|
||||
quantité de code couvert par les tests. Attention qu'il ne s'agit pas de
|
||||
vérifier que le code est \textbf{bien} testé, mais juste de vérifier
|
||||
\textbf{quelle partie} du code est testée. Le paquet \texttt{coverage}
|
||||
se charge d'évaluer le pourcentage de code couvert par les tests.
|
||||
La couverture de code est une analyse qui donne un pourcentage lié à la quantité de code couvert par les tests. Attention qu'il ne s'agit pas de vérifier que le code est \textbf{bien} testé, mais juste de vérifier \textbf{quelle partie} du code est testée.
|
||||
Le paquet \texttt{coverage} se charge d'évaluer le pourcentage de code couvert par les tests.
|
||||
|
||||
\subsection{Tests d'acceptance}
|
||||
|
||||
|
|
@ -211,9 +216,7 @@ se charge d'évaluer le pourcentage de code couvert par les tests.
|
|||
what the customer meant it to.
|
||||
\end{quote}
|
||||
|
||||
Les tests d’acceptance vérifient que l’application fonctionne comme convenu, mais à un
|
||||
plus haut niveau (fonctionnement correct d’une API, validation d’une chaîne d’actions
|
||||
effectuées par un humain, ...).
|
||||
Les tests d’acceptance vérifient que l’application fonctionne comme convenu, mais à un plus haut niveau (fonctionnement correct d’une API, validation d’une chaîne d’actions effectuées par un humain, ...).
|
||||
|
||||
\subsection{Tests d'intégration}
|
||||
|
||||
|
|
|
|||
|
|
@ -20,11 +20,7 @@ Si vous manquez d'idées ou si vous ne savez pas par où commencer:
|
|||
\href{https://github.com/preservim/nerdtree}{nerdtree}
|
||||
\end{itemize}
|
||||
|
||||
Si vous hésitez, et même si Codium n'est pas le plus léger (la faute à
|
||||
\href{https://www.electronjs.org/}{Electron}\ldots\hspace{0pt}), il fera
|
||||
correctement son travail (à savoir: faciliter le vôtre), en intégrant
|
||||
suffisament de fonctionnalités qui gâteront les papilles émoustillées du
|
||||
développeur impatient.
|
||||
Si vous hésitez, et même si Codium n'est pas le plus léger (la faute à \href{https://www.electronjs.org/}{Electron}\ldots\hspace{0pt}), il fera correctement son travail (à savoir : faciliter le vôtre), en intégrant suffisament de fonctionnalités qui gâteront les papilles émoustillées du développeur impatient.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
|
|
@ -39,7 +35,6 @@ développeur impatient.
|
|||
|
||||
\subsection{Mode debug - launch.json}
|
||||
|
||||
|
||||
\section{Terminal}
|
||||
|
||||
\emph{A priori}, les IDE proposés ci-dessus fournissent par défaut ou \emph{via} des greffons un terminal intégré.
|
||||
|
|
@ -47,13 +42,11 @@ Ceci dit, disposer d'un terminal séparé facilite parfois certaines tâches.
|
|||
A nouveau, si vous manquez d'idées :
|
||||
|
||||
\begin{enumerate}
|
||||
\item Soit vous utilisez celui qui intégré à VSCodium et qui fera suffisament bien son travail
|
||||
\item
|
||||
Si vous êtes sous Windows, téléchargez une copie de
|
||||
\href{https://cmder.net/}{Cmder}. Il n'est pas le plus rapide, mais
|
||||
propose une intégration des outils Unix communs (\texttt{ls},
|
||||
\texttt{pwd}, \texttt{grep}, \texttt{ssh}, \texttt{git},
|
||||
\ldots\hspace{0pt}) sans trop se fouler.
|
||||
Soit vous utilisez celui qui intégré à VSCodium et qui fera suffisament bien son travail
|
||||
\item
|
||||
Si vous êtes sous Windows, téléchargez une copie de \href{https://cmder.net/}{Cmder}.
|
||||
Il n'est pas le plus rapide, mais propose une intégration des outils Unix communs (\texttt{ls}, \texttt{pwd}, \texttt{grep}, \texttt{ssh}, \texttt{git}, \ldots\hspace{0pt}) sans trop se fouler.
|
||||
\item
|
||||
Pour tout autre système, vous devriez disposer en natif de ce qu'il faut.
|
||||
\end{enumerate}
|
||||
|
|
@ -98,8 +91,7 @@ De cette manière, il est beaucoup plus facile pour le développeur de se concen
|
|||
\caption{Git en action}
|
||||
\end{figure}
|
||||
|
||||
Cas pratique: vous développez cette nouvelle fonctionnalité qui va révolutionner le monde de demain et d'après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux
|
||||
normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
|
||||
Cas pratique: vous développez cette nouvelle fonctionnalité qui va révolutionner le monde de demain et d'après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
|
||||
Il suffit alors de:
|
||||
|
||||
\begin{enumerate}
|
||||
|
|
@ -112,11 +104,9 @@ Il suffit alors de:
|
|||
\item
|
||||
Solutionner le problème (sans doute un \texttt{;} en trop ?)
|
||||
\item
|
||||
Sauver le correctif sur cette branche
|
||||
(\texttt{git\ add\ .\ \&\&\ git\ commit\ -m\ "Did\ it!"})
|
||||
Sauver le correctif sur cette branche (\texttt{git\ add\ .\ \&\&\ git\ commit\ -m\ "Did\ it!"})
|
||||
\item
|
||||
Récupérer ce correctif sur la branche principal
|
||||
(\texttt{git\ checkout\ main\ \&\&\ git\ merge\ hotfix/pci-compliance})
|
||||
Récupérer ce correctif sur la branche principal (\texttt{git\ checkout\ main\ \&\&\ git\ merge\ hotfix/pci-compliance})
|
||||
\item
|
||||
Et revenir tranquillou sur votre branche de développement pour fignoler ce générateur de noms de dinosaures rigolos que l'univers vous réclame à cor et à a cri (\texttt{git\ checkout\ features/dinolol})
|
||||
\end{enumerate}
|
||||
|
|
@ -179,22 +169,15 @@ Most websites don't need that kind of throughput. \cite{consider_sqlite}
|
|||
\subsection{Gestionnaires}
|
||||
|
||||
Il n'est pas obligatoire de disposer d'une application de gestion pour ces moteurs: pour les cas d'utilisation simples, le shell Django pourra largement suffire (nous y reviendrons).
|
||||
Mais pour faciliter la gestion des bases de données elles-même, et si vous n'êtes pas à l'aise avec la
|
||||
ligne de commande, choisissez l'une des applications d'administration
|
||||
ci-dessous en fonction du moteur de base de données que vous souhaitez
|
||||
utiliser.
|
||||
Mais pour faciliter la gestion des bases de données elles-même, et si vous n'êtes pas à l'aise avec la ligne de commande, choisissez l'une des applications d'administration ci-dessous en fonction du moteur de base de données que vous souhaitez utiliser.
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Pour \textbf{PostgreSQL}, il existe
|
||||
\href{https://www.pgadmin.org/}{pgAdmin}
|
||||
Pour \textbf{PostgreSQL}, il existe \href{https://www.pgadmin.org/}{pgAdmin}
|
||||
\item
|
||||
Pour \textbf{MariaDB} ou \textbf{MySQL}, partez sur
|
||||
\href{https://www.phpmyadmin.net/}{PHPMyAdmin}
|
||||
Pour \textbf{MariaDB} ou \textbf{MySQL}, partez sur \href{https://www.phpmyadmin.net/}{PHPMyAdmin}
|
||||
\item
|
||||
Pour \textbf{SQLite}, il existe
|
||||
\href{https://sqlitebrowser.org/}{SQLiteBrowser} PHPMyAdmin ou
|
||||
PgAdmin.
|
||||
Pour \textbf{SQLite}, il existe \href{https://sqlitebrowser.org/}{SQLiteBrowser} PHPMyAdmin ou PgAdmin.
|
||||
\end{itemize}
|
||||
|
||||
\section{Intégration continue}
|
||||
|
|
@ -202,4 +185,3 @@ utiliser.
|
|||
\subsection{Qualité du code}
|
||||
|
||||
Code climate, SonarQube.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,9 @@
|
|||
\chapter{URLs et espaces de noms}
|
||||
|
||||
|
||||
La gestion des URLs permet \textbf{grosso modo} d'assigner une adresse
|
||||
paramétrée ou non à une fonction Python. La manière simple consiste à
|
||||
modifier le fichier \texttt{gwift/settings.py} pour y ajouter nos
|
||||
correspondances. Par défaut, le fichier ressemble à ceci:
|
||||
La gestion des URLs permet \textbf{grosso modo} d'assigner une adresse paramétrée ou non à une fonction Python.
|
||||
La manière simple consiste à modifier le fichier \texttt{gwift/settings.py} pour y ajouter nos correspondances.
|
||||
Par défaut, le fichier ressemble à ceci:
|
||||
|
||||
\begin{minted}{python}
|
||||
# gwift/urls.py
|
||||
|
|
@ -18,24 +17,12 @@ urlpatterns = [
|
|||
\end{minted}
|
||||
|
||||
|
||||
La variable \texttt{urlpatterns} associe un ensemble d'adresses à des
|
||||
fonctions. Dans le fichier \textbf{nu}, seul le \textbf{pattern}
|
||||
\texttt{admin} est défini, et inclut toutes les adresses qui sont
|
||||
définies dans le fichier \texttt{admin.site.urls}.
|
||||
|
||||
Django fonctionne avec des \textbf{expressions rationnelles} simplifiées
|
||||
(des \textbf{expressions régulières} ou \textbf{regex}) pour trouver une
|
||||
correspondance entre une URL et la fonction qui recevra la requête et
|
||||
retournera une réponse. Nous utilisons l'expression \texttt{\^{}\$} pour
|
||||
déterminer la racine de notre application, mais nous pourrions appliquer
|
||||
d'autres regroupements (\texttt{/home},
|
||||
\texttt{users/\textless{}profile\_id\textgreater{}},
|
||||
\texttt{articles/\textless{}year\textgreater{}/\textless{}month\textgreater{}/\textless{}day\textgreater{}},
|
||||
\ldots\hspace{0pt}). Chaque \textbf{variable} déclarée dans l'expression
|
||||
régulière sera apparenté à un paramètre dans la fonction correspondante.
|
||||
Ainsi, pour reprendre l'exemple où nous étions restés:
|
||||
|
||||
La variable \texttt{urlpatterns} associe un ensemble d'adresses à des fonctions.
|
||||
Dans le fichier \textbf{nu}, seul le \textbf{pattern} \texttt{admin} est défini, et inclut toutes les adresses qui sont définies dans le fichier \texttt{admin.site.urls}.
|
||||
|
||||
Django fonctionne avec des \textbf{expressions rationnelles} simplifiées (des \textbf{expressions régulières} ou \textbf{regex}) pour trouver une correspondance entre une URL et la fonction qui recevra la requête et retournera une réponse.
|
||||
Nous utilisons l'expression \texttt{\^{}\$} pour déterminer la racine de notre application, mais nous pourrions appliquer d'autres regroupements (\texttt{/home}, \texttt{users/\textless{}profile\_id\textgreater{}}, \texttt{articles/\textless{}year\textgreater{}/\textless{}month\textgreater{}/\textless{}day\textgreater{}}, \ldots\hspace{0pt}).
|
||||
Chaque \textbf{variable} déclarée dans l'expression régulière sera apparenté à un paramètre dans la fonction correspondante. Ainsi, pour reprendre l'exemple où nous étions restés:
|
||||
|
||||
\begin{minted}{python}
|
||||
# gwift/urls.py
|
||||
|
|
@ -51,18 +38,12 @@ urlpatterns = [
|
|||
]
|
||||
\end{minted}
|
||||
|
||||
Dans la mesure du possible, essayez toujours de \textbf{nommer} chaque expression.
|
||||
Cela permettra notamment de les retrouver au travers de la fonction \texttt{reverse}, mais permettra également de simplifier vos templates.
|
||||
|
||||
Dans la mesure du possible, essayez toujours de \textbf{nommer} chaque
|
||||
expression. Cela permettra notamment de les retrouver au travers de la
|
||||
fonction \texttt{reverse}, mais permettra également de simplifier vos
|
||||
templates.
|
||||
A présent, on doit tester que l'URL racine de notre application mène bien vers la fonction \texttt{wish\_views.wishlists}.
|
||||
|
||||
A présent, on doit tester que l'URL racine de notre application mène
|
||||
bien vers la fonction \texttt{wish\_views.wishlists}.
|
||||
|
||||
Sauf que les pages \texttt{about} et \texttt{help} existent également.
|
||||
Pour implémenter ce type de précédence, il faudrait implémenter les URLs
|
||||
de la manière suivante:
|
||||
Sauf que les pages \texttt{about} et \texttt{help} existent également. Pour implémenter ce type de précédence, il faudrait implémenter les URLs de la manière suivante:
|
||||
|
||||
\begin{verbatim}
|
||||
| about
|
||||
|
|
@ -70,32 +51,21 @@ de la manière suivante:
|
|||
| <user>
|
||||
\end{verbatim}
|
||||
|
||||
Mais cela signifie aussi que les utilisateurs \texttt{about} et
|
||||
\texttt{help} (s'ils existent\ldots\hspace{0pt}) ne pourront jamais
|
||||
accéder à leur profil. Une dernière solution serait de maintenir une
|
||||
liste d'authorité des noms d'utilisateur qu'il n'est pas possible
|
||||
d'utiliser.
|
||||
Mais cela signifie aussi que les utilisateurs \texttt{about} et \texttt{help} (s'ils existent\ldots\hspace{0pt}) ne pourront jamais accéder à leur profil.
|
||||
Une dernière solution serait de maintenir une liste d'authorité des noms d'utilisateur qu'il n'est pas possible d'utiliser.
|
||||
|
||||
D'où l'importance de bien définir la séquence de déinition de ces
|
||||
routes, ainsi que des espaces de noms.
|
||||
D'où l'importance de bien définir la séquence de déinition de ces routes, ainsi que des espaces de noms.
|
||||
|
||||
Note sur les namespaces.
|
||||
|
||||
De là, découle une autre bonne pratique: l'utilisation de
|
||||
\emph{breadcrumbs}
|
||||
(\url{https://stackoverflow.com/questions/826889/how-to-implement-breadcrumbs-in-a-django-template})
|
||||
ou de guidelines de navigation.
|
||||
De là, découle une autre bonne pratique: l'utilisation de \emph{breadcrumbs} (\url{https://stackoverflow.com/questions/826889/how-to-implement-breadcrumbs-in-a-django-template}) ou de guidelines de navigation.
|
||||
|
||||
|
||||
\section{Reverse}
|
||||
|
||||
En associant un nom ou un libellé à chaque URL, il est possible de récupérer sa \textbf{traduction}. Cela implique par contre de ne plus toucher à ce libellé par la suite\ldots\hspace{0pt}
|
||||
|
||||
En associant un nom ou un libellé à chaque URL, il est possible de
|
||||
récupérer sa \textbf{traduction}. Cela implique par contre de ne plus
|
||||
toucher à ce libellé par la suite\ldots\hspace{0pt}
|
||||
|
||||
Dans le fichier \texttt{urls.py}, on associe le libellé
|
||||
\texttt{wishlists} à l'URL \texttt{r\textquotesingle{}\^{}\$}
|
||||
(c'est-à-dire la racine du site):
|
||||
Dans le fichier \texttt{urls.py}, on associe le libellé \texttt{wishlists} à l'URL \texttt{r\textquotesingle{}\^{}\$} (c'est-à-dire la racine du site):
|
||||
|
||||
\begin{minted}{python}
|
||||
from wish.views import WishListList
|
||||
|
|
@ -106,17 +76,13 @@ urlpatterns = [
|
|||
]
|
||||
\end{minted}
|
||||
|
||||
|
||||
De cette manière, dans nos templates, on peut à présent construire un
|
||||
lien vers la racine avec le tags suivant:
|
||||
De cette manière, dans nos templates, on peut à présent construire un lien vers la racine avec le tags suivant:
|
||||
|
||||
\begin{minted}{html}
|
||||
<a href="{% url 'wishlists' %}">{{ yearvar }} Archive</a>
|
||||
\end{minted}
|
||||
|
||||
|
||||
De la même manière, on peut également récupérer l'URL de destination
|
||||
pour n'importe quel libellé, de la manière suivante:
|
||||
De la même manière, on peut également récupérer l'URL de destination pour n'importe quel libellé, de la manière suivante:
|
||||
|
||||
\begin{minted}{python}
|
||||
from django.core.urlresolvers import reverse_lazy
|
||||
|
|
|
|||
|
|
@ -1,16 +1,10 @@
|
|||
|
||||
\chapter{Travailler en isolation}
|
||||
|
||||
Nous allons aborder la gestion et l'isolation des dépendances. Cette
|
||||
section est aussi utile pour une personne travaillant seule, que pour
|
||||
transmettre les connaissances à un nouveau membre de l'équipe ou pour
|
||||
déployer l'application elle-même.
|
||||
Nous allons aborder la gestion et l'isolation des dépendances. Cette section est aussi utile pour une personne travaillant seule, que pour transmettre les connaissances à un nouveau membre de l'équipe ou pour déployer l'application elle-même.
|
||||
|
||||
Il en était déjà question au deuxième point des 12 facteurs: même dans
|
||||
le cas de petits projets, il est déconseillé de s'en passer. Cela évite
|
||||
les déploiements effectués à l'arrache à grand renfort de \texttt{sudo}
|
||||
et d'installation globale de dépendances, pouvant potentiellement
|
||||
occasioner des conflits entre les applications déployées:
|
||||
Il en était déjà question au deuxième point des 12 facteurs: même dans le cas de petits projets, il est déconseillé de s'en passer.
|
||||
Cela évite les déploiements effectués à l'arrache à grand renfort de \texttt{sudo} et d'installation globale de dépendances, pouvant potentiellement occasioner des conflits entre les applications déployées:
|
||||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
|
|
@ -33,9 +27,9 @@ occasioner des conflits entre les applications déployées:
|
|||
\caption{\url{https://xkcd.com/1987}}
|
||||
\end{figure}
|
||||
|
||||
Un des reproches que l'on peut faire au langage concerne sa versatilité: il est possible de réaliser beaucoup de choses, mais celles-ci ne sont
|
||||
pas toujours simples ou directes.
|
||||
Pour quelqu'un qui débarquererait, la quantité d'options différentes peut paraître rebutante. Nous pensons notamment aux environnements virtuels: ils sont géniaux à utiliser, mais on est passé par virtualenv (l'ancêtre), virtualenvwrapper (sa version améliorée et plus ergonomique), \texttt{venv} (la version intégrée depuis la version 3.3 de l'interpréteur, et \href{https://docs.python.org/3/library/venv.html}{la manière recommandée} de créer un environnement depuis la 3.5).
|
||||
Un des reproches que l'on peut faire au langage concerne sa versatilité: il est possible de réaliser beaucoup de choses, mais celles-ci ne sont pas toujours simples ou directes.
|
||||
Pour quelqu'un qui débarquererait, la quantité d'options différentes peut paraître rebutante.
|
||||
Nous pensons notamment aux environnements virtuels : ils sont géniaux à utiliser, mais on est passé par virtualenv (l'ancêtre), virtualenvwrapper (sa version améliorée et plus ergonomique), \texttt{venv} (la version intégrée depuis la version 3.3 de l'interpréteur, et \href{https://docs.python.org/3/library/venv.html}{la manière recommandée} de créer un environnement depuis la 3.5).
|
||||
|
||||
Pour créer un nouvel environnement, vous aurez donc besoin:
|
||||
|
||||
|
|
@ -48,8 +42,7 @@ Pour créer un nouvel environnement, vous aurez donc besoin:
|
|||
|
||||
|
||||
Il existe plusieurs autres modules permettant d'arriver au même résultat, avec quelques avantages et inconvénients pour chacun d'entre eux.
|
||||
Le plus prometteur d'entre eux est \href{https://python-poetry.org/}{Poetry}, qui dispose d'une interface
|
||||
en ligne de commande plus propre et plus moderne que ce que PIP propose.
|
||||
Le plus prometteur d'entre eux est \href{https://python-poetry.org/}{Poetry}, qui dispose d'une interface en ligne de commande plus propre et plus moderne que ce que PIP propose.
|
||||
|
||||
|
||||
\subsection{Poetry}
|
||||
|
|
@ -77,8 +70,7 @@ Ceci signifie que nous avons directement (et de manière standard):
|
|||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Un répertoire django-gecko, qui porte le nom de l'application que vous
|
||||
venez de créer
|
||||
Un répertoire django-gecko, qui porte le nom de l'application que vous venez de créer
|
||||
\item
|
||||
Un répertoires tests, libellé selon les standards de pytest
|
||||
\item
|
||||
|
|
@ -105,37 +97,26 @@ requires = ["poetry-core>=1.0.0"]
|
|||
build-backend = "poetry.core.masonry.api"
|
||||
\end{verbatim}
|
||||
|
||||
La commande \texttt{poetry\ init} permet de générer interactivement les
|
||||
fichiers nécessaires à son intégration dans un projet existant.
|
||||
La commande \texttt{poetry\ init} permet de générer interactivement les fichiers nécessaires à son intégration dans un projet existant.
|
||||
|
||||
J'ai pour habitude de conserver mes projets dans un répertoire
|
||||
\texttt{\textasciitilde{}/Sources/} et mes environnements virtuels dans
|
||||
un répertoire \texttt{\textasciitilde{}/.venvs/}.
|
||||
J'ai pour habitude de conserver mes projets dans un répertoire \texttt{\textasciitilde{}/Sources/} et mes environnements virtuels dans un répertoire \texttt{\textasciitilde{}/.venvs/}.
|
||||
|
||||
Cette séparation évite que l'environnement virtuel ne se trouve dans le même répertoire que les sources, ou ne soit accidentellement envoyé vers le système de gestion de versions. Elle évite également de rendre ce
|
||||
répertoire "visible" - il ne s'agit au fond que d'un paramètre de configuration lié uniquement à votre environnement de développement; les environnements virtuels étant disposables, il n'est pas conseillé de trop les lier au projet qui l'utilise comme base.
|
||||
Cette séparation évite que l'environnement virtuel ne se trouve dans le même répertoire que les sources, ou ne soit accidentellement envoyé vers le système de gestion de versions.
|
||||
Elle évite également de rendre ce répertoire "visible" - il ne s'agit au fond que d'un paramètre de configuration lié uniquement à votre environnement de développement; les environnements virtuels étant disposables, il n'est pas conseillé de trop les lier au projet qui l'utilise comme base.
|
||||
Dans la suite de ce chapitre, je considérerai ces mêmes répertoires, mais n'hésitez pas à les modifier.
|
||||
|
||||
DANGER: Indépendamment de l'endroit où vous stockerez le répertoire
|
||||
contenant cet environnement, il est primordial de \textbf{ne pas le
|
||||
conserver dans votre dépôt de stockager}. Cela irait à l'encontre des
|
||||
douze facteurs, cela polluera inutilement vos sources et créera des
|
||||
conflits avec l'environnement des personnes qui souhaiteraient
|
||||
intervenir sur le projet.
|
||||
DANGER: Indépendamment de l'endroit où vous stockerez le répertoire contenant cet environnement, il est primordial de \textbf{ne pas le conserver dans votre dépôt de stockager}.
|
||||
Cela irait à l'encontre des douze facteurs, cela polluera inutilement vos sources et créera des conflits avec l'environnement des personnes qui souhaiteraient intervenir sur le projet.
|
||||
|
||||
Pur créer notre répertoire de travail et notre environnement virtuel,
|
||||
exécutez les commandes suivantes:
|
||||
Pur créer notre répertoire de travail et notre environnement virtuel, exécutez les commandes suivantes:
|
||||
|
||||
\begin{verbatim}
|
||||
mkdir ~/.venvs/
|
||||
python -m venv ~/.venvs/gwift-venv
|
||||
\end{verbatim}
|
||||
|
||||
Ceci aura pour effet de créer un nouveau répertoire
|
||||
(\texttt{\textasciitilde{}/.venvs/gwift-env/}), dans lequel vous
|
||||
trouverez une installation complète de l'interpréteur Python. Votre
|
||||
environnement virtuel est prêt, il n'y a plus qu'à indiquer que nous
|
||||
souhaitons l'utiliser, grâce à l'une des commandes suivantes:
|
||||
Ceci aura pour effet de créer un nouveau répertoire (\texttt{\textasciitilde{}/.venvs/gwift-env/}), dans lequel vous trouverez une installation complète de l'interpréteur Python.
|
||||
Votre environnement virtuel est prêt, il n'y a plus qu'à indiquer que nous souhaitons l'utiliser, grâce à l'une des commandes suivantes:
|
||||
|
||||
\begin{verbatim}
|
||||
# GNU/Linux, macOS
|
||||
|
|
@ -147,46 +128,31 @@ souhaitons l'utiliser, grâce à l'une des commandes suivantes:
|
|||
\end{verbatim}
|
||||
|
||||
|
||||
A présent que l'environnement est activé, tous les binaires de cet
|
||||
environnement prendront le pas sur les binaires du système. De la même
|
||||
manière, une variable \texttt{PATH} propre est définie et utilisée, afin
|
||||
que les librairies Python y soient stockées. C'est donc dans cet
|
||||
environnement virtuel que nous retrouverons le code source de Django,
|
||||
ainsi que des librairies externes pour Python une fois que nous les
|
||||
A présent que l'environnement est activé, tous les binaires de cet environnement prendront le pas sur les binaires du système.
|
||||
De la même manière, une variable \texttt{PATH} propre est définie et utilisée, afin que les librairies Python y soient stockées.
|
||||
C'est donc dans cet environnement virtuel que nous retrouverons le code source de Django, ainsi que des librairies externes pour Python une fois que nous les
|
||||
aurons installées.
|
||||
|
||||
Pour les curieux, un environnement virtuel n'est jamais qu'un répertoire
|
||||
dans lequel se trouve une installation fraîche de l'interpréteur, vers
|
||||
laquelle pointe les liens symboliques des binaires. Si vous recherchez
|
||||
l'emplacement de l'interpréteur avec la commande \texttt{which\ python},
|
||||
vous recevrez comme réponse
|
||||
\texttt{/home/fred/.venvs/gwift-env/bin/python}.
|
||||
Pour les curieux, un environnement virtuel n'est jamais qu'un répertoire dans lequel se trouve une installation fraîche de l'interpréteur, vers laquelle pointe les liens symboliques des binaires.
|
||||
Si vous recherchez l'emplacement de l'interpréteur avec la commande \texttt{which\ python}, vous recevrez comme réponse \texttt{/home/fred/.venvs/gwift-env/bin/python}.
|
||||
|
||||
Pour sortir de l'environnement virtuel, exécutez la commande
|
||||
\texttt{deactivate}. Si vous pensez ne plus en avoir besoin, supprimer
|
||||
le dossier. Si nécessaire, il suffira d'en créer un nouveau.
|
||||
Pour sortir de l'environnement virtuel, exécutez la commande \texttt{deactivate}.
|
||||
Si vous pensez ne plus en avoir besoin, supprimer le dossier.
|
||||
Si nécessaire, il suffira d'en créer un nouveau.
|
||||
|
||||
Pour gérer des versions différentes d'une même librairie, il nous suffit
|
||||
de jongler avec autant d'environnements que nécessaires. Une application
|
||||
nécessite une version de Django inférieure à la 2.0 ? On crée un
|
||||
environnement, on l'active et on installe ce qu'il faut.
|
||||
Pour gérer des versions différentes d'une même librairie, il nous suffit de jongler avec autant d'environnements que nécessaires.
|
||||
Une application nécessite une version de Django inférieure à la 2.0 ? On crée un environnement, on l'active et on installe ce qu'il faut.
|
||||
|
||||
Cette technique fonctionnera autant pour un poste de développement que
|
||||
sur les serveurs destinés à recevoir notre application.
|
||||
Cette technique fonctionnera autant pour un poste de développement que sur les serveurs destinés à recevoir notre application.
|
||||
|
||||
Par la suite, nous considérerons que l'environnement virtuel est
|
||||
toujours activé, même si \texttt{gwift-env} n'est pas indiqué.
|
||||
Par la suite, nous considérerons que l'environnement virtuel est toujours activé, même si \texttt{gwift-env} n'est pas indiqué.
|
||||
|
||||
a manière recommandée pour la gestion des dépendances consiste à les
|
||||
épingler dans un fichier requirements.txt, placé à la racine du projet.
|
||||
Ce fichier reprend, ligne par ligne, chaque dépendance et la version
|
||||
nécessaire. Cet épinglage est cependant relativement basique, dans la
|
||||
mesure où les opérateurs disponibles sont ==, et \textgreater=.
|
||||
a manière recommandée pour la gestion des dépendances consiste à les épingler dans un fichier requirements.txt, placé à la racine du projet.
|
||||
Ce fichier reprend, ligne par ligne, chaque dépendance et la version nécessaire.
|
||||
Cet épinglage est cependant relativement basique, dans la mesure où les opérateurs disponibles sont ==, et \textgreater=.
|
||||
|
||||
Poetry propose un épinglage basé sur SemVer. Les contraintes qui peuvent
|
||||
être appliquées aux dépendances sont plus touffues que ce que proposent
|
||||
pip -r, avec la présence du curseur \^{}, qui ne modifiera pas le nombre
|
||||
différent de zéro le plus à gauche:
|
||||
Poetry propose un épinglage basé sur SemVer.
|
||||
Les contraintes qui peuvent être appliquées aux dépendances sont plus touffues que ce que proposent pip -r, avec la présence du curseur \^{}, qui ne modifiera pas le nombre différent de zéro le plus à gauche:
|
||||
|
||||
\begin{verbatim}
|
||||
^1.2.3 (où le nombre en question est 1) pourra proposer une mise à jour jusqu'à la version juste avant la version 2.0.0
|
||||
|
|
@ -297,8 +263,7 @@ Ce qui est quand même 'achement plus simple que d'appréhender tout un
|
|||
|
||||
\section{Un système de virtualisation}
|
||||
|
||||
Par "\emph{système de virtualisation}", nous entendons n'importe quel application, système d'exploitation, système de containeurisation, ... qui permette de créer ou recréer un environnement de
|
||||
développement aussi proche que celui en production.
|
||||
Par "\emph{système de virtualisation}", nous entendons n'importe quel application, système d'exploitation, système de containeurisation, ... qui permette de créer ou recréer un environnement de développement aussi proche que celui en production.
|
||||
Les solutions sont nombreuses:
|
||||
|
||||
\begin{itemize}
|
||||
|
|
@ -331,32 +296,19 @@ Vagrant consiste en un outil de création et de gestion d'environnements virtual
|
|||
the past. \footnote{\url{https://www.vagrantup.com/intro}}
|
||||
\end{quote}
|
||||
|
||||
La partie la plus importante de la configuration de Vagrant pour votre
|
||||
projet consiste à placer un fichier \texttt{Vagrantfile} - \emph{a
|
||||
priori} à la racine de votre projet - et qui contiendra les information
|
||||
suivantes:
|
||||
La partie la plus importante de la configuration de Vagrant pour votre projet consiste à placer un fichier \texttt{Vagrantfile} - \emph{a priori} à la racine de votre projet - et qui contiendra les information suivantes:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Le choix du \emph{fournisseur} (\textbf{provider}) de virtualisation
|
||||
(Virtualbox, Hyper-V et Docker sont natifs; il est également possible
|
||||
de passer par VMWare, AWS, etc.)
|
||||
Le choix du \emph{fournisseur} (\textbf{provider}) de virtualisation (Virtualbox, Hyper-V et Docker sont natifs; il est également possible de passer par VMWare, AWS, etc.)
|
||||
\item
|
||||
Une \emph{box}, qui consiste à lui indiquer le type et la version
|
||||
attendue du système virtualisé (Debian 10, Ubuntu 20.04, etc. - et
|
||||
\href{https://app.vagrantup.com/boxes/search}{il y a du choix}).
|
||||
Une \emph{box}, qui consiste à lui indiquer le type et la version attendue du système virtualisé (Debian 10, Ubuntu 20.04, etc. - et \href{https://app.vagrantup.com/boxes/search}{il y a du choix}).
|
||||
\item
|
||||
La manière dont la fourniture (\textbf{provisioning}) de
|
||||
l'environnement doit être réalisée: scripts Shell, fichiers, Ansible,
|
||||
Puppet, Chef, \ldots\hspace{0pt} Choisissez votre favori :-) même s'il
|
||||
est toujours possible de passer par une installation et une
|
||||
maintenance manuelle, après s'être connecté sur la machine.
|
||||
La manière dont la fourniture (\textbf{provisioning}) de l'environnement doit être réalisée : scripts Shell, fichiers, Ansible, Puppet, Chef, \ldots\hspace{0pt} Choisissez votre favori :-) même s'il est toujours possible de passer par une installation et une maintenance manuelle, après s'être connecté sur la machine.
|
||||
\item
|
||||
Si un espace de stockage doit être partagé entre la machine virtuelle
|
||||
et l'hôte
|
||||
Si un espace de stockage doit être partagé entre la machine virtuelle et l'hôte
|
||||
\item
|
||||
Les ports qui doivent être transmis de la machine virtuelle vers
|
||||
l'hôte.
|
||||
Les ports qui doivent être transmis de la machine virtuelle vers l'hôte.
|
||||
\end{itemize}
|
||||
|
||||
La syntaxe de ce fichier \texttt{Vagrantfile} est en \href{https://www.ruby-lang.org/en/}{Ruby}.
|
||||
|
|
|
|||
|
|
@ -21,10 +21,14 @@
|
|||
|
||||
Il y a une raison très simple à aborder le déploiement dès maintenant : à trop attendre et à peaufiner son développement en local, on en oublie que sa finalité sera de se retrouver exposé et accessible depuis un
|
||||
serveur.
|
||||
En cas de dérogation à ceci, il sera probable d'oublier une partie des désidérata, de zapper une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles puissent être mises à disposition sur un environnement en particulier, une fois que leur développement aura été finalisé, testé et validé.
|
||||
Un bon déploiement ne doit pas dépendre de dizaines de petits scripts éparpillés sur le disque: l'objectif est qu'il soit rapide et fiable. Ceci peut être atteint au travers d'un partitionnement correct, incluant le fait que le composant principal s'assure que chaque sous-composant est correctement démarré intégré et supervisé.
|
||||
Il est du coup probable d'oublier une partie des désidérata, de zapper une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles puissent être mises à
|
||||
disposition sur un environnement en particulier, une fois que leur développement aura été finalisé, testé et validé.
|
||||
Un bon déploiement ne doit pas dépendre de dizaines de petits scripts éparpillés sur le disque.
|
||||
L'objectif est qu'il soit rapide et fiable.
|
||||
Ceci peut être atteint au travers d'un partitionnement correct, incluant le fait que le composant principal s'assure que chaque sous-composant est correctement démarré intégré et supervisé.
|
||||
|
||||
Aborder le déploiement dès le début permet également de rédiger dès le début les procédures d'installation, de mises à jour et de sauvegardes. A la fin de chaque intervalle de développement, les fonctionnalités auront dû avoir été intégrées, testées, fonctionnelles et un code propre, démontrable dans un environnement similaire à un environnement de production, et créées à partir d'un tronc commun au développement
|
||||
Aborder le déploiement dès le début permet également de rédiger dès le début les procédures d'installation, de mises à jour et de sauvegardes.
|
||||
A la fin de chaque intervalle de développement, les fonctionnalités auront dû avoir été intégrées, testées, fonctionnelles et un code propre, démontrable dans un environnement similaire à un environnement de production, et créées à partir d'un tronc commun au développement
|
||||
\cite{devops_handbook}.
|
||||
|
||||
Déploier une nouvelle version doit être le plus simple possible, et doit se résumer, dans le pire des cas, à quelques lignes d'un script Bash.
|
||||
|
|
@ -76,33 +80,21 @@ Dans cette partie, nous aborderons les points suivants:
|
|||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Définir l'infrastructure et les composants nécessaires à notre
|
||||
application
|
||||
Définir l'infrastructure et les composants nécessaires à notre application
|
||||
\item
|
||||
Configurer l'hôte qui hébergera l'application et y déployer notre
|
||||
application: dans une machine physique, virtuelle ou dans un
|
||||
container. Nous aborderons aussi les déploiements via Ansible et Salt.
|
||||
A ce stade, nous aurons déjà une application disponible.
|
||||
Configurer l'hôte qui hébergera l'application et y déployer notre application: dans une machine physique, virtuelle ou dans un container. Nous aborderons aussi les déploiements via Ansible et Salt. A ce stade, nous aurons déjà une application disponible.
|
||||
\item
|
||||
Configurer les outils nécessaires à la bonne exécution de ce code et
|
||||
de ses fonctionnalités: les différentes méthodes de supervision de
|
||||
l'application, comment analyser les fichiers de logs, comment
|
||||
intercepter correctement une erreur si elle se présente et comment
|
||||
remonter correctement l'information.
|
||||
Configurer les outils nécessaires à la bonne exécution de ce code et de ses fonctionnalités: les différentes méthodes de supervision de l'application, comment analyser les fichiers de logs, comment intercepter correctement une erreur si elle se présente et comment remonter correctement l'information.
|
||||
\end{enumerate}
|
||||
|
||||
Nous allons détailler ci-dessous trois méthodes de déploiement:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Sur une machine hôte, en embarquant tous les composants sur un même
|
||||
serveur. Ce ne sera pas idéal, puisqu'il ne sera pas possible de
|
||||
configurer un \emph{load balancer}, de routeur plusieurs basées de
|
||||
données, mais ce sera le premier cas de figure.
|
||||
Sur une machine hôte, en embarquant tous les composants sur un même serveur. Ce ne sera pas idéal, puisqu'il ne sera pas possible de configurer un \emph{load balancer}, de routeur plusieurs basées de données, mais ce sera le premier cas de figure.
|
||||
|
||||
\item Dans des containers, avec Docker-Compose.
|
||||
|
||||
\item
|
||||
Dans des containers, avec Docker-Compose.
|
||||
\item
|
||||
Sur une \textbf{Plateforme en tant que Service} (ou plus simplement,
|
||||
\textbf{PaaSPaaS}), pour faire abstraction de toute la couche de
|
||||
configuration du serveur.
|
||||
Sur une \textbf{Plateforme en tant que Service} (ou plus simplement, \textbf{PaaSPaaS}), pour faire abstraction de toute la couche de configuration du serveur.
|
||||
\end{itemize}
|
||||
|
|
|
|||
|
|
@ -11,8 +11,7 @@ Le code qui permet de faire tourner cette application peut ne pas être élégan
|
|||
|
||||
Les problèmes arriveront lorsqu'une nouvelle demande sera introduite, lorsqu'un bug sera découvert et devra être corrigé ou lorsqu'une dépendance cessera de fonctionner ou d'être disponible.
|
||||
Or, une application qui n'évolue pas, meurt.
|
||||
Toute application est donc destinée, soit à être modifiée, corrigée et suivie, soit à déperrir et à être
|
||||
délaissée par ses utilisateurs.
|
||||
Toute application est donc destinée, soit à être modifiée, corrigée et suivie, soit à déperrir et à être délaissée par ses utilisateurs.
|
||||
Et c'est juste cette maintenance qui est difficile.
|
||||
|
||||
L'application des principes présentés et agrégés ci-dessous permet surtout de préparer correctement tout ce qui pourra arriver, sans aller jusqu'au « \textbf{You Ain't Gonna Need It} » (ou \textbf{YAGNI\index{YAGNI}}), qui consiste à surcharger tout développement avec des fonctionnalités non demandées, juste « au cas ou ».
|
||||
|
|
@ -30,39 +29,22 @@ Le développement d'un logiciel nécessite une rigueur d'exécution et des conna
|
|||
Il nécessite également des intentions, des (bonnes) décisions et énormément d'attention.
|
||||
Indépendamment de l'architecture que vous aurez choisie, des technologies que vous aurez patiemment évaluées et mises en place, une architecture et une solution peuvent être cassées en un instant, en même temps que tout ce que vous aurez construit, dès que vous en aurez détourné le regard.
|
||||
|
||||
Un des objectifs ici est de placer les barrières et les gardes-fous (ou
|
||||
plutôt, les "\textbf{garde-vous}"), afin de péréniser au maximum les
|
||||
acquis, stabiliser les bases de tous les environnements (du
|
||||
développement à la production) qui accueilliront notre application et
|
||||
fiabiliser ainsi chaque étape de communication.
|
||||
Un des objectifs ici est de placer les barrières et les gardes-fous (ou plutôt, les "\textbf{garde-vous}"), afin de péréniser au maximum les acquis, stabiliser les bases de tous les environnements (du développement à la production) qui accueilliront notre application et fiabiliser ainsi chaque étape de communication.
|
||||
|
||||
Dans cette partie-ci, nous parlerons de \textbf{méthodes de travail},
|
||||
avec comme objectif d'éviter que l'application ne tourne que sur notre
|
||||
machine et que chaque déploiement ne soit une plaie à gérer. Chaque mise
|
||||
à jour doit être réalisable de la manière la plus simple possible, et
|
||||
chaque étape doit être rendue la plus automatisée/automatisable
|
||||
possible. Dans son plus simple élément, une application pourrait être
|
||||
mise à jour simplement en envoyant son code sur un dépôt centralisé: ce
|
||||
déclencheur doit démarrer une chaîne de vérification
|
||||
d'utilisabilité/fonctionnalités/débuggabilité/sécurité, pour
|
||||
immédiatement la mettre à disposition de nouveaux utilisateurs si toute
|
||||
la chaîne indique que tout est OK. D'autres mécanismes fonctionnent
|
||||
également, mais au plus les actions nécessitent d'actions humaines,
|
||||
voire d'intervenants humains, au plus la probabilité qu'un problème
|
||||
survienne est grande.
|
||||
Dans cette partie-ci, nous parlerons de \textbf{méthodes de travail}, avec comme objectif d'éviter que l'application ne tourne que sur notre machine et que chaque déploiement ne soit une plaie à gérer.
|
||||
Chaque mise à jour doit être réalisable de la manière la plus simple possible, et chaque étape doit être rendue la plus automatisée/automatisable possible.
|
||||
Dans son plus simple élément, une application pourrait être mise à jour simplement en envoyant son code sur un dépôt centralisé: ce déclencheur doit démarrer une chaîne de vérification d'utilisabilité/fonctionnalités/débuggabilité/sécurité, pour immédiatement la mettre à disposition de nouveaux utilisateurs si toute la chaîne indique que tout est OK.
|
||||
D'autres mécanismes fonctionnent également, mais au plus les actions nécessitent d'actions humaines, voire d'intervenants humains, au plus la probabilité qu'un problème survienne est grande.
|
||||
|
||||
Dans une version plus manuelle, cela pourrait se résumer à ces trois
|
||||
étapes (la dernière étant formellement facultative):
|
||||
Dans une version plus manuelle, cela pourrait se résumer à ces trois étapes (la dernière étant formellement facultative) :
|
||||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Démarrer un script,
|
||||
\item
|
||||
Prévoir un rollback si cela plante (et si cela a planté, préparer un
|
||||
post-mortem de l'incident pour qu'il ne se produise plus)
|
||||
Prévoir un rollback si cela plante (et si cela a planté, préparer un post-mortem de l'incident pour qu'il ne se produise plus)
|
||||
\item
|
||||
Se préparer une tisane en regardant nos flux RSS (pour peu que cette
|
||||
technologie existe encore\ldots\hspace{0pt}).
|
||||
Se préparer une tisane en regardant nos flux RSS (pour peu que cette technologie existe encore\ldots).
|
||||
\end{enumerate}
|
||||
|
||||
Sans aller jusqu'à demander de développer vos algorithmes sur douze pieds, la programmation reste un art régit par un ensemble de bonnes pratiques, par des règles à respecter et par la nécessité de travailler avec d'autres personnes qui ont souvent une expérience, des compétences ou une approche différente.
|
||||
|
|
|
|||
|
|
@ -3,12 +3,10 @@
|
|||
Dans cette partie, nous allons parler de plusieurs concepts fondamentaux au développement rapide d'une application utilisant Django.
|
||||
Nous parlerons de modélisation, de métamodèle, de migrations, d'administration auto-générée, de traductions et de cycle de vie des données.
|
||||
|
||||
Django est un framework Web qui propose une très bonne intégration des composants et une flexibilité bien pensée: chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes
|
||||
logiques et faciles à retenir, et en gérant ses dépendances de manière autonome.
|
||||
Django est un framework Web qui propose une très bonne intégration des composants et une flexibilité bien pensée: chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes logiques et faciles à retenir, et en gérant ses dépendances de manière autonome.
|
||||
Pour un néophyte, la courbe d'apprentissage sera relativement ardue: à côté de concepts clés de Django, il conviendra également d'assimiler correctement les structures de données du langage Python, le cycle de vie des requêtes HTTP et le B.A-BA des principes de sécurité.
|
||||
|
||||
En restant dans les sentiers battus, votre projet suivra un patron de conception dérivé du modèle \texttt{MVC} (Modèle-Vue-Controleur), où la variante concerne les termes utilisés: Django les nomme respectivement
|
||||
Modèle-Template-Vue et leur contexte d'utilisation.
|
||||
En restant dans les sentiers battus, votre projet suivra un patron de conception dérivé du modèle \texttt{MVC} (Modèle-Vue-Controleur), où la variante concerne les termes utilisés: Django les nomme respectivement Modèle-Template-Vue et leur contexte d'utilisation.
|
||||
Dans un \textbf{pattern} MVC classique, la traduction immédiate du \textbf{contrôleur} est une \textbf{vue}. Et comme nous le verrons par la suite, la \textbf{vue} est en fait le \textbf{template}.
|
||||
La principale différence avec un modèle MVC concerne le fait que la vue ne s'occupe pas du routage des URLs; ce point est réalisé par un autre composant, interne au framework, graĉe aux différentes routes définies
|
||||
dans les fichiers \texttt{urls.py}.
|
||||
|
|
@ -26,11 +24,9 @@ dans les fichiers \texttt{urls.py}.
|
|||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Le \textbf{modèle} (\texttt{models.py}) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table.
|
||||
\emph{Grosso modo}*, une table SQL correspondra à une classe d'un modèle Django.
|
||||
Le \textbf{modèle} (\texttt{models.py}) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. \emph{Grosso modo}*, une table SQL correspondra à une classe d'un modèle Django.
|
||||
\item
|
||||
La \textbf{vue} (\texttt{views.py}), qui joue le rôle de contrôleur: \emph{a priori}, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l'affichage d'une page.
|
||||
En d'autres mots, la vue sert de pont entre les données gérées par la base et l'interface utilisateur.
|
||||
La \textbf{vue} (\texttt{views.py}), qui joue le rôle de contrôleur: \emph{a priori}, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l'affichage d'une page. En d'autres mots, la vue sert de pont entre les données gérées par la base et l'interface utilisateur.
|
||||
\item
|
||||
Le \textbf{template}, qui s'occupe de la mise en forme: c'est le composant qui s'occupe de transformer les données en un affichage compréhensible (avec l'aide du navigateur) pour l'utilisateur.
|
||||
\end{itemize}
|
||||
|
|
|
|||
|
|
@ -6,16 +6,16 @@ Nous avons fait exprès de reprendre l'acronyme d'une \emph{Services Oriented Ar
|
|||
Dans cette partie, en page, la définition d'une interface REST, la définition d'une interface GraphQL et le routage d'URLs.
|
||||
|
||||
\begin{quote}
|
||||
|
||||
Don't make me think, or why I switched from JS SPAs to Ruby On Rails
|
||||
\url{https://news.ycombinator.com/item?id=30206989\&utm_term=comment}
|
||||
|
||||
\end{quote}
|
||||
|
||||
On a parcouru les templates et le mode "monolithique de DJango".
|
||||
Maintenant, on va aborder différentes options:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Le mode "intermédiaire", qui consiste à garder tous les mécanismes internes à Django, mais à ajouter une couche de dynamisme au travers d'une (légère) couche de JavaScript ou via HTMX.
|
||||
\item Le mode "warrior", qui consiste lui à ajouter une API, d'abord pour vos clients et utilisateurs, mais aussi pour votre propre consommation \footnote{Aussi intitulé "Eat your own dog's food"}
|
||||
\item
|
||||
Le mode "intermédiaire", qui consiste à garder tous les mécanismes internes à Django, mais à ajouter une couche de dynamisme au travers d'une (légère) couche de JavaScript ou via HTMX.
|
||||
\item
|
||||
Le mode "warrior", qui consiste lui à ajouter une API, d'abord pour vos clients et utilisateurs, mais aussi pour votre propre consommation \footnote{Aussi intitulé "Eat your own dog's food"}
|
||||
\end{enumerate}
|
||||
|
|
|
|||
Loading…
Reference in New Issue