Elixir amqp 1.2 et confirm handler

2019-05-15T13:25:00+00:00

RabbitMq permet de recevoir des confirmations de ventilation des messages par l'exchange. Le client Elixir, amqp (> 1.2)</code> permet d'attendre de manière bloquante ces confirmations, mais ne propose pas d'API pour enregistrer un handler. Ce qui m'a donné l'opportunité de faire cette contribution, qui fait maintenant partie de la version 1.2.

Cet article résume l'histoire de cette contribution à des fins didactiques.

Le contexte</h2>La fonctionnalité de publisher confirm</a> proposée par RabbitMq, permet en sacrifiant un peu de performances, d'obtenir une confirmation que le message publié à bien été accepté par les queues destinataires. Imagine que tu publie un message dans le bus AMQP, ce que tu obtiens de manière synchrone lors d'un publish, c'est une confirmation que l'exchange à bien reçu le message. Cela ne garanti pas que le message est bien ventilé vers les queues enregistrées comme destinataires. Une option serait d'utiliser les transactions du protocol AMQP 0-9-1</code>, mais elle ont un énorme impacte sur le débit de messages. L'autre option est d'utiliser une extension du protocole proposée par RabbitMq: publisher confirm. Cette extension te permet de d'activer le mode confirmation pour un channel. Ce qui a pour effet de reproduire le sémantique de l'acquittement de message, au niveau de l'exchange. Quand celui-ci parvient a router un message, il retourne un message d'acquittement. Le paquet Hex amqp < 1.2</code> expose une fonction AMQP.Confirm.select/1</code> qui permet de d'activer les confirmations sur le channel. Et une suite de fonctions wait_for_confirms*(/1|/2)</code></a> qui permettent d'attendre de manière synchrone la confirmation des derniers messages envoyés. Dans mon système je conserve un état des messages à envoyer, et des messages envoyés avec succès. Mais je ne souhaite pas bloquer l'acteur en charge de publier les messages pour valider la confirmation de l'envoi de ceux-ci. J'aimerais plutôt exploiter au mieux l'outillage en déléguant la confirmation de l'envoi à un autre acteur. En me documentant sur le fonctionnement du publisher confirm et des recommandations pour RabbitMq, et en lisant le code source d'autres clients, je me suis rendu compte que plusieurs clients implémentaient un fonction register_confirm_handler</code> et next_publish_seqno</code>. Ces fonctions permettent respectivement de déclarer un handler pour traiter les confirmations et d'obtenir l'identifiant du message publié pour un channel. C'est justement ce dont j'avais besoin. Le client Elixir s'appuyant sur le client Erlang, qui lui implémement ces fonctions, il n'y avait plus qu'à se pencher pour récolter, permettant de fermer quelque issues au passage. Le développement</h2> Je vais ré-exposer les fonctions proposée par Erlang, dans la continuité de la codebase actuelle. Habituellement je consulte donc avec la plus grande précaution les consignes de contribution. Mais dans le cas présent elles brillaient par leur absence. Dans ce cas, je m'imprègne des pratiques des mainteneurs précédents en explorant le code source. Je trouve que c'est une étape indispensable, open source, ou pas. Cela contribue à rendre le code homogène et compréhensible. Ensuite j'écris un test simple. Je n'argumente plus sur la nécéssité d'écrire les tests en premier. Dans un premier temps le setup. Il me faut : une connection pour obtenir un channel</li> un channel pour selectionner le mode confirmation.</li> un callback pour fermer la connection proprement à la fin du test</li> </ul> Puisque toute les opérations se font au niveau du channel, je l'ajoute au contexte qui sera passé en argument du test. // test/confirm.exs defmodule ConfirmTest do use ExUnit.Case alias AMQP.Connection alias AMQP.Channel alias AMQP.Confirm setup do {:ok, conn} = Connection.open {:ok, chan} = Channel.open(conn) :ok = Confirm.select(chan) on_exit fn -> :ok = Connection.close(conn) end {:ok, chan: chan} end // ... </code></pre> Ensuite le premier test, simple, récupérer le numéro de séquence du message. En consultant la documentation de RabbitMq et du client Erlang, je comprend que le premier numéro de séquence d'un channel vide est 1 et que la fonction Erlang</a> attend l'identifiant du process channel en argument. Ensuite je décide du nom et module de la fonction, en m'inspirant des pratiques du code source actuel, qui est de reprendre celui de la fonction Erlang. Voci le test: describe "next_publish_seqno" do test "returns 1 whe no messages where sent", ctx do assert 1 == Confirm.next_publish_seqno(ctx[:chan]) end end </code></pre> Il ne reste plus qu'a le lancer pour le regarder échouer, puis écrire le code pour le faire passer. Dans le module AMQP.Confirm</code>, j'ajoute une fonction qui: Prend une structure Channel</code> en argument</li> Appelle la fonction Erlang</li> Retourne le résultat sous forme d'entier positif</li> </ul> # lib/amqp/confirm.ex @doc """ On channel with confirm activated, return the next message sequence number. To use in combination with `register_handler/2` """ @spec next_publish_seqno(Channel.t) :: non_neg_integer def next_publish_seqno(%Channel{pid: pid}) do :amqp_channel.next_publish_seqno(pid** end </code></pre> Ensuite je regarde le test passer, easy :) Deux points très importants ici: puisqu'il s'agit d'ajouter cette fonction a l'API publique de la bibliothèque, j'écris une spécification de sa signature en bonne et due forme.</li> Pour les mêmes raisons, je me fends d'une documentation d'utilisation.</li> </ul> L'étape suivante c'est d'ajouter la fonction qui permet d'enregistrer un handler. Tous ce que qui a été dit avant reste vrai (tests, documentation, conventions ...). La fonction Erlang register_confirm_handler</code></a> attend en argument les identifiants du channel et du handler et retourne un ok</code>. La documentation précise également que le handler recevra une structure en guise de message #basic.ack{}</code> ou #basic.nack{}</code>. Ce ne sont pas des structures valides pour Elixir, ce sont des Erlang Records. Comme la sémantique de confirmation est la même que celle de l'acquittement de messages par le consommateur, la transposition des Records Erlang vers Elixir existe déjà. En explorant le fichier core.ex</code></a> de la bibliothèque j'apprends que le process recevra un message :basic_ack</code> ou :basic_nack</code>. Il sera accompagné d'un ou plusieurs numéros de séquence. Si il y en a plusieurs, le troisième argument du message vaudra true</code>. Cette fois-ci le test consiste à: obtenir le prochain numéro de séquence</li> envoyer un message</li> déclarer le module test comme handler de confirmation</li> s'assurer que je reçoive bien la confirmation</li> s'assurer que la confirmation porte bien numéro de séquence attendu</li> </ul> describe "register_handler" do test "handler receive confirm with message seqno", ctx do seq_no = Confirm.next_publish_seqno(ctx[:chan]) :ok = AMQP.Basic.publish(ctx[:chan], "", "", "foo") :ok = Confirm.register_handler(ctx[:chan], self()) assert_receive {:basic_ack, seq_no, false} :ok = Confirm.unregister_handler(ctx[:chan]) end end </code></pre> Faire échouer les tests et passer à l'implémentation. La fonction register_handler</code> prend en argument le channel et l'identifiant du handler. Elle spawn un process qui va servir d'adapter entre les messages de Erlang vers Elixir. Ce process est supervisé ainsi que celui du handler pour réagir à la mort des process enfants</a> avec un message {:DOWN}</code>. Puis appelle la fonction privée handle_confirm</code> qui attend la réception d'un message Erlang et se charge de le transposer et de l'envoyer au handler. Pour finir elle utilise la récursion pour rester à l'écoute. @doc """ Register a handler for confirms on channel. The handler will receive either: * `{:basic_ack, seqno, multiple}` * `{:basic_nack, seqno, multiple}` The `seqno` (delivery_tag) is an integer, the sequence number of the message. `multiple` is a boolean, when `true` means multiple messages confirm, upto `seqno`. see https://www.rabbitmq.com/confirms.html """ @spec register_handler(Channel.t, pid) :: :ok def register_handler(%Channel{pid: pid}, handler_pid) do adapter_pid = spawn fn -> Process.flag(:trap_exit, true) Process.monitor(handler_pid) Process.monitor(pid) handle_confirm(handler_pid) end :amqp_channel.register_confirm_handler(pid, adapter_pid) end defp handle_confirm(handler_pid) do receive do basic_ack(delivery_tag: delivery_tag, multiple: multiple) -> send(handler_pid, {:basic_ack, delivery_tag, multiple}) handle_confirm(handler_pid) basic_nack(delivery_tag: delivery_tag, multiple: multiple) -> send(handler_pid, {:basic_nack, delivery_tag, multiple}) handle_confirm(handler_pid) {:DOWN, _ref, :process, _pid, reason} -> exit(reason) end end </code></pre> Les tests passent, il ne reste qu'à ajouter la fonction unregister_hander/1</code>. Je ne la commenterais pas, car tu n'y apprendra rien de plus ce qui a été dit plus haut. Tu trouvera la commit dans son intégralité sur github</a>. Pour finir</h2> La PR a été intégrée et fait partie des features de la version 1.2. Le fait d'avoir adopté les conventions des mainteneurs du projet leur ont permis d'enchaîner un refactoring sans en souffrir. Et finalement je peux traiter les confirmations de manière asynchrone sans avoir à utiliser l'API du client Erlang dans mon application.

Du dosage de la rouille

2019-04-17T13:25:00+00:00

Parlons de la rouille, cette délicieuse sauce qui accompagne nos soupes de poisson. Le bon dosage des ingrédients ravira le palais vos convives !

Pour faire une portion de rouille les ingrédients sont :

