Create new parts for datamodel, SOA and go-live

source/glossary.adoc

@@ -0,0 +1,10 @@
+[glossary]
+= Glossaire
+
+http:: _HyperText Transfer Protocol_, ou plus généralement le protocole utilisé (et détourné) pour tout ce qui touche au **World Wide Web**. Il existe beaucoup d'autres protocoles d'échange de données, comme https://fr.wikipedia.org/wiki/Gopher[Gopher], https://fr.wikipedia.org/wiki/File_Transfer_Protocol[FTP] ou https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol[SMTP].
+
+IaaS:: _Infrastructure as a Service_, où un tiers vous fournit des machines (généralement virtuelles) que vous devrez ensuite gérer en bon père de famille. L'IaaS propose souvent une API, qui vous permet d'intégrer la durée de vie de chaque machine dans vos flux - en créant, augmentant, détruisant une machine lorsque cela s'avère nécessaire.
+
+ORM:: _Object Relational Mapper_, où une instance est directement (ou à proximité) liée à un mode de persistance de données.
+
+PaaS:: _Platform as a Service_, qui consiste à proposer les composants d'une plateforme (Redis, PostgreSQL, ...) en libre service et disponibles à la demande (quoiqu'après avoir communiqué son numéro de carte de crédit...).

source/main.adoc

@@ -52,12 +52,13 @@ Nous aborderons également la supervision et la mise à jour d'une application e
 *Dans la troisième partie*, nous aborderons les grands principes de modélisation, en suivant les lignes de conduites du cadre de travail.
 Nous aborderons les concepts clés qui permettent à une application de rester maintenable, les formulaires, leurs validations, comment gérer les données en entrée, les migrations de données et l'administration.
 
-*Dans la quatrième partie*, nous mettrons ces concepts en pratique en présentant le développement de deux "vraies" applications: définition des tables, gestion des utilisateurs, ... et mise à disposition!
+*Dans la quatrième partie*, nous aborderons les architectures typées _entreprise_, les services et les différentes manières de structurer son application pour faciliter sa gestion et sa maintenance.
 
-footnote:[Avec même un peu d'https://www.xkcd.com[XKCD] et de Calvin & Hobbes dedans]
+*Dans la cinquième partie*, nous mettrons ces concepts en pratique en présentant le développement de deux "vraies" applications: définition des tables, gestion des utilisateurs, ... et mise à disposition!
 
 === Pour qui ?
 
+Ce livre s'adresse autant au néophyte qui souhaite se lancer dans le développement Web qu'à l'artisan qui a besoin d'un aide-mémoire et qui ne sait toujours
 
 === Pour quoi ?
 
@@ -76,18 +77,11 @@ include::part-2-deployment/_main.adoc[]
 
 include::part-3-django-concepts/_index.adoc[]
 
-include::part-4-go-live/_index.adoc[]
+include::part-5-go-live/_index.adoc[]
 
 include::part-9-resources/_index.adoc[]
 
-[glossary]
-= Glossaire
-
-IaaS:: _Infrastructure as a Service_, où un tiers vous fournit des machines (généralement virtuelles) que vous devrez ensuite gérer en bon père de famille. L'IaaS propose souvent une API, qui vous permet d'intégrer la durée de vie de chaque machine dans vos flux - en créant, augmentant, détruisant une machine lorsque cela s'avère nécessaire.
-
-ORM:: _Object Relational Mapper_, où une instance est directement (ou à proximité) liée à un mode de persistance de données.
-
-PaaS:: _Platform as a Service_, qui consiste à proposer les composants d'une plateforme (Redis, PostgreSQL, ...) en libre service et disponibles à la demande (quoiqu'après avoir communiqué son numéro de carte de crédit...).
+include::glossary.adoc[]
 
 [index]
 == Index

source/part-2-deployment/_main.adoc

@@ -110,6 +110,8 @@ Il est possible de démarrer petit, et de suivre l'évolution des besoins en fon
 
 === Logs
 
+include::logging.adoc[]
+
 === Sentry ! :-D
 
 [source,python]

source/part-3-data-model/_index.adoc

