Boule de contradictions (c’est tout moi ça)

J’ai passé entre hier et aujourd’hui environ 4 heures à lire le code source de Wordpress, et à essayer de comprendre pourquoi mon blog affichait des liens “Previous entries” menant à des 404. Étant donné que c’était la première fois que je mettais vraiment le nez en dehors du code de mon template, le processus a été douloureux :sad:.

Mes recherches ont mené au résultat suivant : en choisissant le mode “Afficher n jours de posts par page” plutôt que “Afficher n posts par page”, je désactive de facto le calcul du nombre de pages du même type que la page affichée ; Wordpress considère en effet qu’il a 999999 pages du même style (fichier wp-includes/templates-functions-links.php, fonction posts_nav_link. Il est vrai que la requête a écrire pour obtenir ce nombre total de pages est complexe à écrire (je suis en train de réfléchir à la forme qu’elle devrait prendre), mais ça n’excuse pas l’absence totale de commentaires sur le sujet dans la fonction. J’ai ouvert un rapport de bug, je suis curieux de voir quelle suite va lui être donnée.

Toutes ces investigations m’ont permis de remarquer que le thème par défaut de Wordpress 1.5, Kubrick, appelle cette fonction entre 2 et 4 fois par pages. Les appels 1 et 2 servent à générer les liens “Previous” et “Next” séparément car, dans Kubrick, ils sont inclus dans des balises html ; la fonction posts_nav_link n’est pas assez générale actuellement pour traiter proprement ce cas. Les appels 3 et 4 servent à écrire deux fois ces liens, alors qu’il serait très simple de sauvegarder le premier appel…

Une opération fastidieuse dans l’écriture de ce blog est d’insérer des images en fin d’article. Mon approche est de faire une version réduite (de taille standardisée), qui est insérée dans le post, puis de mettre un lien hypertexte vers l’image grand format. Ceci nécessite :

1. De générer la miniature (voire même une première version de taille “moyenne” pour mes propres photographies)
2. D’uploader tout ça sur le blog
3. D’écrire le code html affichant le tout

Les deux premières étapes ne sont pas entièrement triviales étant donnée ma configuration plus ou moins alambiquée. Néanmoins je compte y remédier à court terme par quelques scripts shells bien sentis. La dernière étape quant à elle m’apparaissait frustrante, car je pensais qu’elle pouvait être automatisée par un peu de PHP.

La difficulté avec cette approche est que du code PHP inséré dans un post n’est pas exécuté ensuite. En cherchant un peu j’ai trouvé un plugin permettant ce type de programmation appelé RunPhp. En convertissant mes anciens posts (à la main malheureusement), j’ai toutefois rencontré un bug : des apostrophes étaient transformées en apostrophes obliques par Wordpress, ce qui créait du PHP invalide. Des recherches supplémentaires m’ont mené vers une version plus à jour ; mis à part une syntaxe différente, elle semble remplir pleinement son office. De plus, elle fonctionne à un autre niveau et me semble plus rapide.

Il restait alors à écrire une fonction php générant le code html que j’utilise, et de la rendre accessible en PHP. Pour cela, je l’ai placée dans un plugin, et j’ai activé celui-ci. Le code (très simple) de la fonction est disponible ici

Insérer une image dans un post se réduit maintenant à taper la ligne suivante :
<?php image('image','Description'); ?>, ce qui est nettement plus efficace que les opérations que je devais effectuer avant.

Post a priori incomprehensible, c’est pour décompresser

Certains vendredis me permettent de porter la bonne parole sur terre. J’enseigne en effet des rudiments de programmation à des élèves de niveau L2 Comment vous ne maîtrisez pas encore la réforme LMD ? Honte sur vous. Pour mémoire, L2≡Deug 2^{ème année}. Malheureusement ces chères têtes blondes ont choisi de faire des sciences industrielles plutôt que de l’informatique, ce qui explique parfois leur manque de motivation. Les séances se résument donc souvent à Je m’ennuie.

Ce vendredi ne faisait pas exception, le sujet que je leur avais proposé étant de plus particulièrement facile. Le but était de découvrir a posteriori les dates optimales d’achat et de ventes pour une action dont le cours en bourse A entre deux dates était donné.
La seule question difficile de l’énoncé impliquait de calculer cette valeur en un temps linéaire. Pour cela, il était conseillé d’introduire une valeur gc(n) modélisant le gain courant à la date n, à savoir la somme maximale que l’on peut gagner en vendant au temps n. Bien évidemment, celui-ci vaut A(n) auquel on retranche le cours minimum atteint par la valeur avant la date n. Le gain maximal en n est alors soit le gain courant en n, soit le gain maximum en n-1 (on vend soit à la date n, soit avant). Tout ceci nous donne le superbe système d’équations suivant :

m(n+1) = min(m(n), A(n+1))
gc(n+1) = A(n+1) - m(n+1)
gm(n+1) = max(gc(n+1), gm(n))

Il est facile de se convaincre que l’on peut calculer gm(n) en un temps linéaire. Par contre, une angoissante question se pose : combien faut-il de variables temporaires ? La réponse est obtenue en traçant un diagramme de dépendance entre les variables ; dans notre cas il est acyclique, et on n’a donc besoin d’aucune temporaire ! En effectuant un tri topologique, on peut savoir quelle variable doit être mise à jour en premier (ici m(n)), et obtenir du code optimal.

Je savais bien que mes cours d’optimisations sur des architectures parallèles finiraient par me servir un jour.