Strigo Code

zRAM, téléchargez de la RAM ! ou presque…

2024-05-12T00:00:00+02:00

Vous souvenez-vous de ces pubs que l’on voyait sur nos navigateurs au début des années 2000 ? Celles qui nous proposaient de « télécharger de la RAM » ! Eh bien c’est devenu réalité (ou presque) avec zRAM !

zRAM est un module du noyau Linux qui augmente la performance d’un ordinateur en gérant une mémoire virtuelle (ou mémoire d’échange, swap en anglais) dans la mémoire vive (RAM) plutôt que sur le disque dur comme c’est traditionnellement le cas. Pour le dire autrement, zRAM utilise un peu de la RAM pour y stocker une mémoire d’échange compressée. Grace à la compression, l’espace occupé en mémoire correspond généralement au tiers de la mémoire allouée. Et c’est là toute l’astuce ! D’une part, l’accès à la mémoire vive est bien plus rapide qu’un accès disque, d’autre part la compression/décompression de la mémoire vive prenant moins de temps que l’utilisation du disque dur sous forme de mémoire virtuelle, cela permet d’augmenter la réactivité d’un système GNU/Linux.

Situation de départ

Pour éprouver les gains de performance promis par zRAM, j’ai sous la main le candidat idéal : la compilation de la police de caractères Iosevka dont je vous avais déjà parlé dans l’article « Ligatures dans le terminal ».

En l’état actuel des choses, disposant d’un processeur à 12 cœurs, et avec une partition d’échange de 3,8Go sur le disque dur, il me faut compiler cette police en limitant le nombre de processus concurrents (via l’option --jCmd 6) et en réduisant fortement la priorité de ce traitement grâce à la commande nice.

La commande qui me sert à compiler la police est donc la suivante :

nice -n 10 npm run build -- --jCmd=6 ttf::IosevkaCustom

Sans cela, le système gèle totalement pendant plusieurs minutes durant la compilation, avant d’être en mesure de me rendre la main.

Jouons avec zRAM

Tout d’abord, installons les outils nécessaires à la manipulation de zRAM.

sudo apt install zram-tools       # installation de zram

Dès lors, un périphérique zRAM est créé, comme on peut le voir avec la commande zramctl.

❯ sudo zramctl                   
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       256M     0B    0B     0B      12

Par défaut, il a une taille de 256Mo, ce qui est bien trop faible vu que nous disposons de 16Go de RAM. Supprimons donc ce périphérique, pour en créer un à notre convenance, disons de 8Go.

sudo zramctl --reset /dev/zram0   # suppression du périphérique zRAM par défaut
sudo zramctl --find --size 8G     # création d'un périphérique zRAM de 8Go

Voyons ce que cela donne :

❯ sudo zramctl                   
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         8G     0B    0B     0B      12

Parfait ! Il nous faut à présent faire de ce périphérique une mémoire d’échange, puis l’activer.

sudo mkswap /dev/zram0            # faire de ce périphérique une mémoire d'échange (swap)
sudo swapon -p 100 /dev/zram0     # activer la mémoire d'échange avec une priorité de 100

❯ sudo zramctl                   
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         8G     0B    0B     0B      12 [SWAP]

Nous avons à présent deux partitions swap : /dev/zram0 que nous venons d’activer, et /dev/dm-1 notre partition sur disque.

❯ sudo swapon
NAME       TYPE      SIZE   USED PRIO
/dev/zram0 partition 8,7G 590,5M  100
/dev/dm-1  partition 3,8G     0B   -2

Nous pouvons désactiver cette dernière pour que notre système ne soit pas tenté d’écrire sur cette partition.

sudo swapoff /dev/dm-1            # désactive la mémoire d'échange sur disque

Et voilà !

L’épreuve du feu

Faisons un test, et sans filet : levons toute limitation ! La commande que l’on s’apprête à lancer sera donc la suivante :

npm run build -- ttf::IosevkaCustom

Le résultat est probant ! La compilation de la police, qui auparavant saturait la mémoire, la swap et les processeurs en générant de trop nombreux accès disque, s’effectue dorénavant sans heurt, en 1min 51s. Alors oui ça swap ! Aux alentours de 570Mo (2.77G non compressés) sur les 8Go autorisés ; mais aucun gel d’écran, tout est fluide ! Et ce alors même que les limitations sur le nombre de processus parallèles autorisés et sur la priorité du traitement ont été levées ! Merveilleux !

Persistance

Nous avons constaté que zRAM tenait ses promesses, seulement voilà, ce que nous avons fait là ne sera pas persisté au redémarrage du système, à moins de nous y prendre un peu différemment.

Pour persister ces changements, il est nécessaire d’après la documentation de Debian, d’éditer le fichier /etc/default/zramswap ; dans notre cas comme suit :

# /etc/default/zramswap
SIZE=8192  
PRIORITY=100 

Nous pourrions aussi lui indiquer un pourcentage de mémoire vive utilisable par zRAM avec PERCENT (qui prendra le dessus sur SIZE) ; et pourquoi pas changer d’algorithme de compressions avec ALGO, pour opter par exemple pour zstd qui est annoncé comme plus rapide et offrant un meilleur taux de compression que lzo, l’algorithme par défaut. Attention cependant à vérifier que cet algorithme soit bien supporté par le système.

❯ sudo cat /sys/block/zram0/comp_algorithm
lzo [lzo-rle] lz4 lz4hc zstd

Une fois le fichier /etc/default/zramswap mis à jour et sauvegardé, il reste à redémarrer le service zramswap.

❯ sudo service zramswap reload

Enfin, pour éviter que la partition swap sur disque soit montée au démarrage, il suffit de commenter la ligne correspondante dans le fichier /etc/fstab et redémarrer le démon systemctl.

❯ sudo systemctl daemon-reload

Au prochain redémarrage, notre nouvelle mémoire d’échange zRAM sera activée et effective pour notre plus grand plaisir !

Bonus

Petit cadeau pour finir, il est possible de personnaliser le moniteur système htop pour lui faire afficher les accès disque, les accès réseau, ainsi que la consommation de la mémoire zRAM ! Tout cela depuis htop lui-même, sans avoir besoin d’éditer le fichier de configuration à la main ! Pressez la touche F2, et laissez-vous guider !

De l’utilisation des variables d’instance, et de l’intérêt des accesseurs

2024-03-09T00:00:00+01:00

Nous sommes nombreux⋅ses à nous interroger sur la pertinence de l’utilisation directe de variables d’instances au sein d’une classe, ou s’il ne faudrait pas au contraire passer systématiquement par des accesseurs ? Ruby, comme à son habitude, nous laisse une grande liberté à ce sujet. Il nous faut alors nous demander quelles sont les implications et les incidences d’un choix ou d’un autre ? Que véhicule chacun de ces choix en matière d’intention ? Quelles sont les recommandations de la communauté et, plus largement, en ce qui concerne l’art de la programmation orientée objet ?

De quoi parle-t-on ?

Prenons dès à présent un exemple pour poser le cadre.

class User
  def initialize(firstnmae:, lastname:)
    @firstname = firstname
    @lastname = lastname
  end

  def fullname
    "#{@firstname} #{@lastname}"
  end
end

Dans l’exemple ci-dessus, nous utilisons les variables d’instance dans la méthode User#fullname. L’auteur⋅ice de ce code s’arrêta, le regarda, et cela lui sembla juste et bon.

Mais… car oui, il y a un mais, les paroles de Dave Thomas & Andy Hunt, auteurs de “The Pragmatic Programmer” lui revinrent à l’esprit ! Elles disaient ceci:

[…] whenever a module exposes a data structure, you’re coupling all the code that uses that structure to the implementation of that module. Where possible, always use accessor functions to read and write the attributes of objects. It will make it easier to add functionality in the future.

Et de poursuivre :

This use of accessor functions ties in with Meyer’s Uniform Access principle, described in Object-Oriented Software Construction¹, which states that:

All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

— The Pragmatic Programmer, Dave Thomas & Andy Hunt

Et effectivement, nous exposons ici les structures de données portées par notre classe ! Admettons alors, pour filer notre exemple, que nous souhaitions nous assurer que la méthode User#fullname retourne les noms en majuscules et les prénoms ornés d’une majuscule sur la seule première lettre. En poursuivant sur notre lancée, nous ferions certainement ceci :

class User
  def fullname
    "#{@firstname.titleize} #{@lastname.capitalize}"
  end
end

Pourquoi pas, mais nous voyons dores et déjà poindre une faiblesse dans cette approche !

Découpler pour préparer l’avenir

En effet, la prochaine demande d’évolution stipulera, dans un souci d’harmonisation et de cohérence, que les noms et prénoms soient toujours représentés sous cette forme, qu’ils fussent affichés sous leur forme concaténée ou individuellement. Dès lors, on se voit obligé de changer d’approche. Commençons par un petit réusinage :

class User
  attr_reader :firstname, :lastname

  def fullname
    "#{firstname} #{lastname}"
  end
end

Pour rappel, le réusinage ne doit en aucun cas changer le comportement initial. Ce n’est pas le cas ici, puisqu’on retrouve le comportement premier, sans gestion de la casse. Mais cela nous permet, pour les besoins de l’exercice, de mettre l’accent sur un point : si nous étions partis dès le début sur cette voie, celle de l’utilisation systématique d’accesseurs, alors pour répondre au besoin ici exprimé nous n’aurions eu qu’à adapter nos accesseurs, et cela présente deux avantages ! Le premier est que, comme l’entièreté du code repose sur ces accesseurs (l’interface que nous présentons au monde), il n’est nécessaire de réaliser de changement qu’au seul endroit de leur déclaration, et non à une myriade d’endroits éparpillés dans la classe. Le second est que cela nous permet de distinguer structure de données et manipulation de celle-ci ; en d’autres termes, il nous est possible de présenter la donnée de différentes manière et de conserver l’originale intacte. Cette dernière affirmation n’est vérifiée qu’à une seule condition, tout traitement de la donnée fournie à l’instantiation de l’objet se fera en dehors de l’initialiseur, celui-ci devant rester le plus basique possible. Prenons un exemple pour illustrer ce point. Au lieu d’écrire ceci :

class User
  attr_reader :firstname, :lastname

  def initialize(firstname:, lastname:)
    @firstname = firstname.titleize
    @lastname = lastname.capitalize
  end
end

Nous lui préférerons cela :

class User
  def initialize(firstname:, lastname:)
    @firstname = firstname
    @lastname = lastname
  end

  def firstname
    @firstname.titleize
  end

  def lastname
    @lastname.capitalize
  end
end

Dès lors, nous avons la possibilité d’auditer notre code avec beaucoup de précision, car aucune information n’est perdue. Cela est notamment très utile lorsque nous avons besoin diagnostiquer un comportement et de distinguer une donnée mal formée à l’initialisation de l’objet ou un mésusage lors de sa manipulation.