1/2 gousse d'ail dégermée
</span>1/8 petit piment rouge
</span>1/8 jaune d'oeuf
</span>1/8 tranche de pain
</span>1/32 L d'huile d'olive
</span></code></pre>
Plus on est nombreux autour de la table et plus on rit.</p>
Il va donc falloir multiplier la proportion des ingrédients pour atteindre un dosage équilibré.
Miam !</p>
Je profite de cet article dédié à la recette de la rouille pour évoquer Rust au passage.</p>
Non, pas le jeu vidéo pour survivaliste virtuel frustré (je plaisante, bisous !).
Rust(2018)</a>: Le langage de programmation qui fait peur.</p>
{:style="float: left"}
</p>
Je ne sais plus par quelle association d'idée j'en suis arrivé là.
Mais je vais vous expliquer comment je calcule le dosage des ingrédients de ma rouille avec Rust.</p>
En espérant qu'a l'issu de cet article Rust ne vous intimidera plus et titillera votre palais.</p>
Pourquoi autant d'intérêt pour la rouille ?</h2>
Le premier aspect séduisant de Rust est l'absence de garbage collector</em>, évitant beaucoup de problèmes de latence.</p>
Son système de gestion de mémoire, qui martyrise les nouveaux venus, apporte un gros avantage en termes de sécurité. (Mais ce n'est pas le pays des Bisounours</a> non plus)</p>
Rust est idéal pour l'embarqué, les outils système, mais pas que. WebAssembly, protocoles réseau, concurrence, portabilité ...</p>
C'est à chacun de choisir ses arguments.</p>
La recette</h2>
Pour générer un nouveau crate</code> (un package Rust</a>), il est possible d'utiliser cargo</code> (l'outil de build).</p>
cargo new doser</span> --bin
</span></code></pre>
L'option --bin</code> précise qu'il s'agit d'un exécutable et non d'une bibliothèque.</p>
Le point d'entrée d'un crate</code>, sans surprise, est le fichier main.rs</code>.</p>
Le doseur de rouille a besoin de la recette unitaire.
Profitons-en pour introduire quelques notions.</p>
// main.rs
</span>
</span>const </span>RECIPE</span>: </span>&</span>str </span>= </span>"
</span>1/2 gousse d'ail dégermée
</span>1/8 piment rouge
</span>1/8 jaune d'œuf
</span>1/8 tranche de pain
</span>1/32 L d'huile d'olive
</span>"</span>;
</span></code></pre>
C'est une constante const</code>, nommée RECIPE</code> dont on définit le type &str</code></a>.
&str</code> est une référence vers une chaîne de caractères UTF-8 immuable</a>.</p>
La ligne se terminant par un ;</code> il s'agit d'une déclaration</a>.</p>
Les Ingrédients</h2>
Pour modéliser les ingrédients de la recette et leurs proportions utilisons  une structure dans son propre module.</p>
Un module Rust</a> peut être déclaré grâce à mod</code> suivi d'accolades {}</code>, le contenu des accolades sera alors la définition du module.</p>
Le contenu du module peut aussi être déporté dans un autre fichier qui porte le nom du module en question.
Dans ce cas on omet les parenthèses.</p>
// main.rs
</span>
</span>use</span> ingredient
</span></code></pre>
// ingredient.rs
</span>use </span>num_rational::Ratio;
</span>
</span>pub </span>struct </span>Ingredient {
</span>  </span>pub </span>label: String,
</span>  </span>pub </span>quantity: Ratio<</span>u32</span>>
</span>}
</span></code></pre>
Dans notre fichier ingredient.rs</code> est défini une structure (struct</code>) que le module expose publiquement.
Par défaut la visibilité est privée le mot clé pub</code> rend publique la structure et ses champs.</p>
Nos ingrédients sont composés:</p>

d'un label</code> qui contient la désignation, qui est une donnée de type String</code>.</li>
d'une quantity</code> qui contient une fraction Ratio</code>.</li>
</ul>
use num_rational::Ratio</code> est la syntaxe d'import de Rust. Par ce biais nous indiquons que nous utilisons la structure Ratio</code> de la bibliothèque num_rational</code>.</p>
La philosophie de Rust est d'embarquer le strict minimum dans le noyau du langage et d'utiliser des crates</code> pour ajouter des fonctions ou structures.</p>
num_rational</code> ne fait pas partie du langage, c'est une dépendance externe.</p>
Pour gérer les dépendances il faut utiliser le fichier Cargo.toml</code> qui est crée à la racine du projet.</p>
[package]
</span>name </span>= </span>"doser"
</span>version </span>= </span>"0.1.0"
</span>authors </span>= [</span>"Cedric <cedric.brancourt@gmail.com>"</span>]
</span>edition </span>= </span>"2018"
</span>
</span>[dependencies]
</span>num-rational </span>= </span>"0.2"
</span></code></pre>
La section dependencies</code> permet de référencer les dépendances à récupérer lors du cargo build</code> ou cargo run</code>.</p>
Le type Ratio</code> prend un paramètre si l'on regarde la définition de ce type</a>.</p>
La définition du constructeur est pub fn new(numer: T, denom: T) -> Ratio<T></code>.</p>
Puisqu'il existe plusieurs types de numériques suivant leur taille, signés ou pas, la bibliothèque utilise un type générique</a> T</code>. Qui donnera un Ratio</code> dérivé de ce type.</p>
Dans le cadre de notre recette, les quantités négatives n'étant pas possible, il ne s'agira que d'entiers non signés de 32 bits: u32</code>.</p>
À présent définissons une méthode scale</code> qui sera en charge de retourner un nouvel ingrédient multiplié par la quantité.</p>
Un nouvel ingrédient, car il n'est pas question ici de changer la valeur de l'ingrédient d'origine, mais d'en obtenir un nouveau à l'échelle de la recette.</p>
// ingredient.rs
</span>// ...
</span>
</span>impl </span>Ingredient {
</span>    </span>pub </span>fn </span>scale</span>(</span>&</span>self</span>, </span>mult</span>: </span>u32</span>) -> </span>Self </span>{
</span>        </span>Self </span>{
</span>            label: self.label.</span>clone</span>(),
</span>            quantity: self.quantity </span>*</span> mult,
</span>        }
</span>    }
</span>}
</span></code></pre>
impl</code> nous permet de définir des méthodes pour la structure Ingredient</code>.
Nous définissons une méthode publique (pub</code>) nommée scale</code>.</p>
Elle prend en argument :</p>

&self</code> qui est une référence</a> à l'objet courant.</li>
mult: u32</code> qui est notre multiplicateur de type u32</code></li>
</ul>
Elle retourne Self</code> qui est un alias vers le type courant, donc vers Ingredient</code></p>
Le corps de la fonction se contente de retourner une nouvelle instance d'ingrédient dont :</p>

la quantity</code> est multipliée par mult</code>. Ce qui retourne un nouveau Ratio</code></li>
le label est lui explicitement cloné.
Sinon nous aurions transféré la propriété du label au nouvel ingrédient. Ce qui produirait une erreur de compilation car leur cycle de vie est différent.</li>
</ul>
Tests unitaires</h3>
Rust permet d'écrire des tests unitaires à proximité du code source sans les embarquer dans le build de production.</p>
Beaucoup de tests qui auraient été écrits dans un langage interprété et non typé sont évités car le compilateur sert de garde-fou.</p>
L'unique test à écrire dans notre cas est de vérifier que la logique implémentée est la bonne.</p>
// ingredient.rs
</span>// ...
</span>
</span>#[cfg(test)]
</span>mod </span>tests {
</span>    </span>use crate</span>::Ingredient;
</span>    </span>use </span>num_rational::Ratio;
</span>
</span>    #[test]
</span>    </span>fn </span>it_scale_quantity</span>() {
</span>        </span>let</span> quantity </span>= </span>Ratio::new(</span>1</span>, </span>2</span>);
</span>        </span>let</span> ingredient </span>=</span> Ingredient {
</span>            label: </span>""</span>.</span>to_string</span>(),
</span>            quantity,
</span>        };
</span>
</span>        assert_eq!(ingredient.</span>scale</span>(</span>2</span>).quantity, Ratio::from_integer(</span>1</span>))
</span>    }
</span>}
</span>
</span></code></pre>
#[cfg(test)]</code> est une annotation destinée au compilateur.
Elle indique que la section qui suit est destinée à l'environnement de test et donc ne sera pas embarquée dans le binaire de production.</p>
Ensuite est défini un module de tests avec mod tests {}</code>.
Ce module importe ses dépendances à Ratio</code> et Ingredient</code> avec use</code>.</p>
Viens ensuite notre test qui n'est autre qu'une fonction précédée de l'annotation #[test]</code>.</p>
Dans ce test on crée un ingrédient avec une quantity</code> de 1/2.</p>
Puis on vérifie que la quantity</code> du résultat d'une multiplication par 2 nous donne un Ratio</code> équivalent à 1.</p>
À ce stade vous pouvez jouer avec le fichier ingredient.rs dans le Playground</a></p>
Le parser</h2>
Notre recette est une chaîne de caractères multi-lignes.
Nous allons l'analyser pour retourner une collection d'ingrédients.</p>
Notre analyseur est lui aussi un module nommé parser</code>.
Il expose une fonction publique:</p>
pub </span>fn </span>parse</span>(</span>input</span>: </span>&</span>str</span>) -> </span>Vec</span><Ingredient> {
</span>    input.</span>lines</span>().</span>filter_map</span>(</span>&</span>parse_line).</span>collect</span>()
</span>}
</span></code></pre>
Cette fonction prend en paramètre un &str</code> que nous avons déjà rencontré plus haut.</p>
Elle renvoi une collection de type vecteur</a> Vec</code>.</p>
Le type Vec</code> attend lui aussi un paramètre, qui est le type de ses éléments (Ingredient</code>).</p>
lines()</code> appelé sur input</code> renvoi un itérateur</a> sur les lignes du &str</code>.</p>
Ensuite est appelé filter_map</code></a> qui fonctionne comme un map</code> classique à quelque détails près, nous y reviendrons plus loin.</p>
L'argument &parse_line</code> est une référence à la fonction parse_line</code> qui sera appliquée sur chaque ligne.</p>
Le tout renvoi un iterator</code> de nouveau.</p>
Pour terminer nous appelons collect</code></a> qui s'applique aux itérateurs pour renvoyer une collection (Vec</code>).</p>
Revenons à notre fonction parse_line</code>.</p>
// parser.rs
</span>// ...
</span>
</span>fn </span>parse_line</span>(</span>line</span>: </span>&</span>str</span>) -> </span>Option</span><Ingredient> {
</span>    </span>let</span> splits: </span>Vec</span><</span>&</span>str</span>> </span>=</span> line.</span>splitn</span>(</span>2</span>, </span>' '</span>).</span>collect</span>();
</span>
</span>    </span>match</span> splits[</span>..</span>] {
</span>        [quantity, label] </span>=> </span>Some</span>(Ingredient {
</span>            quantity: </span>str_to_ratio</span>(quantity),
</span>            label: label.</span>to_string</span>(),
</span>        }),
</span>        </span>_ => </span>None</span>,
</span>    }
</span>}
</span></code></pre>
Cette fonction prend en argument un &str</code> qui représente une ligne de texte et l'analyse pour en ressortir un Ingredient</code>.</p>
Cependant il est possible que la ligne ne soit pas formatée correctement.</p>
Dans ce cas quel est le retour de la fonction ?</p>
Rust n'a pas de nil</code> ou null</code>, comme d'autres langages il dispose de valeurs mises en boites, ici Option</code></a> qui dénote l'éventualité qu'il y ait une valeur.</p>
Option</code> est une énumération de valeurs possibles:</p>

