Il y a quelques années, les débuts des services Web font rage. Nous devons inclure les cartes dynamiques, les informations du site Gloubi avec celui du site Boulga. C'est l'ère du mashup. Tout cela n'a pas disparu bien sûr. Cela s'est juste régularisé. Les gros ont mangé les petits. Les services plus ou moins rentables ont survécu et les autres ont laissé des trous dans des pages Web non maintenues. Une API pour accéder aux données, une API pour inclure ceci ou cela sans jamais vraiment se poser la question de la pérennité ni de la pertinence. Mais on expérimente. C'est déjà cela.

Depuis les 4 dernières années, l'expression brûlante sur toutes les lèvres est opendata (données ouvertes). Bien sûr, comme le sujet n'avance pas assez vite. On glane (to scrap) ici et là les données dont nous avons besoin. Parfois avec de nombreux efforts, de regex, de requêtes HTTP, on arrive à extraire les données des pages Web, même en tordant le bras aux licences du site Web en question.

Alors bien sûr dès qu'il y a un besoin et un problème technique difficile à régler, un service émerge afin de créer des connexions. Le but de import.io est de démocratiser l'accès des données en ligne. Cela ressemble à un recyclage du vénérable Yahoo! Pipes. Ce qui semble intéressant, je ne peux pas encore le tester directement, c'est que l'outil semble apprendre de la structure de données du site et de proposer des interfaces pour mieux extraire les données.

Dans ma réflexion sur les APIs hypermédias qui accompagne une autre sur les commentaires distribués, je me dis que des vocabulaires génériques (rel/meta/etc) pourraient décoller s'il y avait plus d'outils d'aggrégations utilisant le glanage des données. Pourquoi par exemple donner un accès à un feed au format atom, si nous avons des outils comme webmention et hAtom pour déjà y répondre.

En passant, il y a un événement EcoHack à Montréal bientôt.

Hier, j'ai mentionné qu'il fallait se poser les bonnes questions avant de choisir le style et la technologie de son API (XML-RPC, HTTP, HATEOAS, etc). L'une de ses questions est essentielle, à mon avis, dans le choix d'une API hypermedia (HATEOAS). Cependant cette question est rarement abordée. Aujourd'hui l'argument principal pour promouvoir HATEOAS est celle de rendre l'API explorable par le client (logiciel) lui-même et donc que la construction des URIs de l'interface est beaucoup moins dépendante d'un fort couplage entre le client et le serveur.

Les APIs HTTP d'aujourd'hui

Aujourd'hui, de nombreuses APIs HTTP, qui se disent REST et ne le sont pas, s'appuient sur la construction prédéterminée des URIs. Typiquement, le développeur d'un client lira la documentation sur le serveur et sait que certaines formes d'URI permettent d'obtenir certaines données. Cela permet au développeur de créer très rapidement un client qui à l'avance peut traiter les données. En revanche, cela entraîne un couplage très fort entre le client et le serveur. Le serveur devient victime de ce couplage par rapport aux évolutions futures sur le schéma d'URI choisi—Je ne parle pas de vocabulaire de l'API. Si le serveur change, les clients doivent changer.

Mais est-ce bien grave ? Je vais y revenir.

HATEOAS

Donc souvent, face aux interfaces HTTP à fort couplage, il est souvent recommandé un style légèrement différent : Hypermedia ou HATEOAS. Le client ayant une interface hypermedia générique (comme la connaissance du format HTML et de ses a/href/rel), il peut explorer l'API (soit suivre les liens et les valeurs de rel) afin de construire les URIs dynamiquement plutôt que codés apriori. L'avantage pour le serveur et le client est que cela permet de mettre de l'huile dans les rouages en rendant indépendant du choix de schéma d'URI.

Vocabulaire d'API

Chaque API est composée d'un certain vocabulaire, des requêtes spécifiques auront des réponses spécifiques. Dans le cas d'une API HTTP, le vocabulaire est très fortement couplé avec le schéma d'URI. Dans le cas de HATEOAS, le vocabulaire est très fortement couplé avec la sémantique du document. Dans les deux cas, il s'agira de connaître le vocabulaire pour pouvoir créer un client efficace.

La bonne question

La bonne question dans le choix de HATEOAS vs une API plus couplée n'est pas tant l'évolutivité de l'API au niveau de son vocabulaire mais bien celle de l'évolutivité du schéma d'URI. Donc oui HATEOAS ajoute de la robustesse mais pas celle qui est souvent vendue, promue. Il est ceci dit possible de définir son API de façon à ce que l'évolution du vocabulaire soit aussi explorable dynamiquement, mais cela se réfléchit en amont. Viens alors la réelle question…