@@ -0,0 +1,38 @@
+= (meta)Data Model
+
+Dans ce chapitre, nous allons parler de plusieurs concepts utiles au développement rapide d'une application.
+Nous parlerons de modélisation, de métamodèle, de migrations, d'administration auto-générée, de traductions et de cycle de vie des données.
+
+Django est un framework Web proposant une très bonne intégration des composants et une flexibilité bien pensée: chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes logiques et faciles à retenir.
+Pour un néophyte, la courbe d'apprentissage sera relativement ardue; à côté de concepts clés de Django, il conviendra également d'assimiler correctement les structures de données du langage Python, le cycle de vie d'une requête HTTP
+
+En restant dans les sentiers battus, votre projet suivra un dérivé du patron de conception `MVC` (Modèle-Vue-Controleur), où la variante concerne les termes utilisés: Django les nomme respectivement Modèle-Template-Vue et leur contexte d'utilisation.
+Dans un *pattern* MVC classique, la traduction immédiate du **contrôleur** est une **vue**.
+Et comme on le verra par la suite, la **vue** est en fait le **template**.
+
+* Le modèle (`models.py`) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. _Grosso modo_*, une table SQL correspondra à une classe d'un modèle Django.
+* La vue (`views.py`), qui joue le rôle de contrôleur: _a priori_, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l'affichage d'une page. En d'autres mots, la vue sert de pont entre les données gérées par la base et l'interface utilisateur.
+* Le template, qui s'occupe de la mise en forme: c'est le composant qui va s'occuper de transformer les données en un affichage compréhensible (avec l'aide du navigateur) pour l'utilisateur.
+
+Pour reprendre une partie du schéma précédent, lorsqu'une requête est émise par un utilisateur, la première étape va consister à trouver une _route_ qui correspond à cette requête, c'est à dire à trouver la correspondance entre l'URL qui est demandée par l'utilisateur et la fonction du langage qui sera exécutée pour fournir le résultat attendu.
+Cette fonction correspond au *contrôleur* et s'occupera de construire le *modèle* correspondant.
+
+En simplifiant, Django suit bien le modèle MVC, et toutes ces étapes sont liées ensemble grâce aux différentes routes, définies dans les fichiers `urls.py`.
+
+include::models.adoc[]
+
+include::migrations.adoc[]
+
+include::shell.adoc[]
+
+include::admin.adoc[]
+
+include::forms.adoc[]
+
+include::auth.adoc[]
+
+include::settings.adoc[]
+
+include::tests.adoc[]
+
+== Conclusions

source/part-3-data-model/migrations.adoc

