Pour le moment, je vais juste reprendre une partie de ce que j’avais écrit, concernant la syntaxe des langages.

Une des caractéristiques essentielles d’un langage de programmation, c’est d’être facile à lire et à relire. On doit pouvoir lire du code source comme un linguiste peut lire un texte écrit dans une langue étrangère.
Cela passe notamment par un syntaxe légère, qui ne se mette pas en travers de la lecture, qui ne soit pas inutilement verbeuse et qui reste sans ambiguïté.

Blocs, labels, accolades et indentation

Pour illustrer mon propos, je vais vous montrer comment on code la factorielle récursive dans plusieurs langages procéduraux. Tout d’abord en Pascal :

FUNCTION factorielle (n: shortint) : integer;
BEGIN
    IF n <= 1 THEN
        BEGIN
            WRITELN('End of loop');
            factorielle := 1
        END
    ELSE
        BEGIN
            WRITELN('Loop');
            factorielle := n * factorielle (n - 1)
        END;
END;

Ensuite en BASIC (VB.net, inspiré par le site Developpez.com, © Philippe Laserre) :

Function Factorielle (ByVal N as Long) As Long
    If N=1 Then
        Console.WriteLine("End of loop")
        Return 1
    End If
    Console.WriteLine("Loop")
    Return N * Factorielle(N - 1)
End Function

Et voici le code équivalent en C :

int factorielle(int n)
{
    if (n <= 1)
    {
        printf("End of loop\n");
        return 1;
    }
    printf("Loop\n");
    return n * factorielle(n - 1);
}

def factorielle(x):
    if x <= 1:
        print("End of loop\n")
        return 1
    print("Loop\n")
    return x * factorielle(x - 1)

ma_liste = [
       "aaa",
                     "bbb",
  "ccc"
]

for i:= 0; i < flag.NArg(); i++ {
    if i > 0 {
        s+= space
    }
    s+= flag.Arg(i)
}

for (i = 0; i < flag.NArg(); i++) {
    if (i > 0)
        s += space;
    s += flag.Arg(i);
}

This is my

test

bitches

Évidemment, 45 minutes plus tard, ils envoyaient un message d’excuse, intitulé « We Really Screwed Up » :

Hi,

From all of us on the Fetchnotes team, we sincerely apologize for
the email you received earlier. We were working on a new email
system and unfortunately one of our test emails, with some
questionable language, slipped through. We are deeply sorry for
what happened and hope that we can continue striving to deliver an
excellent experience. This was just not one of those experiences
unfortunately.

Thank you,

The Fetchnotes Team

Ouaip, ils se sont vautrés comme des merdes. Non seulement ils ont envoyé un email de test à tous leurs abonnés, mais le message en question peut être très mal perçu (ce sont leurs abonnés, qu’ils traitent de salopes ?).

C’est le genre de grosses connerie qu’on redoute tous de laisser s’échapper un jour. En tant qu’informaticien, je comprends comment ce genre de chose peut arriver. Mais ça ne donne vraiment pas une bonne image de professionnalisme.

J’ai appris « à la dure » que le professionnalisme est une attitude à laquelle il faut prêter attention en toute circonstance. Lors de mon tout premier stage en entreprise, quand j’étais jeune et bête, je me suis retrouvé à devoir faire une maquette de page web, pour en faire ensuite l’intégration. Je ne suis pas graphiste, je ne connaissais pas encore les générateurs de Lorem Ipsum ; il a donc fallu que je remplisse la maquette avec des textes à la con. Et j’ai vraiment écrit des trucs à la con ; notamment que le patron de l’entreprise était poursuivi pour malversations financières…

Cette maquette, qui ne devait être utilisée que par un autre développeur et moi, a été utilisée par le chef de projet. Sans m’en informer (pourquoi aurait-il dû ?), il l’a placée dans un document de présentation qu’il a envoyé au client.
Quand je me suis rendu compte de ça, je me suis senti tout pâle. J’ai couru voir mon chef de projet, et on s’est heureusement rendu compte qu’il avait réduit l’image au point que le texte était illisible.

Que ce serait-il passé si le client avait lu mes textes débiles ? J’aurais pu me faire virer de mon stage. Au minimum.

Cela m’a servi de leçon. Désormais, je fais toujours attention à ce que j’écris. Quelle que soit la situation, je me dis que ce que je produis pourrait un jour être propagé en dehors du périmètre dans lequel je le crois confiné.

Vous ne savez pas le nombre de fois où j’ai vu des échanges internes, à propos d’un projet par exemple, être transférés à un client ou un partenaire. Simplement parce qu’au milieu des échanges s’est retrouvée une information qui pouvait intéresser le client, quelqu’un lui envoie. Sans se rendre compte que c’est l’ensemble de la discussion qui a été transférée, y compris certains messages très peu professionnels voire même certaines remarques diplomatiquement difficiles à justifier vis-à-vis du client.

Un simple “Projet de merde !”, lâché par un développeur un jour de stress, risque de se retrouvé glissé dans une discussion ; à force de « reply-to », le texte est copié mais on n’y prend pas garde, jusqu’à ce que le client exprime son mécontentement et réclame une explication.

Si vous ne voulez pas vous retrouver dans ce genre de situation, dites-vous que vos échanges d’emails professionnels doivent toujours refléter votre professionnalisme.

Pour en revenir à Fetchnotes, ils ont cumulé les bévues. Envoyer un email de test à toute leur base de données, c’est con. Envoyer un email débile et limite insultant, c’est très con. J’espère pour eux que cela ne les empêchera pas de mener leur service avec succès ; et j’espère que le jeune développeur qui fait ses tests en écrivant des bêtises a été vacciné à vie contre ce genre de choses − comme je l’ai moi-même été, avec moins de conséquence.

Juste pour terminer sur le sujet : Quand on fait une connerie, il faut l’assumer. Fetchnotes l’a bien compris, menant une communication rapide et efficace, par email et sur Twitter. Ils s’excusent, reconnaissent leur erreur (faite par leur cofondateur), répondent individuellement à tous les messages sur le sujet. Bien joué.

Je ne vais pas m’étendre sur la théorie de la création des compilateurs et des interpréteurs. J’avais lu un énorme bouquin sur le sujet il y a quelques années ; c’était super intéressant, mais j’avoue ne pas en avoir retenu grand chose de concret. Il faut dire que c’est assez éloigné de mes préoccupations quotidiennes.

Non, je vais plutôt vous parler… d’un moyen de contourner un peu tout ça.

Compilateurs et interpréteurs

Reprenons. Si on simplifie à l’extrême, le travail d’un compilateur c’est ça :

1. Lecture du code source.
2. Analyses diverses.
3. Construction de l’arbre de compilation.
4. Optimisation.
5. Génération du code machine et écriture du fichier exécutable.

Le boulot d’un interpréteur, c’est plutôt :

1. Lecture du code source.
2. Analyses diverses.
3. Construction de l’arbre d’interprétation.
4. Optimisations éventuelles.
5. Exécution (évaluation de l’arbre).

Dans le principe, il y a beaucoup de similitudes. D’ailleurs, toutes les explications données dans le livre dont je vous parlais plus haut étaient dans l’optique de construire un interpréteur ; alors que le livre s’intitulait Les compilateurs.

De plus en plus, les interpréteurs passent par un code machine intermédiaire, le bytecode, destiné à être exécuté par une machine virtuelle. Ce code peut parfois être stocké sur disque pour accélérer les exécutions futures, mais ce n’est pas systématique. Cela donne donc des interpréteurs qui fonctionnent ainsi :

1. Génération du bytecode
1. Lecture du code source.
2. Analyses diverses.
3. Construction de l’arbre de compilation.
4. Optimisation.
5. Génération du bytecode.
2. Exécution
1. Chargement de la machine virtuelle.
2. Exécution (évaluation du bytecode par la machine virtuelle).

Ce fonctionnement est censé être plus rapide, car le bytecode est généré spécifiquement pour la machine virtuelle ; celle-ci l’exécute comme du code natif à ses yeux, et non pas comme une évaluation pas-à-pas de l’arbre syntaxique (oh les explications foireuses ! je m’en excuse platement).

Il existe un autre type d’interpréteur, les compilateurs JIT. Leur principe est de compiler à la volée le code source en binaire natif. Le gros intérêt est que le binaire est exécuté directement par l’ordinateur, il n’a pas besoin de machine virtuelle. Pourquoi tous les interpréteurs ne sont pas des compilateurs JIT ? Parce que c’est loin d’être simple à mettre en œuvre. Les compilateurs natifs sont habituellement assez lents ; cela ne pose pas le moindre problème, car quand on compile du code C ou C++, le but est d’obtenir un programme dont l’exécution sera la plus rapide possible ; ils intègrent d’ailleurs plein d’optimisations qui ralentissent la compilation mais qui accélèrent l’exécution.

Un compilateur JIT doit donc être capable de compiler nativement dans un délai très court, afin que l’exécution d’un programme interprété ne semble pas systématiquement ralentie.

Comment créer un interpréteur ?

J’ai été amené à créer plusieurs interpréteurs. Un interpréteur Lisp minimal, un interpréteur de script compatible Bash, un évaluateur mathématique assez poussé dans un outil de génération de PDF. Et je confirme : sans être impossible, ce n’est quand même pas simple.