Le service : est-il générique (plusieurs entreprises se partageant le marché) ?

L'enjeu pour avoir des outils génériques capables de fonctionner de façon autonome face à une API dépend du besoin du marché avant tout. C'est à dire que si je conçois un service qui est utilisé par deux/trois personnes. Mon API peut avoir un fort couplage sans aucun problème. Si en revanche, j'ai besoin de parler à un grand nombre de clients différents déployés en grands nombres, l'évolutivité et la flexibilité devient un avantage pour le futur si mon API s'inscrit dans le long terme. Mais finalement, encore plus important est lorsque je conçois mon service Web comme un service générique faisant partie d'un large marché de services similaires (exemple tous les serveurs de mails implémentant IMAP). Cette fois-ci, l'intérêt est de permettre aux personnes qui ont des clients logiciels d'utiliser mon service ainsi que celui des autres par une interface uniforme et non couplée.

Et c'est bien pour cela que les APIs hypermedia ont dû mal à décoller. Les acteurs actuels ont beaucoup d'intérêts d'affaires (API pour silos) et très peu d'intérêts de marché (API génériques).

Il a fallu un rat pour détruire un cable d'alimentation électrique du système de refroidissement de la centrale nucléaire de Fukushima. L'innocence d'un rat pour mettre en péril l'équilibre fragile d'un système complexe et instable. Les estimations actuelles donnent 40 ans avant d'avoir démonté la centrale, environ une génération et demie de temps humain.

L'enjeu de l'énergie nucléaire n'est pas tant dans le danger léthal de la radioactivité—le nucléaire lui-même—mais bien la centrale nucléaire. À la création de nouveaux systèmes, nous créons de nouveaux enjeux, de nouveaux problèmes. Les systèmes crées pour le fonctionnement d'une centrale nucléaire sont très complexes. John Gall dans son essai sur les systèmes, Systemantics, mentionne que Tout grand système va fonctionner la plupart du temps en mode d'échec. En effet ce qui est intéressant dans la création du système n'est pas tant les modes de succès, ce qui généralement fait l'objet de la concentration de nos efforts, mais bien comment ce système va échouer. Cependant il ne faut pas avoir l'illusion que nous pourrions tout prévoir car comme le pose John Gall Un système peut échouer de façon infinie.

Nous savons donc que le système va échouer et nous savons que nous ne pouvons pas prédire l'ensemble des possibles de l'échec. La conception d'un système robuste devient alors une recherche de la flexibilité face à l'échec, face à l'imprévisible. L'enjeu d'une centrale nucléaire est que certains de ces modes d'échecs ont des conséquences difficilement contrôlables à de très larges échelles de temps et d'espace.

L'exposition archéologie du numérique au CCA du 7 mai au 13 octobre 2013 présente quatre projets d'architecture des années 80-90. Sous l'angle de l'utilisation des logiciels de conception, on nous invite comment l'utilisation de ces nouveaux outils a modifié la forme de la conception. La salle du centre présente une maquette pour chacun des quatre projets que l'on peut retrouver dans les salles adjacentes un peu à la façon d'un arbre dont les portes sont les liens entre la salle sommaire à l'entrée.

Voilà cependant l'exposition ne va pas plus loin et plutôt qu'une archéologie du numérique, on se retrouve coincé dans une réflexion plutôt succinte sur comment les automates de programmation, les capacités de calcul ont permis d'explorer les formes sur l'écran et donc de dévelloper de nouvelles formes physiques. Quelques vestiges du passé de l'informatique, des outils sur lesquels j'ai moi-même travaillés, quelques copies imprimées de brevets, quelques maquettes automatisées, … et c'est tout. La réflexion ne va pas plus loin et le terme « archéologie du numérique » devient soudainement une tromperie ou au moins une ébauche du sujet à traiter.

Les conséquences du numérique ne se définissent pas seulement dans la forme, mais également dans la modification de nombreux autres éléments de l'environnement. Dans les idées de pistes à explorer pour une archéologie du numérique dans le domaine de l'architecture :

• La modification des studios d'architecture avec l'arrivée de l'ordinateur
• Les changements sociaux induits entre les employés
• Les coûts d'investissement relatifs pour les concours
• L'accélération du temps
• La simulation des espaces par les flux
• La détérioration de la mémoire des objets numériques dans le quotidien
• La modification de la théorisation architecturale par la destruction du physique pour élaborer le physique.

