Et pouf le compte XMPP DuckDuckGo !

Et voilà, j’en parlais hier, c’est vérité aujourd’hui : j’ai maintenant un compte XMPP chez DuckDuckGo qui me permettra d’éviter l’un des problèmes « cachés » de la politique de Google : l’archivage automatique de toutes les conversations.

En soi, ça ne paraît pas grave.

Mais, à titre personnel, j’estime que ce qui est dans Jabber est du domaine de l’oralité, et ne doit donc pas être archivé (contrairement aux mails, par exemple).

Bon, la conséquence, c’est que je vais migrer mes contacts vers mon compte GMail professionel ou vers ce novueau compte DuckDuckGo. Ca « devrait » être sans douleur …

Twit … talk !

Comme vous le savez, je suis fan des bots Jabber (même si je n’ai hélas pas encore pris le temps de me frotter à cette technologie, alors que pourtant, avec Gaelyk, c’est de la rigolade). je suis en particulier fan des bots twitter, puisque j’utilisais jusqu’à présent comme client Twitter principal tweetjid.
Eh bien tout ça, ça a changé !
j’utilise maintenant le bien plus puissant TwiTalker.
Enfin, quand je dis plus puissant, il manque quelques liens, deux ou trois bricoles.
En revanche,c e qui ne manque pas, ce sont les commandes. Regardez-moi cette liste !
Et comme TwiTalker est conu pour s’intégrer à Google Talk, je l’ai dans mon GMail, mais aussi dans Pidgin, ce qui est un peu plus pratique.
La seule chose qui me chagrine, c’est cette histoire de clarification de l’utilisation de l’API de twitter. Mais bon, tant que ça dure, je ne vais pas me priver de cet excellent service (qui comble un trou laissé béant par Twitter).

GMail et le RDF