Some(Ingredient)</code></li>
None</code></li>
</ul>
line.splitn(2, ' ').collect()</code> divise la ligne en 2 parties à partir du premier espace, et retourne une collection.</p>
let splits: Vec<&str></code> permet de préciser le type de la collection attendue qui ne peut pas être toujours déduit par le compilateur.</p>
splits</code> est ensuite destructuré avec match</code> qui permet de faire des branches en fonction des motifs (pattern matching</em>).</p>
Soit nous obtenons 2 éléments pour construire Some(Ingredient)</code> soit la ligne est mal formatée et donc None</code>.</p>
Lors de la construction de Ingredient</code>, to_string</code> est appelé sur label</code>.</p>
label</code> localement est de type &str</code>(référence empruntée) alors que la structure Ingredient</code> attend un String</code> (valeur possédée), to_string</code> opère la copie comme vu précédemment avec clone</code>.</p>
Puisque nous obtenons un résultat de type Option</code> , dans la fonction parse</code> nous obtenons un Iterator<Option></code>.</p>
Pour obtenir un Iterator<Ingredient></code> il suffit d'utiliser filter_map</code></a> qui va ignorer les résultats de type None</code> et déballer l'ingrédient du Some(Ingredient)</code>.</p>
Pour convertir quantity</code> qui est aussi de type &str</code> en Ratio</code>, nous utilisons la fonction str_to_ratio</code></p>
// parser.rs
</span>//...
</span>
</span>fn </span>str_to_ratio</span>(</span>s</span>: </span>&</span>str</span>) -> Ratio<</span>u32</span>> {
</span>    </span>let</span> numerics: </span>Vec</span><</span>u32</span>> </span>=</span> s
</span>        .</span>splitn</span>(</span>2</span>, </span>'/'</span>)
</span>        .</span>map</span>(</span>str</span>::parse::<</span>u32</span>>)
</span>        .</span>filter_map</span>(</span>Result</span>::ok)
</span>        .</span>collect</span>();
</span>
</span>    </span>match</span> numerics[</span>..</span>] {
</span>        [numer] </span>=> </span>Ratio::from_integer(numer),
</span>        [numer, denom] </span>=> </span>Ratio::new(numer, denom),
</span>        </span>_ => </span>panic!(</span>"Malformed recipe quantity: {:?}"</span>, numerics),
</span>    }
</span>}
</span></code></pre>
Cette fonction sépare le &str</code> en 2 parties à partir du /</code> puis transforme les résultats en u32</code>.</p>
filter_map</code> est de nouveau utilisé, cette fois pour n'obtenir que le contenu des boites Result::ok</code></a>.</p>
Ensuite le résultat est décomposé avec match</code>:</p>

une seule valeur c'est un Ratio</code> depuis un entier.</li>
deux valeurs c'est un Ratio</code> à partir d'un numérateur et d'un dénominateur.</li>
aucun des deux c'est une erreur.</li>
</ul>
panic!</code></a> est une macro comme tout ce qui se termine par un !</code>.
Elle termine le programme comme une exception non interceptée.</p>
En lecteur attentif, vous noterez qu'il aurait été préférable de renvoyer un Option<Ratio></code> pour sécuriser les erreurs d'analyse de la chaîne de caractères.
Ce qui n'est pas fait par besoin de démontrer panic!</code> dans l'article.</p>
La chanson de la main</h2>
Elle vient de loin ...</a></p>
De retour dans notre fichier main.rs</code> voyons comment combiner tout ça.</p>
// main.rs
</span>
</span>mod </span>ingredient;
</span>mod </span>parser;
</span></code></pre>
Cette forme de déclaration de module précise que les modules ingredient</code> et parser</code> se trouvent dans les fichiers du même nom.</p>
La fonction main</code> du fichier main.rs</code> est, sans surprise, celle qui est exécutée lors du lancement du programme.</p>
// main.rs
</span>
</span>fn </span>scale_ingredients</span>(</span>ins</span>: </span>Vec</span><Ingredient>, </span>mult</span>: </span>u32</span>) -> </span>Vec</span><Ingredient> {
</span>    ins.</span>iter</span>().</span>map</span>(|</span>e</span>| e.</span>scale</span>(mult)).</span>collect</span>()
</span>}
</span>
</span>fn </span>main</span>() {
</span>    </span>let</span> scale: </span>u32 </span>= </span>2</span>;
</span>    </span>let</span> base_ingredients </span>= </span>parser::parse(</span>RECIPE</span>);
</span>    </span>for</span> i </span>in</span> base_ingredients.</span>iter</span>() {
</span>        println!(</span>"</span>{}</span>"</span>, i.</span>scale</span>(scale))
</span>    }
</span>}
</span></code></pre>
Cette fonction déclare une variable locale scale</code> qui est le multiplicateur de la recette.
Puis utilise la fonction parse</code> du module parser</code> pour obtenir les ingrédients depuis RECIPE</code>.</p>
Ensuite nous itérons sur les ingrédients pour afficher l'ingrédient multiplié par l'échelle.</p>
iter()</code></a> Nous permet d'obtenir un Iterator</code> depuis un Vec</code>.</p>
println!</code></a> est la macro qui permet d'afficher sur la sortie standard.</p>
Pour qu'une valeur puisse être formatée pour la sortie texte, elle doit implémenter le Trait</code> Display</code></a>.</p>
Un Trait</code></a> s'apparente à une interface pour un comportement implémenté sur plusieurs types.</p>
L'implémentation de Display</code> pour notre ingrédient se déclare ainsi:</p>
// ingredient.rs
</span>
</span>impl </span>std::fmt::Display </span>for </span>Ingredient {
</span>    </span>fn </span>fmt</span>(</span>&</span>self</span>, </span>f</span>: </span>&mut </span>std::fmt::Formatter) -> std::fmt::Result {
</span>        write!(f, </span>"</span>{} {}</span>"</span>, self.quantity, self.label)
</span>    }
</span>}
</span></code></pre>
Elle prend en argument la structure courante et une fonction de formatage</a></p>
La macro write!</code> pousse les données formatées dans un tampon.
Le format choisi est tout simplement d'afficher la quantité suivie du libellé.</p>
Pour aller plus loin</h2>
L'ensemble du programme est disponible est disponible dans le Playground Rust</a>, qui permet de jouer avec le code sans avoir à installer Rust.</p>
Le code est également disponible sur github</a>.</p>
cargo test</code> permettra de lancer les tests.
cargo run</code> lancera l'application (en environnement de développement).</p>
Pour continuer d'expérimenter avec Rust je recommande de tenter ces exercices :</p>

sécuriser la fonction parser::str_to_ratio</code> pour supprimer le panic!</code></li>
faire en sorte de pouvoir passer le multiplicateur</a> à l'invocation du programme</li>
paralléliser l'exécution des parse_line</code> avec l'outillage du langage</a></li>
</ul>
Un dernier conseil pour la faim et le dosage de la rouille :</p>
Rust permet beaucoup d'optimisations de gestion de la mémoire. Cependant, la maîtrise de la recette est dans le dosage !</p>
Utiliser des références à tout bout de chandelles vous obligera à affronter le bourreau shaker</a>.</p>
Dans un premier temps abusez de clone</code>, puis optimisez progressivement.</p>
Toutes bonnes choses ayant une fin, il est temps de nous quitter.
Au revoir lecteur, je pars</a>...</p>

Droits et rôles dans une architecture orientée domaine

2018-11-08T13:25:00+00:00

Le chemin à emprunter en suivant la direction Domain Driven Design (DDD) n’est pas si complexe qu’il n’y paraît. Il requiert, entre autres, de se débarrasser de certains réflexes et idées préconçues. Surtout de la fâcheuse tendance qu’on a de se projeter dans l’implémentation et la technique en zappant l’analyse du domaine. (Si vous n’êtes pas familier avec le DDD, je vous recommande de vous familiariser avec le sujet avant la lecture de cet article.)

C’est vrai aussi pour la question des permissions dans le système. Cette question revient très régulièrement. Comme toujours il n’y a pas de réponse universelle, mais il y a des orientations qu’il est bon de connaître l’heure du choix venue.

Comment faire cohabiter la notion de permission avec la modélisation du domaine</a> ? C’est la question à laquelle je me propose de répondre dans cet article.

Questions / réponses</h2>
Pour introduire la question et la réponse, je vous rapporte une conversation que j'ai eue avec un architecte logiciel externe à l'œil perçant (monsieur X).
Je venais de présenter un diagramme qui détaille le flux de contrôle d'une commande (ci-dessous).
(Image manquante : base_service_arch.png — perdue avec la fermeture du blog Synbioz)
Voici les questions et réponses qui suivirent cette présentation.

