diff --git a/README.md b/README.md index ebed029..878b10a 100644 --- a/README.md +++ b/README.md @@ -12,6 +12,7 @@ Les lexers Pygments disponibles se trouvent sur cette page: http://pygments.org/ ```bash apt install texlive-latex-base latexmk texlive-latex-extra texlive-xetex +apt install plantuml ruby-asciidoctor-plantuml ``` ## Sortie en PDF @@ -27,4 +28,16 @@ cd ~/ python3 -m venv .venvs/gwift-book source .venvs/gwift-book/bin/activate pip install -r requirements/base.txt + +$ gem install asciidoctor-pdf --pre +$ gem install rouge +$ gem install asciidoctor-diagram +``` + +## Conversion en PDF + +```bash +asciidoctor -a rouge-style=monokai -a pdf-themesdir=resources/themes -a pdf-theme=gwift main.adoc -t -r asciidoctor-diagram + +asciidoctor-pdf -a rouge-style=monokai -a pdf-themesdir=resources/themes -a pdf-theme=gwift main.adoc -t -r asciidoctor-diagram ``` diff --git a/adoc/deploy/index.adoc b/adoc/deploy/index.adoc index 99a3a4a..55ebc5c 100644 --- a/adoc/deploy/index.adoc +++ b/adoc/deploy/index.adoc @@ -21,6 +21,13 @@ Comme on l'a vu dans la première partie, Django est un framework complet, inté Supervisor, nginx, gunicorn, utilisateurs, groupes, ... +[plantuml] +-- +entity Nginx +entity "Gunicorn (sockets/HTTP)" as gunicorn +database PGSQL +-- + Aussi : Docker, Heroku, Digital Ocean, Scaleway, OVH, ... Bref, sur Debian et CentOS pour avoir un panel assez large. On oublie Windows. diff --git a/adoc/main.adoc b/adoc/main.adoc index a4ced27..feb5107 100644 --- a/adoc/main.adoc +++ b/adoc/main.adoc @@ -1,6 +1,11 @@ = Deep dive into Django Cédric Declerfayt ; Fred Pauchet +:doctype: book :toc: +:sectnums: +:chapter-label: Chapitre +:preface-title: Préface +:source-highlighter: rouge On ne va pas se mentir: il existe enormément de tutoriaux très bien réalisés sur "Comment réaliser une application Django" et autres "Déployer votre code en 2 minutes". On se disait juste que ces tutoriaux restaient relativement haut-niveau et se limitaient à un contexte donné. @@ -8,21 +13,27 @@ L'idée du texte ci-dessous est de jeter les bases d'un bon développement, en s Ces idées ne s'appliquent pas uniquement à Django et à son cadre de travail, ni même au langage Python. Juste que ces deux bidules sont de bons candidats et que le cadre de travail est bien défini et suffisamment flexible. -Pour cela, on présentera différents outils (mypy, flake, black, ...), 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, ainsi que les bonnes étapes pour arriver à un déploiement rapide et fonctionnel en peu d'étapes. +Pour cela, on présentera différents outils (mypy, flake8, black, ...), 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, ainsi que les bonnes étapes à suivre pour arriver à un déploiement rapide et fonctionnel avec peu d'efforts. -Dans tout à un seul et même endroit. Oui. :-) +Et tout ça à un seul et même endroit. Oui. :-) Bonne lecture. -include::toolchain/index.adoc[] +== Environnement de travail + +include::toolchain/venvs.adoc[] + +include::toolchain/tools.adoc[] -include::deploy/index.adoc[] == Déploiement Et sécurisation du serveur. +include::deploy/index.adoc[] + == Modélisation -Et administration. + +include::models/admin.adoc[] == Go Live ! Et supervision. \ No newline at end of file diff --git a/adoc/models/admin.adoc b/adoc/models/admin.adoc new file mode 100644 index 0000000..f85ed6b --- /dev/null +++ b/adoc/models/admin.adoc @@ -0,0 +1,4 @@ +== Modélisation et conception avancée + +=== Administration + diff --git a/adoc/resources/themes/gwift-theme.yml b/adoc/resources/themes/gwift-theme.yml new file mode 100644 index 0000000..f66a3bb --- /dev/null +++ b/adoc/resources/themes/gwift-theme.yml @@ -0,0 +1,8 @@ +extends: default +footer: + recto: + right: + content: '{section-or-chapter-title} | {page-number}' + verso: + left: + content: '{page-number} | {chapter-title}' \ No newline at end of file diff --git a/adoc/toolchain/index.adoc b/adoc/toolchain/index.adoc index ef495ba..2f9791b 100644 --- a/adoc/toolchain/index.adoc +++ b/adoc/toolchain/index.adoc @@ -3,6 +3,4 @@ Et configuration de l'espace de travail. -include::venvs.adoc[] -include::tools.adoc[] diff --git a/adoc/toolchain/tools.adoc b/adoc/toolchain/tools.adoc index dc4f7c6..617b9e6 100644 --- a/adoc/toolchain/tools.adoc +++ b/adoc/toolchain/tools.adoc @@ -1,11 +1,20 @@ -=== Flake8 +=== Chaîne d'outils + +==== Flake8 + +[source,python] +-- +from datetime import datetime + +datetime.today() +datetime(2020, 2, 5) +-- + +==== Black -=== Black +==== pytest -=== pytest - - -=== mypy +==== mypy diff --git a/adoc/toolchain/venvs.adoc b/adoc/toolchain/venvs.adoc index 1e345e0..9aaa9f3 100644 --- a/adoc/toolchain/venvs.adoc +++ b/adoc/toolchain/venvs.adoc @@ -4,5 +4,5 @@ On va commencer avec la partie la moins funky, mais la plus utile, dans la vie d Il est tout à fait possible de s'en passer complètement dans le cadre de "petits" projets ou d'applications déployées sur des machines dédiées, et de fonctionner à grand renforts de "sudo" et d'installation globale des dépendances. Cette pratique est cependant fortement déconseillée pour plusieurs raisons: -. Pour la reproductibilité d'une +. Pour la reproductibilité d'un environnement spécifique. Cela évite notamment les réponses type "Ca juste marche chez moi", puisqu'on a la possibilité de construire un environnement sain et appliquer des dépendances identiques, quelle que soit la machine hôte. . il est tout à fait envisagable que deux applications soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d'une même dépendance. \ No newline at end of file