Et encore, il ne s’agissait que de simples interpréteurs. Pas de bytecode ni de machine virtuelle, et encore moins de compilation native. J’ai bien codé une machine virtuelle particulièrement sommaire durant mes études, mais elle émulait un ordinateur tellement simple que ça ne serait d’aucune utilité.

Par contre, j’ai suivi des cours de compilation, durant lesquels j’ai appris à utiliser Lex et Yacc, qui forment un compilateur de compilateur. Ils offrent les outils de base nécessaires à la réalisation d’un interpréteur ou d’un compilateur (analyse lexicale, analyse syntaxique) : ils permettent de lire un fichier et de le « comprendre » ; à partir de là, on peut soit exécuter du code (interprétation directe), soit construire un arbre d’exécution (pour ensuite interpréter ou compiler l’arbre).

Je dois bien avouer que je n’ai pas utilisé ces programmes une seule fois de toute ma carrière. Ils ne sont pas particulièrement simples à appréhender, mais rien de fondamentalement impossible.
La grande difficulté n’est pas spécialement d’utiliser Lex/Yacc pour extraire les lexèmes qui composent un code source. La grande difficulté, c’est de construire un arbre efficace et de le traiter correctement. C’est la différence entre un petit interpréteur rigolo et un vrai langage.

La solution ?

J’en viens enfin à ma recette miracle. Il existe un compilateur C qui présente trois caractéristiques très intéressantes :

1. Il est particulièrement rapide. Il applique forcément moins de d’optimisations sur le code qu’un compilateur comme GCC, mais n’en produit pas moins du code binaire natif très efficace.
2. Il peut compiler et exécuter à la volée. Conjugué au point précédent, cela veut dire qu’on peut s’en servir comme d’un interpréteur C. Mais, contrairement aux quelques rares interpréteurs qui utilisent une syntaxe proche du C, le code n’est pas interprété ; il est compilé nativement − très très vite − puis exécuté, et tout ça sans écrire de fichier sur le disque.
3. Il est disponible sous la forme d’une bibliothèque de fonctions, elle-même écrite en C, qui permet d’exécuter du code à la volée. Cette bibliothèque permet même de partager des symboles ; ainsi, le programme qui l’utilise pour compiler et exécuter du code à la volée pourra accéder directement aux données et aux fonctions de ce code, et inversement !

Ce compilateur, c’est TinyCC. Il est écrit par le français Fabrice Bellard, qui a aussi à son actif l’émulateur QEMU ou encore la bibliothèque FFmpeg.

Je suis en train de réaliser divers benchmarks en ce moment, pour comparer plusieurs langages de programmation. Je publierai les résultats sur ce blog quand ce sera terminé. Mais je peux déjà vous dire que, pour un code orienté objet avec de l’héritage et du polymorphisme, beaucoup d’instanciations d’objets, des parcours de tableaux et quelques calculs mathématiques, j’obtiens pour le moment les résultats suivants :

• code C compilé avec GCC : 24 ms
• code C++ compilé avec G++ : 25 ms
• code C compilé à la volée avec TinyCC : 150 ms
• code PHP : 2934 ms

Bon, en soit ça ne veut pas dire grand chose (je publierai les codes sources en même temps que l’ensemble des résultats du benchmark). Mais on se rend quand même compte que TinyCC est très efficace (pour info, la compilation avec GCC prend environ 60 ms).

L’idée que j’ai en tête, c’est que plutôt que d’écrire un interpréteur complet (travail de titan), il est certainement plus simple d’écrire un programme qui traduit une syntaxe donnée en code C, que TinyCC peut compiler et exécuter à la volée. En plus, cela offre la possibilité de compiler le code nativement.

D’une certaine manière cela veut dire que le code C devient le bytecode, le langage intermédiaire qui est utilisé pour produire le binaire final.
Je sais que ça peu sembler tordu, mais je suis très humble quant à ma capacité à générer du bytecode et à créer une machine virtuelle. Par contre, je pense pouvoir être capable de créer un traducteur qui génère du code C à partir d’un autre code source.
La vraie question, c’est de savoir si cette étape de traduction ne risque pas à elle seule de plomber les performances d’un tel interpréteur…

Edit : Je découvre a posteriori que cette idée n’est pas si nouvelle que ça. Le projet SmartEiffel (un compilateur open-source du langage Eiffel) effectue la traduction du code Eiffel en code C (ou en bytecode Java), pour ensuite effectuer une compilation native grâce à GCC.

Faisons un test !

Allez, soyons fou, essayons d’écrire un traducteur ultra-simpliste.

Créons un langage de programmation dont la syntaxe est très simpliste. Il n’accepte que 3 types de commandes. Voici un exemple de code source (bon, ça fait un peu pompeux d’appeler ça du code source, mais on est là pour s’amuser) :

# affecte une variable
# leurs noms commencent par un dollar suivi d'une seule lettre
AFF $a = 3
# incrémente une variable
# si elle n'avait pas été affectée, elle est initialisée à 0
INC $b
# affichage conditionnel
# écrit le texte après les deux-points si la condition est vraie
IF $a <= 3 : Texte

Nous allons maintenant écrire un programme qui lit un fichier de code source (passez-moi l’expression), génère du code C dans une variable, puis utilise la bibliothèque libtcc pour compiler et exécuter ce code.

Le début du programme est facile. Quelques inclusions basiques, la définition des prototypes de deux fonctions utilitaires et la fonction principale du programme. Celle-ci alloue une zone mémoire qui contiendra le code C, puis lance la lecture du fichier source et la génération du code C, ensuite elle affiche le contenu de code C généré, et enfin elle appelle la fonction qui exécute le code C.

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <libtcc.h>

// prototypes
void execute(char*);
void readfile(char*, char*);

/* fonction principale */
void main(int argc, char **argv)
{
   char result[1024];

   // lecture du fichier et génération du code C
   readfile(argv[1], result);
   // affichage du code C généré
   printf("CODE C :\n%s\n", result);
   // exécution du code C généré
   execute(result);
}

La fonction de lecture et de génération de code initialise quelques variables, ouvre le fichier contenant le code source, lit les instructions qui y sont écrites et ajoute l’équivalent en C dans une chaîne de caractères. Il y a une petite subtilité au sujet des variables : à chaque instruction, on complète un tableau pour indiquer quelles sont les variables qui sont utilisées, afin de faciliter leur déclaration en C.

Edit : J’ai modifié légèrement cette fonction pour gérer les lignes de commentaire (commençant par un caractère dièse). Ce sont les deux lignes en bleu. J’explique plus bas l’utilité réelle de la chose.

/* lit le fichier et génère le code C */
void readfile(char *filename, char *result)
{
   FILE *input;
   char line[128], buf[128], msg[128], op1, cond[3];
   char code[1024], variables[128];
   int i;

   // initialisations
   result[0] = code[0] = '\0';
   strcat(result, "int wrapper() {\n");
   for (i = 0; i < 128; ++i)
      variables[i] = '\0';
   // ouverture du fichier source
   input = fopen(filename, "r");
   // lecture de toutes les lignes du fichier
   while (!feof(input) && fgets(line, 128, input))
   {
      // détection de la commande
      if (line[0] == '#')
         continue;
      if (sscanf(line, "AFF $%c = %d", &op1, &i))
         sprintf(buf, "\t%c = %d;\n", op1, i);
      else if (sscanf(line, "INC $%c", &op1))
         sprintf(buf, "\t%c++;\n", op1);
      else if (sscanf(line, "IF $%c %s %d : %s", &op1, cond,
                      &i, msg))
         sprintf(buf, "\tif (%c %s %d) printf(\"%s\\n\");\n",
                 op1, cond, i, msg);
      variables[op1] = op1;
      strcat(code, buf);
   }
   fclose(input);
   // définition des variables
   for (i = 0; i < 128; ++i)
   {
      if (variables[i])
      {
         sprintf(buf, "\tint %c = 0;\n", i);
         strcat(result, buf);
      }
   }
   // ajout du code
   strcat(result, code);
   strcat(result, "\treturn 0;\n}\n");
}

Enfin, la fonction d’exécution fait compiler le code C par TinyCC, place le binaire exécutable dans une zone mémoire exploitable, puis appelle la fonction que l’on a créée préalablement.

/* exécute le code généré à la volée */
void execute(char *code)
{
   TCCState *state;
   int (*wrapper)(void);
   int size;
   void *memory;

   // création du contexte TinyCC
   state = tcc_new();
   tcc_set_output_type(state, TCC_OUTPUT_MEMORY);
   // compilation du code C
   tcc_compile_string(state, code);
   // réallocation en mémoire
   size = tcc_relocate(state, NULL);
   memory = malloc(size);
   tcc_relocate(state, memory);
   // récupération du pointeur sur la fonction
   wrapper = tcc_get_symbol(state, "wrapper");
   // libération de la mémoire allouée par TinyCC
   tcc_delete(state);
   // exécution de la fonction
   wrapper();
   // libération de la mémoire contenant le code binaire
   free(memory);
}

Pour plus d’information sur l’utilisation de libtcc, je ne peux que vous conseiller de lire un très bon article sur le Site du Zéro.

Exécution

Maintenant que nous avons notre super interpréteur, nous allons l’utiliser.

Imaginons que notre code source ressemble à ceci :