@@ -0,0 +1,115 @@
+== Migrations
+
+L'intégration des migrations a été réalisée dans la version 1.7 de Django.
+Avant cela, il convenait de passer par une librairie tierce intitulée https://south.readthedocs.io/en/latest[South].
+
+Dans cette section, nous allons voir comment fonctionnent les migrations.
+Lors d'une première approche, elles peuvent sembler un peu magiques, puisqu'elles centralisent un ensemble de modifications pouvant être répétées sur un schéma de données, en tenant compte de ce qui a déjà été appliqué et en vérifiant quelles migrations devaient encore l'être pour mettre l'application à niveau.
+
+Une analyse en profondeur montrera qu'elles ne sont pas plus complexes à suivre et à comprendre qu'un ensemble de fonctions de gestion appliquées à notre application.
+
+Prenons l'exemple de notre liste de souhaits; nous nous rendons (bêtement) compte que nous avons oublié d'ajouter un champ de `description` à une liste.
+Historiquement, cette action nécessitait l'intervention d'un administrateur système ou d'une personne ayant accès au schéma de la base de données, à partir duquel ce-dit utilisateur pouvait jouer manuellement un script SQL.
+Cet enchaînement d'étapes nécessitait une bonne coordination d'équipe, mais également une bonne confiance dans les scripts à exécuter.
+Et souvenez-vous (cf. ref-à-insérer), que l'ensemble des actions doit être répétable et automatisable.
+
+Bref, dans les années '80, il convenait de jouer ceci après s'être connecté à la base de données:
+
+[source,sql]
+----
+ALTER TABLE WishList ADD COLUMN Description nvarchar(MAX);
+----
+
+Et là, nous nous rappelons qu'un utilisateur tourne sur Oracle et pas sur MySQL, et qu'il a donc besoin de son propre script d'exécution, parce que le type du nouveau champ n'est pas exactement le même entre les deux moteurs:
+
+[source,sql]
+----
+
+----
+
+Bref, vous voyez le(s) problème(s):
+
+1. Aucune autonomie
+2. Aucune automatisation possible (à moins d'écrire un programme, qu'il faudra également maintenir et intégrer au niveau des tests)
+3. Nécessiter de maintenir autant de scripts différents qu'il y a de moteurs de base de données supportés
+4. Aucune possibilité de vérifier si le script a déjà été exécuté ou non (à moins de maintenir un programme supplémentaire, à nouveau)
+5. ...
+
+Les migrations résolvent la plupart de ces soucis: le framework embarque ses propres applications, dont les migrations, qui gèrent elles-mêmes l'arbre de dépendances entre les modifications devant être appliquées.
+Une migration consiste donc à appliquer un ensemble de modifications (ou **opérations**), qui exercent un ensemble de transformations, pour que le schéma de base de données corresponde au modèle de l'application sous-jacente.
+Les migrations (comprendre les "_migrations du schéma de base de données_") sont intimement liées à la représentation d'un contexte fonctionnel.
+L'ajout d'une nouvelle information, d'un nouveau champ ou d'une nouvelle fonction peut s'accompagner de tables de données à mettre à jour ou de champs à étendre.
+
+Toujours dans une optique de centralisation, les migrations sont directement embarquées au niveau du code.
+Le développeur s'occupe de créer les migrations en fonction des actions à entreprendre; ces migrations peuvent être retravaillées, _squashées_, ... et feront partie intégrante du processus de mise à jour de l'application.
+
+A noter que les migrations n'appliqueront de modifications que si le schéma est impacté.
+Ajouter une propriété `related_name` sur une ForeignKey n'engendrera aucune nouvelle action de migration, puisque ce type d'action ne s'applique que sur l'ORM, et pas directement sur la base de données: au niveau des tables, rien ne change.
+Seul le code et le modèle sont impactés.
+
+
+Une migration est donc une classe Python, présentant _a minima_ deux propriétés:
+
+1. `dependencies`, qui décrit les opérations précédentes devant obligatoirement avoir été appliquées
+2. `operations`, qui consiste à décrire précisément ce qui doit être exécuté.
+
+Pour reprendre notre exemple d'ajout d'un champ `description` sur le modèle `WishList`, la migration ressemblera à ceci:
+
+[source,python]
+----
+from django.db import migrations, models
+import django.db.models.deletion
+import django.utils.timezone
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('gwift', '0004_name_value'),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name='wishlist',
+            name='description',
+            field=models.TextField(default="", null=True)
+            preserve_default=False,
+        ),
+    ]
+----
+
+Nous avions un modèle reprenant quelques classes, elles-mêmes saupoudrées de quelques propriétés.
+
+
+=== Réinitialisation d'une ou plusieurs migrations
+
+https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html[reset migrations].
+
+>  En gros, soit on supprime toutes les migrations (en conservant le fichier __init__.py), soit on réinitialise proprement les migrations avec un --fake-initial (sous réserve que toutes les personnes qui utilisent déjà le projet s'y conforment... Ce qui n'est pas gagné.
+Pour repartir de notre exemple ci-dessus, nous avions un modèle reprenant quelques classes, saupoudrées de propriétés décrivant nos différents champs. Pour être prise en compte par le moteur de base de données, chaque modification doit être
+
+
+=== Description d'une migration
+
+1. Décrite, grâce à la commande `makemigrations`
+
+=== Application d'une ou plusieurs migrations
+
+1. Appliquée, avec la commande `migrate`.
+
+=== Analyse
+
+Nous allons ci-dessous analyser exactement les modifications appliquées au schéma de la base de données, en fonction des différents cas, et comment ils sont gérés par les pilotes de Django.
+Nous utiliserons https://sqlitebrowser.org/[Sqlite Browser] et la commande `sqldump`, qui nous présentera le schéma tel qu'il sera compris.
+
+==== Création de nouveaux champs
+
+
+
+==== Modification d'un champ existant
+
+
+==== Suppression d'un champ existant
+
+
+

source/part-3-data-model/models.adoc

@@ -1,17 +1,28 @@
 == Modélisation
 
-Nous allons aborder la modélisation des objets en elle-même, qui est en lien direct avec la conception de la base de données et la manière dont celles-ci s'agencent et communiquent entre elles.
+Ce chapitre aborde la modélisation des objets et les options qui y sont liées.
+Avec Django, la modélisation est en lien direct avec la conception et le stockage de la base de données, la manière dont ces données s'agencent et communiquent entre elles.
 
-Django utilise un paradigme de type https://fr.wikipedia.org/wiki/Mapping_objet-relationnel[ORM] - c'est-à-dire que chaque type d'objet peut s'apparenter à une table SQL, mais en ajoutant une couche propre au modèle orienté objet.
-Il est ainsi possible de définir facilement des notions d'héritage (tout en restant dans une forme d'héritage simple), la possibilité d'utiliser des propriétés spécifiques, des classes intermédiaires, ...
+Django utilise un paradigme de type https://fr.wikipedia.org/wiki/Mapping_objet-relationnel[ORM] - c'est-à-dire que chaque type d'objet manipulé peut s'apparenter à une table SQL, tout en ajoutant une couche propre à la programmation orientée object.
+Plus spécifiquement, l'ORM de Django suit le patron de conception https://en.wikipedia.org/wiki/Active_record_pattern[Active Records], comme ce que font par exemple https://rubyonrails.org/[Rails] pour Ruby ou https://docs.microsoft.com/fr-fr/ef/[EntityFramework] pour .Net.
 
