Omacronides 8

Après une mise à jour avortée (la 7, prévue l'été 2011), voici enfin que j'arrive à peu près au bout des modifications et évolutions que je souhaitais apporté au site cette année (2011).

Pendant plusieurs années, j'ai marqué une (infime) partie de mes lectures sous forme de notes. C'était frustrant parce que je ne me voyait pas écrire une bafouille pour chaque lecture, bafouille qui se réduisait le plus souvent à un simple lien. A partir de juin 2011, j'ai commencé à publier des notes « en vrac » recensant mes dernières lectures, ce qui était déjà un peu plus facile et efficace : je collectais liens et commentaires durant la semaine et je publiai le tout en une seule fois à peu près tous les week-ends. Mais c'était encore loin d'être idéal ; il me fallait trouver un autre système.

Dés lors, pourquoi ne pas utiliser un service en ligne dédié à ce genre d'activité (le « social bookmarking ») ? D'abord parce que je ne voulais pas confier des données à un service qui n'a de gratuit que le nom, et puis parce que je souhaitai contrôler la manière dont sont stockées ces données. Apparait alors Seb Sauvage et son Shaarli, un système de marque-pages perso qui n'a pas vraiment servit de modèle (en tout cas pas ici) mais plutôt d'aiguillon : il était temps que je développe le mien, entendu qui s'intègre au modèle de données utilisé sur ce site. Voilà donc un nouveau type de documents, les liens, des pages regroupant mes lectures mensuelles.

Les données sont donc structurées sous forme d'une page par mois. Les liens ou commentaires sont ensuite marqués dans chaque page en fonction du jour de lecture / consultation et associés à une série de catégories et de tags. La page elle-même est marquée par le mois de publication et une concaténation des catégories et des tags de ces contenus.

Les items peuvent être de simples liens, des photos, des images, un commentaire sur une actualité ou une bande d'un web-comic que je lis régulièrement.

J'utilise le système depuis décembre 2011. J'ai transformé les collections de liens des derniers mois, celles publiées dans les notes « en vrac » (qui ont donc disparues) et celles que je n'avais pas diffusées. Je compte transférer dans ce nouveau système les autres notes « en vrac » ainsi que toutes les anciennes notes « elligibles ».

Le pourquoi de cette organisation tient avant tout à la manière dont je gère / construit les documents du site avec mon gestionnaire de fichiers. J'aurai pu copier le fonctionnement de Shaarli mais il aurait été alors impossible (ou très difficile) d'éditer les données directement, sans passer par une interface web ; et je n'ai pas d'interface d'édition sur ce site (pas encore, mais cela vient peu à peu). J'ai donc opté pour une structure similaire à celles des articles, des notes ou des projets, ce qui m'a obligé à regrouper les items dans des fichiers. J'ai choisi de les classer par mois, ce qui me semble le plus pertinent.

Côté serveur : Col et FlatDB

Le cadre ainsi défini, l'organisation du contenu allait de soi : une collection de liens était parfaitement gérable par un objet PHP pré-existant. 2 problèmes se posèrent alors :

  • Cet objet ne gérait qu'un seul format de fichier, le JSON, alors que je souhaitais évidemment écrire mes fichiers de liens en texte simple (plus facile, rapide et moins de risques d'erreurs de syntaxe).
  • Le gestionnaire de base de données à base de fichiers plats savait gérer une collections de documents mais pas une collection de collections.

L'apparition des liens m'a donc amené à faire évoluer ces modules de rnb-php : FlatDB peut maintenant gérer une collection de documents (Doc) ou une collection de collections (Col), collections qui peuvent être formatées soit en JSON, soit en texte simple.

Côté client : filtre et détails

Les liens m'ont aussi amené à faire évoluer le code côté client. D'abord en développant un objet de filtre en javascript. Les liens « catégories » et « tags » accompagnant chaque document emmènent par défaut vers les pages taxonomiques dédiées. Dans une page de liens, le filtre intercepte les clicks et affiche / masque les items de la page : si on clique sur la catégorie « foo », tous les items n'appartenant pas à la catégorie seront masqués.

Autre expérimentation côté client : l'utilisation d'un élément details, donc j'ai décrit le comportement dans un article dédié.

La bibliothèque

Quoi