AFF $a = 3
AFF $b = 1
IF $a < 5 : ok
IF $b > 7 : ko
AFF $c = 5
INC $c
IF $c >= 6 : parfait

Quand on exécute notre interpréteur, il nous affiche la fonction C générée :

int wrapper() {
   int a = 0;
   int b = 0;
   int c = 0;
   a = 3;
   b = 1;
   if (a < 5) printf("ok\n");
   if (b > 7) printf("ko\n");
   c = 5;
   c++;
   if (c >= 6) printf("parfait\n");
   return 0;
}

Et donc, le résultat de l’exécution est donc :

ok
parfait

Super, ça marche ! Trop fort.

Edit : Pour rendre notre code source directement exécutable (c’est quand même bien utile, quand on fait un interpréteur), il suffit de lui donner les droits d’exécution avec la commande chmod, et d’ajouter le shebang qui conduit vers le programme d’interprétation :

#!/home/amaury/minilang
AFF $a = 3
AFF $b = 1
IF $a < 5 : ok
IF $b > 7 : ko
AFF $c = 5
INC $c
IF $c >= 6 : parfait

Oh miracle ! Le programme s’exécute directement. Même en sachant que ça doit marcher, c’est plaisant à voir.

Par acquis de conscience, je décide de comparer avec le code PHP suivant :

<?php
   $a = 3;
   $b = 1;
   if ($a < 5)
      print("ok\n");
   if ($b > 7)
      print("ko\n");
   $c = 5;
   $c++;
   if ($c >= 6)
      print("parfait\n");
?>

Et hop, un autre benchmark inutile mais rigolo :

• PHP : 25 ms
• mon interpréteur : 2 ms

Eh oui, c’est débile, ça ne sert à rien, mais ça arrache et ça me fait marrer. Évidemment, plus on ajoutera de vraies fonctionnalités à notre interpréteur pour enrichir sa syntaxe, plus on le ralentira. Mais je pense que ça prouve quand même que mon idée de base est loin d’être idiote : Si vous voulez créer un langage de programmation, utilisez le C comme « langage pivot » ; ce sera plus rapide à mettre en œuvre et plus efficace que si vous développiez votre propre bytecode et votre propre machine virtuelle. En plus vous pourrez accéder à toutes les bibliothèques de fonction disponibles en C, ce qui est loin d’être négligeable.

Les objets, l’héritage et le polymorphisme

La notion la plus importante de la programmation orientée objet, c’est… l’objet (tadaa !), une structure qui encapsule en même temps des données et les traitements qui y sont associés. Très vite, on trouve derrière l’héritage et le polymorphisme.

L’héritage : Un objet peut dériver d’un autre. Il en reprend toutes les caractéristiques, en y ajoutant des attributs (données) et/ou des méthodes (traitements) supplémentaires. La plupart du temps, il est même possible de suppléer une méthode de l’objet parent, en redéfinissant une méthode du même nom.

Prenons un exemple. L’objet Véhicule possède les attributs poids et vitesse, et la méthode avance. Les objets Voiture et Camion héritent de Véhicule, en ajoutant des attributs supplémentaires. Voici un petit diagramme UML :

Si on crée une instance de l’objet Voiture, on aura accès aux attributs poids, vitesse et nombre_passager, et aux méthodes avance et allume_autoradio.

Le polymorphisme : Tout les objets qui dérivent d’un même objet (avec différent sous-types) peuvent être manipulés comme s’ils étaient du type de l’objet parent − tant qu’on n’utilise que leur partie commune.

Si on reprend l’exemple précédent, toutes les instances des objets Voiture et Camion peuvent être manipulées comme si elles étaient du type Véhicule. Si on veut calculer leur poids total, il suffit d’additionner la somme des poids de tous les véhicules, sans avoir besoin de savoir s’il s’agit de voitures ou de camion.

Par contre, seuls les camions peuvent charger une cargaison.

Après l’héritage et le polymorphisme, on peut ajouter l’encapsulation et la notion de visibilité, qui permettent de déterminer les règles d’accès aux attributs et aux méthodes dans les objets et depuis l’extérieur des objets. Bien que ces notions soient très répandues, il existe des langages orientés objet qui ne les supportent pas (Javascript, Python).

Implémentation des types d’héritages

Il existe deux types d’héritage : l’héritage simple et l’héritage multiple.

L’avantage de l’héritage multiple, c’est qu’il permet − comme son nom l’indique − à un objet d’hériter de plusieurs objets à la fois. Parmi les langages qui le supportent, je ne connais vraiment que le C++ et le Perl,  sans oublier le Python (que je connais mal) ; il en existe d’autres, qui sont plutôt exotiques (Eiffel, OCaml, …).

La plupart des langages ne supportent que l’héritage simple. Enfin, c’est l’impression que j’ai, je ne peux pas vraiment l’étayer de manière formelle. Mais si on prend l’exemple du Java, du PHP, du Ruby… ça semble être la mode.

Toujours sans la moindre preuve, j’ai tendance à penser que l’héritage multiple est mis de côté pour simplifier le développement des langages. Je m’explique. Dans les années 80, il n’existait pas de compilateur C++. Bjarne Soustrup, son créateur, avait mis à disposition un programme qui traduisait du code C++ en code C, qui pouvait alors être compilé. J’ai été amené, durant mes études, à m’intéresser à ce type de translateur, et c’est très intéressant.

Ce qu’il faut comprendre, c’est qu’il est possible de mettre en œuvre des techniques de programmation orientée objet en C. Cela est notamment utilisé dans les bibliothèques graphiques comme (Motif, LessTif ou GTK+), pour gérer leurs éléments : une fenêtre ou un bouton sera géré simplement comme un widget générique par moments.
Je vais expliquer le principe de ce genre de techniques, sachant que cela peut aller bien plus loin que ce que je vais vous montrer.

Imaginons un code C qui contiennent une structure Véhicule, et la fonction avance :

typedef struct {
    int poids;
    short vitesse;
} vehicule_t;

void avance(vehicule_t *vehicule, short vitesse) {
    vehicule->vitesse = vitesse;
    printf("Le véhicule avance à %d km/h", vitesse);
}

La fonction avance prend en paramètre un pointeur sur le type correspondant au véhicule, et un seconde paramètre qui indique la vitesse à laquelle le véhicule se déplace. Elle se contente d’affecter la vitesse dans le champ prévu à cet effet dans la structure.

Si maintenant nous voulons créer l’objet Voiture, qui hérite de l’objet Véhicule, c’est très simple. La structure Voiture doit contenir la structure Véhicule :

typedef struct {
    vehicule_t parent;
    short nombre_passagers;
} voiture_t;

void allume_autoradio(voiture_t *voiture) {
    printf("Il y a %d mélomanes", voiture->nombre_passagers);
}

Pourquoi avoir placé la structure « parente » au début de la structure « fille » ? Tout simplement parce qu’ainsi, nous pouvons retrouver l’un ou l’autre à la même adresse en mémoire. En faisant un transtypage, on peut facilement se retrouver à manipuler l’un aussi bien que l’autre.
Voici un exemple de code, dans lequel on alloue la mémoire pour créer une voiture, mais on va ensuite la faire avancer en l’utilisant comme n’importe quel véhicule :

// on alloue la structure en mémoire, en l'initialisant à zéro
voiture_t *titine = memset(malloc(sizeof(voiture_t)),
                           0, sizeof(voiture_t));
// on allume l'auto-radio de la voiture
allume_autoradio(titine);
// on fait avancer la voiture comme n'importe quel véhicule
avance((vehicule_t*)titine, 60);

Voilà. C’est super simple, hein ? La seule chose, c’est qu’il faut faire attention à bien faire la conversion de type à chaque fois qu’on appelle une fonction qui attend un véhicule, ou lorsqu’on veut utiliser les champs qui sont dans la structure du véhicule. Mais quand on programme en C, cela semble naturel.

Par exemple, pour récupérer la vitesse de notre voiture, il faut faire :

((vehicule_t*)titine)->vitesse

Et notre objet Camion, qu’est-ce qu’il devient ?

typedef struct {
    vehicule_t parent;
    void* cargaison;
} camion_t;

void charge_cargaison(camion_t *camion, void *cargaison) {
    camion->cargaison = cargaison;
}

// on alloue la structure en mémoire, en l'initialisant à zéro
camion_t *mack = memset(malloc(sizeof(camion_t)),
                        0, sizeof(camion_t));
// on charge une cargaison dans le camion
charge_cargaison(mack, "Flash McQueen");
// on fait avancer le camion comme n'importe quel véhicule
avance((vehicule_t*)mack, 60);

Pas de problème, on voit bien que les camions et les voitures peuvent être manipulés comme des véhicules.

Surcharge de méthodes

Imaginons maintenant que l’on souhaite pouvoir faire de la surcharge de méthodes. Par exemple, on veut laisser la possibilité aux voitures et aux camions de redéfinir le code qui fait avancer le véhicule. Comment faire ?

En C, la réponse passe par les pointeurs de fonction. Le code devient plus complexe, mais rien qui ne devrait vous effrayer.

Pour le véhicule, on aurait quelque chose comme ça :

// définition de la structure
typedef struct vehicule_s {
    int poids;
    short vitesse;
    void (*avance)(struct vehicule_s*, short);
} vehicule_t;