-L'avantage de tout ceci est que tout reste au niveau du code.
-Si l'on revient sur la méthodologie des douze facteurs, ce point concerne principalement la minimisation de la divergence entre les environnements d'exécution.
-Déployer une nouvelle instance de l'application pourra être réalisé directement à partir d'une seule et même commande, dans la mesure où *tout est embarqué au niveau du code*.
+Le modèle de données de Django est sans doute la (seule ?) partie qui soit tellement couplée au framework qu'un changement à ce niveau nécessitera une refonte complète de beaucoup d'autres briques de vos applications; là où un pattern de type https://www.martinfowler.com/eaaCatalog/repository.html[Repository] permettrait justement de découpler le modèle des données de l'accès à ces mêmes données, un pattern Active Record lie de manière extrêmement forte le modèle à sa persistence.
 
-Assez de blabla, on démarre !
+Architecturalement, c'est sans doute la plus grosse faiblesse de Django.
+Conceptuellement, c'est pourtant la manière de faire qui permettra d'avoir quelque chose à présenter très rapidement: à partir du moment où vous aurez un modèle de données, vous aurez accès :
 
-=== Modélisation de base
+1. Aux migrations de données,
+2. A un découplage complet entre le moteur de données relationnel et le modèle de données,
+3. A une interface d'administration auto-générée
+4. A un mécanisme de formulaires HTML qui soit complet, pratique à utiliser, orienté objet et facile à faire évoluer,
+5. De définir des notions d'héritage (tout en restant dans une forme d'héritage simple).
+
+Comme tout ceci reste au niveau du code, cela suit également la méthodologie des douze facteurs, concernant la minimisation des divergences entre environnements d'exécution: comme tout se trouve au niveau du code, il n'est plus nécessaire d'avoir un DBA qui doive démarrer un script sur un serveur au moment de la mise à jour, de recevoir une release note de 512 pages en PDF reprenant les modifications ou de nécessiter l'intervention de trois équipes différentes lors d'une modification majeure du code.
+Déployer une nouvelle instance de l'application pourra être réalisé directement à partir d'une seule et même commande.
+
+_A contrario_, ces avantages sont balancés au travers d'un couplage extrêmement fort entre la modélisation et le reste du framework - à tel point que *ne pas utiliser cette brique de fonctionnalités* peut remettre en question le choix du framework.
+
+=== Principes de modélisation
 
 Dans le domaine des bases de données relationnelles, un point d'attention est de toujours disposer d'une clé primaire pour nos enregistrements.
 Si aucune clé primaire n'est spécifiée, Django s'occupera d'en ajouter une automatiquement et la nommera (par convention) `id`.