x:
Dans ton modèle de flux pour l'exécution des commandes, tu places où le contrôle d'autorisation ?
cb:
Bonne question :) Je distingue 2 choses : le rôle et la propriété. Je suppose que tu parles du rôle. Pour moi les rôles d'un utilisateur sont liés à son identité.
x:
Typiquement un utilisateur doit avoir le rôle X, Y ou Z pour effectuer une action donnée.
cb:
En règle générale je le mettrais dans les interactors/handlers.
x:
Du point de vue métier, c'est généralement exprimé comme précondition à un use case.
cb:
Oui, en effet c'est une précondition ou un argument requis. Parfois même une règle du domaine.
x:
Il y a quelque chose qui me chiffonne à l'idée de passer un objet "current user" à toutes mes commandes
cb:
Oui, tu remarqueras que je ne parle pas de current user. C'est plus qualifié que ça. Le rôle fait partie du jargon du domaine. Dans le cadre de la revue de document par exemple :
Dans mon review handler je transforme mon user en `reviewer_uid</code> et je le passe a mon business tout simplement. Donc si je peux pas transformer mon user en reviewer_uid</code>, c'est qu'une condition de permission n'est pas satisfaite. La réponse sera un échec pour cause de permission.`
`x:`
`Et ton business va chercher les rôles ?`
`cb:`
`Non, si j'avais besoin de plus d'informations sur le reviewer dans mon domaine j'aurai un modèle reviewer en relation avec l'UID de l'utilisateur.`
`x:`
`Oui, d'office je ne comptais pas passer un objet avec des token oauth etc … :)`
`cb:`
`Si le rôle doit interagir avec le domaine au-delà d'une simple référence (UID), c'est le rôle que je passe (entité). Je trouve ça élégant car ça concilie la gestion du rôle et le domain model. La transformation du user en reviewer se fait dans la couche appli. Tandis que l'exploitation du reviewer se fait dans la couche domaine.`
`x:`
`Mais donc la responsabilité de vérifier l'autorisation revient au use case… ce qui peut élargir significativement le nombre de cas à tester :-\`
`cb:`
`Non, je dirais plutôt dans la boundary. Son rôle est de transformer les objets du dehors vers ceux du domaine, ça te permet de "fail early" en validant les entrées.`
`x:`
`Oui ça fonctionne tant que la décision ne dépend pas des données qui vont être chargées dans le use case (typiquement une vérification de propriété)`
`cb:`
`Il n'y pas de "silver bullet" désolé :) La propriété c'est radicalement différent. En tout cas selon moi. Elle serait plutôt un scope d'accès aux ressources.`
`x:`
`Oui t'as raison je pense que ce problème-là doit être réglé via le scoping, ça devrait plus souvent se terminer en "record not found" que "unauthorized" voilà :)`
`cb:`
`J'ai fait` `un article</a> là-dessus y a longtemps. Où j'oriente vers des Activity Access control`
`x:`
`Ok je regarderai ça`
`cb:`
`Si tu le permets, je vais garder notre conversation pour que je puisse éclaircir le sujet plus tard dans le document. </blockquote>`
`Ce monsieur X a le don de poser les bonnes questions. Ce qui en fait un collaborateur à forte valeur ajoutée.`
`Il paraît que j'ai un don aussi : Quand quelqu'un me demande quelque chose, je lui explique comment s'en passer. C'est moisi comme super pouvoir.`
Exemple concret</h2> Par expérience nous utilisons des abstractions pour qualifier les composants logiciels lors de nos échanges. Mais cette pratique a la contrainte de n'être accessible qu'à ceux qui ont déjà l'expérience de l'abstraction en question. Il faut donc du concret, de l'exemple. J'aime beaucoup les exemples, mais je redoute leur principal effet pervers : ils sont souvent pris au pied de la lettre. N'oublions pas de nous inspirer des exemples, mais gardons-nous de les reproduire. Posons le contexte de l'exemple : Il s'agit d'un service qui permet de rédiger et publier des GTC</abbr>. Plusieurs processus sont inclus : rédiger un brouillon, publier un nouveau document à partir d'un brouillon, définir la version courante… Nous allons nous intéresser seulement au cas de l'ajout d'un nouveau brouillon. Puisque tout doit commencer par une analyse du domaine, parlons-en brièvement pour faire apparaître la notion de rôle dans le domaine. Notre jargon du domaine pour l'instant se résume à "ajouter" et "brouillon". Mais qui ? Dans notre contexte métier le brouillon est ajouté par son auteur. Nous avons maintenant un use case complet. Un auteur ajoute un brouillon. Le contexte technique dans notre exemple est déjà en place, car l'intégration se fait dans un système existant. Bien qu'il ne soit pas essentiel au principe de base, le contexte du système l'est pour l'exemple. Je vais donc planter le décor. Les services sont exposés au travers d'une API gateway. Elle est en charge de vérifier l'identité de l'utilisateur et d'enrichir la requête HTTP avec les propriétés liées. Les requêtes qui parviennent aux services contiennent déjà l'UID de l'utilisateur, ainsi que ses rôles dans l'ensemble du système d'information. Ces derniers viennent d'une brique d'authentification historique et n'ont pas de portée dans le domaine actuel. Par exemple, le rôle "admin" n'a aucun sens dans le contexte du domaine de la publication de conditions contractuelles. Un module rack (nommé MountApi) est en charge de filtrer et valider les paramètres reçus via HTTP. Ce qui nous affranchit de beaucoup de programmation défensive. Voilà pour le background, revenons à nos moutons. Nous avons une source d'authentification dont le rôle "admin" peut être un auteur de GTC. Faisons en sorte que notre code exprime le domaine. Notre aggregate Draft</code> (ligne 10 ci-dessous) ne pourra pas s'initialiser sans author_uid</code>. Ce qui évite de transiger avec les règles du domaine. Surtout dans le cadre d'un aggregate. Il en va de même pour toutes les méthodes du genre change_content(author_uid:, content:)</code>. De ce fait notre couche domaine dispose de la notion d'auteur, ce dernier est indispensable à l'écriture d'un brouillon. (Image manquante : domain_draft.png — perdue avec la fermeture du blog Synbioz) Si nous remontons dans la couche applicative (ligne 9 ci-dessous), notre service (command, interactor, use case) aura lui aussi besoin de ce paramètre qui doit lui être fourni, puisqu'il est une précondition au use case : (Image manquante : app_service.png — perdue avec la fermeture du blog Synbioz) Pour finir c'est dans notre couche infrastructure que nous transformons les données externes en données internes. Puisque par le canal HTTP nous obtenons des rôles avec la requête, notre handler est en charge de vérifier ceux-ci. Il agit comme une couche d'anti-corruption pour préserver les autres couches (App</code> et Domain</code>) et les garde centrées sur le domaine et isolées du reste du système. C'est une fonctionnalité partagée à travers un mixin (BaseHandler</code> ci-dessous). La stratégie est simple : Avec l'outil de gestion de permissions (ici activity_permission_engine</a>), on enregistre le handler comme une activité (ligne 15). Puis on autorise le rôle admin</code> à effectuer cette activité (ligne 17). Ensuite nous vérifions que l'utilisateur courant correspond bien à un des rôles pour lesquels l'activité est autorisée (lignes 11, et 22 à 27). S'il ne l'est pas une réponse appropriée est retournée sans aller plus loin. (Image manquante : infra_base_handler.png — perdue avec la fermeture du blog Synbioz) À présent notre handler qui utilise le mixin BaseHandler</code> peut se contenter de passer l'UID de l'utilisateur courant comme celui de l'auteur. (Image manquante : handler.png — perdue avec la fermeture du blog Synbioz) Dans notre exemple le contrôle de droits d'accès se fait au niveau de la couche infrastructure car les rôles n'ont rien de local à l'application puisqu'un contexte borné (bounded context</a>) lui est dédié. Cependant dans le contexte borné du domaine de l'authentification ils seront partie prenante de l'application, voire du domaine. Ces rôles externes ne franchissent jamais la frontière de la couche applicative. Et cette dernière n'utilise que des concepts qui font partie de son domaine d'application (auteur). This is the end, my only friend…</h2> Au-delà de l'exemple fourni il y a beaucoup de manières d'arriver au même résultat. L'important c'est de bien identifier les zones de responsabilité de chaque couche (infrastructure, domaine, application). Éviter que l'implémentation des sessions (dans le giron de l'infrastructure) ne se répande partout dans les autres couches créant du couplage et brouillant la lisibilité (comme un current_user</code> qui se balade dans les modèles). Et rendre visible, les rôles dans la couche domaine. Il ne faudra surtout pas hésiter à implémenter le rôle comme un modèle local du domaine si les règles du métier rendent nécessaire l'interaction avec le domaine. Tous ces principes peuvent être transposés, quel que soit le langage ou le framework. Ils peuvent nécessiter quelques ajustements mineurs en fonction de la nature du domaine (pour la brique d'authentification par exemple). Ils sont la pierre de Rosette de l'architecture du système.

La métaphysique des systèmes proudhoniens

2018-05-17T13:25:00+00:00

Libertaire, Anarchiste, Utopiste, ZADiste, Étudiant (68) … C’est la saison ! Quelle étiquette coller à un système dessiné pour privilégier l’autonomie et l’indépendance de ses composants ?

C’est une promenade philosophique, sans conclusion, qui fait le parallèle entre une « Utopie » sociale et le design d’un système.

Proudhonien ?</h2>
Ces deux dernières années mes recherches documentaires professionnelles ont porté principalement sur la composition de systèmes distribués, plus particulièrement sur la capacité à diviser ces systèmes en sous-systèmes découplés.
L'objectif est de devenir plus efficace sur des systèmes dont l'éventail fonctionnel est large, et donc d'éviter le couplage entre les différentes fonctionnalités offertes par le système. (voir Pérégrinations vers une architecture découplée</a>)
Ces recherches ont fait écho à certaines de mes lectures sur les possibles alternatives de société et plus particulièrement la pensée de Pierre Joseph Proudhon</a>.
(Image manquante : Pierre-Joseph_Proudhon_thumb_650.png — perdue avec la fermeture du blog Synbioz)
Aujourd'hui quand je regarde ces systèmes avec une interprétation personnelle, ils présentent en effet des qualités et similitudes avec les aspirations de P.J. Proudhon.

De l'Utopie idéaliste ?</h2>
On peut se laisser porter par le courant, nager à contre courant, mais aussi rejoindre la berge et continuer à pied ! Cette dernière option n'est pas envisagée quand on idéalise, mais s'avère bien plus pratique.
Dans son genre, Proudhon n'était pas un idéaliste mais un pragmatique. Il donnait dans la proposition concrète. Une proposition qui tendait vers un idéal mais qui était faite aussi de compromis afin de la rendre pratique. Quitte à se contredire ! Ce qui lui a été reproché parfois.