D’aucuns me rétorqueront qu’en utilisant les variables d’instances, on a l’assurance que celle-ci ne seront pas utilisées en dehors de la classe qui les héberge. C’est un point intéressant, mais partiellement faux tant Ruby a une notion très laxiste de la visibilité.

user = User.new(firstname: "Ada", lastname: "Lovelace")
=> #<User:0x00007fbdd11499c0 @firstname="Ada", @lastname="Lovelace">

user.instance_variable_get(:@firstname)
=> "Ada"

Par ailleurs, il est tout à fait possible et recommandé de rendre nos accesseurs privés, non pas pour empêcher strictement leur utilisation — on vient de voir qu’il est très facile de contourner cela — mais pour exprimer notre intention de ne pas voir ceux-ci utilisés en dehors de leur classe.

class User
  def initialize(firstname:, lastname:)
    @firstname = firstname
    @lastname = lastname
  end

  private

  attr_reader :firstname, :lastname
end

Et si l’arobase qui préfixe une variable d’instance permet d’un seul coup d’œil de différencier cette dernière d’une méthode, portant ainsi à notre compréhension que nous sommes en train de manipuler un attribut de notre objet, cette même arobase ne nous permet en aucun cas de distinguer un attribut assigné à l’initialisation d’une variable servant à la mémoïsation.

class User
  def initialize(firstname:, lastname:)
    @firstname = firstname
    @lastname = lastname
  end

  def fullname
    @fullname ||= "#{firstname} #{lastname}"
  end
end

Ici @fullname est déclaré pour de la mémoïsation et il serait bien mal avisé de l’utiliser explicitement plutôt que de passer par la méthode User#fullname.

Résumons-nous

Les accesseurs servent, comme le rappelle Sandy Metz dans “99 Bottles of OOP”, à encapsuler les données primitives de nos objets. Ce faisant, nous n’exposons pas les entrailles de nos objets, leurs structures de données internes, au lieu de cela nous présentons une interface harmonieuse, tout en nous préparant pour l’avenir qui ne manquera pas de nous bousculer !

Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Upper Saddle River, NJ, Second, 1997. ↩

Ligatures dans le terminal

2023-12-27T00:00:00+01:00

Le support des ligatures de la police Iosevka dans l’émulateur de terminal Kitty a nécessité la collaboration des auteurs de ces deux projets, et n’est pas nativement présent dans Debian Bullseye (11). Voyons ensemble comment concilier ces deux-là pour avoir de jolies ligatures dans notre terminal.

Iosevka

Cette police n’est pas incluse dans les dépôts Debian, mais doit être compilée ou récupérée depuis son dépôt Git. Iosevka offrant une grande liberté de personnalisation, c’est pourquoi nous opterons ici pour la compilation.

Compilation

Tout d’abord, clonons le dépôt Git.

git clone https://github.com/be5invis/Iosevka.git

Ensuite, copions le fichier de configuration d’exemple.

cd Iosevka
cp private-build-plans.sample.toml private-build-plans.toml

Nous pouvons à présent adapter private-build-plans.toml à nos besoins. Vous pouvez vous inspirer du mien, ou si vous préférez, il est aussi possible d’utiliser l’outil de personnalisation.

À présent, passons à la compilation.

npm install && npm run build -- --jCmd=9 ttf::IosevkaCustom

Notez l’option --jCmd=9 qui offre la possibilité de n’utiliser qu’un nombre donné de processus en parallèle, ici neuf, ce qui permet de ne pas monopoliser les 12 cœurs de mon processeur et ainsi de ne pas mettre l’ordinateur au tapis lors de la compilation !

Installation

Pour installer notre police fraichement compilée, il nous faut tout d’abord la déposer dans le dossier idoine ; dans notre cas, ce sera ~/.local/share/fonts.

cp -R ./dist/IosevkaCustom/TTF ~/.local/share/fonts/IosevkaCustom/

Ensuite, il nous faut régénérer le cache des polices.

fc-cache -fv

Nous pouvons constater que notre police est bien prise en charge par le système grace à la commande fc-list :

fc-list | grep IosevkaCustom

Et nos ligatures ?

Faisons un peu d’introspection, voyons comment sont prises en compte nos ligatures. Pour cela, nous aurons besoin d’un petit utilitaire, hb-shape, fourni par la bibliothèque harfbuzz.

sudo apt install libharfbuzz-bin

Et demandons-lui de nous décomposer la ligature >= :

hb-shape --show-extents --cluster-level=1 --shapers=ot --features "calt=0,dlig=1" ~/.local/share/fonts/IosevkaCustom/TTF/IosevkaCustom-Regular.ttf '>='
[.g13271.join-r=0+500<138,685,712,-524>|.g13277.join-l=1+500<-362,294,712,-299>]

Tout semble se passer pour le mieux ! On constate en effet que les caractères composant cette ligature utilisent les suffixes .join-r et .join-l définis par Renzhi Li aka. Belleve Invis, l’auteur de Iosevka, dans un échange avec Kovid Goyal, l’auteur de Kitty.

Il est temps à présent d’installer Kitty !

Kitty

Installation

Sous Debian Bullseye (11), l’installation se fait tout naturellement via le gestionnaire de paquet apt :

sudo apt install kitty

kitty --version
kitty 0.19.3 created by Kovid Goyal

Nous voilà avec un Kitty prêt à l’emploi ! Sauf que… le support des ligatures de la police Iosevka n’a été implémenté qu’au moyen du commit e01bb09 du 4 juin 2021 présent dans la version 0.21.0.

Montée de version

Fort heureusement, la dernière version stable de Debian, Bookworm (12), inclus la version 0.26.5 de Kitty !

Paquet kitty

    bullseye (oldstable) (x11): émulateur de terminal, rapide, multifonction, basé sur le GPU
    0.19.3-1: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x
    bookworm (stable) (x11): émulateur de terminal, rapide, multifonction, basé sur le GPU
    0.26.5-5: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x

Il nous suffit donc d’indiquer à notre système que nous souhaitons bénéficier de la version présente sur la liste stable, plutôt que celle proposée par défaut. C’est là qu’entre en jeu apt-pinning !

Épinglage

Avez-vous déjà été agacé par le fait que Debian Stable semble toujours ne pas être à jour ?

Voici comment faire en sorte qu’apt mélange différentes sources (oldstable, stable, testing ou unstable). Cela vous permettra de faire fonctionner un système essentiellement stable, tout en ayant la possibilité d’installer les dernières versions des paquets qui vous intéressent le plus. Cette technique se nomme épinglage, aussi appelée apt pinning.

sources.list

La première étape consiste à configurer votre /etc/apt/sources.list pour y inclure les sources stables, celles de Debian Bookworm (12).

# /etc/apt/sources.list
# Debian Bullseye
deb http://deb.debian.org/debian bullseye main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb http://deb.debian.org/debian bullseye-backports main contrib non-free

# Debian Stable
deb http://deb.debian.org/debian stable main contrib non-free

preferences

L’étape suivante consiste à créer/éditer votre fichier /etc/apt/preferences. Les préférences sont l’endroit où l’épinglage apt a lieu. Normalement, c’est la version la plus élevée d’un paquet disponible qui l’emporte, mais nous allons passer outre en indiquant que pour tout paquet, on souhaite prioriser oldstable, sauf pour Kitty, qu’on ira chercher dans stable. Pour ce faire, ce dernier aura sa propre règle avec une priorité d’épinglage plus haute que celle de la règle par défaut.

# /etc/apt/preferences
Package: *
Pin: release a=oldstable
Pin-Priority: 700

Package: kitty
Pin: release a=stable
Pin-Priority: 750

apt update

Nous sommes maintenant prêts à utiliser apt update. Cela ajoutera les nouveaux dépôts à la liste d’apt.

sudo apt update

Il n’y a plus qu’à installer notre nouvelle version de Kitty.

sudo apt -t stable install kitty

Notez qu’ici on précise -t stable pour installer les versions stables des dépendances de Kitty. Si nous n’avions pas fait cela, apt aurait râlé, car il n’aurait pas su résoudre ces dépendances.

kitty --version
kitty 0.26.5 created by Kovid Goyal

Kitty + Iosevka = ❤

Configuration de Kitty

Kitty nous permet de configurer finement le support des polices via l’instruction font_features. Cela nous permet d’activer ou de désactiver des fonctionnalités OpenType supportées par notre police. Ici, après avoir opté pour notre police Iosevka Custom, nous précisons à Kitty que nous souhaitons désactiver les alternatives contextuelles calt, activer les ligatures discrétionnaires dlig, et activer le texture healing TXTR tout récemment supporté par Iosevka à titre expérimental.

# ~/.config/kitty/kitty.conf

font_family      Iosevka Custom            
bold_font        Iosevka Custom Bold       
italic_font      Iosevka Custom Italic     
bold_italic_font Iosevka Custom Bold Italic

font_features Iosevka-Custom -calt +dlig +TXTR

Rendu final

Faisons un petit essai :

print -rlP -- '-<< --< -<- <-- <--- <<- <- -> ->> --> ---> ->- >- >>=' '=<< =< =<= <== <=== <<= <= => =>> ==> ===> =>= >= >>=' '<-> <--> <---> <----> <=> <==> <===> <====> :: ::: __' '<~~ %F{red}</ </> />%f ~~> == != %F{blue}/= ~=%f <> === !== !=== %F{blue}=/= =!=%f' '<: := *= *+ <* <*> *> <| <|> |> <. <.> .> +* =* =: :>' '(* *) %F{red}/* */%f [| |] {| |} ++ +++ %F{red}\/ /\%f \- -| <!-- <!---'

Et voici le résultat !

Rails et les value objects

2022-11-25T00:00:00+01:00

Les entrailles d’un framework cachent parfois des bouts de code fort intéressants ! C’est le cas de la méthode composed_of du module ActiveRecord::Aggregations qui par plusieurs aspects va nous intéresser aujourd’hui : elle nous permet d’introduire une notion importante d’architecture logiciel, les value objects ; et de revenir sur 10 ans de rebondissements autour de cette méthode ! Sortez les popcorns 🍿

Une vie mouvementée

Nous sommes en juin 2012, Rails arbore fièrement sa version 3.2 ! Et dans un post, faisant suite à une PR de Steve Klabnik, Rafael França nous explique pourquoi composed_of sera prochainement déprécié, puis retiré à compter de la version 4.0 du framework.

Les raisons sont une complexité superflue pour une méthode rarement utilisée qu’on pourrait qualifier de cosmétique (nous y reviendrons), et de multiples bugs relatifs à cette méthode dans le framework à l’époque.

Seulement, tout ne se passa pas comme prévu, et deux mois plus tard, en août 2012…

We have decided to stop introducing API deprecations in all point releases going forward. From now on, it’ll only happen in majors/minors.

— @Rails, Twitter, 1er août 2012

