J'ai décidé de travaillé au mois d'août au développement d'un blog en python avec le framework django. L'idée est, d'une part d'avoir un outil que je puisse m'approprier pleinement avec les fonctionnalités que je souhaite comme je les souhaite et, d'autre part, d'apprendre à utiliser un framework web.

L'apprentissage du développements web avec un framework s'inscrit lui même dans deux démarches :

  • Une grosse part des programmes vont migrer vers le web, savoir comment elles fonctionnent et être capable de développer ces applications web me semble important pour qui prétend faire de la programmation. De plus, si je souhaite un jour mettre professionnellement à profit ce que j'ai appris en autodidacte depuis un certain nombre d'année, c'est très clairement ce qui me manquera pour trouver du travail. Même si je n'envisage pas actuellement de travailler dans l'informatique, ce serait me tirer une balle dans le pied de ne pas savoir comment fonctionne le développement web.
  • A terme, j'espère que pititjo.net sera plus uniquement blog. A moyen terme j'envisage de migrer les utilitaires que j'utilise le plus sur pititjo.net à savoir le logiciel de mail, le lecteur de news (nntp, usenet) et l'agrégateur rss. J'envisage aussi une application qui me permettrait d'accéder et de modifier mes fichier depuis le web.

Ce que j'aimerais changer

De ce qui est du blog, dotclear 2, l'outil que j'utilise actuellement, est particulièrement bien fait. Je ne pense pas parvenir à une telle sophistication surtout du point de vue de l'interface d'administration mais il y a certains points qui me dérangent et que je compte bien implémenté à ma sauce.

La syntaxe

C'est le cas notamment de la syntaxe : la syntaxe wiki de dotclear est, de mon point de vue du moins, une véritable horreur qui se base beaucoup trop sur la présentation et pas assez sur la sémentique. De plus c'est relativement illisible car cette syntaxe utilise abondamment les caractères spéciaux. Je compte utiliser une syntaxe plus proche du BBcode mais avec une approche d'avantage sémantique. Là où j'avais \(\(mon-image\|la description donnée au gestionnaire de média\)\) pour insérer une image, je préfèrerais quelque chose comme [img src="mon-image" alt="mon texte alternatif"], pour un lecteur audio, je devait jusqu'ici taper ça :

[Madame Olga|/public/musique/Madame_Olga_-_Madame_Olga.mp3] de Madame Olga

///html
<object type="application/x-shockwave-flash" data="/public/outils/player_mp3.swf" height="20" width="200">
<param name="movie" value="/public/outils/player_mp3.swf" />
<param name="FlashVars" value="mp3=/public/musique/Madame_Olga_-_Madame_Olga.mp3" />
</object>
// /

pour obtenir ça :

Madame Olga de Madame Olga

J'aimerais avoir plutôt quelque chose comme [track scr="/public/musique/Madame_Olga_-_Madame_Olga.mp3" author="Madame Olga" album="Madame Olga" licence="cc by-nc-sa 2.5"] et avoir un résultat boosté aux microformats voire même [track scr="/public/musique/Madame_Olga_-_Madame_Olga.mp3"] et utiliser la base de donnée pour completer les métadonnées.

Les pièces jointes

Elles sont très peu visibles dans dotclear ou, du moins, dans les template mis à dispositions avec gandi blog. J'aimerais leur donner un peu plus de visibilité et automatiser certaines taches qui leurs sont liées.

J'aimerais par exemple que ma balise pour ajouter un morceau de musique joigne toute seule le morceau au billet et que l'on puisse avoir très simplement un podcast avec les billets auxquels sont joint des fichiers musicaux. Un podcast, mais aussi une liste de lecture au format m3u ou dans n'importe quel format, ajouter un format ce n'est qu'ajouter une vue.

C'est globalement tout ce que je reproche à dotclear. Rien que je ne puisse corrigé avec un peu de PHP et la main sur les template de dotclear. Mais voila, je souhaite apprendre comment ça marche alors je réinvente la roue :)

Les acronymes

Tous les acronymes sur une page web devraient être explicités avec la balise (x)html ad-hoc. C'est possible avec dotclear mais il faut préciser la signification à chaque fois, même si vous utilisez plusieurs fois le même acronyme dans le même billet ou dans une multitudes de billets.

Je vérais bien une base de donnée des acronymes qui se remplirait au fur et à mesure et qui permettrait de les expliciter avec un effort moindre.

Ce a quoi il faut encore que je pense

La refonte de pititjo.net a pas mal de similitude avec celle de biologeek dans une moindre mesure. Et les réflexions de David Larlet à ce sujet m'ont inspiré plusieurs de mes interrogations.

Séparations billets/brèves ?

David compte séparer billets et brèves sur son nouveau biologeek. D'un côté il aurait les billets, très peu lié à la date de leur publication, ce sont généralement des billets longs pour lesquels il y a un certain travail en amont. Ici, on pourrait considéré que Le Mus ou encore le tutoriel Open Office seraient seraient des billets.

Les brèves seraient d'avantages liées au moment de leur publication. Ici, mes histoires de cochons pourraient en être. Un autre exemple serait les billets «En vrac» du standblog.

Étant donné mon usage actuel, une telle scission ne me semble pas nécessaire mais elle pourraient me pousser à faire partager un certains nombre de petites découvertes dont je ne parle pas faute d'avoir assez à dire pour écrire un billet correct.

Organisation des commentaires

Comment organiser les commentaires ? Bien sûr, vu le nombre que j'en ai ce n'est pas forcément la question la plus urgente mais il faut tout de même se la poser. Est-il plus judicieux de classer les commentaires par ordre chronologique comme la plus part des blogs ou plutôt de les organiser en arborescences comme sur usenet ou encore sur linuxfr ? Serait-il intéressantes de proposer les 2 vues ou ces deux vues risquent-elles d'être vite incompatibles ? Comment gèrer le flux rss des commentaires dans le cas d'une arborescences ?

Les url

Je pense savoir à peu près comment je vais organiser les url. Je vais très probablement leur faire suivre un shéma du style : /type-de-navigation/arguments-discriminants/type-de-vue. On aurait alors /categorie/informatique/index pour la liste des billets de la catégorie informatique ou encore /categorie/informatique/rss pour le flux rss de la catégorie. Pour les tags ça donnerait /tags/linux+astuce/index.

L'interrogation précédente à propos de la séparation billets/brèves influe sur l'url des billets. Dans le cas d'une séparation on aurait /billet/titre-du-billet pour un billet et /breve/année/mois/jour/titre pour une brève. De tels url implique de faire attention à ne pas avoir deux billets avec le même titre. Si on ne sépare pas alors les billets auront une url du type /billet/année/mois/jour/titre.

J'ai encore un problème avec les url de syndication des commentaires. J'ajouterais bien un coment juste avant le type de vue, ce qui donnerait par exemple /categorie/informatique/comment/rss, mais on perd alors la logique sauf à dire que le shéma est en fait /type-de-navigation/arguments-discriminants/type-de-ressource/type-de-vue et à supposé implicite le type de ressource correspondant aux billets.