Je code donc je suis

via Jabber.org, 2 nouveaux services (MessagingBay et ASPSMS) permettent d’envoyer simplement un SMS en ajoutant un contact dans son roster. Décidément le monde XMPP est autrement plus intéressant et innovant que le web qui se moisi depuis 18 ans avec un HTML lourdingue et des connexions stateless à 2 balles. Pour comparer avec Linux qui a 17 ans, s’il avait avancé au même rythme on serait toujours en mode console texte (façon minitel) et sans connexion réseau. Bref je rêve d’un Rebol IOS libre, malheureusement Carl Sassenrath n’a que le génie de la technique.

Ceci dit et pour enchainer avec le web et XMPP, Twitter est en cours de tester le service PubSub, j’ai hâte de voir ce que cela donnera.

Pour ceux qui ont des problèmes lors de la signature en ligne de leur déclaration d’impôts sous Linux voici la solution.

source

J’ai migré ce blog vers une dedibox V2 et je note une nette amélioration en terme de réponse. La V2 propose 1Go de RAM supplémentaire mais celle-ci n’était pas mise à contribution. Je suppose donc que l’apport du Celeron joue énormément alors que le VIA C7 n’était pourtant pas en saturation. J’en conclu que la différence du cache processeur passé de 128Ko à 512ko doit entre autre jouer fortement.

On avait plus trop de nouvelles de Jaiku depuis leur rachat par Google. Je supposais qu’ils prennaient leur temps pour intégrer le produit aux autres services de Google, mais en fait ils sont en train de l’adapter au nouveau service Google app engine : Wroom – we’re moving to Google App Engine

Jaiku est écrit en python (Jaiku runs on Python) ce qui explique en parti leur rachat plutôt que Twitter, Ruby ne faisant pas parti des 4 langages utilisés chez Google (C++, Java, Python, JavaScript).

Vu sur le blog de Seesmic la possibilité de suivre par un bot Jabber des évènements sur des contenus ou des utilisateurs. Le bot permet de tracker du texte ou des vidéos de la même manière que le bot Jabber de Twitter.

Même si Jabber / Gtalk n’est pas encore l’IM le plus usité sur le Net il n’en reste pas moins que c’est celui le plus implémenté grâce au standard ouvert qu’est XMPP. Sachant que les messageries instantanées sont au moins, sinon plus, autant employées qu’un navigateur web je pense que l’implémentation de quelques XEP tel que la XEP-0071: XHTML-IM qui permet d’envoyer au client du texte riche au format XHTML, comme le fait Gajim, pourrait aider à populariser Jabber. Les wallpapers animés dans le texte c’est le minimum syndical il parait :)

Pour faire suite à mon billet sur les lapins, voici un article très intéressant, Got applications?, de Peter Saint-Andre le directeur de la XMPP Standards Foundation. Je conseille en complément la lecture rapide de ses slides à l’eComm.

En effet même si XMPP est de plus en plus utilisé en backend, HTTP via REST est toujours autant populaire pour fournir des APIs publics. Cependant, à moins de s’appeler Google ou Amazon et d’avoir suffisamment de ressources en matériels et bande passante à gaspiller, ce protocole synchrone nécessitant des poolings n’est pas du tout adapté comme il l’explique avec l’exemple de Twitter.
Le problème de Twitter n’est pas Rails. Leur problème est de proposer un service ayant de plus en plus de succès, utilisé par de plus en plus d’applications tierces et traitant une somme considérable de données à chaque seconde. De la même manière, on ne peut pas dire que Facebook soit très rapide.
Or pour résoudre ces problèmes de tenue en charge, HTTP n’est pas le meilleur candidat… Il n’est pas concu pour maintenir une connexion client serveur ou serveur serveur, à moins de bricoler, et n’est pas concu pour conserver un état entre chaque requête, à moins de bricoler. Bref on se gausse du web2, mais c’est une vaste blague face à l’énergie dépensé en développement et en administration pour compenser ses lacunes, afin de s’approcher, de loin, de ce qui ce fait depuis des décennies et simplement sur le desktop. Certes le navigateur web est universel, quoi que là encore l’énergie dépensé pour faire fonctionner et présenter correctement un site sur tous les navigateurs est phénoménale.

Bien sûr HTTP n’est pas prêt de disparaître en tant que protocole navigateur web serveur. La question se pose, serveur à serveur et client desktop à serveur comme le propose Peter Saint-Andre. Il est plus simple de convaincre des développeurs, surtout si on obtient ainsi un lapin plus réactif :)

Non cela ne résoud toujours pas le problème entre le navigateur et le serveur. Mais qui peut croire qu’un service à succès est utilisé plusieurs fois par heure depuis un navigateur ?! L’utilisateur le veut à porté de doigt en permanence, intégré à son desktop ou à son iPhone et surtout qu’il consomme le moins de ressources possible. En sommes tout le contraire d’un navigateur …

L’avenir du développement des architectures web se dirige clairement vers des environnements asynchrones et concurrentiels. Bref des outils adaptés aux besoins. Laissons HTTP à ce qu’il sait faire : servir des pages.