Parmi l'énumération nombreuse des droits de l'homme que la sagesse du XIXe siècle recommence si souvent et si complaisamment, deux assez importants ont été oubliés, qui sont le droit de se contredire et le droit de s'en aller. — Charles Baudelaire </blockquote>
Dans la conception du système découplé il n'est point nécessaire de dogmatiser ni de réaliser l'idéal dans son intégralité. C'est une direction à suivre plus qu'un objectif à atteindre. Une force qui s'opère comme un contre-pouvoir aux processus qui sont employés par réflexe pavlovien.
L'ordre sans le pouvoir</h2>
Le pouvoir s'exerce sur des sujets, d'autres personnes ou entités. Quand il s'exerce sur soi, j'imagine qu'il doit s'appeler l'indépendance.
Dans notre système découplé l'abolition du pouvoir autoritaire peut se traduire par un passage du mode de coopération de l'orchestration à la chorégraphie</a>.
(Image manquante : orchestration_vs_choregraphy.png — perdue avec la fermeture du blog Synbioz — Building Microservices by Sam Newman, O'Reilly)
Il n'y a plus de relation impérative entre les composants du système, mais une relation réactive, comme le montrent les études plus formelles</a>.
La notion de contrôle de flux assurée par une cascade d'orchestrateurs disparaît au profit de l'apparition de plusieurs acteurs qui agissent de concert quand on leur donne la réplique.
Si le résultat de loin ressemble à un brouhaha, localement il est loin de brouiller l'écoute.
La décentralisation</h2>
En passant du mode orchestration au mode chorégraphie, en plus de nous affranchir de la notion de contrôle nous décentralisons la décision pour la rendre locale.
Chaque service est en charge d'opérer sur son strict périmètre de responsabilité, ses propres données. Aucun autre service ne peut faire d'ingérence dans ces dernières, ni produire d'effet de bord non maîtrisé. Il ne peut y avoir d'effets de bords sur d'autres services.
Autrement dit les décisions sont prises localement et ont un impact direct local uniquement.

La commune est par son essence… un être souverain. En cette qualité, la commune a le droit de se gouverner elle-même, de s'administrer, de s'imposer des taxes, de disposer de ses propriétés et de ses revenus, de créer pour sa jeunesse des écoles, d'y nommer des professeurs, de faire sa police, d'avoir sa gendarmerie, et sa garde civique ; de nommer ses juges ; d'avoir ses journaux, ses réunions, ses sociétés particulières, ses entrepôts, sa mercuriale, sa banque, etc. La commune prend des arrêtés, rend des ordonnances : qui empêche qu'elle n'aille jusqu'à se donner des lois ? Elle a son Église, son culte, son clergé, librement élus ; elle discute publiquement, en conseil municipal, dans ses journaux ou ses cercles, tout ce qui touche à ses intérêts ou excite son opinion… Il n'y a point de milieu : la commune sera souveraine ou succursale, tout ou rien — P.J. Proudhon </blockquote>
Le fédéralisme</h2>

Toutes mes idées économiques… peuvent se résumer en ces trois mots : Fédération agricole industrielle ; toutes mes vues politiques se réduisent à une formule semblable : Fédération politique ou décentralisation… Toutes mes espérances actuelles et futures sont exprimées par ce troisième terme, corollaire des deux autres : Fédération progressive — P.J. Proudhon </blockquote>
Pour que les systèmes puissent coopérer, ils doivent adhérer à des principes communs. L'adhésion d'un service à un système est une initiative qui est gérée dans son périmètre de décision.
En souscrivant à un bus d'événements commun, les services forment une fédération.
(Image manquante : La_Bretagne_Fédérale - novembre 1931.jpg — perdue avec la fermeture du blog Synbioz)

Le contrat de fédération, dont l'essence est de réserver toujours plus aux citoyens qu'à l'État, aux autorités municipales et provinciales plus qu'à l'autorité centrale, pouvait seul nous mettre sur le chemin de la vérité. — P.J. Proudhon </blockquote>
Les échanges au sein de cette fédération sont régulés par un contrat. C'est la clé de voûte du système et de la fédération.
La définition des APIs et des formats de messages échangés de manière formelle et concrète permet aux composants du système de s'intégrer sans heurts. Empaqueté et distribué, notre contrat peut être utilisé par les tests d'intégration des services qui y souscrivent pour assurer la cohésion de l'ensemble.
Voila l'aspect fédéraliste du système. Son rôle est d'assurer la composition d'entités autonomes afin de pouvoir achever collectivement des projets plus grands.
La propriété</h2>
(Image manquante : data-ownership_thumb_650.png — perdue avec la fermeture du blog Synbioz)
Chaque service est seul propriétaire et exploitant de ses données internes. Il peut ainsi garantir sa cohérence interne et son autonomie.
Dans un système composé de Self-Contained Systems</a>, dont l'intégration repose sur un flux d'événements chaque système maintient sa propre version d'une donnée plus globale.
Le flux d'événements est partagé entre les différents services, chacun constitue son jeu de données local à partir de ce flux.
La propriété dans ce cas est non privative.
Le fruit du travail d'un service, ce sont quelques effets de bords sur la donnée locale, mais surtout un nouvel événement. Événement qui sera exploité par quantité d'autres services pour en produire de nouveaux.
Échanger le fruit du travail tout en mutualisant les ressources, ça laisserait rêveur plus d'un communard !
Une majorité de minorités</h2>

Un État de 26 millions d'âmes, comme serait l'Italie, est un État dans lequel toutes les fiertés provinciales et municipales sont confisquées au profit d'une puissance supérieure, qui les gouvernent. Là, toute localité doit se taire, l'esprit de clocher, faire silence : hors le jour des élections, dans lequel le citoyen manifeste sa souveraineté par un nom propre écrit sur un bulletin, la collectivité est absorbée dans le pouvoir central… La fusion, en un mot, c'est-à-dire l'anéantissement des nationalités particulières, où vivent et se distinguent les citoyens, en une nationalité abstraite où l'on ne respire ni ne se connaît plus : voilà l'unité… Et qui profite de ce régime d'unité ? Le peuple ? Non, les classes supérieures. — P.J. Proudhon </blockquote>
Puisque notre système est composé d'unités indépendantes dont les choix d'implémentation se font localement. Il est possible de faire cohabiter un grand nombre de services faisant tous appel à des technologies différentes. Permettant à chaque service d'exploiter les technologies qui répondent le mieux à son périmètre de responsabilités. La seule contrainte étant de respecter le contrat.
Un système qui valorise la diversité plutôt que de cacher les différences derrière un ordre dicté à un niveau supérieur.
Liberté, Égalité, Fraternité ou choucroute ?</h2>

Au témoignage de l'histoire, la fraternité, but suprême des révolutions, ne s'impose pas : elle a pour condition la liberté d'abord, l'égalité après. Comme si la justice nous disait à tous : Hommes, soyez libres ; citoyens, devenez égaux, et puis, frères, embrassez-vous. — P.J. Proudhon </blockquote>
Ce qui est vrai pour le système est vrai pour l'équipe qui le développe.

Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway </blockquote>
Le système fonctionne plutôt bien dans des équipes autogérées.
Puisque chaque membre est autonome dans son domaine, Il est indispensable que chacun ait une bonne connaissance de l'objectif global et final. Pour que chacun ait cette maitrise et cette envie positive, ils doivent être impliqués dès le début du projet.
(Image manquante : liberte-egalite-solidarite-20693_thumb_650.png — perdue avec la fermeture du blog Synbioz)
L'attachement au respect du contrat (API, conventions, guidelines…), est un autre pilier qui doit faire l'objet d'une grande attention. C'est ce qui garantit que le travail fourni par chacun peut s'intégrer correctement avec celui du voisin.
Finalement le ciment du tout doit être la fraternité bienveillante. Se serrer les coudes, assister, écouter, concéder, concilier et réconcilier.

Le système de l'humanité ne sera connu qu'à la fin de l'humanité. — P.J. Proudhon </blockquote>

Meta de la configuration, illustré avec Elixir

2018-02-22T13:25:00+00:00

La configuration des applications est un (non)sujet qui semble simple à première vue, mais qui n’est pas si bien maîtrisé par les développeurs juniors ou seniors.

Build configuration vs Run configuration</h2>
Attaquons par le fond du problème, sans tourner autour du pot. Il existe deux types de configuration dont les rôles et la mise en œuvre sont totalement orthogonaux.
Si votre expérience tourne autour de langages compilés, la distinction entre ces types de configuration vous est souvent imposée par l'outillage.
Si votre expérience tourne autour d'un langage interprété, comme Ruby, il est plus que probable que vous n'ayez jamais fait de distinction entre ces deux types de configuration.
Pourtant qu'il s'agisse de langage compilé ou interprété, ignorer cette distinction se traduit souvent par des applications rigides, difficiles à déployer, peu réutilisables ou par une explosion de la complexité de configuration.
Une confusion générale dont l'écho se fait entendre et se propage jusque dans les meilleures recommandations</a>.

Build configuration</h2>

Il s'agit de faire varier l'assemblage de l'application pour satisfaire des besoins ou contraintes en fonction du stade dans lequel on exécute l'application.

Par assemblage on entend configuration des dépendances et liens entre les modules de l'application.

Dans la grande majorité des cas, il y a trois stades ou environnements qui justifient de faire varier l'assemblage de l'application : développement, test et production.

Tous les environnements doivent être une variation minimale de celui de production. Une trop grande divergence produirait une application différente de celle développée ou testée et des comportements incohérents et non reproductibles.

L'environnement de développement varie souvent en incluant un debugger, un backend de persistance allégé, le hot reloading du code, la verbosité des logs, ou une toute autre manière de servir l'application.

Prenons l'exemple d'une application JavaScript à destination du navigateur : l'environnement de développement ne sert pas de fichiers « minifiés », ni assemblés, il inclut parfois des outils d'assistance au debugging, linting, etc.

Dans le cas d'une application Ruby il peut inclure un debugger, un analyseur de code statique, une console améliorée …

L'environnement de test diffère souvent de l'environnement de production par la présence d'un framework de test, et surtout si le code est correctement architecturé, par l'utilisation de dépendances de substitution (adapters) pour les I/O.

En règle générale, ces configurations de build sont référencées dans un fichier car elles sont (presque) toujours identiques. Que ce soit sur le poste de Victor, Hugo ou Quentin, lorsque nous jouons les tests unitaires, ils s'exécutent tous avec le même adapter de persistance.

Par exemple dans une application Rails vous trouverez des fichiers d'environnement pour le développement, test, et production, ainsi que des bundles différents pour chaque environnement.

Si vous trouvez des fichiers config/environnement/staging.rb</code>, config/environnement/qa.rb</code>, config/environnement/feature.rb</code> … C'est une erreur.

Ce sont des configurations qui varient en fonction du stack dans lequel on fait tourner l'application, et donc des run configurations.

Sur une plate-forme de « Staging », « QA » ou le « cluster-prod-2 », c'est toujours le build de production qui tourne. Sinon comment assurer le résultat en production avec un build différent ?

Dans l'exemple d'une application JavaScript qui est build avec Webpack, vous trouverez aussi des fichiers destinés à assembler l'application pour les différents environnements couvrant toujours les mêmes besoins, à savoir faire varier les dépendances incluses dans le build, et l'assemblage des modules. Si vous trouvez l'URL du backend de l'application dans ces fichiers, c'est également un problème de conception, car celle-ci doit varier au run et non au build.

Enfin prenons l'exemple d'une application Elixir : Mix est utilisé pour faire varier la configuration au build. Toujours pour les mêmes raisons. Et vous trouverez parfois les même erreurs, à savoir des environnements qui n'en sont pas. Et des configurations de run qui n'ont rien à y faire.

Run configuration</h2>
Ces configurations n'ont pas pour but de faire varier le comportement de l'application ni de modifier ses dépendances.
Elles sont utilisées pour adapter les variables du stack</em> courant : les URLs des services en relation, les credentials</em> de la DB, le port sur lequel on écoute …
Elles ne nécessitent pas de recompiler, réassembler ou redéployer l'application pour varier.
En général un simple redémarrage suffit.</p>
En règle générale les variables d'environnement sont utilisées pour faire varier la configuration.
Mais dans le cadre d'une application JavaScript exécutée dans un document HTML, c'est ce dernier qui porte la configuration et qui la fournit en argument du script d'initialisation de l'application.</p>
Côté bonnes pratiques, il est recommandé d'utiliser les variables d'environnement. Mais attention à ne pas les disséminer partout dans la codebase</em>.
Un fichier fournissant un dictionnaire des clés/valeurs dans lequel on interpole les variables d'environnement fera des miracles en cas de changement de noms de variables et en termes de lisibilité.</p>
Les mécanismes fournis par les plate-formes d'exécution et les frameworks</em> servent principalement à faire varier les build configurations</em></strong>.
Il vaut mieux construire votre module de configuration (ou en utiliser un tout fait), pour encapsuler celles-ci, gérer les valeurs par défaut, etc, plutôt que d'utiliser le mécanisme de build</strong>, qui n'est pas vraiment fait pour.</p>

Exemple d'une app Ruby et/ou Rails</h3>
N'ajoutez pas vos configurations dans les fichiers d'environnement du framework ! Tout simplement ajoutez un fichier config/my_app.yml</code> qui contiendra les variables de votre application. Ensuite chargez-le dans un initializer et interpolez les variables d'environnement grâce à ERB. Que ce soit dans une application rails ou dans une bibliothèque Ruby la technique est identique.

module </span>MyApp
</span>  </span>extend </span>self
</span>
</span>  </span>attr_writer </span>:config
</span>
</span>  </span>def </span>config
</span>    @config </span>||= </span>MyApp</span>::</span>Config</span>.</span>new</span>()
</span>  </span>end
</span>
</span>  </span>def </span>configure
</span>    </span>yield</span>(config)
</span>  </span>end
</span>
</span>  </span>def </span>load_config_file</span>(</span>file</span>)
</span>    config </span>= </span>YAML</span>.</span>load</span>(</span>ERB</span>.</span>new</span>(</span>File</span>.read(file)))
</span>  </span>end
</span>end
</span></code></pre>
module </span>MyApp
</span>  </span>class </span>Config
</span>    </span>attr_accessor </span>:url_example
</span>
</span>    </span>def </span>initialize</span>(</span>opts</span>)
</span>      url_example </span>=</span> opts.fetch(</span>:url_example</span>)
</span>    </span>end
</span>  </span>end
</span>end
</span></code></pre>
# config.yml
</span>
</span>url_example</span>: </span><%= ENV.fetch("URL_EXAMPLE", "http://default.value") %>
</span></code></pre>
De cette manière vous pouvez gérer la configuration de l'application comme bon vous semble :</p>
MyApp</span>.load_config_file(</span>"config.yml"</span>)
</span>
</span># Ou
</span>
</span>MyApp</span>.configure </span>do </span>|</span>config</span>|
</span>  config.url_example </span>= </span>"http://another.value"
</span>end
</span>
</span># Ou
</span>
</span>MyApp</span>.config </span>= </span>MyApp</span>::</span>Config</span>.</span>new</span>(</span>url_example: </span>"http://another.value"</span>)
</span>
</span># …
</span>
</span></code></pre>
Elixir et les env vars</h2>
Si vous développez et déployez des applications Elixir à des fins de production, il y a de fortes chances pour que vous vous soyez cassé les dents sur le build</strong> d'une release</em>, comme on peut le lire un peu partout sur le web (d'autant plus si vous avez été (dé)formés par RubyOnRails).</p>
Les configurations gérées avec Mix sont destinées au build</strong>.
Si vous utilisez System.get_env</code> dans la configuration Mix, celle-ci sera statique car évaluée à la compilation ; Et c'est bien normal ! Pour comprendre pourquoi, relisez l'article depuis le début, mais avec attention cette fois.</p>
Il faut donc comme dit précédemment construire son propre module de configuration de l'application qui pourra servir de proxy</em> aux configurations de Mix.</p>
Un exemple</h3>
Pour illustrer le principe prenons l'exemple d'une application « iFriend », pour ceux qui n'ont pas d'amis, qui envoie un certain nombre de « bonjour » par SMS.</p>
Build configuration</h4>
Lorsque le développeur travaille sur l'application il n'a pas intérêt à envoyer des SMS, parce que c'est long, coûteux, et difficile à vérifier ; Idem lorsque la suite de test s'exécute.</p>
Il serait possible d'utiliser un bouchon pour la SMS gateway</em>, mais ce n'est pas la piste que nous explorons afin de ne pas alourdir les dépendances de l'environnement de développement.</p>
Et si en fonction de l'environnement de build les IO de l'application utilisent des adapters</em> différents ?
Dans le cas de l'environnement de production</strong>, nous utilisons un adapter</em> qui utilise une SMS gateway</em> au travers de HTTP.
Dans l'environnement de dev</strong>, les SMS envoyés sont directement envoyés sur la sortie standard.
Dans l'environnement de test</strong>, ils sont capturés pour être comptés et vérifiés.</p>
Ainsi nos différents fichiers d'environnement de build</strong> ressembleront à ceci :</p>
# config/config.exs
</span>
</span>use </span>Mix</span>.</span>Config
</span>
</span>config </span>:IFriend</span>, </span>:greet_medium_adapter</span>, </span>IFriend</span>.</span>GreetMedium</span>.</span>SMS
</span>
</span>
</span>case </span>Mix</span>.env </span>do
</span>  </span>:prod </span>-> </span>:ok
</span>  _ </span>-></span> import_config </span>"#{</span>Mix</span>.env}</span>.exs"
</span>end
</span></code></pre>
On définit l'adapter</em> dans la configuration de base, qui est utilisé pour la production.
Celui-ci est étendu pour les environnements de dev et test par les définitions ci-dessous.</p>
# config/dev.exs
</span>
</span>use </span>Mix</span>.</span>Config
</span>
</span>config </span>:IFriend</span>, </span>:greet_medium_adapter</span>, </span>IFriend</span>.</span>GreetMedium</span>.</span>IO
</span></code></pre>
Pour le développement on log</em> dans la console</p>
# config/test.exs
</span>
</span>use </span>Mix</span>.</span>Config
</span>
</span>config </span>:IFriend</span>, </span>:greet_medium_adapter</span>, </span>IFriend</span>.</span>GreetMedium</span>.</span>Memory
</span></code></pre>
Pour les tests on garde les messages en mémoire.
Ces configurations sont évaluées au moment du build</strong>, et sont donc figées dans la release</em> qui est produite.</p>
Elles sont utilisées par le code applicatif à l'aide de Application.get_env(:IFriend, :greet_medium_adapter)</code>.</p>
Exemple :</p>
  </span>def </span>greet</span>(max, count) </span>do