Le projet de bibliothèque traînait depuis des mois dans mes cartons, en tant que simple concept d'abord et de manière plus précise depuis le début de l'année 2011. J'ai finalement trouvé le temp de terminer le module de conversion des fichiers Tellico, et donc d'écrire le code me permettant d'afficher le contenu de ma bibliothèque sur le site. Pas toute la bibliothèque, malheureusement, puisque j'ai arrêté d'utiliser Tellico il y a un moment déjà. Le plus important était cependant d'avoir enfin un outil de publication viable.

Comment

Une fois l'outil en main, il s'agissait de savoir quelle structure d'url adoptée, et donc quelles informations récupérées (ou inversement). Allais-je construire une API uniquement centrée sur les ouvrages (cas 1), ou fallait-il pouvoir récupérer d'autres informations comme la liste des auteurs ou celle des éditeurs (cas 2) ? Cette dichotomie change radicalement la manière d'envisager les urls (et la nature du « service ») :

// Cas 1 : récupérer la liste des n derniers livres
GET /books
// Cas 2 : récupérer la liste des n derniers articles
GET /biblio/books
Requête des n derniers livres.
// Cas 1 : récupérer le livre ID
GET /books/ID
// Cas 2 : récupérer le livre ID
GET /biblio/books/ID
Requête du livre ID.
// Cas 1 : liste des ouvrages de l'auteur ID
GET /books/?authors=ID
// Cas 2 : auteur ID avec liste des ouvrages
GET /biblio/authors/ID
Requête de la liste des livres de l'auteur ID.
// Cas 1 : liste des auteurs
GET /books/?authors
// Cas 2 : liste des auteurs
GET /biblio/authors/
Requête de la liste des auteurs.

Les urls du cas 2 donnant une plus grande marge de manoeuvre, outre le fait de décrire une « bibliothèque » et pas seulement une liste d'ouvrages, c'est celles que j'ai implémenté. Mais rien n'est encore fixé. 2017-03-27 : J'ai fini par implémenter le cas 1.

Photos et dessins

La galerie de photos et dessins est une une histoire ancienne puisqu'elle est apparue une premiere fois en avril 2004. Elle a ensuite disapru, à une date que je n'arrive plus à déterminer avec précision, mais cela devait être en 2006-2007. Pourquoi a-t-elle disparu ? Ca aussi je n'arrive plus trop à me rappeler :-).

L'idée de la réactiver a emmergé en mai 2011, après 2 semaines de « vacances » au Portugal au cours desquelles j'ai pris quelques photos. Le projet est resté dans les cartons, comme beaucoup d'autres, jusqu'à ce que je prenne le temps de le mettre en place. Pas que ce fût compliqué : tout l'infrastucture était déjà là, mais le dévellopement des liens a apporté la dernière pierre nécessaire. Ne me restait plus qu'a travailler un peu les images pour pouvoir les publier.

Ce n'est pas encore totalement fait, et les anciennes galeries ne sont pas toutes revenues, mais cela progresse.

2017-03-27 : J'ai finalement abandonnée l'idée de galleries de photos / images. Je transformerai tout cela en article plus conventionnel.

Autres modifications

Bien d'autres modifications ont eut lieu, la plupart ne touchant que ce qui se passe côté serveur : réccriture du module de contrôle des requêtes pour qu'il soit plus souple et efficace, avec la notion de « routes » ; suppression de modules devenus inutiles...

L'une de ces modifications à toucher le processus de mise en production. Auparavant, mon espace de travail était consitué de deux projets : une copie de travail du site en développement et une copie de production ; c'est cette dernière qui était envoyé sur les serveurs OVH. Le processu de mise en ligne se déroulait dés lors comme suit :

  1. Ecriture de code dans la copie de travail.
  2. commit de la nouvelle version de travail.
  3. Fusion des modifications dans la copie de production.
  4. commit de la nouvelle version de production.
  5. Construction de la production (minification/concaténation).
  6. Mise en ligne.

Comment cela se passe maintenant :

  1. Ecriture de code dans la copie de travail.
  2. commit de la nouvelle version de travail.
  3. Construction de la production (copie + minification/concaténation).
  4. Mise en ligne.

Dés que j'ai une évolution un peu complexe, je créé une branche temporaire de développement.