// fonction avance()
void vehicule_avance(vehicule_t *vehicule, short vitesse) {
    vehicule->vitesse = vitesse;
    printf("Le véhicule avance à %d km/h", vitesse);
}
// fonction servant de "constructeur"
vehicule_t* vehicule_create() {
    // Allocation mémoire
    vehicule_t *vroum = memset(malloc(sizeof(vehicule_t)),
                                  0, sizeof(vehicule_t));
    // initialisation du pointeur de fonction
    vehicule->avance = vehicule_avance;
    // retour
    return (vroum);
}

Si on veut créer un véhicule et le faire avancer, c’est simple :

vehicule_t *vehicule = vehicule_create();
vehicule->avance(vehicule, 40);

Maintenant, faisons un camion ; lorsqu’on lui dit d’avancer, il va vérifier qu’on ne lui demande pas d’aller trop vite :

// définition de la structure
typedef struct {
    vehicule_t parent;
    void *cargaison;
} camion_t;

// fonction de chargement de la cargaison
void charge_cargaison(camion_t *camion, void *cargaison) {
    camion->cargaison = cargaison;
}
// fonction avance() spécifique aux camions
void camion_avance(vehicule_t *vehicule, short vitesse) {
    if (vitesse > 90)
        printf("Ce camion ne dépasse pas 90 km/h");
    else if (vitesse > 80 &&
             ((camion_t)*vehicule)->cargaison != NULL)
        printf("Ce camion chargé ne dépasse pas 80 km/h");
    else {
        vehicule->vitesse = vitesse;
        printf("Le camion avance à %d km/h", vitesse);
    }
}
// fonction servant de "constructeur"
camion_t *camion_create() {
    camion_t *camion = memset(malloc(sizeof(camion_t)),
                                           0, sizeof(camion_t));
    ((vehicule_t)camion)->avance = camion_avance;
    return (camion);
}

Maintenant, créons un camion, chargeons-lui une cargaison et faisons-le avancer :

camion_t *mack = camion_create();
charge_cargaison(mack, "Flash McQueen");
((vehicule_t*)mack)->avance((vehicule_t*)mack, 85);

Si vous avez bien suivi, ce code affichera le résultat suivant :

Ce camion chargé ne dépasse pas 80 km/h

Bref, tout cela fonctionne très bien. Je ne dis pas que c’est facile à lire, ni que la syntaxe est super évidente. Mais c’est efficace.

Pour aller plus loin

Si la programmation orientée objet en C vous intéresse, n’hésitez pas à me contacter. À une époque j’étais allé assez loin dans le concept, avec notamment un support des exceptions, et des macros qui simplifiaient énormément de choses.

Je peux aussi vous recommander les liens suivants :

• http://www.bolthole.com/OO-C-programming.html
• http://www.planetpdf.com/codecuts/pdfs/ooc.pdf (PDF de 221 pages)

C’est bien beau, et alors ?

Qu’est-ce qu’on peut retirer de tout ça ? Eh bien, l’héritage simple et le polymorphisme sont des notions franchement pas compliquées à implémenter dans un langage de bas niveau. Je pense que cela fait partie des raisons qui ont conduit à privilégier l’héritage simple au détriment de l’héritage multiple. On m’objectera qu’il s’agit d’un choix philosophique, que les concepteurs de langages ne veulent pas proposer l’héritage multiple ; mais j’en douterais toujours.

Ce qui m’énerve un peu, c’est que s’est rapidement rendu compte que l’héritage simple réduit tellement les possibilités de programmation, que des solutions de contournement ont été mises en place.

Ainsi sont arrivées les interfaces, qui servent à enrichir la définition d’un objet (et de partager ces définitions entre plusieurs objets) sans fournir d’implémentation.
Puis sont arrivés les mixins et les traits, qui fournissent pour leur part des implémentations qui peuvent être intégrées dans des objets.

N’importe quel développeur C++ vous dirait que ces notions sont inutiles à partir du moment où vous savez créer des classes abstraites.

Récemment, je donnais à ce propos deux exemples à un ami.

1. En Pascal, il y a une différence explicite entre les fonctions et les procédures. La différence, c’est simplement que les procédures ne retournent rien. En C et dans les langages qui en ont découlé, on n’a toujours que des fonctions, sauf que parfois elles ne retournent rien. C’est simple à comprendre, pas besoin de se retourner le cerveau.
2. Autre parallèle : Que je veuille ouvrir mon ordinateur ou démonter un meuble, j’utilise le même tournevis cruciforme. J’ai beau aimer les meubles Ikea (ils sont faciles et rapides à monter), ça m’énerve d’avoir à aller chercher un clé Allen pour les démonter. Le tournevis cruciforme, c’est l’héritage multiple, qui s’adapte à tous les usages. Les meubles Ikea, c’est le Java ou le Ruby ; ça peut accélérer le développement, mais il n’y a − à mon sens − aucune bonne raison d’imposer les clés Allen (les interfaces).

Pour ma part, c’est le cheminement que je trouve bancal : On essaye de justifier la simplification (l’héritage multiple, c’est mal), mais on se retrouve à refaire du pseudo-héritage multiple incomplet.
Mais parce que le nom est différent, ça devient acceptable ? Mixin, c’est plus hype ?

Il existe des techniques pour gérer le problème de l’héritage en diamant (la recherche profonde et la linéarisation C3), plusieurs langages les utilisent déjà, il n’y a donc pas de raison. En plus de ça, si vous avez un objet qui essaye d’implémenter deux interfaces qui possèdent une méthode dont le nom est identique, ça ne marchera pas mieux pour autant. Dans tous les cas, c’est au développeur de faire correctement sa modélisation.

Dans le prochain article, je vais tenter de rassembler mes idées sur ce que j’aimerais avoir comme langage. C’est pas gagné.

Ne me demandez pas pourquoi, mais ça me reprend en ce moment. Ça va sûrement repartir aussi vite que c’est venu, mais ça amène quand même quelques réflexions.

Je pense écrire 3 articles sur le sujet. Dans celui-ci, je vais lister les langages que je connais, histoire de situer un peu les choses. Dans le suivant, je parlerai un peu du modèle objet sous un angle inhabituel. Pour terminer, je « réfléchirai à haute voix » sur ce que j’attends d’un langage de programmation, et pourquoi je serai toujours un éternel insatisfait.

BASIC

C’est le premier langage que j’ai appris. Quand j’étais gamin, dans les années 80, il y avait deux émissions télévisées au Québec − Octo-puce et Octo-giciel − qui enseignaient entre autre à programmer en Basic. C’est comme ça que j’ai commencé à programmer sur papier en rêvant au jour où j’aurais un ordinateur. Environ 10 ans plus tard, j’ai passé un couple d’années à programmer en Visual Basic ; c’était avant de commencer mes études d’informatique, et je croyais savoir programmer…

Ce que j’en retiens, c’est que le Basic, le « vrai » (celui des Apple II et Commodore 64) était en fait complètement imbitable. Après coup, j’ai compris en partie pourquoi Dijkstra avait la dent si dure à son encontre.
Malgré tout, ses déclinaisons successives, depuis le QuickBasic, les STOS et AMOS, jusqu’au RealBasic et le VB.NET, en ont fait un langage moderne et utilisable.

Moderne et utilisable, mais je n’ai désormais strictement aucune envie de coder en Basic.

Javascript

Je me suis intéressé au Web dès 1995. Je me suis mis alors au HTML, et même à cette époque cela incitait à rapidement se pencher sur le Javascript. Les premières années, je n’en ai fait qu’un survol, mais j’ai fini par mettre en œuvre des techniques assez poussées (notamment concernant la programmation orientée objet en Javascript) qui me sont encore utiles aujourd’hui au quotidien. Je suis même passé par une phase de développement assez intensive à base de XUL, où tout le code est réalisé en Javascript.

À une époque, j’étais assez fan du Javascript. J’aimais sa simplicité et sa malléabilité. J’ai imaginé l’utiliser pour des usages très divers. Pour les développements « client lourd », après avoir développé en XUL, j’en suis un peu revenu ; comme expliqué dans un précédent article, je me suis fatigué de devoir taper 8 lignes de code illisible pour simplement lire le contenu d’un fichier. Pareil pour les développements côté serveur ; j’ai longtemps pensé que le Javascript combinait assez de qualités pour s’y montrer à son avantage ; cette idée va et vient, depuis le serveur de Netscape dans les années 90, jusqu’à  des projets comme CommonJS et Node.js.
J’espère que Mathieu ne m’en voudra pas, mais l’ensemble du langage me paraît maintenant trop bancal pour sortir de l’usage Web client qui est sa spécialité. Entre le modèle objet incomplet, la bibliothèque standard plutôt limitée et une évolution très lente (qui ne laisse pas apercevoir d’améliorations profondes à courte échéance), je préférerai toujours d’autres solutions.

C

Ce fut la grande révélation de ma vie. Ce que j’apprécie dans ce langage, c’est sa simplicité et sa limpidité. Quelques types scalaires, des structures (et des énumérations et des unions), des fonctions… et des pointeurs au milieu de tout ça. Difficile de faire plus évident. J’ai acquis une certaine expertise en C ; durant mes études j’ai fait du développement kernel (Linux et BSD), et par la suite j’ai travaillé dans le développement système et réseau. C’est formateur.