Et de nombreux autres sûrement à explorer. Je vous recommande tout de même d'y aller mais sans espoir de révélations intenses.

API, API, API. Il est impossible d'avoir une conversation à propos du Web sans en parler généreusement que ce soit entre développeurs, architectes de solutions, mais également marketing, business, etc. Le terme a pénétré un peu partout.

Comme tout sujet largement evoqué, il existe de nombreux écoles de pensée sur la manière de créer de une bonne API. Au sein même du Web, il existe plusieurs niveaux d'API. Le code lui-même et ses interactions entre ses différentes composantes (opaque pour ce qui est du Web mais permettant le Web) est constitué d'API. L'exposition de la communication entre le client et le serveur constitue une ou des APIs. Ainsi qu'au niveau du client lui-même, les APIs permettant de manipuler les données du document (partiellement opaques pour le Web).

Le marteau de Maslow

Christian a dit il y a quelques jours

Je ne comprends pas le choix systématique de JSON comme MediaType pour les APIs ; HTML5 me semble tellement plus simple.

Christian exprime là une différence d'écoles de pensée. Elle illustre peut-être aussi l'intérêt ou l'influence de sa conception des interactions sur le Web. Cela tient en partie à la loi de l'instrument ou le marteau de Maslow :

Nous avons tendance à utiliser notre bagage culturel (nos outils) pour résoudre les problèmes, enjeux, questions que nous croisons. Il est directement accessible, nous aide à démarrer très rapidement à résoudre le début du problème.

Bataille d'acronymes

JSON, HTML5, REST, SOAP, XML-RPC, HATEOAS, … Nous nous engageons dans des batailles d'acronymes sur la pertinence d'une école, d'un style, d'un format et en mélangeant souvent au passage les domaines d'applications. À se demander parfois, si cela nous permet d'éviter de résoudre le véritable enjeu. Voir les échanges d'ébats, les débats que nous avons avec David et Eric et quelques autres.

Et en effet, il est difficile de ne pas s'engager dans une bataille conceptuelle sur la bonne méthode à utiliser, mais finalement admettons que nos batailles sont bien futiles tant que nous nous ne concentrons pas sur la résolution d'un enjeu particulier.

Un enjeu à résoudre

Avant toutes discussions sur la pertinence d'un choix stylistique ou technologique, il est nécessaire de poser clairement quel est l'enjeu à résoudre. Il est tout à fait possible d'avoir plus d'un enjeu avec des priorités et des domaines d'applications très différents. Ce matin, en marchant pour aller boire un café au lait, je me disais que finalement ce qui manquait dans nos discussions est une liste de questions préliminaires. Si nous prenons le cas d'un service exposé sur le Web, il existe de nombreux questions intéressantes que l'on se pose rarement comme :

• Le service : peut-il exister dans ses interactions sans utiliser le Web (HTTP) ?
• Le service : doit/peut-il être unique (une seule entreprise offrant ce service) ?
• Le service : est-il générique (plusieurs entreprises se partageant le marché) ?
• Le service : doit-il interagir avec un unique logiciel client ?
• Le service : doit-il interagir avec de nombreux logiciels clients créés indépendamment les uns des autres ?

Il y a sûrement de nombreuses autres questions. Mais répondre à ces questions déjà va vous permettre non seulement de comprendre un peu mieux l'écosystème de votre service, les technologies à explorer pour résoudre le problème, ainsi que les efforts nécessaires en termes de coopération et d'innovation.

Il pourrait être intéressant de développer les questions ci-dessus. Dites-le moi si vous êtes intéressés.

Le professeur Joon-Young a créé un appareil révolutionnaire d'immersion totale des expériences sensorielles. Sa première expérience fût de recréer les impressions sensorielles que nous avons lors d'un tour de montagnes russes. À l'aide des transmetteurs localisés près de la boite crânienne, l'appareil reproduit les sensations de la chute, du vent dans les cheveux, ainsi que les stimulations rétiniennes à la perfection. L'accélération du rythme cardiaque, les sentiments de peur et d'excitation se recomposent alors naturellement. Le prototype, pour l'instant encore un objet imposant, n'aura pas de difficulté à être miniaturisé et pour un prix modique. « Nous travaillons déjà avec une usine de Shenzhen pour produire l'exemplaire à quelques milliers d'exemplaires par jour. » nous a dit le professeur « C'est excitant ! L'entrée d'un parc est de quelques dizaines de dollars et il faut attendre bien souvent une heure ou deux entre chaque tour. Avec mon appareil, il sera possible pour quelques dollars de le faire de son salon mais aussi n'importe où et surtout nous avons prévu un module pour concevoir vous-même vos parcours. »

