LightBlog le moteur de blogs léger
12 Décembre 2011
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
31 Octobre 2011
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
25 Octobre 2011
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.
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.