Clarus' blog

LightBlog le moteur de blogs léger

Mon, 12 Dec 2011 00:00:00 +0100

J'ai publié et j'utilise désormais LightBlog, un moteur de blog simple, léger et ouvert. Il ne dépend pas de base de donnée SQL et génère uniquement des pages Html statiques. La configuration et les publications sont décrites dans des fichiers texte. La base de code (100 lignes de Ruby et des templates Html) est suffisamment courte pour être comprise et personnalisable. L'utilisateur garde ainsi un contrôle complet de ses données.

Comparaison avec les systèmes existants

J'ai longtemps utilisé les moteurs WordPress et dotclear, mais j'ai toujours été déçu par leur aspect « usine à gaz » et surtout WYSIWYG.

Les publications sont créées à la souris, écrites dans une syntaxe wiki puis converties en Html en étant entre-temps enregistrées dans une obscure base SQL. Cette simplicité d'utilisation pour les rédacteurs se fait au prix d'une installation et d'une administration lourde voire impossible (à cause de la dépendance à PHP et MySQL) et au prix d'une perte de contrôle sur les données. Cela peut se constater lors des mise à jours ou des migrations, même si des fonctions d'import/export existent, ou dès que l'on veut personnaliser un peu trop le rendu des articles.

Il me fallait donc un moteur de blog minimaliste qui soit ce que LaTeX est à Word en terme de contrôle d'informations. Dans ce style là il existe bien Fugitive, mais certains choix de design (avoir Git comme dépendance, être codé uniquement en sh) ne me convenaient pas.

Utilisation

Il peut se télécharger depuis son dépôt hg.clarus.me/light_blog/. Il vient en contenant déjà toutes les données de mon blog.

La compilation se fait à travers la commande make qui produit sa sortie dans le dossier blog/. Il ne reste plus qu'à configurer vos variables dans le Makefile, écrire vos articles dans posts/, personnaliser votre thème dans static/style/ et modifier le contenu des pages dans templates/. Les détails sont disponibles dans le README.

Convention d'appel objet puis abstraction

Mon, 31 Oct 2011 00:00:00 +0100

Les programmeurs doivent, en plus de se souvenir des noms des fonctions qu'ils utilisent, connaître l'ordre de leurs arguments. L'utilisation d'IDE simplifie le travail, en affichant en direct la définition d'une fonction au moment de son appel, de même que l'utilisation d'arguments nommés, notamment en ce qui concerne la lisibilité du code. Des conventions simples peuvent également faciliter la vie, conventions pouvant même être encouragées par la syntaxe du langage.

Objet

L'un des principaux apports de la programmation orientée objet a sans doute été de regrouper la définition des méthodes avec les objets auxquels elles font référence. Lors de leurs appels, la syntaxe :

  obj.meth(arg1, arg2)

impose un rôle prépondérant à l'argument obj et facilite la mémorisation, l'idée étant que la donnée de travail principale d'une fonction doit toujours être placée en tête. Dans un langage non-objet on devrait aussi continuer à écrire dans l'ordre :

  meth(obj, arg1, arg2)

Abstraction

En programmation fonctionnelle, on est souvent amené à passer des fonctions anonymes en arguments. En fait, en pratique, les fonctions ne prennent souvent qu'un seul argument fonctionnel. Cet argument s'écrivant fréquemment sur plusieurs lignes, il est préférable qu'il soit donné en dernier pour éviter d'avoir des mini-arguments qui traînent tous seuls à la fin. Là encore certains langages imposent cette convention par la syntaxe, comme Ruby avec la notion de « blocks », abstractions placées nécessairement en fin d'appel :

  3.upto(12) do |i|
    puts i
  end

Curryfication

La curryfication, bien qu'élégante d'un point de vue théorique, impose je pense de mauvaises pratiques, en encourageant un ordre d'arguments uniquement sur la base des appels de fonction partiels les plus souvent faits. Par exemple :

  map (fun x -> x + 1) list

ne respecte pas les conventions introduites ci-dessus, simplement car on veut pouvoir écrire par curryfication :

  let incr_list = map (fun x -> x + 1)

Sûreté de l'identité numérique

Tue, 25 Oct 2011 00:00:00 +0200

Alors que presque tout le monde maintenant possède une identité numérique (numéro de téléphone, mail, …) en plus d'une identité physique (nom, prénom, adresse) et en dépend de manière critique pour sa vie professionnelle et privée, les lois et les structures en place offrent toujours peu de garanties.

Téléphone

Ce n'est que récemment que l'on a le droit de conserver son numéro de téléphone en changeant d'opérateur, et en pratique j'ai toujours beaucoup d'amis qui changent de numéro. Ce peut être par paresse des procédures, ou pour cause de départ à l'étranger et donc de résiliation de contrat. Or il est surprenant que la gestion des numéros soit confiée aux opérateurs et serve de moyen de pression sur les clients. Il serait plus logique d'avoir deux services découplés, un pour les numéros, un autre pour les abonnements téléphoniques, le premier géré par l'État et le second par les entreprises de téléphonie. Libre ensuite à chacun d'associer son numéro au contrat téléphonique de son choix, voir à aucun contrat si on se retrouve expatrié temporairement, sachant que notre numéro nous appartiendra toujours au retour. C'est ainsi que fonctionne sur Internet l'attribution des noms de domaine, qui se fait indépendamment des hébergeurs.