</span>    greet_medium().output(greeter())
</span>    greet(max, count </span>+ </span>1</span>)
</span>  </span>end
</span>
</span>  </span>defp </span>greet_medium </span>do
</span>    </span>Application</span>.get_env(</span>:IFriend</span>, </span>:greet_medium_adapter</span>)
</span>  </span>end
</span></code></pre>
En prime il sera aisé de remplacer les SMS</em> par des e-mails</em> ou des messages Discord, puisque le code est découplé.
Il suffira de créer un nouvel adapter</em>.</p>
Run configuration</h4>
Notre application pourra être configurée pour envoyer un message différent, suivant les préférences de la personne qui l'exécute, et faire varier la quantité de messages, ou encore modifier les credentials</em> et l'URL de la SMS gateway</em>.</p>
Ainsi lors d'un déploiement en staging</em> il sera possible d'utiliser un service alternatif ou un bouchon pour ne pas envoyer de SMS, tout en utilisant le build</em> de production.</p>
Comme je l'expliquais plus haut, Mix n'est pas destiné à configurer l'application, mais le build</strong> (c'est écrit #000 sur #FFF dans la documentation).</p>
Pour configurer l'application je recommande d'utiliser un module qui sert de proxy</em> à la configuration, et qui va nous permettre d'utiliser les valeurs des variables d'environnement présentes au run</strong> et non au build</strong>.</p>
# lib/i_friend/config.ex
</span>
</span>defmodule </span>IFriend</span>.</span>Config </span>do
</span>
</span>  # L'interface principale du module de config
</span>  </span>def </span>get</span>(app, key, default </span>\\ </span>nil</span>) </span>when is_atom</span>(app) </span>and is_atom</span>(key) </span>do
</span>    </span>case</span> read_config(</span>Application</span>.get_env(app, key)) </span>do
</span>      </span>nil </span>-></span> default
</span>      val </span>-></span> val
</span>    </span>end
</span>  </span>end
</span>
</span>  # Dans le cas du tupple {:system, var } on lit la variable sur le systeme courrant
</span>  </span>defp </span>read_config</span>({</span>:system</span>, var_name}), </span>do: </span>System</span>.get_env(var_name)
</span>  </span>defp </span>read_config</span>({</span>:system</span>, var_name, default}) </span>do
</span>    </span>case </span>System</span>.get_env(var_name) </span>do
</span>      </span>nil </span>-></span> default
</span>      val </span>-></span> val
</span>    </span>end
</span>  </span>end
</span>
</span>  # Si c'est une liste alors c'est une sous-clé de configuration
</span>  </span>defp </span>read_config</span>(list) </span>when is_list</span>(list) </span>do
</span>    </span>Enum</span>.reduce(list, [], </span>fn</span>(e, acc) </span>->  </span>[ read_config(e) </span>|</span> acc] </span>end</span>)
</span>  </span>end
</span>  </span>defp </span>read_config</span>({subconfig, val}) </span>when is_atom</span>(subconfig), </span>do: </span>{subconfig, read_config(val)}
</span>  </span>defp </span>read_config</span>(other), </span>do:</span> other
</span>
</span>
</span>  # Si on attend un entier, autant faire le cast dans le module
</span>  </span>def </span>get_cast</span>(</span>:integer</span>, app, key, default </span>\\ </span>nil</span>) </span>do
</span>    </span>case</span> get(app, key, default) </span>do
</span>      val </span>when</span> is_integer(val) </span>-></span> val
</span>      val </span>-> with </span>{i, </span>""</span>} </span><- </span>Integer</span>.parse(val)
</span>      </span>do
</span>        i
</span>      </span>else
</span>        err </span>-> raise </span>ArgumentError</span>, </span>message: </span>~s</span>"""
</span>        Error parsing Config value for #{</span>app}</span>, #{</span>key}</span> :
</span>        #{</span>err}</span> does not seem to be valid integer
</span>        """
</span>      </span>end
</span>    </span>end
</span>  </span>end
</span>end
</span></code></pre>
Notre fichier de configuration peut maintenant contenir des variables qui varient :)</p>
# config/config.exs
</span>
</span>use </span>Mix</span>.</span>Config
</span>
</span>config </span>:IFriend</span>, </span>:greeter</span>, {</span>:system</span>, </span>"GREETER"</span>, </span>"hello"</span>}
</span>config </span>:IFriend</span>, </span>:greeting</span>, [</span>max: </span>{</span>:system</span>, </span>"MAX"</span>}]
</span>config </span>:IFriend</span>, </span>:greet_medium_adapter</span>, </span>IFriend</span>.</span>GreetMedium</span>.</span>SMS
</span>
</span>case </span>Mix</span>.env </span>do
</span>  </span>:prod </span>-> </span>:ok
</span>  _ </span>-></span> import_config </span>"#{</span>Mix</span>.env}</span>.exs"
</span>end
</span></code></pre>
Et utiliser ces dernières dans notre application.</p>
# extrait de lib/i_friend.ex
</span>
</span>  </span>def </span>hello </span>do
</span>    greet(greet_count())
</span>  </span>end
</span>
</span>  </span>defp </span>greet</span>(max, count </span>\\ </span>0</span>)
</span>  </span>defp </span>greet</span>(max, count) </span>when</span> count </span>></span> max , </span>do: :ok
</span>  </span>defp </span>greet</span>(max, count) </span>do
</span>    greet_medium().output(greeter())
</span>    greet(max, count </span>+ </span>1</span>)
</span>  </span>end
</span>
</span>  </span>defp </span>greeter</span>, </span>do: </span>Config</span>.get(</span>:IFriend</span>, </span>:greeter</span>)
</span>  </span>defp </span>greet_count</span>, </span>do: </span>Config</span>.get_cast(</span>:interger</span>, </span>:IFriend</span>, </span>:greeting</span>, </span>:max</span>)
</span>  </span>defp </span>greet_medium</span>, </span>do: </span>Config</span>.get(</span>:IFriend</span>, </span>:greet_medium_adapter</span>)
</span></code></pre>
En ajustant les variables d'environnement GREETER</code> et MAX</code> je peux à présent faire varier le message et le nombre de messages sans avoir à build</strong> une nouvelle version.</p>
Les maux de la faim …</h2>
Distinguer les variables liées à l'assemblage de celles qui varient à l'exécution peut vite devenir indispensable, suivant la plate-forme employée.
Sur une plate-forme interprétée c'est tout aussi payant pour ce qui est de la lisibilité et la modularité.</p>
Ces connaissances théoriques peuvent être rapidement mises en pratique, quelle que soit votre techno de prédilection, et vous éviter des nœuds dans les synapses lorsque vous travaillez sur des systèmes multi-tiers ou distribués.</p>
La bibliothèque de configuration Elixir présentée ici fera l'objet d'un package</em> Hex très prochainement.
Ce qui sera sûrement l'occasion de détailler les patterns</em> utilisés dans le code.</p>
Pour les plus curieux d'entre vous qui ont lu jusqu'au bout, l'application d'exemple est disponible sur GitHub</a>.
Vous y trouverez l'exemple concret de configuration, mais aussi la recette pour empaqueter les releases</em> Elixir dans un conteneur docker avec Distillery.
(ce qui fera peut-être l'objet d'un autre article)</p>