Vous vous souvenez que je vous parlais avant-hier de Shelf, et de la possibilité, intéressante selon moi, d'avoir un bot jabber à qui on pose des questions (du genre "qui a son anniversaire aujourd'hui" ou "c'est quoi l'adresse pro de Jérôme") et qui nous fournit des réponses pas idiotes ? Bon, comme diraient deux amis, ça chauffe dans le chaudron.
J'ai donc jeté un oeil un peu plus pointu à ces histoires de RDF, SPARQL, … et GMail.
Bon, évidement, la première chose qui arrive quand on se plonge là-dedans, c'est une bonne envie de vomir. Parce que bon, SPARQL, c'est tout sauf sympa, en fait. Cela dit, c'est extrêmement puissant. Regardez par exemple ce que les gens de DBTune s'amusent à faire avec xoperator et un back-end RDF de musique : Playing with SPARQL and XMPP. Bon, je ne vous en voudrai pas de ne pas tout comprendre, parce que le SPARQL, au niveau de la syntaxe bizarre, c'est un peu le grand champion, loin devant le SQL et le Brainf*ck. Cela dit, il faut bien reconnaître qu'avec un peu de traitement du langage naturel, on pourrait quasiment imaginer une interface demandant gentiment au back-end des informations, qu'il serait très content de nous fournir.
Et ce back-end, quel est-il ? Supposons plutôt, pour la beauté de la chose, que je parle de mon back-end. De quelles sources d'information j'aurais besoin pour alimenter ce genre d'usine à gaz unifiée ?
  • La wikipedia, bien sûr (euh, pardon, la DBPedia)
  • Mon blog, bien sûr (et alors ça c'est quand même pas trivial, de transformer en RDF du HTML tout simple).
  • Peut-étre même mes liens, parce qu'ils sont raisonnablement bien taggés, et du coup facilement accessibles.
  • Et peut-étre aussi StackOverflow, parce que c'est une base de connaissance sacrément bien qualifiée (surtout que les gens de l'entreprise éponyme sont de suffisement bons citoyens du web pour fournir réguliérement un data dump régulier … regardez ce data-torrent-RSS – il est moche, cet espéce d'acronyme, mais synthétise bien le contenu de la page : un flux RSS de liens vers des torrents ala torrentcast )
  • Enfin – et surtout – un peu de ma vie chez Google (parce qu'avec mes mails, mon flux RSS public qui n'est pas pour les enfants, et quelques autres choses, il y a moyen d'accumuler de l'information)
Et en fait, c'est surtout ça qui est chouette. Google met à disposition mes données publiques dans un format compatible avec RDF. Pour les données privées, il existe évidement des APIs pour tout, sauf les tÄches de GMail (c'est moche, mais c'est comme ça). Du coup, je pourrais tout à fait, si j'avais le temps et que je comprenais ces histoires de web of data, me faire un petit bot Jabber (oui, exactement, avec Gaelyk, je vois que vous suivez) qui accéde à toutes ces sources de données et me présente l'information sous une forme humainement lisible … Mais est-ce que j'ai le temps ?

C’est pas mal, comme idée, ça

La semaine dernière, sur The Tao Of Mac, Rui Carmo mentionnait un logiciel mac spécifique, Shelf.

Intrigué par ce soft dont je ne connaissais rien, j’ai été y jeter un oeil, et force m’a été de reconnaître que le concept est très intéressant : à partir d’un nom, retrouver toutes les informations dont on dispose sur quelqu’un pour pouvoir discuter avec lui de la manière la plus efficace possible, c’est évidement intéressant. Seulement, c’est mac-centric (et, par extension, platform-centric). Or aujourd’hui, l’ordinateur n’est plus le centre du monde. Et cet outil, à priori bien pratique, c’est un peu une espèce de moteur de recherche de personne dans l’ordinateur.
Toutefois, l’idée m’intriguait, dans le sens le plus positif du terme, parce qu’il s’agit là d’un authentique objet science-fictif. Depuis des dizaines d’années, je lis des romans où les personnages, en se connectant à « linfosphère », « la matrice », « le réseau », arrivent à avoir, dans une espèce de réalité augmentée bizarre, des informations en temps réel sur leur interlocuteur du moment. Je ne vais pas vous faire la liste complet, mais dans les exemples les plus immédiats, il y a … l’étoile de Pandore (que je vais d’ailleurs revendre, mais c’est une autre histoire), Oblique, La reine des anges, et tant d’autres …
Et donc Shelf, c’est la promesse, d’accéder au même degré d’ubiquité de l’accès à l’information. C’est-à-dire que l’ordinateur n’attend pas que je lui pose la question pour me donner les informations Personnellement je trouve ça franchement balaize.
Et je me suis donc demandé ce que je pouvais trouver d’équivalent …
A bien y réfléchir, c’est quand même assez conceptuel : en fonction de ce que j’ai sous les « yeux » (pour simplifier on va dire sous le curseur/sous la souris), l’ordinateur va aller chercher des informations dans tout l’internet qui auront une chance de coller à ce que je regarde. Pas facile. Voire même complètement dingue. Cela dit, si vous regardez un projet comme Google Instant (et ses multiples déclinaisons), il semble bien que ce soit une idée intéressante. J’en étais là de mes réflexions quand je suis tombé (ouille, ça fait mal à chaque fois) sur un n-ième projet du web sémantique (au passage, cet article explique plutôt bien les enjeux du web sémantique) visant à rendre ça utilisable en langage naturel : xoperator. Bon, comme à chaque fois avec le web sémantique, j’ai eu l’impression de me noyer dans une mare de boue, alors qu’il s’agit somme toute de rendre le web des humains lisible par les ordinateurs. cela dit, ça m’a permis de comprendre un truc (que je savais somme tout déja) les bots jabber, en terme de communication de données, c’est l’avenir. Parce qu’xoperator, ça n’est ni plus ni moins qu’un bot jabber, certes beaucoup plus compliqué que les autres, mais un bot jabber avant tout. Tiens, remarquez en passant que pour écrire des requêtes compatibles avec xoperator, le groovy, c’est encore une fois une bonne idée 🙂
Et puis ça m’a aussi permis de comprendre un truc : si je crée un bot jabber qui, par exemple, hein, accède à mon compte gmail pour lire toutes les infos des contacts, et que mes infos de contact sont « riches » (c’est-à-dire, par exemple, qu’elles incluent des adresses de site web, des dates d’anniversaire, des photos, bref, toutes ces informations que Shelf fournit), je peux tout à fait disposer d’un équivalent de Shelf qui au lieu de faire turbiner mon PC ferait turbiner l’internet, ce qui serait vachement bien, non ? (cela dit, à voir les screenshots de xoperator, ça semble déja exister, quoique d’une façon bien plus complexe, je trouve, mais ça, c’est l’effet sémantique : personne n’y comprend rien).

Twitter dans Jabber

En parlant de façon de dialoguer avec le monde, l’un des sites les plus typiques est évidement Twitter. Twitter, je lui envoie des cris dans la nuit, et il se charge de les renvoyer à la terre entière. Bon, c’est pas faramineux, mais apparemment ça les fait vivre.
Et comme je vous le disais juste avant le week-end, j’ai maintenant tendance à considérer que la ligne de commande, ça n’est pas le navigateur, c’est Jabber (et donc son client sur ma machine, en l’occurence Pidgin – ou Gmail, mais c’est moins bien). Du coup, je devais évidement fouiller un peu du coté des interconnexions entre Twitter et Jabber. Et permettez-moi de vous dire que c’est une longue histoire.

Il y a bien longtemps, quand les gens de Twitter avaient la bonne idée d’utiliser XMPP comme protocole de back-end, il existait une passerelle « officielle » jabber vers twitter. Seulement, à cause de considérations internes, ce temps heureux est terminé. Du coup, maintenant, il faut reposer sur des solutions tierces qui peuvent ne pas marcher correctement :
  • Tweet.IM, par exemple, a l’air très bien, dispose d’une liste de commandes impressionnante, et se connecte à Twitter via leur mécanisme d’OAuth (ce qui fait que tweet.IM ne voit jamais mon mot de passe, et ça c’est essentiel). Malheureusement, après à peine vingt minutes d’utilisation, j’ai arrêté de recevoir les updates … Ce qui vide l’expérience de sa substance; Cela dit, c’est vachement bien pensé, parce que chaque message privé que je reçoit apparaît sous la forme d’une nouvelle discussion.
  • excla.im est un bot jabber développé en Python sur Google App Engine (quasiment comme je l’écrirais, en fait) et qui semble ne permettre que l’envoi de message. Et je trouve ça vraiment dommage, parce que l’un des intérêts majeurs de XMPP, c’est la communication bidirectionnelle, non ? Alors même si c’est difficile – ce que je veux bien croire étant donné les limitations de Google App Engine – il faut tenter le coup.
  • Twitterspy, quant à lui, semble assez complet, malgré son défaut terrible de me demander mon login et mon mot de passe (ce qui me suffit en fait pour ne pas l’utiliser).
  • tweetjid, lui, semble assez simple, et utilise également OAuth et Google App Engine (en même temps, pour développer un bot Jabber, GAE, c’est le pied). Son seul défaut, c’est de me forcer à écrire UPDATE pour envoyer un nouveau statut, quand j’aurais largement préféré, comme dans tweet.im, ne rien avoir à écrire comme nom de commande pour ce qui est l’action par défaut.
  • twitter-xmpp marche exactement de la même manière, mais comme je n’arrive pas à m’authentifier avec le module OAuth, ben je vais pas vraiment pouvoir le tester, hein.
Du coup, j’utilise pour l’instant tweetjid en test, avant de pouvoir me décider plus avant. Mais si jamais ça marche, je crois que j’abandonnerai avec joie le site web de Twitter, que je trouve pas vraiment moche, mais pas fabuleux non plus, en fait.

Les bots Jabber

Je parlais donc hier ou juste avant) de mettre une todo-list dans Twitter, avant de me rabattre sur Google Tasks. En fait, j’ai compris un truc durant cette recherche, c’est que si un truc est en train de devenir la ligne de commande de l’internet, c’est bien Jabber (et non Twitter, comme certains le pensent).
Pour prendre un exemple près de chez moi, à l’heure actuelle, je parle déja à un certain nombre de bots via Jabber :
  • Hudson (enfin, quand il veut bien me parler)
  • StackOverflow (très pratique pour « sniper » sur des questions dont les réponses sont facilement trouvables en deux coups de google)
  • Ohloh (même si je ne m’en sers pas assez pour indiquer l’avancement escargotesque de gaedo)
  • Google Translate (là aussi, c’est assez rare, parce que l’un dans l’autre je me débrouille plutôt bien)
