Delete latex (too complicated for my little brain)
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
a6519ed11a
commit
1af4d4c8f2
|
|
@ -1,7 +0,0 @@
|
|||
compile_pdf:
|
||||
image: ddidier/sphinx-doc
|
||||
script:
|
||||
- make latexpdf
|
||||
artifacts:
|
||||
paths:
|
||||
- build/latex/Gwift.pdf
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
\documentclass[a4paper,12pt]{book}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{hyperref}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\author{Cédric Declerfayt, Frederick Pauchet}
|
||||
\title{Minor swing with Django}
|
||||
\date{2016-2032}
|
||||
|
||||
\frontmatter
|
||||
\maketitle
|
||||
\tableofcontents
|
||||
|
||||
\mainmatter
|
||||
\part{Environnement de travail}
|
||||
|
||||
\chapter{Construire des applications maintenables}
|
||||
\section{12 facteurs}
|
||||
|
||||
Pour la méthode de travail et de développement, nous allons nous baser sur les \href{https://12factor.net/fr/}{Twelve-factorApp} - ou plus simplement les 12 facteurs.
|
||||
L’idée derrière cette méthode, et indépendamment des langages de développement utilisés, consisteà suivre un ensemble de douze concepts, afin de:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Faciliter la mise en place de phases d’automatisation; plus concrètement, de faciliter lesmises à jour applicatives, simplifier la gestion de l’hôte, diminuer la divergence entre lesdifférents environnements d’exécution et offrir la possibilité d’intégrer le projet dans unprocessus d’intégration continue ou déploiement continu
|
||||
\item Faciliter la mise à pied de nouveaux développeurs ou de personnes souhaitant rejoindrele projet, dans la mesure où la mise à disposition d’un environnement sera grandementfacilitée
|
||||
\item Minimiser les divergences entre les différents environnemens sur lesquels un projetpourrait être déployé
|
||||
\item Augmenter l’agilité générale du projet, en permettant une meilleure évolutivité architecturale et une meilleure mise à l’échelle - Vous avez 5000 utilisateurs en plus? Ajoutez un serveur et on n’en parle plus ;-)
|
||||
\end{enumerate}
|
||||
|
||||
En pratique, les points ci-dessus permettront de monter facilement 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 de manière très brute les différentes idées derrière cette méthode, nous avons:
|
||||
|
||||
\begin{enumerate}
|
||||
\item ...
|
||||
\item ...
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Une base de code unique, suivie par un système de contrôle de versions}
|
||||
|
||||
\chapter{Boite à outils}
|
||||
\chapter{Un projet Python}
|
||||
\chapter{Un projet Django}
|
||||
|
||||
|
||||
\part{Déploiement}
|
||||
\chapter{Infrastructure et composants}
|
||||
\chapter{Code source}
|
||||
\chapter{Supervision et mise à disposition}
|
||||
\chapter{Méthodes de déploiement}
|
||||
\chapter{Ressources}
|
||||
|
||||
\part{Backend}
|
||||
\chapter{Modélisation}
|
||||
\chapter{Migrations}
|
||||
\chapter{Administration}
|
||||
\chapter{Authentification}
|
||||
\chapter{Shell}
|
||||
|
||||
\part{Frontend}
|
||||
\chapter{Formulaires}
|
||||
\chapter{Vues}
|
||||
\chapter{Templates}
|
||||
\chapter{URLs et espaces de noms}
|
||||
|
||||
\part{Concepts périphériques}
|
||||
\chapter{Logging}
|
||||
\chapter{Tests unitaires}
|
||||
|
||||
\part{Go Live}
|
||||
\chapter{Gwift}
|
||||
|
||||
\chapter{Khana}
|
||||
|
||||
\chapter{Applications \textit{Legacy}}
|
||||
|
||||
\chapter{Refactoring}
|
||||
|
||||
\backmatter
|
||||
% bibliography, glossary and index would go here.
|
||||
|
||||
\end{document}
|
||||
|
|
@ -2,15 +2,17 @@
|
|||
|
||||
Avant de démarrer le développement, il est nécessaire de passer un peu de temps sur la configuration de l'environnement.
|
||||
|
||||
Les morceaux de code que vous trouverez ci-dessous seront développés pour Python3.6+ et Django 3.0+. Ils nécessiteront peut-être quelques adaptations pour fonctionner sur une version antérieure.
|
||||
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.
|
||||
|
||||
Django fonctionne sur un https://docs.djangoproject.com/en/dev/internals/release-process/[roulement de trois versions mineures pour une version majeure], clôturé par une version LTS (_Long Term Support_).
|
||||
|
||||
image::images/django-support-lts.png[]
|
||||
|
||||
La version utilisée sera une bonne indication à prendre en considération pour nos dépendances, puisqu'en visant une version particulière, nous ne devrons pratiquement pas nous soucier (bon, un peu quand même...) des dépendances à installer, pour peu que l'on reste sous un certain seuil.
|
||||
La version utilisée sera une bonne indication à prendre en considération pour nos dépendances, puisqu'en visant une version particulière, nous ne devrons pratiquement pas nous soucier (bon, un peu quand même, mais nous le verrons plus tard...) des dépendances à installer, pour peu que l'on reste sous un certain seuil.
|
||||
|
||||
Dans cette partie, nous allons parler de *méthode 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:
|
||||
Dans cette partie, nous allons parler de *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:
|
||||
|
||||
. démarrer un script,
|
||||
. prévoir un rollback si cela plante
|
||||
|
|
|
|||
|
|
@ -15,15 +15,50 @@ Chacune d'entre elles doit être approuvée par le http://fr.wikipedia.org/wiki/
|
|||
|
||||
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: https://gto76.github.io/python-cheatsheet/[Python Cheat Sheet].
|
||||
|
||||
NOTE: Le langage Python utilise un typage dynamique appelé https://fr.wikipedia.org/wiki/Duck_typing[*duck typing*]: "_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_" (Source: http://en.wikipedia.org/wiki/Duck_test[Wikipedia (as usual)]).
|
||||
NOTE: Le langage Python utilise un typage dynamique appelé https://fr.wikipedia.org/wiki/Duck_typing[*duck typing*]: "_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_"
|
||||
Source: http://en.wikipedia.org/wiki/Duck_test[Wikipedia].
|
||||
|
||||
==== The Zen of Python
|
||||
|
||||
[source,python]
|
||||
----
|
||||
>>> import this
|
||||
----
|
||||
|
||||
[source,text]
|
||||
----
|
||||
The Zen of Python, by Tim Peters
|
||||
|
||||
Beautiful is better than ugly.
|
||||
Explicit is better than implicit.
|
||||
Simple is better than complex.
|
||||
Complex is better than complicated.
|
||||
Flat is better than nested.
|
||||
Sparse is better than dense.
|
||||
Readability counts.
|
||||
Special cases aren't special enough to break the rules.
|
||||
Although practicality beats purity.
|
||||
Errors should never pass silently.
|
||||
Unless explicitly silenced.
|
||||
In the face of ambiguity, refuse the temptation to guess.
|
||||
There should be one-- and preferably only one --obvious way to do it.
|
||||
Although that way may not be obvious at first unless you're Dutch.
|
||||
Now is better than never.
|
||||
Although never is often better than *right* now.
|
||||
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!
|
||||
----
|
||||
|
||||
|
||||
==== PEP8 - Style Guide for Python Code
|
||||
|
||||
La première PEP qui va nous intéresser est la https://www.python.org/dev/peps/pep-0008/[PEP 8 -- Style Guide for Python Code]. 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, ...
|
||||
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: pep8. Pour l'installer, passez par pip. Lancez ensuite la commande pep8 suivie du chemin à analyser (`.`, le nom d'un répertoire, le nom d'un fichier `.py`, ...). Si vous souhaitez uniquement avoir le nombre d'erreur de chaque type, saisissez les options `--statistics -qq`.
|
||||
|
||||
Dans cet objectif, un outil existe et listera l'ensemble des conventions qui ne sont pas correctement suivies dans votre projet: pep8.
|
||||
Pour l'installer, passez par pip. Lancez ensuite la commande pep8 suivie du chemin à analyser (`.`, le nom d'un répertoire, le nom d'un fichier `.py`, ...).
|
||||
Si vous souhaitez uniquement avoir le nombre d'erreur de chaque type, saisissez les options `--statistics -qq`.
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -168,7 +203,8 @@ Nous trouvons des erreurs:
|
|||
* de *conventions*: le nombre de lignes qui séparent deux fonctions, le nombre d'espace après un opérateur, une ligne vide à la fin du fichier, ... Ces _erreurs_ n'en sont pas vraiment, elles indiquent juste de potentiels problèmes de communication si le code devait être lu ou compris par une autre personne.
|
||||
* de *définition*: une variable assignée mais pas utilisée ou une lexème non trouvé. Cette dernière information indique clairement un bug potentiel. Ne pas en tenir compte nuira sans doute à la santé de votre code (et risque de vous réveiller à cinq heures du mat', quand votre application se prendra méchamment les pieds dans le tapis).
|
||||
|
||||
L'étape d'après consiste à invoquer pylint. Lui, il est directement moins conciliant:
|
||||
L'étape d'après consiste à invoquer pylint.
|
||||
Lui, il est directement moins conciliant:
|
||||
|
||||
|
||||
[source,text]
|
||||
|
|
@ -195,7 +231,8 @@ test.py:16:10: E0602: Undefined variable 'Get_Today' (undefined-variable)
|
|||
Your code has been rated at -5.45/10
|
||||
----
|
||||
|
||||
En gros, j'ai programmé comme une grosse bouse anémique (et oui, le score d'évaluation du code permet bien d'aller en négatif). En vrac, on trouve des problèmes liés:
|
||||
En gros, j'ai programmé comme une grosse bouse anémique (et oui: le score d'évaluation du code permet bien d'aller en négatif).
|
||||
En vrac, nous trouvons des problèmes liés:
|
||||
|
||||
* au nommage (C0103) et à la mise en forme (C0305, C0326, W0105)
|
||||
* à des variables non définies (E0602)
|
||||
|
|
@ -213,23 +250,30 @@ Pour reprendre la http://pylint.pycqa.org/en/latest/user_guide/message-control.h
|
|||
|
||||
TODO: Expliquer comment faire pour tagger une explication.
|
||||
|
||||
TODO: Voir si la sortie de pylint est obligatoirement 0 s'il y a un warning
|
||||
|
||||
TODO: parler de `pylint --errors-only`
|
||||
|
||||
|
||||
==== 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 _linter_ pour nous indiquer quels morceaux de code doivent absolument être revus, ...
|
||||
Reste que ces tâches sont [line-through]#parfois# (très) souvent fastidieuses: écrire un code propre et systématiquement cohérent est une tâche ardue. Heureusement, il existe des outils pour nous aider (un peu).
|
||||
Reste que ces tâches sont [line-through]#parfois# (très) souvent fastidieuses: écrire un code propre et systématiquement cohérent est une tâche ardue.
|
||||
Heureusement, il existe des outils pour nous aider (un peu).
|
||||
|
||||
A nouveau, il existe plusieurs possibilités de formatage automatique du code.
|
||||
Même si elle n'est pas parfaite, https://black.readthedocs.io/en/stable/[Black] arrive à un compromis entre la clarté du code, la facilité d'installation et d'intégration et un résultat.
|
||||
Même si elle n'est pas parfaite, https://black.readthedocs.io/en/stable/[Black] arrive à un compromis entre clarté du code, facilité d'installation et d'intégration et résultat.
|
||||
|
||||
Est-ce que ce formatage est idéal et accepté par tout le monde ?
|
||||
Non. Même Pylint arrivera parfois à râler.
|
||||
**Non**. Même Pylint arrivera parfois à râler.
|
||||
Mais ce formatage conviendra dans 97,83% des cas (au moins).
|
||||
|
||||
> By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.
|
||||
>
|
||||
> Black makes code review faster by producing the smallest diffs possible. Blackened code looks the same regardless of the project you’re reading. Formatting becomes transparent after a while and you can focus on the content instead.
|
||||
|
||||
Traduit rapidement à partir de la langue de Batman: "_En utilisant Black, vous cédez le contrôle sur le formatage de votre code. En retour, Black vous fera gagner un max de temps, diminuera votre charge mentale et fera revenir l'être aimé_". Mais la partie réellement intéressante concerne le fait que "_Tout code qui sera passé par Black aura la même forme, indépendamment du project sur lequel vous serez en train de travailler. L'étape de formatage deviendra transparente, et vous pourrez vous concentrer sur le contenu_".
|
||||
Traduit rapidement à partir de la langue de Batman: "_En utilisant Black, vous cédez le contrôle sur le formatage de votre code. En retour, Black vous fera gagner un max de temps, diminuera votre charge mentale et fera revenir l'être aimé_".
|
||||
Mais la partie réellement intéressante concerne le fait que "_Tout code qui sera passé par Black aura la même forme, indépendamment du project sur lequel vous serez en train de travailler. L'étape de formatage deviendra transparente, et vous pourrez vous concentrer sur le contenu_".
|
||||
|
||||
|
||||
==== Complexité cyclomatique
|
||||
|
|
@ -483,7 +527,47 @@ $ touch setup.cfg
|
|||
|
||||
==== Dockerfile
|
||||
|
||||
[source,docker]
|
||||
----
|
||||
# Dockerfile
|
||||
|
||||
# Pull base image
|
||||
#FROM python:3.8
|
||||
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/
|
||||
|
||||
----
|
||||
|
||||
|
||||
==== Makefile
|
||||
|
|
@ -514,38 +598,6 @@ coverage:
|
|||
Pour la petite histoire, `make` peu sembler un peu désuet, mais reste extrêmement efficace.
|
||||
|
||||
|
||||
==== The Zen of Python
|
||||
|
||||
[source,python]
|
||||
----
|
||||
>>> import this
|
||||
----
|
||||
|
||||
[source,text]
|
||||
----
|
||||
The Zen of Python, by Tim Peters
|
||||
|
||||
Beautiful is better than ugly.
|
||||
Explicit is better than implicit.
|
||||
Simple is better than complex.
|
||||
Complex is better than complicated.
|
||||
Flat is better than nested.
|
||||
Sparse is better than dense.
|
||||
Readability counts.
|
||||
Special cases aren't special enough to break the rules.
|
||||
Although practicality beats purity.
|
||||
Errors should never pass silently.
|
||||
Unless explicitly silenced.
|
||||
In the face of ambiguity, refuse the temptation to guess.
|
||||
There should be one-- and preferably only one --obvious way to do it.
|
||||
Although that way may not be obvious at first unless you're Dutch.
|
||||
Now is better than never.
|
||||
Although never is often better than *right* now.
|
||||
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!
|
||||
----
|
||||
|
||||
|
||||
=== Environnement de développement
|
||||
|
||||
|
|
@ -802,6 +854,38 @@ services:
|
|||
|
||||
----
|
||||
|
||||
[source,dockerfile]
|
||||
----
|
||||
[source,docker]
|
||||
----
|
||||
# docker-compose.yml
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
web:
|
||||
build: .
|
||||
command: python /code/manage.py runserver 0.0.0.0:8000
|
||||
volumes:
|
||||
- .:/code
|
||||
ports:
|
||||
- 8000:8000
|
||||
depends_on:
|
||||
- slqserver
|
||||
slqserver:
|
||||
image: mcr.microsoft.com/mssql/server:2019-latest
|
||||
environment:
|
||||
- "ACCEPT_EULA=Y"
|
||||
- "SA_PASSWORD=sqklgjqihagrtdgqk12§!"
|
||||
ports:
|
||||
- 1433:1433
|
||||
volumes:
|
||||
- ../sqlserver/data:/var/opt/mssql/data
|
||||
- ../sqlserver/log:/var/opt/mssql/log
|
||||
- ../sqlserver/secrets:/var/opt/mssql/secrets
|
||||
|
||||
----
|
||||
----
|
||||
|
||||
|
||||
[source,dockerfile]
|
||||
----
|
||||
|
|
|
|||
Loading…
Reference in New Issue