Retrieve architecture image from data intensive apps

chapters/architecture.tex

@@ -38,7 +38,7 @@ Des équivalents à ces directives existent au niveau des composants, puis au ni
 
 \section{Modules}
 
-\subsection{Single Responsility Principle}
+\subsection{Single Responsility Principle} \label{SRP}
 
 Le principe de responsabilité unique conseille de disposer de concepts ou domaines d'activité qui ne s'occupent chacun que d'une et une seule
 chose. 
@@ -474,7 +474,7 @@ L’implémentation d’une imprimante multifonction aura tout son sens:
 
 \begin{listing}[H]
 	\begin{minted}[tabsize=4]{java}
-	public class AllInOnePrinter implements Printer extends IPrinter
+	public class AllInOnePrinter extends Printer implements IPrinter
 	{
 		public AllInOnePrinter(string name)
 		{
@@ -504,7 +504,7 @@ Tandis que l’implémentation d’une imprimante premier-prix ne servira pas à
 
 \begin{listing}[H]
 	\begin{minted}[tabsize=4]{java}
-	public class FirstPricePrinter implements Printer extends IPrinter
+	public class FirstPricePrinter extends Printer implements IPrinter
 	{
 		public FirstPricePrinter(string name)
 		{
@@ -723,7 +723,7 @@ Plus spécifiquement, la définition exacte devient celle-ci:
 
 Que l'on résumera ainsi: "don’t depend on things you don’t need", comme nous l'avons déjà expliqué plus haut.
 
-\subsection{Stable dependency principle}
+\subsection{Stable Dependency Principle} \label{SDP}
 
 Ce principe définit une formule de stabilité pour les composants, en fonction de leur faculté à être modifié et des composants qui dépendent de lui: au plus un composant est nécessaire, au plus il sera stable (dans la mesure où il lui sera difficile de changer). 
 En C++, cela correspond aux mots clés \#include. 
@@ -731,7 +731,7 @@ Pour faciliter cette stabilité, il convient de passer par des interfaces (donc,
 
 En Python, ce ratio pourrait être calculé au travers des import, via les AST.
 
-\subsection{Stable Abstraction Principle}
+\subsection{Stable Abstraction Principle} \label{SAP}
 
 Ce principe-ci définit les politiques de haut niveau vs les composants plus concrets. 
 SAP est juste une modélisation du OCP pour les composants: nous plaçons ceux qui ne changent pas ou pratiquement pas le plus haut possible dans l'organigramme (ou le diagramme), et ceux qui changent souvent plus bas, dans le sens de stabilité du flux. 

chapters/infrastructure.tex

@@ -1,5 +1,11 @@
 \chapter{Infrastructure et composants}
 
+\begin{figure}[H]
+  \centering
+  \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/diagrams/infrastructure.drawio.png}}
+  \caption{Une architecture possible pour un système de données, qui combine plusieurs composants \cite[p. 5]{data_intensive}}
+\end{figure}
+
 Pour une mise ne production, le standard \emph{de facto} est le suivant:
 
 \begin{itemize}
@@ -94,7 +100,7 @@ Comme nous l'avons vu dans la première partie, Django est un framework complet,
 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. 
+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
@@ -159,7 +165,7 @@ exemples}.
     \item
       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}.

chapters/new-project.tex

@@ -705,3 +705,6 @@ En relançant la couverture de code, on voit à présent que nous arrivons à 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.
+
+A noter que tester le modèle en lui-même (ses attributs ou champs) ou des composants internes à Django n'a pas de sens: cela reviendrait à mettre en doute son fonctionnement interne.
+Selon le principe du SRP \ref{SRP}, c'est le framework lui-même qui doit en assurer la maintenance et le bon fonctionnement.

parts/deployment.tex

@@ -1,6 +1,11 @@
 \part{Déploiement}
 
-\includegraphics{images/penguin-overflow.jpg}
+\begin{figure}[H]
+    \centering
+    \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/penguin-overflow.jpg}}
+    \caption{David Revoy}
+\end{figure}
+
 
 \begin{quote}
     To be effective, a software system must be deployable. The higher the
@@ -10,21 +15,19 @@
     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. 
+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 à
+En cas de dérogation à ceci, il sera probable d'oublier une partie des désidérata, de zapper une fonctionnalité essentielle ou simplement de passer énormément de temps à adapter les sources pour qu'elles puissent être mises à disposition sur un environnement en particulier, une fois que leur développement aura été finalisé, testé et validé.
-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é.
-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
+Déploier une nouvelle version doit être le plus simple possible, et doit se résumer, dans le pire des cas, à quelques lignes d'un script Bash.
-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
@@ -33,35 +36,39 @@ disruptions such as service outages, service impairments, or security or complia
 ---  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
+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.
-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
+En production:
-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.
+
+\begin{itemize}
+    \item Il est inutile de passer par du code Python pour charger des fichiers statiques (feuilles de style, fichiers JavaScript, images, ...
+    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.
+    \item 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.
+\end{itemize}
 
 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.
+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ébergement.
 
-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}
+\begin{figure}[H]
-\centering
+    \centering
-\includegraphics{images/deployment/iaas_focus-paas-saas-diagram.png}
+    \scalebox{1.0}{\includegraphics[max size={\textwidth}{\textheight}]{images/deployment/iaas_focus-paas-saas-diagram.png}}
-\caption{L'infrastructure en tant que service, cc. \emph{RedHat Cloud
+    \caption{L'infrastructure en tant que service, cc. \emph{RedHat Cloud Computing}}
-Computing}}
 \end{figure}
 
 Ainsi, on trouve:
 
 \begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
 \item
-    Le déploiment \emph{on-premises} ou \emph{on-site}
+    Le déploiment \emph{on-premises} ou \emph{on-site},
 \item
-    Les \emph{Infrastructures as a service} ou \emph{IaaSIaaS}
+    Les \emph{Infrastructures as a Service} ou \emph{IaaS}
 \item
-    Les \emph{Platforms as a service} ou \emph{PaaSPaaS}
+    Les \emph{Platforms as a Service} ou \emph{PaaS}
 \item
-    Les \emph{Softwares as a service} ou \emph{SaaSSaaS}, ce dernier point
+    Les \emph{Softwares as a service} ou \emph{SaaS}, ce dernier point
     nous concernant moins, puisque c'est nous qui développons le logiciel.
 \end{enumerate}