On entend souvent dire que le C n’est qu’un assembleur à peine amélioré… C’est tellement faux ! Par contre, ce qui est certain, c’est qu’il est quasi-impossible de faire des exécutables plus rapides et plus petits que ceux écrits en C. Bon, il n’est évidemment pas exempt de défauts, mais qui sont inhérents à ce qu’il est intrinsèquement. Si vous savez ce que vous faites, le C est un outil redoutable ; par contre, si vous vous permettez des approximations, vous ne vous en relèverez pas.

Aujourd’hui, je ne code plus du tout en C, au profit du PHP (j’en parle juste après). Cela m’ennuie un peu, le manque de pratique émousse le niveau d’expertise que j’avais ; mais d’un autre côté, si on peut coder plus vite sans avoir besoin des performances maximales…

Perl

J’ai appris les bases du Perl durant mes études d’informatique. Comme disait mon professeur d’administration système (Marc Espie, l’un des principaux contributeurs à OpenBSD), “il faut savoir laisser son compilateur au placard quand on a juste besoin d’un petit script”. Plus tard, j’ai travaillé pendant 4 ans dans une entreprise où le Perl était le principal langage de développement ; j’y ai considérablement amélioré ma connaissance du langage.

J’ai apprécié ce langage, qui est particulièrement souple et puissant. Il intègre nativement les listes, les tableaux associatifs et les expressions régulières, ce qui est très pratique au quotidien. Le CPAN est un fantastique outil centralisé pour trouver des bibliothèques, tellement complet qu’il est difficile à mettre en défaut.

Par contre, j’ai aussi été profondément gêné par les bizarreries du langage. La syntaxe qui autorise d’écrire certaines choses « à l’envers ». La notion de référence qui casse les noix quand on manipule des types scalaires (c’est comme des pointeurs… mais ça n’a rien à voir). Les variables magiques (on aime ou on déteste, moi je ne suis pas fan). Le modèle objet est incomplet bien que largement utilisable. Mais surtout, c’est un langage qui incite presque à faire du code illisible, tellement il permet d’écrire les choses de plusieurs manières différentes ; si vous n’êtes pas vigilant, vous finissez par privilégier les écritures les plus denses mais les moins maintenables.

PHP

J’ai commencé à utiliser le PHP dans sa version 3 en 1999. Pendant plusieurs années j’alternais mes développement serveur entre le PHP et le C. J’ai fini par m’habituer aux qualités du PHP, sa simplicité et sa bibliothèque très fournie. Sa syntaxe très inspirée de celles du C et du Perl me convenait très bien, et j’ai fini par me rendre compte que recompiler un exécutable à chaque modification d’un site web, c’est quand même pénible.

J’ai suivi les évolutions successives du langage, à travers ses versions majeures (4, 5, 5.3) et les différentes améliorations qu’elles ont apportées. J’apprécie le PHP pour sa souplesse et son équilibre entre contrainte et permissivité. Syntaxiquement, son intégration des tableaux associatifs est particulièrement réussie, et son modèle objet est complet depuis 2004 (version 5).

La quasi-totalité de mes développements se font désormais en PHP. J’ai réalisé quelques projets assez pointus avec ce langage (FineFS, Temma), et je suis très heureux de profiter des facilités qu’il offre.

C++

J’ai fait du C++ à l’école, je l’ai même utilisé pour développer un projet sous licence libre (Headerbrowser). C’est un langage très puissant, qui comble la plupart des lacunes du C, tout en gardant une syntaxe très similaire (au contraire de l’ObjectiveC, par exemple).

Malgré tout, je me suis toujours senti « le cul entre deux chaises » avec le C++. Si j’ai un grand besoin de performance ou de portabilité, j’aurai tendance à choisir le C pour sa simplicité. Si je cherche un langage de haut niveau, je prendrais le PHP pour son typage faible et sa gestion dynamique de la mémoire. Certaines fonctionnalités du C++ complexifient la syntaxe à l’extrême. Nul doute que cela ne soit qu’une question d’habitude, mais je n’arrive pas à m’y faire.

J’ai parfois hésité à écrire du code C++ comme si je codais en C, en utilisant seulement les fonctionnalités qui m’intéressaient (les objets et les exceptions, par exemple). Mais j’ai lu tellement de choses disant que c’est une mauvaise idée… Je vais peut-être revenir là-dessus, parce que les donneurs de leçon qui disent que tel ou tel truc, « il faut le faire à fond ou pas du tout », j’ai fini par ne plus les écouter.

Java

J’ai appris le Java durant mes études d’informatique. Pour quelqu’un qui s’orientait vers le développement système, ce langage ne jouissait pas d’une bonne réputation.
Je l’ai au final très peu utilisé en dehors du cadre académique. Dans toute ma carrière, je n’ai qu’une expérience d’un an en JEE.

J’ai trouvé que le Java était un plutôt bon langage. Sa grande force vient de sa bibliothèque standard d’objets, qui est très complète et très proprement structurée. J’ai par contre connu des problèmes avec l’environnement général, pas évident à mettre en place au premier abord.

Dans le cadre du développement Web, j’ai trouvé le JEE d’une lourdeur incroyable. L’ensemble des technologies impliquées est vaste et complexe. À mon sens, inutilement vaste et complexe. Beaucoup de choses semblent séduisantes d’un point de vue théorique, mais leur utilisation est malaisée, ce qui allonge les temps de développement et les coûts associés.

Au final, j’ai un peu les mêmes griefs que pour le C++. Pour un langage qui se veut de haut niveau, il lui manque beaucoup de facilités d’écriture, tout en manquant de clarté sur plein de points. S’il fallait faire un match en C++ et Java, je les mettrais ex æquo. Le Java me semble plus clair, et son API standard est ultra-complète ; par contre, le C++ est plus dans mes habitudes par son absence de machine virtuelle et sa compatibilité avec le C (aussi bien le code que les bibliothèques compilées).

Fortran

J’en parle juste pour déconner. J’ai fait un peu de Fortran quand j’étais en fac de biologie. Je n’en garde presque aucun souvenir. Il n’empêche que ce langage a continué à évoluer, qu’il est toujours beaucoup utilisé dans la communauté scientifique, et que c’est l’un des langages les plus facilement optimisable sur des architectures réparties (il n’y avait pas d’allocation dynamique de la mémoire jusqu’au Fortran90).

Pascal

Là aussi, j’en parle juste pour le fun. Quand j’étais petit et que je commençais à m’intéresser à l’informatique, un ami informaticien qui avait fait le MIT m’a donné un livre traitant de la programmation en Pascal. Je n’y ai pas compris grand chose sur le moment. Bien plus tard, alors étudiant en informatique, je me souviens avoir aidé des amis qui étaient en prépa, et qui bûchaient sur de la programmation en Pascal. J’ai pu comprendre sans problème les bases du langage en quelques secondes. Et j’ai compris de quoi mon prof de C parlait, lorsqu’il évoquait les différences entre les langages créés par les mathématiciens suisses et ceux créés par les hippies américains. Niveau syntaxe et clarté, pas de soucis, je préfère les baba-cools.

Lisp et OCaml

Oui, je continue avec les trucs à la con. Juste pour la petite histoire, j’ai eu à développer un interpréteur de Lisp durant mes études. La syntaxe est tellement simple que ce type d’interpréteur n’est vraiment pas très compliqué à coder. Bon, de là à vouloir coder en Lisp au quotidien, c’est une autre paire de manches. À une époque, c’était une idée tout à fait valable quand on voulait intégrer un langage dans un logiciel, pour permettre d’écrire des extensions (comme dans Emacs, par exemple).

L’OCaml, je l’ai étudié durant mes études. Avec le Lisp et l’OCaml, je me suis vite rendu compte que j’avais beaucoup de mal à me faire aux langage fonctionnels (je sais, OCaml peut être considéré comme à la fois fonctionnel et impératif, mais zut). J’ai sûrement été trop marqué par les langages procéduraux, mais on peut quand même remarquer que les langages fonctionnels sont globalement l’apanage des chercheurs et des mathématiciens, alors que les langages procéduraux sont utilisés par « ceux qui veulent faire du vrai code » ; je forcis le trait, mais il y a un peu de vrai là-dedans.

Et pourtant, on peut voir l’héritage des langages fonctionnels se cacher dans le Javascript, ou dans des notions comme le map-reduce. Il est important de connaître le principe, même sans l’utiliser au quotidien.

Je vais vous expliquer point par point comment j’ai procédé, depuis la génération des certificats « wildcard » jusqu’à la configuration Apache.

Pré-requis et informations préalables

Considérons que nous avons déjà un serveur Linux avec Apache qui tourne dessus. Dans mon cas, j’ai travaillé sur une distribution Ubuntu 11.04, mais j’imagine que les mêmes étapes s’appliqueront à l’identique sur Fedora, Suse, ou autres.

Les certificats SSL représentent un business important. Des entreprises se font beaucoup d’argent en vendant très cher une prestation technique qui est automatisée. Chaque option supplémentaire est facturée à prix d’or. Suivant l’entreprise qui fournit le certificat, les tarifs peuvent aller de 12$ à 150$ pour sécuriser un unique nom de domaine, et les certificats wildcard − qui permettent de sécuriser tous les sous-domaines d’un domaine donné − peuvent atteindre les 500$.
Et encore, si vous allez vers un grand nom comme VeriSign, vous dépassez allègrement le millier de dollars. Par an !