La décision fut alors prise de réintroduire cette méthode, toujours présente à ce jour dans la version 7.0 de Rails ! Cette méthode et la documentation qui lui est associée reçoivent d’ailleurs toujours des améliorations, comme le montre cette PR de Neil Carvalho datant de septembre 2022.

Mais alors, à quoi peut bien servir cette méthode méconnue qui a bien failli disparaitre ?

Déclarez vos objets de valeur

La méthode composed_of du module ActiveRecord::Aggregations permet de manipuler des value objects, c’est-à-dire des objets ayant pour seule vocation que de véhiculer une valeur. Un value object a la particularité d’être identifiable par la valeur qu’il véhicule et non pas par un identifiant. En d’autres termes, deux value objects sont égaux s’ils représentent la même valeur. Autre condition nécessaire, un value object se doit d’être immuable. La notion de value object est très présente dans la littérature portant sur le Domain Driven Design. Un excellent article de Victor Savkin fait d’ailleurs le lien entre Rails et DDD.

Un cas d’usage

Prenons un exemple qui parlera à tout le monde : la manipulation de valeurs monétaires. Il arrive assez fréquemment que l’on ait à manipuler des montants et des devises, que ce soit dans le cadre d’une application e-commerce, ou tout simplement l’établissement d’une facture. Dans ce cas, nous avons pris l’habitude de stocker en base, dans deux champs distincts mais étroitement liés, ce montant (appelons-le amount) et la devise associée (nommons-la currency).

Un value object nous permettra ici de manipuler ces deux informations au sein d’une même représentation. Nous pourrions imaginer la chose comme ceci, par exemple :

class Money
  attr_reader :amount, :currency

  def initialize(amount, currency = "EUR")
    @amount = amount
    @currency = currency
  end
end

Nous avons là un objet Money qui nous permet de manipuler des valeurs monétaires, et nous assure de toujours conserver ce lien entre montant et devise, l’un n’allant pas sans l’autre d’un point de vue fonctionnel. Seulement, il nous manque un petit quelque chose pour en faire un value object : nous avons besoin de définir l’égalité entre deux objets de cette classe !

class Money
  include Comparable

  # …

  def ==(other_money)
    amount == other_money.amount && currency == other_money.currency
  end
end

Grace au module Comparable que l’on vient d’inclure, et à la méthode ==, nous voici en mesure de comparer deux objets de la classe Money :

irb(main)> Money.new(5, "EUR") == Money.new(5, "EUR")
=> true
irb(main)> Money.new(5, "EUR") != Money.new(5, "USD")
=> true

Mais un value object ne se limite pas forcément à l’encapsulation d’une ou plusieurs valeurs, il peut aussi présenter un ensemble de méthodes qui lui sont propres ! Ici nous pourrions par exemple souhaiter convertir un montant dans une autre devise, ou encore comparer deux montants déclarés dans des devises différentes.

class Money
  EXCHANGE_RATES = { "EUR_TO_JPY" => 146 }

  # …

  def exchange_to(other_currency)
    exchanged_amount = (amount * EXCHANGE_RATES["#{currency}_TO_#{other_currency}"]).floor
    Money.new(exchanged_amount, other_currency)
  end

  def <=>(other_money)
    if currency == other_money.currency
      amount <=> other_money.amount
    else
      amount <=> other_money.exchange_to(currency).amount
    end
  end
end

Notons que notre objet est immuable, la méthode exchange_to retourne donc une nouvelle instance de notre classe Money.

irb(main)> Money.new(5, "EUR") == Money.new(5, "EUR")
=> true
irb(main)> Money.new(5, "EUR").exchange_to("JPY")
=> #<Money:0x00007faee7162f68 @amount=730, @currency="JPY">
irb(main)> Money.new(5, "EUR") == Money.new(730, "JPY")
=> true
irb(main)> Money.new(5, "EUR") > Money.new(500, "JPY")
=> true

Et composed_of dans tout ça ?

La méthode de classe composed_of appliquée sur un modèle ActiveRecord nous permet de lier les attributs de celui-ci pour les manipuler sous la forme d’un value object. Voici un exemple d’utilisation de notre classe Money :

# == Schema Information
#
# Table name: invoices
#
#  id                  :integer          not null, primary key
#  total_amount        :decimal(, )
#  total_currency      :string
class Invoice < ActiveRecord::Base
  composed_of :total,
    class_name: "Money",
    mapping: { total_amount: :amount, total_currency: :currency }
end

Ainsi, nous pouvons directement utiliser une instance de la classe Money à travers l’attribut total, et ce en lecture comme en écriture !

irb(main)> invoice = Invoice.new(total: Money.new(5, "EUR"))
=> #<Invoice id: nil, total_amount: 0.5e1, total_currency: "EUR">
irb(main)> invoice.total
=> #<Money:0x00007f1d1006b038 @amount=5, @currency="EUR">
irb(main)> invoice.total = Money.new(500, "JPY")
=> #<Money:0x000055eca216b658 @amount=500, @currency="JPY">
irb(main)> invoice.total_amounnt
=> 0.5e3
irb(main)> invoice.total_currency
=> "JPY"

Très utile cette méthode, et cela clarifie par la même occasion notre intention ! Notre code s’en trouve plus explicite, et plus facile à comprendre et à maintenir. De plus, nous limitons les responsabilités de notre modèle en cloisonnant dans des value objects les méthodes qui leur sont propres.

Mais alors, pourquoi vouloir la supprimer de Rails ?

Valeur ajoutée & maintenabilité

Tout est dans la mesure. Cette méthode n’est au final qu’un sucre syntaxique, une fonctionnalité cosmétique, et celle-ci a un coût, notamment en termes de maintenabilité pour l’équipe de développement du framework. Ce coût est loin d’être négligeable, à en croire les multiples remontées de bugs qui lui sont imputées, et il convient dans ce cas de peser le pour et le contre afin de choisir entre conserver cette fonctionnalité ou la supprimer.

L’un des arguments de poids à l’encontre de cette méthode, est le fait de devoir lui passer des procs et des hashes pour obtenir magiquement un comportement qui pourrait être décrit de manière bien plus explicite avec un simple objet Ruby. Arrêtons-nous un moment pour prendre deux exemples.

Dans le cas le plus simple, celui d’un attribut unique, nous pourrions nous contenter d’un serializer. Admettons que dans notre exemple précédent, nous ayons choisi de faire fi de la devise. Nous pourrions ainsi écrire ceci :

class MoneySerializer
  def dump(money)
    money.amount
  end

  def load(amount)
    Money.new(amount)
  end
end

class Invoice < ActiveRecord::Base
  serialize :total_amount, MoneySerializer.new
end

Autre approche, nous pourrions aussi faire appel à de simples accesseurs, comme ceci par exemple :

class Invoice < ActiveRecord::Base
  def total
    @total ||= Money.new(total_amount, total_currency)
  end

  def total=(money)
    self[:total_amount] = money.amount
    self[:total_currency] = money.currency

    @total = money
  end
end

Ces deux exemples nous montrent à quel point il est facile d’obtenir le même résultat, sans la magie de composed_of, mais surtout avec beaucoup plus de clarté, j’en veux pour preuve cet exemple tiré de la documentation d’ActiveRecord :

class NetworkResource < ActiveRecord::Base
  composed_of :cidr,
              class_name: 'NetAddr::CIDR',
              mapping: [ %w(network_address network), %w(cidr_range bits) ],
              allow_nil: true,
              constructor: Proc.new { |network_address, cidr_range| NetAddr::CIDR.create("#{network_address}/#{cidr_range}") },
              converter: Proc.new { |value| NetAddr::CIDR.create(value.is_a?(Array) ? value.join('/') : value) }
end

On comprend rapidement ici que maintenir ce code et le tester sera des plus pénibles !

Ceci étant, dans sa configuration la plus simple, ce petit sucre syntaxique reste attirant à l’œil et, sans convaincre celles et ceux fortement attachés aux principes du Domain Driven Design, devrait séduire les plus Rails-istes d’entre nous — Il suffit de ne pas être trop regardant de ce qu’il y a sous le capot ;)

Petit bonus

Puisque nous parlons d’ActiveRecord, qu’en est-il du requêtage de ces attributs ? Eh bien tout semble se passer le plus intuitivement du monde :

Invoice.where(total: Money.new(42, "EUR"))

Si vous avez choisi de vous passer de composed_of, il s’agira simplement d’être explicite là aussi, à l’aide d’une méthode de classe par exemple :

def self.costing(money)
  where(total_amount: money.amount, total_currency: money.currency)
end

Le coût d’un code explicite ne semble pas excessif. Surtout au regard des 768 lignes de code nécessaires à cette fonctionnalité cosmétique.

Du discernement

Cet exemple nous montre une nouvelle fois à quel point Rails n’est pas simple ! Il nous faut donc rester sur nos gardes, et prendre la mesure des choix techniques que nous faisons. Aussi insignifiants qu’ils puissent nous paraitre à première vue, leurs répercussions peuvent être considérable avec le temps, en particulier sur la maintenabilité, la pérennité et la testabilité de nos applications.

Recherche plein texte avec PostgreSQL

2022-09-29T00:00:00+02:00

J’ai récemment eu l’opportunité de travailler pour un client qui souhaitait mettre en place une recherche plus pertinente sur son logiciel. L’occasion rêvée de regarder du côté de la recherche plein texte (full-text) proposée nativement par PostgreSQL !

Révélez votre meilleur profil

La recherche était effectuée sur des profils : un intitulé, une description, rien de bien exotique.

Historiquement la recherche de profil se faisait très sommairement sur la base de mots-clés et remontait des résultats peu pertinents. On recherchait, via Ransack, le terme exact faisant tout ou partie d’un mot, dans l’intitulé et la description des profils.

Par ailleurs, les mots-clés n’étaient utilisés que pour filtrer les résultats, le tri, lui, était effectué selon le critère de tri choisi (par défaut : la date de publication, les plus récents en premier).

Exemple : une recherche avec le mot clé « app » fera ressortir les profils dans lesquels figure le mot app, mais aussi application, appétit ou encore rapport.

Recherche plein texte

On comprend dès lors que cela manque de précision et que la pertinence n’est pas au rendez-vous. C’est là que PostgreSQL entre en jeu, et notamment ce que l’on nomme la recherche plein texte. Voici ce que nous en dit la documentation :

La recherche plein texte (ou plus simplement la recherche de texte) permet de sélectionner des documents en langage naturel qui satisfont une requête et, en option, de les trier par intérêt suivant cette requête. Le type le plus fréquent de recherche concerne la récupération de tous les documents contenant les termes de recherche indiqués et de les renvoyer dans un ordre dépendant de leur similarité par rapport à la requête.

— Chapitre 12. Recherche plein texte

Il va donc nous être possible de formuler une requête SQL, un peu velue certes, qui nous permettra d’exprimer ce qui pour nous est digne d’intérêt.

Un peu de vocabulaire

