Skip to content

Tuyaux pour moi-même

09/04/2011

Voilà des mois (des années ?) que j’ai l’envie pressante de documenter la manière dont fonctionne le Bouillon, afin de le rendre compréhensible pour quiconque souhaiterait se le réapproprier, le dupliquer, le modifier, etc.

Las ! Une présentation compréhensible me semble impossible.

Mais depuis plusieurs semaines des problèmes persistent dans la tuyauterie (sur plusieurs aspects), et en essayant de m’y replonger je constate que je redécouvre moi-même les pipes, que je ne connais plus les URL des différents tuyaux en production (car il y en a plein qui ont servi un jour, qui ont conservé le même nom, mais qui en fait ne sont plus branchés à rien). Pourquoi ? Parce que je n’ai pas eu à m’y replonger depuis juin 2010, car depuis cette date tout se passait bien.

Bref, ça suffit : je documente cet énorme monstre pour moi-même, vous pouvez regarder de loin, mais je ne vous convie pas à vous approcher.

Pipe 1 : les sources

Ce pipe récupère la page qui contient la liste des veilleurs (une liste de ce genre-là), la décompose en veilleurs, en distinguant Nom et flux de veille.

Il exploite un « pipe d’appui » en boucle : ce pipe 1bis ouvre le flux de chaque veilleur, et à chaque item rajoute le nom du veilleur comme dans un nouveau champ « origine ». Ce pipe d’appui dédoublonne également pour chaque flux : si un même billet est partagé deux fois avec la même origine, la 2e occurrence est supprimée.

Après avoir récupéré tous les items de tous les flux (chaque item enrichi désormais d’un champ « origine »), et les avoir retrié par date de publication, le pipe ne conserve que les 200 derniers items.

(le dédoublonnage se fait ensuite sur ces 200 items seulement, ce qui explique qu’un même billet puisse revenir dans le circuit, même s’il est encore présent dans un des flux des veilleurs, pour peu que, la fois précédente où il a été partagé, ça correspond à la 219e place dans le flux global).

Ce pipe

  • Nettoie, en fin de titre, la mention « [via feedly] »
  • Nettoie, en fin de titre, la mention « (+2) », « (+3) », etc., pour peu qu’un veilleur décide de republier un billet lu dans le Bouillon (ou chez les Archiveilleurs)
  • bloque les items où le champ « Commentaire » propre à Google Reader commence par le caractère #. Cela permet aux veilleurs utilisant Greader d’alimenter leur liste de partage sans alimenter le Bouillon.
  • contient des tests résiduels, débranches, qui
    • empêchaient un veilleur de se citer lui-même (contrôle entre l’URL du blog du veilleur, dont le nom est cliquable, et URL de chaque billet cité)
    • résolvaient le partage de liens raccourcis : cela aurait permis une veille sur Twitter, où on ne partage de des http://go.gl et des http://bit.ly. Mais Yahoo Pipes a une utilisation trop aléatoire de l’API LongURL.

Pipe 2 : dédoublonnage et enrichissement des notices

C’est le pipe le plus monstrueux (et celui qui plante le plus souvent), parce que :

  • il dédoublonne chaque item en fonction de l’URL partagée, puis en fonction du titre.
    Le « double dédoublonnage » permet que le même billet, partagé sous plusieurs URL (c’est plus que fréquent), soit tout de même dédoublonné s’il a bien le même titre.
  • si l’item est partagé 3 fois, il récupère, dans chaque occurrence, le nom de chaque veilleur et ses commentaires GReader éventuels
    Pour ça, utilisation d’un autre pipe d’appui : le pipe 2bis, qui pour chaque lien vérifie si ce même lien est présent plusieurs fois dans le flux. Si le lien est présent 3 fois, il concatène les 3 veilleurs (et commentaires) et stocke ces concaténations dans les 3 items
    C’est même plus vicieux encore : ce pipe d’appui est appelé deux fois : la première fois avec le paramètre « origine », la seconde avec le paramètre « commentaire ». Si c’est le paramètre « origine » qui est appelé, il applique une certaine règle (concaténation des noms des veilleurs stockée dans un certain champ), si c’est le paramètre « commentaires » il en applique une autre.
  • il ajoute le nom des veilleurs et les commentaires en tête du billet
  • si le billet est partagé plus d’une fois, il mentionne le nombre d’occurrences dans le titre, entre parenthèses.
    A noter : à ma connaissance, Yahoo Pipes ne permet pas de dire : si l’item correspond à telle condition, faire ceci — et sinon, faire cela. Donc en fait le pipe indique systématiquement le nombre de partages dans le titre. Et ensuite je supprime tout  » (+1) » dans ce champ.

Vestiges désactivés : détecteur de langue (pour proposer un lien de traduction automatique…)

Pipe 3 : anticipation du plantage et mode dégradé

Le pipe 2 bugge souvent : le dédoublonnage et la concaténation des commentaires au sein du corps du texte semble poser des problèmes de performance. Il arrive donc que le pipe 2 soit vide.

Le pipe 3 concatène donc, dans l’ordre :

  1. Le pipe 2, dont il ne garde que les 30 derniers items
  2. Le pipe 1 (qui généralement ne plante pas, mais qui ne fournit pas la liste des veilleurs et commentaires en tête de chaque flux), qu’il dédoublonne, rajoutant pour chaque item partagé plus de 2 fois le nombre de partages, et ne conservant que les 30 derniers items.

Ce qui lui fait 60 items au total. Et il tronque à 30. Ainsi, si le pipe 2 est plein, ça évacue le pipe 1. Et s’il est vide, seul reste le contenu du pipe 1 (Bouillon en mode « dégradé »).

Production du Nectar

Le Nectar en RSS, c’est un autre pipe, avec en paramètre la page listant les Bibliobsédés. Il appelle le pipe 3, et ne garde que les items partagés plus de 2 fois. Il les trie par ordre de recommandation plutôt que par date de publication. C’est tout. Donc logiquement il devrait ne poser aucun problème…

[A compléter plus tard… : reste le Nectar par mail, et peut-être deux ou trois autres choses que j’oublie]

Problèmes actuels (avril 2011)

Le debugger ne fonctionne pas, ou très mal, si bien qu’il m’affiche régulièrement 0 résultat quand je teste l’URL d’une page listant de veilleurs, alors que, quand je lance effectivement le pipe pour cette même URL, j’ai 100 résultats. Conséquence : quand je modifie le pipe, je travaille en aveugle, sans savoir si ça va marcher quand même ensuite, ou si j’ai tout fait sauter.
En essayant d’améliorer les choses et d’alléger les tâches, un des archiveilleurs apparaît désormais en double, et je suis dans l’incapacité de trouver à quel endroit « ça se passe ». Je pense que c’est dans le pipe 2bis, mais…

Plus exaspérant encore : quand je lance le pipe directement depuis l’interface, j’obtiens des résultats.

Mais si je réclame le flux RSS correspondant (Lien « Get as RSS »), il est vide…

Les flux Delicious ne sont pas « acceptés » par Yahoo Pipes (message d’erreur 502). C’est d’autant plus absurde que Yahoo possède les deux services. Il paraît que Delicious y travaille…
Si le problème se prolonge (et il dure déjà depuis mi-mars), la solution de contournement est : donner le flux RSS Delicious à Feedburner, et d’inclure le flux Feedburner dans la liste des veilleurs, rend le flux lisible. Sinon, passer à Diigo !

Le Nectar s’alimente mal. Ben… Faut voir.

%d blogueurs aiment cette page :