I was recently asked by someone who manages a librarian newsletter, why I thought that library tools did not make it in the Top 100 Tools for Learning by Jane Hart. I immediately replied that Google Scholar made it to the list.

(source)

Then I had to think back. What about the last time I used a library tool (other than Google Scholar)? I can remember bad feelings like “why is the user interface so complicated?”. Then “why can’t I find what I am looking for?”. And “why do I have to choose which database I want to search in, can’t it just search them all?”. And “why do I have to go to another, different tool, to know who cited this paper and when?”.

Beyond these frustrations, I came up with some more specific reasons why library tools are not used:

• They are not user-friendly. They were clearly designed with the “we shall train the users” motto in mind. Sorry. I do not want any training. I want you and your tools to get out of my way and let me find what I am looking for.
• You may not consider this workshop paper that appeared on the Web two months ago a “worthwhile” reference, but I do.
• It is ok for you to have to mail order a journal article and wait a week for it. Me? I want it now, on my screen, or else…
• So, your search engine covers more prestigious journals than Google Scholar? It can count citations appearing in prestigious journals with absolute accuracy? Because, of course, you can only trust the “reliable sources”. Well, you are a librarian and you care about these things, but I am a researcher and I do not care as much as you do. I have a social network, I know who are the researchers you can absolutely trust, those who I should investigate further. In minutes or even seconds, I can tell about the quality of a paper. It is not a problem for me to trim out junk: the Web has trained me well to do it. Students should learn to do the same.

My wife, before and after losing 35 pounds. Note that she had two kids in the process.

I think that the pictures are sufficiently impressive, I do not need to tell her how impressed I am.

We went to the Botanical Garden today. What a great day it was.

First, my favorite picture of the day… I caught my son Lohan as he was running:

This is Louka, being funny as usual (his left eye is all swollen):

My beautiful wife is, well, beautiful:

Finally, Lohan with Anne-Sophie:

For all my adult life, the American dollar has been worth more than the Canadian dollar, often much more. No longer! We reached parity today. Maybe Americans should reflect on what this means for them that the value of their currency is going downward so fast. (Hint: stuff is going to cost more.)

Less than a year ago, I predicted that Google would come up with a PowerPoint-like tool. They did it. And you know what? It is pretty good.

Downes had this to say about it:

What I’d really like is a slide library I can simply draw from to create presentations. But you can’t even drag and drop slides inside presentations.

To this, I reply:

• You can’t drag and drop slides within your presentation, but you can move them in the slide desk using buttons to achieve the same result.
• You can’t drag and drop slides from one presentation to another, but you can copy a slide in a presentation and copy it in another.

(Picture source)

The call for papers of the International Conference on Enterprise Information Systems (ICEIS 2008) is out. The conference will be held, next June, in Barcelona.

I do not entirely believe the title of this post. Clearly, if you hire subpar programmers, you have to settle for whatever programming languages they know. These days, it is probably going to be Java. And you could do a lot worse than choose Java. Or maybe it is PHP. Again, PHP is fine.

The real question is… should you prevent your programmers from using Ruby or Python because you worry about what will happen to the next guy who needs to maintain their code?

On this issue, Eugene makes a great point. What languages like Java offer that “crazier languages” like Ruby do not offer is builtin testing. In Java, types are checked at compile time, except of course, when it does not, such as when you use collections of objects. In languages with dynamic typing, fewer tests are done at compile time.

The solution? Simply get programmers to use unit testing more aggressively. In my experience, unit testing is relatively painless to put in place. It is a great way to document what you expect your code to do, way beyond what static typing offers.

So, next time a programmer working for you wants to use Ruby, just say yes, but require him to do unit testing.