@@ -264,3 +275,13 @@ couplage des classes et on centralise l'accès.
 class ItemManager(...):
     (de mémoire, je ne sais plus exactement :-))
 ----
+
+=== Conclusion
+
+Le modèle proposé par Django est un composant extrêmement performant, mais fort couplé avec le coeur du framework.
+Si tous les composants peuvent être échangés avec quelques manipulations, le cas du modèle sera plus difficile à interchanger.
+
+A côté de cela, il permet énormément de choses, et vous fera gagner un temps précieux, tant en rapidité d'essais/erreurs, que de preuves de concept.
+
+Une possibilité peut également être de cantonner Django à un framework
+

source/part-3-django-concepts/_index.adoc

@@ -1,47 +0,0 @@
-= Django
-
-Dans ce chapitre, on va parler de plusieurs concepts utiles au développement rapide d'une application. On parlera de modélisation, de migrations, d'administration auto-générée. C'est un framework Web proposant une très bonne intégration des composants, et une flexibilité bien pensée: chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes logiques et faciles à retenir.
-
-En restant dans les sentiers battus, votre projet suivra le patron de conception `MVC` (Modèle-Vue-Controleur), avec une petite variante sur les termes utilisés: Django les nomme respectivement Modèle-Template-Vue:
-
-
-Dans un *pattern* MVC classique, la traduction immédiate du **contrôleur** est une **vue**. Et comme on le verra par la suite, la **vue** est en fait le **template**.
-
-* Le modèle (`models.py`) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. _Grosso modo_*, une table SQL correspondra à une classe d'un modèle Django.
-* La vue (`views.py`), qui joue le rôle de contrôleur: _a priori_, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l'affichage d'une page. En d'autres mots, la vue sert de pont entre les données gérées par la base et l'interface utilisateur.
-* Le template, qui s'occupe de la mise en forme: c'est le composant qui va s'occuper de transformer les données en un affichage compréhensible (avec l'aide du navigateur) pour l'utilisateur.
-
-Pour reprendre une partie du schéma précédent, on a une requête qui est émise par un utilisateur. La première étape consiste à trouver une route qui correspond à cette requête, c'est à dire à trouver la correspondance entre l'URL demandée et la fonction qui sera exécutée. Cette fonction correspond au *contrôleur* et s'occupera de construire le *modèle* correspondant. 
-
-En simplifiant, Django suit bien le modèle MVC, et toutes ces étapes sont liées ensemble grâce aux différentes routes, définies dans les fichiers `urls.py`.
-
-include::models.adoc[]
-
-include::migrations.adoc[]
-
-include::shell.adoc[]
-
-include::admin.adoc[]
-
-include::forms.adoc[]
-
-include::views.adoc[]
-
-include::templates.adoc[]
-
-include::layout.adoc[]
-
-include::urls.adoc[]
-
-include::auth.adoc[]
-
-include::logging.adoc[]
-
-include::settings.adoc[]
-
-include::tests.adoc[]
-
-NOTE: Ne pas oublier de parler des sessions. Mais je ne sais pas si c'est le bon endroit.
-
-include::multilingual.adoc[]
-

source/part-3-django-concepts/migrations.adoc

