# ★ Objectifs et motivations de la refonte de ce blog

Je comptais faire un premier billet listant les différentes étapes de la refonte mais je me suis finalement ravisé, je n'aime pas spoiler les bonnes séries ;-). Tout ce que je peux vous dire c'est qu'il y aura une dizaine d'étapes et qu'en comptant une étape par semaine environ ça nous amène vers fin avril (les étapes paraissent longues mais c'est surtout la rédaction du billet associé qui prend du temps...). Étant donné qu'on travaille mieux avec des jalons, je fixe arbitrairement le 23 avril comme date de mise en production.

Lorsque je débute un projet, j'aime bien commencer par une phrase clef qui permet de garder le cap tout au long du projet (certains appellent ça le bug n°1 par exemple). Voici celle choisie pour cette refonte :

> Accroître la flexibilité de l'application de manière à davantage mettre en valeur le contenu existant et permettre d'augmenter l'interactivité du site en proposant de nouveaux contenus.

Explications point par point :

## Accroître la flexibilité de l'application

C'est la raison essentielle de cette refonte : reprendre le contrôle du code de l'application dont je me sers pour avoir la liberté de faire ce qui me plaît facilement et rapidement. Je ressens une énorme frustration actuellement à ne pas pouvoir ajouter les fonctionnalités qui me semblent intéressantes sans devoir passer par un plugin (lorsqu'il existe...). D'autant que je dois avoir une aversion au moins équivalente pour PHP de celle que j'ai pour Java (hop un petit troll au passage ça fait pas de mal ;-)).

En contrepartie, il y a un travail conséquent à réaliser, même avec un framework web. Heureusement des snippets commencent à voir le jour un peu partout permettant d'accélérer ce développement avec Django, pour ajouter des trackbacks, des pingbacks ou même une identification via OpenId, c'est autant de boulot en moins. Alors bien sûr le prix à payer est énorme puisqu'il s'agit de recoder une application complète mais justement cela va me permettre de faire la distinction entre les différents contenus.

Il y a aussi de nombreuses limitations propres à Dotclear 1 qui m'énervent (syntaxe wiki exotique, administration, etc) et je voudrais en profiter pour changer tout ça. Je ne fais pas ici le procès de Dotclear qui est un formidable outil de blog et qui doit surement avoir corrigé certaines de ces irritations dans sa version 2 mais je crois qu'un outil de blog n'est tout simplement plus adapté à ce que je veux faire ici.

Un autre inconvénient est bien sûr l'hébergement, j'ai la chance de connaitre un hébergeur de qualité mais je suis conscient qu'il n'en est pas de même pour tout le monde.

## davantage mettre en valeur le contenu existant

Le contenu actuel est un pré-requis à la refonte (qui serait sinon un nouveau départ), j'ai commencé à passer en méta-données les premières images que je mettais en dur dans le code, c'est un travail fastidieux. J'essaye au passage de corriger quelques fautes d'orthographes grâce à Firefox, c'est marrant c'est toujours les mêmes :-). Par ailleurs, j'ai enfin trouver un convertisseur python wiki2xhtml, merci David ! Ce n'était pas un point bloquant car j'aurais pu me baser sur le html mais c'est toujours plus agréable si je veux éditer de vieux billets.

En ce qui concerne la mise en valeur, le sondage précédemment réalisé va m'être d'une grande aide. Je n'ai pas encore fignolé les vues (c'est l'objet de la prochaine itération) mais c'est bien parti. Les billets ne seront plus basés sur leur date de publication mais sur leurs tags. Enfin je ne me suis pas encore décidé entre tags ou tags + catégorie principale. J'ai bien envie aussi de rajouter des billets et des liens externes relatifs aux billets de façon manuelle.

Il reste deux problèmes auxquels je veux tordre le cou :

### La pagination

Ça fait un moment que j'y pense et plus j'y pense plus je me dis que c'est crétin de mettre de la pagination sur un affichage antéchronologique car le contenu d'une URL change à chaque nouveau billet. Il y a deux solutions à ma connaissance :

- tout mettre sur la même page mais dans ce cas là interviennent les problèmes d'indexation par les moteurs de recherche et de temps de téléchargement lors des visites. Je pourrais ne mettre que les introductions des billets pour alléger la page mais vous n'aimez pas ça non plus...
- mettre en place un défilement infini (enfin presque) comme vous pouvez le voir sur l'agrégateur d'Humanized. C'est un concept intéressant même s'il faut des alternatives au niveau du référencement et de la mise en favori d'une page donc ça devient un peu lourd.