Le syndicat international des parcs d'attractions mondiaux a lancé depuis quelques semaines un groupe de pression afin de modifier auprès de l'ONU la législation internationale pour interdire le nouvel appareil du professeur Joon-Young. Ils avancent notamment qu'il est important que les visiteurs des parcs continuent de pouvoir sentir le vent dans les cheveux et la gravité de manière naturelle. Ils ont également lancé un mois de promotion à tarifs réduits pour toutes les montagnes russes. Ils essaient également en second recours de prévoir une taxe spécifique sur chaque appareil vendu versée à l'association de gestion des droits des parcs d'attractions mondiaux. C'est donc une affaire à suivre de très près, l'industrie des parcs d'attractions n'est pas en reste et comptent lancer une grande campagne d'information sur la réalité physique de la montagne russe afin de combattre « la perversion de la dématérialisation » selon les mots du président Mr Layssekur.

Ce moment de l'année, où nous ouvrons la boîte de carpes achetée dans un magasin de Sendagi. Faute de banderoles, nous avons un mobile pour koinobori. Les carpes flottent au dessus de mon plaisir.

Sortir finalement les vélos, regonfler les pneus après les 6 mois. Mettre un grand morceau de tissus dans le sac et remplir une gourde d'eau. Se diriger vers le canal de Lachine et s'arrêter au magasin Les produits du Québec Smoked Meat Inc.. Commander deux sandwich à la viande fumée avec fromage et se rendre au bord du canal. Étaler le tissu et enlever ses chaussures. Voilà c'est le moment du plaisir, de la bouchée, un des meilleurs de Montréal. Une fois fini, faites une sieste. Et puis un peu plus tard, se rendre au marché Atwater et acheter des légumes frais. Faire une salade le soir avec des concombres, tomates, avocats, coriandre et une sauce au vinaigre de cidre et échalotes.

Variations possibles et sans contraintes.

Le magnolia dans ses cheveux sombres, c'est le souvenir que je souhaite garder.

Voici un peu plus de deux ans que le tremblement de terre et le raz de marée ont détruit une partie du Japon. Dans certains journaux du Japon, il existe encore des sections consacrées à l'événement. Lors de ma dernière visite au Japon au début de l'année, j'ai été surpris par le magasin Tokyu Hands qui avait créé une section complètement dédiée aux catastrophes à venir.

La population japonaise est formée aux tremblements de terre. Les enfants ont des exercices réguliers dans les écoles. Il existe des lieux d'évacuation d'urgence et les cartes dans les administrations. Il existe des kits de première urgence disponible dans toutes les maisons. Les maisons neuves sont construites aux normes anti-sismiques et même parfois démolies quand elles ne le sont pas. Cependant, la section du Tokyu Hands de Shinjuku était bien différente, mettant en avant bien plus qu'à l'ordinaire la notion d'être prêt pour les catastrophes à venir.

Des valises étanches, des abris d'urgence pour les tsunamis, comme cette boule rose—Je me demande ce qui se passe quand on se retrouve au milieu de l'océan dans sa boule rose. Même les réchauds de camping et les panneaux solaires ont été sémantisés dans une optique de l'urgence.

Tout ce qui était objet de loisirs, du plaisir de découvrir la nature et de partir ailleurs, devient l'objet de la crainte de la nature, d'être prêt au cas où… sans bien sûr savoir quand ce cas arrivera. Je ne peux m'empêcher qu'il y a un enjeu légèrement cynique de la part des études de marché où il est surement plus facile de vendre des objets anodins pour une future catastrophe plutôt que pour aller s'extasier sur les chemins de forêt. La possible catastrophe touchant plus de monde et ne donnant que peu de choix.

« Tu es dorénavant en charge de la soupe miso ! » De nos gestes coulent les habitudes à venir. Elle avait aimé la semaine passée, le goût de la courge dans la soupe. De ce succès me voilà nominé maître ès soupe miso. De nouveau, je me prépare à préparer la soupe. Je choisis les ingrédients et je procède. Ce soir, ce sera okura. Il faut d'abord laisser suer les morceaux de Tofu frit dans l'eau bouillante pendant quelques secondes pour enlever l'huile. Je jette l'eau et prends de l'eau fraîche pour la porter de nouveau à ébulition. J'ajoute le dashi et l'oignon coupé. Et puis finalement à la fin j'ajoute le okura coupé en tranche, peu de temps. Le feu coupé, je prends le bouillon et juste le bouillon pour diluer le miso dans les bols. Finalement, j'ajoute le okura et l'oignon dans les bols ainsi que le tofu frit coupé en deux.

