Tales from the Evil Empire

We went skiing on Sunday (which was an especially well-named day this time) while everybody was eating nachos in front of the TV.
What a day! The snow in Stevens was perfect (14" of new snow in the last 48h), the sun was shining, I was in great shape and the resort was virtually empty.
Best skiing day this year, by far.
Couldn't there be several Super Bowls every year? Pretty please?

Nikhil has an excellent post about developing a client-side behavior with Atlas. If you're thinking about developing your own Atlas components, this is a must-read:
http://www.nikhilk.net/Entry.aspx?id=107

Karl wrote some feedback about the eWeek article:

http://www.eweek.com/article2/0,1895,1917558,00.asp

Just kidding. But I think that got your attention :)
Seriously, there are things I really like about Javascript (like it being a dynamic language), but some things are just... So unexpected they just look plain wrong.
For instance, what do you think this evaluates to:

"" == 0

Of course, I gave you enough clues for you to guess that it does return the wrong thing. Yes, this is actually true. Empty string equals zero. Isn't that a beautiful feature? Isn't that going to make your life so much easier? No? Really? Well, I agree with you, this is FUBAR.
While I can understand that Javascript would evaluate both empty string and zero to be equivalent to false in contexts where a bool is expected, I would expect both sides of an == operator not to be such a place. To tell you the truth, I think it's kind of wrong even in boolean contexts because it's a bug attractor, but anyways.
If anyone has a reasonable explanation for this, I'm all ears.
Oh, and about a workaround... You can use toString() on both sides of the equals operator once you've checked that they are not undefined or null.

UPDATE: as some have pointed out in comments (and I should have researched that), you can use the strict equality operators (=== and !==) and get the expected results on recent browsers (on older browsers you can compare the types as well).
In a nutshell, I think the problem here is that the initial specification for the == operator was absolutely wrong, but changing it would have been a breaking change so they had to add the === operator to finally get it right. So for all useful purposes, I can see no reason to use == instead of === except to save one character.

While binding a Menu (or TreeView: everything in this article applies to TreeView as well) to a SiteMapDataSource is very easy, it can prove challenging to find how to extend the site map with custom properties and use these extended properties in a Menu. This sample shows how to add icons in a sitemap-driven menu.

MSDN France publishes an interview they made of me in November. The subject is Atlas, but it's in French only. Thought some of you may find it useful anyway (and I don't get interviewed every day, so I thought I'd do some bragging).

Here's an example I just found in the MSDN JScript documentation: