relecture du fichier

.gitignore

@@ -8,3 +8,10 @@ build
 *.vscode/
 *.asciidoctor/
 *.aux
+*.idx
+*.lof
+*.lol
+*.lot
+*.out
+*.toc
+*.pyg*

chapters/administration.tex

@@ -1,18 +1,19 @@
 \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é. 
+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}, c'est-à-dire tout ce qu'il faut pour ajouter, lister, modifier ou supprimer des informations.
 
-Son problème est qu'elle présente une courbe d'apprentissage asymptotique. 
-Il est \textbf{très} facile d'arriver rapidement à un bon résultat, au travers d'un périmètre de configuration relativement restreint. 
+Son problème est qu'elle présente une courbe d'apprentissage asymptotique.
+Il est \textbf{très} facile d'arriver rapidement à un bon résultat, au travers d'un périmètre de configuration relativement restreint.
 Quoi que vous fassiez, il y a un moment où la courbe de paramétrage sera tellement ardue que vous aurez plus facile à développer ce que vous souhaitez ajouter en utilisant les autres concepts de Django.
 
-Cette fonctionnalité doit rester dans les mains d'administrateurs ou de gestionnaires, et dans leurs mains à eux uniquement: il n'est pas question de donner des droits aux utilisateurs finaux (même si c'est extrêment tentant durant les premiers tours de roues). 
+Cette fonctionnalité doit rester dans les mains d'administrateurs ou de gestionnaires, et dans leurs mains à eux uniquement : il n'est pas question de donner des droits aux utilisateurs finaux (même si c'est extrêment tentant durant les premiers tours de roues).
 Indépendamment de la manière dont vous allez l'utiliser et la configurer, vous finirez par devoir développer une "vraie" application, destinée aux utilisateurs classiques, et répondant à leurs besoins uniquement.
 
-Une bonne idée consiste à développer l'administration dans un premier temps, en \textbf{gardant en tête qu'il sera nécessaire de développer des concepts spécifiques}. 
+Une bonne idée consiste à développer l'administration dans un premier temps, en \textbf{gardant en tête qu'il sera nécessaire de développer des concepts spécifiques}.
 Dans cet objectif, l'administration est un outil exceptionel, qui permet de valider un modèle, de créer des objets rapidement et de valider les liens qui existent entre eux.
 
 C'est aussi un excellent outil de prototypage et de preuve de concept.
@@ -21,20 +22,17 @@ Elle se base sur plusieurs couches que l'on a déjà (ou on va bientôt)
 aborder (suivant le sens de lecture que vous préférez):
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\item
-  Le modèle de données
-\item
-  Les validateurs
-\item
-  Les formulaires
-\item
-  Les widgets
+    \def\labelenumi{\arabic{enumi}.}
+    \item Le modèle de données
+    \item Les validateurs
+    \item Les formulaires
+    \item Les widgets
 \end{enumerate}
 
 \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:
 
@@ -52,7 +50,7 @@ urlpatterns = [
 Cette URL signifie que la partie \texttt{admin} est déjà active et accessible à l'URL \texttt{\textless{}mon\_site\textgreater{}/admin}.
 C'est le seul prérequis pour cette partie.
 
-Chaque application nouvellement créée contient par défaut un fichier \texttt{admin.py}, dans lequel il est possible de déclarer quel ensemble de données sera accessible/éditable. 
+Chaque application nouvellement créée contient par défaut un fichier \texttt{admin.py}, dans lequel il est possible de déclarer quel ensemble de données sera accessible/éditable.
 Ainsi, si nous partons du modèle basique que nous avions détaillé plus tôt, avec des souhaits et des listes de souhaits:
 
 \begin{minted}{python}
@@ -85,123 +83,113 @@ admin.site.register(WishList)
 
 
 \begin{itemize}
-  \item
-    Nous importons les modèles que nous souhaitons gérer dans l'admin
-  \item
-    Et nous les déclarons comme gérables. Cette dernière ligne implique aussi qu'un modèle pourrait ne pas être disponible du tout, ce qui n'activera simplement aucune opération de lecture ou modification.
+    \item
+        Nous importons les modèles que nous souhaitons gérer dans l'admin
+    \item
+        Et nous les déclarons comme gérables. Cette dernière ligne implique aussi qu'un modèle pourrait ne pas être disponible du tout, ce qui n'activera simplement aucune opération de lecture ou modification.
 \end{itemize}
-  
-Il nous reste une seule étape à réaliser: créer un nouvel utilisateur. 
+
+Il nous reste une seule étape à réaliser: créer un nouvel utilisateur.
 Pour cet exemple, notre gestion va se limiter à une gestion manuelle; nous aurons donc besoin d'un \emph{super-utilisateur}, que nous pouvons créer grâce à la commande \texttt{python\ manage.py\ createsuperuser}.
 
 \begin{verbatim}
-  $ python manage.py createsuperuser
-  Username (leave blank to use 'fred'): fred
-  Email address: fred@root.org
-  Password: ******
-  Password (again): ******
-  Superuser created successfully.
+    $ python manage.py createsuperuser
+    Username (leave blank to use 'fred'): fred
+    Email address: fred@root.org
+    Password: ******
+    Password (again): ******
+    Superuser created successfully.
 \end{verbatim}
 
 
 \begin{figure}[H]
-  \centering
-  \includegraphics{images/django/django-site-admin.png}
-  \caption{Connexion au site d'administration}
+    \centering
+    \includegraphics{images/django/django-site-admin.png}
+    \caption{Connexion au site d'administration}
 \end{figure}
-  
+
 \begin{figure}[H]
-  \centering
-  \includegraphics{images/django/django-site-admin-after-connection.png}
-  \caption{Administration}
+    \centering
+    \includegraphics{images/django/django-site-admin-after-connection.png}
+    \caption{Administration}
 \end{figure}
-  
+
 \section{Quelques conseils de base}
 
 \begin{enumerate}
-  \item
-    Surchargez la méthode \texttt{str(self)} pour chaque classe que vous aurez définie dans le modèle. 
-    Cela permettra de construire une représentation textuelle pour chaque instance de votre classe. 
-    Cette information sera utilisée un peu partout dans le code, et donnera une meilleure idée de ce que l'on manipule. 
-    En plus, cette méthode est également appelée lorsque l'administration historisera une action (et     comme cette étape sera inaltérable, autant qu'elle soit fixée dans le début).
-  \item
-    La méthode \texttt{get\_absolute\_url(self)} retourne l'URL à laquelle on peut accéder pour obtenir les détails d'une instance. Par exemple:
+    \item
+        Surchargez la méthode \texttt{str(self)} pour chaque classe que vous aurez définie dans le modèle.
+        Cela permettra de construire une représentation textuelle pour chaque instance de votre classe.
+        Cette information sera utilisée un peu partout dans le code, et donnera une meilleure idée de ce que l'on manipule.
+        En plus, cette méthode est également appelée lorsque l'administration historisera une action (et     comme cette étape sera inaltérable, autant qu'elle soit fixée dans le début).
+    \item
+        La méthode \texttt{get\_absolute\_url(self)} retourne l'URL à laquelle on peut accéder pour obtenir les détails d'une instance. Par exemple:
 \end{enumerate}
-  
+
 \begin{minted}{python}
 def get_absolute_url(self):
   return reverse('myapp.views.details', args=[self.id])
 \end{minted}
-  
-  \begin{enumerate}
-  \def\labelenumi{\arabic{enumi}.}
-  \item
-    Les attributs \texttt{Meta}:
-  \end{enumerate}
-  
+
+\begin{enumerate}
+    \def\labelenumi{\arabic{enumi}.}
+    \item
+        Les attributs \texttt{Meta}:
+\end{enumerate}
+
 \begin{minted}{python}
 class Meta:
   ordering = ['-field1', 'field2']
   verbose_name = 'my class in singular'
   verbose_name_plural = 'my class when is in a list!'
 \end{minted}
-  
-\begin{enumerate}
 
-  \item
-    Le titre:
-  
+\begin{enumerate}
+    \item
+        Le titre:
+
     \begin{itemize}
-    \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}.
+        \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}.
     \end{itemize}
-  \item
+    \item
     Prefetch
 \end{enumerate}
-  
+
 \url{https://hackernoon.com/all-you-need-to-know-about-prefetching-in-django-f9068ebe1e60?gi=7da7b9d3ad64}
-  
+
 \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}
-\def\labelenumi{\arabic{enumi}.}
-\item
-  Créer de nouveaux éléments
-\item
-  Lister les éléments existants
-\item
-  Modifier des éléments existants
-\item
-  Supprimer un élément en particulier.
+    \def\labelenumi{\arabic{enumi}.}
+    \item
+        Créer de nouveaux éléments
+    \item
+        Lister les éléments existants
+    \item
+        Modifier des éléments existants
+    \item
+        Supprimer un élément en particulier.
 \end{enumerate}
 
 Les affichages sont donc de deux types: en liste et par élément.
 
 Pour les affichages en liste, le plus simple consiste à jouer sur la propriété \texttt{list\_display}.
 
-Par défaut, la première colonne va accueillir le lien vers le formulaire d'édition. 
+Par défaut, la première colonne va accueillir le lien vers le formulaire d'édition.
 On peut donc modifier ceci, voire créer de nouveaux liens vers d'autres éléments en construisant des URLs dynamiquement.
 
 Voir aussi comment personnaliser le fil d'Ariane ?
@@ -209,20 +197,20 @@ Voir aussi comment personnaliser le fil d'Ariane ?
 \section{Filtres}
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\item
-  list\_filter
-\item
-  filter\_horizontal
-\item
-  filter\_vertical
-\item
-  date\_hierarchy
+    \def\labelenumi{\arabic{enumi}.}
+    \item
+        list\_filter
+    \item
+        filter\_horizontal
+    \item
+        filter\_vertical
+    \item
+        date\_hierarchy
 \end{enumerate}
 
 \section{Permissions}
 
-On l'a dit plus haut, il vaut mieux éviter de proposer un accès à l'administration à vos utilisateurs. 
+On l'a dit plus haut, il vaut mieux éviter de proposer un accès à l'administration à vos utilisateurs.
 Il est cependant possible de configurer des permissions spécifiques pour certains groupes, en leur autorisant certaines actions de visualisation/ajout/édition ou suppression.
 
 Cela se joue au niveau du \texttt{ModelAdmin}, en implémentant les méthodes suivantes:
@@ -277,13 +265,13 @@ défaut, il existe déjà une action de \textbf{suppression}.
 Les paramètres d'entrée sont :
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\item
-  L'instance de classe
-\item
-  La requête entrante
-\item
-  Le queryset correspondant à la sélection.
+    \def\labelenumi{\arabic{enumi}.}
+    \item
+        L'instance de classe
+    \item
+        La requête entrante
+    \item
+        Le queryset correspondant à la sélection.
 \end{enumerate}
 
 \begin{minted}{python}
@@ -307,6 +295,6 @@ else:
 
 \section{Documentation}
 
-Nous l'avons dit plus haut, l'administration de Django a également la possibilité de rendre accessible la documentation associée à un modèle de données. 
+Nous l'avons dit plus haut, l'administration de Django a également la possibilité de rendre accessible la documentation associée à un modèle de données.
 Pour cela, il suffit de suivre les bonnes pratiques, puis \href{https://docs.djangoproject.com/en/stable/ref/contrib/admin/admindocs/}{d'activer la documentation à partir des URLs}:
 

chapters/api.tex

@@ -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
@@ -60,7 +58,7 @@ class Contract(models.Model):
     date_end = models.DateField(blank=True, null=True)
     contract_type = models.ForeignKey(ContractType, on_delete=models.CASCADE)
     service = models.ForeignKey(Service, on_delete=models.CASCADE)
-    
+
     def __str__(self):
         if self.date_end is not None:
             return "A partir du {}, jusqu'au {}, dans le service {} ({})".format(
@@ -88,35 +86,31 @@ La configuration des points de terminaison de notre API est relativement
 touffue. Il convient de:
 
 \begin{enumerate}
-\item
-  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,
-\item
-  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.
+    \item
+        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,
+    \item
+        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.
 \end{enumerate}
 
 \subsection{Serialiseurs}
 
 \begin{minted}{python}
     # serializers.py
-    
+
     from django.contrib.auth.models import User, Group
     from rest_framework import serializers
-    
+
     from .models import People, Contract, Service
 
     class PeopleSerializer(serializers.HyperlinkedModelSerializer):
         class Meta:
             model = People
             fields = ("last_name", "first_name", "contract_set")
-    
+
     class ContractSerializer(serializers.HyperlinkedModelSerializer):
         class Meta:
             model = Contract
@@ -139,20 +133,20 @@ touffue. Il convient de:
 
     from .models import People, Contract, Service
     from .serializers import PeopleSerializer, ContractSerializer, ServiceSerializer
-    
-    
+
+
     class PeopleViewSet(viewsets.ModelViewSet):
         queryset = People.objects.all()
         serializer_class = PeopleSerializer
         permission_class = [permissions.IsAuthenticated]
-    
-    
+
+
     class ContractViewSet(viewsets.ModelViewSet):
         queryset = Contract.objects.all()
         serializer_class = ContractSerializer
         permission_class = [permissions.IsAuthenticated]
-    
-    
+
+
     class ServiceViewSet(viewsets.ModelViewSet):
         queryset = Service.objects.all()
         serializer_class = ServiceSerializer
@@ -167,14 +161,14 @@ touffue. Il convient de:
     from django.contrib import admin
     from django.urls import path, include
     from rest_framework import routers
-    
+
     from core import views
-    
+
     router = routers.DefaultRouter()
     router.register(r"people", views.PeopleViewSet)
     router.register(r"contracts", views.ContractViewSet)
     router.register(r"services", views.ServiceViewSet)
-    
+
     urlpatterns = [
         path("api/v1/", include(router.urls)),
         path('admin/', admin.site.urls),
@@ -208,11 +202,11 @@ En nous rendant sur l'URL \texttt{http://localhost:8000/api/v1}, nous obtiendron
 \section{Modéles et relations}
 
 Plus haut, nous avons utilisé une relation de type \texttt{HyperlinkedModelSerializer}. C'est une bonne manière pour autoriser des relations entre vos instances à partir de l'API, mais il faut reconnaître que cela reste assez limité. Pour palier à ceci, il existe {[}plusieurs manières de représenter ces
-\url{https://www.django-rest-framework.org/api-guide/relations/}: 
+\url{https://www.django-rest-framework.org/api-guide/relations/}:
 
 \begin{enumerate}
-    \item Soit \textbf{via} un hyperlien, comme ci-dessus, 
-    \item Soit en utilisant les clés primaires, soit en utilisant l'URL canonique permettant d'accéder à la ressource. 
+    \item Soit \textbf{via} un hyperlien, comme ci-dessus,
+    \item Soit en utilisant les clés primaires, soit en utilisant l'URL canonique permettant d'accéder à la ressource.
 \end{enumerate}
 
 La solution la plus complète consiste à intégrer la relation directement au niveau des données sérialisées, ce qui nous permet de passer de ceci (au niveau des contrats):

chapters/authentication.tex

@@ -1,60 +1,56 @@
 \chapter{Authentification}
 
-Comme on l'a vu dans la partie sur le modèle, nous souhaitons que le créateur d'une liste puisse retrouver facilement les éléments qu'il aura créée. 
-Ce dont nous n'avons pas parlé cependant, c'est la manière dont l'utilisateur va pouvoir créer son compte et s'authentifier. 
+Comme on l'a vu dans la partie sur le modèle, nous souhaitons que le créateur d'une liste puisse retrouver facilement les éléments qu'il aura créée.
+Ce dont nous n'avons pas parlé cependant, c'est la manière dont l'utilisateur va pouvoir créer son compte et s'authentifier.
 La \href{https://docs.djangoproject.com/en/stable/topics/auth/}{documentation} est très complète, nous allons essayer de la simplifier au maximum.
 Accrochez-vous, le sujet peut être complexe.
 
 \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. 
-Pour y accéder, un paramètre par défaut est défini dans votre fichier de settings: \texttt{AUTH\_USER\_MODEL}.
+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, \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}.
+
 
 \section{Mécanisme d'authentification}
 
 On peut schématiser le flux d'authentification de la manière suivante :
-
 En gros:
 
 \begin{enumerate}
-\item
-  La personne accède à une URL qui est protégée (voir les décorateurs @login\_required et le mixin LoginRequiredMixin)
-\item
-  Le framework détecte qu'il est nécessaire pour la personne de se connecter (grâce à un paramètre type LOGIN\_URL)
-\item
-  Le framework présente une page de connexion ou un mécanisme d'accès pour la personne (template à définir)
-\item
-  Le framework récupère les informations du formulaire, et les transmets aux différents backends d'authentification, dans l'ordre
-\item
-  Chaque backend va appliquer la méthode \texttt{authenticate} en cascade, jusqu'à ce qu'un backend réponde True ou qu'aucun ne réponde
-\item
-  La réponse de la méthode authenticate doit être une instance d'un utilisateur, tel que définit parmi les paramètres généraux de l'application.
+    \item
+        La personne accède à une URL qui est protégée (voir les décorateurs @login\_required et le mixin LoginRequiredMixin)
+    \item
+        Le framework détecte qu'il est nécessaire pour la personne de se connecter (grâce à un paramètre type LOGIN\_URL)
+    \item
+        Le framework présente une page de connexion ou un mécanisme d'accès pour la personne (template à définir)
+    \item
+        Le framework récupère les informations du formulaire, et les transmets aux différents backends d'authentification, dans l'ordre
+    \item
+        Chaque backend va appliquer la méthode \texttt{authenticate} en cascade, jusqu'à ce qu'un backend réponde True ou qu'aucun ne réponde
+    \item
+        La réponse de la méthode authenticate doit être une instance d'un utilisateur, tel que définit parmi les paramètres généraux de l'application.
 \end{enumerate}
 
 En résumé (bis):
 
 \begin{enumerate}
-\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.
-\item
-  Si OK, on retourne une instance de type current\_user, qui pourra être
-  utilisée de manière uniforme dans l'application.
+    \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.
+    \item
+        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:
 
 \begin{enumerate}
-\item
-  Une authentification par jeton
-\item
-  Une authentification LDAP
+    \item
+        Une authentification par jeton
+    \item
+        Une authentification LDAP
 \end{enumerate}
 
 \begin{minted}{python}
@@ -77,14 +73,14 @@ class TokenBackend(backends.ModelBackend):
         current_token = Token.objects.filter(
             token=token, validity_date__gte=datetime.now()
         ).first()
-        
+
         if current_token:
             user = current_token.user
             current_token.last_used_date = datetime.now()
             current_token.save()
-    
+
         return user
-    
+
     return None
 \end{minted}
 
@@ -109,17 +105,17 @@ class LdapBackend(backends.ModelBackend):
     """
     ldap_server = Server(settings.LDAP_SERVER, get_info=ALL)
     ldap_connection = Connection(
-      ldap_server, 
-      user=username, 
+      ldap_server,
+      user=username,
       password=password
     )
-    
+
     try:
       if not ldap_connection.bind():
         raise ValueError("Login ou mot de passe incorrect")
     except (LDAPPasswordIsMandatoryError, ValueError) as ldap_exception:
       raise ldap_exception
-    
+
     user, _ = UserModel.objects.get_or_create(username=username)
 
     return user
@@ -129,43 +125,50 @@ class LdapBackend(backends.ModelBackend):
 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}.
-\item
-  Si vous souhaitez modifier la manière dont l'utilisateur se connecte, alors vous devrez modifier le \textbf{backend}.
+    \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}.
+    \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}
-\item
-  \texttt{first\_name}
-\item
-  \texttt{last\_name}
-\item
-  \texttt{email}
-\item
-  \texttt{password}
-\item
-  \texttt{date\_joined}.
+    \item
+        \texttt{username}
+    \item
+        \texttt{first\_name}
+    \item
+        \texttt{last\_name}
+    \item
+        \texttt{email}
+    \item
+        \texttt{password}
+    \item
+        \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'
@@ -175,43 +178,44 @@ 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{Social-auth}
+Voir ici : \href{https://github.com/omab/python-social-auth}{pythonsocial auth}
 
-Voir ici : \href{https://github.com/omab/python-social-auth}{python
-social auth}
 
 \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_}.
-On y trouve par exemple les paramètres suivants:
+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}
-\item
-  \texttt{LOGIN\_REDIRECT\_URL}: si vous ne spécifiez pas le paramètre
-  \texttt{next}, l'utilisateur sera automatiquement redirigé vers cette
-  page.
-\item
-  \texttt{LOGIN\_URL}: l'URL de connexion à utiliser. Par défaut,
-  l'utilisateur doit se rendre sur la page \texttt{/accounts/login}.
+    \item
+        \texttt{LOGIN\_REDIRECT\_URL}: si vous ne spécifiez pas le paramètre \texttt{next}, l'utilisateur sera automatiquement redirigé vers cette page.
+    \item
+        \texttt{LOGIN\_URL}: l'URL de connexion à utiliser.
+        Par défaut, l'utilisateur doit se rendre sur la page \texttt{/accounts/login}.
 \end{itemize}

chapters/contexts-processors.tex

@@ -1,10 +1,7 @@
 \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.
 
-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.
 
 \begin{minted}{python}
 # core/context_processors.py

chapters/deployments.tex

@@ -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,99 +16,90 @@ 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
-  groupadd --system webapps
-  groupadd --system gunicorn_sockets
-  useradd --system --gid webapps --shell /bin/bash --home /home/gwift gwift
-  mkdir -p /home/gwift
-  chown gwift:webapps /home/gwift
+    apt update
+    groupadd --system webapps
+    groupadd --system gunicorn_sockets
+    useradd --system --gid webapps --shell /bin/bash --home /home/gwift gwift
+    mkdir -p /home/gwift
+    chown gwift:webapps /home/gwift
 \end{verbatim}
 
 
 \begin{itemize}
-  \item
-    On ajoute un groupe intitulé \texttt{webapps}
-  \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}
-  \item
-    On crée le répertoire home/gwift
-  \item
-    On donne les droits sur le répertoire /home/gwift
+    \item
+        On ajoute un groupe intitulé \texttt{webapps}
+    \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}
+    \item
+        On crée le répertoire home/gwift
+    \item
+        On donne les droits sur le répertoire /home/gwift
 \end{itemize}
 
 \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 :
 
 \begin{verbatim}
-  yum install python36 -y
+    yum install python36 -y
 \end{verbatim}
 
 Ou passer par une installation alternative:
 
 \begin{verbatim}
-  sudo yum -y groupinstall "Development Tools"
-  sudo yum -y install openssl-devel bzip2-devel libffi-devel
-  wget https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tgz
-  cd Python-3.8*/
-  ./configure --enable-optimizations
-  sudo make altinstall
+    sudo yum -y groupinstall "Development Tools"
+    sudo yum -y install openssl-devel bzip2-devel libffi-devel
+    wget https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tgz
+    cd Python-3.8*/
+    ./configure --enable-optimizations
+    sudo make altinstall
 \end{verbatim}
 
 \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.
+    \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.
 \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)
-\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{]}
-\item
-  Oracle via
-  \href{https://oracle.github.io/python-cx_Oracle/}{cx\_Oracle}.
+    \item
+        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{]}
+    \item
+        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}
@@ -160,7 +152,7 @@ des notes là-dessus.
 
 La clé SSH doit ensuite être renseignée au niveau du dépôt, afin de pouvoir y accéder.
 A ce stade, on devrait déjà avoir quelque chose de fonctionnel en démarrant les commandes
-suivantes:
+suivantes :
 
 \begin{verbatim}
     # en tant qu'utilisateur 'gwift'
@@ -173,280 +165,275 @@ suivantes:
     =config.settings_production
 \end{verbatim}
 
+
 \section{Configuration de l'application}
 
 \begin{verbatim}
-  SECRET_KEY=<set your secret key here>
-  ALLOWED_HOSTS=*
-  STATIC_ROOT=/var/www/gwift/static
-  DATABASE=
+    SECRET_KEY=<set your secret key here>
+    ALLOWED_HOSTS=*
+    STATIC_ROOT=/var/www/gwift/static
+    DATABASE=
 \end{verbatim}
 
 \begin{itemize}
-  \item
-    La variable \texttt{SECRET\_KEY} est notamment utilisée pour le
-    chiffrement des sessions.
-  \item
-    On fait confiance à django\_environ pour traduire la chaîne de
-    connexion à la base de données.
-  \end{itemize}
-  
+    \item
+        La variable \texttt{SECRET\_KEY} est notamment utilisée pour le
+        chiffrement des sessions.
+    \item
+        On fait confiance à django\_environ pour traduire la chaîne de
+        connexion à la base de données.
+\end{itemize}
+
+
 \section{Création des répertoires de logs}
 
-
 \begin{verbatim}
-  mkdir -p /var/www/gwift/static
+    mkdir -p /var/www/gwift/static
 \end{verbatim}
 
-\section{Socket}  
 
+\section{Socket}
 Dans le fichier \texttt{/etc/tmpfiles.d/gwift.conf}:
-  
+
 \begin{verbatim}
-  D /var/run/webapps 0775 gwift gunicorn_sockets -
+    D /var/run/webapps 0775 gwift gunicorn_sockets -
 \end{verbatim}
-  
+
 Suivi de la création par systemd :
-  
 \begin{verbatim}
   systemd-tmpfiles --create
 \end{verbatim}
 
+
 \section{Gunicorn}
 
 \begin{verbatim}
-  #!/bin/bash
-  # defines settings for gunicorn
-  NAME="gwift"
-  DJANGODIR=/home/gwift/webapps/gwift
-  SOCKFILE=/var/run/webapps/gunicorn_gwift.sock
-  USER=gwift
-  GROUP=gunicorn_sockets
-  NUM_WORKERS=5
-  DJANGO_SETTINGS_MODULE=config.settings_production
-  DJANGO_WSGI_MODULE=config.wsgi
-  echo "Starting $NAME as `whoami`"
-  source /home/gwift/.venvs/gwift/bin/activate
-  cd $DJANGODIR
-  export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
-  export PYTHONPATH=$DJANGODIR:$PYTHONPATH
-  exec gunicorn ${DJANGO_WSGI_MODULE}:application \
-    --name $NAME \
-    --workers $NUM_WORKERS \
-    --user $USER \
-    --bind=unix:$SOCKFILE \
-    --log-level=debug \
-    --log-file=-
+    #!/bin/bash
+    # defines settings for gunicorn
+    NAME="gwift"
+    DJANGODIR=/home/gwift/webapps/gwift
+    SOCKFILE=/var/run/webapps/gunicorn_gwift.sock
+    USER=gwift
+    GROUP=gunicorn_sockets
+    NUM_WORKERS=5
+    DJANGO_SETTINGS_MODULE=config.settings_production
+    DJANGO_WSGI_MODULE=config.wsgi
+    echo "Starting $NAME as `whoami`"
+    source /home/gwift/.venvs/gwift/bin/activate
+    cd $DJANGODIR
+    export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
+    export PYTHONPATH=$DJANGODIR:$PYTHONPATH
+    exec gunicorn ${DJANGO_WSGI_MODULE}:application \
+        --name $NAME \
+        --workers $NUM_WORKERS \
+        --user $USER \
+        --bind=unix:$SOCKFILE \
+        --log-level=debug \
+        --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
+    yum install supervisor -y
 \end{verbatim}
 
 On crée ensuite le fichier \texttt{/etc/supervisord.d/gwift.ini}:
 
 \begin{verbatim}
-  [program:gwift]
-  command=/home/gwift/bin/start_gunicorn.sh
-  user=gwift
-  stdout_logfile=/var/log/gwift/gwift.log
-  autostart=true
-  autorestart=unexpected
-  redirect_stdout=true
-  redirect_stderr=true
+    [program:gwift]
+    command=/home/gwift/bin/start_gunicorn.sh
+    user=gwift
+    stdout_logfile=/var/log/gwift/gwift.log
+    autostart=true
+    autorestart=unexpected
+    redirect_stdout=true
+    redirect_stderr=true
 \end{verbatim}
 
 Et on crée les répertoires de logs, on démarre supervisord et on vérifie
-qu'il tourne correctement:
+qu'il tourne correctement :
 
 \begin{verbatim}
-  $ mkdir /var/log/gwift
-  $ chown gwift:nagios /var/log/gwift
-  $ systemctl enable supervisord
-  $ systemctl start supervisord.service
-  $ systemctl status supervisord.service
-  supervisord.service - Process Monitoring and Control Daemon
-  Loaded: loaded (/usr/lib/systemd/system/supervisord.service; enabled;
-  vendor preset: disabled)
-  Active: active (running) since Tue 2019-12-24 10:08:09 CET; 10s ago
-  Process: 2304 ExecStart=/usr/bin/supervisord -c /etc/supervisord.conf (code
-  =exited, status=0/SUCCESS)
-  Main PID: 2310 (supervisord)
-  CGroup: /system.slice/supervisord.service
-  - 2310 /usr/bin/python /usr/bin/supervisord -c
-  /etc/supervisord.conf
-  - 2313 /home/gwift/.venvs/gwift/bin/python3
-  /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
-  - 2317 /home/gwift/.venvs/gwift/bin/python3
-  /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
-  - 2318 /home/gwift/.venvs/gwift/bin/python3
-  /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
-  - 2321 /home/gwift/.venvs/gwift/bin/python3
-  /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
-  - 2322 /home/gwift/.venvs/gwift/bin/python3
-  /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
-  - 2323 /home/gwift/.venvs/gwift/bin/python3
-  /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
-  ls /var/run/webapps
+    $ mkdir /var/log/gwift
+    $ chown gwift:nagios /var/log/gwift
+    $ systemctl enable supervisord
+    $ systemctl start supervisord.service
+    $ systemctl status supervisord.service
+    supervisord.service - Process Monitoring and Control Daemon
+    Loaded: loaded (/usr/lib/systemd/system/supervisord.service; enabled;
+    vendor preset: disabled)
+    Active: active (running) since Tue 2019-12-24 10:08:09 CET; 10s ago
+    Process: 2304 ExecStart=/usr/bin/supervisord -c /etc/supervisord.conf (code
+    =exited, status=0/SUCCESS)
+    Main PID: 2310 (supervisord)
+    CGroup: /system.slice/supervisord.service
+    - 2310 /usr/bin/python /usr/bin/supervisord -c
+    /etc/supervisord.conf
+    - 2313 /home/gwift/.venvs/gwift/bin/python3
+    /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
+    - 2317 /home/gwift/.venvs/gwift/bin/python3
+    /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
+    - 2318 /home/gwift/.venvs/gwift/bin/python3
+    /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
+    - 2321 /home/gwift/.venvs/gwift/bin/python3
+    /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
+    - 2322 /home/gwift/.venvs/gwift/bin/python3
+    /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
+    - 2323 /home/gwift/.venvs/gwift/bin/python3
+    /home/gwift/.venvs/gwift/bin/gunicorn config.wsgi:...
+    ls /var/run/webapps
 \end{verbatim}
 
 
 On peut aussi vérifier que l'application est en train de tourner, à
-l'aide de la commande \texttt{supervisorctl}:
+l'aide de la commande \texttt{supervisorctl} :
 
 \begin{verbatim}
-  supervisorctl status gwift
-  gwift RUNNING pid 31983, uptime 0:01:00
-  supervisorctl stop gwift
-  gwift: stopped
-  root@ks3353535:/etc/supervisor/conf.d# supervisorctl start gwift
-  gwift: started
-  root@ks3353535:/etc/supervisor/conf.d# supervisorctl restart gwift
-  gwift: stopped
-  gwift: started
+    supervisorctl status gwift
+    gwift RUNNING pid 31983, uptime 0:01:00
+    supervisorctl stop gwift
+    gwift: stopped
+    root@ks3353535:/etc/supervisor/conf.d# supervisorctl start gwift
+    gwift: started
+    root@ks3353535:/etc/supervisor/conf.d# supervisorctl restart gwift
+    gwift: stopped
+    gwift: started
 \end{verbatim}
 
+
 \section{Firewall}
+\begin{verbatim}
+    et 443 (HTTPS).
+\end{verbatim}
 
 \begin{verbatim}
-  et 443 (HTTPS).
+    firewall-cmd --permanent --zone=public --add-service=http
+    firewall-cmd --permanent --zone=public --add-service=https
+    firewall-cmd --reload
 \end{verbatim}
-  
-\begin{verbatim}
-  firewall-cmd --permanent --zone=public --add-service=http 
-  firewall-cmd --permanent --zone=public --add-service=https 
-  firewall-cmd --reload
-\end{verbatim}
-  
+
 \begin{itemize}
-  \item
-    On ouvre le port 80, uniquement pour autoriser une connexion HTTP,
-    mais qui sera immédiatement redirigée vers HTTPS
-  \item
-    Et le port 443 (forcément).
+    \item
+        On ouvre le port 80, uniquement pour autoriser une connexion HTTP,
+        mais qui sera immédiatement redirigée vers HTTPS
+    \item
+        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
-  usermod -a -G gunicorn_sockets nginx
-  \end{verbatim}
-  
-  On configure ensuite le fichier \texttt{/etc/nginx/conf.d/gwift.conf}:
-  
-  \begin{verbatim}
-  upstream gwift_app {
-    server unix:/var/run/webapps/gunicorn_gwift.sock fail_timeout=0;
-  }
-  
-  server {
-    listen 80;
-    server_name <server_name>;
-    root /var/www/gwift;
-    error_log /var/log/nginx/gwift_error.log;
-    access_log /var/log/nginx/gwift_access.log;
-
-    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;
-      add_header Pragma public;
-      add_header Cache-Control "public";
-      add_header Vary "Accept-Encoding";
-      try_files $uri $uri/ =404;
+    upstream gwift_app {
+        server unix:/var/run/webapps/gunicorn_gwift.sock fail_timeout=0;
     }
 
-    location / {
-      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
-      proxy_set_header Host $http_host;
-      proxy_redirect off;
+    server {
+        listen 80;
+        server_name <server_name>;
+        root /var/www/gwift;
+        error_log /var/log/nginx/gwift_error.log;
+        access_log /var/log/nginx/gwift_access.log;
 
-      proxy_pass http://gwift_app;
+        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;
+        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;
+
+        proxy_pass http://gwift_app;
+        }
     }
-  }
-  \end{verbatim}
-  
-  \begin{itemize}
-  \item
-    Ce répertoire sera complété par la commande \texttt{collectstatic} que
-    l'on verra plus tard. L'objectif est que les fichiers ne demandant
-    aucune intelligence soit directement servis par Nginx. Cela évite
-    d'avoir un processus Python (relativement lent) qui doive être
-    instancié pour servir un simple fichier statique.
-  \item
-    Afin d'éviter que Django ne reçoive uniquement des requêtes provenant
-    de 127.0.0.1
-  \end{itemize}
+\end{verbatim}
+
+\begin{itemize}
+    \item
+        Ce répertoire sera complété par la commande \texttt{collectstatic} que l'on verra plus tard.
+        L'objectif est que les fichiers ne demandant aucune intelligence soit directement servis par Nginx.
+        Cela évite d'avoir un processus Python (relativement lent) qui doive être instancié pour servir un simple fichier statique.
+    \item
+        Afin d'éviter que Django ne reçoive uniquement des requêtes provenant de 127.0.0.1
+\end{itemize}
+
 
 \section{Mise à jour}
-
 \begin{verbatim}
-  u - <user>
-  source ~/.venvs/<app>/bin/activate
-  cd ~/webapps/<app>
-  git fetch
-  git checkout vX.Y.Z
-  pip install -U requirements/prod.txt
-  python manage.py migrate
-  python manage.py collectstatic
-  kill -HUP `ps -C gunicorn fch -o pid | head -n 1`
+    u - <user>
+    source ~/.venvs/<app>/bin/activate
+    cd ~/webapps/<app>
+    git fetch
+    git checkout vX.Y.Z
+    pip install -U requirements/prod.txt
+    python manage.py migrate
+    python manage.py collectstatic
+    kill -HUP `ps -C gunicorn fch -o pid | head -n 1`
 \end{verbatim}
 
 
 \begin{itemize}
-  \item
-    \url{https://stackoverflow.com/questions/26902930/how-do-i-restart-gunicorn-hup-i-dont-know-masterpid-or-location-of-pid-file}
+    \item
+        \url{https://stackoverflow.com/questions/26902930/how-do-i-restart-gunicorn-hup-i-dont-know-masterpid-or-location-of-pid-file}
 \end{itemize}
 
 \section{Logrotate}
 
 \begin{verbatim}
-  /var/log/gwift/* {
-    weekly
-    rotate 3
-    size 10M
-    compress
-    delaycompress
-  }
+    /var/log/gwift/* {
+        weekly
+        rotate 3
+        size 10M
+        compress
+        delaycompress
+    }
 \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.
 
 \begin{verbatim}
-mkdir -p /home/gwift/borg-backups/
-cd /home/gwift/borg-backups/
-borg init gwift.borg -e=none
-borg create gwift.borg::{now} ~/bin ~/webapps
+    mkdir -p /home/gwift/borg-backups/
+    cd /home/gwift/borg-backups/
+    borg init gwift.borg -e=none
+    borg create gwift.borg::{now} ~/bin ~/webapps
 \end{verbatim}
 
 Et dans le fichier crontab :
-
 \begin{verbatim}
-0 23 * * * /home/gwift/bin/backup.sh
+    0 23 * * * /home/gwift/bin/backup.sh
 \end{verbatim}
 
 \section{Ansible}
-
+(under construction)

chapters/docker-compose.tex

@@ -3,34 +3,26 @@
 
 (c/c Ced' - 2020-01-24)
 
-Ça y est, j'ai fait un test sur mon portable avec docker et cookiecutter
-pour django.
+Ça y est, j'ai fait un test sur mon portable avec docker et cookiecutter pour django.
 
-D'abords, après avoir installer docker-compose et les dépendances sous
-debian, tu dois t'ajouter dans le groupe docker, sinon il faut être root
-pour utiliser docker. Ensuite, j'ai relancé mon pc car juste relancé un
-shell n'a pas suffit pour que je puisse utiliser docker avec mon compte.
+D'abords, après avoir installer docker-compose et les dépendances sous debian, tu dois t'ajouter dans le groupe docker, sinon il faut être root pour utiliser docker.
+Ensuite, j'ai relancé mon pc car juste relancé un shell n'a pas suffit pour que je puisse utiliser docker avec mon compte.
 
-Bon après c'est facile, un petit virtualenv pour cookiecutter, suivit
-d'une installation du template django. Et puis j'ai suivi sans t
+Bon après c'est facile, un petit virtualenv pour cookiecutter, suivit d'une installation du template django.
+Et puis j'ai suivi sans t
 \url{https://cookiecutter-django.readthedocs.io/en/latest/developing-locally-docker.html}
 
-Alors, il télécharge les images, fait un petit update, installe les
-dépendances de dev, install les requirement pip \ldots\hspace{0pt}
+Alors, il télécharge les images, fait un petit update, installe les dépendances de dev, install les requirement pip \ldots\hspace{0pt}
 
 Du coup, ça prend vite de la place: image.png
 
-L'image de base python passe de 179 à 740 MB. Et là j'en ai pour presque
-1,5 GB d'un coup.
+L'image de base python passe de 179 à 740 MB.
+Et là j'en ai pour presque 1,5 GB d'un coup.
 
-Mais par contre, j'ai un python 3.7 direct et postgres 10 sans rien
-faire ou presque.
+Mais par contre, j'ai un python 3.7 direct et postgres 10 sans rien faire ou presque.
 
-La partie ci-dessous a été reprise telle quelle de
-\href{https://cookiecutter-django.readthedocs.io/en/latest/deployment-with-docker.html}{la
-documentation de cookie-cutter-django}.
+La partie ci-dessous a été reprise telle quelle de \href{https://cookiecutter-django.readthedocs.io/en/latest/deployment-with-docker.html}{la documentation de cookie-cutter-django}.
 
-le serveur de déploiement ne doit avoir qu'un accès en lecture au dépôt
-source.
+le serveur de déploiement ne doit avoir qu'un accès en lecture au dépôt source.
 
 On peut aussi passer par fabric, ansible, chef ou puppet.

chapters/filters.tex

@@ -1,51 +1,33 @@
 \chapter{Filtres}
 
+A ce stade, nous pouvons juste récupérer des informations présentes dans notre base de données, mais à part les parcourir, il est difficile d'en faire quelque chose.
 
-
-A ce stade, nous pouvons juste récupérer des informations présentes dans
-notre base de données, mais à part les parcourir, il est difficile d'en
-faire quelque chose.
-
-Il est possible de jouer avec les URLs en définissant une nouvelle route
-ou avec les paramètres de l'URL, ce qui demanderait alors de programmer
-chaque cas possible - sans que le consommateur ne puisse les déduire
-lui-même. Une solution élégante consiste à autoriser le consommateur à
-filtrer les données, directement au niveau de l'API. Ceci peut être
-fait. Il existe deux manières de restreindre l'ensemble des résultats
-retournés:
+Il est possible de jouer avec les URLs en définissant une nouvelle route ou avec les paramètres de l'URL, ce qui demanderait alors de programmer chaque cas possible - sans que le consommateur ne puisse les déduire
+lui-même.
+Une solution élégante consiste à autoriser le consommateur à filtrer les données, directement au niveau de l'API.
+Ceci peut être fait.
+Il existe deux manières de restreindre l'ensemble des résultats retournés:
 
 \begin{enumerate}
-\item
-  Soit au travers d'une recherche, qui permet d'effectuer une recherche
-  textuelle, globale et par ensemble à un ensemble de champs,
-\item
-  Soit au travers d'un filtre, ce qui permet de spécifier une valeur
-  précise à rechercher.
+    \item
+        Soit au travers d'une recherche, qui permet d'effectuer une recherche textuelle, globale et par ensemble à un ensemble de champs,
+    \item
+        Soit au travers d'un filtre, ce qui permet de spécifier une valeur précise à rechercher.
 \end{enumerate}
 
-Dans notre exemple, la première possibilité sera utile pour rechercher
-une personne répondant à un ensemble de critères. Typiquement,
-\texttt{/api/v1/people/?search=raymond\ bond} ne nous donnera aucun
-résultat, alors que \texttt{/api/v1/people/?search=james\ bond} nous
-donnera le célèbre agent secret (qui a bien entendu un contrat chez
-nous\ldots\hspace{0pt}).
+Dans notre exemple, la première possibilité sera utile pour rechercher une personne répondant à un ensemble de critères.
+Typiquement, \texttt{/api/v1/people/?search=raymond\ bond} ne nous donnera aucun résultat, alors que \texttt{/api/v1/people/?search=james\ bond} nous donnera le célèbre agent secret (qui a bien entendu un contrat chez nous\ldots\hspace{0pt}).
 
-Le second cas permettra par contre de préciser que nous souhaitons
-disposer de toutes les personnes dont le contrat est ultérieur à une
-date particulière.
+Le second cas permettra par contre de préciser que nous souhaitons disposer de toutes les personnes dont le contrat est ultérieur à une date particulière.
 
-Utiliser ces deux mécanismes permet, pour Django-Rest-Framework, de
-proposer immédiatement les champs, et donc d'informer le consommateur
-des possibilités:
+Utiliser ces deux mécanismes permet, pour Django-Rest-Framework, de proposer immédiatement les champs, et donc d'informer le consommateur des possibilités :
 
 \includegraphics{images/rest/drf-filters-and-searches.png}
 
-\section{Recherches}
 
-La fonction de recherche est déjà implémentée au niveau de
-Django-Rest-Framework, et aucune dépendance supplémentaire n'est
-nécessaire. Au niveau du \texttt{viewset}, il suffit d'ajouter deux
-informations:
+\section{Recherches}
+La fonction de recherche est déjà implémentée au niveau de Django-Rest-Framework, et aucune dépendance supplémentaire n'est nécessaire.
+Au niveau du \texttt{viewset}, il suffit d'ajouter deux informations:
 
 \begin{minted}{python}
 ...
@@ -81,20 +63,18 @@ et nous l'ajoutons parmi les applications installées:
     Successfully installed django-filter-2.4.0
 \end{verbatim}
 
-Une fois l'installation réalisée, il reste deux choses à faire:
+Une fois l'installation réalisée, il reste deux choses à faire :
 
 \begin{enumerate}
     \def\labelenumi{\arabic{enumi}.}
     \item
-      Ajouter \texttt{django\_filters} parmi les applications installées:
+        Ajouter \texttt{django\_filters} parmi les applications installées :
     \item
-      Configurer la clé \texttt{DEFAULT\_FILTER\_BACKENDS} à la valeur
-      \texttt{{[}\textquotesingle{}django\_filters.rest\_framework.DjangoFilterBackend\textquotesingle{}{]}}.
-    \end{enumerate}
-    
-Vous avez suivi les étapes ci-dessus, il suffit d'adapter le fichier
-\texttt{settings.py} de la manière suivante:
-    
+        Configurer la clé \texttt{DEFAULT\_FILTER\_BACKENDS} à la valeur \texttt{{[}\textquotesingle{}django\_filters.rest\_framework.DjangoFilterBackend\textquotesingle{}{]}}.
+\end{enumerate}
+
+Vous avez suivi les étapes ci-dessus, il suffit d'adapter le fichier \texttt{settings.py} de la manière suivante :
+
 \begin{minted}{python}
 REST_FRAMEWORK = {
     'DEFAULT_PAGINATION_CLASS':
@@ -125,28 +105,19 @@ class PeopleViewSet(viewsets.ModelViewSet):
 A ce stade, nous avons deux problèmes:
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\item
-  Le champ que nous avons défini au niveau de la propriété
-  \texttt{filterset\_fields} exige une correspondance exacte. Ainsi,
-  \texttt{/api/v1/people/?last\_name=Bon} ne retourne rien, alors que
-  \texttt{/api/v1/people/?last\_name=Bond} nous donnera notre agent
-  secret préféré.
-\item
-  Il n'est pas possible d'aller appliquer un critère de sélection sur la
-  propriété d'une relation. Notre exemple proposant rechercher
-  uniquement les relations dans le futur (ou dans le passé) tombe à
-  l'eau.
+    \def\labelenumi{\arabic{enumi}.}
+    \item
+        Le champ que nous avons défini au niveau de la propriété \texttt{filterset\_fields} exige une correspondance exacte.
+        Ainsi, \texttt{/api/v1/people/?last\_name=Bon} ne retourne rien, alors que \texttt{/api/v1/people/?last\_name=Bond} nous donnera notre agent
+        secret préféré.
+    \item
+        Il n'est pas possible d'aller appliquer un critère de sélection sur la propriété d'une relation.
+        Notre exemple proposant rechercher uniquement les relations dans le futur (ou dans le passé) tombe à l'eau.
 \end{enumerate}
 
-Pour ces deux points, nous allons définir un nouveau filtre, en
-surchargeant une nouvelle classe dont la classe mère serait de type
-\texttt{django\_filters.FilterSet}.
+Pour ces deux points, nous allons définir un nouveau filtre, en surchargeant une nouvelle classe dont la classe mère serait de type \texttt{django\_filters.FilterSet}.
 
 TO BE CONTINUED.
 
-A noter qu'il existe un paquet
-{[}Django-Rest-Framework-filters{]}(\url{https://github.com/philipn/django-rest-framework-filters}),
-mais il est déprécié depuis Django 3.0, puisqu'il se base sur
-\texttt{django.utils.six} qui n'existe à présent plus. Il faut donc le
-faire à la main (ou patcher le paquet\ldots\hspace{0pt}).
+A noter qu'il existe un paquet {[}Django-Rest-Framework-filters{]}(\url{https://github.com/philipn/django-rest-framework-filters}), mais il est déprécié depuis Django 3.0, puisqu'il se base sur \texttt{django.utils.six} qui n'existe à présent plus.
+Il faut donc le faire à la main (ou patcher le paquet\ldots\hspace{0pt}).

chapters/forms.tex

@@ -2,44 +2,38 @@
 
 \includegraphics{images/xkcd-327.png}
 
-
 \begin{quote}
-    Le form, il s'assure que l'utilisateur n'a pas encodé de conneries et
-    que l'ensemble reste cohérent. Il (le form) n'a pas à savoir que tu as
-    implémenté des closure tables dans un graph dirigé acyclique.
+    Le form, il s'assure que l'utilisateur n'a pas encodé de conneries et que l'ensemble reste cohérent.
+    Il (le form) n'a pas à savoir que tu as implémenté des closure tables dans un graph dirigé acyclique.
 \end{quote}
-    
+
 Ou comment valider proprement des données entrantes.
 
-Quand on parle de \texttt{forms}, on ne parle pas uniquement de formulaires Web. 
-On pourrait considérer qu'il s'agit de leur objectif principal, mais on peut également voir un peu plus loin: on peut en fait voir les \texttt{forms} comme le point d'entrée pour chaque donnée arrivant dans notre application: il s'agit en quelque sorte d'un ensemble de règles complémentaires à celles déjà présentes au niveau du modèle.
+Quand on parle de \texttt{forms}, on ne parle pas uniquement de formulaires Web.
+% TODO: tu as une explication (:) dans une explication (:). Je trouve pas ca très français.
+On pourrait considérer qu'il s'agit de leur objectif principal, mais on peut également voir un peu plus loin : on peut en fait voir les \texttt{forms} comme le point d'entrée pour chaque donnée arrivant dans notre application : il s'agit en quelque sorte d'un ensemble de règles complémentaires à celles déjà présentes au niveau du modèle.
 
-L'exemple le plus simple est un fichier \texttt{.csv}: la lecture de ce fichier pourrait se faire de manière très simple, en récupérant les valeurs de chaque colonne et en l'introduisant dans une instance du modèle.
+L'exemple le plus simple est un fichier \texttt{.csv} : la lecture de ce fichier pourrait se faire de manière très simple, en récupérant les valeurs de chaque colonne et en l'introduisant dans une instance du modèle.
 
-Mauvaise idée. On peut proposer trois versions d'un même code, de la version simple (lecture du fichier csv et jonglage avec les indices de colonnes), puis une version plus sophistiquée (et plus lisible, à base
-de \href{https://docs.python.org/3/library/csv.html\#csv.DictReader}{DictReader}), et la version + à base de form.
+Mauvaise idée.
+On peut proposer trois versions d'un même code, de la version simple (lecture du fichier csv et jonglage avec les indices de colonnes), puis une version plus sophistiquée (et plus lisible, à base de \href{https://docs.python.org/3/library/csv.html\#csv.DictReader}{DictReader}), et la version + à base de form.
 
-Les données fournies par un utilisateur \textbf{doivent} \textbf{toujours} être validées avant introduction dans la base de données. 
+Les données fournies par un utilisateur \textbf{doivent} \textbf{toujours} être validées avant introduction dans la base de données.
 Notre base de données étant accessible ici par l'ORM, la solution consiste à introduire une couche supplémentaire de validation.
 
 Le flux à suivre est le suivant:
 
 \begin{enumerate}
-\item
-  Création d'une instance grâce à un dictionnaire
-\item
-  Validation des données et des informations reçues
-\item
-  Traitement, si la validation a réussi.
+    \item Création d'une instance grâce à un dictionnaire
+    \item Validation des données et des informations reçues
+    \item Traitement, si la validation a réussi.
 \end{enumerate}
 
 Ils jouent également deux rôles importants:
 
 \begin{enumerate}
-\item
-  Valider des données, en plus de celles déjà définies au niveau du modèle
-\item
-  Contrôler le rendu à appliquer aux champs.
+    \item Valider des données, en plus de celles déjà définies au niveau du modèle
+    \item Contrôler le rendu à appliquer aux champs.
 \end{enumerate}
 
 Ils agissent come une glue entre l'utilisateur et la modélisation de vos structures de données.
@@ -53,7 +47,7 @@ A compléter ;-)
 
 \section{Dépendance avec le modèle}
 
-Un \textbf{form} peut dépendre d'une autre classe Django. 
+Un \textbf{form} peut dépendre d'une autre classe Django.
 Pour cela, il suffit de fixer l'attribut \texttt{model} au niveau de la \texttt{class\ Meta} dans la définition.
 
 \begin{minted}{python}
@@ -68,16 +62,15 @@ class WishlistCreateForm(forms.ModelForm):
         fields = ('name', 'description')
 \end{minted}
 
-De cette manière, notre form dépendra automatiquement des champs déjà déclarés dans la classe \texttt{Wishlist}. 
-Cela suit le principe de \texttt{DRY\ \textless{}don’t\ repeat\ yourself\textgreater{}\textasciigrave{}\_,\ et\ évite\ qu’une\ modification\ ne\ pourrisse\ le\ code:\ en\ testant\ les\ deux\ champs\ présent\ dans\ l’attribut\ \textasciigrave{}fields},
-nous pourrons nous assurer de faire évoluer le formulaire en fonction du
-modèle sur lequel il se base.
+% TODO: je comprends pas pourquoi il y a autant de \ dans le paragraphe.
+De cette manière, notre form dépendra automatiquement des champs déjà déclarés dans la classe \texttt{Wishlist}.
+Cela suit le principe de \texttt{DRY\ \textless{}don’t\ repeat\ yourself\textgreater{}\textasciigrave{}\_,\ et\ évite\ qu’une\ modification\ ne\ pourrisse\ le\ code :\ en\ testant\ les\ deux\ champs\ présent\ dans\ l’attribut\ \textasciigrave{}fields}, nous pourrons nous assurer de faire évoluer le formulaire en fonction du modèle sur lequel il se base.
 
 \section{Rendu et affichage}
 
-Le formulaire permet également de contrôler le rendu qui sera appliqué lors de la génération de la page. 
+Le formulaire permet également de contrôler le rendu qui sera appliqué lors de la génération de la page.
 Si les champs dépendent du modèle sur lequel se base le formulaire, ces widgets doivent être initialisés dans
-l'attribut \texttt{Meta}. 
+l'attribut \texttt{Meta}.
 Sinon, ils peuvent l'être directement au niveau du champ.
 
 \subsection{Squelette par défaut}
@@ -86,36 +79,27 @@ On a d'un côté le \{\{ form.as\_p \}\} ou \{\{ form.as\_table \}\}, mais il y
 
 \subsection{Crispy-forms}
 
-Comme on l'a vu à l'instant, les forms, en Django, c'est le bien. Cela
-permet de valider des données reçues en entrée et d'afficher (très)
-facilement des formulaires à compléter par l'utilisateur.
+Comme on l'a vu à l'instant, les forms, en Django, c'est le bien.
+Cela permet de valider des données reçues en entrée et d'afficher (très) facilement des formulaires à compléter par l'utilisateur.
 
-Par contre, c'est lourd. Dès qu'on souhaite peaufiner un peu
-l'affichage, contrôler parfaitement ce que l'utilisateur doit remplir,
-modifier les types de contrôleurs, les placer au pixel près,
-\ldots\hspace{0pt} Tout ça demande énormément de temps. Et c'est là
-qu'intervient
-\href{http://django-crispy-forms.readthedocs.io/en/latest/}{Django-Crispy-Forms}.
-Cette librairie intègre plusieurs frameworks CSS (Bootstrap, Foundation
-et uni-form) et permet de contrôler entièrement le \textbf{layout} et la
-présentation.
+Par contre, c'est lourd.
+Dès qu'on souhaite peaufiner un peu l'affichage, contrôler parfaitement ce que l'utilisateur doit remplir, modifier les types de contrôleurs, les placer au pixel près, \ldots\hspace{0pt} Tout ça demande énormément de temps.
+Et c'est là qu'intervient \href{http://django-crispy-forms.readthedocs.io/en/latest/}{Django-Crispy-Forms}.
+Cette librairie intègre plusieurs frameworks CSS (Bootstrap, Foundation et uni-form) et permet de contrôler entièrement le \textbf{layout} et la présentation.
 
 (c/c depuis le lien ci-dessous)
 
 Pour chaque champ, crispy-forms va :
 
 \begin{itemize}
-\item
-  utiliser le \texttt{verbose\_name} comme label.
-\item
-  vérifier les paramètres \texttt{blank} et \texttt{null} pour savoir si
-  le champ est obligatoire.
-\item
-  utiliser le type de champ pour définir le type de la balise
-  \texttt{\textless{}input\textgreater{}}.
-\item
-  récupérer les valeurs du paramètre \texttt{choices} (si présent) pour
-  la balise \texttt{\textless{}select\textgreater{}}.
+    \item
+        utiliser le \texttt{verbose\_name} comme label.
+    \item
+        vérifier les paramètres \texttt{blank} et \texttt{null} pour savoir si le champ est obligatoire.
+    \item
+        utiliser le type de champ pour définir le type de la balise \texttt{\textless{}input\textgreater{}}.
+    \item
+        récupérer les valeurs du paramètre \texttt{choices} (si présent) pour la balise \texttt{\textless{}select\textgreater{}}.
 \end{itemize}
 
 \url{http://dotmobo.github.io/django-crispy-forms.html}

chapters/gwift.tex

@@ -6,548 +6,397 @@
     \caption{Gwift}
 \end{figure}
 
-Pour prendre un exemple concret, nous allons créer un site permettant de
-gérer des listes de souhaits, que nous appellerons \texttt{gwift} (pour
-\texttt{GiFTs\ and\ WIshlisTs} :)).
+Pour prendre un exemple concret, nous allons créer un site permettant de gérer des listes de souhaits, que nous appellerons \texttt{gwift} (pour \texttt{GiFTs\ and\ WIshlisTs} :)).
 
-La première chose à faire est de définir nos besoins du point de vue de
-l'utilisateur, c'est-à-dire ce que nous souhaitons qu'un utilisateur
-puisse faire avec l'application.
+La première chose à faire est de définir nos besoins du point de vue de l'utilisateur, c'est-à-dire ce que nous souhaitons qu'un utilisateur puisse faire avec l'application.
+
+Ensuite, nous pourrons traduire ces besoins en fonctionnalités et finalement effectuer le développement.
 
-Ensuite, nous pourrons traduire ces besoins en fonctionnalités et
-finalement effectuer le développement.
 
 \section{Besoins utilisateurs}
-
-
-Nous souhaitons développer un site où un utilisateur donné peut créer
-une liste contenant des souhaits et où d'autres utilisateurs,
-authentifiés ou non, peuvent choisir les souhaits à la réalisation
-desquels ils souhaitent participer.
+Nous souhaitons développer un site où un utilisateur donné peut créer une liste contenant des souhaits et où d'autres utilisateurs, authentifiés ou non, peuvent choisir les souhaits à la réalisation desquels ils souhaitent participer.
 
 Il sera nécessaire de s'authentifier pour :
-
 \begin{itemize}
-\item
-  Créer une liste associée à l'utilisateur en cours
-\item
-  Ajouter un nouvel élément à une liste
+    \item Créer une liste associée à l'utilisateur en cours
+    \item Ajouter un nouvel élément à une liste
 \end{itemize}
 
 Il ne sera pas nécessaire de s'authentifier pour :
-
 \begin{itemize}
-\item
-  Faire une promesse d'offre pour un élément appartenant à une liste,
-  associée à un utilisateur.
+    \item
+        Faire une promesse d'offre pour un élément appartenant à une liste, associée à un utilisateur.
 \end{itemize}
 
-L'utilisateur ayant créé une liste pourra envoyer un email directement
-depuis le site aux personnes avec qui il souhaite partager sa liste, cet
-email contenant un lien permettant d'accéder à cette liste.
+L'utilisateur ayant créé une liste pourra envoyer un email directement depuis le site aux personnes avec qui il souhaite partager sa liste, cet email contenant un lien permettant d'accéder à cette liste.
 
 A chaque souhait, on pourrait de manière facultative ajouter un prix.
-Dans ce cas, le souhait pourrait aussi être subdivisé en plusieurs
-parties, de manière à ce que plusieurs personnes puissent participer à
-sa réalisation.
+Dans ce cas, le souhait pourrait aussi être subdivisé en plusieurs parties, de manière à ce que plusieurs personnes puissent participer à sa réalisation.
+
+Un souhait pourrait aussi être réalisé plusieurs fois.
+Ceci revient à dupliquer le souhait en question.
 
-Un souhait pourrait aussi être réalisé plusieurs fois. Ceci revient à
-dupliquer le souhait en question.
 
 \section{Besoins fonctionnels}
 
 \subsection{Gestion des utilisateurs}
+Pour gérer les utilisateurs, nous allons faire en sorte de surcharger ce que Django propose: par défaut, on a une la possibilité de gérer des utilisateurs (identifiés par une adresse email, un nom, un prénom, \ldots\hspace{0pt}) mais sans plus.
 
-Pour gérer les utilisateurs, nous allons faire en sorte de surcharger ce
-que Django propose: par défaut, on a une la possibilité de gérer des
-utilisateurs (identifiés par une adresse email, un nom, un prénom,
-\ldots\hspace{0pt}) mais sans plus.
+Ce qu'on peut souhaiter, c'est que l'utilisateur puisse s'authentifier grâce à une plateforme connue (Facebook, Twitter, Google, etc.), et qu'il puisse un minimum gérer son profil.
 
-Ce qu'on peut souhaiter, c'est que l'utilisateur puisse s'authentifier
-grâce à une plateforme connue (Facebook, Twitter, Google, etc.), et
-qu'il puisse un minimum gérer son profil.
 
 \subsection{Gestion des listes}
 
 \subsubsection{Modélisation}
-
-
-Les données suivantes doivent être associées à une liste:
-
+Les données suivantes doivent être associées à une liste :
 \begin{itemize}
-\item
-  un identifiant
-\item
-  un identifiant externe (un GUID, par exemple)
-\item
-  un nom
-\item
-  une description
-\item
-  le propriétaire, associé à l'utilisateur qui l'aura créée
-\item
-  une date de création
-\item
-  une date de modification
+    \item un identifiant
+    \item un identifiant externe (un GUID, par exemple)
+    \item un nom
+    \item une description
+    \item le propriétaire, associé à l'utilisateur qui l'aura créée
+    \item une date de création
+    \item une date de modification
 \end{itemize}
 
+
 \subsubsection{Fonctionnalités}
-
-
 \begin{itemize}
     \item
-      Un utilisateur authentifié doit pouvoir créer, modifier, désactiver et
-      supprimer une liste dont il est le propriétaire
+        Un utilisateur authentifié doit pouvoir créer, modifier, désactiver et supprimer une liste dont il est le propriétaire
     \item
-      Un utilisateur doit pouvoir associer ou retirer des souhaits à une
-      liste dont il est le propriétaire
+        Un utilisateur doit pouvoir associer ou retirer des souhaits à une liste dont il est le propriétaire
     \item
-      Il faut pouvoir accéder à une liste, avec un utilisateur authentifier
-      ou non, \textbf{via} son identifiant externe
+        Il faut pouvoir accéder à une liste, avec un utilisateur authentifier ou non, \textbf{via} son identifiant externe
     \item
-      Il faut pouvoir envoyer un email avec le lien vers la liste, contenant
-      son identifiant externe
+        Il faut pouvoir envoyer un email avec le lien vers la liste, contenant son identifiant externe
     \item
-      L'utilisateur doit pouvoir voir toutes les listes qui lui
-      appartiennent
+        L'utilisateur doit pouvoir voir toutes les listes qui lui appartiennent
 \end{itemize}
 
+
 \subsection{Gestion des souhaits}
 
 \subsubsection{Modélisation}
 
-
-Les données suivantes peuvent être associées à un souhait:
+Les données suivantes peuvent être associées à un souhait :
 
 \begin{itemize}
-\item
-  un identifiant
-\item
-  identifiant de la liste
-\item
-  un nom
-\item
-  une description
-\item
-  le propriétaire
-\item
-  une date de création
-\item
-  une date de modification
-\item
-  une image, afin de représenter l'objet ou l'idée
-\item
-  un nombre (1 par défaut)
-\item
-  un prix facultatif
-\item
-  un nombre de part, facultatif également, si un prix est fourni.
+    \item un identifiant
+    \item identifiant de la liste
+    \item un nom
+    \item une description
+    \item le propriétaire
+    \item une date de création
+    \item une date de modification
+    \item une image, afin de représenter l'objet ou l'idée
+    \item un nombre (1 par défaut)
+    \item un prix facultatif
+    \item un nombre de part, facultatif également, si un prix est fourni.
 \end{itemize}
 
+
 \subsubsection{Fonctionnalités}
-
-
 \begin{itemize}
     \item
-      Un utilisateur authentifié doit pouvoir créer, modifier, désactiver et
-      supprimer un souhait dont il est le propriétaire.
+        Un utilisateur authentifié doit pouvoir créer, modifier, désactiver et supprimer un souhait dont il est le propriétaire.
     \item
-      On ne peut créer un souhait sans liste associée
+        On ne peut créer un souhait sans liste associée
     \item
-      Il faut pouvoir fractionner un souhait uniquement si un prix est
-      donné.
+        Il faut pouvoir fractionner un souhait uniquement si un prix est donné.
     \item
-      Il faut pouvoir accéder à un souhait, avec un utilisateur authentifié
-      ou non.
+        Il faut pouvoir accéder à un souhait, avec un utilisateur authentifié ou non.
     \item
-      Il faut pouvoir réaliser un souhait ou une partie seulement, avec un
-      utilisateur authentifié ou non.
+        Il faut pouvoir réaliser un souhait ou une partie seulement, avec un utilisateur authentifié ou non.
     \item
-      Un souhait en cours de réalisation et composé de différentes parts ne
-      peut plus être modifié.
+        Un souhait en cours de réalisation et composé de différentes parts ne peut plus être modifié.
     \item
-      Un souhait en cours de réalisation ou réalisé ne peut plus être
-      supprimé.
+        Un souhait en cours de réalisation ou réalisé ne peut plus être supprimé.
     \item
-      On peut modifier le nombre de fois qu'un souhait doit être réalisé
-      dans la limite des réalisations déjà effectuées.
+        On peut modifier le nombre de fois qu'un souhait doit être réalisé dans la limite des réalisations déjà effectuées.
 \end{itemize}
 
+
 \subsection{Réalisation d'un souhait}
 
 \subsubsection{Modélisation}
-
-
-Les données suivantes peuvent être associées à une réalisation de
-souhait:
+Les données suivantes peuvent être associées à une réalisation de souhait :
 
 \begin{itemize}
-\item
-  identifiant du souhait
-\item
-  identifiant de l'utilisateur si connu
-\item
-  identifiant de la personne si utilisateur non connu
-\item
-  un commentaire
-\item
-  une date de réalisation
+    \item identifiant du souhait
+    \item identifiant de l'utilisateur si connu
+    \item identifiant de la personne si utilisateur non connu
+    \item un commentaire
+    \item une date de réalisation
 \end{itemize}
 
+
 \subsubsection{Fonctionnalités}
-
-
 \begin{itemize}
     \item
-      L'utilisateur doit pouvoir voir si un souhait est réalisé, en partie
-      ou non. Il doit également avoir un pourcentage de complétion sur la
-      possibilité de réalisation de son souhait, entre 0\% et 100\%.
+        L'utilisateur doit pouvoir voir si un souhait est réalisé, en partie ou non.
+        Il doit également avoir un pourcentage de complétion sur la possibilité de réalisation de son souhait, entre 0\% et 100\%.
     \item
-      L'utilisateur doit pouvoir voir la ou les personnes ayant réalisé un
-      souhait.
+        L'utilisateur doit pouvoir voir la ou les personnes ayant réalisé un souhait.
     \item
-      Il y a autant de réalisation que de parts de souhait réalisées ou de
-      nombre de fois que le souhait est réalisé.
+        Il y a autant de réalisation que de parts de souhait réalisées ou de nombre de fois que le souhait est réalisé.
 \end{itemize}
-    
+
+
 \section{Modélisation}
+L'ORM de Django permet de travailler uniquement avec une définition de classes, et de faire en sorte que le lien avec la base de données soit géré uniquement de manière indirecte, par Django lui-même.
+On peut schématiser ce comportement par une classe = une table.
 
-
-L'ORM de Django permet de travailler uniquement avec une définition de
-classes, et de faire en sorte que le lien avec la base de données soit
-géré uniquement de manière indirecte, par Django lui-même. On peut
-schématiser ce comportement par une classe = une table.
-
-Comme on l'a vu dans la description des fonctionnalités, on va
-\textbf{grosso modo} avoir besoin des éléments suivants:
+Comme on l'a vu dans la description des fonctionnalités, on va \textbf{grosso modo} avoir besoin des éléments suivants :
 
 \begin{itemize}
-\item
-  Des listes de souhaits
-\item
-  Des éléments qui composent ces listes
-\item
-  Des parts pouvant composer chacun de ces éléments
-\item
-  Des utilisateurs pour gérer tout ceci.
+    \item Des listes de souhaits
+    \item Des éléments qui composent ces listes
+    \item Des parts pouvant composer chacun de ces éléments
+    \item Des utilisateurs pour gérer tout ceci.
 \end{itemize}
 
-Nous proposons dans un premier temps d'éluder la gestion des
-utilisateurs, et de simplement se concentrer sur les fonctionnalités
-principales. Cela nous donne ceci:
+Nous proposons dans un premier temps d'éluder la gestion des utilisateurs, et de simplement se concentrer sur les fonctionnalités principales.
+Cela nous donne ceci:
 
+% TODO: il y a beaucoup de verbatim dans l'enumerate ci-dessous.
 \begin{enumerate}
-\def\labelenumi{\alph{enumi}.}
-\item
-  code-block:: python
+    \def\labelenumi{\alph{enumi}.}
+    \item
+        code-block:: python
 
-\begin{verbatim}
-# wish/models.py
-\end{verbatim}
+        \begin{verbatim}
+            # wish/models.py
+        \end{verbatim}
 
-\begin{verbatim}
-from django.db import models
-\end{verbatim}
+        \begin{verbatim}
+            from django.db import models
+        \end{verbatim}
 
-\begin{verbatim}
-class Wishlist(models.Model):
-    pass
-\end{verbatim}
+        \begin{verbatim}
+            class Wishlist(models.Model):
+                pass
+        \end{verbatim}
 
-\begin{verbatim}
-class Item(models.Model):
-    pass
-\end{verbatim}
+        \begin{verbatim}
+            class Item(models.Model):
+                pass
+        \end{verbatim}
 
-\begin{verbatim}
-class Part(models.Model):
-    pass
-\end{verbatim}
+        \begin{verbatim}
+            class Part(models.Model):
+                pass
+        \end{verbatim}
 \end{enumerate}
 
-Les classes sont créées, mais vides. Entrons dans les détails.
+Les classes sont créées, mais vides.
+Entrons dans les détails.
 
 Listes de souhaits
 
-Comme déjà décrit précédemment, les listes de souhaits peuvent
-s'apparenter simplement à un objet ayant un nom et une description. Pour
-rappel, voici ce qui avait été défini dans les spécifications:
+Comme déjà décrit précédemment, les listes de souhaits peuvent s'apparenter simplement à un objet ayant un nom et une description.
+Pour rappel, voici ce qui avait été défini dans les spécifications:
 
 \begin{itemize}
-\item
-  un identifiant
-\item
-  un identifiant externe
-\item
-  un nom
-\item
-  une description
-\item
-  une date de création
-\item
-  une date de modification
+    \item un identifiant
+    \item un identifiant externe
+    \item un nom
+    \item une description
+    \item une date de création
+    \item une date de modification
 \end{itemize}
 
 Notre classe \texttt{Wishlist} peut être définie de la manière suivante:
 
 \begin{enumerate}
-\def\labelenumi{\alph{enumi}.}
-\item
-  code-block:: python
+    \def\labelenumi{\alph{enumi}.}
+    \item
+        code-block:: python
 
-\begin{verbatim}
-# wish/models.py
-\end{verbatim}
+    \begin{verbatim}
+        # wish/models.py
+    \end{verbatim}
 
-\begin{verbatim}
-class Wishlist(models.Model):
-\end{verbatim}
+    \begin{verbatim}
+        class Wishlist(models.Model):
+    \end{verbatim}
 
-\begin{verbatim}
-name = models.CharField(max_length=255)
-description = models.TextField()
-created_at = models.DateTimeField(auto_now_add=True)
-updated_at = models.DateTimeField(auto_now=True)
-external_id = models.UUIDField(unique=True, default=uuid.uuid4, editable=False)
-\end{verbatim}
+    \begin{verbatim}
+        name = models.CharField(max_length=255)
+        description = models.TextField()
+        created_at = models.DateTimeField(auto_now_add=True)
+        updated_at = models.DateTimeField(auto_now=True)
+        external_id = models.UUIDField(unique=True, default=uuid.uuid4, editable=False)
+    \end{verbatim}
 \end{enumerate}
 
-Que peut-on constater?
-
+Que peut-on constater ?
 \begin{itemize}
-\item
-  Que s'il n'est pas spécifié, un identifiant \texttt{id} sera
-  automatiquement généré et accessible dans le modèle. Si vous souhaitez
-  malgré tout spécifier que ce soit un champ en particulier qui devienne
-  la clé primaire, il suffit de l'indiquer grâce à l'attribut
-  \texttt{primary\_key=True}.
-\item
-  Que chaque type de champs (\texttt{DateTimeField}, \texttt{CharField},
-  \texttt{UUIDField}, etc.) a ses propres paramètres d'initialisation.
-  Il est intéressant de les apprendre ou de se référer à la
-  documentation en cas de doute.
+    \item
+        Que s'il n'est pas spécifié, un identifiant \texttt{id} sera automatiquement généré et accessible dans le modèle.
+        Si vous souhaitez malgré tout spécifier que ce soit un champ en particulier qui devienne la clé primaire, il suffit de l'indiquer grâce à l'attribut \texttt{primary\_key=True}.
+    \item
+        Que chaque type de champs (\texttt{DateTimeField}, \texttt{CharField}, \texttt{UUIDField}, etc.) a ses propres paramètres d'initialisation.
+        Il est intéressant de les apprendre ou de se référer à la documentation en cas de doute.
 \end{itemize}
 
-Au niveau de notre modélisation:
-
+Au niveau de notre modélisation :
 \begin{itemize}
-\item
-  La propriété \texttt{created\_at} est gérée automatiquement par Django
-  grâce à l'attribut \texttt{auto\_now\_add}: de cette manière, lors
-  d'un \textbf{ajout}, une valeur par défaut ("\textbf{maintenant}")
-  sera attribuée à cette propriété.
-\item
-  La propriété \texttt{updated\_at} est également gérée automatique,
-  cette fois grâce à l'attribut \texttt{auto\_now} initialisé à
-  \texttt{True}: lors d'une \textbf{mise à jour}, la propriété se verra
-  automatiquement assigner la valeur du moment présent. Cela ne permet
-  évidemment pas de gérer un historique complet et ne nous dira pas
-  \textbf{quels champs} ont été modifiés, mais cela nous conviendra dans
-  un premier temps.
-\item
-  La propriété \texttt{external\_id} est de type \texttt{UUIDField}.
-  Lorsqu'une nouvelle instance sera instanciée, cette propriété prendra
-  la valeur générée par la fonction \texttt{uuid.uuid4()}. \textbf{A
-  priori}, chacun des types de champs possède une propriété
-  \texttt{default}, qui permet d'initialiser une valeur sur une nouvelle
-  instance.
+    \item
+        La propriété \texttt{created\_at} est gérée automatiquement par Django grâce à l'attribut \texttt{auto\_now\_add}: de cette manière, lors d'un \textbf{ajout}, une valeur par défaut ("\textbf{maintenant}") sera attribuée à cette propriété.
+    \item
+        La propriété \texttt{updated\_at} est également gérée automatique, cette fois grâce à l'attribut \texttt{auto\_now} initialisé à \texttt{True}: lors d'une \textbf{mise à jour}, la propriété se verra automatiquement assigner la valeur du moment présent.
+        Cela ne permet évidemment pas de gérer un historique complet et ne nous dira pas \textbf{quels champs} ont été modifiés, mais cela nous conviendra dans un premier temps.
+    \item
+        La propriété \texttt{external\_id} est de type \texttt{UUIDField}.
+        Lorsqu'une nouvelle instance sera instanciée, cette propriété prendra la valeur générée par la fonction \texttt{uuid.uuid4()}.
+        \textbf{A priori}, chacun des types de champs possède une propriété \texttt{default}, qui permet d'initialiser une valeur sur une nouvelle instance.
 \end{itemize}
 
 Souhaits
 
-Nos souhaits ont besoin des propriétés suivantes:
-
+Nos souhaits ont besoin des propriétés suivantes :
 \begin{itemize}
-\item
-  un identifiant
-\item
-  l'identifiant de la liste auquel le souhait est lié
-\item
-  un nom
-\item
-  une description
-\item
-  le propriétaire
-\item
-  une date de création
-\item
-  une date de modification
-\item
-  une image permettant de le représenter.
-\item
-  un nombre (1 par défaut)
-\item
-  un prix facultatif
-\item
-  un nombre de part facultatif, si un prix est fourni.
+    \item un identifiant
+    \item l'identifiant de la liste auquel le souhait est lié
+    \item un nom
+    \item une description
+    \item le propriétaire
+    \item une date de création
+    \item une date de modification
+    \item une image permettant de le représenter.
+    \item un nombre (1 par défaut)
+    \item un prix facultatif
+    \item un nombre de part facultatif, si un prix est fourni.
 \end{itemize}
 
-Après implémentation, cela ressemble à ceci:
-
-
-
+Après implémentation, cela ressemble à ceci :
 \begin{enumerate}
     \def\labelenumi{\alph{enumi}.}
     \item
       code-block:: python
-    
+
     \begin{verbatim}
-    # wish/models.py
+        # wish/models.py
     \end{verbatim}
-    
+
     \begin{verbatim}
-    class Wish(models.Model):
+        class Wish(models.Model):
     \end{verbatim}
-    
+
     \begin{verbatim}
-    wishlist = models.ForeignKey(Wishlist)
-    name = models.CharField(max_length=255)
-    description = models.TextField()
-    created_at = models.DateTimeField(auto_now_add=True)
-    updated_at = models.DateTimeField(auto_now=True)
-    picture = models.ImageField()
-    numbers_available = models.IntegerField(default=1)
-    number_of_parts = models.IntegerField(null=True)
-    estimated_price = models.DecimalField(max_digits=19, decimal_places=2,
-                                            null=True)
+        wishlist = models.ForeignKey(Wishlist)
+        name = models.CharField(max_length=255)
+        description = models.TextField()
+        created_at = models.DateTimeField(auto_now_add=True)
+        updated_at = models.DateTimeField(auto_now=True)
+        picture = models.ImageField()
+        numbers_available = models.IntegerField(default=1)
+        number_of_parts = models.IntegerField(null=True)
+        estimated_price = models.DecimalField(max_digits=19, decimal_places=2, null=True)
     \end{verbatim}
-    \end{enumerate}
-    
-    A nouveau, que peut-on constater ?
-    
-    \begin{itemize}
-    \item
-      Les clés étrangères sont gérées directement dans la déclaration du
-      modèle. Un champ de type `ForeignKey
-      \textless{}\url{https://docs.djangoproject.com/en/1.8/ref/models/fields/\#django.db.models.ForeignKey\%3E\%60_}
-      permet de déclarer une relation 1-N entre deux classes. Dans la même
-      veine, une relation 1-1 sera représentée par un champ de type
-      `OneToOneField
-      \textless{}\url{https://docs.djangoproject.com/en/1.8/topics/db/examples/one_to_one/\%3E\%60}\emph{,
-      alors qu'une relation N-N utilisera un `ManyToManyField
-      \textless{}\url{https://docs.djangoproject.com/en/1.8/topics/db/examples/many_to_many/\%3E\%60}}.
-    \item
-      L'attribut \texttt{default} permet de spécifier une valeur initiale,
-      utilisée lors de la construction de l'instance. Cet attribut peut
-      également être une fonction.
-    \item
-      Pour rendre un champ optionnel, il suffit de lui ajouter l'attribut
-      \texttt{null=True}.
-    \item
-      Comme cité ci-dessus, chaque champ possède des attributs spécifiques.
-      Le champ \texttt{DecimalField} possède par exemple les attributs
-      \texttt{max\_digits} et \texttt{decimal\_places}, qui nous permettra
-      de représenter une valeur comprise entre 0 et plus d'un milliard (avec
-      deux chiffres décimaux).
-    \item
-      L'ajout d'un champ de type \texttt{ImageField} nécessite
-      l'installation de \texttt{pillow} pour la gestion des images. Nous
-      l'ajoutons donc à nos pré-requis, dans le fichier
-      \texttt{requirements/base.txt}.
-    \end{itemize}
-
-\subsection{Parts}
-
-Les parts ont besoins des propriétés suivantes:
-
-\begin{itemize}
-\item
-  un identifiant
-\item
-  identifiant du souhait
-\item
-  identifiant de l'utilisateur si connu
-\item
-  identifiant de la personne si utilisateur non connu
-\item
-  un commentaire
-\item
-  une date de réalisation
-\end{itemize}
-
-Elles constituent la dernière étape de notre modélisation et représente
-la réalisation d'un souhait. Il y aura autant de part d'un souhait que
-le nombre de souhait à réaliser fois le nombre de part.
-
-Elles permettent à un utilisateur de participer au souhait émis par un
-autre utilisateur. Pour les modéliser, une part est liée d'un côté à un
-souhait, et d'autre part à un utilisateur. Cela nous donne ceci:
-
-\begin{enumerate}
-\item
-  code-block:: python
-
-\begin{verbatim}
-from django.contrib.auth.models import User
-\end{verbatim}
-
-\begin{verbatim}
-class WishPart(models.Model):
-\end{verbatim}
-
-\begin{verbatim}
-wish = models.ForeignKey(Wish)
-user = models.ForeignKey(User, null=True)
-unknown_user = models.ForeignKey(UnknownUser, null=True)
-comment = models.TextField(null=True, blank=True)
-done_at = models.DateTimeField(auto_now_add=True)
-\end{verbatim}
 \end{enumerate}
 
-La classe \texttt{User} référencée au début du snippet correspond à
-l'utilisateur qui sera connecté. Ceci est géré par Django. Lorsqu'une
-requête est effectuée et est transmise au serveur, cette information
-sera disponible grâce à l'objet \texttt{request.user}, transmis à chaque
-fonction ou \textbf{Class-based-view}. C'est un des avantages d'un
-framework tout intégré: il vient \textbf{batteries-included} et beaucoup
-de détails ne doivent pas être pris en compte. Pour le moment, nous nous
-limiterons à ceci. Par la suite, nous verrons comment améliorer la
-gestion des profils utilisateurs, comment y ajouter des informations et
-comment gérer les cas particuliers.
+A nouveau, que peut-on constater ?
+\begin{itemize}
+    \item
+        Les clés étrangères sont gérées directement dans la déclaration dumodèle.
+        Un champ de type `ForeignKey
+        \textless{}\url{https://docs.djangoproject.com/en/1.8/ref/models/fields/\#django.db.models.ForeignKey\%3E\%60_}
+        permet de déclarer une relation 1-N entre deux classes.
+        % TODO : il y a des fautes de syntaxe dans
+        Dans la même veine, une relation 1-1 sera représentée par un champ de type `OneToOneField \textless{}\url{https://docs.djangoproject.com/en/1.8/topics/db/examples/one_to_one/\%3E\%60}\emph{,alors qu'une relation N-N utilisera un `ManyToManyField \textless{}\url{https://docs.djangoproject.com/en/1.8/topics/db/examples/many_to_many/\%3E\%60}}.
+    \item
+        L'attribut \texttt{default} permet de spécifier une valeur initiale, utilisée lors de la construction de l'instance.
+        Cet attribut peut également être une fonction.
+    \item
+        Pour rendre un champ optionnel, il suffit de lui ajouter l'attribut \texttt{null=True}.
+    \item
+        Comme cité ci-dessus, chaque champ possède des attributs spécifiques.
+        Le champ \texttt{DecimalField} possède par exemple les attributs \texttt{max\_digits} et \texttt{decimal\_places}, qui nous permettra de représenter une valeur comprise entre 0 et plus d'un milliard (avec deux chiffres décimaux).
+    \item
+        L'ajout d'un champ de type \texttt{ImageField} nécessite l'installation de \texttt{pillow} pour la gestion des images.
+        Nous l'ajoutons donc à nos pré-requis, dans le fichier \texttt{requirements/base.txt}.
+\end{itemize}
+
+\subsection{Parts}
+Les parts ont besoins des propriétés suivantes :
+\begin{itemize}
+    \item un identifiant
+    \item identifiant du souhait
+    \item identifiant de l'utilisateur si connu
+    \item identifiant de la personne si utilisateur non connu
+    \item un commentaire
+    \item une date de réalisation
+\end{itemize}
+
+Elles constituent la dernière étape de notre modélisation et représente la réalisation d'un souhait.
+Il y aura autant de part d'un souhait que le nombre de souhait à réaliser fois le nombre de part.
+
+Elles permettent à un utilisateur de participer au souhait émis par un autre utilisateur.
+Pour les modéliser, une part est liée d'un côté à un souhait, et d'autre part à un utilisateur.
+Cela nous donne ceci :
+\begin{enumerate}
+    \item
+        code-block:: python
+
+        \begin{verbatim}
+            from django.contrib.auth.models import User
+        \end{verbatim}
+
+        \begin{verbatim}
+            class WishPart(models.Model):
+        \end{verbatim}
+
+        \begin{verbatim}
+            wish = models.ForeignKey(Wish)
+            user = models.ForeignKey(User, null=True)
+            unknown_user = models.ForeignKey(UnknownUser, null=True)
+            comment = models.TextField(null=True, blank=True)
+            done_at = models.DateTimeField(auto_now_add=True)
+        \end{verbatim}
+\end{enumerate}
+
+La classe \texttt{User} référencée au début du snippet correspond à l'utilisateur qui sera connecté.
+Ceci est géré par Django.
+Lorsqu'une requête est effectuée et est transmise au serveur, cette information sera disponible grâce à l'objet \texttt{request.user}, transmis à chaque fonction ou \textbf{Class-based-view}.
+C'est un des avantages d'un
+framework tout intégré : il vient \textbf{batteries-included} et beaucoup de détails ne doivent pas être pris en compte.
+Pour le moment, nous nous limiterons à ceci.
+Par la suite, nous verrons comment améliorer la gestion des profils utilisateurs, comment y ajouter des informations et comment gérer les cas particuliers.
+
+La classe \texttt{UnknownUser} permet de représenter un utilisateur non enregistré sur le site et est définie au point suivant.
 
-La classe \texttt{UnknownUser} permet de représenter un utilisateur non
-enregistré sur le site et est définie au point suivant.
 
 \subsection{Utilisateurs inconnus}
-
-
 Utilisateurs inconnus
 
 \begin{enumerate}
-\def\labelenumi{\alph{enumi}.}
-\item
-  todo:: je supprimerais pour que tous les utilisateurs soient gérés au
-  même endroit.
+    \def\labelenumi{\alph{enumi}.}
+    \item
+        todo:: je supprimerais pour que tous les utilisateurs soient gérés au même endroit.
 \end{enumerate}
 
-Pour chaque réalisation d'un souhait par quelqu'un, il est nécessaire de
-sauver les données suivantes, même si l'utilisateur n'est pas enregistré
-sur le site:
-
+Pour chaque réalisation d'un souhait par quelqu'un, il est nécessaire de sauver les données suivantes, même si l'utilisateur n'est pas enregistré sur le site:
 \begin{itemize}
-\item
-  un identifiant
-\item
-  un nom
-\item
-  une adresse email. Cette adresse email sera unique dans notre base de
-  données, pour ne pas créer une nouvelle occurence si un même
-  utilisateur participe à la réalisation de plusieurs souhaits.
+    \item un identifiant
+    \item un nom
+    \item une adresse email.
+        Cette adresse email sera unique dans notre base de données, pour ne pas créer une nouvelle occurence si un même utilisateur participe à la réalisation de plusieurs souhaits.
 \end{itemize}
 
-Ceci nous donne après implémentation:
-
+Ceci nous donne après implémentation :
 \begin{enumerate}
-\def\labelenumi{\alph{enumi}.}
-\item
-  code-block:: python
+    \def\labelenumi{\alph{enumi}.}
+    \item
+        code-block:: python
 
-\begin{verbatim}
-class UnkownUser(models.Model):
-\end{verbatim}
+        \begin{verbatim}
+            class UnkownUser(models.Model):
+        \end{verbatim}
 
-\begin{verbatim}
-name = models.CharField(max_length=255)
-email = models.CharField(email = models.CharField(max_length=255, unique=True)
-\end{verbatim}
+        \begin{verbatim}
+            name = models.CharField(max_length=255)
+            email = models.CharField(email = models.CharField(max_length=255, unique=True)
+        \end{verbatim}
 \end{enumerate}

chapters/heroku.tex

@@ -1,26 +1,24 @@
 \chapter{PaaS - Heroku}
 
-
-\href{https://www.heroku.com}{Heroku} est une \emph{Plateform As A Service} paas, où vous choisissez le \emph{service} dont vous avez besoin (une base de données, un service de cache, un service applicatif, ..., vous lui envoyer les paramètres nécessaires et le tout démarre gentiment sans que vous ne deviez superviser l'hôte. Ce mode démarrage ressemble énormément aux 12 facteurs dont nous avons déjà parlé plus tôt - raison de plus pour que notre application soit directement prête à y être déployée, d'autant plus qu'il ne sera pas
-possible de modifier un fichier une fois qu'elle aura démarré: si vous souhaitez modifier un paramètre, cela reviendra à couper l'actuelle et envoyer de nouveaux paramètres et recommencer le déploiement depuis le
+\href{https://www.heroku.com}{Heroku} est une \emph{Plateform As A Service} paas, où vous choisissez le \emph{service} dont vous avez besoin (une base de données, un service de cache, un service applicatif, \ldots, vous lui envoyer les paramètres nécessaires et le tout démarre gentiment sans que vous ne deviez superviser l'hôte.
+Ce mode démarrage ressemble énormément aux 12 facteurs dont nous avons déjà parlé plus tôt - raison de plus pour que notre application soit directement prête à y être déployée, d'autant plus qu'il ne sera pas possible de modifier un fichier une fois qu'elle aura démarré : si vous souhaitez modifier un paramètre, cela reviendra à couper l'actuelle et envoyer de nouveaux paramètres et recommencer le déploiement depuis le
 début.
 
 \begin{figure}
-\centering
-\includegraphics{images/deployment/heroku.png}
-\caption{Invest in apps, not ops. Heroku handles the hard stuff ---
-patching and upgrading, 24/7 ops and security, build systems, failovers,
-and more --- so your developers can stay focused on building great
-apps.}
+    \centering
+    \includegraphics{images/deployment/heroku.png}
+    \caption{Invest in apps, not ops. Heroku handles the hard stuff --- patching and upgrading, 24/7 ops and security, build systems, failovers, and more --- so your developers can stay focused on building great apps.}
 \end{figure}
 
-Pour un projet de type "hobby" et pour l'exemple de déploiement ci-dessous, il est tout à fait possible de s'en sortir sans dépenser un kopek, afin de tester nos quelques idées ou mettre rapidement un \emph{Most Valuable Product} en place. La seule contrainte consistera à pouvoir héberger des fichiers envoyés par vos utilisateurs - ceci pourra être fait en configurant un \emph{bucket compatible S3}, par exemple chez Amazon, Scaleway ou OVH.
+Pour un projet de type "hobby" et pour l'exemple de déploiement ci-dessous, il est tout à fait possible de s'en sortir sans dépenser un kopek, afin de tester nos quelques idées ou mettre rapidement un \emph{Most Valuable Product} en place.
+La seule contrainte consistera à pouvoir héberger des fichiers envoyés par vos utilisateurs - ceci pourra être fait en configurant un \emph{bucket compatible S3}, par exemple chez Amazon, Scaleway ou OVH.
 
-Le fonctionnement est relativement simple: pour chaque application, Heroku crée un dépôt Git qui lui est associé. Il suffit donc d'envoyer les sources de votre application vers ce dépôt pour qu'Heroku les interprête comme étant une nouvelle version, déploie les nouvelles fonctionnalités - sous réserve que tous les tests passent correctement - et les mettent à disposition. Dans un fonctionnement plutôt manuel, chaque déploiement est initialisé par le développeur ou par un membre de l'équipe. Dans une version plus automatisée, chacun de ces déploiements peut être placé en fin de \emph{pipeline}, lorsque tous les tests
-unitaires et d'intégration auront été réalisés.
-
-Au travers de la commande \texttt{heroku\ create}, vous associez donc une nouvelle référence à votre code source, comme le montre le contenu du fichier \texttt{.git/config} ci-dessous:
+Le fonctionnement est relativement simple: pour chaque application, Heroku crée un dépôt Git qui lui est associé.
+Il suffit donc d'envoyer les sources de votre application vers ce dépôt pour qu'Heroku les interprête comme étant une nouvelle version, déploie les nouvelles fonctionnalités - sous réserve que tous les tests passent correctement - et les mettent à disposition.
+Dans un fonctionnement plutôt manuel, chaque déploiement est initialisé par le développeur ou par un membre de l'équipe.
+Dans une version plus automatisée, chacun de ces déploiements peut être placé en fin de \emph{pipeline}, lorsque tous les tests unitaires et d'intégration auront été réalisés.
 
+Au travers de la commande \texttt{heroku\ create}, vous associez donc une nouvelle référence à votre code source, comme le montre le contenu du fichier \texttt{.git/config} ci-dessous :
 \begin{verbatim}
     $ heroku create
     Creating app... done, -> young-temple-86098
@@ -43,24 +41,20 @@ Au travers de la commande \texttt{heroku\ create}, vous associez donc une nouvel
 
 \begin{verbatim}
     Pour définir de quel type d'application il s'agit, Heroku nécessite un minimum de configuration.
-    Celle-ci se limite aux deux fichiers suivants:
-    
+    Celle-ci se limite aux deux fichiers suivants :
+
     * Déclarer un fichier `Procfile` qui va simplement décrire le fichier à passer au protocole WSGI
     * Déclarer un fichier `requirements.txt` (qui va éventuellement chercher ses propres dépendances dans un sous-répertoire, avec l'option `-r`)
 \end{verbatim}
 
-Après ce paramétrage, il suffit de pousser les changements vers ce
-nouveau dépôt grâce à la commande \texttt{git\ push\ heroku\ master}.
+Après ce paramétrage, il suffit de pousser les changements vers ce nouveau dépôt grâce à la commande \texttt{git\ push\ heroku\ master}.
 
-Heroku propose des espaces de déploiements, mais pas d'espace de
-stockage. Il est possible d'y envoyer des fichiers utilisateurs
-(typiquement, des media personnalisés), mais ceux-ci seront perdus lors
-du redémarrage du container. Il est donc primordial de configurer
-correctement l'hébergement des fichiers média, de préférences sur un
-stockage compatible S3. s3
+Heroku propose des espaces de déploiements, mais pas d'espace de stockage.
+Il est possible d'y envoyer des fichiers utilisateurs (typiquement, des media personnalisés), mais ceux-ci seront perdus lors du redémarrage du container.
+Il est donc primordial de configurer correctement l'hébergement des fichiers média, de préférences sur un stockage compatible S3.
+s3
 
-Prêt à vous lancer ? Commencez par créer un compte:
-\url{https://signup.heroku.com/python}.
+Prêt à vous lancer ? Commencez par créer un compte : \url{https://signup.heroku.com/python}.
 
 \section{Configuration du compte}
 
@@ -69,37 +63,29 @@ Prêt à vous lancer ? Commencez par créer un compte:
 Vous aurez peut-être besoin d'un coup de pouce pour démarrer votre première application; heureusement, la documentation est super bien faite:
 
 \begin{figure}
-\centering
-\includegraphics{images/deployment/heroku-new-app.png}
-\caption{Heroku: Commencer à travailler avec un langage}
+    \centering
+    \includegraphics{images/deployment/heroku-new-app.png}
+    \caption{Heroku: Commencer à travailler avec un langage}
 \end{figure}
 
 Installez ensuite la CLI (\emph{Command Line Interface}) en suivant \href{https://devcenter.heroku.com/articles/heroku-cli}{la documentation suivante}.
 
-Au besoin, cette CLI existe pour:
-
+Au besoin, cette CLI existe pour :
 \begin{enumerate}
-\item
-  macOS, \emph{via} `brew `
-\item
-  Windows, grâce à un
-  \href{https://cli-assets.heroku.com/heroku-x64.exe}{binaire x64} (la
-  version 32 bits existe aussi, mais il est peu probable que vous en
-  ayez besoin)
-\item
-  GNU/Linux, via un script Shell
-  \texttt{curl\ https://cli-assets.heroku.com/install.sh\ \textbar{}\ sh}
-  ou sur \href{https://snapcraft.io/heroku}{SnapCraft}.
+    \item
+        macOS, \emph{via} `brew `
+    \item
+        Windows, grâce à un \href{https://cli-assets.heroku.com/heroku-x64.exe}{binaire x64} (la version 32 bits existe aussi, mais il est peu probable que vous en ayez besoin)
+    \item
+        GNU/Linux, via un script Shell \texttt{curl\ https://cli-assets.heroku.com/install.sh\ \textbar{}\ sh} ou sur \href{https://snapcraft.io/heroku}{SnapCraft}.
 \end{enumerate}
 
-Une fois installée, connectez-vous:
-
+Une fois installée, connectez-vous :
 \begin{verbatim}
     $ heroku login
 \end{verbatim}
 
-Et créer votre application:
-
+Et créer votre application :
 \begin{verbatim}
     $ heroku create
     Creating app... done, -> young-temple-86098
@@ -113,12 +99,8 @@ Et créer votre application:
     \caption{Notre application est à présent configurée!}
 \end{figure}
 
-    
-
 Ajoutons lui une base de données, que nous sauvegarderons à intervalle
-régulier:
-
-
+régulier :
 \begin{verbatim}
     $ heroku addons:create heroku-postgresql:hobby-dev
     Creating heroku-postgresql:hobby-dev on -> still-thicket-66406... free
@@ -127,7 +109,7 @@ régulier:
     ! data from another database with pg:copy
     Created postgresql-clear-39693 as DATABASE_URL
     Use heroku addons:docs heroku-postgresql to view documentation
-    
+
     $ heroku pg:backups schedule --at '14:00 Europe/Brussels' DATABASE_URL
     Scheduling automatic daily backups of postgresql-clear-39693 at 14:00
     Europe/Brussels... done
@@ -145,21 +127,21 @@ régulier:
     heroku config:set DJANGO_DEBUG=False
     heroku config:set DJANGO_SETTINGS_MODULE=config.settings.production
     heroku config:set DJANGO_SECRET_KEY="$(openssl rand -base64 64)"
-    
+
     # Generating a 32 character-long random string without any of the visually
     similar characters "IOl01":
     heroku config:set DJANGO_ADMIN_URL="$(openssl rand -base64 4096 | tr -dc 'A-
     HJ-NP-Za-km-z2-9' | head -c 32)/"
-    
+
     # Set this to your Heroku app url, e.g. 'bionic-beaver-28392.herokuapp.com'
     heroku config:set DJANGO_ALLOWED_HOSTS=
-    
+
     # Assign with AWS_ACCESS_KEY_ID
     heroku config:set DJANGO_AWS_ACCESS_KEY_ID=
-    
+
     # Assign with AWS_SECRET_ACCESS_KEY
     heroku config:set DJANGO_AWS_SECRET_ACCESS_KEY=
-    
+
     # Assign with AWS_STORAGE_BUCKET_NAME
     heroku config:set DJANGO_AWS_STORAGE_BUCKET_NAME=
     git push heroku master
@@ -170,24 +152,22 @@ régulier:
 
 \section{Type d'application}
 
-Pour qu'Heroku comprenne le type d'application à démarrer, ainsi que les commandes à exécuter pour que tout fonctionne correctement. Pour un projet Django, cela comprend, à placer à la racine de votre projet:
-
+Pour qu'Heroku comprenne le type d'application à démarrer, ainsi que les commandes à exécuter pour que tout fonctionne correctement.
+Pour un projet Django, cela comprend, à placer à la racine de votre projet :
 \begin{enumerate}
-\item
-  Un fichier \texttt{requirements.txt} (qui peut éventuellement faire appel à un autre fichier, \textbf{via} l'argument \texttt{-r})
-\item
-  Un fichier \texttt{Procfile} ({[}sans extension{]}(\url{https://devcenter.heroku.com/articles/procfile)}!),
-  qui expliquera la commande pour le protocole WSGI.
+    \item
+        Un fichier \texttt{requirements.txt} (qui peut éventuellement faire appel à un autre fichier, \textbf{via} l'argument \texttt{-r})
+    \item
+        Un fichier \texttt{Procfile} ({[}sans extension{]}(\url{https://devcenter.heroku.com/articles/procfile)}!), qui expliquera la commande pour le protocole WSGI.
 \end{enumerate}
 
-Dans notre exemple:
-
+Dans notre exemple :
 \begin{verbatim}
-# requirements.txt
-django==3.2.8
-gunicorn
-boto3
-django-storages
+    # requirements.txt
+    django==3.2.8
+    gunicorn
+    boto3
+    django-storages
 \end{verbatim}
 
 \begin{verbatim}
@@ -198,50 +178,36 @@ django-storages
 
 \section{Hébergement S3}
 
-Pour cette partie, nous allons nous baser sur
-l'\href{https://www.scaleway.com/en/object-storage/}{Object Storage de
-Scaleway}. Ils offrent 75GB de stockage et de transfert par mois, ce qui
-va nous laisser suffisament d'espace pour jouer un peu.
+Pour cette partie, nous allons nous baser sur l'\href{https://www.scaleway.com/en/object-storage/}{Object Storage de Scaleway}.
+Ils offrent 75GB de stockage et de transfert par mois, ce qui va nous laisser suffisament d'espace pour jouer un peu.
 
 \includegraphics{images/deployment/scaleway-object-storage-bucket.png}
 
-L'idée est qu'au moment de la construction des fichiers statiques,
-Django aille simplement les héberger sur un espace de stockage
-compatible S3. La complexité va être de configurer correctement les
-différents points de terminaison. Pour héberger nos fichiers sur notre
-\textbf{bucket} S3, il va falloir suivre et appliquer quelques étapes
-dans l'ordre:
+L'idée est qu'au moment de la construction des fichiers statiques, Django aille simplement les héberger sur un espace de stockage compatible S3.
+La complexité va être de configurer correctement les différents points de terminaison.
+Pour héberger nos fichiers sur notre \textbf{bucket} S3, il va falloir suivre et appliquer quelques étapes dans l'ordre :
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\item
-  Configurer un bucket compatible S3 - je parlais de Scaleway, mais il y
-  en a - \textbf{littéralement} - des dizaines.
-\item
-  Ajouter la librairie \texttt{boto3}, qui s'occupera de "parler" avec
-  ce type de protocole
-\item
-  Ajouter la librairie \texttt{django-storage}, qui va elle s'occuper de
-  faire le câblage entre le fournisseur (\textbf{via} \texttt{boto3}) et
-  Django, qui s'attend à ce qu'on lui donne un moteur de gestion
-  \textbf{via} la clé
-  {[}\texttt{DJANGO\_STATICFILES\_STORAGE}{]}(\url{https://docs.djangoproject.com/en/3.2/ref/settings/\#std:setting-STATICFILES_STORAGE}).
+    \def\labelenumi{\arabic{enumi}.}
+    \item
+    Configurer un bucket compatible S3 - je parlais de Scaleway, mais il y
+    en a - \textbf{littéralement} - des dizaines.
+    \item
+    Ajouter la librairie \texttt{boto3}, qui s'occupera de "parler" avec
+    ce type de protocole
+    \item
+    Ajouter la librairie \texttt{django-storage}, qui va elle s'occuper de
+    faire le câblage entre le fournisseur (\textbf{via} \texttt{boto3}) et
+    Django, qui s'attend à ce qu'on lui donne un moteur de gestion
+    \textbf{via} la clé
+    {[}\texttt{DJANGO\_STATICFILES\_STORAGE}{]}(\url{https://docs.djangoproject.com/en/3.2/ref/settings/\#std:setting-STATICFILES_STORAGE}).
 \end{enumerate}
 
-La première étape consiste à se rendre dans {[}la console
-Scaleway{]}(\url{https://console.scaleway.com/project/credentials}),
-pour gérer ses identifiants et créer un jeton.
+La première étape consiste à se rendre dans {[}la console Scaleway{]}(\url{https://console.scaleway.com/project/credentials}), pour gérer ses identifiants et créer un jeton.
 
 \includegraphics{images/deployment/scaleway-api-key.png}
 
-Selon la documentation de
-\href{https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html\#settings}{django-storages},
-de
-\href{https://boto3.amazonaws.com/v1/documentation/api/latest/index.html}{boto3}
-et de
-\href{https://www.scaleway.com/en/docs/tutorials/deploy-saas-application/}{Scaleway},
-vous aurez besoin des clés suivantes au niveau du fichier
-\texttt{settings.py}:
+Selon la documentation de \href{https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html\#settings}{django-storages}, de \href{https://boto3.amazonaws.com/v1/documentation/api/latest/index.html}{boto3} et de \href{https://www.scaleway.com/en/docs/tutorials/deploy-saas-application/}{Scaleway}, vous aurez besoin des clés suivantes au niveau du fichier \texttt{settings.py} :
 
 \begin{minted}{python}
     AWS_ACCESS_KEY_ID = os.getenv('ACCESS_KEY_ID')
@@ -283,10 +249,8 @@ qui sera confirmée par le \textbf{bucket}:
 Sources complémentaires:
 
 \begin{itemize}
-\item
-  {[}How to store Django static and media files on S3 in
-  production{]}(\url{https://coderbook.com/@marcus/how-to-store-django-static-and-media-files-on-s3-in-production/})
-\item
-  {[}Using Django and
-  Boto3{]}(\url{https://www.simplecto.com/using-django-and-boto3-with-scaleway-object-storage/})
+    \item
+        {[}How to store Django static and media files on S3 in production{]}(\url{https://coderbook.com/@marcus/how-to-store-django-static-and-media-files-on-s3-in-production/})
+    \item
+        {[}Using Django and Boto3{]}(\url{https://www.simplecto.com/using-django-and-boto3-with-scaleway-object-storage/})
 \end{itemize}

chapters/i18n.tex

@@ -4,15 +4,11 @@ La localisation (\emph{l10n}) et l'internationalization (\emph{i18n})
 sont deux concepts proches, mais différents:
 
 \begin{itemize}
-\item
-  Internationalisation: \emph{Preparing the software for localization.
-  Usually done by developers.}
-\item
-  Localisation: \emph{Writing the translations and local formats.
-  Usually done by translators.}
+    \item
+        Internationalisation: \emph{Preparing the software for localization. Usually done by developers.}
+    \item
+        Localisation: \emph{Writing the translations and local formats. Usually done by translators.}
 \end{itemize}
 
-L'internationalisation est donc le processus permettant à une
-application d'accepter une forme de localisation. La seconde ne va donc
-pas sans la première, tandis que la première ne fait qu'autoriser la
-seconde.
+L'internationalisation est donc le processus permettant à une application d'accepter une forme de localisation.
+La seconde ne va donc pas sans la première, tandis que la première ne fait qu'autoriser la seconde.

chapters/infrastructure.tex

@@ -1,141 +1,117 @@
 \chapter{Infrastructure et composants}
 
-Pour une mise ne production, le standard \emph{de facto} est le suivant:
-
+Pour une mise ne production, le standard \emph{de facto} est le suivant :
 \begin{itemize}
-\item
-  Nginx comme reverse proxy
-\item
-  HAProxy pour la distribution de charge
-\item
-  Gunicorn ou Uvicorn comme serveur d'application
-\item
-  Supervisor pour le monitoring
-\item
-  PostgreSQL ou MySQL/MariaDB comme bases de données.
-\item
-  Celery et RabbitMQ pour l'exécution de tâches asynchrones
-\item
-  Redis / Memcache pour la mise à en cache (et pour les sessions ? A
-  vérifier).
-\item
-  Sentry, pour le suivi des bugs
+    \item Nginx comme reverse proxy
+    \item HAProxy pour la distribution de charge
+    \item Gunicorn ou Uvicorn comme serveur d'application
+    \item Supervisor pour le monitoring
+    \item PostgreSQL ou MySQL/MariaDB comme bases de données.
+    \item Celery et RabbitMQ pour l'exécution de tâches asynchrones
+    \item Redis / Memcache pour la mise à en cache (et pour les sessions ? A vérifier).
+    \item Sentry, pour le suivi des bugs
 \end{itemize}
 
-Si nous schématisons l'infrastructure et le chemin parcouru par une requête, nous pourrions arriver à la synthèse suivante:
-
+Si nous schématisons l'infrastructure et le chemin parcouru par une requête, nous pourrions arriver à la synthèse suivante :
 \begin{enumerate}
-\item
-  L'utilisateur fait une requête via son navigateur (Firefox ou Chrome)
-\item
-  Le navigateur envoie une requête http, sa version, un verbe (GET,
-  POST, \ldots\hspace{0pt}), un port et éventuellement du contenu
-\item
-  Le firewall du serveur (Debian GNU/Linux, CentOS, ...
-  vérifie si la requête peut être prise en compte
-\item
-  La requête est transmise à l'application qui écoute sur le port
-  (probablement 80 ou 443; et \emph{a priori} Nginx)
-\item
-  Elle est ensuite transmise par socket et est prise en compte par un
-  des \emph{workers} (= un processus Python) instancié par Gunicorn. Si
-  l'un de ces travailleurs venait à planter, il serait automatiquement
-  réinstancié par Supervisord.
-\item
-  Qui la transmet ensuite à l'un de ses \emph{workers} (= un processus
-  Python).
-\item
-  Après exécution, une réponse est renvoyée à l'utilisateur.
+    \item
+        L'utilisateur fait une requête via son navigateur (Firefox ou Chrome)
+    \item
+        Le navigateur envoie une requête http, sa version, un verbe (GET, POST, \ldots\hspace{0pt}), un port et éventuellement du contenu
+    \item
+        Le firewall du serveur (Debian GNU/Linux, CentOS, \ldots~ vérifie si la requête peut être prise en compte
+    \item
+        La requête est transmise à l'application qui écoute sur le port (probablement 80 ou 443; et \emph{a priori} Nginx)
+    \item
+        Elle est ensuite transmise par socket et est prise en compte par un des \emph{workers} (= un processus Python) instancié par Gunicorn.
+        Si l'un de ces travailleurs venait à planter, il serait automatiquement réinstancié par Supervisord.
+    \item
+        Qui la transmet ensuite à l'un de ses \emph{workers} (= un processus Python).
+    \item
+        Après exécution, une réponse est renvoyée à l'utilisateur.
 \end{enumerate}
 
 \includegraphics{images/diagrams/architecture.png}
 
 
 \section{Reverse proxy}
-
-Le principe du \textbf{proxy inverse} est de pouvoir rediriger du trafic entrant vers une application hébergée sur le système. Il serait tout à fait possible de rendre notre application directement accessible depuis l'extérieur, mais le proxy a aussi l'intérêt de pouvoir élever la sécurité du serveur (SSL) et décharger le serveur applicatif grâce à un mécanisme de cache ou en compressant certains résultats \footnote{\url{https://fr.wikipedia.org/wiki/Proxy_inverse}}
+Le principe du \textbf{proxy inverse} est de pouvoir rediriger du trafic entrant vers une application hébergée sur le système.
+Il serait tout à fait possible de rendre notre application directement accessible depuis l'extérieur, mais le proxy a aussi l'intérêt de pouvoir élever la sécurité du serveur (SSL) et décharger le serveur applicatif grâce à un mécanisme de cache ou en compressant certains résultats \footnote{\url{https://fr.wikipedia.org/wiki/Proxy_inverse}}
 
 \section{Load balancer}
+% TODO: à écrire
 
 \section{Workers}
+% TODO: à écrire
 
 \section{Supervision des processus}
+% TODO: à écrire
 
 \section{Bases de données}
+% TODO: à écrire
 
 \section{Tâches asynchrones}
+% TODO: à écrire
 
 \section{Mise en cache}
+% TODO: à écrire
 
 \section{Niveau application}
-
 Au niveau logiciel (la partie mise en subrillance ci-dessus), la requête arrive dans les mains du processus Python, qui doit encore
 
 \begin{enumerate}
-\item
-  effectuer le routage des données,
-\item
-  trouver la bonne fonction à exécuter,
-\item
-  récupérer les données depuis la base de données,
-\item
-  effectuer le rendu ou la conversion des données,
-\item
-  et renvoyer une réponse à l'utilisateur.
+    \item effectuer le routage des données,
+    \item trouver la bonne fonction à exécuter,
+    \item récupérer les données depuis la base de données,
+    \item effectuer le rendu ou la conversion des données,
+    \item et renvoyer une réponse à l'utilisateur.
 \end{enumerate}
 
-Comme nous l'avons vu dans la première partie, Django est un framework complet, intégrant tous les mécanismes nécessaires à la bonne évolution d'une application. Il est possible de démarrer petit, et de suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, d'ajouter un mécanisme de mise en cache, des logiciels de suivi, ...
+Comme nous l'avons vu dans la première partie, Django est un framework complet, intégrant tous les mécanismes nécessaires à la bonne évolution d'une application.
+Il est possible de démarrer petit, et de suivre l'évolution des besoins en fonction de la charge estimée ou ressentie, d'ajouter un mécanisme de mise en cache, des logiciels de suivi, \ldots
+
 
 \section{Supervision globale}
-
-
 \subsection{Journaux}
-
 La structure des niveaux de journaux est essentielle.
 
 \begin{quote}
-When deciding whether a message should be ERROR or WARN, imagine being woken up at 4 a.m. 
-Low printer toner is not an ERROR.
+    When deciding whether a message should be ERROR or WARN, imagine being woken up at 4 a.m.
+    Low printer toner is not an ERROR.
 
----  Dan North former ToughtWorks consultant
+    ---  Dan North former ToughtWorks consultant
 \end{quote}
 
 \begin{itemize}
-\item
-  \textbf{DEBUG}: Il s'agit des informations qui concernent tout ce qui   peut se passer durant l'exécution de l'application. Généralement, ce niveau est désactivé pour une application qui passe en production,
-  sauf s'il est nécessaire d'isoler un comportement en particulier, auquel cas il suffit de le réactiver temporairement.
-\item
-  \textbf{INFO}: Enregistre les actions pilotées par un utilisateur - Démarrage de la transaction de paiement, ...
-\item
-  \textbf{WARN}: Regroupe les informations qui pourraient potentiellement devenir des erreurs.
-\item
-  \textbf{ERROR}: Indique les informations internes - Erreur lors de l'appel d'une API, erreur interne, ...
-\item
-  \textbf{FATAL} (ou \textbf{EXCEPTION}): ... généralement suivie d'une terminaison du programme - Bind raté
-  d'un socket, etc.
+    \item
+        \textbf{DEBUG}: Il s'agit des informations qui concernent tout ce qui peut se passer durant l'exécution de l'application.
+        Généralement, ce niveau est désactivé pour une application qui passe en production, sauf s'il est nécessaire d'isoler un comportement en particulier, auquel cas il suffit de le réactiver temporairement.
+    \item
+        \textbf{INFO} : Enregistre les actions pilotées par un utilisateur - Démarrage de la transaction de paiement, \ldots
+    \item
+        \textbf{WARN} : Regroupe les informations qui pourraient potentiellement devenir des erreurs.
+    \item
+        \textbf{ERROR} : Indique les informations internes - Erreur lors de l'appel d'une API, erreur interne, ...
+    \item
+        \textbf{FATAL} (ou \textbf{EXCEPTION}) : \ldots généralement suivie d'une terminaison du programme - Bind raté d'un socket, etc.
 \end{itemize}
 
-La configuration des \emph{loggers} est relativement simple, un peu plus complexe si nous nous penchons dessus, et franchement complète si nous creusons encore. Il est ainsi possible de définir des formattages,
-gestionnaires (\emph{handlers}) et loggers distincts, en fonction de nos applications.
-
-Sauf que comme nous l'avons vu avec les 12 facteurs, nous devons traiter les informations de notre application comme un flux d'évènements. Il n'est donc pas réellement nécessaire de chipoter la configuration,
-puisque la seule classe qui va réellement nous intéresser concerne les \texttt{StreamHandler}. La configuration que nous allons utiliser est celle-ci:
+La configuration des \emph{loggers} est relativement simple, un peu plus complexe si nous nous penchons dessus, et franchement complète si nous creusons encore.
+Il est ainsi possible de définir des formattages, gestionnaires (\emph{handlers}) et loggers distincts, en fonction de nos applications.
 
+Sauf que comme nous l'avons vu avec les 12 facteurs, nous devons traiter les informations de notre application comme un flux d'évènements.
+Il n'est donc pas réellement nécessaire de chipoter la configuration, puisque la seule classe qui va réellement nous intéresser concerne les \texttt{StreamHandler}.
+La configuration que nous allons utiliser est celle-ci :
 \begin{enumerate}
-\item
-  Formattage: à définir - mais la variante suivante est complète, lisible et pratique:
-  \texttt{\{levelname\}\ \{asctime\}\ \{module\}\ \{process:d\}\ \{thread:d\}\ \{message\}}
-\item
-  Handler: juste un, qui définit un \texttt{StreamHandler}
-\item
-  Logger: pour celui-ci, nous avons besoin d'un niveau (\texttt{level})
-  et de savoir s'il faut propager les informations vers les
-  sous-paquets, auquel cas il nous suffira de fixer la valeur de
-  \texttt{propagate} à \texttt{True}.
+    \item
+        Formattage : à définir - mais la variante suivante est complète, lisible et pratique: \texttt{\{levelname\}\ \{asctime\}\ \{module\}\ \{process:d\}\ \{thread:d\}\ \{message\}}
+    \item
+        Handler : juste un, qui définit un \texttt{StreamHandler}
+    \item
+        Logger : pour celui-ci, nous avons besoin d'un niveau (\texttt{level}) et de savoir s'il faut propager les informations vers les sous-paquets, auquel cas il nous suffira de fixer la valeur de \texttt{propagate} à \texttt{True}.
 \end{enumerate}
 
-Pour utiliser nos loggers, il suffit de copier le petit bout de code suivant:
-
+Pour utiliser nos loggers, il suffit de copier le petit bout de code suivant :
 \begin{minted}{python}
     import logging
 
@@ -143,31 +119,29 @@ Pour utiliser nos loggers, il suffit de copier le petit bout de code suivant:
     logger.debug('helloworld')
 \end{minted}
 
-
-\href{https://docs.djangoproject.com/en/stable/topics/logging/\#examples}{Par
-exemples}.
-
+\href{https://docs.djangoproject.com/en/stable/topics/logging/\#examples}{Par exemples}.
 
 \begin{enumerate}
     \def\labelenumi{\arabic{enumi}.}
     \item
-      Sentry via sentry\_sdk
+        Sentry via sentry\_sdk
     \item
-      Nagios
+        Nagios
     \item
-      LibreNMS
+        LibreNMS
     \item
-      Zabbix
+        Zabbix
 \end{enumerate}
-    
-Il existe également \href{https://munin-monitoring.org}{Munin},
-\href{https://www.elastic.co}{Logstash, ElasticSearch et Kibana
-(ELK-Stack)} ou \href{https://www.fluentd.org}{Fluentd}.
+
+Il existe également \href{https://munin-monitoring.org}{Munin}, \href{https://www.elastic.co}{Logstash, ElasticSearch et Kibana (ELK-Stack)} ou \href{https://www.fluentd.org}{Fluentd}.
 
 
 \subsection{Zabbix, Nagios, ...}
+% TODO: a écrire
 
 \subsection{Sentry}
+% TODO: a écrire
 
 \subsection{Greylog}
+% TODO: a écrire
 

chapters/introduction.tex

@@ -1,20 +1,15 @@
 \chapter{Introduction}
 
 \begin{quote}
-The only way to go fast, is to go well
+    The only way to go fast, is to go well
 
----  Robert C. Martin
+    ---  Robert C. Martin
 \end{quote}
 
-Nous n'allons pas vous mentir: il existe énormément de tutoriaux très
-bien réalisés sur "\emph{Comment réaliser une application Django}" et
-autres "\emph{Déployer votre code en 2 minutes}". Nous nous disions
-juste que ces tutoriaux restaient relativement haut-niveaux et se
-limitaient à un contexte donné, sans réellement préparer à la
-maintenance et au suivi de l'application nouvellement développée.
-
-Les quelques idées ci-dessous  de jeter les bases d'un bon développement, en 
+Nous n'allons pas vous mentir: il existe énormément de tutoriaux très bien réalisés sur "\emph{Comment réaliser une application Django}" et autres "\emph{Déployer votre code en 2 minutes}".
+Nous nous disions juste que ces tutoriaux restaient relativement haut-niveaux et se limitaient à un contexte donné, sans réellement préparer à la maintenance et au suivi de l'application nouvellement développée.
 
+Les quelques idées ci-dessous  de jeter les bases d'un bon développement, en
 \begin{itemize}
 	\item Survolant l'ensemble des lignes directrices reconnues
 	\item Maintenant une bonne qualité de code
@@ -23,163 +18,111 @@ Les quelques idées ci-dessous  de jeter les bases d'un bon développement, en
 	\item Permettant à quiconque de reprendre ce qui aura déjà été écrit.
 \end{itemize}
 
-Ces idées ne s'appliquent pas uniquement à Django et à son cadre de travail, ni même au langage Python en particulier. 
+Ces idées ne s'appliquent pas uniquement à Django et à son cadre de travail, ni même au langage Python en particulier.
 Ces deux sujets sont cependant de bons candidats et leur utilisation et cadre de travail sont bien définis, documentés et flexibles.
 
-Django se présente comme un \emph{Framework Web pour perfectionnistes
-ayant des deadlines} \cite{django} et suit ces quelques principes
-\cite{django_design_philosophies}:
+Django se présente comme un \emph{Framework Web pour perfectionnistes ayant des deadlines} \cite{django} et suit ces quelques principes \cite{django_design_philosophies}:
 
 \begin{itemize}
-\item
-	\textbf{Faible couplage et forte cohésion}, pour que chaque composant dispose de son indépendance, en n'ayant aucune connaissance des autres couches applicatives. Ainsi, le moteur de rendu ne connait absolument rien à l'existence du moteur de base de données, tout comme le système de vues ne sait pas quel moteur de rendu est utilisé.
-\item
-	\textbf{Plus de fonctionnalités avec moins de code}: chaque application Django
-  doit utiliser le moins de code possible
-\item
-	\textbf{\emph{Don't repeat yourself}}, chaque concept ou morceau de code ne
-  doit être présent qu'à un et un seul endroit de vos dépôts.
-\item
-	\textbf{Rapidité du développement}, en masquant les aspects fastidieux du
-  développement web actuel
+    \item
+        \textbf{Faible couplage et forte cohésion}, pour que chaque composant dispose de son indépendance, en n'ayant aucune connaissance des autres couches applicatives.
+        Ainsi, le moteur de rendu ne connait absolument rien à l'existence du moteur de base de données, tout comme le système de vues ne sait pas quel moteur de rendu est utilisé.
+    \item
+        \textbf{Plus de fonctionnalités avec moins de code}: chaque application Django doit utiliser le moins de code possible
+    \item
+        \textbf{\emph{Don't repeat yourself}}, chaque concept ou morceau de code ne doit être présent qu'à un et un seul endroit de vos dépôts.
+    \item
+        \textbf{Rapidité du développement}, en masquant les aspects fastidieux du développement web actuel
 \end{itemize}
 
-Mis côte à côte, le suivi de ces principes permet une bonne stabilité du
-projet à moyen et long terme.
+Mis côte à côte, le suivi de ces principes permet une bonne stabilité du projet à moyen et long terme.
 
-Sans être parfait, Django offre une énorme flexibilité qui permet de conserver un maximum d'options ouvertes et de facilement expérimenter différentes pistes, jusqu'au moment de prendre une vraie décision. 
-Pour la (grande) majorité des problèmes rencontrés lors du développement d'une application Web, Django proposera une solution pragmatique, compréhensible et facile à mettre en place: pour tout problème communément connu, vous disposerez d'une solution logique. 
+Sans être parfait, Django offre une énorme flexibilité qui permet de conserver un maximum d'options ouvertes et de facilement expérimenter différentes pistes, jusqu'au moment de prendre une vraie décision.
+Pour la (grande) majorité des problèmes rencontrés lors du développement d'une application Web, Django proposera une solution pragmatique, compréhensible et facile à mettre en place: pour tout problème communément connu, vous disposerez d'une solution logique.
 
 Tout pour plaire à n'importe quel directeur IT.
 
-\textbf{Dans la première partie}, nous verrons comment partir d'un
-environnement sain, comment le configurer correctement, comment
-installer Django de manière isolée et comment démarrer un nouveau
-projet. Nous verrons rapidement comment gérer les dépendances, les
-versions et comment appliquer et suivre un score de qualité de notre
-code. Ces quelques points pourront être appliqués pour n'importe quel
-langage ou cadre de travail. Nous verrons aussi que la configuration
-proposée par défaut par le framework n'est pas idéale dans la majorité
-des cas.
+\textbf{Dans la première partie}, nous verrons comment partir d'un environnement sain, comment le configurer correctement, comment installer Django de manière isolée et comment démarrer un nouveau projet.
+Nous verrons rapidement comment gérer les dépendances, les versions et comment appliquer et suivre un score de qualité de notre code.
+Ces quelques points pourront être appliqués pour n'importe quel langage ou cadre de travail.
+Nous verrons aussi que la configuration proposée par défaut par le framework n'est pas idéale dans la majorité des cas.
 
-Pour cela, nous présenterons différents outils, la rédaction de tests
-unitaires et d'intégration pour limiter les régressions, les règles de
-nomenclature et de contrôle du contenu, comment partir d'un squelette
-plus complet, ainsi que les bonnes étapes à suivre pour arriver à un
-déploiement rapide et fonctionnel avec peu d'efforts.
+Pour cela, nous présenterons différents outils, la rédaction de tests unitaires et d'intégration pour limiter les régressions, les règles de nomenclature et de contrôle du contenu, comment partir d'un squelette plus complet, ainsi que les bonnes étapes à suivre pour arriver à un déploiement rapide et fonctionnel avec peu d'efforts.
 
-A la fin de cette partie, vous disposerez d'un code propre et d'un
-projet fonctionnel, bien qu'encore un peu inutile.
+A la fin de cette partie, vous disposerez d'un code propre et d'un projet fonctionnel, bien qu'encore un peu inutile.
 
-textbf{Dans la deuxième partie}, nous aborderons les grands principes
-de modélisation, en suivant les lignes de conduites du cadre de travail.
-Nous aborderons les concepts clés qui permettent à une application de
-rester maintenable, les formulaires, leurs validations, comment gérer
-les données en entrée, les migrations de données et l'administration.
+textbf{Dans la deuxième partie}, nous aborderons les grands principes de modélisation, en suivant les lignes de conduites du cadre de travail.
+Nous aborderons les concepts clés qui permettent à une application de rester maintenable, les formulaires, leurs validations, comment gérer les données en entrée, les migrations de données et l'administration.
 
-\textbf{Dans la troisième partie}, nous détaillerons précisément les
-étapes de déploiement, avec la description et la configuration de
-l'infrastructure, des exemples concrets de mise à disposition sur deux
-distributions principales (Debian et CentOS), sur une \emph{*Plateform
-as a Service*}, ainsi que l'utilisation de Docker et Docker-Compose.
+\textbf{Dans la troisième partie}, nous détaillerons précisément les étapes de déploiement, avec la description et la configuration de l'infrastructure, des exemples concrets de mise à disposition sur deux distributions principales (Debian et CentOS), sur une \emph{*Plateform as a Service*}, ainsi que l'utilisation de Docker et Docker-Compose.
 
-Nous aborderons également la supervision et la mise à jour d'une
-application existante, en respectant les bonnes pratiques
-d'administration système.
+Nous aborderons également la supervision et la mise à jour d'une application existante, en respectant les bonnes pratiques d'administration système.
 
-\textbf{Dans la quatrième partie}, nous aborderons les architectures
-typées \emph{entreprise}, les services et les différentes manières de
-structurer notre application pour faciliter sa gestion et sa
-maintenance, tout en décrivant différents types de scénarii, en fonction
-des consommateurs de données.
+\textbf{Dans la quatrième partie}, nous aborderons les architectures typées \emph{entreprise}, les services et les différentes manières de structurer notre application pour faciliter sa gestion et sa maintenance, tout en décrivant différents types de scénarii, en fonction des consommateurs de données.
 
-\textbf{Dans la cinquième partie}, nous mettrons ces concepts en
-pratique en présentant le développement en pratique de deux
-applications, avec la description de problèmes rencontrés et la solution
-qui a été choisie: définition des tables, gestion des utilisateurs,
-\ldots\hspace{0pt} et mise à disposition.
+\textbf{Dans la cinquième partie}, nous mettrons ces concepts en pratique en présentant le développement en pratique de deux applications, avec la description de problèmes rencontrés et la solution qui a été choisie: définition des tables, gestion des utilisateurs, \ldots\hspace{0pt} et mise à disposition.
 
 \subsection{Pour qui ?}
 
-Avant tout, pour moi. Comme le disait le Pr Richard Feynman: "\emph{Si
-vous ne savez pas expliquer quelque chose simplement, c'est que vous ne
-l'avez pas compris}". \footnote{Et comme l'ajoutait Aurélie Jean dans de
-  L'autre côté de la machine: \emph{"Si personne ne vous pose de
-  questions suite à votre explication, c'est que vous n'avez pas été
-  suffisamment clair !"} \cite{other_side}}
+Avant tout, pour moi.
+Comme le disait le Pr Richard Feynman: "\emph{Si vous ne savez pas expliquer quelque chose simplement, c'est que vous ne l'avez pas compris}".
+\footnote{Et comme l'ajoutait Aurélie Jean dans de L'autre côté de la machine: \emph{"Si personne ne vous pose de questions suite à votre explication, c'est que vous n'avez pas été suffisamment clair !"} \cite{other_side}}
 
-Ce livre s'adresse autant au néophyte qui souhaite se lancer dans le
-développement Web qu'à l'artisan qui a besoin d'un aide-mémoire et qui
-ne se rappelle plus toujours du bon ordre des paramètres, ou à l'expert
-qui souhaiterait avoir un aperçu d'une autre technologie que son domaine
-privilégié de compétences.
+Ce livre s'adresse autant au néophyte qui souhaite se lancer dans le développement Web qu'à l'artisan qui a besoin d'un aide-mémoire et qui ne se rappelle plus toujours du bon ordre des paramètres, ou à l'expert qui souhaiterait avoir un aperçu d'une autre technologie que son domaine privilégié de compétences.
 
-Beaucoup de concepts présentés peuvent être oubliés ou restés inconnus
-jusqu'au moment où ils seront réellement nécessaires. A ce moment-là,
-pour peu que votre mémoire ait déjà entraperçu le terme, il vous sera
-plus facile d'y revenir et de l'appliquer.
+Beaucoup de concepts présentés peuvent être oubliés ou restés inconnus jusqu'au moment où ils seront réellement nécessaires.
+A ce moment-là, pour peu que votre mémoire ait déjà entraperçu le terme, il vous sera plus facile d'y revenir et de l'appliquer.
 
 \subsection{Pour aller plus loin}
 
-Il existe énormément de ressources, autant spécifiques à Django que plus
-généralistes. Il ne sera pas possible de toutes les détailler; faites un
-tour sur
+Il existe énormément de ressources, autant spécifiques à Django que plus généralistes.
+Il ne sera pas possible de toutes les détailler; faites un tour sur
 
 \begin{itemize}
-\item
-  \url{https://duckduckgo.com},
-\item
-  \url{https://stackoverflow.com},
-\item
-  \url{https://ycombinator.com},
-\item
-  \url{https://lobste.rs/},
-\item
-  \url{https://lecourrierduhacker.com/}
-\item
-  ou \url{https://www.djangoproject.com/}.
+    \item \url{https://duckduckgo.com},
+    \item \url{https://stackoverflow.com},
+    \item \url{https://ycombinator.com},
+    \item \url{https://lobste.rs/},
+    \item \url{https://lecourrierduhacker.com/}
+    \item ou \url{https://www.djangoproject.com/}.
 \end{itemize}
 
-Restez curieux, ne vous enclavez pas dans une technologie en particulier
-et gardez une bonne ouverture d'esprit.
+Restez curieux, ne vous enclavez pas dans une technologie en particulie et gardez une bonne ouverture d'esprit.
 
 \subsection{Conventions}
 
 Les notes indiquent des anecdotes.
-Les conseils indiquent des éléments utiles, mais pas spécialement
-indispensables.
+Les conseils indiquent des éléments utiles, mais pas spécialemen indispensables.
 
 Les notes importantes indiquent des éléments à retenir.
 
-Ces éléments indiquent des points d'attention. Les retenir vous fera
-gagner du temps en débuggage.
+Ces éléments indiquent des points d'attention.
+Les retenir vous fer gagner du temps en débuggage.
 
-Les avertissements indiquent un (potentiel) danger ou des éléments
-pouvant amener des conséquences pas spécialement sympathiques.
+Les avertissements indiquent un (potentiel) danger ou des élément pouvant amener des conséquences pas spécialement sympathiques.
 
 Les morceaux de code source seront présentés de la manière suivante:
 
 \begin{listing}[htbp]
-        \begin{minted}{Python}
+    \begin{minted}{Python}
         # <folder>/<fichier>.<extension>
 
         def function(param):
-                """
-                """
-                callback()
-        \end{minted}
+            """
+            """
+            callback()
+    \end{minted}
 \end{listing}
 
 Chaque extrait de code reprendra
-
 \begin{itemize}
-        \item l'emplacement du fichier, présenté sous forme de commentaire (ligne 1),
-        \item Des commentaires au niveau des fonctions et méthodes, si cela s'avère nécessaire
-        \item Un surlignage sur les parties importantes ou récemment modifiées
+    \item l'emplacement du fichier, présenté sous forme de commentaire (ligne 1),
+    \item Des commentaires au niveau des fonctions et méthodes, si cela s'avère nécessaire
+    \item Un surlignage sur les parties importantes ou récemment modifiées
 \end{itemize}
 
-La plupart des commandes qui seront présentées dans ce livre le seront depuis un shell sous GNU/Linux. 
+La plupart des commandes qui seront présentées dans ce livre le seront depuis un shell sous GNU/Linux.
 Certaines d'entre elles pourraient devoir être adaptées si vous utilisez un autre système d'exploitation (macOS) ou n'importe quelle autre grosse bouse commerciale.
 
-Les morceaux de code que vous trouverez ci-dessous seront développés pour Python3.9+ et Django 3.2+. 
+Les morceaux de code que vous trouverez ci-dessous seront développés pour Python3.9+ et Django 3.2+.
 Ils nécessiteront peut-être quelques adaptations pour fonctionner sur une version antérieure.

chapters/licence.tex

@@ -1,31 +1,27 @@
 \chapter{Licence}
 
-Ce travail est licencié sous Attribution-NonCommercial 4.0 International
-Attribution-NonCommercial 4.0 International
+Ce travail est licencié sous Attribution-NonCommercial 4.0 International Attribution-NonCommercial 4.0 International
 
-This license requires that reusers give credit to the creator. It allows
-reusers to distribute, remix, adapt, and build upon the material in any
-medium or format, for noncommercial purposes only.
-
-You are free to:
+This license requires that reusers give credit to the creator.
+It allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, for noncommercial purposes only.
 
+You are free to :
 \begin{itemize}
-	\item \textbf{Share} — copy and redistribute the material in any medium or format 
-	\item \textbf{Adapt} — remix, transform, and build upon the material 
+	\item \textbf{Share} — copy and redistribute the material in any medium or format
+	\item \textbf{Adapt} — remix, transform, and build upon the material
 \end{itemize}
 
 Under the following terms:
 
 \begin{itemize}
-\item
-  \textbf{Attribution}: You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. 
-\item
-  \textbf{NC}: Only noncommercial use of your work is permitted.
-  Noncommercial means not primarily intended for or directed towards
-  commercial advantage or monetary compensation.
+    \item
+        \textbf{Attribution}: You must give appropriate credit, provide a link to the license, and indicate if changes were made.
+        You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
+    \item
+        \textbf{NC}: Only noncommercial use of your work is permitted.
+        Noncommercial means not primarily intended for or directed towards commercial advantage or monetary compensation.
 \end{itemize}
 
 \url{https://creativecommons.org/licenses/by-nc/4.0/}
 
-La seule exception concerne les morceaux de code (non attribués),
-disponibles sous licence \href{https://mit-license.org/}{MIT}.
+La seule exception concerne les morceaux de code (non attribués), disponibles sous licence \href{https://mit-license.org/}{MIT}.

chapters/maintenability.tex

@@ -1,90 +1,56 @@
 \chapter{Fiabilité, évolutivité et maintenabilité}
 
 \begin{quote}
-The primary cost of maintenance is in spelunking and risk
-        \cite[139]{clean_architecture}
+    The primary cost of maintenance is in spelunking and risk\cite[139]{clean_architecture}
 
----  Robert C. Martin
+    ---  Robert C. Martin
 \end{quote}
 
-Pour la méthode de travail et de développement, nous allons nous baser
-sur les \href{https://12factor.net/fr/}{The Twelve-factor App} - ou plus
-simplement les \textbf{12 facteurs}. 
-Suivre ces concepts permet de:
-
+Pour la méthode de travail et de développement, nous allons nous baser sur les \href{https://12factor.net/fr/}{The Twelve-factor App} - ou plus simplement les \textbf{12 facteurs}.
+Suivre ces concepts permet de :
 \begin{enumerate}
-\item
-  \textbf{Faciliter la mise en place de phases d'automatisation}; plus
-  concrètement, de faciliter les mises à jour applicatives, simplifier
-  la gestion de l'hôte qui héberge l'application ou les services, 
-  diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le
-  projet dans un processus
-  d'\href{https://en.wikipedia.org/wiki/Continuous_integration}{intégration
-  continue} ou
-  \href{https://en.wikipedia.org/wiki/Continuous_deployment}{déploiement
-  continu}
-\item
-  \textbf{Faciliter l'intégration de nouveaux développeurs dans l'équipe ou de
-  personnes souhaitant rejoindre le projet}, dans la mesure où la construction d'un nouvel environnement sera grandement facilitée.
-\item
-  \textbf{Minimiser les divergences entre les différents environnemens}
-  sur lesquels un projet pourrait être déployé, pour éviter de découvrir un bogue sur l'environnement de production qui serait impossible à reproduire ailleurs, simplement parce qu'un des composants varierait
-\item
-  \textbf{Augmenter l'agilité générale du projet}, en permettant une
-  meilleure évolutivité architecturale et une meilleure mise à l'échelle.  
+    \item
+    \textbf{Faciliter la mise en place de phases d'automatisation}; plus concrètement, de faciliter les mises à jour applicatives, simplifier la gestion de l'hôte qui héberge l'application ou les services, diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le projet dans un processus d'\href{https://en.wikipedia.org/wiki/Continuous_integration}{intégration continue} ou \href{https://en.wikipedia.org/wiki/Continuous_deployment}{déploiement continu}
+    \item
+    \textbf{Faciliter l'intégration de nouveaux développeurs dans l'équipe ou de personnes souhaitant rejoindre le projet}, dans la mesure où la construction d'un nouvel environnement sera grandement facilitée.
+    \item
+    \textbf{Minimiser les divergences entre les différents environnemens} sur lesquels un projet pourrait être déployé, pour éviter de découvrir un bogue sur l'environnement de production qui serait impossible à reproduire ailleurs, simplement parce qu'un des composants varierait
+    \item
+    \textbf{Augmenter l'agilité générale du projet}, en permettant une meilleure évolutivité architecturale et une meilleure mise à l'échelle.
 \end{enumerate}
 
-En pratique, les points ci-dessus permettront de gagner un temps précieux à la construction d'un nouvel environnement - qu'il soit sur la machine du petit nouveau dans l'équipe, sur un serveur Azure/Heroku/Digital Ocean ou votre nouveau
-Raspberry Pi Zéro planqué à la cave - et vous feront gagner un temps
-précieux.
+En pratique, les points ci-dessus permettront de gagner un temps précieux à la construction d'un nouvel environnement - qu'il soit sur la machine du petit nouveau dans l'équipe, sur un serveur Azure/Heroku/Digital Ocean ou votre nouveau Raspberry Pi Zéro planqué à la cave - et vous feront gagner un temps précieux.
 
-Pour reprendre plus spécifiquement les différentes idées derrière
-cette méthode, nous avons:
+Pour reprendre plus spécifiquement les différentes idées derrière cette méthode, nous avons:
 
 \section{Une base de code unique, suivie par un contrôle de versions}
 
-Chaque déploiement de l'application, et quel que soit l'environnement ciblé, se basera sur une source unique, afin de minimiser les différences que l'on pourrait trouver entre deux environnements d'un même projet. 
-Git est reconnu dans l'industrie comme standard des systèmes de contrôles de versions, malgré une courbe d'apprentissage assez ardue. 
+Chaque déploiement de l'application, et quel que soit l'environnement ciblé, se basera sur une source unique, afin de minimiser les différences que l'on pourrait trouver entre deux environnements d'un même projet.
+Git est reconnu dans l'industrie comme standard des systèmes de contrôles de versions, malgré une courbe d'apprentissage assez ardue.
 Comme dépôt, nous pourrons par exemple utiliser GitHub, Gitea ou Gitlab, suivant que vous ayez besoin d'une plateforme centralisée, propriétaire, payante ou auto-hébergée. \index{Git} \index{Github} \index{Gitlab} \index{Gitea}
 
 \includegraphics{images/diagrams/12-factors-1.png}
 
-Comme l'explique Eran Messeri, ingénieur dans le groupe Google Developer
-Infrastructure: "Un des avantages d'utiliser un dépôt unique de sources,
-est qu'il permet un accès facile et rapide à la forme la plus à jour du
-code, sans aucun besoin de coordination. \cite[pp. 288-298]{devops_handbook}.
-Ce cépôt n'est pas uniquement destiné à hébergé le code source, mais
-également à d'autres artefacts et autres formes de connaissance:
-
+Comme l'explique Eran Messeri, ingénieur dans le groupe Google Developer Infrastructure: "Un des avantages d'utiliser un dépôt unique de sources, est qu'il permet un accès facile et rapide à la forme la plus à jour du code, sans aucun besoin de coordination. \cite[pp. 288-298]{devops_handbook}.
+Ce cépôt n'est pas uniquement destiné à hébergé le code source, mais également à d'autres artefacts et autres formes de connaissance :
 \begin{itemize}
-\item
-  Standards de configuration (Chef recipes, Puppet manifests, ...
-\item
-  Outils de déploiement
-\item
-  Standards de tests, y compris tout ce qui touche à la sécurité
-\item
-  Outils de déploiement de pipeline
-\item
-  Outils d'analyse et de monitoring
-\item
-  Tutoriaux
+    \item Standards de configuration (Chef recipes, Puppet manifests, \ldots
+    \item Outils de déploiement
+    \item Standards de tests, y compris tout ce qui touche à la sécurité
+    \item Outils de déploiement de pipeline
+    \item Outils d'analyse et de monitoring
+    \item Tutoriaux
 \end{itemize}
 
 \section{Déclaration explicite et isolation des dépendances}
 
-Chaque installation ou configuration doit toujours être faite de la même
-manière, et doit pouvoir être répétée quel que soit l'environnement
-cible.
-Ceci permet d'éviter que l'application n'utilise une dépendance qui ne soit
-déjà installée sur un des sytèmes de développement, et qu'elle soit
-difficile, voire impossible, à répercuter sur un autre environnement.
-Dans le cas de Python, cela pourra être fait au travers de
-\href{https://pypi.org/project/pip/}{PIP - Package Installer for Python}
-ou \href{https://python-poetry.org/}{Poetry}.
-La majorité des langages moderners proposent des mécanismes similaires (\href{https://rubygems.org/}{Gem} pour Ruby, \href{https://www.npmjs.com/}{NPM} pour NodeJS, ...)
+Chaque installation ou configuration doit toujours être faite de la même manière, et doit pouvoir être répétée quel que soit l'environnement cible.
+Ceci permet d'éviter que l'application n'utilise une dépendance qui ne soit déjà installée sur un des sytèmes de développement, et qu'elle soit difficile, voire impossible, à répercuter sur un autre environnement.
+Dans le cas de Python, cela pourra être fait au travers de \href{https://pypi.org/project/pip/}{PIP - Package Installer for Python} ou \href{https://python-poetry.org/}{Poetry}.
+La majorité des langages moderners proposent des mécanismes similaires (\href{https://rubygems.org/}{Gem} pour Ruby, \href{https://www.npmjs.com/}{NPM} pour NodeJS, \ldots)
 
-Dans tous les cas, chaque application doit disposer d'un environnement sain, qui lui est assigné. Vu le peu de ressources que cela coûte, il ne faut pas s'en priver.
+Dans tous les cas, chaque application doit disposer d'un environnement sain, qui lui est assigné.
+Vu le peu de ressources que cela coûte, il ne faut pas s'en priver.
 
 Chaque dépendance devra déclarer et épingler dans un fichier la version nécessaire.
 Lors de la création d'un nouvel environnement vierge, il suffira d'utiliser ce
@@ -92,108 +58,81 @@ fichier comme paramètre afin d'installer les prérequis au bon
 fonctionnement de notre application.
 Ceci autorise une reproductibilité quasi parfaite de l'environnement.
 
-Il est important de bien "épingler" les versions liées aux dépendances
-de l'application. Cela peut éviter des effets de bord comme une nouvelle
-version d'une librairie dans laquelle un bug aurait pu avoir été
-introduit. Parce qu'il arrive que ce genre de problème apparaisse, et
-lorsque ce sera le cas, ce sera systématiquement au mauvais moment \footnote{Le paquet PyLint dépend par exemple d'Astroid; \href{https://github.com/PyCQA/pylint-django/issues/343}{en janvier 2022}, ce dernier a été mis à jour sans respecter le principe de versions sémantiques et introduisant une régression. PyLint spécifiait que sa dépendance avec Astroid devait respecter une version ~2.9. Lors de sa mise à jour en 2.9.1, Astroid a introduit un changement majeur, qui faisait planter Pylint. L'épinglage explicite aurait pu éviter ceci.}
+Il est important de bien "épingler" les versions liées aux dépendances de l'application.
+Cela peut éviter des effets de bord comme une nouvelle version d'une librairie dans laquelle un bug aurait pu avoir été introduit.
+Parce qu'il arrive que ce genre de problème apparaisse, et lorsque ce sera le cas, ce sera systématiquement au mauvais moment \footnote{Le paquet PyLint dépend par exemple d'Astroid; \href{https://github.com/PyCQA/pylint-django/issues/343}{en janvier 2022}, ce dernier a été mis à jour sans respecter le principe de versions sémantiques et introduisant une régression.
+PyLint spécifiait que sa dépendance avec Astroid devait respecter une version ~2.9.
+Lors de sa mise à jour en 2.9.1, Astroid a introduit un changement majeur, qui faisait planter Pylint.
+L'épinglage explicite aurait pu éviter ceci.}
+
 
 \section{Configuration applicative}
 
-Il faut éviter d'avoir à recompiler/redéployer l'application simplement parce
-que:
-
+Il faut éviter d'avoir à recompiler/redéployer l'application simplement parce que:
 \begin{enumerate}
-\item
-  l'adresse du serveur de messagerie a été modifiée,
-\item
-  un protocole a changé en cours de route
-\item
-  la base de données a été déplacée
-\item
-  ...
+    \item l'adresse du serveur de messagerie a été modifiée,
+    \item un protocole a changé en cours de route
+    \item la base de données a été déplacée
+    \item \ldots
 \end{enumerate}
 
-En pratique, toute information susceptible d'évoluer ou de changer (un seuil, une ressource externe, un couple utilisateur/mot de passe, ...) doit se trouver dans un fichier ou dans une variable d'environnement, et doit être facilement modifiable. 
+En pratique, toute information susceptible d'évoluer ou de changer (un seuil, une ressource externe, un couple utilisateur/mot de passe, \ldots) doit se trouver dans un fichier ou dans une variable d'environnement, et doit être facilement modifiable.
 
 Ceci permet de paramétrer facilement un environnement (par exemple, un container), simplement en modifiant une variable de configuration qui spécifierait la base de données sur laquelle l'application devra se connecter.
 
-Toute clé de configuration (nom du serveur de base de données, adresse d'un service Web externe, clé d'API pour l'interrogation d'une ressource, ...) sera définie directement au niveau de l'hôte - à aucun moment, nous ne devons trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d'évoluer, écrite en dur dans le code. \footnote{Ainsi, nous pourrions faire une \href{https://github.com/search?q=filenamefilename:.env DB_USERNAME&type=Code}{recherche sur Github} pour retrouver certaines variables d'environnement qui auraient été laissées en dur dans le code source de certains projets. Le \href{https://github.com/techgaun/github-dorks}{dépôt suivant} liste quelques idées de variables à rechercher...}.
+Toute clé de configuration (nom du serveur de base de données, adresse d'un service Web externe, clé d'API pour l'interrogation d'une ressource, \ldots) sera définie directement au niveau de l'hôte - à aucun moment, nous ne devons trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d'évoluer, écrite en dur dans le code.\footnote{Ainsi, nous pourrions faire une \href{https://github.com/search?q=filenamefilename:.env DB_USERNAME&type=Code}{recherche sur Github} pour retrouver certaines variables d'environnement qui auraient été laissées en dur dans le code source de certains projets.
+Le \href{https://github.com/techgaun/github-dorks}{dépôt suivant} liste quelques idées de variables à rechercher\ldots}.
 
-Au moment de développer une nouvelle fonctionnalité, réfléchissez si
-l'un des paramètres utilisés risquerait de subir une modification ou s'il concerne un principe de sécurité: ce composant peut concerner une nouvelle chaîne de connexion, un point de terminaison nécessaire à télécharger des données officielles ou un chemin vers un répertoire partagé pour y déposer un fichier.
+Au moment de développer une nouvelle fonctionnalité, réfléchissez si l'un des paramètres utilisés risquerait de subir une modification ou s'il concerne un principe de sécurité : ce composant peut concerner une nouvelle chaîne de connexion, un point de terminaison nécessaire à télécharger des données officielles ou un chemin vers un répertoire partagé pour y déposer un fichier.
 
 Le risque est de se retrouver avec une liste colossale de paramètres; pensez à leur assigner une variable par défaut.
 Par exemple, Gitea expose \href{https://docs.gitea.io/en-us/config-cheat-sheet/}{la liste suivante de paramètres}; il serait impossible de tous les configurer un à un avant de pouvoir démarrer une instance.
 
 \section{Ressources externes}
 
-Nous parlons de bases de données, de services de mise en cache, d'API
-externes, ... L'application doit être capable d'effectuer
-des changements au niveau de ces ressources sans que son code ne soit
-modifié. Nous parlons alors de \textbf{ressources attachées}, dont la
-présence est nécessaire au bon fonctionnement de l'application, mais
-pour lesquelles le \textbf{type} n'est pas obligatoirement défini.
+Nous parlons de bases de données, de services de mise en cache, d'API externes, \ldots
+L'application doit être capable d'effectuer des changements au niveau de ces ressources sans que son code ne soit modifié.
+Nous parlons alors de \textbf{ressources attachées}, dont la présence est nécessaire au bon fonctionnement de l'application, mais pour lesquelles le \textbf{type} n'est pas obligatoirement défini.
 
-Nous voulons par exemple "une base de données" et "une mémoire cache",
-et pas "une base MariaDB et une instance Memcached". De cette manière,
-les ressources peuvent être attachées et détachées d'un déploiement à la
-volée.
+Nous voulons par exemple "une base de données" et "une mémoire cache", et pas "une base MariaDB et une instance Memcached".
+De cette manière, les ressources peuvent être attachées et détachées d'un déploiement à la volée.
 
-Si une base de données ne fonctionne pas correctement (problème matériel
-?), l'administrateur pourrait simplement restaurer un nouveau serveur à
-partir d'une précédente sauvegarde, et l'attacher à l'application sans
-que le code source ne soit modifié. une solution consiste à passer
-toutes ces informations (nom du serveur et type de base de données, clé
-d'authentification, ... directement \emph{via} des
-variables d'environnement.
+Si une base de données ne fonctionne pas correctement (problème matériel ?), l'administrateur pourrait simplement restaurer un nouveau serveur à partir d'une précédente sauvegarde, et l'attacher à l'application sans que le code source ne soit modifié.
+Une solution consiste à passer toutes ces informations (nom du serveur et type de base de données, clé d'authentification, \ldots directement \emph{via} des variables d'environnement.
 
 \includegraphics{images/12factors/attached-resources.png}
 
-Nous serons ravis de pouvoir simplement modifier une chaîne
-\texttt{sqlite:////tmp/my-tmp-sqlite.db} en
-\texttt{psql://user:pass@127.0.0.1:8458/db} lorsque ce sera nécessaire,
-sans avoir à recompiler ou redéployer les modifications.
+Nous serons ravis de pouvoir simplement modifier une chaîne \texttt{sqlite:////tmp/my-tmp-sqlite.db} en \texttt{psql://user:pass@127.0.0.1:8458/db} lorsque ce sera nécessaire, sans avoir à recompiler ou redéployer les modifications.
 Ces ressources sont donc spécifiés grâce à des variables d'environnement, et chacune d'entre elles dispose également d'un \textbf{type}, afin de profiter d'une correspondance dynamique entre un moteur d'exécution et une information de configuration.
 
 \section{Séparation des phases de construction}
 
 \begin{enumerate}
-\item
-  La \textbf{construction} (\emph{build}) convertit un code source en un
-  ensemble de fichiers exécutables, associé à une version et à une
-  transaction dans le système de gestion de sources.
-\item
-  La \textbf{mise à disposition} (\emph{release}) associe cet ensemble à
-  une configuration prête à être exécutée,
-\item
-  tandis que la phase d'\textbf{exécution} (\emph{run}) démarre les
-  processus nécessaires au bon fonctionnement de l'application.
+    \item La \textbf{construction} (\emph{build}) convertit un code source en un ensemble de fichiers exécutables, associé à une version et à une transaction dans le système de gestion de sources.
+    \item La \textbf{mise à disposition} (\emph{release}) associe cet ensemble à une configuration prête à être exécutée,
+    \item tandis que la phase d'\textbf{exécution} (\emph{run}) démarre les processus nécessaires au bon fonctionnement de l'application.
 \end{enumerate}
 
 \includegraphics{images/12factors/release.png}
 
 Parmi les solutions possibles, nous pourrions nous pourrions nous baser
-sur les \emph{releases} de Gitea, sur un serveur d'artefacts (\href{https://fr.wikipedia.org/wiki/Capistrano_(logiciel)}{Capistrano}), voire directement au niveau de forge logicielle (Gitea, Github, Gitlab, ...).
+sur les \emph{releases} de Gitea, sur un serveur d'artefacts (\href{https://fr.wikipedia.org/wiki/Capistrano_(logiciel)}{Capistrano}), voire directement au niveau de forge logicielle (Gitea, Github, Gitlab, \ldots).
 
 \section{Mémoire des processus d'exécution}
 
 Toute information stockée en mémoire ou sur disque ne doit pas altérer le comportement futur de l'application, par exemple après un redémarrage non souhaité.
 Dit autrement, l'exécution de l'application ne doit pas dépendre de la présence d'une information stockée en mémoire ou sur disque.
 
-Pratiquement, si l'application devait rencontrer un problème, il est nécessaire qu'elle puisse redémarrer rapidement, éventuellement en étant déployée sur un autre serveur - par exemple suite à un problème matériel. 
-Toute information stockée physiquement sur le premier hôte durant son exécution sur le premier hôte, puisqu'elle pourra avoir été entretemps perdue. 
+Pratiquement, si l'application devait rencontrer un problème, il est nécessaire qu'elle puisse redémarrer rapidement, éventuellement en étant déployée sur un autre serveur - par exemple suite à un problème matériel.
+Toute information stockée physiquement sur le premier hôte durant son exécution sur le premier hôte, puisqu'elle pourra avoir été entretemps perdue.
 Lors d'une initialisation ou réinitialisation, la solution consiste donc à jouer sur les variables d'environnement (cf. \#3) et sur les informations que l'on pourra trouver au niveau des ressources attachées (cf \#4), et faire en sorte que les informations et données primordiales puissent être récupérées ou reconstruites.
 
 Il serait également difficile d'appliquer une mise à l'échelle de l'application, en ajoutant un nouveau serveur d'exécution, si une donnée indispensable à son fonctionnement devait se trouver sur la seule machine où elle est actuellement exécutée.
 
 \section{Liaison des ports}
 
-Les applications 12-factors sont auto-contenues et peuvent fonctionner
-en autonomie totale. Elles doivent être joignables grâce à un mécanisme
-de ponts, où l'hôte qui s'occupe de l'exécution effectue lui-même la
-redirection vers l'un des ports ouverts par l'application, typiquement,
-en HTTP ou via un autre protocole.
+Les applications 12-factors sont auto-contenues et peuvent fonctionner en autonomie totale.
+Elles doivent être joignables grâce à un mécanisme de ponts, où l'hôte qui s'occupe de l'exécution effectue lui-même la redirection vers l'un des ports ouverts par l'application, typiquement, en HTTP ou via un autre protocole.
 
 \includegraphics{images/diagrams/12-factors-7.png}
 
@@ -202,86 +141,63 @@ Le serveur (= l'hôte) choisit d'appliquer une correspondance entre "son" port 4
 
 \section{Connaissance et confiance des processys systèmes}
 
-Comme décrit plus haut (cf. \#6), l'application doit utiliser des processus \emph{stateless} (sans état). Nous pouvons créer et utiliser des processus supplémentaires pour tenir plus facilement une lourde charge, ou dédier des   particuliers pour certaines tâches: requêtes HTTP \emph{via} des processus Web; \emph{long-running} jobs pour des processus asynchrones, ... 
+Comme décrit plus haut (cf. \#6), l'application doit utiliser des processus \emph{stateless} (sans état).
+Nous pouvons créer et utiliser des processus supplémentaires pour tenir plus facilement une lourde charge, ou dédier des   particuliers pour certaines tâches: requêtes HTTP \emph{via} des processus Web; \emph{long-running} jobs pour des processus asynchrones, \ldots
 Si cela existe sur l'hôte hébergeant l'application, ne vous fatiguez pas: utilisez le.
 
 \includegraphics{images/12factors/process-types.png}
 
 \section{Arrêts élégants et démarrages rapides}
 
-Par "arrêt élégant", nous voulons surtout éviter le fameux
-\texttt{kill\ -9\ \textless{}pid\textgreater{}} (ou équivalent), ou tout autre arrêt brutal d'un processus qui nécessiterait une intervention urgente du
-superviseur. 
-En prévoyant une manière élégante d'envoyer un signal de terminaison, 
+Par "arrêt élégant", nous voulons surtout éviter le fameux \texttt{kill\ -9\ \textless{}pid\textgreater{}} (ou équivalent), ou tout autre arrêt brutal d'un processus qui nécessiterait une intervention urgente du superviseur.
+En prévoyant une manière élégante d'envoyer un signal de terminaison,
 
 \begin{enumerate}
-	\item Les requêtes en cours peuvent se terminer au mieux, 
-	\item Le démarrage rapide de nouveaux processus améliorera la balance d'un processus en cours d'extinction vers des processus tout frais, en autorisant l'exécution parallèle d'anciens et de nouveaux "types" de processus	
+	\item Les requêtes en cours peuvent se terminer au mieux,
+	\item Le démarrage rapide de nouveaux processus améliorera la balance d'un processus en cours d'extinction vers des processus tout frais, en autorisant l'exécution parallèle d'anciens et de nouveaux "types" de processus
 \end{enumerate}
 
-L'intégration de ces mécanismes dès les premières étapes de
-développement limitera les perturbations et facilitera la prise en
-compte d'arrêts inopinés (problème matériel, redémarrage du système
-hôte, etc.).
+L'intégration de ces mécanismes dès les premières étapes de développement limitera les perturbations et facilitera la prise en compte d'arrêts inopinés (problème matériel, redémarrage du système hôte, etc.).
 
 \includegraphics{images/12factors/process-type-chronology.png}
 
 \section{Similarité des environnements}
 
-Conserver les différents environnements aussi similaires
-que possible, et limiter les divergences entre un environnement de
-développement et de production
-
-L'exemple donné est un développeur qui utilise macOS, NGinx et SQLite, tandis que l'environnement de production tourne sur une CentOS avec Apache2 et PostgreSQL. 
+Conserver les différents environnements aussi similaires que possible, et limiter les divergences entre un environnement de développement et de production.
+L'exemple donné est un développeur qui utilise macOS, NGinx et SQLite, tandis que l'environnement de production tourne sur une CentOS avec Apache2 et PostgreSQL.
 Faire en sorte que tous les environnements soient les plus similaires possibles limite les divergences entre environnements, facilite les déploiements et limite la casse et la découverte de modules non compatibles, au plus proche de la phase de développement, selon le principe de la corde d'Andon \cite[p. 140]{devops_handbook} \index{Andon} \footnote{Pour donner un exemple tout bête, SQLite utilise un
-\href{https://www.sqlite.org/datatype3.html}{mécanisme de stockage dynamique}, associée à la valeur plutôt qu'au schéma, \emph{via} un système d'affinités. Un autre moteur de base de données définira un schéma statique et rigide, où la valeur sera déterminée par son contenant. 
-Un champ \texttt{URLField} proposé par Django a une longeur maximale par défaut de \href{https://docs.djangoproject.com/en/3.1/ref/forms/fields/\#django.forms.URLField}{200 caractères}. 
-Si vous faites vos développements sous SQLite et que vous rencontrez une URL de plus de 200 caractères, votre développement sera passera parfaitement bien, mais plantera en production (ou en \emph{staging}, si vous faites les choses   peu mieux) parce que les données seront tronquées, et que cela ne plaira pas à la base de données.
-
+\href{https://www.sqlite.org/datatype3.html}{mécanisme de stockage dynamique}, associée à la valeur plutôt qu'au schéma, \emph{via} un système d'affinités.
+Un autre moteur de base de données définira un schéma statique et rigide, où la valeur sera déterminée par son contenant.
+Un champ \texttt{URLField} proposé par Django a une longeur maximale par défaut de \href{https://docs.djangoproject.com/en/3.1/ref/forms/fields/\#django.forms.URLField}{200 caractères}.
+Si vous faites vos développements sous SQLite et que vous rencontrez une URL de plus de 200 caractères, votre développement sera passera parfaitement bien, mais plantera en production (ou en \emph{staging}, si vous faites les choses peu mieux) parce que les données seront tronquées, et que cela ne plaira pas à la base de données.
 Conserver des environements similaires limite ce genre de désagréments.}
 
 \section{Journaux de flux évènementiels}
 
-Une application ne doit jamais se soucier de l'endroit où les évènements qui la concerne seront écrits, mais se doit simplement de les envoyer sur la sortie \texttt{stdout}. 
-De cette manière, que nous soyons en développement sur le poste d'un développeur avec une sortie console ou sur une machine de production avec un envoi vers une instance \href{https://www.graylog.org/}{Greylog} ou \href{https://sentry.io/welcome/}{Sentry}, le routage des journaux sera réalisé en fonction de sa nécessité et de sa criticité, et non pas parce que le développeur l'a spécifié en dur dans son code. 
+Une application ne doit jamais se soucier de l'endroit où les évènements qui la concerne seront écrits, mais se doit simplement de les envoyer sur la sortie \texttt{stdout}.
+De cette manière, que nous soyons en développement sur le poste d'un développeur avec une sortie console ou sur une machine de production avec un envoi vers une instance \href{https://www.graylog.org/}{Greylog} ou \href{https://sentry.io/welcome/}{Sentry}, le routage des journaux sera réalisé en fonction de sa nécessité et de sa criticité, et non pas parce que le développeur l'a spécifié en dur dans son code.
 
 Cette phase est critique, dans la mesure où les journaux d'exécution sont la seule manière pour une application de communiquer son état vers l'extérieur: recevoir une erreur interne de serveur est une chose; pouvoir obtenir un minimum d'informations, voire un contexte de plantage complet en est une autre.
 La différence entre ces deux points vous fera, au mieux, gagner plusieurs heures sur l'identification ou la résolution d'un problème.
 
 \section{Isolation des tâches administratives}
 
-Evitez qu'une migration ne puisse être démarrée depuis une URL de l'application, ou qu'un envoi massif de notifications ne soit accessible pour n'importe quel utilisateur: les tâches administratives ne doivent être accessibles qu'à un administrateur. 
+Evitez qu'une migration ne puisse être démarrée depuis une URL de l'application, ou qu'un envoi massif de notifications ne soit accessible pour n'importe quel utilisateur : les tâches administratives ne doivent être accessibles qu'à un administrateur.
 Les applications 12facteurs favorisent les langages qui mettent un environnement REPL (pour \emph{Read}, \emph{Eval}, \emph{Print} et \emph{Loop}) \index{REPL} à disposition (au hasard: \href{https://pythonprogramminglanguage.com/repl/}{Python} ou \href{https://kotlinlang.org/}{Kotlin}), ce qui facilite les étapes de maintenance.
 
 \section{Conclusions}
 
-Une application devient nettement plus maintenable dès lors que l'équipe
-de développement suit de près les différentes étapes de sa conception,
-de la demande jusqu'à son aboutissement en production.
+Une application devient nettement plus maintenable dès lors que l'équipe de développement suit de près les différentes étapes de sa conception, de la demande jusqu'à son aboutissement en production.
 \cite[pp. 293-294]{devops_handbook}.
 Au fur et à mesure que le code est délibérément construit pour être maintenable, l'équipe gagne en rapidité, en qualité et en fiabilité de déploiement, ce qui facilite les tâches opérationnelles:
 
 \begin{enumerate}
-\item
-  Activation d'une télémétrie suffisante dans les applications et les
-  environnements
-\item
-  Conservation précise des dépendances nécessaires
-\item
-  Résilience des services et plantage élégant (i.e. \textbf{sans finir
-  sur un SEGFAULT avec l'OS dans les choux et un écran bleu})
-\item
-  Compatibilité entre les différentes versions (n+1, \ldots\hspace{0pt})
-\item
-  Gestion de l'espace de stockage associé à un environnement (pour
-  éviter d'avoir un environnement de production qui fait 157
-  Tera-octets)
-\item
-  Activation de la recherche dans les logs
-\item
-  Traces des requêtes provenant des utilisateurs, indépendamment des
-  services utilisés
-\item
-  Centralisation de la configuration (\textbf{via} ZooKeeper, par
-  exemple)
+    \item Activation d'une télémétrie suffisante dans les applications et les environnements
+    \item Conservation précise des dépendances nécessaires
+    \item Résilience des services et plantage élégant (i.e. \textbf{sans finir sur un SEGFAULT avec l'OS dans les choux et un écran bleu})
+    \item Compatibilité entre les différentes versions (n+1, \ldots\hspace{0pt})
+    \item Gestion de l'espace de stockage associé à un environnement (pour éviter d'avoir un environnement de production qui fait 157 Tera-octets)
+    \item Activation de la recherche dans les logs
+    \item Traces des requêtes provenant des utilisateurs, indépendamment des services utilisés
+    \item Centralisation de la configuration (\textbf{via} ZooKeeper, par exemple)
 \end{enumerate}

chapters/new-project.tex

@@ -5,7 +5,7 @@ Django fonctionne sur un
 
 \section{Gestion des dépendances}
 
-Comme nous en avons déjà discuté, Poetry est la solution que nous avons choisie pour la gestion de nos dépendances. 
+Comme nous en avons déjà discuté, Poetry est la solution que nous avons choisie pour la gestion de nos dépendances.
 Pour installer une nouvelle librairie, vous pouvez simplement passer par la commande \texttt{pip\ install\ \textless{}my\_awesome\_library\textgreater{}}.
 Dans le cas de Django, et après avoir activé l'environnement, nous pouvons à présent y installer Django. Comme expliqué ci-dessus, la librairie restera indépendante du reste du système, et ne polluera aucun autre projet. nous exécuterons donc la commande suivante:
 
@@ -21,21 +21,18 @@ Dans le cas de Django, et après avoir activé l'environnement, nous pouvons à
 \end{verbatim}
 
 
-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.
+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.
-\item
-  \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.
-\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.
+    \item
+        \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.
+    \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.
+    \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.
 \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:
@@ -85,20 +71,20 @@ Tant que nous y sommes, nous pouvons ajouter un répertoire dans lequel nous sto
 TODO
 
 Comme nous venons d'ajouter une dépendance à notre projet, profitons-en pour créer un fichier reprenant tous les dépendances de notre projet.
-Celles-ci sont normalement placées dans un fichier \texttt{requirements.txt}. 
+Celles-ci sont normalement placées dans un fichier \texttt{requirements.txt}.
 Dans un premier temps, ce fichier peut être placé directement à la racine du projet, mais on préférera rapidement le déplacer dans un sous-répertoire spécifique (\texttt{requirements}), afin de grouper les dépendances en fonction de leur environnement de destination:
 
 \begin{itemize}
-\item
-  \texttt{base.txt}
-\item
-  \texttt{dev.txt}
-\item
-  \texttt{production.txt}
+    \item
+        \texttt{base.txt}
+    \item
+        \texttt{dev.txt}
+    \item
+        \texttt{production.txt}
 \end{itemize}
 
-Au début de chaque fichier, il suffit d'ajouter la ligne \texttt{-r\ base.txt}, puis de lancer l'installation grâce à un \texttt{pip\ install\ -r\ \textless{}nom\ du\ fichier\textgreater{}}. 
-De cette manière, il est tout à fait acceptable de n'installer \texttt{flake8} et \texttt{django-debug-toolbar} qu'en développement par exemple. 
+Au début de chaque fichier, il suffit d'ajouter la ligne \texttt{-r\ base.txt}, puis de lancer l'installation grâce à un \texttt{pip\ install\ -r\ \textless{}nom\ du\ fichier\textgreater{}}.
+De cette manière, il est tout à fait acceptable de n'installer \texttt{flake8} et \texttt{django-debug-toolbar} qu'en développement par exemple.
 Dans l'immédiat, nous allons ajouter \texttt{django} dans une version égale à la version 3.2 dans le fichier \texttt{requirements/base.txt}.
 
 \begin{verbatim}
@@ -109,12 +95,12 @@ Dans l'immédiat, nous allons ajouter \texttt{django} dans une version égale à
 
 Une bonne pratique consiste à également placer un fichier \texttt{requirements.txt} à la racine du projet, et dans lequel nous retrouverons le contenu \texttt{-r requirements/production.txt} (notamment pour Heroku).
 
-Prenez directement l'habitude de spécifier la version ou les versions compatibles: les librairies que vous utilisez comme dépendances évoluent, de la même manière que vos projets. 
-Pour être sûr et certain le code que vous avez écrit continue à fonctionner, spécifiez la version de chaque librairie de dépendances. 
-Entre deux versions d'une même librairie, des fonctions sont cassées, certaines signatures sont modifiées, des comportements sont altérés, etc. 
+Prenez directement l'habitude de spécifier la version ou les versions compatibles: les librairies que vous utilisez comme dépendances évoluent, de la même manière que vos projets.
+Pour être sûr et certain le code que vous avez écrit continue à fonctionner, spécifiez la version de chaque librairie de dépendances.
+Entre deux versions d'une même librairie, des fonctions sont cassées, certaines signatures sont modifiées, des comportements sont altérés, etc.
 Il suffit de parcourirles pages de \emph{Changements incompatibles avec les anciennes versions dans Django}
 \href{https://docs.djangoproject.com/fr/3.1/releases/3.0/}{(par exemple ici pour le passage de la 3.0 à la 3.1)} pour réaliser que certaines opérations ne sont pas anodines, et que sans filet de sécurité, c'est le
-mur assuré. 
+mur assuré.
 Avec les mécanismes d'intégration continue et de tests unitaires, nous verrons plus loin comment se prémunir d'un changement inattendu.
 
 
@@ -126,35 +112,32 @@ Dans les étapes ci-dessous, nous épinglerons une version LTS afin de nous assu
 
 \section{Django}
 
-Comme nous l'avons vu ci-dessus, \texttt{django-admin} permet de créer un nouveau projet. 
+Comme nous l'avons vu ci-dessus, \texttt{django-admin} permet de créer un nouveau projet.
 Nous faisons ici une distinction entre un \textbf{projet} et une \textbf{application}:
 
 \begin{itemize}
-\item
-  \textbf{Un projet} représente l'ensemble des applications, paramètres, middlewares, dépendances, ..., qui font que votre code fait ce qu'il est sensé faire.
-  Il s'agit grosso modo d'un câblage de tous les composants entre eux.
-\item
-  \textbf{Une application} est un contexte d'exécution (vues, comportements, pages HTML, ...), idéalement autonome, d'une partie du projet. 
-  Une application est supposée avoir une portée de réutilisation, même s'il ne sera pas toujours possible de viser une généricité parfaite.
+    \item
+        \textbf{Un projet} représente l'ensemble des applications, paramètres, middlewares, dépendances, ..., qui font que votre code fait ce qu'il est sensé faire.
+        Il s'agit grosso modo d'un câblage de tous les composants entre eux.
+    \item
+        \textbf{Une application} est un contexte d'exécution (vues, comportements, pages HTML, ...), idéalement autonome, d'une partie du projet.
+        Une application est supposée avoir une portée de réutilisation, même s'il ne sera pas toujours possible de viser une généricité parfaite.
 \end{itemize}
 
-Pour \texttt{gwift}, nous aurons:
-
+Pour \texttt{gwift}, nous aurons :
 \begin{figure}
-\centering
-\includegraphics{images/django/django-project-vs-apps-gwift.png}
-\caption{Projet Django vs Applications}
+    \centering
+    \includegraphics{images/django/django-project-vs-apps-gwift.png}
+    \caption{Projet Django vs Applications}
 \end{figure}
 
 \begin{enumerate}
-\item
-  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.
+    \item
+        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.
 \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
@@ -168,8 +151,8 @@ Pour \texttt{khana}, nous pourrions avoir quelque chose comme ceci:
 \caption{Django Project vs Applications}
 \end{figure}
 
-En rouge, vous pouvez voir quelque chose que nous avons déjà vu: la gestion des utilisateurs et la possibilité qu'ils auront de communiquer entre eux. 
-Ceci pourrait être commun aux deux projets. 
+En rouge, vous pouvez voir quelque chose que nous avons déjà vu: la gestion des utilisateurs et la possibilité qu'ils auront de communiquer entre eux.
+Ceci pourrait être commun aux deux projets.
 Nous pouvons clairement visualiser le principe de \textbf{contexte} pour une application: celle-ci viendra avec son modèle, ses tests, ses vues et son paramétrage et pourrait ainsi être réutilisée dans un autre projet.
 C'est en ça que consistent les \href{https://www.djangopackages.com/}{paquets Django} déjà disponibles:
 ce sont "\emph{simplement}" de petites applications empaquetées et pouvant être réutilisées dans différents contextes (eg. \href{https://github.com/tomchristie/django-rest-framework}{Django-Rest-Framework}, \href{https://github.com/django-debug-toolbar/django-debug-toolbar}{Django-Debug-Toolbar}, ...
@@ -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
@@ -204,7 +186,7 @@ catégories:
 \item
   \textbf{auth}: création d'un nouveau super-utilisateur, changer le mot de passe pour un utilisateur existant.
 \item
-  \textbf{django}: vérifier la \textbf{conformité} du projet, lancer un \textbf{shell}, \textbf{dumper} les données de la base, effectuer une migration du schéma, ... 
+  \textbf{django}: vérifier la \textbf{conformité} du projet, lancer un \textbf{shell}, \textbf{dumper} les données de la base, effectuer une migration du schéma, ...
   Ce sont des commandes d'administration générale.
 \item
   \textbf{sessions}: suppressions des sessions en cours
@@ -240,7 +222,7 @@ Si nous nous rendons sur la page \url{http://127.0.0.1:8000} (ou \url{http://loc
     \caption{python manage.py runserver (Non, ce n'est pas Challenger)}
 \end{figure}
 
-Nous avons mis un morceau de la sortie console entre crochet \texttt{{[}\ldots{}\hspace{0pt}{]}} ci-dessus, car elle concerne les migrations. 
+Nous avons mis un morceau de la sortie console entre crochet \texttt{{[}\ldots{}\hspace{0pt}{]}} ci-dessus, car elle concerne les migrations.
 Si vous avez suivi les étapes jusqu'ici, vous avez également dû voir un message type \texttt{You\ have\ 18\ unapplied\ migration(s).\ {[}\ldots{}\hspace{0pt}{]}\ Run\ \textquotesingle{}python\ manage.py\ migrate\textquotesingle{}\ to\ apply\ them.}
 Cela concerne les migrations, et c'est un point que nous verrons un peu plus tard.
 
@@ -261,8 +243,8 @@ Résultat? Django nous a créé un répertoire \texttt{wish}, dans lequel nous t
 \item
   \texttt{wish/\_\_init\_\_.py} pour que notre répertoire \texttt{wish} soit converti en package Python.
 \item
-  \texttt{wish/admin.py} servira à structurer l'administration de notre application. 
-  Chaque information peut être gérée facilement au travers d'une interface générée à la volée par le framework. 
+  \texttt{wish/admin.py} servira à structurer l'administration de notre application.
+  Chaque information peut être gérée facilement au travers d'une interface générée à la volée par le framework.
   Nous y reviendrons par la suite.
 \item
   \texttt{wish/apps.py} qui contient la configuration de l'application et qui permet notamment de fixer un nom ou un libellé \url{https://docs.djangoproject.com/en/stable/ref/applications/}
@@ -274,7 +256,7 @@ Résultat? Django nous a créé un répertoire \texttt{wish}, dans lequel nous t
   \texttt{wish/tests.py} pour les tests unitaires.
 \end{itemize}
 
-Par soucis de clarté, vous pouvez déplacer ce nouveau répertoire \texttt{wish} dans votre répertoire \texttt{gwift} existant. 
+Par soucis de clarté, vous pouvez déplacer ce nouveau répertoire \texttt{wish} dans votre répertoire \texttt{gwift} existant.
 C'est \emph{une} forme de convention.
 
 La structure de vos répertoires devient celle-ci:
@@ -286,19 +268,19 @@ Notre application a bien été créée, et nous l'avons déplacée dans le répe
 
 \section{Fonctionnement général}
 
-Le métier de programmeur est devenu de plus en plus complexe. 
-Il y a 20 ans, nous pouvions nous contenter d'une simple page PHP dans laquelle nous mixions l'ensemble des actions à réaliser: requêtes en bases de données, construction de la page, ... 
+Le métier de programmeur est devenu de plus en plus complexe.
+Il y a 20 ans, nous pouvions nous contenter d'une simple page PHP dans laquelle nous mixions l'ensemble des actions à réaliser : requêtes en bases de données, construction de la page, ...
 La recherche d'une solution à un problème n'était pas spécialement plus complexe - dans la mesure où le rendu des enregistrements en direct n'était finalement qu'une forme un chouia plus évoluée du \texttt{print()} ou des \texttt{System.out.println()} - mais c'était l'évolutivité des applications qui en prenait un coup: une grosse partie des tâches étaient dupliquées entre les différentes pages, et l'ajout d'une nouvelle fonctionnalité était relativement ardue.
 
-Django (et d'autres frameworks) résolvent ce problème en se basant ouvertement sur le principe de \texttt{Don’t\ repeat\ yourself} \footnote{DRY}. 
+Django (et d'autres frameworks) résolvent ce problème en se basant ouvertement sur le principe de \texttt{Don’t\ repeat\ yourself} \footnote{DRY}.
 Chaque morceau de code ne doit apparaitre qu'une seule fois, afin de limiter au maximum la redite (et donc, l'application d'un même correctif à différents endroits).
 
 Le chemin parcouru par une requête est expliqué en (petits) détails ci-dessous.
 
 
-\textbf{Un utilisateur ou un visiteur souhaite accéder à une URL hébergée et servie par notre application}. 
-Ici, nous prenons l'exemple de l'URL fictive \texttt{https://gwift/wishes/91827}. 
-Lorsque cette URL "arrive" dans notre application, son point d'entrée se trouvera au niveau des fichiers \texttt{asgi.py} ou \texttt{wsgi.py}. 
+\textbf{Un utilisateur ou un visiteur souhaite accéder à une URL hébergée et servie par notre application}.
+Ici, nous prenons l'exemple de l'URL fictive \texttt{https://gwift/wishes/91827}.
+Lorsque cette URL "arrive" dans notre application, son point d'entrée se trouvera au niveau des fichiers \texttt{asgi.py} ou \texttt{wsgi.py}.
 Nous verrons cette partie plus tard, et nous pouvons nous concentrer sur le chemin interne qu'elle va parcourir.
 
 \begin{figure}
@@ -314,7 +296,7 @@ Nous verrons cette partie plus tard, et nous pouvons nous concentrer sur le chem
   from django.contrib import admin
   from django.urls import path
   from gwift.views import wish_details
-  
+
   urlpatterns = [
       path('admin/', admin.site.urls),
       path("wishes/<int:wish_id>", wish_details),
@@ -323,7 +305,7 @@ Nous verrons cette partie plus tard, et nous pouvons nous concentrer sur le chem
 
 \textbf{Etape 1} - Si ce n'est pas le cas, l'application n'ira pas plus loin et retournera une erreur à l'utilisateur.
 
-\textbf{Etape 2} - Django va parcourir l'ensemble des \emph{patterns} présents dans le fichier \texttt{urls.py} et s'arrêtera sur le premier qui correspondra à la requête qu'il a reçue. 
+\textbf{Etape 2} - Django va parcourir l'ensemble des \emph{patterns} présents dans le fichier \texttt{urls.py} et s'arrêtera sur le premier qui correspondra à la requête qu'il a reçue.
 Ce cas est relativement trivial: la requête \texttt{/wishes/91827} a une correspondance au
 niveau de la ligne \texttt{path("wishes/\textless{}int:wish\_id\textgreater{}} dans l'exemple ci-dessous. Django va alors appeler la fonction \footnote{Qui ne sera pas toujours une fonction. Django s'attend à trouver un \emph{callable}, c'est-à-dire n'importe quel élément qu'il peut appeler comme une fonction.} associée à ce \emph{pattern}, c'est-à-dire \texttt{wish\_details} du module \texttt{gwift.views}.
 
@@ -335,17 +317,17 @@ niveau de la ligne \texttt{path("wishes/\textless{}int:wish\_id\textgreater{}} d
       Champomy et cotillons! Nous avons une correspondance avec
       \texttt{wishes/details/91827}
 \end{itemize}
-  
+
 Le module \texttt{gwift.views} qui se trouve dans le fichier \texttt{gwift/views.py} peut ressembler à ceci:
 
 \begin{minted}{Python}
   # gwift/views.py
 
   [...]
-  
+
   from datetime import datetime
-  
-  
+
+
   def wishes_details(request: HttpRequest, wish_id: int) -> HttpResponse:
     context = {
       "user_name": "Bond,"
@@ -364,7 +346,7 @@ Pour résumer, cette fonction permet:
 
 \begin{enumerate}
 \item
-  De construire un \emph{contexte}, qui est représenté sous la forme d'un dictionnaire associant des clés à des valeurs. 
+  De construire un \emph{contexte}, qui est représenté sous la forme d'un dictionnaire associant des clés à des valeurs.
   Les clés sont respectivement \texttt{user\_name}, \texttt{user\_first\_name} et \texttt{now}, tandis que leurs valeurs respectives sont \texttt{Bond}, \texttt{James} et le \texttt{moment\ présent} \footnote{Non, pas celui d'Eckhart Tolle}.
 \item
   Nous passons ensuite ce dictionnaire à un canevas, \texttt{wish\_details.html}, que l'on trouve normalement dans le répertoire \texttt{templates} de notre projet, ou dans le répertoire \texttt{templates} propre à notre application.
@@ -413,7 +395,7 @@ Après application de notre contexte sur ce template, nous obtiendrons ce docume
 
 \subsection{Structure finale}
 
-En repartant de la structure initiale décrite au chapitre précédent, nous arrivons à ceci. 
+En repartant de la structure initiale décrite au chapitre précédent, nous arrivons à ceci.
 
 TODO : passer à poetry
 
@@ -422,9 +404,9 @@ TODO : passer à poetry
 Pfiou! Ca en fait des commandes et du boulot pour "juste" démarrer un nouveau projet, non? Sachant qu'en plus, nous avons dû modifier des fichiers, déplacer des dossiers, ajouter des dépendances, configurer une
 base de données, ...
 
-Bonne nouvelle! Il existe des générateurs, permettant de démarrer rapidement un nouveau projet sans (trop) se prendre la tête. 
+Bonne nouvelle! Il existe des générateurs, permettant de démarrer rapidement un nouveau projet sans (trop) se prendre la tête.
 Le plus connu (et le plus personnalisable) est \href{https://cookiecutter.readthedocs.io/}{Cookie-Cutter}, qui se base sur des canevas \emph{type \href{https://pypi.org/project/Jinja2/}{Jinja2}}, pour créer une
-arborescence de dossiers et fichiers conformes à votre manière de travailler. 
+arborescence de dossiers et fichiers conformes à votre manière de travailler.
 Et si vous avez la flemme de créer votre propre canevas, vous pouvez utiliser \href{https://cookiecutter-django.readthedocs.io}{ceux qui existent déjà}.
 
 Pour démarrer, créez un environnement virtuel (comme d'habitude):
@@ -432,7 +414,7 @@ Pour démarrer, créez un environnement virtuel (comme d'habitude):
 \begin{verbatim}
     python -m venv .venvs\cookie-cutter-khana
     .venvs\cookie-cutter-khana\Scripts\activate.bat
-    
+
     (cookie-cutter-khana) $ pip install cookiecutter
     Collecting cookiecutter
     [...]
@@ -446,11 +428,11 @@ Pour démarrer, créez un environnement virtuel (comme d'habitude):
     [SUCCESS]: Project initialized, keep up the good work!
 \end{verbatim}
 
-Si vous explorez les différents fichiers, vous trouverez beaucoup de similitudes avec la configuration que nous vous proposions ci-dessus. 
+Si vous explorez les différents fichiers, vous trouverez beaucoup de similitudes avec la configuration que nous vous proposions ci-dessus.
 En fonction de votre expérience, vous serez tenté de modifier certains paramètres, pour faire correspondre ces sources avec votre utilisation ou vos habitudes.
 
 Il est aussi possible d'utiliser l'argument \texttt{-\/-template}, suivie d'un argument reprenant le nom de votre projet (\texttt{\textless{}my\_project\textgreater{}}), lors de l'initialisation d'un projet avec la commande \texttt{startproject} de \texttt{django-admin}, afin de calquer votre arborescence sur un projet
-existant. 
+existant.
 La \href{https://docs.djangoproject.com/en/stable/ref/django-admin/\#startproject}{documentation} à ce sujet est assez complète.
 
 \begin{verbatim}
@@ -459,12 +441,12 @@ La \href{https://docs.djangoproject.com/en/stable/ref/django-admin/\#startprojec
 
 \section{Tests unitaires}
 
-Il y a deux manières d'écrire les tests: soit avant, soit après l'implémentation. 
+Il y a deux manières d'écrire les tests: soit avant, soit après l'implémentation.
 Oui, idéalement, les tests doivent être écrits à l'avance. Entre nous, on ne va pas râler si vous faites l'inverse, l'important étant que vous le fassiez. Une bonne métrique pour vérifier l'avancement des tests est la couverture de code.
 
 Chaque application est créée par défaut avec un fichier \textbf{tests.py}, qui inclut la classe \texttt{TestCase} depuis le package \texttt{django.test}:
 
-On a deux choix ici: 
+On a deux choix ici:
 
 \begin{enumerate}
     \item Utiliser les librairies de test de Django
@@ -486,13 +468,13 @@ On a deux choix ici:
 
 \subsection{Couverture de code}
 
-Quel que soit le framework de tests choisi (django-tests, pytest, unittest, ...), la couverture de code est une analyse qui donne un pourcentage lié à la quantité de code couvert par les tests. 
-Il ne s'agit pas de vérifier que le code est bien testé, mais de vérifier quelle partie du code est testée. 
+Quel que soit le framework de tests choisi (django-tests, pytest, unittest, ...), la couverture de code est une analyse qui donne un pourcentage lié à la quantité de code couvert par les tests.
+Il ne s'agit pas de vérifier que le code est bien testé, mais de vérifier quelle partie du code est testée.
 Le paquet coverage se charge d’évaluer le pourcentage de code couvert par les tests.
 Avec pytest, il convient d’utiliser le paquet pytest-cov, suivi de la commande pytest
 \texttt{--cov=gwift tests/}.
 Si vous préférez rester avec le cadre de tests de Django, vous pouvez passer par le paquet django-coverage-plugin.
-Ajoutez-le dans le fichier requirements/base.txt, et lancez une couverture de code grâce à la commande coverage. 
+Ajoutez-le dans le fichier requirements/base.txt, et lancez une couverture de code grâce à la commande coverage.
 La configuration peut se faire dans un fichier .coveragerc que vous placerez à la racine de votre projet, et qui sera lu lors de l’exécution.
 
 
@@ -509,10 +491,10 @@ La configuration peut se faire dans un fichier .coveragerc que vous placerez à
     omit = ../*migrations*
     plugins =
         django_coverage_plugin
-    
+
     [report]
         ignore_errors = True
-    
+
     [html]
     directory = coverage_html_report
 \end{verbatim}
@@ -574,9 +556,9 @@ class HomeTests(TestCase):
 \begin{minted}{python}
   from django.core.urlresolvers import reverse
   from django.test import TestCase
-  
+
   from .views import home
-  
+
   class HomeTests(TestCase):
     def test_home_view_status_code(self):
       view = resolve("/")
@@ -599,7 +581,7 @@ class Wish(models.Model):
     total = self.number_of_parts * self.numbers_available
     percentage = (number_of_linked_parts / total)
     return percentage * 100
-\end{minted}  
+\end{minted}
 
 Lancez maintenant la couverture de code. Vous obtiendrez ceci:
 
@@ -643,7 +625,7 @@ class TestWishModel(TestCase):
       description='This is a faked wishlist'
     )
     wishlist.save()
-    
+
     wish = Wish(
       wishlist=wishlist,
       name='Fake Wish',
@@ -651,25 +633,25 @@ class TestWishModel(TestCase):
       number_of_parts=4
     )
     wish.save()
-    
+
     part1 = WishPart(wish=wish, comment='part1')
     part1.save()
-    
+
     self.assertEqual(25, wish.percentage_of_completion)
-    
+
     part2 = WishPart(wish=wish, comment='part2')
     part2.save()
-    
+
     self.assertEqual(50, wish.percentage_of_completion)
-    
+
     part3 = WishPart(wish=wish, comment='part3')
     part3.save()
-    
+
     self.assertEqual(75, wish.percentage_of_completion)
-    
+
     part4 = WishPart(wish=wish, comment='part4')
     part4.save()
-    
+
     self.assertEqual(100, wish.percentage_of_completion)
 \end{minted}
 
@@ -685,7 +667,7 @@ En relançant la couverture de code, on voit à présent que nous arrivons à 99
   .
   ----------------------------------------------------------------------
   Ran 1 test in 0.006s
-  
+
   OK
   Creating test database for alias 'default'...
   Destroying test database for alias 'default'...
@@ -703,5 +685,5 @@ En relançant la couverture de code, on voit à présent que nous arrivons à 99
   ------------------------------------------------------------------
   TOTAL                               87      0      4      1    99%
 \end{verbatim}
-  
+
 En continuant de cette manière (ie. Ecriture du code et des tests, vérification de la couverture de code), on se fixe un objectif idéal dès le début du projet. En prenant un développement en cours de route, fixez-vous comme objectif de ne jamais faire baisser la couverture de code.

chapters/programming-poetry.tex

@@ -1,8 +1,8 @@
 \chapter{Poésie de la programmation}
 
 \begin{quote}
-The primary cost of maintenance is in spelunking and risk
-	\cite[139]{clean_architecture}
+    The primary cost of maintenance is in spelunking and risk
+        \cite[139]{clean_architecture}
 
----  Robert C. Martin
+    ---  Robert C. Martin
 \end{quote}

chapters/python.tex

@@ -8,7 +8,7 @@ Le langage \href{https://www.python.org/}{Python} est un \href{https://docs.pyth
 \caption{\url{https://xkcd.com/353/}}
 \end{figure}
 
-A première vue, et suivants les autres langages que vous connaitriez ou auriez déjà abordé, certains concepts restent difficiles à aborder: l'indentation définit l'étendue d'un bloc (classe, fonction, méthode, boucle, condition, il n'y a pas de typage fort des variables et le compilateur n'est pas là pour assurer le filet de sécurité avant la mise en production (puisqu'il n'y a pas de compilateur). 
+A première vue, et suivants les autres langages que vous connaitriez ou auriez déjà abordé, certains concepts restent difficiles à aborder: l'indentation définit l'étendue d'un bloc (classe, fonction, méthode, boucle, condition, il n'y a pas de typage fort des variables et le compilateur n'est pas là pour assurer le filet de sécurité avant la mise en production (puisqu'il n'y a pas de compilateur).
 Et malgré ces quelques points, Python reste un langage généraliste accessible et "bon partout", et de pouvoir se reposer sur un écosystème stable et fonctionnel.
 
 Il fonctionne avec un système d'améliorations basées sur des propositions: les PEP, ou "\textbf{Python Enhancement Proposal}\index{PEP}".
@@ -19,7 +19,7 @@ Le langage Python utilise un typage dynamique appelé \href{https://fr.wikipedia
 \begin{quote}
 "\emph{When I see a bird that quacks like a duck, walks like a duck, has
 feathers and webbed feet and associates with ducks --- I'm certainly
-going to assume that he is a duck}" 
+going to assume that he is a duck}"
 
 	-- Source: \href{http://en.wikipedia.org/wiki/Duck_test}{Wikipedia}.
 \end{quote}
@@ -28,29 +28,20 @@ En fonction de votre niveau d'apprentissage du langage, plusieurs
 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}
-\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, ... 
-  A ce jour, c'est le concentré de sujets liés au langage le plus intéressant qui ait pu arriver entre nos mains.
+    \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}
+    \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, \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}
@@ -60,21 +51,21 @@ permet de surcharger l'initialisation d'une instance de classe.
 	\end{minted}
 \end{listing}
 
-Ces méthodes, utilisées seules ou selon des combinaisons spécifiques, constituent les \emph{protocoles de langage}. 
+Ces méthodes, utilisées seules ou selon des combinaisons spécifiques, constituent les \emph{protocoles de langage}.
 Une liste complètement des \emph{dunder methods} peut être trouvée dans la section \texttt{Data\ Model} de \href{https://docs.python.org/3/reference/datamodel.html}{la documentation du langage Python}.
 
-Tous les opérateurs sont également exposés comme des fonctions ordinaires du module \texttt{opeartor}, dont la \href{https://docs.python.org/3.9/library/operator.html}{documentation} donne un bon aperçu. 
+Tous les opérateurs sont également exposés comme des fonctions ordinaires du module \texttt{opeartor}, dont la \href{https://docs.python.org/3.9/library/operator.html}{documentation} donne un bon aperçu.
 Indiquer qu'un type d'objet implémente un protocole du langage indique simplement qu'il est compatible avec une partie spécifique de la syntaxe du langage Python.
 
 Vous trouverez ci-dessous un tableau reprenant les protocoles les plus courants:
 
 \begin{center}
 	\begin{tabular}{ c c c }
-	 cell1 & cell2 & cell3 \\ 
-	 cell4 & cell5 & cell6 \\  
-	 cell7 & cell8 & cell9    
+        cell1 & cell2 & cell3 \\
+        cell4 & cell5 & cell6 \\
+        cell7 & cell8 & cell9
 	\end{tabular}
-\end{center}	
+\end{center}
 
 Les points principaux à présenter ci-dessus:
 
@@ -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{*}.
@@ -103,15 +94,15 @@ L'exemple ci-dessous implémente la soustraction de deux matrices:
 \begin{listing}
 	\begin{minted}[tabsize=4]{python}
 	def __sub__(self, other):
-		if (len(self.rows) != len(other.rows) 
+		if (len(self.rows) != len(other.rows)
 			or len(self.rows[0]) != len(other.rows[0])
 		):
 			raise ValueError("Matrix dimensions don't match")
 
 		return Matrix(
 			[
-				[a - b for a, b in zip(a_row, b_row)] 
-				for a_row, b_row in zip(self.rows, other.rows) 
+				[a - b for a, b in zip(a_row, b_row)]
+				for a_row, b_row in zip(self.rows, other.rows)
 			]
 		)
 	\end{minted}
@@ -119,7 +110,7 @@ L'exemple ci-dessous implémente la soustraction de deux matrices:
 
 Il suffit dès lors de réaliser la soustraction matricielle entre deux objets de type \texttt{Matrix} pour que la méthode \texttt{sub())} ci-dessous soit appelée.
 
-En fait, l'intérêt concerne surtout la représentation de nos modèles, puisque chaque classe du modèle est représentée par la définition d'un objet Python. 
+En fait, l'intérêt concerne surtout la représentation de nos modèles, puisque chaque classe du modèle est représentée par la définition d'un objet Python.
 Nous pouvons donc utiliser ces mêmes \textbf{dunder methods} (\textbf{double-underscores methods}) pour étoffer les protocoles du langage.
 
 \section{The Zen of Python}
@@ -148,19 +139,19 @@ Nous pouvons donc utiliser ces mêmes \textbf{dunder methods} (\textbf{double-un
 	If the implementation is hard to explain, it's a bad idea.
 	If the implementation is easy to explain, it may be a good idea.
 	Namespaces are one honking great idea -- let's do more of those!
-	
+
 \end{verbatim}
 	\caption{The Zen of Python}
 \end{listing}
 
 \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, ...
+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, \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}, ...). 
+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}, \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]
@@ -182,26 +173,26 @@ Si vous ne voulez pas être dérangé sur votre manière de coder, et que vous v
 
 \begin{listing}[!ht]
 	\begin{verbatim}
-	$ pyflakes . 
-	...
+	$ pyflakes .
+	\ldots
 	\end{verbatim}
 	\caption{Une utilisation de pyflakes}
 \end{listing}
 
 A noter qu'un greffon pour \texttt{flake8} existe et donnera une estimation de la complexité de McCabe pour les fonctions trop complexes.
-Installez-le avec \texttt{pip\ install\ mccabe}, et activez-le avec le paramètre \texttt{-\/-max-complexity}. 
+Installez-le avec \texttt{pip\ install\ mccabe}, et activez-le avec le paramètre \texttt{-\/-max-complexity}.
 Toute fonction dans la complexité est supérieure à cette valeur sera considérée comme trop complexe.
 
 \section{Conventions de documentation}
 
-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":
+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, \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,14 +210,14 @@ 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}
 
-La \href{https://peps.python.org/pep-0257/#what-is-a-docstring}{PEP-257} nous donne des recommandations haut-niveau concernant la structure des docstrings: ce qu'elles doivent contenir et comment l'expliciter, sans imposer quelle que mise en forme que ce soit. 
-de contenu, mais pas de forme, notamment sur la manière de représenter des docstrings ne nécessitant qu'une seule ligne, nécessitant plusieurs lignes ou de gérer l'indentation. 
-Son objectif est d'arriver à une forme de cohérence lorsqu'un utilisateur souhaitera accéder à la propriété 
-Elle contient des conventions, pas des règles ou 
+La \href{https://peps.python.org/pep-0257/#what-is-a-docstring}{PEP-257} nous donne des recommandations haut-niveau concernant la structure des docstrings: ce qu'elles doivent contenir et comment l'expliciter, sans imposer quelle que mise en forme que ce soit.
+de contenu, mais pas de forme, notamment sur la manière de représenter des docstrings ne nécessitant qu'une seule ligne, nécessitant plusieurs lignes ou de gérer l'indentation.
+Son objectif est d'arriver à une forme de cohérence lorsqu'un utilisateur souhaitera accéder à la propriété
+Elle contient des conventions, pas des règles ou
 
 \begin{quote}
 “A universal convention supplies all of maintainability, clarity, consistency, and a foundation for good programming habits too. What it doesn’t do is insist that you follow it against your will. That’s Python!”
@@ -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}
@@ -249,7 +240,7 @@ A remplir
 
 \subsection{Napoleon}
 
-Les \href{https://google.github.io/styleguide/pyguide.html\#38-comments-and-docstrings}{conventions proposées par Google} nous semblent plus faciles à lire que du RestructuredText, mais sont parfois moins bien intégrées que les docstrings officiellement supportées (par exemple, \href{https://clize.readthedocs.io/en/stable/}{clize} ne reconnait que du RestructuredText; \href{https://docs.djangoproject.com/en/stable/ref/contrib/admin/admindocs/}{l'auto-documentation} de Django également). 
+Les \href{https://google.github.io/styleguide/pyguide.html\#38-comments-and-docstrings}{conventions proposées par Google} nous semblent plus faciles à lire que du RestructuredText, mais sont parfois moins bien intégrées que les docstrings officiellement supportées (par exemple, \href{https://clize.readthedocs.io/en/stable/}{clize} ne reconnait que du RestructuredText; \href{https://docs.djangoproject.com/en/stable/ref/contrib/admin/admindocs/}{l'auto-documentation} de Django également).
 
 L'exemple donné dans les guides de style de Google est celui-ci:
 
@@ -257,30 +248,30 @@ L'exemple donné dans les guides de style de Google est celui-ci:
 	\begin{minted}{python}
 	def fetch_smalltable_rows(table_handle: smalltable.Table, keys: Sequence[Union[bytes, str]], require_all_keys: bool = False,) -> Mapping[bytes, Tuple[str]]:
 		"""Fetches rows from a Smalltable.
-		
+
 		Retrieves rows pertaining to the given keys from the Table instance
 		represented by table_handle. String keys will be UTF-8 encoded.
-		
+
 		Args:
 			table_handle: An open smalltable.Table instance.
 			keys: A sequence of strings representing the key of each table
 			      row to fetch. String keys will be UTF-8 encoded.
 			require_all_keys: Optional; If require_all_keys is True only
 			      rows with values set for all keys will be returned.
-		
+
 		Returns:
 			A dict mapping keys to the corresponding table row data
 			fetched. Each row is represented as a tuple of strings. For
 			example:
-			
+
 			{b'Serak': ('Rigel VII', 'Preparer'),
 			b'Zim': ('Irk', 'Invader'),
 			b'Lrrr': ('Omicron Persei 8', 'Emperor')}
-			
+
 			Returned keys are always bytes. If a key from the keys argument is
 			missing from the dictionary, then that row was not found in the
 			table (and require_all_keys must have been False).
-		
+
 		Raises:
 			IOError: An error occurred accessing the smalltable.
 		"""
@@ -371,13 +362,13 @@ code pas très propre et qui ne sert à rien:
 	\begin{minted}{python}
 	from datetime import datetime
 	"""On stocke la date du jour dans la variable ToD4y"""
-	
+
 	ToD4y = datetime.today()
-	
+
 	def print_today(ToD4y):
 		today = ToD4y
 		print(ToD4y)
-	
+
 	def GetToday():
 		return ToD4y
 
@@ -444,7 +435,7 @@ test.py:16:10: E0602: Undefined variable 'Get_Today' (undefined-variable)
 Your code has been rated at -5.45/10
 \end{verbatim}
 
-En gros, j'ai programmé comme une grosse bouse anémique (et oui: le score d'évaluation du code permet   d'aller en négatif). 
+En gros, j'ai programmé comme une grosse bouse anémique (et oui: le score d'évaluation du code permet   d'aller en négatif).
 En vrac, nous trouvons des problèmes liés:
 
 \begin{itemize}
@@ -472,19 +463,19 @@ chaque code possède sa signification:
 \item
   \textbf{E} pour les erreurs ou des bugs probablement présents dans le code
 \item
-  \textbf{F} pour les erreurs internes au fonctionnement de pylint, qui font que le traitement n'a pas pu aboutir. 
+  \textbf{F} pour les erreurs internes au fonctionnement de pylint, qui font que le traitement n'a pas pu aboutir.
 \end{itemize}
 
-Connaissant ceci, il est extrêmement pratique d'intégrer pylint au niveau des processus d'intégration continue, puisque la présence d'une 
+Connaissant ceci, il est extrêmement pratique d'intégrer pylint au niveau des processus d'intégration continue, puisque la présence d'une
 Pylint propose également une option particulièrement efficace, qui prend le paramètre \texttt{--errors-only}, et qui n'affiche que les occurrences appartenant à la catégorie \textbf{E}.
 
 Si nous souhaitons ignorer l'une de ces catégories, ce doit être fait explicitement: de cette manière, nous marquons notre approbation pour que pylint ignore consciemment un élément en particulier.
-Cet élément peut être: 
+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 projet entier}, en spécifiant la non-prise en compte au niveau du fichier \texttt{.pylintrc}, qui contient 
+\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}
 
 \subsection{Ignorer une ligne de code}
@@ -496,10 +487,10 @@ 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, ... 
-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. 
+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 
+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
 
 \begin{itemize}
 	\item Clarté du code
@@ -508,8 +499,8 @@ Même si elle n'est pas parfaite, la librairie \href{https://black.readthedocs.i
 \end{itemize}
 
 Est-ce que ce formatage est idéal et accepté par tout le monde ?
-\textbf{Non}. 
-Même Pylint arrivera parfois à râler. 
+\textbf{Non}.
+Même Pylint arrivera parfois à râler.
 Mais ce formatage conviendra dans 97,83\% des cas (au moins).
 
 \begin{quote}
@@ -535,7 +526,7 @@ vous concentrer sur le contenu}".
 
 \section{Typage statique \index{PEP585}}
 
-Nous vous disions ci-dessus que Python est un langage dynamique interprété. 
+Nous vous disions ci-dessus que Python est un langage dynamique interprété.
 Concrètement, cela signifie que des erreurs qui auraient pu avoir été détectées lors de la phase de compilation, ne le sont pas avec Python.
 
 Il existe cependant une solution à ce problème, sous la forme de \href{http://mypy-lang.org/}{Mypy}, qui peut vérifier une forme de typage statique de votre code source, grâce à une expressivité du code, basée sur des annotations.
@@ -545,10 +536,10 @@ Ces vérifications se présentent de la manière suivante:
 \begin{listing}[H]
 	\begin{minted}{python}
 	from typing import List
-	
+
 	def first_int_elem(l: List[int]) -> int:
 		return l[0] if l else None
-			
+
 	if __name__ == "__main__":
 		print(first_int_elem([1, 2, 3]))
 		print(first_int_elem(['a', 'b', 'c']))
@@ -561,7 +552,7 @@ Est-ce que le code ci-dessous fonctionne correctement ? \textbf{Oui}:
 \begin{listing}[H]
 	\begin{verbatim}
 	>>> python mypy-test.py
-	1	
+	1
 	a
 	\end{verbatim}
 \end{listing}
@@ -569,7 +560,7 @@ Est-ce que le code ci-dessous fonctionne correctement ? \textbf{Oui}:
 Malgré que nos annotations déclarent une liste d'entiers, rien ne nous empêche de lui envoyer une liste de caractères, sans que cela ne lui pose de problèmes.
 La signature de notre fonction n'est donc pas cohérente avec son comportement.
 
-Est-ce que Mypy va râler ? \textbf{Oui, aussi}. 
+Est-ce que Mypy va râler ? \textbf{Oui, aussi}.
 Non seulement nous retournons la valeur \texttt{None} si la liste est vide alors que nous lui annoncions un entier en sortie, mais en plus, nous l'appelons avec une liste de caractères, alors que nous nous attendons à une liste d'entiers:
 
 \begin{listing}[H]
@@ -595,7 +586,7 @@ Pour corriger ceci, nous devons:
 
 \section{Tests unitaires}
 
-Comme tout bon \textbf{langage de programmation moderne} qui se respecte, Python embarque tout un environnement facilitant le lancement de tests; 
+Comme tout bon \textbf{langage de programmation moderne} qui se respecte, Python embarque tout un environnement facilitant le lancement de tests;
 Une bonne pratique (parfois discutée) consiste cependant à switcher vers \texttt{pytest}, qui présente quelques avantages par rapport au module \texttt{unittest}:
 
 \begin{itemize}
@@ -624,7 +615,7 @@ complètement biesse; on est sur la partie théorique ici):
 	\end{minted}
 \end{listing}
 
-Forcément, cela va planter. 
+Forcément, cela va planter.
 Pour nous en assurer (dès fois que quelqu'un en doute), il nous suffit de démarrer la commande \texttt{pytest}:
 
 \begin{listing}
@@ -654,7 +645,7 @@ Pour nous en assurer (dès fois que quelqu'un en doute), il nous suffit de déma
 Avec \texttt{pytest}, il convient d'utiliser le paquet \href{https://pypi.org/project/pytest-cov/}{\texttt{pytest-cov}}, suivi de la commande \texttt{pytest\ -\/-cov=gwift\ tests/}.
 
 Si vous préférez rester avec le cadre de tests de Django, vous pouvez passer par le paquet\href{https://pypi.org/project/django-coverage-plugin/}{django-coverage-plugin}.
-Ajoutez-le dans le fichier \texttt{requirements/base.txt}, et lancez une couverture de code grâce à la commande \texttt{coverage}. 
+Ajoutez-le dans le fichier \texttt{requirements/base.txt}, et lancez une couverture de code grâce à la commande \texttt{coverage}.
 La configuration peut se faire dans un fichier \texttt{.coveragerc} que vous placerez à la racine de votre projet, et qui sera lu lors de l'exécution.
 
 \section{Gestion des versions de l'interpréteur}
@@ -665,17 +656,17 @@ La configuration peut se faire dans un fichier \texttt{.coveragerc} que vous pla
 
 \section{Matrice de compatibilité}
 
-Une matrice de compatibilité consiste à spécifier un ensemble de plusieurs versions d'un même interpréteur (ici, Python), afin de s'assurer que votre application continue à fonctionner. 
+Une matrice de compatibilité consiste à spécifier un ensemble de plusieurs versions d'un même interpréteur (ici, Python), afin de s'assurer que votre application continue à fonctionner.
 Nous sommes donc un cran plus haut que la spécification des versions des librairies, puisque nous nous situons directement au niveau de l'interpréteur.
 L'objectif consiste à définir un tableau à deux dimensions, dans lequel nous trouverons la compatibilité entre notre application et une version de l'interpréteur.
 
 \begin{center}
 	\begin{tabular}{|c|c|c|c|}
-	  & py37 & py38 & py39 \\ 
+	  & py37 & py38 & py39 \\
 	 \hline
 		lib2 & V & V & V \\
 		lib3 & X & V & V \\
-		lib4 & X & V & V   
+		lib4 & X & V & V
 	\end{tabular}
 \end{center}
 
@@ -703,7 +694,7 @@ L'outil le plus connu est \href{https://tox.readthedocs.io/en/latest/}{Tox}, qui
 
 Démarrez ensuite la commande \texttt{tox}, pour démarrer la commande \texttt{pytest} sur les environnements Python 3.6, 3.7, 3.8 et 3.9, après avoir installé nos dépendances présentes dans le fichier \texttt{requirements/dev.txt}.
 
-Pour que la commande ci-dessus fonctionne correctement, il sera nécessaire que vous ayez les différentes versions d'interpréteurs installées. 
+Pour que la commande ci-dessus fonctionne correctement, il sera nécessaire que vous ayez les différentes versions d'interpréteurs installées.
 Ci-dessus, la commande retournera une erreur pour chaque version non trouvée, avec une erreur type
 \texttt{ERROR:\ \ \ pyXX:\ InterpreterNotFound:\ pythonX.X}.
 
@@ -716,24 +707,24 @@ Décrire le fichier setup.cfg.
 
 \section{Makefile}
 
-Pour gagner un peu de temps, n'hésitez pas à créer un fichier \texttt{Makefile} que vous placerez à la racine du projet. 
+Pour gagner un peu de temps, n'hésitez pas à créer un fichier \texttt{Makefile} que vous placerez à la racine du projet.
 L'exemple ci-dessous permettra, grâce à la commande \texttt{make\ coverage}, d'arriver au même résultat que ci-dessus:
 
 \begin{listing}
 \begin{verbatim}
 	# Makefile for gwift
 	#
-	
+
 	# User-friendly check for coverage
 	ifeq ($(shell which coverage >/dev/null 2>&1; echo $$?), 1)
 		$(error The 'coverage' command was not found. Make sure you have coverage installed)
 	endif
-	
+
 	.PHONY: help coverage
-	
+
 	help:
 		@echo "  coverage to run coverage check of the source files."
-	
+
 	coverage:
 		coverage run --source='.' manage.py test; coverage report; coverage html;
 		@echo "Testing of coverage in the sources finished."
@@ -759,11 +750,11 @@ facteurs → Construction du fichier setup.cfg
   [flake8]
   max-line-length = 100
   exclude = .tox,.git,*/migrations/*,*/static/CACHE/*,docs,node_modules,venv
-  
+
   [pycodestyle]
   max-line-length = 100
   exclude = .tox,.git,*/migrations/*,*/static/CACHE/*,docs,node_modules,venv
-  
+
   [mypy]
   python_version = 3.8
   check_untyped_defs = True
@@ -772,14 +763,14 @@ facteurs → Construction du fichier setup.cfg
   warn_redundant_casts = True
   warn_unused_configs = True
   plugins = mypy_django_plugin.main
-  
+
   [mypy.plugins.django-stubs]
   django_settings_module = config.settings.test
-  
+
   [mypy-*.migrations.*]
   # Django migrations should not produce any errors:
   ignore_errors = True
-  
+
   [coverage:run]
   include = khana/*
   omit = *migrations*, *tests*

chapters/tests.tex

@@ -1,71 +1,68 @@
-
 \chapter{Tests unitaires et d'intégration}
 
 \begin{quote}
-Tests are part of the system.
-You can think of tests as the outermost circle in the architecture.
-Nothing within in the system depends on the tests, and the tests always depend inward on the components of the system.
+    Tests are part of the system.
+    You can think of tests as the outermost circle in the architecture.
+    Nothing within in the system depends on the tests, and the tests always depend inward on the components of the system.
 
--- Robert C. Martin, Clean Architecture
+    -- 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:
 
 \begin{enumerate}
-\item
-  Design aid: Writing tests first gives you a clearer perspective on the ideal API design.
-\item
-  Feature documentation (for developers): Test descriptions enshrine in code every implemented feature requirement.
-\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.
-\item
-  Continuous Delivery Aid: Automated QA affords the opportunity to automatically prevent broken builds from being deployed to production.
+    \item Design aid: Writing tests first gives you a clearer perspective on the ideal API design.
+    \item Feature documentation (for developers): Test descriptions enshrine in code every implemented feature requirement.
+    \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.
+    \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
-	  What component aspect are you testing?
-	\item
-	  What should the feature do? What specific behavior requirement are you testing?
+	\item What component aspect are you testing?
+	\item What should the feature do? What specific behavior requirement are you testing?
 \end{enumerate}
 
-Traduit grossièrement depuis un article sur \url{https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d\#.kfyvxyb21\%3E\%60_}:
+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\ldots. ??????"
 \begin{verbatim}
-Vos tests sont la première et la meilleure ligne de défense contre les défauts de programmation. Ils sont
+    Vos tests sont la première et la meilleure ligne de défense contre les défauts de programmation. Ils sont
 \end{verbatim}
 
+% TODO : Pourquoi il finit par ":" le verbatim ci-dessous ?
 \begin{verbatim}
-Les tests unitaires combinent de nombreuses fonctionnalités, qui en fait une arme secrète au service d'un développement réussi:
+    Les tests unitaires combinent de nombreuses fonctionnalités, qui en fait une arme secrète au service d'un développement réussi:
 \end{verbatim}
 
 \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.
-\item
-  Documentation (pour les développeurs): chaque description d'un test
-\item
-  Tester votre compréhension en tant que développeur:
-\item
-  Assurance qualité: des tests, 5.
+    \item
+        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 Tester votre compréhension en tant que développeur:
+    \item Assurance qualité: des tests, 5.
 \end{enumerate}
 
 
 \section{Complexité cyclomatique\index{McCabe}}
 
-La \href{https://fr.wikipedia.org/wiki/Nombre_cyclomatique}{complexité cyclomatique} (ou complexité de McCabe) peut s'apparenter à mesure de difficulté de compréhension du code, en fonction du nombre d'embranchements trouvés dans une même section. 
+La \href{https://fr.wikipedia.org/wiki/Nombre_cyclomatique}{complexité cyclomatique} (ou complexité de McCabe) peut s'apparenter à mesure de difficulté de compréhension du code, en fonction du nombre d'embranchements trouvés dans une même section.
 Quand le cycle d'exécution du code rencontre une condition, cette condition peut être évalue à VRAI ou à FAUX.
 L'exécution du code dispose donc de deux embranchements, correspondant chacun à un résultat de cette condition.
 
-Le code suivant \autoref{cyclomatic-simple-code} a une complexité cyclomatique 1; il s'agit du cas le plus simple que nous pouvons implémenter: l'exécution du code rentre dans la fonction (il y a un seul embranchement), et aucun bloc conditionnel n'est présent sur son chemin. 
+Le code suivant \autoref{cyclomatic-simple-code} a une complexité cyclomatique 1; il s'agit du cas le plus simple que nous pouvons implémenter : l'exécution du code rentre dans la fonction (il y a un seul embranchement), et aucun bloc conditionnel n'est présent sur son chemin.
 La complexité reste de 1.
 
 \begin{listing}[!hbpt]
@@ -93,18 +90,23 @@ Si nous complexifions cette fonction en vérifiant (par exemple) le jour de la s
 	\caption{Ajout d'une fonctionnalité essentielle et totalement indispensable}
 \end{listing}
 
-La complexité cyclomatique d'un bloc est évaluée sur base du nombre d'embranchements possibles; par défaut, sa valeur est de 1. 
+La complexité cyclomatique d'un bloc est évaluée sur base du nombre d'embranchements possibles; par défaut, sa valeur est de 1.
 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.  
+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.
 L'amélioration que nous visons ici est une amélioration \textbf{locale}, qui facilite la lecture d'un bloc spécifique, et pas d'un programme complet.
 
 "Améliorons" notre code ci-dessous, pour lui ajouter la possibilité de gérer les autres jours de la semaine:
@@ -134,7 +136,7 @@ L'amélioration que nous visons ici est une amélioration \textbf{locale}, qui f
 	\label{Impression du jour de la semaine, version naïve}
 \end{listing}
 
-La complexité de ce code est évaluée à 8, même si la complexité effective ne sera que de 7. 
+La complexité de ce code est évaluée à 8, même si la complexité effective ne sera que de 7.
 Extraire une méthode à partir de ce bloc pourra réduire la complexité de la fonction \mintinline{python}{print_current_date} n'améliorera rien et ne fera que déplacer le problème.
 Une solution serait de passer par un dictionnaire, de façon à ramener la complexité à 1:
 
@@ -161,20 +163,21 @@ Une solution serait de passer par un dictionnaire, de façon à ramener la compl
 
 \section{Types de tests}
 
-De manière générale, si nous nous rendons compte que les tests sont trop compliqués à écrire ou nous coûtent trop de temps, c’est sans doute que l’architecture de la solution n’est pas adaptée et que les composants sont couplés les uns aux autres. 
+De manière générale, si nous nous rendons compte que les tests sont trop compliqués à écrire ou nous coûtent trop de temps, c’est sans doute que l’architecture de la solution n’est pas adaptée et que les composants sont couplés les uns aux autres.
 Dans ces cas, il sera nécessaire de refactoriser le code, afin que chaque module puisse être testé
 indépendamment des autres. \cite{clean_code}
 
 Le plus important est de toujours corréler les phases de tests indépendantes du reste du travail (de développement, ici), en l’automatisant au plus près de sa source de création:
 
 \begin{quote}
-Martin Fowler observes that, in general, "a ten minute build [and test process] is perfectly within reason... 
-[We first] do the compilation and run tests that are more localized unit tests with the database completely stubbed out. Such tests can run very fast, keeping within the ten minutes guideline. 
-However any bugs that involve larger scale intercations, particularly those involving the real database, won’t be found. 
-The second stage build runs a different suite of tests [acceptance tests] that do hit the real database and involve more end-to-end behavior. 
-This suite may take a couple of hours to run.
+    Martin Fowler observes that, in general, "a ten minute build [and test process] is perfectly within reason\ldots
+    [We first] do the compilation and run tests that are more localized unit tests with the database completely stubbed out.
+    Such tests can run very fast, keeping within the ten minutes guideline.
+    However any bugs that involve larger scale intercations, particularly those involving the real database, won’t be found.
+    The second stage build runs a different suite of tests [acceptance tests] that do hit the real database and involve more end-to-end behavior.
+    This suite may take a couple of hours to run.
 
--- Robert C. Martin, Clean Architecture
+    -- Robert C. Martin, Clean Architecture
 \end{quote}
 
 \subsection{Tests unitaires}
@@ -185,38 +188,32 @@ This suite may take a couple of hours to run.
 \end{quote}
 
 Les tests unitaires ciblent typiquement une seule fonction, classe ou méthode, de manière isolée, en fournissant au développeur l’assurance que son code réalise ce qu’il en attend.
-Pour plusieurs raisons (et notamment en raison de performances), les tests unitaires utilisent souvent des données stubbées - pour éviter d’appeler le "vrai" service
+Pour plusieurs raisons (et notamment en raison de performances), les tests unitaires utilisent souvent des données stubbées - pour éviter d’appeler le "vrai" service.
 
 Le nombre de tests unitaires nécessaires à la couverture d'un bloc fonctionnel est au minimum égal à la complexité cyclomatique de ce bloc.
-Une possibilité pour améliorer la maintenance du code est de faire baisser ce nombre, et de le conserver sous un certain seuil. 
+Une possibilité pour améliorer la maintenance du code est de faire baisser ce nombre, et de le conserver sous un certain seuil.
 Certains recommandent de le garder sous une complexité de 10; d'autres de 5.
 
-Idéalement, chaque fonction ou méthode doit être testée afin de bien en valider le fonctionnement, indépendamment du reste des composants. 
-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, ...)
+Idéalement, chaque fonction ou méthode doit être testée afin de bien en valider le fonctionnement, indépendamment du reste des composants.
+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, \ldots)
 
-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}
 
 \begin{quote}
-	The objective of acceptance tests is to prove that our application does
-	what the customer meant it to.
+	The objective of acceptance tests is to prove that our application does 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, \ldots).
 
 \subsection{Tests d'intégration}
 
-Les tests d’intégration vérifient que l’application coopère correctement avec les systèmes
-périphériques
-
+Les tests d’intégration vérifient que l’application coopère correctement avec les systèmes périphériques.

chapters/tools.tex

@@ -2,29 +2,25 @@
 
 \section{Environnement de développement intégré \index{IDE}}
 
-Concrètement, nous pourrions tout à fait nous limiter à Notepad ou Notepad++. 
+Concrètement, nous pourrions tout à fait nous limiter à Notepad ou Notepad++.
 Mais à moins d'aimer se fouetter avec un câble USB, nous apprécions la complétion du code, la coloration syntaxique, l'intégration des tests unitaires et d'un debugger, ainsi que deux-trois sucreries qui feront plaisir à n'importe quel développeur.
 
-Si vous manquez d'idées ou si vous ne savez pas par où commencer:
+Si vous manquez d'idées ou si vous ne savez pas par où commencer :
 
 \begin{itemize}
-\item
-  \href{https://vscodium.com/}{VSCodium}, avec les plugins
-  \href{https://marketplace.visualstudio.com/items?itemName=ms-python.python}{Python}et
-  \href{https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens}{GitLens}
-\item
-  \href{https://www.jetbrains.com/pycharm/}{PyCharm}
-\item
-  \href{https://www.vim.org/}{Vim} avec les plugins
-  \href{https://github.com/davidhalter/jedi-vim}{Jedi-Vim} et
-  \href{https://github.com/preservim/nerdtree}{nerdtree}
+    \item
+        \href{https://vscodium.com/}{VSCodium}, avec les plugins
+        \href{https://marketplace.visualstudio.com/items?itemName=ms-python.python}{Python}et
+        \href{https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens}{GitLens}
+    \item
+        \href{https://www.jetbrains.com/pycharm/}{PyCharm}
+    \item
+        \href{https://www.vim.org/}{Vim} avec les plugins
+        \href{https://github.com/davidhalter/jedi-vim}{Jedi-Vim} et
+        \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,23 +35,18 @@ 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é. 
+\emph{A priori}, les IDE proposés ci-dessus fournissent par défaut ou \emph{via} des greffons un terminal intégré.
 Ceci dit, disposer d'un terminal séparé facilite parfois certaines tâches.
-A nouveau, si vous manquez d'idées:
+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.
-\item
-  Pour tout autre système, vous devriez disposer en natif de ce qu'il faut.
+    \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.
+    \item Pour tout autre système, vous devriez disposer en natif de ce qu'il faut.
 \end{enumerate}
 
 \begin{figure}[H]
@@ -67,76 +58,68 @@ A nouveau, si vous manquez d'idées:
 
 \section{Un gestionnaire de mots de passe}
 
-Nous en auront besoin pour gé(né)rer des phrases secrètes pour nos applications. 
-Si vous n'en utilisez pas déjà un, partez sur \href{https://keepassxc.org/}{KeepassXC}: il est multi-plateformes, suivi et s'intègre correctement aux différents environnements, tout en restant accessible.
+Nous en auront besoin pour gé(né)rer des phrases secrètes pour nos applications.
+Si vous n'en utilisez pas déjà un, partez sur \href{https://keepassxc.org/}{KeepassXC} : il est multi-plateformes, suivi et s'intègre correctement aux différents environnements, tout en restant accessible.
 
 \includegraphics{images/environment/keepass.png}
 
 \subsection{Un système de gestion de versions}
 
-Il existe plusieurs systèmes de gestion de versions. 
-Le plus connu/utilisé à l'heure actuelle est \href{https://git-scm.com/}{Git}, notamment pour sa (très) grande flexibilité et sa rapidité d'exécution. 
-Il est une aide précieuse pour développer rapidement des preuves de concept, switcher vers une nouvelle fonctionnalité, un bogue à réparer ou une nouvelle release à proposer au téléchargement. 
+Il existe plusieurs systèmes de gestion de versions.
+Le plus connu/utilisé à l'heure actuelle est \href{https://git-scm.com/}{Git}, notamment pour sa (très) grande flexibilité et sa rapidité d'exécution.
+Il est une aide précieuse pour développer rapidement des preuves de concept, switcher vers une nouvelle fonctionnalité, un bogue à réparer ou une nouvelle release à proposer au téléchargement.
 Ses deux plus gros défauts concernent sa courbe d'apprentissage pour les nouveaux venus et la complexité des actions qu'il permet de réaliser.
 
 \begin{figure}[H]
-\centering
-\includegraphics{images/xkcd-1597-git.png}
-\caption{\url{https://xkcd.com/1597/}}
+    \centering
+    \includegraphics{images/xkcd-1597-git.png}
+    \caption{\url{https://xkcd.com/1597/}}
 \end{figure}
 
 Même pour un développeur solitaire, un système de gestion de versions (quel qu'il soit) reste indispensable.
 
-Chaque "\textbf{branche}" correspond à une tâche à réaliser: un bogue à corriger (\emph{Hotfix A}), une nouvelle fonctionnalité à ajouter ou un "\emph{truc à essayer}" \footnote{Oui, comme dans "Attends, j'essaie vite un truc, si ça marche, c'est beau."} (\emph{Feature A} et \emph{Feature B}).
+Chaque "\textbf{branche}" correspond à une tâche à réaliser: un bogue à corriger (\emph{Hotfix A}), une nouvelle fonctionnalité à ajouter ou un "\emph{truc à essayer}"\footnote{Oui, comme dans "Attends, j'essaie vite un truc, si ça marche, c'est beau."} (\emph{Feature A} et \emph{Feature B}).
 
-Chaque "\textbf{commit}" correspond à une sauvegarde atomique d'un état ou d'un ensemble de modifications cohérentes entre elles.\footnote{Il convient donc de s'abstenir de modifier le CSS d'une application et la couche d'accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up.} 
+Chaque "\textbf{commit}" correspond à une sauvegarde atomique d'un état ou d'un ensemble de modifications cohérentes entre elles.\footnote{Il convient donc de s'abstenir de modifier le CSS d'une application et la couche d'accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up.}
 De cette manière, il est beaucoup plus facile pour le développeur de se concenter sur un sujet en particulier, dans la mesure où celui-ci ne doit pas obligatoirement être clôturé pour appliquer un changement de contexte.
 
 \begin{figure}[H]
-\centering
-\includegraphics{images/diagrams/git-workflow.png}
-\caption{Git en action}
+    \centering
+    \includegraphics{images/diagrams/git-workflow.png}
+    \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. 
-Il suffit alors de:
+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}
-\item
-  Sauver le travail en cours (\texttt{git\ add\ .\ \&\&\ git\ commit\ -m\ {[}WIP{]}})
-\item
-  Revenir sur la branche principale (\texttt{git\ checkout\ main})
-\item
-  Créer un "hotfix" (\texttt{git\ checkout\ -b\ hotfix/pci-compliance})
-\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!"})
-\item
-  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})
+    \item Sauver le travail en cours (\texttt{git\ add\ .\ \&\&\ git\ commit\ -m\ {[}WIP{]}})
+    \item Revenir sur la branche principale (\texttt{git\ checkout\ main})
+    \item Créer un "hotfix" (\texttt{git\ checkout\ -b\ hotfix/pci-compliance})
+    \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!"})
+    \item 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}
 
-Finalement, sachez qu'il existe plusieurs manières de gérer ces flux d'informations. 
+Finalement, sachez qu'il existe plusieurs manières de gérer ces flux d'informations.
 Les plus connus sont \href{https://www.gitflow.com/}{Gitflow} et \href{https://www.reddit.com/r/programming/comments/7mfxo6/a_branching_strategy_simpler_than_gitflow/}{Threeflow}.
 
 
 \subsection{Décrire ses changements}
 
-La description d'un changement se fait \emph{via} la commande \texttt{git\ commit}. 
-Il est possible de lui passer directement le message associé à ce changement grâce à l'attribut \texttt{-m}, mais c'est une pratique relativement déconseillée: un \emph{commit} ne doit effectivement pas obligatoirement être décrit sur une seule ligne. 
+La description d'un changement se fait \emph{via} la commande \texttt{git\ commit}.
+Il est possible de lui passer directement le message associé à ce changement grâce à l'attribut \texttt{-m}, mais c'est une pratique relativement déconseillée : un \emph{commit} ne doit effectivement pas obligatoirement être décrit sur une seule ligne.
 Une description plus complète, accompagnée des éventuels tickets ou références, sera plus complète, plus agréable à lire, et plus facile à revoir pour vos éventuels relecteurs.
 
-De plus, la plupart des plateformes de dépôts présenteront ces informations de manière ergonomique. Par exemple:
+De plus, la plupart des plateformes de dépôts présenteront ces informations de manière ergonomique.
+Par exemple :
 
 \begin{figure}[H]
-\centering
-\includegraphics{images/environment/gitea-commit-message.png}
-\caption{Un exemple de commit affiché dans Gitea}
+    \centering
+    \includegraphics{images/environment/gitea-commit-message.png}
+    \caption{Un exemple de commit affiché dans Gitea}
 \end{figure}
 
 La première ligne est reprise comme titre (normalement, sur 50 caractères maximum); le reste est repris comme de la description.
@@ -144,32 +127,33 @@ La première ligne est reprise comme titre (normalement, sur 50 caractères maxi
 \section{Bases de données}
 
 \begin{quote}
-  The database is really nothing more than a big bucket of bits where we store our data on a long term basis 
-  \cite[p. 281]{clean_architecture}
+    The database is really nothing more than a big bucket of bits where we store our data on a long term basis
+    \cite[p. 281]{clean_architecture}
 \end{quote}
 
-Django gère plusieurs moteurs de base de données. 
+Django gère plusieurs moteurs de base de données.
 Certains sont gérés nativement (PostgreSQL, MariaDB, SQLite); et \emph{a priori}, ces trois-là sont disponibles pour tous les systèmes d'exploitation.
 D'autres moteurs nécessitent des librairies tierces (Oracle, Microsoft SQL Server).
 
 \subsection{SQLite}
 
-Parfois, SQLite peut être une bonne option:
+Parfois, SQLite peut être une bonne option :
 
 \begin{quote}
-Write througput is the area where SQLite struggles the most, but there's not a ton of compelling data online about how it fares, so I got some of my own: I spun up a Equinix m3.large.x86 instance, and ran a slightly modified1 version of the SQLite kvtest2 program on it. 
-Writing 512 byte blobs as separate transactions, in WAL mode with synchronous=normal3, temp\_store=memory, and mmap enabled, I got 13.78$\mu$s per write, or \textasciitilde72,568 writes per second. Going a bit larger, at 32kb writes, I got 303.74$\mu$s per write, or \textasciitilde3,292 writes per second. 
-That's not astronomical, but it's certainly way more than most websites being used by humans need. 
-If you had 10 million daily active users, each one could get more than 600 writes per day with that.
+    Write througput is the area where SQLite struggles the most, but there's not a ton of compelling data online about how it fares, so I got some of my own: I spun up a Equinix m3.large.x86 instance, and ran a slightly modified1 version of the SQLite kvtest2 program on it.
+    Writing 512 byte blobs as separate transactions, in WAL mode with synchronous=normal3, temp\_store=memory, and mmap enabled, I got 13.78$\mu$s per write, or \textasciitilde72,568 writes per second.
+    Going a bit larger, at 32kb writes, I got 303.74$\mu$s per write, or \textasciitilde3,292 writes per second.
+    That's not astronomical, but it's certainly way more than most websites being used by humans need.
+    If you had 10 million daily active users, each one could get more than 600 writes per day with that.
 \end{quote}
 
 \begin{quote}
-Looking at read throughput, SQLite can go pretty far: with the same test above, I got a read throughput of \textasciitilde496,770 reads/sec (2.013$\mu$s/read) for the 512 byte blob. 
-Other people also report similar results 
+    Looking at read throughput, SQLite can go pretty far: with the same test above, I got a read throughput of \textasciitilde496,770 reads/sec (2.013$\mu$s/read) for the 512 byte blob.
+    Other people also report similar results
 
---- Expensify reports that you can get 4M QPS if you're willing to make some slightly more involved changes and use a beefier server.
-Four million QPS is enough that every internet user in the world could make \textasciitilde70 queries per day, with a little headroom left over. 
-Most websites don't need that kind of throughput. \cite{consider_sqlite}
+    --- Expensify reports that you can get 4M QPS if you're willing to make some slightly more involved changes and use a beefier server.
+    Four million QPS is enough that every internet user in the world could make \textasciitilde70 queries per day, with a little headroom left over.
+    Most websites don't need that kind of throughput. \cite{consider_sqlite}
 \end{quote}
 
 \subsection{MySQL/MariaDB}
@@ -178,23 +162,13 @@ 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.
+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.
 
 \begin{itemize}
-\item
-  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}
-\item
-  Pour \textbf{SQLite}, il existe
-  \href{https://sqlitebrowser.org/}{SQLiteBrowser} PHPMyAdmin ou
-  PgAdmin.
+    \item 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}
+    \item Pour \textbf{SQLite}, il existe \href{https://sqlitebrowser.org/}{SQLiteBrowser} PHPMyAdmin ou PgAdmin.
 \end{itemize}
 
 \section{Intégration continue}
@@ -202,4 +176,3 @@ utiliser.
 \subsection{Qualité du code}
 
 Code climate, SonarQube.
-

chapters/urls.tex

@@ -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

chapters/working-in-isolation.tex

@@ -1,29 +1,23 @@
 
 \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
-  Il est tout à fait envisagable que deux applications différentes soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d'une même dépendance.
-\item
-  Pour la reproductibilité d'un environnement spécifique, cela évite notamment les réponses type "Ca marche chez moi", puisque la construction du nouvel environnement fait partie intégrante du processus de développement et de la documentation du projet; grâce à elle, nous avons la possibilité de construire un environnement sain et d'appliquer des dépendances identiques, quelle que soit l'hôte destiné à accueillir le déploiment.
+    \item
+        Il est tout à fait envisagable que deux applications différentes soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d'une même dépendance.
+    \item
+        Pour la reproductibilité d'un environnement spécifique, cela évite notamment les réponses type "Ca marche chez moi", puisque la construction du nouvel environnement fait partie intégrante du processus de développement et de la documentation du projet; grâce à elle, nous avons la possibilité de construire un environnement sain et d'appliquer des dépendances identiques, quelle que soit l'hôte destiné à accueillir le déploiment.
 \end{enumerate}
 
 \begin{figure}
-  \centering
-  \includegraphics{images/it-works-on-my-machine.jpg}
-  \caption{It works on my machine}
-\end{figure}  
+    \centering
+    \includegraphics{images/it-works-on-my-machine.jpg}
+    \caption{It works on my machine}
+\end{figure}
 
 \section{Environnements virtuels}
 
@@ -32,29 +26,28 @@ occasioner des conflits entre les applications déployées:
     \includegraphics{images/xkcd-1987.png}
     \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:
 
 \begin{enumerate}
-\item
-    D'une installation de Python - \url{https://www.python.org/}
-\item
-    D'un terminal - voir le point \href{../environment/_index.xml\#un-terminal}{Un terminal}
+    \item
+        D'une installation de Python - \url{https://www.python.org/}
+    \item
+        D'un terminal - voir le point \href{../environment/_index.xml\#un-terminal}{Un terminal}
 \end{enumerate}
 
 
-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.
+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.
 
 
 \subsection{Poetry}
 
-Poetry se propose de gérer le projet au travers d'un fichier pyproject.toml. 
+Poetry se propose de gérer le projet au travers d'un fichier pyproject.toml.
 TOML (du nom de son géniteur, Tom Preston-Werner, légèrement CEO de GitHub à ses heures), se place comme alternative aux formats comme JSON, YAML ou INI.
 
 
@@ -63,12 +56,12 @@ TOML (du nom de son géniteur, Tom Preston-Werner, légèrement CEO de GitHub à
     $ tree django-gecko/
     django-gecko/
     django_gecko
-     __init__.py
-     pyproject.toml
-     README.rst
-     tests
-     __init__.py
-     test_django_gecko.py
+        __init__.py
+        pyproject.toml
+        README.rst
+        tests
+        __init__.py
+        test_django_gecko.py
     2 directories, 5 files
 \end{verbatim}
 
@@ -76,15 +69,14 @@ TOML (du nom de son géniteur, Tom Preston-Werner, légèrement CEO de GitHub à
 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
-\item
-  Un répertoires tests, libellé selon les standards de pytest
-\item
-  Un fichier README.rst (qui ne contient encore rien)
-\item
-  Un fichier pyproject.toml, qui contient ceci:
+    \item
+        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
+        Un fichier README.rst (qui ne contient encore rien)
+    \item
+        Un fichier pyproject.toml, qui contient ceci:
 \end{itemize}
 
 \begin{verbatim}
@@ -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
@@ -145,48 +126,33 @@ souhaitons l'utiliser, grâce à l'une des commandes suivantes:
     # Pour les deux
     (gwift-env) fred@aerys:~/Sources/.venvs/gwift-env$
 \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
@@ -197,7 +163,7 @@ différent de zéro le plus à gauche:
 
 L'avantage est donc que l'on spécifie une version majeure - mineure - patchée, et que l'on pourra spécifier accepter toute mise à jour jusqu'à la prochaine version majeure - mineure patchée (non incluse).
 
-Une bonne pratique consiste également, tout comme pour npm, à intégrer le fichier de lock (poetry.lock) dans le dépôt de sources: de cette manière, seules les dépendances testées (et intégrées) seront considérées sur tous les environnements de déploiement.
+Une bonne pratique consiste également, tout comme pour npm, à intégrer le fichier de lock (poetry.lock) dans le dépôt de sources : de cette manière, seules les dépendances testées (et intégrées) seront considérées sur tous les environnements de déploiement.
 
 Il est alors nécessaire de passer par une action manuelle (poetry update) pour mettre à jour le fichier de verrou, et assurer une mise à jour en sécurité (seules les dépendances testées sont prises en compte)
 et de qualité (tous les environnements utilisent la même version d'une dépendance).
@@ -238,27 +204,27 @@ Django = "^3.2.3"
 [...]
 \end{verbatim}
 
-Et contrairement à \texttt{pip}, pas besoin de savoir s'il faut pointer vers un fichier (\texttt{-r}) ou un dépôt VCS (\texttt{-e}), puisque Poetry va tout essayer, {[}dans un certain ordre{]}(\url{https://python-poetry.org/docs/cli/\#add}). 
+Et contrairement à \texttt{pip}, pas besoin de savoir s'il faut pointer vers un fichier (\texttt{-r}) ou un dépôt VCS (\texttt{-e}), puisque Poetry va tout essayer, {[}dans un certain ordre{]}(\url{https://python-poetry.org/docs/cli/\#add}).
 L'avantage également (et cela m'arrive encore souvent, ce qui fait hurler le runner de Gitlab), c'est qu'il n'est plus nécessaire de penser à épingler la dépendance que l'on vient d'installer parmi les fichiers de
 requirements, puisqu'elles s'y ajoutent automatiquement grâce à la commande \texttt{add}.
 
 \subsubsection{Python Packaging Made Easy}
 
-Cette partie dépasse mes compétences et connaissances, dans la mesure où je n'ai jamais rien packagé ni publié sur {[}pypi.org{]}(pypi.org). 
-Ce n'est pas l'envie qui manque, mais les idées et la nécessité. 
+Cette partie dépasse mes compétences et connaissances, dans la mesure où je n'ai jamais rien packagé ni publié sur {[}pypi.org{]}(pypi.org).
+Ce n'est pas l'envie qui manque, mais les idées et la nécessité.
 Ceci dit, Poetry propose un ensemble de règles et une préconfiguration qui (doivent) énormément facilite(r) la mise à disposition de librairies sur Pypi - et rien que ça, devrait ouvrir une partie de l'écosystème.
 
 Les chapitres 7 et 8 de {[}Expert Python Programming - Third Edtion{]}(\#), écrit par Michal Jaworski et Tarek Ziadé en parlent très bien:
 
 \begin{quote}
-Python packaging can be a bit overwhelming at first. The main reason for
-that is the confusion about proper tools for creating Python packages.
-Anyway, once you create your first package, you will se that this is as
-hard as it looks. Also, knowing propre, state-of-the-art packaging helps
-a lot.
+    Python packaging can be a bit overwhelming at first. The main reason for
+    that is the confusion about proper tools for creating Python packages.
+    Anyway, once you create your first package, you will se that this is as
+    hard as it looks. Also, knowing propre, state-of-the-art packaging helps
+    a lot.
 \end{quote}
 
-En gros, c'est ardu-au-début-mais-plus-trop-après. 
+En gros, c'est ardu-au-début-mais-plus-trop-après.
 Et c'est heureusement suivi et documenté par la PyPA (\textbf{\href{https://github.com/pypa}{Python Packaging Authority}}).
 
 Les étapes sont les suivantes:
@@ -274,7 +240,7 @@ Les étapes sont les suivantes:
   Définir un ensemble d'actions (voire, de plugins nécessaires - lien avec le VCS, etc.) dans le fichier \texttt{setup.py}, et définir les propriétés du projet ou de la librairie dans le fichier \texttt{setup.cfg}.
 \end{enumerate}
 
-Avec Poetry, deux commandes suffisent (théoriquement - puisque je n'ai pas essayé): \texttt{poetry\ build} et \texttt{poetry\ publish}:
+Avec Poetry, deux commandes suffisent (théoriquement - puisque je n'ai pas essayé) : \texttt{poetry\ build} et \texttt{poetry\ publish}:
 
 \begin{verbatim}
 $ poetry build
@@ -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}
@@ -314,7 +279,7 @@ Les solutions sont nombreuses:
   \href{https://docs.microsoft.com/fr-fr/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v}{Hyper-V}
 \end{itemize}
 
-Ces quelques propositions se situent un cran plus loin que la "simple" isolation d'un environnement, puisqu'elles vous permettront de construire un environnement complet. 
+Ces quelques propositions se situent un cran plus loin que la "simple" isolation d'un environnement, puisqu'elles vous permettront de construire un environnement complet.
 Elles constituent donc une étape supplémentaires dans la configuration de votre espace de travail, mais en amélioreront la qualité.
 
 Dans la suite, nous détaillerons Vagrant et Docker, qui constituent deux solutions automatisables et multiplateformes, dont la configuration peut faire partie intégrante de vos sources.
@@ -329,50 +294,37 @@ Vagrant consiste en un outil de création et de gestion d'environnements virtual
     automation, Vagrant lowers development environment setup time, increases
     production parity, and makes the "works on my machine" excuse a relic of
     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:
-    
-    \begin{itemize}
+\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:
+
+\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.
-    \end{itemize}
-    
-La syntaxe de ce fichier \texttt{Vagrantfile} est en \href{https://www.ruby-lang.org/en/}{Ruby}. 
+        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}.
 Vous trouverez ci-dessous un exemple, généré (et nettoyé) après avoir exécuté la commande \texttt{vagrant\ init}:
 
 \begin{listing}[H]
     \begin{minted}{ruby}
     # -*- mode: ruby -*-
     # vi: set ft=ruby :
-    
+
     Vagrant.configure("2") do |config|
-    
+
     config.vm.box = "ubuntu/bionic64"
     config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip:
     "127.0.0.1"
-    
+
     config.vm.provider "virtualbox" do |vb|
         vb.gui = true
         vb.memory = "1024"
@@ -389,14 +341,14 @@ Vous trouverez ci-dessous un exemple, généré (et nettoyé) après avoir exéc
 Dans le fichier ci-dessus, nous créons:
 
 \begin{itemize}
-\item
-  Une nouvelle machine virtuelle (ie. \emph{invitée}) sous Ubuntu Bionic Beaver, en x64
-\item
-  Avec une correspondance du port \texttt{80} de la machine vers le port \texttt{8080} de l'hôte, en limitant l'accès à celui-ci - accédez à \texttt{localhost:8080} et vous accéderez au port \texttt{80} de la machine virtuelle.
-\item
-  En utilisant Virtualbox comme backend - la mémoire vive allouée sera limitée à 1Go de RAM et nous ne voulons pas voir l'interface graphique au démarrage
-\item
-  Et pour finir, nous voulons appliquer un script de mise à jour \texttt{apt-get\ update} et installer le paquet \texttt{nginx}
+    \item
+        Une nouvelle machine virtuelle (ie. \emph{invitée}) sous Ubuntu Bionic Beaver, en x64
+    \item
+        Avec une correspondance du port \texttt{80} de la machine vers le port \texttt{8080} de l'hôte, en limitant l'accès à celui-ci - accédez à \texttt{localhost:8080} et vous accéderez au port \texttt{80} de la machine virtuelle.
+    \item
+        En utilisant Virtualbox comme backend - la mémoire vive allouée sera limitée à 1Go de RAM et nous ne voulons pas voir l'interface graphique au démarrage
+    \item
+        Et pour finir, nous voulons appliquer un script de mise à jour \texttt{apt-get\ update} et installer le paquet \texttt{nginx}
 \end{itemize}
 
 Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichier \texttt{Vagrantfile} se trouve) sera synchronisé dans le répertoire \texttt{/vagrant} sur la machine invitée.
@@ -410,7 +362,7 @@ Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichie
 \begin{listing}[H]
     \begin{verbatim}
     version: '3'
-    
+
     volumes:
         local_postgres_data: {}
         local_postgres_data_backups: {}
@@ -442,7 +394,7 @@ Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichie
 \end{listing}
 
 \begin{listing}[H]
-    \begin{verbatim}    
+    \begin{verbatim}
     postgres:
         build:
         context: .
@@ -542,7 +494,7 @@ Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichie
       - 8000:8000
       depends_on:
       - slqserver
-    
+
     slqserver:
       image: mcr.microsoft.com/mssql/server:2019-latest
       environment:
@@ -562,12 +514,12 @@ Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichie
 \begin{listing}[H]
 \begin{verbatim}
   FROM python:3.8-slim-buster
-  
+
   ENV PYTHONUNBUFFERED 1
   ENV PYTHONDONTWRITEBYTECODE 1
-  
+
   RUN apt-get update \
-  
+
     # dependencies for building Python packages
     && apt-get install -y build-essential \
     # psycopg2 dependencies
@@ -578,33 +530,33 @@ Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichie
     && apt-get purge -y --auto-remove -o
     APT::AutoRemove::RecommendsImportant=false \
     && rm -rf /var/lib/apt/lists/*
-    
+
   # Requirements are installed here to ensure they will be cached.
   COPY ./requirements /requirements
   RUN pip install -r /requirements/local.txt
-  
+
   COPY ./compose/production/django/entrypoint /entrypoint
   RUN sed -i 's/\r$//g' /entrypoint
   RUN chmod +x /entrypoint
-  
+
   COPY ./compose/local/django/start /start
   RUN sed -i 's/\r$//g' /start
   RUN chmod +x /start
-  
+
   COPY ./compose/local/django/celery/worker/start /start-celeryworker
   RUN sed -i 's/\r$//g' /start-celeryworker
   RUN chmod +x /start-celeryworker
-  
+
   COPY ./compose/local/django/celery/beat/start /start-celerybeat
   RUN sed -i 's/\r$//g' /start-celerybeat
   RUN chmod +x /start-celerybeat
-  
+
   COPY ./compose/local/django/celery/flower/start /start-flower
   RUN sed -i 's/\r$//g' /start-flower
   RUN chmod +x /start-flower
-  
+
   WORKDIR /app
-  
+
   ENTRYPOINT ["/entrypoint"]
 \end{verbatim}
 \end{listing}
@@ -617,39 +569,39 @@ Par défaut, le répertoire courant (ie. le répertoire dans lequel notre fichie
 
 		# Pull base image
 		FROM python:3.8-slim-buster
-		
+
 		# Set environment variables
 		ENV PYTHONDONTWRITEBYTECODE 1
 		ENV PYTHONUNBUFFERED 1
 		ENV DEBIAN_FRONTEND noninteractive
 		ENV ACCEPT_EULA=Y
-		
+
 		# install Microsoft SQL Server requirements.
 		ENV ACCEPT_EULA=Y
 		RUN apt-get update -y && apt-get update \
 		  && apt-get install -y --no-install-recommends curl gcc g++ gnupg
-		
-		
+
+
 		# Add SQL Server ODBC Driver 17
 		RUN curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
 		RUN curl https://packages.microsoft.com/config/debian/10/prod.list > /etc/apt/sources.list.d/mssql-release.list
 		RUN apt-get update \
 		  && apt-get install -y msodbcsql17 unixodbc-dev
-		
+
 		# clean the install.
 		RUN apt-get -y clean
-		
+
 		# Set work directory
 		WORKDIR /code
-		
+
 		# Install dependencies
 		COPY ./requirements/base.txt /code/requirements/
 		RUN pip install --upgrade pip
 		RUN pip install -r ./requirements/base.txt
-		
+
 		# Copy project
 		COPY . /code/
-		
+
 	\end{verbatim}
 	\caption{Un exemple de Dockerfile}
 \end{listing}

main.tex

@@ -12,7 +12,7 @@
 \usepackage{graphics}
 \usepackage{float}
 \usepackage[export]{adjustbox}
-
+\usepackage[left=2.5cm,bottom=3cm,right=2.5cm]{geometry}
 
 \renewcommand\listlistingname{Liste des morceaux de code}
 

parts/deployment.tex

@@ -10,92 +10,81 @@
     is seldom considered during initial development. This leads to
     architectures that may be make the system easy to develop, but leave it
     very difficult to deploy.
-    
+
     ---  Robert C. Martin Clean Architecture
 \end{quote}
-    
-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. 
-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
+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.
+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
 \cite{devops_handbook}.
 
-Déploier une nouvelle version sera aussi simple que de récupérer la dernière archive depuis le dépôt, la placer dans le bon répertoire, appliquer des actions spécifiques (et souvent identiques entre deux
-versions), puis redémarrer les services adéquats, et la procédure complète se résumera à quelques lignes d'un script bash.
+Déploier une nouvelle version sera aussi simple que de récupérer la dernière archive depuis le dépôt, la placer dans le bon répertoire, appliquer des actions spécifiques (et souvent identiques entre deux versions), puis redémarrer les services adéquats, et la procédure complète se résumera à quelques lignes d'un script bash.
 
 \begin{quote}
-Because value is created only when our services are running into production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and
-disruptions such as service outages, service impairments, or security or compliance failures.
+    Because value is created only when our services are running into production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and
+    disruptions such as service outages, service impairments, or security or compliance failures.
 
----  DevOps Handbook Introduction
+    ---  DevOps Handbook Introduction
 \end{quote}
 
 Le serveur que django met à notre disposition \emph{via} la commande \texttt{runserver} est extrêmement pratique, mais il est uniquement prévu pour la phase développement: en production, il est inutile de
-passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, \ldots\hspace{0pt}). De même, Django propose par défaut une base de données SQLite, qui fonctionne
-parfaitement dès lors que l'on connait ses limites et que l'on se limite à un utilisateur à la fois. En production, il est légitime que la base de donnée soit capable de supporter plusieurs utilisateurs et connexions simultanés. En restant avec les paramètres par défaut, il est plus que probable que vous rencontriez rapidement des erreurs de verrou parce qu'un autre processus a déjà pris la main pour écrire ses données. En bref, vous avez quelque chose qui fonctionne, qui répond à un besoin, mais qui va attirer la grogne de ses utilisateurs pour des problèmes de latences, pour des erreurs de verrou ou simplement parce que le serveur répondra trop lentement.
+passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, \ldots\hspace{0pt}).
+De même, Django propose par défaut une base de données SQLite, qui fonctionne parfaitement dès lors que l'on connait ses limites et que l'on se limite à un utilisateur à la fois.
+En production, il est légitime que la base de donnée soit capable de supporter plusieurs utilisateurs et connexions simultanés.
+En restant avec les paramètres par défaut, il est plus que probable que vous rencontriez rapidement des erreurs de verrou parce qu'un autre processus a déjà pris la main pour écrire ses données.
+En bref, vous avez quelque chose qui fonctionne, qui répond à un besoin, mais qui va attirer la grogne de ses utilisateurs pour des problèmes de latences, pour des erreurs de verrou ou simplement parce que le serveur répondra trop lentement.
 
 L'objectif de cette partie est de parcourir les différentes possibilités qui s'offrent à nous en termes de déploiement, tout en faisant en sorte que le code soit le moins couplé possible à sa destination de
-production. L'objectif est donc de faire en sorte qu'une même application puisse être hébergées par plusieurs hôtes sans avoir à subir de modifications. Nous vous renvoyons vers les 12-facteurs dont nous
-avons déjà parlé et qui vous énormément nous aider, puisque ce sont des variables d'environnement qui vont réellement piloter le câblage entre l'application, ses composants et son hébergeur.
+production.
+L'objectif est donc de faire en sorte qu'une même application puisse être hébergées par plusieurs hôtes sans avoir à subir de modifications.
+Nous vous renvoyons vers les 12-facteurs dont nous avons déjà parlé et qui vous énormément nous aider, puisque ce sont des variables d'environnement qui vont réellement piloter le câblage entre l'application, ses composants et son hébergeur.
 
-RedHat proposait récemment un article intitulé \emph{*What Is IaaS*}, qui présentait les principales différences entre types d'hébergement. 
+RedHat proposait récemment un article intitulé \emph{*What Is IaaS*}, qui présentait les principales différences entre types d'hébergement.
 
 \begin{figure}
-\centering
-\includegraphics{images/deployment/iaas_focus-paas-saas-diagram.png}
-\caption{L'infrastructure en tant que service, cc. \emph{RedHat Cloud
-Computing}}
+    \centering
+    \includegraphics{images/deployment/iaas_focus-paas-saas-diagram.png}
+    \caption{L'infrastructure en tant que service, cc. \emph{RedHat Cloud Computing}}
 \end{figure}
 
 Ainsi, on trouve:
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\item
-    Le déploiment \emph{on-premises} ou \emph{on-site}
-\item
-    Les \emph{Infrastructures as a service} ou \emph{IaaSIaaS}
-\item
-    Les \emph{Platforms as a service} ou \emph{PaaSPaaS}
-\item
-    Les \emph{Softwares as a service} ou \emph{SaaSSaaS}, ce dernier point
+    \def\labelenumi{\arabic{enumi}.} % TODO : a revoir -> définir des theme dans un fifhier STY non ?
+    \item Le déploiment \emph{on-premises} ou \emph{on-site}
+    \item Les \emph{Infrastructures as a service} ou \emph{IaaSIaaS}
+    \item Les \emph{Platforms as a service} ou \emph{PaaSPaaS}
+    \item Les \emph{Softwares as a service} ou \emph{SaaSSaaS}, ce dernier point
     nous concernant moins, puisque c'est nous qui développons le logiciel.
 \end{enumerate}
 
 Dans cette partie, nous aborderons les points suivants:
 
 \begin{enumerate}
-\item
-    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.
-\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.
+    \item
+        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.
+    \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.
 \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.
-\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.
+    \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.
+
+    \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.
 \end{itemize}

parts/environment.tex

@@ -1,75 +1,57 @@
 \part{Environnement et méthodes de travail}
 
 \begin{quote}
-Make it work, make it right, make it fast
+    Make it work, make it right, make it fast
 
----  Kent Beck
+    ---  Kent Beck
 \end{quote}
 
-En fonction de vos connaissances et compétences, la création d'une nouvelle application est une étape relativement facile à mettre en place. 
+En fonction de vos connaissances et compétences, la création d'une nouvelle application est une étape relativement facile à mettre en place.
 Le code qui permet de faire tourner cette application peut ne pas être élégant, voire buggé jusqu'à la moëlle, il pourra fonctionner et faire "preuve de concept".
 
-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. 
+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.
 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 ». 
+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 ».
 Pour paraphraser une partie de l'introduction du livre \emph{Clean Architecture} \cite{clean_architecture}:
 
 \begin{quote}
-Getting software right is hard: it takes knowledge and skills that most young programmers don't take the time to develop. 
-It requires a level of discipline and dedication that most programmers never dreamed they'd need. 
-Mostly, it takes a passion for the craft and the desire to be a professional.
+    Getting software right is hard: it takes knowledge and skills that most young programmers don't take the time to develop.
+    It requires a level of discipline and dedication that most programmers never dreamed they'd need.
+    Mostly, it takes a passion for the craft and the desire to be a professional.
 
----  Robert C. Martin Clean Architecture
+    ---  Robert C. Martin Clean Architecture
 \end{quote}
 
-Le développement d'un logiciel nécessite une rigueur d'exécution et des connaissances précises dans des domaines extrêmement variés. 
-Il nécessite également des intentions, des (bonnes) décisions et énormément d'attention. 
+Le développement d'un logiciel nécessite une rigueur d'exécution et des connaissances précises dans des domaines extrêmement variés.
+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}
-\def\labelenumi{\arabic{enumi}.}
-\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)
-\item
-  Se préparer une tisane en regardant nos flux RSS (pour peu que cette
-  technologie existe encore\ldots\hspace{0pt}).
+    \def\labelenumi{\arabic{enumi}.}
+    \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)
+    \item
+        Se préparer une tisane en regardant nos flux RSS (pour peu que cette technologie existe encore\ldots\hspace{0pt}).
 \end{enumerate}
 
 \begin{quote}
-  La poésie est "l'art d'évoquer et de suggérer les sensations, les impressions, les émotions les plus vives par l'union intense des sons, des rythmes, des harmonies, en particulier par les vers."
-  
-  -- https://www.larousse.fr/dictionnaires/francais/po%C3%A9sie/61960
-  \end{quote}
-  
-  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 \sout{parfois} souvent une expérience, des compétences ou une approche différente.
+    La poésie est "l'art d'évoquer et de suggérer les sensations, les impressions, les émotions les plus vives par l'union intense des sons, des rythmes, des harmonies, en particulier par les vers."
+
+    -- https://www.larousse.fr/dictionnaires/francais/po%C3%A9sie/61960
+\end{quote}
+
+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 \sout{parfois} souvent une expérience, des compétences ou une approche différente.

parts/principles.tex

@@ -1,40 +1,36 @@
 \part{Principes fondamentaux de Django}
 
-Dans cette partie, nous allons parler de plusieurs concepts fondamentaux au développement rapide d'une application utilisant Django. 
+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. 
-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}. 
+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}.
 
 \begin{center}
-\begin{tabular}{ |c|c|c| } 
- \hline
- tableau comparatif MVC vs MTV & cell2 & cell3 \\ 
- cell4 & cell5 & cell6 \\ 
- cell7 & cell8 & cell9 \\ 
- \hline
-\end{tabular}
+    \begin{tabular}{ |c|c|c| }
+        \hline
+        tableau comparatif MVC vs MTV & cell2 & cell3 \\
+        cell4 & cell5 & cell6 \\
+        cell7 & cell8 & cell9 \\
+        \hline
+    \end{tabular}
 \end{center}
 
 
 \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.
-\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.
-\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.
+    \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.
+    \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.
+    \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}
 
 Pour reprendre une partie du schéma précédent, lorsqu'une requête est émise par un utilisateur, la première étape va consister à trouver une \emph{route} qui correspond à cette requête, c'est à dire à trouver la
-correspondance entre l'URL qui est demandée par l'utilisateur et la fonction du langage qui sera exécutée pour fournir le résultat attendu. 
+correspondance entre l'URL qui est demandée par l'utilisateur et la fonction du langage qui sera exécutée pour fournir le résultat attendu.
 Cette fonction correspond au \textbf{contrôleur} et s'occupera de construire le \textbf{modèle} correspondant.

parts/soa.tex

@@ -1,21 +1,21 @@
 \part{Services Oriented Applications}
 
-Nous avons fait exprès de reprendre l'acronyme d'une \emph{Services Oriented Architecture} pour cette partie. L'objectif est de vous mettre
-la puce à l'oreille quant à la finalité du développement: que l'utilisateur soit humain, bot automatique ou client Web, l'objectif est de fournir des applications résilientes, disponibles et accessibles.
+Nous avons fait exprès de reprendre l'acronyme d'une \emph{Services Oriented Architecture} pour cette partie.
+L'objectif est de vous mettre la puce à l'oreille quant à la finalité du développement: que l'utilisateur soit humain, bot automatique ou client Web, l'objectif est de fournir des applications résilientes, disponibles et accessibles.
 
 Dans cette partie, nous aborderons les vues, la mise en forme, la mise 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}