Tout ça à travers (le poche mais pratique) pidgin. D’ailleurs, à un moment, j’utilisais ce même pidgin pour consulter twitter via l’un de ses plugins. Pour faire un petit apparté, je trouve d’ailleurs singulièrement triste que les clients Jabber pour Windows soient, pour l’essentiel, des portages de clients Linux (encore plus laids et mal fichus graphiquement que Pidgin) alors que MacOS dispose d’un client incroyablenet élégant … Adium. Ah, si il existait un client pour Windows s’inspirant d’Adium plutôt que de Psi, ce serait le paradis !
Bref …
Je disais donc que j’utilisais pendant un moment un plugin pour maquiller Twitter comme un contact Pidgin, ce qui avait quelques avantages, mais également l’inconvénient majeur d’afficher encore moins d’infos que le site web de Twitter (ce qui diminue largement l’aspect social de la chose).
Et en fait, ce qui faisait que je cherchais à intégrer ma todolist à twitter, c’est avant tout que je cherchais à interragir avec elle comme, en un sens, avec un majordome qui se contenterait de me rappeler la liste des choses à faire. Tout à fait dans l’esprit de todo.txt pour lequel le fichier n’est en fait qu’une base de données qu’on interroge via quelques commandes.
Du coup, évidement, j’ai demandé à google. Si j’avais été fidèle à ce que j’expose ici, j’aurais plutôt utilisé le ThinkBot, mais je ne sais pas trop comment le test.Toujours est-il que Google m’a donné l’adresse du bot todo@jabber.org auquel je peux accéder depuis GMail (bien !), qui est codé en Groovy (encore mieux !) mais qui hélas se contente de stocker ma todo-list dans une base de données. J’aurais largement préféré qu’il aille stocker les infos directement dans Google Tasks. Bon, d’un autre côté, ça me donne excuse pour jouer du gaelyk pour créer mon propre bot jabber (après tout, ça fait partie des choses dont je gave mes connaissances, et sur lesquelles il faudra bien un jour que je m’use les dents). Et pour ça, merci gaelyk !
Et puis ça me permettra de faire le seul truc qui puisse me motiver pour ces tâches toujours chiantes : un peu de serious gaming à la Epic Win 🙂
Tiens, ça me donne presque envie, du coup ! En fait, le seul truc qui me manque, c’est sans doute l’API pour aller lire et écrire les tâches dans Google Tasks … Et ça, si vous la connaissez, je serais bien content d’avoir son url ! (mais à prior, ça se trouve pas sous le sabot d’un cheval … j’espère que je pourrais utiliser HtmlUnit depuis Google App Engine, mais j’y crois moyen).