J’ai donc choisi de me tourner vers StartSSL. Cette autorité de certification fournit gratuitement des certificats de classe 1 (sans vérification d’identité). Pour les certificats de classe 2 − intégrant les wildcard − ils facturent uniquement l’opération humaine de vérification d’identité. On peut ensuite générer autant de certificats que nécessaire, c’est gratuit ; il suffit d’abord de prouver que l’on est propriétaire des domaines ciblés (la procédure est automatisée, je vais revenir dessus).
Ce fonctionnement est au final complètement logique. L’ensemble de la chaîne est automatisé et ne génère aucun coût pour StartSSL, à part la vérification d’identité qui est manuelle. Cette opération est facturée 60$ (47,80 € au cours d’hier) et est valable pendant deux ans.

La génération de certificat

Je me suis largement inspiré d’une documentation trouvée sur le site Biapy. La procédure est au finale assez simple.

Si OpenSSL n’est pas installé, c’est le moment de le faire :

$> apt-get install openssl

Idem pour l’activation du module SSL d’Apache :

$> a2enmod ssl

Imaginons que l’on possède le nom de domaine xyz.com, et que l’on souhaite en sécuriser tous les sous-domaine grâce à un certificat wildcard *.xyz.com.

Commençons par créer la clé privée :

$> openssl genrsa -out /etc/ssl/private/xyz.com.key 2048
$> chmod 400 /etc/ssl/private/xyz.com.key

On va ensuite créer le CSR (certificate signing request), qui sera transmis par la suite à StartSSL pour récupérer la clé publique :

$> mkdir /etc/ssl/reqs
$> openssl req -new -key /etc/ssl/private/xyz.com.key \
   -out /etc/ssl/reqs/xyz.com.csr

Le programme va demander plusieurs informations :

• Notre pays, sur deux lettres (“FR” dans mon cas).
• Le nom de notre province, état ou région (“Ile-de-France” pour moi).
• Le nom de notre ville (“Paris” si vous êtes parisien).
• Le nom de notre entreprise ou de votre organisation.
• Le nom de notre unité organisationnelle (moi je laisse vide).
• Le “Common Name”, c’est-à-dire le nom de domaine à sécuriser (“*.xyz.com”, attention à bien mettre l’étoile au début quand on crée un wildcard).
• Notre adresse email.
• Un mot de passe pour sécuriser le certificat. Il faut le laisser vide, sinon StartSSL ne saura pas générer la clé publique.

Si on regarde le fichier /etc/ssl/reqs/xyz.com.csr, il devrait contenir quelque chose comme ça :

-----BEGIN CERTIFICATE REQUEST-----
... (plusieurs lignes encodées en base64) ...
-----END CERTIFICATE REQUEST-----

Il faut le garder sous le coude, nous devrons ensuite le copier-coller dans l’interface de StartSSL.

La vérification d’identité

La procédure d’inscription sur le site StartSSL peut sembler un peu compliquée. Le site va générer un certificat qui va vous identifier personnellement. Ce certificat s’installe automatiquement sur votre navigateur (cela fonctionne avec Firefox mais pas avec Chrome) ; si vous voulez utiliser un autre ordinateur, il faudra exporter le certificat sur le navigateur d’origine, et l’importer sur le navigateur de destination.

Ce certificat se contente de vous identifier. Pour le générer, il faut suivre la procédure du site, qui inclut la vérification de votre adresse email.

Une fois que l’on est connecté et identifié, on peut utiliser le « Validation Wizard » pour demander à valider notre identité en cliquant sur « Personal Identity Validation ». Cette validation nécessite que l’on scanne  − ou que l’on prenne en photo − notre passeport (couverture, première page, page avec nom et photo) et une autre pièce d’identité comme la carte d’identité ou le permis de conduire (recto et verso). L’interface permet d’envoyer les fichiers correspondants. Dans la foulée, j’ai reçu un email me demandant une copie d’une facture récente de téléphone fixe ou mobile. Je me suis exécuté, et dans les minutes qui ont suivies j’ai reçu un coup de téléphone très aimable (en anglais) ; pour vérifier mon identité, Eddy m’a demandé ma date et mon lieu de naissance.

En parallèle de ça, il faut aller dans l’onglet « Tool Box » de l’interface, pour enregistrer une carte bancaire ou un compte Paypal. Si vous choisissez Paypal, vous recevrez rapidement une demande de paiement correspondant aux 60$ facturés pour la vérification d’identité ; si vous choisissez la carte bancaire, le prélèvement se fera automatiquement.

Notre identité est vérifiée, maintenant il faut prouver que l’on est bien propriétaire du domaine xyz.com. Pour cela, il faut retourner dans l’onglet « Validation Wizard », en choisissant cette fois l’option « Domain Name Validation ». Après avoir saisi le nom xyz.com, on nous propose de choisir une adresse email à laquelle sera envoyé l’email de validation (postmaster@xyz.com, hostmaster@xyz.com ou webmaster@xyz.com). En menant la procédure à son terme, StartSSL enregistrera que le domaine nous appartient bien.

Clé publique et certificat racine

Nous pouvons maintenant générer la clé publique dont nous avons besoin pour sécuriser notre site. Il faut aller dans l’onglet « Certificates Wizard », et choisir la cible « Web Server SSL/TLS Certificate ». La première étape doit être passée (bouton « Skip »). À l’étape suivante, il faut copier-coller le contenu du fichier /etc/ssl/reqs/xyz.com.csr. Ensuite, il faut ajouter le sous-domaine « * » à la liste de sous-domaines inclus dans le certificat (la liste est vide, il suffit simplement d’insérer l’étoile dans le champ texte et de passer à l’étape suivante). Après quelques dizaines de secondes, on reçoit un email indiquant que le certificat est disponible. Pour cela, il faut aller dans l’onglet « Tool Box », puis dans « Retrieve Certificate ». Il faut sélectionner le certificat qui nous intéresse, puis le copier-copier dans le fichier /etc/ssl/certificates/xyz.com.crt (pensez à créer le répertoire d’abord).

Pour que notre certificat fonctionne, nous devons récupérer sur notre serveur deux fichiers supplémentaires : le certificat racine et le certificat intermédiaire.

$> mkdir /etc/ssl/roots /etc/ssl/chains
$> wget https://www.startssl.com/certs/ca.pem \
   -O /etc/ssl/roots/xyz.com-root.ca.pem
$> wget https://www.startssl.com/certs/sub.class2.server.ca.pem \
   -O /etc/ssl/chains/xyz.com.ca.pem

Configuration Apache

Ça y est, nous avons récupéré tous les fichiers nécessaires. Ouf. Nous allons pouvoir configurer nos sites. StartSSL propose une documentation succincte pour la plupart des serveurs HTTP, je me suis inspiré de celle pour Apache.

Nous allons créer deux « virtual hosts » dans Apache. L’un répondra aux requêtes HTTPS, l’autre répondra aux requêtes HTTP et renverra vers l’équivalent sécurisé.

# sites sécurisés
<VirtualHost *:443>
    ServerName      www.xyz.com
    ServerAlias     *.xyz.com
    DocumentRoot    /path/to/site
    SSLEngine       on
    SSLProtocol     all -SSLv2
    SSLCipherSuite  ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
    SSLCertificateFile       /etc/ssl/certificates/xyz.com.crt
    SSLCertificateKeyFile    /etc/ssl/private/xyz.com.key
    SSLCertificateChainFile  /etc/ssl/chains/xyz.ca.pem
    SSLCACertificateFile     /etc/ssl/roots/xyz.com-root.ca.pem
    SetEnvIf    User-Agent   ".*MSIE.*"   nokeepalive \
        ssl-unclean-shutdown
    # ... la suite de la configuration habituelle du virtual host
</VirtualHost>

# sites non sécurisés
<VirtualHost *:80>
    ServerName     www.xyz.com
    ServerAlias    *.xyz.com
    RewriteEngine  On
    RewriteRule    ^(.*)$   https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Suivant la configuration existante, vous aurez peut-être besoin des directives suivantes (à placer dans le fichier précédent ou dans le fichier contenant le virtual host par défaut) :

NameVirtualHost *:80
NameVirtualHost *:443

On vérifie la configuration et on redémarre Apache :

$> apache2ctl configtest
$> apache2ctl restart

Il faut être attentif à ce qu’il se passe dans les fichiers de log, notamment dans /var/log/apache2/error.log

Si tout s’est bien passé, vous pourrez vous connecter à l’URL https://bidule.xyz.com sans problème. Et en allant sur http://machin.xyz.com/truc vous devriez être automatiquement redirigé vers https://machin.xyz.com/truc

Plutôt que de noyer l’utilisateur sous des options qui l’obligeront à choisir la manière dont il souhaite manipuler l’outil, il est préférable d’analyser les choses finement pour proposer quelque chose d’exploitable immédiatement et sans effort.

Il y avait eu un certain nombre de commentaires intéressants à l’époque, dont quelques-uns qui remettaient en question cette vision des choses. De manière assez amusante, je sais que certains de ces commentateurs sont par ailleurs dithyrambiques sur la manière dont Apple mène ses designs, justement en restreignant les options et en s’attachant à proposer les meilleurs choix par défaut…