On connait tous XMPP le protocole utilisé par Jabber, comme service de messagerie instantané que nous souhaiterions voir se démocratiser un peu plus.

Cependant il serait très réducteur de limiter ce protocole à un usage sur le frontend. En effet ce protocole est idéal pour permettre à des applications backend de communiquer entre elles, et ce de manière asynchrone.

J’avais écris un article à ce sujet, détaillant une implémentation de ce système avec Ruby on Rails (De la répartition de charge en Ruby on Rails).

Je viens de découvrir que certains lapins ont décidé de parler en XMPP :) Le fameux nabaztag.

Pour résumer mes recherches, il s’avère que ce robot est constamment connecté aux serveurs de l’éditeur afin de récupérer des données (mails, sons, mises à jour, ...). Or il utilisait un bon vieux pooling moisi. On imagine bien que ce fonctionnement a fini par saturer les serveurs d’autant plus que le problème est proprotionnel au nombre de nabaztag dans la nature. Ceci explique les problèmes de latences insupportables, voir d’indisponibilités observées par les clients furieux, voir aussi nabaztag-review.

Au début de cette année, la société Violet a donc modifié son backend afin d’utiliser Jabber, ou plutôt XMPP et les XEPs. Le site propose de tester cette version béta. Plus de détails de la “jabbérisation” ici beta-test-les-tagtags-sous-jabber et ici nabaztag bullet.

Violet a donc pu améliorer la qualité de son service en n’invoquant plus des pools mais des pushs serveurs -> clients, comme je le déduis.

XMPP suit donc son petit bonhomme de chemin, et il est à parier qu’il sera de plus en plus utilisé dans les backend, même si évidement les communications à ce sujet sont rare, mais on peut citer TiVo : XMPP in TiVo

La leçon à tirer est qu’il me parait vital pour une entreprise qui décide de fournir un service de qualité à ses utilisateurs, de prendre le temps de penser correctement son architecture dès la conception, d’autant plus lorsqu’on vise le grand public.
La deuxième leçon est que XMPP est l’outil idéal pour répondre aux critères de scalabilité et standards ouverts. Cependant je pense que le protocole ne fait pas tout et qu’il est nécessaire d’utiliser des outils et langages de développement adaptés à ce type d’architecture tel que Erlang mais cela fera peut être l’objet d’un futur billet.

Pour finir avec le nabaztag, je préfère de loin l’équivalent complètement libre et ouvert du tuxdroid, qui même s’il ne propose pas pour l’instant toutes les fonctionnalités du lapin ne peut que le surpasser à long terme.

Google vient de publier un service complémentaire à Gtalk, le chatback. Cela consiste en une iframe à copier sur votre site, et permet à n’importe qui de chatter avec vous sur un simple clic.
Dommage que ça utilise flash et que l’on doit ouvrir un navigateur web pour répondre, mais cela reste très pratique.

via zorglub.

Vu sur googlified. Google propose via Gtalk des bots effectuant une traduction automatique. Il suffit d’ajouter dans son client Jabber ou dans Gmail les bots que l’on souhaite utiliser, exemple fr2en@bot.talk.google.com pour du français vers de l’anglais. Cela fonctionne très bien avec Gajim bien sûr et tous autres clients Jabber.
Plus rapide et pratique que d’aller sur la page web translate. Encore un exemple de la fusion desktop/web et de l’avantage évident à utiliser des applications desktop vers des services web.

L’autre énorme intérêt de ce service est que Gtalk utilise le protocole XMPP de Jabber et ainsi n’impose pas un client desktop particulier. Service web via des protocoles ouverts et standards, nul doute que se trouve là l’évolution du web.

liste des bots

C’est l’histoire d’un FAI auprès duquel j’avais fais une demande de changement de ligne suite à mon déménagement. Cet FAI n’a pas été capable de l’effectuer ni même de commencer le dégroupage de la nouvelle ligne au bout de 23 jours, alors que j’avais fourni le numéro du précédent locataire … Impossible également de suivre l’avancée de la demande.

Lassé malgré plusieurs appels en signifiant que j’en avais besoin professionnellement, j’ai résilié et commandé un abonnement chez Free. Contrairement à ce qu’un employé de Neuf m’a dit ironiquement, la commande et le dégroupage total chez Free a été effectué en moins d’une semaine !
De plus j’ai pu me connecter au réseau de Free sans attendre la Freebox grâce à mon modem ADSL speedtouch 510 v4 (à conserver précieusement) et à ce fichier de configuration fourni dans ce forum : free.ini. Penser à bien récupérer son IP fixe depuis son compte Free pour l’ajouter dans le fichier. Free propose également les informations pour ce type de connexion : Configurer un autre modem que la Freebox

L’attitude de Neuf telecom est déplorable, alors que j’étais un client satisfait. Je ne sais pas si leur service client est délocalisé, mais je doute fortement qu’ils gagnent à gratter dessus si c’est pour perdre des clients. Pour info un ami chez Free a obtenu sa ligne 1 semaine après son déménagement …

Les telecoms sont un vrai panier de crabes, et même si Free n’est pas exempt de reproches c’est à mon avis le meilleur FAI avec Nerim orienté professionnel.