Mail

On se rend compte souvent de l'importance du mail en entrant dans le monde du travail, où une adresse en pseudo@gmail.com ne passe plus sur un CV et où l'on est parfois contraint, à raison, d'utiliser le service mails de l'entreprise. Notre boîte mail contenant une part importante de notre vie professionnelle et surtout privée, il est malsain et dangereux de faire confiance à n'importe qui, notamment en passant par une entreprise n'étant pas sous juridiction française, quand bien même le service soit évidement proposé de manière gratuite. J'ai la chance de pouvoir héberger mes mails via le service de mon école, l'ENS, mais je crois que si tant de gens continuent d'utiliser des services comme Gmail ou Hotmail c'est avant tout à cause d'un manque d'information et d'alternative. Là encore le service public aurait son rôle à jouer, en fournissant un service mails gratuit et en avertissant les jeunes via l'Éducation Nationale. Je tiens d'ailleurs à saluer le travail de Jacques Beigbeder en ce sens.

Noms de domaine

Enfin, l'usage de noms de domaine reste encore réservé à une niche de connaisseurs. Même si je comprends que tout le monde ne veuille pas héberger son propre site web, il est pourtant très simple de les utiliser pour mettre en place des redirections mails et par exemple de disposer d'une adresse prénom@nom.fr pour toute sa famille. L'obscurité qui se cache derrière la gestion d'un nom de domaine pourrait facilement être supprimée par une formation spécifique à l'école, et on pourrait voir fleurir des services permettant de facilement mettre en place sa page personnelle. Les gens ne seraient plus contraints d'utiliser Facebook ou des hébergeurs de blog comme wordpress.com, gardant ainsi la souveraineté sur leurs données. Cependant, il y a aussi le problème de la saturation des NDD, tout le monde ne pouvant pas posséder son propre nom.fr. Il faudrait alors réfléchir à l'attribution des prénom.nom.nom.fr ou prénom.nom.name.fr, gratuitement ou pour une somme symbolique, à toutes les personnes le désirant, voire à la naissance en ajoutant les deuxièmes prénoms pour éviter les homonymes.

LLVM MD et correction de compilateurs

Thu, 06 Oct 2011 00:00:00 +0200

Alors que la plupart des compilateurs définissent un nouveau langage intermédiaire par phase de compilation, LLVM n'en utilise qu'un seul (une sorte d'assembleur généraliste), ce qui permet une grande modularité et une meilleur mise en commun des efforts. Vous pouvez développer votre propre optimisateur de code et il sera réutilisable dans toutes les chaînes de compilation existantes.

Beaucoup de preuves de correction de compilateurs montrent que le code produit respecte nécessairement la sémantique du code source, mais il existe aussi l'approche inverse qui consiste à calculer pour chaque code généré, a posteriori et quand on y arrive, un certificat prouvant l'équivalence avec le code initial. Cette approche s'applique particulièrement au cas de LLVM, car être capable de décider (avec de bonnes heuristiques) l'équivalence de deux programmes revient à être capable de donner la correction de tous les compilateurs LLVM, existants ou à venir.

C'est justement le but du projet LLVM MD de l'université de Harvard. L'équivalence est décidée par comparaison des sémantiques opérationnelles, la principale difficulté étant la présence d'effets de bord, de branchements et surtout de boucles.

À partir d'un code source C1 donné en forme SSA, et de sa version C2 produite par une phase de compilation intermédiaire, on en extrait une représentation GDSA (Guarded Dynamic Single Assignement) qui est un ensemble de règles de réécritures avec explicitement une variable m pour décrire l'état mémoire et un opérateur µ pour décrire les boucles. En est déduite une représentation symbolique pour chaque variable de retour de fonction, réduite à l'aide de règles de simplification collant si possible aux règles utilisées par le compilateur. Enfin les valeurs obtenues sont comparées entre elles.

Une implémentation a été réalisée en Haskell et appliquée à de gros programmes tels que SQLite, composé de plus de 1.300 fonctions C. Les résultats dépendent de la phase d'optimisation mais environ 90 % des fonctions compilées sont validées pour chacune des passes. Ainsi, quitte à ne pas compiler certaines fonctions, un code peut être presque totalement optimisé de façon certifiée.

Le projet c'est pas encore terminé et, même si des restrictions sont faites sur les instructions LLVM utilisables et si on peut regretter que l'outil de donne pas de certificat Coq de ses analyses (il faudrait pour cela d'abord formaliser la sémantique de LLVM), les résultats semblent très prometteurs.

En-tête LaTeX standard

Thu, 16 Jun 2011 00:00:00 +0200

Le problème d'encodage de caractères et de police est récurrent en informatique. En LaTeX, il est bon d'utiliser les commandes suivantes pour être tranquille :

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}

On active la saisie du code LaTeX en utf-8, le mode T1 génère un unique symbole pour les caractères accentués, au lieu d'un accent superposé à un 'e' par exemple pour le 'é' (meilleur rendu, copier-coller du texte de PDF simplifié). Enfin, lmodern permet d'utiliser les polices Latin Modern, qui ont un bien meilleur rendu que les Computer Modern utilisées par défaut.

Bien sûr, si vous écrivez en Français, il faut aussi charger le module babel pour respecter les règles typographiques :

\usepackage[francais]{babel}