About dependencies...

chapters/architecture.tex

@@ -623,6 +623,10 @@ Dans l'exemple ci-dessus, l'utilisation du module \texttt{is-odd} requière déj
 
 Imaginez la suite.
 
+Réduire le nombre de dépendances accélère également l'intégration d'une personne souhaitant participer au projet: n'ajoutez pas de nouvelles dépendances à moins que leur plus-value ne surpasse le temps qu'il sera nécessaire à vos développeurs actuels et futurs pour en appréhender toutes les fonctionnalités \cite[Simplicity]{django_for_startup_founders}.
+Soyez intelligents et n'ajoutez pas systématiquement une nouvelle dépendance ou fonctionnalité uniquement parce qu'elle est disponible, et maintenez la documentation nécessaire à une utilisation cohérente d'une dépendance par rapport à vos objectifs et au reste de l'application.
+Conserver des dépendances à jour peut facilement vous prendre 25\% de votre temps \cite[Upgradability]{django_for_startup_founders}: dès que vous arrêterez de les suivre, vous risquez de rencontrer des bugs mineurs, des failles de sécurité, voire qu'elles ne soient plus du tout compatibles avec d'autres morceaux de vos applications.
+
 \subsection{Dependency Inversion}
 
 Dans une architecture conventionnelle, les composants de haut-niveau dépendent directement des composants de bas-niveau.

chapters/python.tex

@@ -213,10 +213,10 @@ Ceci implique aussi de \textbf{tout} documenter: les modules, les paquets, les c
 \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
 \item
-  S'il est nécessaire de décrire un comportement au sein-même d'une fonction, avec un commentaire \emph{inline}, c'est que ce comportement pourrait être extrait dans une nouvelle fonction (qui, elle, pourra être documentée proprement
+  S'il est nécessaire de décrire un comportement au sein-même d'une fonction, avec un commentaire \emph{inline}, c'est que ce comportement pourrait être extrait dans une nouvelle fonction (qui, elle, pourra être documentée proprement).
 \end{itemize}
 
-Documentation: be obsessed! Mais \textbf{le code reste la référence}
+En résumé, vous pouvez être obsédé par la documentation, mais \textbf{le code reste la référence}.
 
 Il existe plusieurs types de balisages reconnus/approuvés:
 

chapters/working-in-isolation.tex

@@ -1,7 +1,8 @@
 
 \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:
@@ -44,13 +45,11 @@ Pour créer un nouvel environnement, vous aurez donc besoin:
 Il existe plusieurs autres modules permettant d'arriver au même résultat, avec quelques avantages et inconvénients pour chacun d'entre eux.
 Le plus prometteur d'entre eux est \href{https://python-poetry.org/}{Poetry}, qui dispose d'une interface en ligne de commande plus propre et plus moderne que ce que PIP propose.
 
-
 \subsection{Poetry}
 
 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.
 
-
 \begin{verbatim}
     $ poetry new django-gecko
     $ tree django-gecko/
@@ -65,7 +64,6 @@ TOML (du nom de son géniteur, Tom Preston-Werner, légèrement CEO de GitHub à
     2 directories, 5 files
 \end{verbatim}
 
-
 Ceci signifie que nous avons directement (et de manière standard):
 
 \begin{itemize}
@@ -105,7 +103,7 @@ Cette séparation évite que l'environnement virtuel ne se trouve dans le même
 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}.
+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 stockage}.
 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:
@@ -121,8 +119,10 @@ Votre environnement virtuel est prêt, il n'y a plus qu'à indiquer que nous sou
 \begin{verbatim}
     # GNU/Linux, macOS
     source ~/.venvs/gwift-venv/bin/activate
+
     # MS Windows, avec Cmder
     ~/.venvs/gwift-venv/Scripts/activate.bat
+
     # Pour les deux
     (gwift-env) fred@aerys:~/Sources/.venvs/gwift-env$
 \end{verbatim}