Ces deux solutions ne sont pas très satisfaisantes, peut-être avez-vous mieux à proposer ?

### Le référencement

Les URL du site vont forcément changer. Ce n'est pas une limitation de Django, c'est plus un blocage personnel à conserver « index.php » dans chacun de mes liens. Alors bien sûr un tas de redirections vont être mises en place pour ne pas perdre les visiteurs et... les moteurs de recherche. Cela signifie que toutes les pages vont être réindexées lors de la refonte. À ce moment là, pourquoi ne pas changer de nom de domaine ? Je crois savoir que Google se base sur l'ancienneté des noms de domaines mais est-ce un frein suffisant ? J'aime pas trop orienter mes décisions en fonction du PR donc ça reste à déterminer...

## augmenter l'interactivité du site en proposant de nouveaux contenus

Une nouvelle partie va apparaître sur ce site : le bistrot. Ça fait longtemps que j'attends de pouvoir faire ça, la rubrique Ailleurs actuelle étant trop réductrice. Il s'agit à la fois d'un filtre à la masse d'information quotidienne qui peut transiter sur la toile mais aussi une occasion de vous faire participer à ce filtrage en proposant vos brèves. Je ne sais pas encore si ça peut marcher, je voudrais vraiment que cette partie se distingue des digg-like par la qualité des brèves/liens proposés. Je commencerais sûrement en solo pour donner le ton mais je compte implémenter quelque chose dans ce sens, ça pourra aussi être l'occasion d'être un peu plus léger.

Une identification via OpenID est aussi envisagée bien entendu avec la liberté que ça laisse pour faire des comptes utilisateurs personnalisés.

Concernant maintenant les contenus qui vont disparaître, la page sur la syndication probablement (ce sera l'objet d'un billet) et les liens en partie remplacés par les brèves. La page contact sera étoffée d'un « à propos de l'auteur » qui vous semble important à la lecture d'un blog.

Au final, pas mal de boulot mais rien d'irréalisable avec un peu de volonté (et beaucoup de temps ;-), prochaine étape : les interfaces.

### Étapes de la refonte réalisées :

- Contenus + templates + URL + agencement = interfaces
- Initialisation et modèles de données de la refonte
- Vues génériques, héritage et templatetags : développez rapidement avec Django
- De Dotclear à Django : migration des données et redirections
- Ajout des flux RSS, du sitemap et des commentaires avec Django

### Articles peut-être en rapport

- Biologeek (enfin) propulsé par Django
- Ajout des flux RSS, du sitemap et des commentaires avec Django
- De Dotclear à Django : migration des données et redirections

### Commentaires

Damien B le 24/02/2007 :

"Ça fait un moment que j'y pense et plus j'y pense plus je me dis que c'est crétin de mettre de la pagination sur un affichage antéchronologique car le contenu d'une URL change à chaque nouveau billet."
1 - Ce n'est pas propre au système antéchronologique, mais à toute sous-liste non figée. Si je liste les articles par ordre alphabétique du premier "tag" (souponomie 2.0), et qu'un article graffité "aaron" arrive, toute les pages vont être modifiées et c'est normal. Comme dirait Ségolène, c'est l'ordre naturel.
2 - "Cool URIs don't change", ça ne veut pas dire que le contenu d'une page est gravé dans le marbre (et heureusement, pauvre web). Tu dis que le contenu de ta page est : "affichage antéchronologique des articles". Qu'est-ce qui te gêne le plus ? Que le contenu change de manière iso-sémantique (c'est cool comme néologisme), ou d'avoir une navigation de niveau maternelle (une URI = un permalien, point barre) ? Même en Gopher on pouvait avoir des listes paginés, ça ne l'a pas sauvé hélas.

Damien le 24/02/2007 :

Pour le nom de domaine, si tu veux garder un bon référencement tout en changeant, il suffit de faire les redirections 301 qui s'imposent. Tu perdras un peu, mais ça devrait vite revenir.
Sinon tu lui reproches quoi à ton nom de domaine, je le trouve sympa moi :)

vincent le 25/02/2007 :