Design stratégique et jeu de Go

2017-09-08T13:25:00+00:00

Dans l’article précédent nous avons effleuré le concept de design stratégique. La phase indispensable qui consiste à analyser notre système sous l’aspect et dans le référentiel du problème (par opposition à la solution).

J’ai insisté sur le fait que l’analyse du domaine est une étape incontournable. C’est souvent une étape oubliée, mais c’est fondamental lorsqu’on prétend répondre à un problème précis.

C’est ce qui est souligné dans l’épisode 7 de Clean code</a>. (Une série que je recommande tant pour le contenu pédagogique que pour l’humour désopilant d’Uncle Bob.)

Mais également clairement le fondamental de “Domain-Driven Design: Tackling Complexity in the Heart of Software” d’Eric Evans.

Et que l’on retrouve subtilement dans cet article de Martin Fowler</a>.

Objectifs</h2>
Pour rappel un de nos objectifs est de partitionner et découpler un système complexe afin de le rendre plus maintenable et évolutif.
La formulation du problème sous forme de sous-ensemble de problèmes. Ou Domain et Sub-Domain vont nous permettre plus tard d'accomplir le partitionnement de la solution (le système) en composants spécialisés dans résolution d'un sous-problème.
Si nous suivons ce principe, l'architecture de notre système devrait aboutir à une représentation employant des concepts identiques à celui du domaine du problème. (Nous détaillerons ceci dans la suite de la série d'articles)
C'est un mouvement, un verbe, pas une posture ou un nom.</h2>
Il est un autre point sur lequel je souhaite insister : la modélisation du problème comme de la solution, sont des processus itératifs. Ce ne sont ni des finalités, ni des résultats.
Ainsi évitons de penser « J'implémente le DDD » mais plutôt « J'oriente la conception en me basant sur l'observation du domaine »
Ou encore « c'est de la Clean Architecture » mais plutôt « Lorsque j'implémente une solution, je veille à ce qu'elle ne soit pas en contradiction avec les principes SOLID</a> »
C'est un peu à l'image du rémoulage de lames. Un de mes passe-temps favori. Les techniques sont multiples, ma préférée est le rémoulage depuis la pierre à gros grains puis de plus en plus fin jusqu'au polissage.
Je peux passer 10 minutes ou 2 heures sur un couteau, le processus est le même : Dégrossir le taillant avec un angle constant. Une fois le fil formé sur l'angle du taillant je passe au polissage qui va me donner la finition.
Mais une fois ce cycle effectué suivant le résultat que je souhaite atteindre — couteau pour les enfants ou rasoir… l'objectif est différent — je peux décider de relancer un cycle.
C'est un processus quasiment sans fin (sauf quand la pierre ou la lame a complètement disparu :))
L'analogie continue, à l'usage le fil de mon couteau s'émoussera il faudra donc entretenir celui-ci. Et donc renouveler le processus.
Et pour finir, l'expérience accumulée dans les précédents rémoulages, me permet de limiter la vitesse à la quelle le fil s'émoussera.
Greenfield vs Legacy</h2>
Est-ce qu'on peut entrer dans cette démarche pour tous les projets ? Probablement non, mais je n'ai pas de contre-exemple en tête.
Mais c'est une démarche qu'il convient d'entreprendre, que le projet soit nouveau tout beau, ou alors une infâme patate chaude.
Même dans le contexte de l'existant, l'analyse stratégique va permettre de faire évoluer le système et de l'assouplir petit à petit (il faudra peut-être des années).
Une autre étude de cas</h2>
Puisque le sujet est sérieux et critique, il me semble nécessaire d'apporter un second cas pour illustrer le tout.
Nous allons nous projeter dans un autre cas, il s'agit d'une application à destination des joueurs de Go. Elle permet de jouer en ligne ou localement et de suivre sa progression au jeu de Go</a>.
Je ne vais pas m'attarder sur la présentation de cet extraordinaire jeu de Stratégie originaire de l'Empire du Milieu sous le nom de Weiqi (Wei chi) et popularisé par l'Empire du Soleil Levant.
Vous trouverez tout ce qu'il faut sur le sujet en ligne dans votre langue favorite.
Ubiquitous Language</h2>
Faire en sorte que le système soit une implémentation de la solution qui utilise des représentations métaphoriques du domaine du problème, sous-entend qu'on utilisera le langage du domaine partout.
Tout au long de notre analyse nous devons collecter les termes du champ lexical de nos domaines et sous-domaines.
Ce sont ces termes qui devront être utilisés dans l'expression des tickets, la documentation, les réunions de projet, le code, les tests, les diagrammes, …
C'est pour cela qu'on l'appelle l'Ubiquitous Language</a>.
C'est une notion que l'on retrouve de nouveau dans les préconisations des experts précités. Parce qu'elle est une des clés de la lisibilité d'un projet tout entier mais surtout de sa cohérence !

