I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)


Entries in web (25)


More on WS directories - is over

In my previous post, I was reporting that was badly dysfunctional. Well, the problem has been solved, is no more. On their home page, they blame the market for being too slow to adopt Web Services. Well, I do agree that surprisingly the adoption of web services has been fairly slow; yet, you can't blame the market for obvious bugs in your web application.

Also, (my company, which provides time-series forecasting web services) has been listed in, a new flashy - good looking - web services directory. Yet, only 200 web services are listed at this point. I guess that somehow BindingPoint was not entirely wrong in their analysis, the adoption rate for web services has been really low for a technology that has been supported by so many major players (MS, Sun, Ibm) for several years.


What do most WS directories have in common?

Most Web Services directories have one thing in common: they are totally bugged at the point of being totally unusable. Indeed I have tried to submit the Lokad Forecasting Web Services to several directories. Namely:

  • registration process crashes and the ASP.Net default exception page.

  • can't even login, gets a fatal cgi-bin error while trying.

  • website painfully designed, registration succeeds but submission crashes.

  • "Submit URL" gets me to a page Service Temporarily Unavailable (it has been that way for the last 2 weeks)

It's almost unbelievable that so many top-ranked web sites (try web services directory on Google) are not even able to achieve something as simple as a registration process.

On the positive side, I have found which is by far the most usable WS directory out there IMO.


Blogosphere quatitative elements, a few slides

Being part of the Corps des Telecoms, I have been assigned for a modest blog study within the scope of a communication course. I have found the subject highly interesting because blogs open whole new directions of research and whole new methodologies. Indeed, contrary to most usual communication events (ex: person-to-person talks), it's potentially possible to retrieve most of the blogosphere content through web crawling intensive methods.

The slides of the talk have been uploaded. Disclaimer: don't take the content for granted, the professor in charge of the communication course was thinking that this talk was a big pile of stupidities from the first slide to the last. My personal opinion is quite different on this matter. Well, I can't make everybody happy.


Typo hunting: get some weapons first!

It's just too hard to spell check your text by hand (or it requires an unreasonable amount of time). Before you actually get a spell checker, you might not even realize how many typos you produce. I have just downloaded today the FireFox RC1 that includes a web form spell checker. My first target for typo hunting was an intranet wiki I am working on. I feel that I won't ever go back to a browser that does not provide such a feature natively.

My second target for typo hunting was the source code of a Asp.Net application I am currently developing. Since Visual Studio 2005 does not provide a native spell checker (shame! such feature should have been implemented years ago), I have used the MailFrame CodeSpell product. CodeSpell has a really nice VS 2005 integration. On the minus side, the dictionary is a bit light at the present time (nchar or aspx not being part of the default dictionary for example) and I did experience of a few crashes while playing with the custom user dictionary.

A funny aspect of applying this source code spell-checker was to discover that 3rd party [*] XML documentations present in my .Net solution were no less typo-crippled than my own code. If automated spell-checking is not part of your development process, well, it should.

[*] Elmah and Telerik are both advised to get some spell-checking tools :-)


Your e-mail is your username

The 30-years-old unix pattern for user management involves a UserName, Password pair associated to a unicity constraint on the usernames. On most web applications, this pattern has been enriched as a triplet UserName, Password, Email with, usually, a two-fold unicity constraint both on usernames and on emails. But is there any good reason to distinguish e-mail from username?

By looking at the major web players (Google, PayPal, Amazon ...), the answer is negative without any doubt. This pattern has already been widely adopted. Yet, it's still not stated a being an obvious web design best practice. For example, there is still no simple ways in ASP.Net 2.0 to enforce such a policy through the CreateUserWizard. Let's review the arguments in favor of this pattern.

  • UserName and Email are redundant because both are used as user identification keys. For the user, it means more information to provide at the registration step, and then more information to remember.

  • Choosing your UserName is often painful because most of the time your favorite username is already taken (unless you got the chance having a pretty unfrequent first name like joannes).

  • UserName is not idiot-proof because most non-web traditional services (your bank, your mobile operator) do not rely on your name to get you authenticated.

A mighty, but somehow recursive, argument is that since big players (Google, PayPal, Amazon) are doing that then doing anything else is only going to hurt a large number of users.

The only real drawback of this approach is the lack-of-privacy concern i.e. you may prefer your e-mail address to stay invisible to the other users of the website where you are registering. Yet IMO, the Display Name is a much more appealing and user-friendly concept compared to the username approach.

Ps: does not follow this pattern. I have no good excuse for this situation. I was just young and inexperienced at the time.