> Ces deux solutions ne sont pas très satisfaisantes, peut-être avez-vous mieux à proposer ?
Moi je propose une sorte de pagination par "mois". En gros, les billets sont regrouper par mois, et tu les mets tous dedans. A moins que tu manges du lion tous les jours, ça devrait pas être trop monstrueux. (moi c'est ce que j'ai fais :))
Pour les urls.. hum... Soit faire monstre redirection 'choisies' avec l'application Redirects de Django, soit utiliser un autre domaine. Enfin, ça.. :)
Pour openid, tu as déjà mis en place l'authentification par openid ? (moi j'y suis presque arrivé mais j'ai pas le temps de débugger mon truc pour l'instant)

effraie le 25/02/2007 :

Serais tu en train de développer un moteur de blog en python?
si oui, tu comptes le distribuer?

NiCoS le 25/02/2007 :

Pour le changement de ndd, en passant mon blog de lessteinmetz.net à unelectronlibre.info, avec des redirect permanent, j'ai pas perdu mon référencement longtemps.
Sinon pour wiki2xhtml, pourquoi prendre la version wiki alors que la version html existe dans le champ d'a coté dans la table de dotclear ? A moins que tu convertisses vers un autre format de "wiki" ?
Je vois qu'on a plus ou moins les mêmes buts en tous cas (j'y arriverais un jour à publier atome :-P )

David, biologeek le 25/02/2007 :

@Damien B : ce qui me gène le plus pour donner un exemple c'est la pagination sur une page d'accueil de blog. À chaque nouveau billet le contenu de chaque page de la pagination change. Pour répondre à 1, là c'est pas un problème de pagination (par contre si je veux mettre des tags dans les URL style /refonte,site,biologeek/objectifs-et-motivation.../ là le problème se pose si j'ajoute un tag à un ancien billet mais c'est un autre débat).
@Damien : le problème c'est qu'il va falloir un peu plus que des 301 car il faudra certainement taper en base pour récupérer les catégories. Au sujet du nom de domaine, hum, je suis plus trop biolo finalement ce qui se reflète pas mal dans la nature de mes billets. Cela dit, c'est pas encore fait, je l'aime bien aussi ;-).
@vincent : en effet pour des archives chronologiques c'est parfait (surtout vu ma régularité de publication...) mais dans le cas des tags c'est un peu plus compliqué : actuellement 58 billets dans la catégorie Ubuntu.
> Pour openid, tu as déjà mis en place l'authentification par openid ?
Non, il va falloir que je me penche sérieusement sur le problème.
@effraie : ce sera très spécifique à ce que je veux faire ici donc je sais pas si ce sera très utile mais ce sera de toute façon distribué :-).
@NiCoS : merci pour l'info sur le ndd. Je souhaite conserver la possibilité d'éditer mes billets en wiki, mais pas wiki2xhtml (plutôt textile, markdown ou ReST). Avoir wiki2xhtml.py ça permet d'éditer les anciens billets facilement.
Dommage qu'atome ne soit pas prêt ! :p

Gnux le 25/02/2007 :

Salut
J'espère que tu continues à te lever tôt afin de réussir à trouver tout le tps nécessaire à cette refonte en profondeur.

Bast le 25/02/2007 :

Salut David, je me pose une question à laquelle tu as déjà du répondre mais ça ne coute rien de demander. Est ce que tu diffuseras le code "fini" de tout ton projet de refonte de ce blog ?

Damien B le 26/02/2007 :

@David : donc ce qui te gêne, c'est qu'une page puisse ne pas être une pure page de contenu si je comprends bien. Il va falloir enlever les liens sur les tags et les catégories alors :-)

David, biologeek le 26/02/2007 :

@Damien B : pas du tout :-)
Je recommence en détaillant. Dans le cas d'une pagination chronologique, la seule page qui change à l'ajout d'un billet est la dernière (par exemple si on a 10 pages pour l'accueil, la dixième change le temps d'avoir le nombre de billets souhaité, puis la onzième, etc). Dans le cas antéchronologique, à chaque ajout de billet ce sont les 10 pages qui font passer un billet sur la page suivante et donc le contenu de chaque page de la pagination est modifié. C'est ce que je voudrais éviter.
J'espère avoir été plus clair.

NiCoS le 26/02/2007 :