À ce niveau, il est important de s’arrêter quelques instants sur le vocabulaire pour comprendre de quoi nous parlons exactement.

Un document est l’unité de recherche, c’est-à-dire ce sur quoi nous souhaitons effectuer notre recherche. Cela peut être un simple champ d’une table de la base de données, ou la concaténation de plusieurs champs, éventuellement issus de plusieurs tables. Dans notre exemple, ce qui nous intéresse c’est l’intitulé et la description des profils.

SELECT (coalesce("profiles"."label"::text, '') || coalesce("profiles"."description"::text, '')) AS document
FROM "profiles"

On utilise ici coalesce() pour éviter de manipuler NULL lors de la concaténation, ce qui conduirait à un résultat nul pour l’ensemble du document.

Une requête (tsquery) se fait sur un document (tsvector) à l’aide de l’opérateur @@.

SELECT to_tsvector('Portez ce vieux whisky au juge blond qui fume') @@ to_tsquery('vieux & juge')
+----------+
| ?column? |
|----------|
| True     |
+----------+

Remarquez que l’on utilise ici to_tsvector() et to_tsquery(). En effet, nous ne manipulons pas de simples textes. Un tsquery contient des termes de recherche qui doivent déjà être des lexèmes normalisés, et peut combiner plusieurs termes en utilisant les opérateurs AND, OR, NOT et FOLLOWED BY.

SELECT to_tsquery('vieux & whisky')
+--------------------+
| to_tsquery         |
|--------------------|
| 'vieux' & 'whiski' |
+--------------------+

Notez le mot whisky remplacé par le lexème whiski.

Pour pouvoir faire usage de ce tsquery, notre document lui sera présenté sous la forme d’un tsvector, c’est-à-dire une version pré-traitée et compacte de celui-ci.

SELECT to_tsvector('Portez ce vieux whisky au juge blond qui fume')
+-----------------------------------------------------------------------------------+
| to_tsvector                                                                       |
|-----------------------------------------------------------------------------------|
| 'au':5 'blond':7 'ce':2 'fume':9 'juge':6 'portez':1 'qui':8 'vieux':3 'whiski':4 |
+-----------------------------------------------------------------------------------+

Notre document est ici découpé en lexèmes présentés dans l’ordre alphabétique et suivis des indices auxquels on les retrouve dans le document. Pourtant, ces lexèmes n’ont pas l’air si normalisés que ça… c’est parce que la recherche plein texte se base sur une configuration qui par défaut considère qu’il s’agit d’un document en anglais. Sans entrer trop vite dans le détail de la configuration, sachez qu’on peut préciser un argument supplémentaire à nos fonctions to_tsquery() et to_tsvector(), voyez :

-- to_tsvector([ config regconfig, ] document text) returns tsvector

SELECT to_tsvector('french', 'Portez ce vieux whisky au juge blond qui fume')
+---------------------------------------------------------+
| to_tsvector                                             |
|---------------------------------------------------------|
| 'blond':7 'fum':9 'jug':6 'port':1 'vieux':3 'whisky':4 |
+---------------------------------------------------------+

On comprend à présent que l’opérateur @@ cherchera dans ce tsvector la présence (ou l’absence) de certains lexèmes décrits par notre tsquery. L’intérêt de passer par des lexèmes normalisés est de pouvoir découvrir les différentes formes d’un même mot sans avoir à toutes les préciser.

Les plus attentifs d’entre vous auront remarqué la disparition des termes « ce », « au » et « qui ». Il s’agit là d’un des effets de la configuration choisie qui ignore tout simplement certains mots jugés trop génériques et non pertinents.

Une recherche aux petits oignons

Mais alors, comment fonctionne cette configuration ?

En interne, la fonction to_tsvector appelle un analyseur qui casse le texte en jetons et affecte un type à chaque jeton. Pour chaque jeton, une liste de dictionnaires est consultée, liste pouvant varier suivant le type de jeton. Le premier dictionnaire qui reconnaît le jeton émet un ou plusieurs lexèmes pour représenter le jeton. Le choix de l’analyseur, des dictionnaires et des types de jetons à indexer est déterminé par la configuration de recherche plein texte sélectionnée. Il est possible d’avoir plusieurs configurations pour la même base, et des configurations prédéfinies sont disponibles pour différentes langues.

— 12.3. Contrôler la recherche plein texte

Ainsi, il nous est possible de choisir une configuration préexistante, comme french dans l’exemple précédent, mais aussi d’élaborer une configuration spécialement adaptée à nos besoins. Et cela tombe bien, car nous en aurons justement besoin ! Prenons un exemple.

Cas particulier : C++, C#, .net

La recherche par dictionnaire, lorsque celle-ci est effectuée à l’aide de l’une des configurations mises à notre disposition, ignore un certain nombre de symboles (espaces, ponctuation) et les mots jugés non pertinents (stopwords ; particules, mots de liaison). Or, certains langages de programmation, qui peuvent très bien faire l’objet d’une recherche, contiennent l’un ou l’autre, voire les deux !

Pour palier cela, il nous faut constituer un thésaurus personnalisé, le porter à la connaissance de PostgreSQL, le lier à un dictionnaire lui aussi personnalisé, car il ne devra pas discriminer les stopwords, et enfin altérer la configuration du français pour les caractères ASCII et les symboles.

Reprenons. Les dictionnaires sont utilisés pour éliminer les mots qui ne devraient pas être considérés dans une recherche et pour normaliser des mots qui peuvent prendre des formes diverses. Il existe différents types de dictionnaires :

Termes courants (stopwords)
Dictionnaire simple
Dictionnaire des synonymes
Dictionnaire thésaurus
Dictionnaire Ispell
Dictionnaire Snowball

Une configuration définira ainsi la correspondance entre un type de jeton et un ou plusieurs dictionnaires. En ce qui nous concerne, nous avons besoin d’un thésaurus pour pouvoir associer un lexème à un ensemble de jetons.

Notre thésaurus devra se trouver dans /usr/local/share/postgresql/tsearch_data/ et nous le nommerons prog_thesaurus.ths. Sa syntaxe est plutôt transparente, voyez vous-même :

a + : aplus
a # : asharp
c - - : cminusminus
c + + : cplusplus
c/c + + : cplusplus
c # : csharp
. net : dotnet
f # : fsharp
f * : fstar
j + + : jplusplus
j # : jsharp
m # : msharp
q # : qsharp
r + + : rplusplus
xbase + + : xbaseplusplus
x + + : xplusplus
x # : xsharp
z + + : zplusplus

Il nous faut maintenant instruire PostgreSQL de l’existence de ce thésaurus. Mais nous allons faire face à un petit souci : certains des jetons utilisés dans notre thésaurus sont des stopwords ! Pour que notre thésaurus puisse les prendre en considération, il faut que ceux-ci ne soient pas ignorés par le dictionnaire de base. Ce dictionnaire (Snowball) est basé sur un algorithme de stemming qui sait comment réduire les variantes standard d’un mot vers une base, ou stem, en rapport avec la langue.

Observons tout d’abord le comportement actuel.

SELECT * FROM ts_debug('french', 'c++');
+-----------+-----------------+-------+---------------+-------------+---------+
| alias     | description     | token | dictionaries  | dictionary  | lexemes |
|-----------+-----------------+-------+---------------+-------------+---------|
| asciiword | Word, all ASCII | c     | {french_stem} | french_stem | []      |
| blank     | Space symbols   | +     | {}            | <null>      | <null>  |
| blank     | Space symbols   | +     | {}            | <null>      | <null>  |
+-----------+-----------------+-------+---------------+-------------+---------+

SELECT * FROM plainto_tsquery('french','c++')
NOTICE:  text-search query contains only stop words or does not contain lexemes, ignored

+-----------------+
| plainto_tsquery |
|-----------------|
|                 |
+-----------------+

Effectivement, nous nous trouvons là dans une situation cocasse où l’ensemble des jetons de notre requête sont ignorés : le premier étant un stopword, les suivants des symboles.

Créons donc un nouveau dictionnaire Snowball sans stopwords :

CREATE TEXT SEARCH DICTIONARY public.french_strigo_stem (
    TEMPLATE = pg_catalog.snowball,
    LANGUAGE = 'french'
);

Déclarons à présent notre thésaurus qui s’appuiera sur notre nouveau dictionnaire french_strigo_stem :

CREATE TEXT SEARCH DICTIONARY public.prog_thesaurus (
    TEMPLATE = pg_catalog.thesaurus,
    DICTFILE = 'prog_thesaurus',
    DICTIONARY = 'public.french_strigo_stem'
);

Pour éviter toute mauvaise surprise, clonons la configuration french ; c’est cette réplique que nous altèrerons par la suite :

CREATE TEXT SEARCH CONFIGURATION public.french_strigo (
  COPY = french
);

Voyons quels dictionnaires sont définis par notre configuration :

\dF+ french_strigo

Text search configuration "pg_catalog.french_strigo"
Parser: "pg_catalog.default"
+-----------------+--------------+
| Token           | Dictionaries |
|-----------------+--------------|
| asciihword      | french_stem  |
| asciiword       | french_stem  |
| email           | simple       |
| file            | simple       |
| float           | simple       |
| host            | simple       |
| hword           | french_stem  |
| hword_asciipart | french_stem  |
| hword_numpart   | simple       |
| hword_part      | french_stem  |
| int             | simple       |
| numhword        | simple       |
| numword         | simple       |
| sfloat          | simple       |
| uint            | simple       |
| url             | simple       |
| url_path        | simple       |
| version         | simple       |
| word            | french_stem  |
+-----------------+--------------+

Modifions à présent notre configuration pour y lier les types de jetons de notre choix à notre thésaurus. L’ordre de déclaration des dictionnaires a ici une importance, on prendra garde à positionner notre thésaurus en tête de liste :

ALTER TEXT SEARCH CONFIGURATION public.french_strigo
  ALTER MAPPING FOR asciiword, asciihword, hword_asciipart, word
  WITH prog_thesaurus, french_strigo_stem;

ALTER TEXT SEARCH CONFIGURATION public.french_strigo
  DROP MAPPING IF EXISTS FOR blank;

ALTER TEXT SEARCH CONFIGURATION public.french_strigo
  ALTER MAPPING FOR file, host
  WITH prog_thesaurus, simple;

Pourquoi altérer file, me direz-vous ? Parce que c/c dans « c/c++ » est considéré comme un jeton de type file.

Si l’on observe notre configuration, elle ressemble à présent à ceci :

\dF+ french_strigo