C'est maintenant la soupe qui me possède, et déjà je m'interroge sur la prochaine variation.

Je suis en cours de lecture de L’homme qui ne vécut que pour aimer. Le traducteur a amplement documenté sa traduction avec des notes en fin de chapitres. L'objet livre permet un accès dans le volume en plus de celui de la linéarité du texte. C'est essentiel dans le cas des notes en fin de chapitres. Typiquement le lecteur placera un doit à la fin du chapitre ou bien un marque page spécifique afin de pouvoir faire des aller-retours rapides entre le texte et les notes. Il y a une bi-directionnalité de l'action.

Dans le cas d'un texte au format numérique et des outils associés comme une liseuse, cette métaphore d'interaction ne fonctionne plus. En effet, les notes numérotées apparaissent dans le texte afin de renvoyer à la référence numérotée en fin de chapitre. Mais il est impossible d'y accéder sans faire défiler toutes les pages du chapitre en question. Il serait envisageable de « sauter » à la page en question lorsque l'on connaît le numéro précis. Il faudra l'avoir découvrir par avant.

Dans le fichier ePub, le markup est présent et organisé de la façon suivante :

<p class="texte">Un jour qu’il s’était rendu chez
une relation aux environs du mont Kurabu
<span class="appel-note">
   <a id="footnote-225-142-backlink"
      class="footnote-link"
      href="#footnote-225-142">142</a>
</span>, il effraya les oiseaux

[… texte …]

<div class="footnote">
   <p class="notes">
       <a id="footnote-225-149"
          class="footnote-anchor"
          href="#footnote-225-149-backlink">149</a>
          Certainement Washu-Nakazawa, sis en Yamato et mentionné
          en IV, 3.</p>
</div>

La référence à la note est bien présente. Le lien de retour également. La liseuse Kobo Touch ne prend pas avantage de ce markup afin de rendre la lecture plus fluide. Existe-t-il un markup normalisé pour les notes de texte ?

La spécification ePub3

La spécification ePub3 pour le contenu définit un attribut type permettant d'élargir la sémantique des éléments. Une phrase surprenante de la spécification est The epub:type attribute is intended to be functionally equivalent to the W3C Role Attribute [Role], but with restrictions as specified in Vocabulary Association. Il est assez difficile de comprendre pourquoi ne pas avoir repris l'attribut role plutôt que d'inventer un nouvel attribut. La spécification nous dit ensuite que la valeur de type est une liste de property séparés par des espaces, mais lorsque l'on clique sur le mot property, nous sommes renvoyés sur la définition de l'attribute property.

Dans la section suivante sur les associations de vocabulaire, nous pouvons remarquer un exemple de markup.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
       …
       <p> … <a epub:type="noteref" href="#n1">1</a> … </p>
       …
       <aside epub:type="footnote" id="n1">
           …
       </aside>
       …
   </html>

La légende de l'exemple nous dit que le vocabulaire est défini dans un autre document : EPUB 3 Structural Semantics Vocabulary. La valeur noteref est définie comme une référence vers une note, apparaissant typiquement avec symbole en exposant dans le corps du texte. La valeur de footnote est définie comme une note apparaissant au bas de la page. Dans la même section sont définies note, rearnote, footnotes (pluriel), rearnotes (pluriel). RhahahhahhhhaaaaaaRHHHHAAAAA. Pourquoi tant de haine ? Je m'égare. Nous avons donc là des propriétés avec une sémantique très similaire et qui signifient à peu près la même chose, mais qui sont identifiées à cause de leur héritage du monde du livre papier. Je pense… ePub4, version simplifiée de Epub3 ?

Mon désir de lecteur pour les annotations

