Desgrange.net

Email protocols history

A long time ago there was several protocols to send a message from a computer to an other one. There was a protocol per network (the internet was not really born at that time). Those protocols were not compatible between each others. So for instance, if you were using FidoNet, you were not able to send emails to people using BITNET. Hopefully some people created some gateways to transfer emails from a network to an other one (but it looks like it was quite a nightmare). At some point in time, ARPANET and its email protocol became the standard and other protocols started vanishing. People were now able to communicate with each other easily.

Instant messaging

Instant messaging (IM) appeared much more recently (email started in the late 60s, late 80s for IM). Personal IM became very well known in 1996 with ICQ (I still have my ICQ account! (but nobody to talk to on it anymore)). Then several other protocols appeared:

• Jabber (1998, free and open protocol)
• QQ (1998, closed and proprietary)
• Yahoo! Messenger (1998, closed and proprietary)
• MSN Messenger (1999, closed and proprietary)
• …

Of course you can't chat with somebody using MSN Messenger if you use Yahoo! Messenger. ICQ was bought by AOL, AOL created AIM (AOL Instant Messenger) based on ICQ protocol. At some point people using ICQ were able to speak with people using AIM.

In 2004, XMPP, the protocol used by Jabber, became the official IETF instant messaging standard (IETF is the group defining the internet standards (like HTTP for the web, SMTP for emails, FTP for file transfer…)).

Jabber/XMPP

XMPP as been the standard for 5 years now, but still, most of my contacts are using MSN Messenger. Why? Because they also use a Microsoft Windows based computer and Microsoft MSN Messenger is the default instant messaging software installed on those computers.

XMPP allows creating gateways to other protocols (like MSN, Yahoo!, ICQ…). The situation looks a bit like the email status in the old days. But the email standard imposed itself as the killer application of ARPANET. So, what will be the thing that will wipe out all proprietary protocols and impose the XMPP open standard?

The problem with standards is that it take time to be developed. History as shown that new versions of a standard are not implemented by all software vendors quickly, nor they are deployed as fast as possible. So changes to the standard must not happen everyday and having it quite right at version 1.0 take time.