Text search configuration "public.french_strigo"
Parser: "pg_catalog.default"
+-----------------+------------------------------------+
| Token           | Dictionaries                       |
|-----------------+------------------------------------|
| asciihword      | prog_thesaurus,french_strigo_stem  |
| asciiword       | prog_thesaurus,french_strigo_stem  |
| email           | simple                             |
| file            | prog_thesaurus,simple              |
| float           | simple                             |
| host            | prog_thesaurus,simple              |
| hword           | french_stem                        |
| hword_asciipart | prog_thesaurus,french_strigo_stem  |
| hword_numpart   | simple                             |
| hword_part      | french_stem                        |
| int             | simple                             |
| numhword        | simple                             |
| numword         | simple                             |
| sfloat          | simple                             |
| uint            | simple                             |
| url             | simple                             |
| url_path        | simple                             |
| version         | simple                             |
| word            | prog_thesaurus,french_strigo_stem  |
+-----------------+------------------------------------+

Parfait ! Si l’on teste à présent notre nouvelle configuration :

SELECT * FROM ts_debug('french_strigo', 'c++');
+-------+-------------------+-------+-------------------------------------+----------------+---------------+
| alias | description       | token | dictionaries                        | dictionary     | lexemes       |
|-------+-------------------+-------+-------------------------------------+----------------+---------------|
| word  | Word, all letters | c++   | {prog_thesaurus,french_strigo_stem} | prog_thesaurus | ['cplusplus'] |
+-------+-------------------+-------+-------------------------------------+----------------+---------------+

SELECT * FROM plainto_tsquery('french_strigo','c++')
+-----------------+
| plainto_tsquery |
|-----------------|
| 'cplusplus'     |
+-----------------+

Excellent ! Nous observons à présent que notre thésaurus a reconnu « c++ » comme étant un jeton et lui a substitué le lexème « cplusplus ».

Stop ou encore ?

Je tiens à attirer votre attention sur le fait qu’ignorer purement et simplement les stopwords n’est peut-être pas souhaitable en conditions réelles. En effet, les stopwords ont leur intérêt dans la mesure de pertinence des résultats retournés. Mais rien ne nous empêche de déclarer notre propre dictionnaire de stopwords en y excluant ceux qui entrent en conflit avec notre thésaurus !

Pour cela on peut s’inspirer du dictionnaire french.stop.

cd /usr/local/share/postgresql/tsearch_data/
cp french.stop french_strigo.stop
# modifier french_strigo.stop

Il nous suffit alors de préciser le dictionnaire stopwords à utiliser :

CREATE TEXT SEARCH DICTIONARY public.french_strigo_stem (
  TEMPLATE = pg_catalog.snowball,
  LANGUAGE = 'french',
  STOPWORDS = 'french_strigo'
);

Si vous êtes amené à mettre à jour l’un de vos dictionnaires, pensez bien à recharger votre configuration ! Pour cela, voici une petite astuce :

ALTER TEXT SEARCH DICTIONARY public.prog_thesaurus ( dummy );
ALTER TEXT SEARCH DICTIONARY public.french_strigo_stem ( dummy );

Et maintenant ?

Nous venons de voir les bases de la recherche plein texte et de sa configuration. Cela fait déjà de nombreuses notions à assimiler, et encore, nous n’avons fait que les survoler ! Pour approfondir cela, je vous invite à consulter la documentation officielle ou sa version française, riches d’exemples et de détails.

Dans un prochain article, nous aborderons un autre aspect important de la recherche plein texte : la pondération. S’ensuivra un dernier article pour clore cette série, il mettra l’accent sur l’indexation et pg_search, une gem Ruby nous permettant de créer des scopes ActiveRecord qui tirent parti de la recherche plein texte de PostgreSQL.

Orthogonalité

2022-04-08T00:00:00+02:00

L’orthogonalité est un concept essentiel si l’on veut produire des systèmes faciles à concevoir, à construire, à tester et à étendre. Cependant, le concept d’orthogonalité est rarement enseigné directement. Il s’agit souvent d’une caractéristique implicite de diverses autres méthodes et techniques que vous apprenez. C’est une erreur. Une fois que vous aurez appris à appliquer directement le principe d’orthogonalité, vous constaterez une amélioration immédiate de la qualité des systèmes que vous produisez.

— Dave Thomas, Andy Hunt. « The Pragmatic Programmer »

Ainsi commence le chapitre 10 du livre « The Pragmatic Programmer » de Dave Thomas & Andy Hunt. Excellent livre dont nous avons déjà parlé dans les articles Duplication ou coïncidence ? et L’art de l’aiguisage. Aujourd’hui nous allons donc parler d’orthogonalité, de ce qui se cache derrière cette notion, et des bénéfices que peuvent nous apporter sa compréhension et sa mise en pratique !

Qu’est-ce que l’orthogonalité ?

Il s’agit d’une analogie avec les vecteurs orthogonaux en algèbre linéaire : aucun des vecteurs d’un ensemble orthogonal ne dépend des autres et tous sont nécessaires pour décrire l’espace vectoriel dans son ensemble.

L’orthogonalité signifie que les caractéristiques peuvent être utilisées dans n’importe quelle combinaison, que les combinaisons ont toutes un sens et que la signification d’une caractéristique donnée est cohérente, indépendamment des autres caractéristiques avec lesquelles elle est combinée.

— Michael Scott. « Programming Language Pragmatics »

Ainsi, lorsqu’on parle d’orthogonalité en ingénierie logicielle, on fait référence aux notions de découplage, mais aussi de composabilité, de prédictibilité et de cohérence.

Limiter les effets de bord

Penser en termes d’orthogonalité nous amène à concevoir des composants respectant les principes SOLID promus par Robert C. Martin. On va leur octroyer une responsabilité unique, favoriser l’injection de dépendance, ou encore les rendre déterministes, limitant ainsi les effets de bord.

Ce faisant, il est bien plus simple de tester nos composants puisque leur périmètre est restreint au strict nécessaire ; leur comportement prédictible, car ils sont insensibles aux perturbations exogènes ; et leurs dépendances quasi inexistantes, il sera donc plus aisé de mettre sur pied un jeu de tests de façon à reproduire les différents scénarios pouvant se présenter.

Non seulement nos tests sont plus simples à écrire, mais nos composants, découplés les uns des autres, sont aussi plus facilement modifiables, adaptables, voire remplaçables !

Effets algébriques

Une approche pratique pour contenir les effets de bord nous vient de la programmation fonctionnelle et se nomme effet algébrique.

Les effets algébriques sont une approche des effets computationnels basée sur le principe que le comportement impur d’une fonction découle d’un ensemble d’opérations telles que get & set pour le stockage mutable, read & print pour les entrées/sorties interactives, ou raise pour les exceptions. Cela donne naturellement lieu à des handlers non seulement pour les exceptions, mais aussi pour tout autre effet qui, entre autres, peut capturer la redirection de flux, la rétrospection, le multithreading coopératif et les continuations délimitées.

— Matija Pretnar. « An Introduction to Algebraic Effects and Handlers »

Une implémentation de cette approche existe en Ruby via la gem dry-effects qui, pour ne rien gâcher, est livrée avec une documentation fournie et éclairante sur son potentiel.

Gagner en productivité

Bien qu’assez exigeant et demandant un peu d’exercice, penser en termes d’orthogonalité peut assez vite s’avérer payant. En effet, l’empreinte de nos composants étant réduite, y apporter des modifications en sera d’autant plus aisé. Car il va de soi que sans couplage ni effet de bord, nous serons plus facilement enclins à réaliser des changements que nous saurons localisés. Sérénité et productivité vont de pair !

Par ailleurs, il nous sera aussi très facile de chaîner nos composants pour répondre à des besoins plus complexes. En permettant la composabilité, l’orthogonalité favorise ainsi la réutilisabilité de nos composants. Sans cela, nous ferions face à des composants dont les responsabilités se chevauchent, voire à des incompatibilités structurelles.

Composabilité

En Ruby, la gem dry-transformer, dont nous avons déjà parlé ici-même pour présenter une manière élégante de manipuler des structures de données, est un exemple de méthodes simples et composables pour couvrir un grand nombre de scénarios.

Réduire les risques

Restreindre le périmètre, les responsabilités et les dépendances nous permet aussi d’éviter l’effet domino ! Un composant risque moins de propager un comportement inattendu s’il est isolé des autres et n’a pas d’effet de bord.

De la même manière, dans un système orthogonal il devient assez aisé de substituer une dépendance à une autre. Changer d’ORM, de SGBD, voire de framework devrait être du domaine du possible — moyennant un certain effort, voire un effort certain, mais néanmoins possible — et idéalement n’avoir aucun impact sur notre code métier.

Une architecture résiliente

Sans forcément l’avoir pensé en ces termes précis, nous sommes déjà habitués à concevoir des systèmes orthogonaux. Le découpage en 7 couches du modèle OSI en est un exemple, l’architecture hexagonale en est un autre, ou encore les microservices pour en prendre un troisième. Toutes ces architectures ont en commun, sans jamais vraiment l’exprimer en ces termes, une recherche d’orthogonalité.

Ainsi, une architecture orthogonale sera résiliente, dans le sens où sa capacité à absorber un changement sera élevée et que cela ne génèrera pas de soubresauts à travers toute l’application.

Du choix de ses outils

L’art de l’aiguisage nous l’a appris, le choix de ses outils est primordial pour qui recherche précision et efficacité. Ainsi, choisir des bibliothèques ou autres greffons qui respectent le principe d’orthogonalité nous sera d’une grande aide pour la maintenabilité et la testabilité de nos applications. Les programmes GNU/Linux en sont un bon exemple, comme le fait remarquer Eric Steven Raymond dans l’extrait suivant de « The Art of Unix Programming ».

L’orthogonalité signifie également que plusieurs programmes n’ont pas les mêmes fonctions. Par exemple, sous GNU/Linux, la sélection raffinée de fichiers n’est effectuée que par le programme find. D’autre part, find ne peut que sélectionner des fichiers et n’a pas de fonctions supplémentaires ; il peut cependant être combiné avec toutes les autres commandes. Le programme tar peut combiner plusieurs fichiers en une archive ; pour la compression, il est combiné avec gzip. gzip ne peut compresser qu’un seul fichier et ne peut ni sélectionner ni combiner des fichiers.

— Eric Steven Raymond. « The Art of Unix Programming »

Un code découplé

Alors comment concevoir de tels programmes ? Au quotidien, il est difficile de conserver l’orthogonalité de son code sans y apporter une attention particulière. Nos frameworks ne nous y encourage pas toujours non plus, ce qui n’arrange rien. Cependant, et sans dénaturer l’esprit et la philosophie du framework que l’on utilise, nous pouvons tâcher de préserver un découplage quand l’occasion nous en est donnée. Il est par exemple préférable de laisser un objet gérer lui-même son état interne. Limiter l’exposition de nos objets sur l’extérieur est là aussi une pratique qui va dans le sens recherché.

Prenons un exemple inspiré du livre de Dave Thomas & Andy Hunt. Selon vous, laquelle de ces deux classes respecte le mieux le principe d’orthogonalité ?

class Split1
  def initialize(fileName) # accède au fichier en lecture
  def readNextLine()       # lit la prochaine ligne
  def getWord(n)           # retourne le n-ième mot de la ligne courante