Dans la lecture des œuvres au format numérique, je veux pouvoir avoir les notes en contexte. Structurellement qu'elle soit à la fin du fichier HTML ou en son cœur, ce n'est pas très important. (Je pense que les notes in-situ font beaucoup plus de sens pour l'auteur et la gestion de ses notes sur le long terme).

En revanche en tant que lecteur, je veux que les notes soient incluses dans le flot du texte. Que ce soit en pop-up ou au sein du texte avec une fonctionnalité pour les cacher ou les montrer. J'ose à peine imaginer comment Pale Fire est illisible sur une liseuse.

Depuis janvier 2013, je cherche à décrocher (comme de nombreuses autres personnes) un nouveau job. Je n'ai pas encore trouvé.

Quelques entretiens déjà passés, le dernier en date était avec Mozilla pour le poste de Mozilla Web Compatibility Engineer (un rôle équivalent à la mission de l'équipe Open the Web à Opera). Je crois savoir la/les personnes recrutées et je pense que j'aurais choisi les mêmes. Mozilla fait partie de ces entreprises d'une certaine éthique que j'apprécie.

La dynamique lors des entretiens est intéressante car en fonction des différentes annonces pour différentes organisations ou entreprises, j'ai obtenu des commentaires différents et parfois contradictoires : « pas assez technique, » « trop technique, » « trop évangéliste, » « trop Open Web, » « sympathique, » etc. Une recherche de job est toujours angoissante. Et pourtant, elle ne devrait pas tant l'être. Il s'agit de faire correspondre deux affinités : celles des besoins d'une entreprise et celles des besoins, désirs d'une personne.

Freelance

Plusieurs fois, les amis m'ont demandé, pourquoi ne pas me mettre à mon compte (freelance). J'aime beaucoup travailler pour les autres. Être freelance est un double job. Pour pouvoir assurer les contrats, il faut tout d'abord partir à la chasse de ces contrats et gérer la partie administrative de ces contrats. Cette partie plus administrative et hors-travail m'intéresse moins. Me mettre à mon compte, c'est la garantie pour moi de n'avoir pratiquement aucun revenu.

Ouverture

L'ouverture dans le dialogue est un art difficile. Comme le dit l'adage « Ma liberté me coûtera tout. » Je ne me suis jamais vraiment senti contraint dans mes paroles. Je veux croire et faire confiance à mon interlocuteur, que mes mots ne soient pas perçus comme une critique sévère mais comme une mise en contexte. J'exprime une pensée affirmée, mais ouverte au débat. Il faut que j'apprenne à « mettre de l'eau dans mon calva. » (sacrilège normand)

Manager

Au nombre de mes défauts, ne pas accepter que je peux encadrer une équipe. J'ai une sérieuse tendance à fuir les annonces de jobs de manager. Je suis parfois perçu trop vieux (âge) et trop junior pour des jobs de développeur pur. Cornélien. Ma répulsion du job de manager tient sûrement en partie à conception des pouvoirs et des attentes face à ces pouvoirs. Quand je suis dans une position hiérarchique, le changement de comportement des individus me coûte énormément. J'aime permettre aux gens de comprendre, de s'épanouir, de s'extasier. J'aime pouvoir apprendre avec eux et leur donner ou construire ensemble les outils d'organisations, les pistes de recherche pour qu'ils puissent réaliser leur travail convenablement. Mais la docilité ou le respect que les autres attachent parfois à la position hiérarchique me rend triste. Il faut que j'apprenne à « mettre de l'eau dans mon calva. »

Le futur ?

Je n'ai pas de pistes pour l'instant. Je dois annuler ma présence à SudWeb 2013, ce qui me peine beaucoup, car je dois me concentrer sur le fait de trouver un emploi. Je recherche toujours. Mozilla fait partie des endroits où j'aimerais travailler tout en étant critique, mais n'est pas le seul endroit où il est possible de s'épanouir. Il me faut juste trouver le bon endroit et surtout la bonne équipe.

Petit rappel : Je suis prêt à me déplacer. Je peux légalement travailler au Canada, en France et au Japon. Je peux travailler à distance aussi. Nous aimerions quitter Montréal pour le Japon ou la France, mais c'est négociable. Pour le reste.

Elle m'a dit : « Tu dois prendre le bus pour aller sur Côte des Neiges. Une fois là bas, tu entres au 3744, rue Jean-Brillant. L'ascenseur vers le quatrième étage. Quand tu sors de l'ascenseur, il y a une porte avec la notice Centre d'études de l'Asie de l'Est. » J'ai alors suivi les instructions et je me suis rendu au quatrième étage, un peu intimidé par les lieux que l'on découvre, la peur d'être inopportun.

J'ouvre la porte et je débouche dans un étroit couloir avec des portes de salles et bureaux sur la gauche et un long mur sur la droite. Les épaules rentrées, le souffle presque coupé, je me fais discret. Sur le mur à droite, une exposition magnifique de photographies de la Chine, une dizaine seulement, des scènes de rue. J'ai oublié de prendre le nom de l'artiste.

J'entends des personnes parlées chinois, du mandarin par la porte ouverte d'une salle de classe. Au fond à droite du couloir, il y a la destination qu'elle m'avait recommandée de visiter : Le Centre de documentation Robert-Garry. Une bibliothèque dédiée avec de nombreux ouvrages en trois sections principales : Chine, Japon et Corée. Quand j'entre, j'aperçois une machine de typographie chinoise. Je m'évade entre les falaises du Japon. La littérature, la photographie, l'architecture, les traditions artisinales, je pourrais rester quelques jours dans ce lieu à lire, partager avec les autres, mais cela ne me donnerait toujours pas un job.

Au moment de partir du lieu, une femme m'interpelle :

— Vous êtes souvent au café […]

— Oui ?!

— Je vous vois de temps en temps. Êtes-vous étudiant en études asiatiques.

— Non, juste un curieux et amoureux des cultures d'Asie.

— Vous savez, c'est un peu compliqué mais même sans être étudiant vous pourriez emprunter les livres par accord de prêts entre les bibliothèques.

(Je souris et hôche la tête. Elle continue)

— C'est vraiment dommage. Certains de ces livres ne sont pas empruntés pendant des dizaines d'années. Mais maintenant… il faut dire… tout est accessible de manière électronique.

— Oui et le lieu est difficile à trouver. Vous devriez créer un blog en plongeant dans les fiches des livres les moins empruntés afin d'en parler en ligne.

Nous échangeons quelques mots de plus. Et puis je repars la tête plein de rêves. Il y a déjà deux sites pour les études japonaises et un pour les études chinoises, ainsi qu'un portail de veille sur le domaine. Allez au moins voir l'exposition dans le couloir et les deux machines de composition typographique.

Le matin, un tigre qu'elle a glissé dans mon sac. Une table en terrasse, un café au lait et le livre du thé pour attendre le moment de la rencontre. L'appaisement, l'oubli de soi et l'ouverture des idées échangées.

Le compte-rendu de la rencontre entre Julian Assange (Wikileaks) et Eric Schmidt (Google) est à lire en détail. Il y a de nombreux points sujets à discussions. J'ai cependant retenu un thème que j'ai croisé dans un contexte complètement différent très récemment.

À se demander si le réalisateur du film After Earth est en contact avec Julian Assange. Bande annonce. Je n'ai pas vu le film.

Je suis un grand consommateur de feeds (atom, rss, etc). Ils me permettent de suivre un bon nombre de sites Web. Russel Beatie a récemment publié un billet à propos de l'écosystème des feeds avec une orientation très économique. Il remarque qu'il est difficile d'établir une rentabilité autour des feeds que l'on soit producteur de contenu ou bien créateurs d'outils pour traiter ces feeds.

Avoir une opinion sur un sujet essentiellement orientée dans un contexte de rentabilité est une attitude qui me dérange beaucoup. Non pas à cause de la tentative de création d'un revenu, mais en éliminant de fait d'autres modèles sociaux d'existence et de partage.

Dans son billet il identifie quatre enjeux particuliers :

• Droits sur le contenu : Entendre ici l'éternel sérénade sur la protection du contenu et sa monétisation. Pas un enjeu unique aux feeds.
• Autorisation d'accès : Dans le cadre des outils Web, la délégation de son autorisation à un service en ligne. Pas un enjeu unique aux feeds.
• La taille du marché : Le marché est bien plus petit que d'autres technologies. Pas un enjeu unique aux feeds.

Ce n'est finalement pas très convaincant comme argument. L'autre enjeu est celui de la technologie. Mais une fois de plus son argument est faible. Reprenons un peu ce qu'il entend dans cet enjeu.

Formats nuls ?

RSS and Atom are really crappy formats to deliver web content updates. XML is brittle and bloated, parsing is painful, … : RSS 2.0 et Atom (RFC4287) sont des formats XML. RSS 1.0 est un format XML avec un modèle de données RDF. Les formats ne sont pas plus nuls que tout autre format. Ils sont juste à prendre dans le contexte social du Web où les formats sont torturés par les outils, les auteurs, etc. Rien de nouveau et vrai peu importe la technologie. Dès qu'un format n'est pas respecté, le parsing devient un enjeu.

Cependant un des enjeux propes à Atom et RSS est celui du mélange de contenu. D'un côté l'enveloppe qui sert à l'information de mise à jour et de l'autre le contenu du billet. Il y a une petite notion de XML-RPC qui rend certainement plus difficile l'échange des données.

Plus loin dans son billet, il propose : My best guess would be to replace polling RSS for updates with JSON API calls, but it doesn't necessarily have to be that radical. A model to look towards would be Facebook's Open Graph API. Après la poudre de perlimpinpin, et l'eau bénite, l'arme ultime du moment sont Saint JSON et Saint API, deux sauveurs miraculeux de tous les troubles de l'humanité. Ce qui est oublié à chaque fois dans cette rhétorique, c'est que ces APIs sont « plus stables » car elles sont contrôlées par une seule source. Dès qu'elles deviennent des formats libremement implémentables et largement implémentées, les erreurs feront partie du jeu. En revanche, trouver un moyen d'avoir une mise à jour plus atomique est intéressante mais complètement orthogonale au format.

Normalisation des meta-data

Il poursuit : … meta-data standardization is minimal … . Les efforts d'extensions normalisés et communautaires ne sont pas un problème de technologie, mais bien un enjeu d'effort collectif pour étendre Atom ou RSS. Rien n'empêche de le faire, mais les acteurs n'ont pas su trouver de consensus ou d'intérêts autour d'extensions largement partagées. Encore une fois je ne pense pas que ce soit un véritable enjeu.

Mises à jour

Et puis … updates are all or nothing. Celui-ci est un véritable enjeu du format. Un feed contient un certain nombre d'éléments. À chaque fois qu'une mise à jour est réalisée, l'information la plus ancienne est enlevée, et la nouvelle est ajoutée. Pour obtenir le feed mis à jour, il faut demander la ressource au complet. Imaginons un feed avec 20 informations, si l'une est changée, il faut télécharger l'ensemble du feed pour seulement environ 1/20 qui a réellement changé. Ce n'est pas une bonne utilisation de la bande passante.

Je me demande souvent ce qui aurait été plus efficace. On peut imaginer un feed maître contenant juste l'information de statut et pointant ensuite vers les conteneurs individuels des billets. C'est à dire deux requêtes HTTP au lieu d'une mais moins de bonne passante consommée. Ce serait à tester en termes d'efficacité. Bande passante ou latence ?

Réaliser un diff est un peu plus complexe car cela signifie que le client est capable de gérer les différentes versions de diff et a une sorte de diff original.

Les utilisateurs ne comprennent pas

Again, regular users have never, ever understood the concept of newsfeeds, … Difficile. Les gens ne comprennent pas mieux les sites Web. Je pense plutôt que l'outil feed n'a jamais été vraiment un outil de travail pour nombre de personnes et donc il n'y a que peu de nécessité d'apprendre à utiliser un outil spécifique pour. D'autant plus que ces mêmes utilisateurs comprennent très bien la notion de statut des réseaux sociaux. Il y a peu de différences entre les deux. Si tous les clients mails avaient eu des fonctions de lecture de feed, peut-être l'histoire aurait été différente. Peut-être.

… and the browser makers have never agreed on how to handle them, leading to general chaos and confusion for everyone involved. Oui. Il n'y a pas réellement d'interfaces par défaut dans les navigateurs pour gérer les flux de manière utile. Opera avait quelque chose d'intéressant mais pas assez fini.

Coût de maintenance

Servers (or cloud services) are expensive, and RSS/Atom feeds are incredibly inefficient, making bandwidth and storage costs non-trivial (though, admittedly, a lot less expensive than it used to be).. C'est à peu près le même point que précédemment. Au final quand on dissèque un peu le billet de Russel Beatie, on se rend compte qu'il fait finalement peu de points utiles.

Les mots que j'entends, que je lis autour de moi.

« Appelle moi quand tu arrives ? »

« J'arrive dans 5 minutes. »

« Je suis dans le train. »

« Nous embarquons dans l'avion. »

« Je suis dans le café X. »

Je me dis que parfois il devrait y avoir des messages dans les lieux rappelant « Ont-ils vraiment besoin de savoir où vous êtes ? »

13 ans que cela dure.

Okakura a publié Le livre du thé en 1906 en langue anglaise afin de faire découvrir la cérémonie du thé. Il en profite pour situer le contexte entre les civilisations réciproques. Deux passages sur les clichés de l'occident à cette époque à propos du Japon ainsi que des japonais à propos des occidentaux.

Sans commentaires.