"Je souhaite conserver la possibilité d'éditer mes billets en wiki, mais pas wiki2xhtml (plutôt textile, markdown ou ReST). Avoir wiki2xhtml.py ça permet d'éditer les anciens billets facilement."
Ahhh ok :-) - tu nous feras un petit tuto à ce sujet, dis, hein ? Je suis sur que ça peut intéresser tout plein de personnes (/me siffle)
"Dommage qu'atome ne soit pas prêt ! :p"
Oui il est vrai, y a une début de socle mais c'est encore loin loin d'être aboutit - un checkout sur le svn te permettrait de le voir très rapidement :-)
C'est vrai que du coup on est plein à faire +/- la même chose en même temps... je crains d'arriver bon dernier à cette "course"... :-P

JS le 26/02/2007 :

Mais tu veux refaire un moteur de blog avec django ? avec un système de template et tout ?
Bon courrage en tout cas, j'espère que tu te feras plaisir.

David, biologeek le 26/02/2007 :

@Gnux : j'essaye, il faut que je m'y remette sérieusement si je veux tenir les délais.
@Bast : déjà répondu.
@NiCoS : je compte bloguer l'ensemble de la refonte (et c'est pas une course ;-)
@JS : ce sera pas vraiment un moteur de blog. Faire un blog est très simple avec django (en comparaison).

NiCoS le 26/02/2007 :

"je compte bloguer l'ensemble de la refonte (et c'est pas une course ;-) )"
Yipi ! :-D
Déjà que Kib vient de me dire que l'intégration de reST est quasi auto :
kib2.webfactional.com/blo...

Nicolas Hoizey le 28/11/2007 :

« Dans le cas d'une pagination chronologique, la seule page qui change à l'ajout d'un billet est la dernière [...]. Dans le cas antéchronologique, à chaque ajout de billet ce sont les 10 pages qui font passer un billet sur la page suivante et donc le contenu de chaque page de la pagination est modifié. C'est ce que je voudrais éviter. »
Personnellement, j'ai de toute façon un doute quant à l'intérêt des lecteurs pour les billets anciens accessibles via cette pagination.
En tant que lecteur de nombreux blogs, quand je ne passe pas uniquement par le flux RSS/Atom, je lis en général les derniers billets présents sur la page d'accueil, et les autres billets sont avant tout accessibles via la recherche.
Donc la pagination est surtout intéressante pour Google et consorts, pour que l'indexation du site soit complète, sans avoir besoin d'une page trop lourde avec tous les liens.

David, biologeek le 28/11/2007 :

@Nicolas Hoizey :
> Donc la pagination est surtout intéressante pour Google et consorts
Justement la pagination chronologique fait constamment sauter les articles de page en page au fil de leur arrivée donc au final les pages sont moins bien référencées à mon avis.
Mettons que je poste 10 articles sur Ubuntu, au fil des mois la page qui devrait être bien référencée sur Ubuntu va passer de page 2 à 3 à 4, etc et si je poste souvent l'utilisateur va arriver d'un moteur de recherche sur la 3 alors que les articles pertinents seront déjà sur la 4.

Nicolas Hoizey le 28/11/2007 :

« Justement la pagination chronologique fait constamment sauter les articles de page en page au fil de leur arrivée donc au final les pages sont moins bien référencées à mon avis. »
Ce qui compte, c'est le référencement de l'article, pas celui de la page qui pointe vers lui.
« Mettons que je poste 10 articles sur Ubuntu, au fil des mois la page qui devrait être bien référencée sur Ubuntu va passer de page 2 à 3 à 4, etc et si je poste souvent l'utilisateur va arriver d'un moteur de recherche sur la 3 alors que les articles pertinents seront déjà sur la 4. »
Quand je mets un nouveau contenu sur mon site, il est indexé par Google en moins d'une heure, donc je ne pense pas que le problème soit si important... ;-)
Petite question en marge : comment je fais pour être alerté d'une réponse à l'un de mes commentaires ???

Nicolas Hoizey le 28/11/2007 :

J'ai trouvé le flux RSS des commentaires, dommage que le lien ne soit indiqué que lors de la prévisualisation, on peut être intéressé par les commentaires même sans avoir commenté...

David, biologeek le 28/11/2007 :

> Ce qui compte, c'est le référencement de l'article, pas celui de la page qui pointe vers lui.
Ça dépend, si tu raisonnes en termes de portails de contenus, il peut être intéressant d'avoir un bon référencement sur tes pages de tags/catégorie par exemple.
> J'ai trouvé le flux RSS des commentaires, dommage que le lien ne soit indiqué que lors de la prévisualisation
Il est dans tous les pieds de page avec le petit icône rss et sur la page /journal/ dans la marge mais en effet il gagnerait à être plus visible, en fin d'article par exemple.