Bref, je viens de tomber sur un lien très intéressant :
http://www.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/

L’histoire est édifiante. Afin de savoir si les utilisateurs modifient les options de leurs logiciels, ils ont demandé à des utilisateurs de Word d’envoyer le fichier de configuration présent sur leur machine. Plusieurs centaines ont répondu.
Résultat : 95% des utilisateurs utilisaient les réglages par défaut.

On pourrait penser que cela ne fait que montrer à quel point Microsoft avait bien fait son travail, et avait réussi à proposer un outil qui soit parfaitement fonctionnel pour le plus grand nombre. Et pourtant c’est complètement l’inverse !
À cette époque, l’auto-enregistrement était désactivé par défaut. Si votre ordinateur plantait, vous perdiez tout votre travail, à moins que vous n’ayez activé cette option. Cette fonctionnalité était déjà perçue comme quelque chose de particulièrement utile. Malgré cela, l’écrasante majorité des utilisateurs ne faisaient pas l’effort de contraindre le logiciel à faire ce qu’ils voulaient.

Pourquoi ? Parce qu’ils se disaient que Microsoft étant expert en la matière (ce qui semble normal, vu que c’est Microsoft qui édite le logiciel), il devait y avoir une bonne raison pour que cette fonctionnalité soit désactivée par défaut. Le problème n’était pas que les utilisateurs ne connaissaient pas l’existence de l’option ; ils expliquaient ne simplement pas vouloir y toucher.

On pourra m’objecter que cette étude doit dater de plus de 10 ans. Quand bien même, je pense que le comportement des utilisateurs n’a pas changé d’un iota à ce niveau. Et on ne peut pas dire que Word soit un logiciel difficile à prendre en main ; ce n’est pas un CRM ou un modeleur 3D.

Je ne le martèlerai donc jamais assez : Faites des choix à la place de vos utilisateurs.
Si vous avez peur de vous tromper, commencez par vous mettre à leur place ; utilisez votre produit, apprenez à le connaître ; comparez avec les produits concurrents, faites le tri entre ce qui fonctionne quasiment tout le temps et la cerise sur le gâteau qui ne sera utilisée que par les power-users.

Cela se tiendra dans les locaux de l’école au Kremlin Bicêtre, le vendredi 13 janvier, de 14h00 à 15h30.

Cette conférence ne sera ouverte qu’aux étudiants de l’école. Venez nombreux !

Bref. Suite à mon dernier article sur le sujet, l’un de mes développeurs m’a fait une remarque très pertinente, à laquelle j’ai répondu en expliquant au passage quelques notions concernant le travail distribué.

La situation

Je replace rapidement le contexte : Nous développons un petit programme de sauvegarde, constitué d’un serveur et de « workers ». Le serveur envoie aux workers des ordres, pour leur indiquer les machines à sauvegarder. Grâce aux fonctionnalités de load-balancing intégrées à ZeroMQ, le serveur n’a pas à se soucier de «qui fait quoi» ; il se contente d’envoyer les ordres, en se disant que les workers les recevront et les traiteront.

Le seul petit soucis est qu’il fallait prendre en compte le temps de création des workers, et le temps qu’ils mettent à se connecter au serveur. La solution que j’ai présenté est d’ajouter un canal de communication supplémentaire, qui permet aux workers d’indiquer au serveur qu’ils sont prêts.

Voici le schéma de l’infrastructure finale :

Les workers font du PUSH vers le serveur, pour lui confirmer leur disponibilité. Le serveur fait du PULL pour recevoir ces confirmations, puis fait du PUSH pour envoyer ses ordres, qui sont répartis entre les workers. Les workers font du PULL pour recevoir les ordres et les traiter.

La solution alternative

Mon développeur m’a alors demandé : « Mais pourquoi les workers ne feraient pas du REQ pour demander au serveur le prochain ordre à exécuter, qu’il enverrait par REP ? »

Pour rappel, le REQ/REP (request/response) est l’un des 3 types de communications supportées par ZeroMQ. À chaque requête effectuée (du côté de la socket REQ), une réponse doit obligatoirement être envoyée (côté REP).

Effectivement, le schéma de l’architecture devient plus simple :

En faisant ainsi, on se soustrait la partie « initialisation », pendant laquelle les workers indiquent au serveur qu’ils sont connectés et disponibles. Par contre, tout le reste du serveur se complexifie.

Dans un tel fonctionnement, les workers vont se connecter au serveur, pour lui demander «Eh, qu’est-ce que je dois faire ?». Le serveur devra garder en mémoire une liste des machines à sauvegarder ; à chaque fois qu’un worker fera une demande, il devra dépiler un nom de machine, pour l’envoyer dans sa réponse au worker.

Cela n’a rien de bien méchant, nous sommes d’accord. Juste une liste supplémentaire à gérer. Mais si on veut gérer une remontée d’information (que les workers préviennent le serveur quand ils ont terminé une tâche), il faudra là encore ajouter un peu de code supplémentaire.

Si on compare avec le fonctionnement précédent, on s’aperçoit d’une chose : En simplifiant l’architecture réseau, on complexifie le code applicatif ; en complexifiant légèrement l’architecture réseau, on simplifie le code applicatif.

Toute la magie de ZeroMQ est là. Ajouter une socket ZMQ supplémentaire ? C’est seulement deux lignes de code en plus !
Il est donc plus simple de faire reposer la complexité sur ZeroMQ, le code n’en est que plus simple à comprendre, plus rapide à écrire, plus facile à maintenir.

Une file de message

Imaginons maintenant que nous voulions utiliser ZeroMQ pour mettre en place une file de message.

Je vais prendre un exemple concret. Dans mon entreprise, nous devons indexer des contenus, pour permettre leur recherche textuelle. Cette étape est relativement longue et coûteuse en CPU, elle ne peut donc pas être faite par les processus qui communiquent avec les navigateurs web au moment où les contenus sont créés.
Les contenus sont donc enregistrés sans être indexés, et des messages sont ajoutés à une file de messages pour indiquer les contenus qui doivent être indexés.
Sur une machine dédiée, un programme est exécuté à intervalles réguliers. Il consulte la file de messages pour savoir si de nouveaux contenus doivent être indexés.

La file de messages que nous utilisons est très frustre, basée sur une table en base de données. L’extension FineMessageQueue disponible sur le site de notre framework Temma en reprend le principe.

Si nous voulions la remplacer par une file de messages réalisée avec ZeroMQ, comment nous y prendrions-nous ?

Pour commencer, nous devrions écrire un programme qui fera office de « serveur » (mettons de côté toute notion de redondance ; pour nous simplifier la vie, on va faire une file centralisée).
D’un côté, le serveur recevra des messages, qu’il ajoutera à sa file.
La file de message pourrait être stockée uniquement en mémoire, mais c’est un peu risqué. Partons du principe que les messages sont stockés sur disque ou dans une base de données.
De l’autre côté, le serveur va envoyer ses messages à des workers qui sont là pour ça et qui attendent qu’on leur demande de travailler.

Avec ce type d’architecture, il paraît évident que la communication entre le serveur et les workers ne va pas se faire par du REQ/REP. Si on imagine que les workers fassent un REQ pour savoir ce qu’ils ont à faire, et que la file de messages est vide, que se passe-t-il ? Le serveur répond qu’il n’y a rien à faire ; donc le worker ne « fait rien ». Et après ? Il redemande au serveur ce qu’il a à faire. On tombe vite dans la boucle qui commence énormément de CPU pour rien.

Il est donc bien plus logique que ce soit le serveur qui informe les workers du travail qu’ils ont à faire. C’est un peu différent de la vision classique du client-serveur, mais c’est beaucoup plus efficace, et ZeroMQ permet d’y arriver très simplement.

Une architecture complète

Dans l’idée d’une telle file de messages, on considérera que les workers « sont là ». Ce n’est donc pas le serveur de file de messages qui va les démarrer. Cela implique potentiellement d’avoir des mécanismes dédiés à la gestion des workers : un démon se charge de lancer de nouveaux workers quand il n’y en a pas assez (dans une limite maximale définie), et les tue quand il y en a trop d’inactifs (dans une limite minimale définie).

Idéalement, le serveur de file de messages doit être capable de relancer une tâche qui n’a pas été déclarée comme terminée, après un certain délai. Ce qui veut dire que les workers doivent informer le serveur qu’ils ont terminé telle ou telle tâche.

Pour joindre l’utile à l’agréable (comprendre : pour faire un peu de R&D, monter mes équipes en compétence sur des projets intéressants pour l’entreprise), j’ai demandé à mon administrateur système de sortir de sa «zone de confort», et de coder un petit projet en PHP utilisant ZeroMQ.

Le projet

L’idée est de mettre en place un serveur de sauvegarde centralisé. Ce serveur contient un gros disque dur (en fait, plusieurs, mais j’y reviendrai), sur lequel est stocké une copie de tous les fichiers qui doivent être sauvegardés sur les postes de travail. Tous les jours, ce serveur doit lancer une série de rsync pour synchroniser le disque dur local avec les machines à sauvegarder. C’est l’étape de “backup”.

