Blog makina

Ma machine de bureau personnelle dont le matériel a maintenant non loin de 6 ans tourne avec la distribution Linux Ubuntu depuis son premier boot. Aujourd'hui est un jour de fête : j'ai décidé de lui faire passer la dernière mise à jour majeure vers la version 12.10 nommée Quantal Quetzal (le quetzal quantique traduction approximative).

Ceci en soit ne mérite pas réellement un article à tout bien y réfléchir  Mais c'est en mettant à jour que je suis posé la question de savoir combien de mises à jour majeure cette dernière a subit. J'ai donc décidé de rechercher de quand l'installation date :

Précedement dans un article parlant d'un cas concret de mauvaise gestion de cache j'ai évoqué le hook_hook_info() ; En continuant ma lecture de code sur le sujet, je me suis aperçu d'une autre erreur de gestion de cache de la part des développeurs du core : les cache inutiles.

Dans un article précédent je vous ai présenté la gestion des caches d'une manière assez théorique  Je ne pensais pas que ce matin même j'allais tomber sur un très bon exemple d'une mauvaise gestion de cache, et je pensais encore moins la trouver dans le core. Cet article va présenter, d'une façon aussi objective que possible, l'anatomie de ce cache particulier, et pourquoi même si l'idée était bonne théoriquement, elle s'est en réalité avérée catastrophique dans mon cas d'utilisation. Je vais dans les paragraphes suivants qualifier cette gestion de cache de réel bug.

Today, I was enjoying a boring and alone day, after a incomplete night spent in a very light sleeping state. When I started my day, as always, I turned on my screen and started looking up at Drupal core issue queues, int order to see if some answers magically spawned during the night : as always, U.S. people are the most active while we europeans are deeply asleep.

Today, the main concern for me was a bunch of issues about core handling transactions and some others module related issues. Along those, an old one was stalling where I took the habit to argue louder, entitled Add a persistent key/value store for non-configuration state. I will name this issue The One.

Aujourd'hui, dans un élan de motivation, j'ai décidé de mettre à jour le thème de ce site. Pour continuer sur ma lancée initiale lorsque j'ai changé de thème pour cette version plus sombre et sobre, j'ai bien entendu usé et abusé de la CSS3 et des media queries.

Parmis ces modifications, vous pouvez admirer la magnifique sidebar à droite : j'admets avoir de nouveau calqué un site existant pour quelques petites directives CSS. Notez que je ne suis pas particulièrement mauvais (je ne pense pas l'être) mais incroyablement faignant.

Sometimes you lose your master password. Won't describe here how you managed to do it, since distraction that lead to that kind of errors is a burden to carry for all of us.

Drupal 6 was quite easy to recover, because its passwords were encrypted using the well known MD5 digest algorithm, while Drupal 7 uses SHA512 and a custom seed depending on the site. This statement makes us unable to use well known functions for that.

In order to recover your password, there are two easy steps.

Mise à jour du 12 mars 2011 : Le fameux module est loin d'être efficace à 100%, je reçois régulièrement des SPAM qui arrivent à se faire publier sous la forme de commentaires. Cependant, beaucoup moins que lorsque que j'avais aucun filtre, il y'a encore quelques temps (de plus même avec le module CAPTCHA, il y'a toujours des SPAM manuels qui passent).

Blazé devant la lenteur du module Captcha pour Drupal à être porté sur Drupal 7, j'ai fini par écrire un micro module pour le remplacer. Ce module injecte des champs de manières arbitraire dans tous les formulaires et procède à une série d'altérations — plus ou moins arbitraires—  pour aller dessus. Certains de ces champs doivent être vidés, d'autres non, certains autres ne doivent pas changer. Bref, suffisament de cas d'utilisation, j'espère, pour éviter la majeure partie des SPAM.

De retour du DC Nantes 2011, après avoir beaucoup dormi et absorbé une quantité certaine de café, j'ai enfin 5 minutes pour partager mes slides. Pour information, ils ont été créé avec Beamer.

Merci à la patience de tous ceux ayant assisté à ma courte session, c'est dans un état de fatigue assez improbable mais avec beaucoup de plaisir que j'ai échangé avec vous sur le sujet des performances. J'espère que le peu d'information que j'ai pu apporter vous sera utile.

Comme promis, voici quelques liens aggrégés ces 10 dernières minutes (j'avoue ne pas tous les avoir lus en entier).

Comme promis dans l'article précédent, je vais vous introduire la gestion du cache dans Drupal 7. Dans cet article, je ne vais pas m'étendre sur les politiques de cache d'un point de vue du développeur, mais plutôt du choix du backend approprié en fonction de l'environnement. Cet article a donc vocation de se placer plutôt côté architecte ou administrateur système.

Je suis moi même développeur, architecte n'est pas mon métier, cependant avoir un point de vue éclairé sur les problématiques que rencontrent ces derniers – sans pour autant être un expert – peut amener à se poser des questions sur le code que l'on produit. L'architecture et le design d'une application web (ou d'un sous-ensemble de cette dernière) poussent à se poser la question d'une politique de gestion de cache efficace. Pour mener à bien la conception d'une politique de cache, il faut comprendre les problèmatiques qui se posent derrière.

Cet article va être tourné plus particulièrement à la gestion du cache dans Drupal 7, qui à été grandement améliorée depuis Drupal 6. L'accent sera mis sur les différents backends.

Note de fin de soirée : Terminant cet article, je me suis rendu compte que ma simple introduction à la problématique elle même s'avère être suffisament consistente pour exister en tant qu'article complet. C'est pourquoi je m'arrête ici ce soir. Je vous souhaite une bonne lecture.