end

class Split2
  def initialize(line)     # découpe la ligne en mots
  def getWord(n)           # retourne le n-ième mot de la ligne courante
end

La seconde, en effet, puisqu’elle se concentre sur une seule tâche (découper une ligne en mots) sans s’inquiéter d’où provient cette ligne. Ainsi, non seulement on réduit le couplage, mais on améliore aussi sa composabilité, tout simplifiant l’écriture de tests.

Un code contextualisé

Inscrire son code dans un contexte est également un excellent moyen d’éviter les couplages non désirés, le cumul des responsabilités, et les effets de bord. En contextualisant son code, on s’évite l’usage de variables globales, partagées et modifiables par tous. Ce faisant, on s’offre aussi la possibilité de respecter le principe DRY ; lorsque nos méthodes et fonctions sont contextualisées, il est plus facile de discerner la duplication de la coïncidence.

DRY concerne la duplication de la connaissance, de l’intention. Il s’agit d’exprimer la même chose à deux endroits différents, peut-être de deux manières totalement différentes.

— Dave Thomas, Andy Hunt. « The Pragmatic Programmer »

Un code facile à tester

Avez-vous déjà eu à tester une méthode qui manipule toute une arborescence d’objets complexes, fait des appels en base de données et interroge une API externe, tout en étant sensible à une ou plusieurs variables d’environnement ? C’est une torture ! Et c’est là tout ce qu’on souhaite s’éviter en visant l’orthogonalité ! Réduire le nombre de dépendances et les inverser quand elles sont nécessaires permet une meilleure maitrise des cas de figures pouvant se présenter. Limiter l’exposition de nos objets réduit drastiquement le nombre de situations à tester. Favoriser la composabilité et le déterminisme de nos composants permet de faire face à un grand nombre de situations sans pour autant multiplier les tests.

Pour aller plus loin

Nous venons de le voir, cette notion d’orthogonalité se cache partout ! Et une fois identifiée, elle se révèlera être votre meilleure alliée pour concevoir des applications pérennes et résilientes.

Si vous souhaitez creuser davantage le sujet, je vous invite à la lecture de « The Pragmatic Programmer » de Dave Thomas & Andy Hunt ; ainsi que « The Art of Unix Programming » d’Eric Steven Raymond, dont le chapitre 4 aborde ce sujet, et plus largement la notion de modularité, du point de vue du développement applicatif sous Unix.

Regex, ZSH & Darwin

2021-11-18T00:00:00+01:00

Comme promis dans l’article portant sur les classes de caractères des regex, me revoilà avec, cette fois, un exemple concret que je vais exécuter froidement devant vous !

En passant d’un macOS à une Debian GNU/Linux, je me suis aperçu d’un comportement inattendu sur un script ZSH de ma confection en ce qui concerne les regex, et plus particulièrement les classes de caractères.

Le contexte

L’idée était de détecter la présence d’un mot dans une chaîne de caractères. Prenons la chaîne suivante en exemple :

bat exa fd fzf git htop ncdu neovim ripgrep tig tldr tmux tree watch z zplug

Mettons maintenant que nous recherchions la présence du mot « tldr » dans cette liste. D’après ce que nous savons des classes de caractères, nous pouvons par exemple écrire la regex suivante :

/[[:\<:]]tldr[[:\>:]]/

Les classes de caractères [[:\<:]] et [[:\>:]] représentent respectivement le début et la fin d’un mot. Cela nous permet de nous assurer de ne pas tomber sur une suite de caractères au milieu d’un mot. On peut ainsi rechercher « z » sans tomber sur « fzf » ou « zplug », pour reprendre notre exemple.

Lost in the Shell

Voyons à présent ce que cela donne quand on utilise notre petite regex dans le contexte de ZSH.

❯ uname
Darwin
❯ [[ "bat tldr zplug" =~ [[:\<:]]man[[:\>:]] ]] && echo "true" || echo "false"
false
❯ [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]] && echo "true" || echo "false"
true

Tout semble se passer pour le mieux ! Essayons sous GNU/Linux :

❯ uname
Linux
❯ [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]] && echo "true" || echo "false"
zsh: failed to compile regex: Nom de classe de caractères invalide
false

Outch ! Mais que se passe-t-il ?

Let’s Read The Famous Manual!

Un petit tour dans la documentation de ZSH devrait nous aiguiller… voyons voir.

REMATCH_PCRE
       If set, regular expression matching with the =~ operator will use
       Perl-Compatible Regular Expressions from the PCRE library. (The zsh/pcre
       module must be available.) If not set, regular expressions will use the
       extended regexp syntax provided by the system libraries.

Il semblerait qu’une option nous permettrait d’imposer une bibliothèque compatible Perl (PCRE). Si cette option n’est pas définie, nous sommes dépendants de la bibliothèque système. Allons-y !

❯ uname
Darwin
❯ setopt rematch_pcre
❯ [[ "bat tldr zplug" =~ [[:\<:]]man[[:\>:]] ]] && echo "true" || echo "false"
false
❯ [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]] && echo "true" || echo "false"
true

❯ unsetopt rematch_pcre
❯ [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]] && echo "true" || echo "false"
true

❯ uname
Linux
❯ setopt rematch_pcre
❯ [[ "bat tldr zplug" =~ [[:\<:]]man[[:\>:]] ]] && echo "true" || echo "false"
false
❯ [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]] && echo "true" || echo "false"
true

❯ unsetopt rematch_pcre
❯ [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]] && echo "true" || echo "false"
zsh: failed to compile regex: Nom de classe de caractères invalide
false

Parfait, ça semble faire le boulot ! Cela dit, si nous nous rappelons bien du tableau présenté dans l’article précédent, il existe d’autres manières de délimiter un mot :

❯ uname
Linux
❯ unsetopt rematch_pcre
❯ [[ "bat tldr zplug" =~ "\<tldr\>" ]] && echo "true" || echo "false"
true
❯ [[ "bat tldr zplug" =~ "\btldr\b" ]] && echo "true" || echo "false"
true

Mais là, manque de chance, c’est macOS qui flanche :

❯ uname
Darwin
❯ unsetopt rematch_pcre
❯ [[ "bat tldr zplug" =~ "\btldr\b" ]] && echo "true" || echo "false"
false
❯ [[ "bat tldr zplug" =~ "\<tldr\>" ]] && echo "true" || echo "false"
false

La solution

À la vue de ces comportements bigarrés, la meilleure option qui s’offre à nous est de nous assurer qu’un moteur PCRE sera utilisé, ou d’utiliser une regex de repli dans le cas contraire. Ce qui pourrait donner ceci :

if [[ -o rematchpcre || "$OSTYPE" == darwin* ]]; then
  [[ "bat tldr zplug" =~ [[:\<:]]tldr[[:\>:]] ]]
else
  [[ "bat tldr zplug" =~ "\<tldr\>" ]]
fi

On considère ici que si l’option ZSH rematchpcre est activée ou si le système d’exploitation est macOS (darwin de son petit nom), alors on pourra utiliser notre regex compatible Perl.

En espérant que ce petit retour d’expérience vous aura appris une ou deux choses et donné l’envie de lire le fameux manuel quand une question vous taraude !

Des regex qui ont la classe !

2021-11-12T00:00:00+01:00

Parlons regex ! Expressions rationnelles. Alors oui, les plus assidus me feront remarquer qu’on a déjà abordé ce thème à plusieurs reprises ; on a abordé le sujet des quantificateurs, des groupes de capture et on a même joué avec les emojis ! Mais il reste encore des aspects de ce fabuleux outil que sont les regex à aborder, et aujourd’hui je vous propose de nous pencher sur les classes de caractères.

Classes de caractères

Une classe de caractère, c’est tout simplement un ensemble de caractères manipulé comme un tout ; généralement parce qu’ils partagent un trait commun. Au sein d’une expression rationnelle, on note une classe de caractère entre crochets, comme ceci :

[0123456789] une simple liste de caractères ;
[0-9] un intervalle ;
[A-Za-z0-9_] un mix de tout ça ;
\w ou [[:word:]] une classe prédéfinie ;
[^0-9] une négation (caractérisée par la présence d’un circonflexe en tête de liste).

Moteur !

Il existe différentes implémentations de moteurs de regex, dits moteurs NFA piloté par le motif ou DFA piloté par l’entrée. Suivant le langage et l’environnement dans lequel vous évoluez, de petites différences pourront être constatées. En l’occurrence, tous les moteurs ne supportent pas les mêmes classes de caractères prédéfinies.

Le moteur le plus complet à ce jour étant celui de Perl. Celui-ci permet, par exemple, de rechercher le mot le plus long d’une chaîne de caractères à l’aide de boundaries, possessive quantifiers, positive lookahead, negative lookahead, positive lookbehind… on a sorti tout l’attirail !

/\b(\w++)(?=(.*))(?!(.*\W)\b((?<=(?=(?=\1\2$)(?:(?=\w*+\3(\5?+\w))\w)++\b|(?4)).)))/

Aïe, ça pique !

Un manque de standardisation

Les classes prédéfinies sont fort utiles, seulement elles sont peu portables du fait du manque de standardisation entre les différents moteurs de regex. Voici un petit aperçu.

Vim	JS	Ruby, Elixir, PHP	ASCII	Description
		`[[:ascii:]]`	`[\x00-\x7F]`	Caractères ASCII
		`[[:alnum:]]`	`A-Za-z0-9`	Caractères alphanumériques
`\w`	`\w`	`\w` ou `[[:word:]]`	`A-Za-z0-9_`	Caractères alphanumériques, et « _ »
`\W`	`\W`	`\W` ou `[^[:word:]]`	`^A-Za-z0-9_`	Caractères ne composant pas les mots
`\a`		`[[:alpha:]]`	`A-Za-z`	Caractères alphabétiques
`\s`		`[[:blank:]]`	`\t`	Espace et tabulation
`\\<` `\\>`	`\b`	`\b` ou `[[:<:]]` `[[:>:]]`	`(?<=\W)(?=\w)│(?<=\w)(?=\W)`	Positions de début et fin de mots
	`\B`	`\B` ou `[^[:<:]]` `[^[:>:]]`	`(?<=\W)(?=\W)│(?<=\w)(?=\w)`	Positions ni en début ni en fin de mot
		`[[:cnrtl:]]`	`\x00-\x1F\x7F`	Caractères de contrôle
`\d`	`\d`	`\d` ou `[[:digit:]]`	`0-9`	Chiffres décimaux
`\D`	`\D`	`\D` ou `[^[:digit:]]`	`^0-9`	Autre qu’un chiffre décimal
		`[[:graph:]]`	`\x21-\x7E`	Caractères visibles
`\l`		`[[:lower:]]`	`a-z`	Lettres en minuscule
`\p`		`[[:print:]]`	`\x20-\x7E`	Caractères imprimables
		`[[:punct:]]`	`][!"#$%&'()\*+,./:;<=>?@\^_{│}~-`	Caractères de ponctuation