Dans le domaine du GO un plateau de jeu s'appelle un Goban. Nous retrouverons donc Goban à tous les échelons de la communication ainsi que dans le code.
À la place de `game.current_playing_board</code> (qui est un nom pas trop déconnant) nous aurions game.goban</code>`
`Mon conseil pratique est que l'équipe maintienne un lexique pour chaque domaine / sous-domaine.`
`Le point de départ</h2> Dans un premier temps on peut dresser la liste des problèmes ou des situations auxquelles le système doit répondre. En d'autres termes, ses Use Cases de haut niveau ! (Tout se recoupe…)`Doit permettre jouer une partie en ligne sur les serveurs GO existant</li> Doit permettre de jouer localement contre un joueur humain ou une IA</li> Permet de visualiser et analyser des parties enregistrées</li> Permet de suivre sa progression et son ranking</li> </ul> Domaine</h2> Partant de ces fonctions attendues, nous allons tenter d'identifier quels sont les domaines concernés. Première approche</h3> Dans une première approche naïve nous résumons ceci au domaine du jeu de Go . Hum nous voila bien avancés… Il doit y avoir une erreur quelque part. Le domaine du jeu de Go concerne tout ce qui tourne autour du jeu en lui-même, ses règles, ses pierres, les différentes tailles de Goban… Mais est-ce que je réponds à mes Use Cases uniquement avec les règles du jeu de Go ? Non. Hum… Plus que ça.</h3> Si on reprend nos Use Cases : Il est question de parties en ligne sur des serveurs existants. Peut-être que le domaine du jeu en ligne est davantage une description de notre domaine ? Pas tout à fait non plus. Car il est aussi question d'analyse et de visualisation. Le concept d'analyse et de visualisation d'une partie semble ne pas se situer dans le domaine du jeu de go en tant que tel. Mais dans un domaine qui vient en support à celui-ci. Il en va de même de la partie contre une IA ? Non, notre domaine ne se résume pas à celui de l'intelligence artificielle. Alors que dire du suivi de progression et de ranking ? À quel domaine fait-il référence ? Finalement avec une expression plutôt claire des Uses Cases et une première analyse, il apparaît que déterminer le domaine n'est pas si simple. Que plusieurs domaines semblent se chevaucher. Mais rien de cohérent n'en sort. C'est tout simplement car nous manquons de contexte par rapport au problème global. Pour modéliser il nous faut creuser plus profond. Pourquoi suis-je ?</h3> Un bon filon à exploiter pour avancer plus loin, consiste à identifier les raisons profondes de concevoir le système. Qu'est-ce qu'il apporte à ce qui existe déjà ? Qu'est-ce qui fait sa raison d'être ? C'est en interrogeant les parties intéressées que nous obtenons en général la réponse. Qu'est-ce qui fait que notre plateforme de jeu est unique ? Nous interrogeons l'équipe produit : « Notre plateforme est compatible avec plusieurs serveurs disponibles » Qu'entend-on par compatible ? « L'usager peut démarrer une partie sur un de ces serveurs et la jouer, nous gardons l'historique de la partie pour ensuite l'analyser » « Notre plateforme dispose d'une fonctionnalité d'analyse de jeu poussée et intelligente, elle permet de repérer les différentes situations dans le déroulement d'une partie. Comme les yeux, les catégories de groupes, les Shichô et Geta… » D'accord on est bien loin de la simple visualisation de parties donc. « Nous centralisons également les résultats de toutes les parties jouées depuis la plateforme, qu'elles soient en ligne ou locales, nous les historisons, de manière à fournir des indicateurs sur le niveau comparatif du joueur. C'est un indicateur de progression. Mais aussi une bibliothèque de parties souvenir analyser ! » Bien, nous obtenons des informations très intéressantes ici. Dans un premier temps comme dans le jeu de Go, et beaucoup de courants de pensée asiatiques, le vide compte autant que le plein. Ici le grand absent est qu'ils ne mentionnent jamais un super Goban avec une ergonomie novatrice ou une nouvelle expérience du jeu de Go en VR ! Le déroulement du jeu en lui-même n'est pas une fonctionnalité clé, il n'est même pas mis en avant. Le silence de l'équipe produit à ce sujet est éloquent. Si le déroulement d'une partie de Go ne fait pas partie du problème principal, il en est une sorte de dépendance puisqu'il sert de support aux fonctionnalités clés. Nous posons tout de même la question et la réponse nous confirme cette déduction. « Non nous n'avons pas la prétention de révolutionner l'expérience en jeu, au contraire elle n'est qu'accessoire, car dans l'univers du Go nous utilisons le Smart Game Format pour échanger des données. Nous pourrions analyser toute partie qui n'est pas jouée sur la plateforme. La présence d'un Goban n'est qu'une commodité… » Très intéressant. Finalement le domaine que nous avons identifié en premier est un sous-domaine de soutien. Un espace du problème qui n'est pas critique pour la solution et qui n'est qu'un outil optionnel et remplaçable. Bon, il nous reste à classifier les autres sous-domaines. Priorités</h3> Pour continuer à découvrir et qualifier le domaine il nous faut aussi déterminer les priorités du commanditaire. Allons à la pêche aux informations en leur demandant dans un premier temps d'ordonner leurs fonctionnalités par ordre de valeur ajoutée. « Notre numéro 1 est la fonctionnalité d'analyse car elle est la clé de voute de la progression et se distingue vraiment par son ambition » « Notre numéro 2 c'est l'historisation des statistiques et les indicateurs de progression. C'est un complément pédagogique aux fonctionnalités d'analyse » « La compatibilité multi-serveur ne vient qu'en numéro 3. Car l'impact pédagogique est moindre. Le support de 2 serveurs majeurs devrait déjà satisfaire une bonne partie de la population de joueurs » Bien, il semble que le domaine principal de notre système soit davantage celui de l'analyse d'une partie de Go. C'est le problème principal qu'on semble chercher à résoudre, alors qu'au début de notre analyse il n'apparaissait que comme un problème secondaire. Une dernière question pour la route, vous allez voir c'est marrant :) Comment le système est il financé, quel est votre modèle économique ? « Aujourd'hui nous n'avons pas encore bien identifié comment nous pourrions pérenniser le système, nous bénéficions de financements participatifs. Nous ne souhaitons pas que l'accès au service soit payant. Mais nous songeons sérieusement à proposer un service de coaching, en nous appuyant sur les statistiques du joueur et des analyses avancées, nous pourrions proposer un suivi personnalisé avec des conseils pour progresser.» Ah ! En effet l'avenir du produit dépend aussi du moteur d'analyse. Si il est négligé le projet sera forcément un échec. Une autre perspective</h3> Nous avons maintenant une connaissance plus profonde et structurée du domaine du système. Aujourd'hui notre perception du domaine s'est modifiée radicalement : (Image manquante : domain_du_system.png — perdue avec la fermeture du blog Synbioz) Notre plateforme est en fait composée d'un domaine cœur et critique d'analyse. Analyser ses propres parties en tant que joueur est un facilitateur d'accès à l'analyse. C'est donc un domaine générique moins critique. Il en va de même pour les domaines « Jouer une partie » et « Compatibilité Serveur ». Ce dernier semble faire partie de l'espace solution, car l'intégration serveur nous fait penser directement au jargon technique. Cependant pour notre client et dans le lexique du domaine cela fait référence à une fonctionnalité du produit recherchée par les joueurs. Exploitation</h2> Maintenant que nous avons une meilleure compréhension du domaine, nous pouvons prendre des décisions stratégiques : Notre domaine critique de l'analyse sera notre point de départ et celui que nous devons sécuriser en premier. Nous approfondirons sûrement la modélisation en commençant par ce domaine. Nous mettrons nos meilleurs experts sur la question. Le niveau de qualité attendu dans l'implémentation sera plus élevé. </li> Le domaine d'historique et de progression bien qu'il fasse partie du cursus pédagogique n'est pas le plus critique. Nos exigences sur cette partie seront moindres dans un premier temps. Nous ne traiterons pas ce sujet en priorité. Il fera l'objet d'une couverture fonctionnelle minime et s'étendra au besoin. </li> Jouer une partie, n'est qu'une commodité offerte. Nous pourrions juste nous contenter d'intégrer une solution existante, comme WGo.js. Ce qui nous éviterait de gaspiller de précieuses ressources dans le développement et la maintenance. </li> La compatibilité multi-serveurs n'est pas non plus une priorité. L'interfaçage se veut simple au départ puisque l'objectif est de récupérer les parties jouées pour un joueur. Confier certaines parties de ce sous-domaine à une équipe externe semble envisageable. </li> </ul> Tout ceci doit nous permettre de sécuriser le développement et la direction prise. Ici nous optimisons le time to market sans sacrifier la qualité de notre avantage concurrentiel. La forme du système</h2> Comme les pierres posées successivement sur le Goban forment l'image finale de la partie. Les domaines que nous avons identifiés vont nous aider à former les relations et les unités livrables du système. C'est ce que nous aborderons dans la série, lorsque nous étudierons plus le domaine du problème, mais celui de la solution. Cependant si vous clignez des yeux très vite en regardant le diagramme du domaine vous discernerez les contours vagues de ce que l'on nomme des bounded context. Dans le jeu de Go les pierres disparaissent, les tensions stratégiques évoluent d'un côté à l'autre du Goban. Il en va de même pour notre domaine qui est amené à évoluer, voir apparaitre de nouveaux domaines et disparaitre d'autres, voir les enjeux évoluer. Comment jouer au Go sans analyse stratégique ? Comment espérer gagner une partie sans réviser sa stratégie régulièrement pour l'adapter à la situation ? Espérer gagner sur un coup de chance ou une maladresse de l'adversaire ne tend pas vers le Kung Fu (étymologique)</a>. Il en va de même pour le design de systèmes. Projetez-vous un peu dans l'analogie !

Domaine</h2>
Partant de ces fonctions attendues, nous allons tenter d'identifier quels sont les domaines concernés.</p>

Les grandes messes</h2>
Les écrits existent sur le sujet, certains semblent répondre aux problèmes exposés. En voici un résumé des grands principes.</p>

Les dénominateurs communs</h2>
Les différentes propositions que nous avons passé en revue ont beaucoup de points communs. Ce sont les propriétés essentielles véhiculées par ces architecture que nous cherchons à obtenir.</p>

Meta Lambda

Ports and Adapters at compile-time for Rust

Elixir amqp 1.2 et confirm handler

Du dosage de la rouille

Droits et rôles dans une architecture orientée domaine

La métaphysique des systèmes proudhoniens

Meta de la configuration, illustré avec Elixir

Design stratégique et jeu de Go

Pérégrinations vers une architecture découplée

Rails 5 web console and Docker

J'ai une dette technique et c'est mon choix ! ™

Meta Lambda

Ports and Adapters at compile-time for Rust

Elixir amqp 1.2 et confirm handler

Du dosage de la rouille

Droits et rôles dans une architecture orientée domaine

La métaphysique des systèmes proudhoniens

Proudhonien ?</h2> Ces deux dernières années mes recherches documentaires professionnelles ont porté principalement sur la composition de systèmes distribués, plus particulièrement sur la capacité à diviser ces systèmes en sous-systèmes découplés.</p>

L'ordre sans le pouvoir</h2> Le pouvoir s'exerce sur des sujets, d'autres personnes ou entités. Quand il s'exerce sur soi, j'imagine qu'il doit s'appeler l'indépendance.</p>

La propriété</h2> (Image manquante : data-ownership_thumb_650.png — perdue avec la fermeture du blog Synbioz)</em></p> Chaque service est seul propriétaire et exploitant de ses données internes. Il peut ainsi garantir sa cohérence interne et son autonomie.</p>

Meta de la configuration, illustré avec Elixir

Design stratégique et jeu de Go

Une autre étude de cas</h2> Puisque le sujet est sérieux et critique, il me semble nécessaire d'apporter un second cas pour illustrer le tout.</p>

Domaine</h2> Partant de ces fonctions attendues, nous allons tenter d'identifier quels sont les domaines concernés.</p>

Pérégrinations vers une architecture découplée

Du charabia technique</h3> Que fait mon application, ou commence et se termine une fonctionnalité ? Prenons l'exemple d'une application Rails touffue, voici ce qu'il arrive de trouver dans le répertoire app</p>

Les grandes messes</h2> Les écrits existent sur le sujet, certains semblent répondre aux problèmes exposés. En voici un résumé des grands principes.</p>

Les dénominateurs communs</h2> Les différentes propositions que nous avons passé en revue ont beaucoup de points communs. Ce sont les propriétés essentielles véhiculées par ces architecture que nous cherchons à obtenir.</p>

Rails 5 web console and Docker

J'ai une dette technique et c'est mon choix ! ™

Domaine</h2>
Partant de ces fonctions attendues, nous allons tenter d'identifier quels sont les domaines concernés.</p>

Les grandes messes</h2>
Les écrits existent sur le sujet, certains semblent répondre aux problèmes exposés. En voici un résumé des grands principes.</p>

Les dénominateurs communs</h2>
Les différentes propositions que nous avons passé en revue ont beaucoup de points communs. Ce sont les propriétés essentielles véhiculées par ces architecture que nous cherchons à obtenir.</p>