Par la suite, nous recopions les données sur un second disque dur. Chaque dimanche, une copie complète est effectuée, alors que tous les autres jours de la semaine on se contente de faire une copie incrémentale pour ajouter les nouveaux fichiers. C’est l’étape d’“archivage”.

(oui, je sais, on pourrait utiliser un logiciel de sauvegarde comme Amanda, mais l’aspect R&D serait vachement moins évident, hein)

La réalisation

Tout cela n’a rien de bien sorcier. On pourrait faire un simple programme, lancé par crontab, qui lanceraient séquentiellement un rsync sur chaque poste de travail, puis qui effectuerait séquentiellement l’archivage de chaque machine. Le truc, c’est qu’en faisant ainsi, on perdrait un temps fou. De nos jours, on a des processeurs multi-cœurs, des réseaux gigabit ou plus… Ce serait quand même idiot de ne pas mener plusieurs sauvegardes en parallèle.

La première possibilité qu’on pourrait envisager serait simplement de lancer autant de programmes qu’il y a de machines à sauvegarder. Mais ce serait peut-être un peu violent et difficile à surveiller efficacement. Et plus le nombre de machine à sauvegarder augmente, moins cette méthode serait efficace.

On a donc décidé de mettre en place une architecture comprenant  un serveur qui coordonne le travail de plusieurs « workers », des programmes qui effectuent le boulot réel. L’idée est de démarrer un nombre fini de workers, ce qui détermine le nombre de tâches effectuées simultanément, et de leur indiquer les machines à sauvegarder.
ZeroMQ excelle dans ce genre de situation. Les workers vont se connecter au serveur, et attendre qu’il leur envoie des ordres. Le serveur, lui se contentera d’envoyer des ordres séquentiels sur sa socket ; ZeroMQ se chargera de les délivrer en les répartissant aux différents clients (c’est la fonctionnalité de load-balancing intégrée à ZeroMQ).

Petit rappel : À la base, ZeroMQ fournit 3 types de communication. Le REQ/REP sert à faire du client-serveur classique (on fait une requête, on reçoit une réponse) ; le PUSH/PULL pour envoyer des données à sens unique ; le PUB/SUB pour envoyer des données à tous ceux qui s’y sont abonnés. La principale différence entre les deux derniers est que le PUB envoie ses paquets de données − en même temps − à tous les SUB qui y sont connectés, alors que le PUSH envoie ses données successivement à chacun des PULL connectés − l’un après l’autre.

Le problème

Mon admin sys. est revenu vers moi avec un comportement étrange. Quelque soit le nombre de workers, un seul d’entre eux recevait tous les paquets de données. Aïe.

Voici, en très simplifié, le code du serveur :

// création de la socket ZMQ
$ctx = new ZMQContext();
$socket = new ZMQSocket($ctx, ZMQ::SOCKET_PUSH);
$socket->bind('tcp://*:1234');

// création des workers en tâche de fond
for ($i = 0; $i < $nbrWorkers; $i++)
    exec('/path/to/worker.php >> /path/to/log 2>&1 &');

// envoi des ordres de sauvegarde
foreach ($machines as $machine)
    $socket->send($machine);

// envoi des ordres de "suicide"
for ($i = 0; $i < $nbrWorkers; $i++)
    $socket->send('KILL');

Le code du client (là encore, très simplifié) :

// création de la socket ZMQ
$ctx = new ZMQContext();
$socket = new ZMQSocket($ctx, ZMQ::SOCKET_PULL);
$socket->connect('tcp://localhost:1234');

// traitement
while (true) {
    // réception des données
    $msg = $socket->recv();

    // gestion du "suicide"
    if ($msg == 'KILL')
        exit(0);

    // sauvegarde de la machine demandée
    backup($msg);
}

Reprenons le déroulement. Le serveur commence par créer sa socket ZMQ. Puis il crée des sous-processus pour instancier autant de workers que prévu. Dans la foulée, il envoie les noms des machines à sauvegarder. Puis il envoie autant d’ordres de « suicide » qu’il a créé de workers (pour leur demander de s’arrêter une fois que le travail est terminé).

Imaginons que nous avons cinq machines à sauvegarder (nommées A, B, C, D et E), et trois workers (nommés Prime, Seconde et Tierce).
Le serveur envoie les messages dans l’ordre suivant : A, B, C, D, E, KILL, KILL, KILL.

On peut imaginer que les réceptions se fassent de la sorte :

• A => Prime
• B => Seconde
• C => Tierce
• D => Prime
• E => Seconde
• KILL => Tierce
• KILL => Prime
• KILL => Seconde

Tout irait bien ; on peut voir que toutes les machines seraient sauvegardées en parallélisant les traitements (jusqu’à 3 sauvegardes simultanées), puis que chaque worker recevrait bien une instruction lui demandant de s’arrêter. Et pourtant, ce n’est pas le cas. L’un des workers reçoit tous les messages, et les deux autres rien du tout.

L’explication

ZeroMQ est une bibliothèque dont l’exécution est très rapide. Dans le code présenté ci-dessus, la partie la plus lente de l’exécution tient dans la connexion réseau ; le moment où les socket BSD entrent en jeu pour connecter un programme à un autre.

En fait, au moment où le premier worker se connecte au serveur, ZeroMQ a déjà dans sa file d’attente interne tous les messages qui doivent être envoyés. Donc, dès que cette première connexion est établie, il lui balance tout. Ce qui est normal, car à ce moment-là il n’y a pas encore d’autre connexion avec laquelle faire le load-balancing.

La solution est donc d’attendre que toutes les connexions soient effectuées avant d’envoyer les données. Il y a deux manières d’y arriver ; l’une est rapide mais crado, l’autre est bien plus propre mais un poil plus complexe.

Méthode quick and dirty

Le plus simple, pour bien comprendre où se situait le problème, est d’ajouter une temporisation entre la création des workers et l’envoi des données. Cela afin de laisser aux workers le temps de se connecter au serveur et d’être « enregistrés » dans le load-balancing.

Voici le code du serveur adapté :

// création de la socket ZMQ
$ctx = new ZMQContext();
$socket = new ZMQSocket($ctx, ZMQ::SOCKET_PUSH);
$socket->bind('tcp://*:1234');

// création des workers en tâche de fond
for ($i = 0; $i < $nbrWorkers; $i++)
    exec('/path/to/worker.php >> /path/to/log 2>&1 &');

// temporisation de 3 secondes
sleep(3);

// envoi des ordres de sauvegarde
foreach ($machines as $machine)
    $socket->send($machine);

// envoi des ordres de "suicide"
for ($i = 0; $i < $nbrWorkers; $i++)
    $socket->send('KILL');

Ah oui, je sais, c’est sale. Mais j’avais prévenu, et ça marche. Par contre, si on augmente le nombre de workers à lancer, on risque d’avoir une temporisation insuffisante. Et si la machine est spécialement lente à ce moment-là, on risque encore de rater des workers.

Méthode propre

Pour bien faire les choses, il faut que les workers envoient un message au serveur, pour lui signifier qu’ils sont prêts à recevoir des données. Ainsi, le serveur n’enverra ses ordres qu’après que tous les workers se soient déclarés.

Comme bien souvent avec ZeroMQ, cela impose d’ouvrir un canal de communication supplémentaire. Mais, comme toujours avec ZeroMQ, il ne faut pas avoir peur de le faire, car c’est simple et rapide à mettre en œuvre.

Cela donne donc une infrastructure de la forme suivante :

Le serveur doit donc ouvrir deux sockets, l’une qui lui servira à envoyer ses ordres aux workers, l’autre pour recevoir les messages envoyés par ceux-ci.
Cette seconde socket est d’ailleurs bien utile : elle permettra de remonter d’autres types d’informations, par exemple pour avertir le serveur à chaque fois qu’une sauvegarde est terminée.

Cela nous amène à un serveur qui ressemble à ceci :

// création des sockets ZMQ
$ctx = new ZMQContext();
$output = new ZMQSocket($ctx, ZMQ::SOCKET_PUSH);
$output->bind('tcp://*:1234');
$input = new ZMQSocket($ctx, ZMQ::SOCKET_PULL);
$input->bind('tcp://*:1235');

// création des workers en tâche de fond
for ($i = 0; $i < $nbrWorkers; $i++)
    exec('/path/to/worker.php >> /path/to/log 2>&1 &');

// réception des confirmations des workers
for ($i = 0; $i < $nbrWorkers; $i++)
    $input->recv();

// envoi des ordres de sauvegarde
foreach ($machines as $machine)
    $output->send($machine);

// envoi des ordres de "suicide"
for $i = 0; $i < $nbrWorkers; $i++)
    $output->send('KILL');

Le code du client :

// création des sockets ZMQ
$ctx = new ZMQContext();
$input = new ZMQSocket($ctx, ZMQ::SOCKET_PULL);
$input->connect('tcp://localhost:1234');
$output = new ZMQSocket($ctx, ZMQ::SOCKET_PUSH);
$output->connect('tcp://localhost:1235');

// envoi de la confirmation de connexion au serveur
$output->send(1);

// traitement
while (true) {
    // réception des données
    $msg = $input->recv();

    // gestion du "suicide"
    if ($msg == 'KILL')
        exit(0);

    // sauvegarde de la machine demandée
    backup($msg);
}

Et là, tout fonctionne à la perfection.