`\_s`	`\s`	`\s` ou `[[:space:]]`	`\t\r\n\v\f`	Caractères d’espacement
`\S`	`\S`	`\S` ou `[^[:space:]]`	`^ \t\r\n\v\f`	Autre qu’un caractère d’espacement
	`\v`	`\v`		Caractère d’espacement vertical
		`\V`		Autre qu’un caractère d’espacement vertical
`\u`		`[[:upper:]]`	`A-Z`	Lettres capitales
`\x`	`\x`	`\h` ou `[[:xdigit:]]`	`A-Fa-f0-9`	Chiffres hexadécimaux
		`\H` ou `[^[:xdigit:]]`		Autre qu’un chiffre hexadécimal
	`\A`	`\A`		Début de chaîne de caractère
	`\z`	`\z`		Fin de chaîne de caractère

Propriétés Unicode

Mais les classes de caractères ne se limitent pas à celles listées ci-dessus. Il est en effet possible de tirer profit des propriétés Unicode. Voici quelques exemples pour toucher du doigt le potentiel de ces classes.

Jeux de caractères

Il est par exemple possible de rechercher n’importe quel caractère grec :

/\p{Greek}/

2ΠR valent mieux qu'un caillou
 ^

Symboles monétaires

Ou encore, de retrouver les symboles monétaires dans une chaîne :

/\p{Sc}/g

Vous pouvez payer en €uro en £ivre ou en ¥en. Et même en ₿itcoin !
                     ^       ^           ^               ^

Tirets de ponctuation

Voire de détecter n’importe quel tiret de ponctuation :

/\p{Pd}/g

Vous êtes plutôt trait d'union (‐ U+2010), signe moins (- U+002D), tiret demi-cadratin (– U+2013), tiret cadratin (— U+2014) ou tiret numérique (‒ U+2012) ?
                                ^                       ^                               ^                          ^                             ^

Exclusion

Il est même possible d’exclure une sous-classe. Par exemple, voici comment retrouver tous les caractères de ponctuation et symboles, excepté les tirets :

/(?!\p{Pd})[\p{P}\p{S}]/g

schöner co-operative two_words!@#$%^
                        ^     ^^^^^^

Il existe près de 40 de ces propriétés Unicode ! Si la curiosité vous pique, je vous invite à aller faire un tour du côté de la documentation d’Erlang traitant de ce sujet.

À suivre…

Dans un prochain article, je vous présenterai un cas concret de non portabilité d’une expression rationnelle et comment j’ai dû ruser pour arriver à mes fins !

Configuration applicative

2021-10-01T00:00:00+02:00

Lorsqu’il s’agit de configurer une application Rails, chez Synbioz, on aime bien y apporter une grande souplesse pour pouvoir nous adapter à de multiples situations. C’est pourquoi on favorise l’usage de variables d’environnement. Pour accéder à ces variables, on pourra utiliser ENV.fetch("ma_variable") si sa présence est obligatoire, ou ENV["ma_variable"] si elle est optionnelle.

Se pose alors la question des variables booléennes. Par convention, nous avons choisi de favoriser “0” ou “1” au détriment d’autres valeurs comme “true”, “FALSE”, “yes”, “f”, etc. Ainsi, une variable d’environnement booléenne sera récupérée via ENV.fetch("ma_variable").to_i.positive?.

Fail fast

The most annoying aspect of software development, for me, is debugging. I don’t mind the kinds of bugs that yield to a few minutes’ inspection. The bugs I hate are the ones that show up only after hours of successful operation, under unusual circumstances, or whose stack traces lead to dead ends. Fortunately, there’s a simple technique that will dramatically reduce the number of these bugs in your software. It won’t reduce the overall number of bugs, at least not at first, but it’ll make most defects much easier to find. The technique is to build your software to “fail fast.”

— Jim Shore

Dans l’idéal, quel que soit le framework ou le langage, il est préférable de récupérer l’ensemble des variables d’environnement utiles à l’application au démarrage de celle-ci, de manière centralisée pour faciliter la prise de connaissance de ces variables et leur mise à jour. Ainsi, si une variable est manquante au démarrage, on pourra faire planter l’application dès son lancement avec un message explicite. Ceci évite d’avoir des plantages aléatoires à l’exécution ; à l’envoi d’un courriel ou lors d’un appel à une API par exemple.

Configuration X

Dans le cas d’une application Rails, on va centraliser la récupération des variables d’environnement dans le fichier config/application.rb. On a donc notre point centralisé, chargé au démarrage de l’application qui va nous permettre d’être robuste face aux variables d’environnement manquantes.

Rails prévoit un mécanisme pour stocker toutes les informations de configuration transversales à l’application. Cela nous évite de passer par un système maison, ou pire, des variables globales. Rails.configuration.x permet de stocker l’ensemble des données de configuration pour une instance donnée et de récupérer très facilement ces infos depuis n’importe où dans l’application.

L’implémentation de Rails.configuration.x mérite qu’on s’y attarde ! Il s’agit d’une instance de la classe Custom déclarée comme ceci :

# railties/lib/rails/application/configuration.rb

module Rails
  class Application
    class Configuration < ::Rails::Engine::Configuration

      def initialize(*)
        @x = Custom.new
      end

      class Custom #:nodoc:
        def initialize
          @configurations = Hash.new
        end

        def method_missing(method, *args)
          if method.end_with?("=")
            @configurations[:"#{method[0..-2]}"] = args.first
          else
            @configurations.fetch(method) {
              @configurations[method] = ActiveSupport::OrderedOptions.new
            }
          end
        end

        def respond_to_missing?(symbol, *)
          true
        end
      end
    end
  end
end

On observe que la technique consiste à faire usage de la méthode method_missing, nous offrant ainsi la possibilité de récupérer ou d’affecter une valeur via n’importe quelle méthode de notre choix sur cet objet. On remarque que si la clé foo n’existe pas dans le dictionnaire @configurations, c’est-à-dire la première fois qu’on fait appel à Rails.configuration.foo, une nouvelle instance d’ActiveSupport::OrderedOptions.new est créée. Il s’agit d’une classe qui hérite de la classe Hash et qui fournit des accesseurs dynamiques.

Avec un Hash, les paires clé-valeur sont généralement manipulées comme ceci :

h = {}
h[:boy] = 'John'
h[:girl] = 'Mary'
h[:boy]  # => 'John'
h[:girl] # => 'Mary'
h[:dog]  # => nil

En utilisant un OrderedOptions, l’exemple ci-dessus peut être écrit comme ceci :

h = ActiveSupport::OrderedOptions.new
h.boy = 'John'
h.girl = 'Mary'
h.boy  # => 'John'
h.girl # => 'Mary'
h.dog  # => nil

Il est aussi possible de lever une exception si la valeur est manquante :

h.dog! # => raises KeyError: :dog is blank

Dans ce contexte, l’utilisation conjointe de method_missing et OrderedOptions nous offre une grande souplesse à l’usage. C’est une approche intéressante, notamment dans le cas d’un framework ou d’une bibliothèque généraliste, mais coûteuse et déconseillée pour implémenter un code métier aux règles de gestion bien connues et maîtrisées.

Remarquons ici une bonne pratique souvent oubliée lorsqu’on fait usage de method_missing : implémenter également respond_to_missing? de manière à indiquer si la méthode que l’on s’apprête à utiliser est implémentée ou non à la volée par method_missing. Dans notre cas, on répondra toujours oui (true) parce que notre implémentation de method_missing se comportera toujours comme un accesseur, peu importe le nom de la méthode qu’on lui passe en argument.

À l’usage

Dans les faits, en suivant les recommandations précédentes, nous pourrions nous retrouver avec une configuration applicative qui ressemble à ceci :

# config/application.rb

module MyApp
  class Application < Rails::Application
  # …
  config.x.api_url = ENV.fetch("API_URL")
  config.x.api_scheme = ENV.fetch("API_SCHEME", "http")
  config.x.enable_foo = ENV.fetch("ENABLE_FOO", 0).to_i.positive?
  # …
  end
end

Et l’utiliser de cette manière dans notre application :

Rails.configuration.x.api_url
Rails.configuration.x.enable_foo == true

Allons un peu plus loin

Rails nous offre un outil supplémentaire qui peut s’avérer fort utile, j’ai nommé config_for. Il s’agit d’un moyen de charger une configuration applicative à partir d’un fichier YAML. Cerise sur le gâteau, l’environnement courant de Rails est pris en compte ! Voici un petit exemple :

# config/api_custom.yml

defaults: &defaults
  timeout: <%= ENV.fetch("API_CUSTOM_TIMEOUT", 20).to_i %>

development:
  <<: *defaults
  url: <%= ENV.fetch("API_CUSTOM_URL", "https://custom-dev.api.example.org/api/v2") %>

test:
  <<: *defaults
  url: https://custom-test.api.custom.org/api/v2

production:
  <<: *defaults
  url: <%= ENV.fetch("API_CUSTOM_URL", "https://custom.api.custom.org/api/v2") %>

# config/application.rb

class Application < Rails::Application
  # Custom Configuration
  config.x.api_custom = config_for(:api_custom)
end

À présent, nous pouvons faire appel à notre configuration :

Rails.configuration.api_custom.timeout
Rails.configuration.api_custom.url

Avouez que c’est bien pratique ! Ainsi notre configuration applicative est à la fois centralisée et contextualisée ; fini les variables de configuration obscures qui surgissent d’on ne sait où !

Ressources

Faut-il coder en français ?

2021-06-04T00:00:00+02:00

Voici une question qui me taraude depuis quelque temps et à laquelle je souhaite apporter le fruit de mes réflexions et des échanges que j’ai pu avoir avec mes consœurs et confrères. Alors, faut-il coder en français ? Eh bien, ça dépend…

Oui ça évidemment, on vous demande de répondre par oui ou par non, alors « ça dépend » ça dépasse !

— Le Père-Noël est une ordure

C’est-à-dire que la question est complexe et demande d’être contextualisée pour pouvoir y apporter des éléments de réponse ou, à tout le moins, des axes de réflexion.

Au service de la France

Le contexte le plus évident qui nous vient à l’esprit quand on commence à se poser ce genre de question, c’est celui d’un projet réalisé par une équipe francophone, pour un commanditaire francophone, à destination d’un public francophone. Là, on en arrive vite à se demander pourquoi coder en anglais ? Quel intérêt à cela ? Qu’a-t-on à y gagner ?

C’est vrai que dans ce genre de situation, la question semble légitime. L’anglais n’étant généralement pas la langue maternelle d’un francophone, il en maîtrisera moins les subtilités. De plus, il y a fort à parier que la majorité des communications et échanges au sein de l’équipe, mais aussi avec le client et les utilisateurs se feront en français. Et ce n’est pas sans incidence, car si le choix de la terminologie s’est porté sur l’anglais, ça implique alors pour bien se comprendre en toute situation de tenir à jour un lexique bilingue, de manière à partager un vocabulaire commun. Si au contraire, le français avait été employé pour nommer toute chose dans l’application, nous aurions pu éviter cette étape de traduction parfois maladroite pour ne pas dire casse-gueule.