Hudson est dans la place !

Je ne crois pas avoir déjà parlé dans ce blog (ou ailleurs) de Hudson. Et pourtant, il le mérite le bougre !
A la base, Hudson est un serveur d’intégration continue. C’est simple, comme mot magique, non ? ca veut dire que quand on développe son logiciel, régulièrement, Hudson va aller se connecter au système de gestion de source pour voir si on a fait des modifications. Et si c’est le cas, et bien Hudson va se charger tout seul de recompiler le projet, d’exécuter tous les tests unitaires, et éventuellement de le déployer et de générer le site avec les rapports de documentation.

De cette manière, si j’écris un code incorrect, très rapidement, Hudson va me le dire (et le dire à toute l’équipe). Bon, ça c’est la base. Une base très intéressante, puisqu’on considère dans les milieux du développement que la remonté d’erreurs précoce est le gage d’un développement rapide et « é peu prés bug free ».
Comme hudson est quand même un logiciel moderne, il supporte un système de plugins qui fournit des choses utiles, et d’autres moins.
L’un des plugins au sujet duquel j’ai eu longtemps des doutes, c’est le plugin Jabber. je ne voyais en effet pas quel était l’intérêt de laisser Hudson chatter avec nous. Et bien hier soir, mes camarades de dooapp m’ont montré que c’était trop loin d’être un gadget pour pouvoir être ignoré. Pour avoir vu une démo, c’est complètement bluffant : on demande à Hudson de builder un projet, et il le fait !
On lui demande dans quel état est un projet, et il le dit. C’est peut-être moins joli que l’interface web, ça ressemble sans doute un peu plus à une ligne de commande YubNub, mais c’est quand même sacrément chouette. Et en plus, la plupart du temps, les développeurs ont un coté geek de la ligne de commande qui leur fait apprécier cette interaction.
Pour finir, mes camarades de dooapp misent aussi sur un truc que j’ai déjà vu, qui peut être un peu risqué mais qui est riche de bénéfices : passer de l’intégration continue au déploiement continu: quand Hudson builde l’un de leurs projets, il ne se contente pas de compiler et tester. Non, en plus, il déploie le war sur le serveur d’application choisi (et je me suis laissé dire qu’à terme, une suite de tests fonctionnels automatisés va même être exécutée sur ce serveur d’application de « prod »). Je trouve ça plus que bien !