In the meantime, other protocols evolve faster because vendors have a captive market and a better control on how the software is distributed/used (and they don't have to wait for others to implement changes).

While XMPP was on the way to be standardized, other protocols got voice then video functionalities. I had a lot of hope in 1995 when Google released it's own IM software Google Talk. GTalk is based on XMPP and add some voice extension and video extension later.

Then AOL started an experiment to allow XMPP connections to its network, Yahoo announced that they were interested by XMPP too. The chat in Facebook uses XMPP (but the network is closed, you can only talk to Facebook users), several other community websites do the same.

Nowadays

Last week, the specifications for voice/video in XMPP were released. The biggest missing features making people stay with their proprietary IM is going to be old story soon. But I'm not sure it will be enough to see a big migration to XMPP.

Those last few years, XMPP interest increased a lot and nearly all IM vendors are now looking at XMPP… except Microsoft. It looks like you will soon have the choice between speaking to nearly everybody except MSN Messenger users or speaking only to MSN Messenger users.

Of course there are lots of softwares allowing you to use several accounts at the same time (so being connected to MSN, Yahoo! and Jabber at the same time). I also have several emails account. The difference is that from my professional email account I can send emails to everybody, same for my personal email. I'm choosing the email account I'm using depending on what my "role" is. If I want to send a message to a colleague, I will use my professional email address.

In IM, you can't do that, except if you open several accounts on each protocol you use. Having a professional and a personal account on MSN, on Yahoo!, on AIM, on Jabber… With all those protocols I currently have 9 accounts. And you know what? I like keeping things simple. For my email addresses I have started closing several accounts, keeping only the mandatory ones (my personal email address and the ones I have to use for my job). And I would really like doing the same for IM but you know what? Here I can't do what I want. Why? Because if I close my MSN account, I will lose contact with a lot of people.

I feel a bit like in jail. Worse, I feel like my friends are in jail too but they are saying "Where do you see a jail? There's only walls and fences".

Anyway, lots of people are using GMail now, and there is a chat embedded in GMail. Of course this chat uses Google Talk so it uses XMPP. Even if I don't really like GMail, I prefer having my friends using GMail/Google Talk than Hotmail/MSN Messenger (or whatever the name of those services are this week).

ejabberd

Since XMPP is an open protocol, anybody can implement it. There are several XMPP clients (Pidgin, Adium, Kopete, Trillian, iChat…) and there are also several servers.

In XMPP servers there is well-known one: ejabberd. This server is open source and written in Erlang. Ejabberd use the power of Erlang to be fault-tolerant, redundant, scalable, <add here any cool property a server should have>.

And since XMPP is a decentralized system, I can install my own server (as I did for my email server for instance).

Installing ejabberd on debian is as easy as usual:

$ sudo apt-get install ejabberd

To configure it, you just need to change the domain name to serve in /etc/ejabberd/ejabberd.cfg. If your domain name is example.org change the following:

%% Hostname
{hosts, ["example.org"]}.

And set the admin user:

%% Admin user
{acl, admin, {user, "admin_user_name", "example.org"}}.

Add a user with the following command:

$ sudo ejabberdctl register user_name example.org password

Restart the server. Done.

Of course there are a lot more parameters to change if you want to fine tune it. You may also need to create a SRV entry in your DNS if your server is not the one serving "example.org" (but "im.example.org" for example).

For a long time now I have seen several "unusual" ways to produce electricity but mostly never seen them in use in real life devices.

As somebody working with a laptop, I can tell that the amount of electricity used by my computer does not allow the battery to last for a long time (maybe 4 or 5 hours if I'm doing nearly nothing with bluetooth and wifi shut down and screen backlight set to the minimum, and about 2 hours doing more CPU consuming stuff).

Computer makers are usually working a lot on:

• making less power hungry computers,
• making higher capacity batteries.

But I thought more stuff could be done, add electricity generators in the computer :

• making electricity when pressing a key on the keyboard (keys with magnets/coils),
• adding solar panels on screen's back (maybe on the front with a transparent solar panel?
• use vibrations to generate electricity (several implementation exists using magnets, piezo-electric systems…),
• use temperature gradient (thermoelectric effect)

But then, we need to check the full energy usage here. If those generators cost more energy to produce and recycle than the "free" energy provided/saved, we should not use them.

My example was about a laptop, but those technologies can be used in lots of other devices (and several are already in use but not widely):

• In wall clocks with thermoelectric effect (temperature gradient between the wall and the air) and solar panels.
• In wristwatches with vibrations.
• In cellphones with solar panels, vibrations.
• In wireless keyboards with keystrokes.

Well, anywhere a battery is in use.

Lundi 25 et mardi 26 mai il y a eu XP Day France 2009, j'en avais parlé dans un précédent billet.

La conférence s'est tenue au Chalet de la Porte Jaune, près du bois de Vincennes. Le cadre était donc agréable, entouré par la nature, ça change de la FIAP des années précédentes.

Bien que la conférence s'appelle XP Day, elle n'est pas consacrée uniquement à l'eXtreme Programming. Il y a eu plusieurs conférences relatives à Scrum et comme l'année dernière on peut voir que l'engouement pour Lean est de plus en plus important, avec maintenant des retours d'expériences de tentatives d'applications de concepts Lean dans des équipes de développement logiciel.

Je n'ai pas assisté à beaucoup de présentations, mais celles que j'ai vu étaient de très bonne qualité. Je retiendrais particulièrement la présentation de Régis sur la Théorie des Centres de Christopher Alexander. Pour moi du code "beau" était quelque chose d'assez subjectif, bien que souvent beaucoup de personnes soient d'accord pour dire que tel morceau de code est beau et tel autre ne l'est pas. Maintenant je sais qu'il y a un certain nombre de propriétés qui participent à faire que le code (mais pas uniquement) soit beau, vivant, agréable. Nous autres développeurs passons une grande partie de nos journées dans du code, autant en faire un endroit agréable où il fait bon vivre… ce qui m'amène à la présentation de Dominic sur le "développement hédoniste", la recherche du plaisir et l'évitement du déplaisir. Le parallèle, entre idéalisme et cycle en V, RUP d'une part et hédonisme et méthodes agiles d'autre part, est assez frappant.

Mais XP Day n'est pas qu'une série de conférences, c'est aussi un bon moment pour faire des rencontres enrichissantes avec des acteurs des méthodes agiles, de pouvoir partager son point de vue de manière informelle avec d'autres participants.

J'ai le sentiment que les personnes attirées par les méthodes agiles ont un penchant pour l'hédonisme (cf. la présentation de Dominic) et c'est certainement ce qui fait que l'ambiance est toujours bonne. Il doit bien y avoir des conférences sur le cycle en V, ça pourrait être intéressant d'y assister pour voir si on s'y ennuie ;-).

Java Black Belt is a community website aiming at "building better developers". Given the name, it's targeting mainly Java developers but some exams cover Ruby, .NET C#…

Every user has a belt like in karate, the color (from white to black) represents user's knowledge of Java, common frameworks, tools… To get next belt you need to pass some specific exams and have a certain amount of knowledge points.

You get knowledge points by passing exams. An exam is usually a list of multiple choices questions, you need a certain amount of good answers to pass the test (around 80 % successful answers). If you fail an exam you need to wait some time before trying it again (around 15 days).

To get an exam you need some contribution points (except if you decide to follow the "Belt Track", doing the exams in a predefined order). Contribution points are obtained when writing a question, reporting problems on a question, etc. So all the questions are created by the community, voted by the users (to have them accepted or rejected).

Since I mostly didn't write anything in Java for a year and a half, I need to train myself a bit before taking an exam (I don't really want to be forced to wait 15 days before trying an exam again).

So basically the website (until the black belt) is just checking your knowledge of Java and does not check if you are really able to write good code. In order to check that, the exam to get the black belt IS a programming task, but it's not yet released (so nobody as a black belt yet).

One drawback I see is that several questions are useless. Since there is no point using Java without a proper IDE (as one of my colleagues says: "The power of Java is IntelliJ."), questions about knowing by heart all the details of Java APIs, questions like "Does the following program compile?" are meaningless.

During my (short) career, I was interviewed several times and I interviewed several people. Quite often there are some technical questions to be sure that the interviewee knows a bit of Java, so sometimes I was asking questions like the ones found on Java Black Belt. Seeing the belt somebody obtained on this website will reduce the number of technical questions I have to ask, Java Black Belt already did it.

But in fact, if I need somebody in the team I'm working in, Java Black Belt is not enough. Of course it's a hint about is knowledge, but it does not tell me how the guy works. But at least I have more time in the interview to ask those questions.

Some pics taken last year during my trip in Japan.