MOÏSE, Qu’est-ce qui vous a pris de répondre au téléphone ?
ANDRÉ MERLAUX, Eh bien (hésitant), le téléphone sonnait. Et j’ai décroché.
MOÏSE, La logique m’échappe. (silence) Je ne comprends pas.
ANDRÉ MERLAUX, Le téléphone… (silence) J’ai pensé que…
MOÏSE, Vous n’êtes pas à la Sécurité sociale Merlaux. La moindre information mal interprétée peut déclencher une guerre mondiale. (silence) Une guerre mondiale !

— Au service de la France, saison 1, épisode 1

Soyons honnêtes, il est très rare qu’un lexique soit défini, et encore plus rare qu’il soit partagé entre les équipes métier chez le client et les équipes techniques chez le prestataire. Alors maintenir un lexique bilingue relève de l’utopie ! Pourtant il est crucial de se comprendre. Lorsqu’on échange avec notre client, lorsqu’on souhaite réaliser un produit qui répond à ses besoins, il est nécessaire de comprendre ces besoins. Pour ce faire, il nous faut impérativement parler un langage commun. Et ce langage doit être celui du client. Il ne nous appartient pas en tant que prestataire d’imposer à notre client un vocabulaire qui lui est étranger. Notre métier consiste à comprendre le sien, puis à le modéliser le plus fidèlement possible sous la forme d’un programme informatique. À la lecture du code, tout ce qui fait la spécificité, la particularité, la nature unique du métier de notre client doit transpirer. Si votre client exerce dans le domaine médical, par exemple, il conviendra de parler de patient et non d’utilisateur.

Ce langage commun est appelé ubiquitous language par Eric Evans dans son livre « Domain Driven Design » ; un langage omniprésent donc, à la fois dans les échanges, mais également dans le code source.

Zazie dans le métro

Tout bien considéré, on se dit pourquoi pas tenter la chose ! Allons-y, faisons transparaitre le vocabulaire métier dans notre code ! Oui mais…

– glup, c’est d’un compliqué… Ah! enfin, des mots que tout le monde connaît… vestalat… vésulien… vétilleux…euse… ça y est! Le voilà! Et en haut d’une page encore. Vêtir. Y a même un accent circonchose. Oui: vêtir. Je vêts… là, vous voyez si je m’esprimais bien tout à l’heure. Tu vêts, il vêt, nous vêtons, vous vêtez… vous vêtez… c’est pourtant vrai… vous vêtez… marant… positivement marant… Tiens… Et dévêtir?… regardons dévêtir… voyons voir… déversement… déversoir… dévêtir… Le vlà. Dévêtir vé té se conje comme vêtir. On dit donc dévêtez-vous. Eh bien, hurla-t-il brusquement, eh bien, ma toute belle, dévêtez-vous! Et en vitesse! A poil!

— Zazie dans le métro de Raymond Queneau

Les errances du langage et une syntaxe malmenée font la singularité de cette œuvre de Raymond Queneau. C’est aussi ce qui caractérise les courageuses tentatives de l’emploi du français dans des bases de code, le génie en moins. Oui, ne nous mentons pas, quand on code en français, ça donne généralement quelque chose comme ça :

describe "DossierMailer" do
  it "creates a commentaire" do
    expect(DossierMailer).
      to have_received(:notify_new_commentaire_to_instructeur).
      with(dossier, instructeur_with_instant_message.email)
  end
end

Aïe, ça pique les yeux. On a ici un exemple où l’effort a été fait d’utiliser le vocabulaire métier. On y retrouve « Dossier », « commentaire » ou encore « instructeur ». Mais l’effort s’arrête là puisqu’on se retrouve avec un mélange maladroit de français et d’anglais qui dessert l’objectif. Tout d’abord, la lecture s’en trouve malaisée, le cerveau fait des nœuds, ne sachant plus s’il lit un mot anglais ou français. Essayons de faire un peu mieux :

describe "ExpediteurDeDossier" do
  it "crée un commentaire" do
    expect(ExpediteurDeDossier).
      to have_received(:notifier_d_un_nouveau_commentaire_a_l_instructeur).
      with(dossier, instructeur_avec_message_instantane.courriel)
  end
end

Ce n’est là que mon ressenti, mais je ne suis pas certain qu’on ait clarifié grand-chose… En fait, on butte sur plusieurs contraintes du langage et autres particularités de la langue. Tout d’abord, l’évidence : les mots clés du langage, ici Ruby, et des DSL comme celui de RSpec sont en anglais. Quand bien même vous feriez l’effort de traduire le DSL de RSpec en français, il vous serait impossible de redéfinir les mots réservés du langage.

Ensuite, la langue. On s’aperçoit, dès lors qu’on aborde des considérations techniques, que le vocabulaire associé est très souvent en anglais et il peut être difficile de trouver une traduction fidèle en français. Prenez « mailer » dans l’exemple ci-dessus, que j’ai maladroitement traduit par « expéditeur », faute de mieux. On remarque ici une perte de sens. On comprend bien que quelque chose sera envoyé, mais le fait que ce soit un courriel est totalement passé sous silence. Plutôt qu’« expéditeur de dossier », il aurait été plus correct de parler d’« expéditeur de courriel concernant un dossier ». Si vous aviez dans l’idée de vous limiter à des lignes de 80 caractères, vous pouvez oublier !

L’empire des signes

Notez aussi l’absence des diacritiques ! Ruby, comme bien d’autres langages, a beau supporter parfaitement UTF-8, on ne voit pour ainsi dire jamais un seul caractère accentué lorsque les variables sont en français. Et pourquoi diable !? Rien ne nous empêche de nommer nos variables Expéditeur ou message_instantané, pour reprendre l’exemple ci-dessus. Et en effet, c’est syntaxiquement valide du point de vue du langage. Mais j’y vois bien une contre-indication ou du moins quelque argument qu’on pourrait y opposer : ces caractères ne sont pas toujours facilement accessibles au clavier, cela va dépendre de sa disposition et si vous avez opté pour Qwerty, Dvorak ou Colemak, les touches accentuées vous seront moins facilement accessibles. Et je ne parle même pas des ligatures qu’on trouve par exemple dans sœur ou ex_æquo !

Maintenant, laissons là notre contexte franco-centré et imaginons que nous collaborions à un projet open source initié par un Japonais. En parcourant le code, on pourrait y lire ceci :

module Japanize
  class Parser
    def initialize(sequence)
      @sequence = sequence
    end

    def parse
      @sequence.split('　').map do |s|
        s.split(/#{助詞.join("|")}/)
      end.flatten.map do |s|
        if 動詞[s]
         動詞[s]
        elsif 数字[s[0]]
         NumberConverter.convert(s)
        end
      end
    end
  end
end

Ah tout de suite, à moins d’être japonisant, on fait moins le malin ! Même la coloration syntaxique du blog botte en touche ! Et pour cause : bien que ce code soit totalement valide et fonctionnel, l’utilisation de kanjis pour nommer les méthodes nous place dans une situation pour le moins inconfortable.

Lorsque Yukihiro “Matz” Matsumoto a commencé à développer Ruby en 1995, il a utilisé des mots-clés anglais, mais il écrivait toute la documentation en japonais ! En 2001, quand est publié Programming Ruby, la quasi-totalité de la documentation était encore en japonais. C’est pourquoi ce langage fut si peu utilisé en dehors de son archipel natal durant ses premières années. Mais à présent, c’est un langage utilisé à travers le monde, et le fait qu’il soit né au Japon n’a qu’un intérêt historique. Si le langage avait utilisé des mots-clés en hiragana, il aurait eu beaucoup plus de mal à gagner en popularité.

Ce qui nous amène à l’internationalisation. Les choses évoluent ; les contextes aussi. Il se peut qu’un projet soit amené à rencontrer un public plus vaste que prévu. Autant quand il s’agit d’un projet français à destination d’un ministère ou d’une collectivité territoriale, on peut raisonnablement penser que la langue vernaculaire sera le français ; autant quand il s’agit d’une suite bureautique, on a de bonnes raisons de mettre cette affirmation en doute.

The Office

Une évolution de contexte, c’est justement ce qui est arrivé à StarOffice. Initialement développé par l’entreprise allemande Star Division, ce projet a été libéré en 2000 suite au rachat de l’entreprise par Sun, donnant ainsi naissance à OpenOffice et ouvrant la porte à une communauté internationale de contributeurs. Seul hic, la base de code comportait quelque 100 000 lignes de commentaires en allemand ! La traduction de ces commentaires en anglais s’est étalée de 2011 à 2018.

Et on ne parle ici que de documentation ! Imaginez si les classes, les méthodes, les variables et autres constantes étaient elles aussi formulées en allemand… ç’aurait été une autre paire de manche !

Alors quoi ?

Nous venons de voir que choisir de coder et documenter en français peut avoir de forts impacts, tant positifs que négatifs. C’est pourquoi il est important que ce choix soit fait en conscience. Et si vous optez pour le français, faites-le pleinement ! Cela évitera des résultats hybrides dont tout le monde se serait bien passé. Écrivez votre code en français, dans la limite des possibilités offertes par votre langage et des conventions de nommage. Mais rédigez aussi vos commits, vos tests et votre documentation en français.

Ce faisant, les échanges avec le métier seront plus fluides. Pas besoin de traduire le langage métier en langage technique, et vice-versa. La terminologie gagnera aussi en précision. Lorsqu’il s’agit d’un domaine métier ayant un vocabulaire riche et précis (légal, médical…), et que celui-ci vous est transmis en français, trouver une correspondance en anglais peut s’avérer délicat voire hasardeux quand on n’est ni bilingue, ni du métier. Au final, le code et tout ce qui aura été produit traduiront avec une grande fidélité le besoin exprimé par le client si l’on s’épargne la phase de traduction.

Si au contraire vous optez pour l’anglais, c’est correct. Mais soyez rigoureux et vigilant ; veillez à ce que des termes français ne se glissent pas au beau milieu de votre code ou d’une description de merge request. Efforcez-vous aussi à rédiger dans un anglais correct plutôt qu’un globish saupoudré de franglicismes.

Rédigé en français, le code n’est plus accessible aux non-francophones. À l’inverse, rédigé en anglais il sera peut-être moins abordable pour qui n’est pas à l’aise avec cette langue. Dans les deux cas, cela pose la question de l’inclusion et de l’intégration au sein de votre entreprise ou communauté.

Peu importe votre choix, assumez-le, faites-le vôtre, et itérez pour trouver le compromis qui, selon votre contexte, vous permettra d’en tirer le meilleur bénéfice.