@@ -1,94 +0,0 @@
-== Migrations
-
-Dans cette section, nous allons voir comment les migrations fonctionnent.
-Dans une première version, elles peuvent sembler un peu magiques, dans la mesure où elles appliquent des modifications au 
-niveau du schéma de données en se basant uniquement sur des modifications effectuées sur le modèle.
-
-Techniquement, elles ne sont pas plus complexes à comprendre qu'un ensemble de fonctions appliquées à notre application.
-
-[source,python]
-----
-from django.db import migrations, models
-import django.db.models.deletion
-import django.utils.timezone
-
-
-class Migration(migrations.Migration):
-
-    dependencies = [
-        ('gwift', '0004_name_value'),
-    ]
-
-    operations = [
-        migrations.AddField(
-            model_name='wish',
-            name='date',
-            field=models.DateField(default=django.utils.timezone.now),
-            preserve_default=False,
-        ),
-        migrations.AddField(
-            model_name='wish',
-            name='description',
-            field=models.TextField(default="", null=True)
-            preserve_default=False,
-        ),
-    ]
-----
-
-Pour repartir de notre exemple ci-dessus, nous avions un modèle reprenant quelques classes, et saupoudrées de propriétés.
-Pour schématiser, chaque classe correspond à une table dans la base de données, tandis que 
-chaque propriété correspond à un champ de cette table.
-
-Une migration consiste donc à appliquer un ensemble de modifications (ou **opérations**), 
-qui exercent un ensemble de transformations, pour que le schéma de base de données corresponde au modèle de l'application.
-
-Les migrations (comprendre les "_migrations du schéma de base de données_") sont intimement liées à la 
-représentation d'un contexte fonctionnel. 
-L'ajout d'une nouvelle information, d'un nouveau champ ou d'une nouvelle fonction peut s'accompagner 
-de tables de données à mettre à jour ou de champs à étendre.
-
-Toujours dans une optique de centralisation, les migrations sont directement embarquées au niveau du code. 
-Le développeur s'occupe de créer les migrations en fonction des actions à entreprendre; 
-ces migrations peuvent être retravaillées, _squashées_, ... 
-et feront partie intégrante du processus de mise à jour de l'application.
-
-A noter que les migrations n'appliqueront de modifications que si le schéma est impacté. 
-Ajouter une propriété `related_name` sur une ForeignKey n'engendrera aucune nouvelle action de migration, 
-puisque ce type d'action ne s'applique que sur l'ORM, et pas directement sur la base de données: 
-au niveau des tables, rien ne change. Seul le code et le modèle sont impactés.
-
-
-https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html[reset migrations].
-
->  En gros, soit on supprime toutes les migrations (en conservant le fichier __init__.py), soit on réinitialise proprement les migrations avec un --fake-initial (sous réserve que toutes les personnes qui utilisent déjà le projet s'y conforment... Ce qui n'est pas gagné.
-Pour repartir de notre exemple ci-dessus, nous avions un modèle reprenant quelques classes, saupoudrées de propriétés décrivant nos différents champs. Pour être prise en compte par le moteur de base de données, chaque modification doit être
-
-
-
-
-=== Description d'une migration
-
-1. Décrite, grâce à la commande `makemigrations`
-
-=== Application d'une ou plusieurs migrations
-
-2. Appliquée, avec la commande `migrate`.
-
-=== Analyse
-
-Nous allons ci-dessous analyser exactement les modifications appliquées au schéma de la base de données, 
-en fonction des différents cas, et comment ils sont gérés par les pilotes de Django.
-Nous utiliserons https://sqlitebrowser.org/[Sqlite Browser] et la commande `sqldump`, 
-qui nous présentera le schéma tel qu'il sera compris.
-
-==== Création de nouveaux champs
-
-
-
-==== Modification d'un champ existant
-
-
-==== Suppression d'un champ existant
-
-
-

source/part-4-services-oriented-applications/_main.adoc

@@ -0,0 +1,18 @@
+= Services Oriented Applications
+
+Nous avons fait exprès de reprendre l'acronyme d'une _Services Oriented Architecture_ pour cette partie.
+L'objectif est de vous mettre la puce à l'oreille quant à la finalité du développement: que l'utilisateur soit humain, bot automatique ou client Web, l'objectif est de fournir des applications résilientes, disponibles et accessibles.
+
+Dans cette partie, nous aborderons les vues, la mise en forme, la mise en page, la définition d'une interface REST, la définition d'une interface GraphQL et le routage d'URLs.
+
+include::views.adoc[]
+
+include::templates.adoc[]
+
+include::querysets.adoc[]
+
+include::urls.adoc[]
+
+== Conclusions
+
+De part son pattern `MVT`, Django ne fait pas comme les autres frameworks.