diff --git a/chapters/architecture.tex b/chapters/architecture.tex index 89db44e..3046f2c 100644 --- a/chapters/architecture.tex +++ b/chapters/architecture.tex @@ -693,10 +693,6 @@ Dans d'autres projets écrits en Python, ce type de mécanisme peut être implé Un autre exemple concerne les bases de données: pour garder un maximum de flexibilité, Django ajoute une couche d'abstraction en permettant de spécifier le moteur de base de données que vous souhaiteriez utiliser, qu'il s'agisse d'SQLite, MSSQL, Oracle, PostgreSQL ou MySQL/MariaDB \footnote{\url{http://howfuckedismydatabase.com/}}. -\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} -\end{quote} - D'un point de vue architectural, nous ne devons pas nous soucier de la manière dont les données sont stockées, s'il s'agit d'un disque magnétique, de mémoire vive, ... en fait, on ne devrait même pas savoir s'il y a un disque du tout. Et Django le fait très bien pour nous. diff --git a/chapters/new-project.tex b/chapters/new-project.tex index a1ac758..85bce60 100644 --- a/chapters/new-project.tex +++ b/chapters/new-project.tex @@ -521,10 +521,11 @@ On a deux choix ici: \subsection{Couverture de code} -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 ---cov=gwift tests/. +\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. 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. @@ -551,6 +552,10 @@ La configuration peut se faire dans un fichier .coveragerc que vous placerez à directory = coverage_html_report \end{verbatim} +Nous pouvons à présent jouer au jeu de la couverture, qui consiste à augmenter ou égaliser la couverture existante à chaque nouvelle fonctionnalité ajoutée ou bug corrigé. +De cette manière, sans arriver à une couverture de 100\%, chaque modification du code améliorera la base existante. \footnote{cf. Two Scoops of Django}. +Suivant l'outil d'intégration continue que vous utiliserez, cette évolution pourra être affichée à chaque demande de fusion, et pourra être considérée comme un indicateur de qualité. + \begin{verbatim} $ coverage run --source "." manage.py test diff --git a/chapters/python.tex b/chapters/python.tex index 56fa370..5c7c359 100644 --- a/chapters/python.tex +++ b/chapters/python.tex @@ -665,8 +665,20 @@ La configuration peut se faire dans un fichier \texttt{.coveragerc} que vous pla \section{Matrice de compatibilité} -L'intérêt de la 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 \\ + \hline + lib2 & V & V & V \\ + lib3 & X & V & V \\ + lib4 & X & V & V + \end{tabular} +\end{center} + L'outil le plus connu est \href{https://tox.readthedocs.io/en/latest/}{Tox}, qui consiste en un outil basé sur virtualenv et qui permet: diff --git a/chapters/tools.tex b/chapters/tools.tex index ff1e45f..18770ca 100644 --- a/chapters/tools.tex +++ b/chapters/tools.tex @@ -1,6 +1,6 @@ \chapter{Outils de développement} -\section{Environnement de développement} +\section{Environnement de développement intégré \index{IDE}} 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. @@ -32,16 +32,22 @@ développeur impatient. \caption{Codium en action} \end{figure} + +\subsection{Greffons} + +\subsection{settings.json} + +\subsection{Mode debug - launch.json} + + \section{Terminal} -\emph{A priori}, les IDE \footnote{Integrated Development Environment} -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. - +\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: \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 @@ -58,30 +64,6 @@ A nouveau, si vous manquez d'idées: \caption{Mise en abîme} \end{figure} -\section{Un gestionnaire de base de données} - -Django gère plusieurs moteurs de base de données. -Certains sont gérés nativement par Django (PostgreSQL, MariaDB, SQLite); \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). - -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. -\end{itemize} \section{Un gestionnaire de mots de passe} @@ -161,6 +143,17 @@ 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} +\end{quote} + +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: \begin{quote} @@ -179,5 +172,34 @@ Four million QPS is enough that every internet user in the world could make \tex Most websites don't need that kind of throughput. \cite{consider_sqlite} \end{quote} +\subsection{MySQL/MariaDB} +\subsection{PostgreSQL} + +\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. + +\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. +\end{itemize} + +\section{Intégration continue} + +\subsection{Qualité du code} + +Code climate, SonarQube.