Bring It On

While trying to track the delivery of my new router I noticed I can install a local application provided by French post (called e-Como) that should notify me in realtime when my package moves toward me.

e-Como did not work too well in the end (I have my package and it still thinks that it's about 200Km away from here) but that's not what I wanted to point out.

The authors of e-Como made a classic mistake - they assumed I was running French Windows, and while trying to add the app into the startup group they hard-coded the path to the name of the Startup group (see the picture above) in French (there are more places like this in Windows where a name of a system folder is localized).

Don't do this. There is a documented way to get this information - all you need to do is to call SHGetSpecialFolderPath API. This function lives in shell32.dll version 4.71 and higher - in other words, everyone with Internet Explorer 4.0 and higher should have it. Pass CSIDL_STARTUP to it and you'll get the desired folder location.

Last week I started the process called “degroupage total”. What this means is that I am getting rid of traditional telecom operator (in this case France Telecom) in favor of a modern Internet operator (called Free) that gives me telephony, TV (free-to-air but also pay-per-view channels and possibility to stream/save up to 8 channels at once) and Internet (I hope to get about 20Mb down and 1Mb up, we'll see) through a single ADSL2 line. This does have a drawback - if your Internet connection goes south, you lose everything at once. Luckily for all of us and thanks to the wonders ;) of mobile telephony, even in this case we are never totally cut off from the world.

During the process there was no disturbance of the service and my Internet connection still works just fine. The phones do not work now but will when I install a special modem box that Free sent me (unsurprisingly called  the Freebox) and attach the phone and the new router to it (my old router was also a modem and I can't use it any more).

I am really looking forward to setting this all up. Not only that my wife gets the chance to watch a lot more (hopefully) interesting TV, but we also get to phone for free locally and toward half a Europe and the USA.

You might think of Visual Studio 2005 code snippets as text replacement tool, but apparently it's more than that.

Check this out: type switch and press tab  - as expected, you get this:

switch (switch_on)
{
  default:
}

The bold parts is for you to fill in. What do think will happen after  you fill in the value? In my case, I typed the name of the local variable of type SeekOrigin. And then I got this:

switch (origin)
{
  case SeekOrigin.Begin:
    break;
  case SeekOrigin.Current:
    break;
  case SeekOrigin.End:
    break;
  default:
    break;
}

Visual Studio knew I was using an enum and filled in all available values! Of course, when you think of it, this makes perfect sense - not many types have limited pool of available values to use in this scenario, but when they do you'd expect to get exactly this behavior.

How is this implemented? Well, I looked into the snippet definition (small XML file whose source is distributed with Visual Studio) and found that the expansion is done by a function call to GenerateSwitchCases($expression$) where $expression$ is the thing you type in (I haven't looked yet where this function resides).

Having the ability to call functions from code snippets makes them a lot more useful and definitely more than just a text replacement tool.

Firefox is undoubtedly a good product. It's small, standard compliant, looks native on all platforms and works reasonably fast. It has a strength that is also a weakness: very minimalistic feature set. There are thousands of extensions out there that supplement the core feature set making the offer as a whole really great.

But adding more and more extensions becomes a pain in and of itself. Setting up large number of extensions on each and every machine that you own gets tedious really fast. That's why it's best if you can keep the number of extensions as low as possible.

Old habits die hard but it doesn't hurt to occasionally check if some of the extensions you've been using have been superseded by a newer variant or if a few have been consolidated into one. In my case, a few things happened recently:

• AdBlock Plus has superseded AdBlock
• IE Tab has generally replaced IE View
• TabMix Plus replaced Tabbrowser preferences and Session Saver; I am particularly happy about exchanging these two extension for one - Session Saver has The Most Horrible UI Ever Conceded ^TM and while Tabbrowser preferences worked fine it tended to forget a few of its settings; TabMix Plus replaces both and has all the features you could ever imagine to ask for

I think I have reduced the number of extension I use to about 4-5 and I plan to keep it this way.

Sooner or later you will run into this issue - you have a class X in some assembly A. Class X is internal to assembly A, but you can read that as “public to the classes from assembly A”. Now, you want to unit test this class but your unit test classes are kept in a separate assembly - let's call the class XTest and the assembly ATest. How do you go about doing this in the cleanest possible way?

Before I give you the solution, note that this is not the case where you're testing internals of the class. You are testing internals of the assembly, and that is not the same thing. You are still testing public methods of a class, it's just that this class is local to the assembly.

The best solution that you can come up on your own is to have a wrapper public class that exposes public interface (note: all “public” methods of the class X will in fact be internal) of the class X and to surround the definition of this class with #if TEST or something similar. Other variations of this like moving the test class XTest into the assembly A are out of the question - you want to keep tests separate from the production code.

Fortunately, there is a better solution if you can use .NET 2.0 - Microsoft has added a new attribute called InternalsVisibleToAttribute so you can tell one assembly to expose internals to another. This should probably be used only for unit testing as I cannot imagine any other usage that would not go against basic design principles.

I'd love to take credit for finding this solution but alas that is not the case - I've found out about this from this blog post. Took me quite a while to find it though as most discussions about this problem end up straying into different issue altogether (whether to test private methods of a class, which is not what this is about as I explained).

This would be a good time to plug TestDriven.net, by far the best unit testing helper app/add-in out there. Go get it if you don't already use it (works even with Express versions of Visual Studio!).

Every now and then somebody asks what is the direction Microsoft is going to with Avalon, ahem Windows Presentation Foundation (WPF), in respect to the UI consistency. The reason is mainly that of the few apps that Microsoft built using WPF (Sparkle and Max come to mind) none looks like a normal app on Windows XP (haven't tried them on Vista but judging from the beta releases till now, they are not looking “native” on Vista either).

Because WPF is so powerful and because many GUI effects are easy to achieve without a performance penalty it is very tempting to make your GUI stand out from the rest, consistency be damned. We are all guilty of this and it is hard to resist it. On the other hand, the cornerstone of the modern graphical OS is consistency so that users have to endure minimal if any training when moving from one app to another.

So what is one to do? Go with the crazy “skinnable everything” approach like Winamp or stick to the default OS look whenever appropriate? I'd say that we should definitely not underestimate users - judging by the number of Web apps that people feel comfortable with it's probably safe to assume that as long as UI follows some kind of logic, people will be able to figure it out. It's important to be internally consistent and to do the right thing. One of the most compelling things (to me at least) is the possibility to mix “classic” UI patterns with the “Web” UI patterns in WPF. A repository of UI patterns exists and is perfect for keeping things sane. I've bought the book and highly recommend it, even though there's not much there that you don't already know if you are an experienced GUI developer.

It's probably a good time to quote Spiderman (of all things): “With great power comes great responsibility”. Just because we can do almost anything with WPF doesn't mean we should. I'd say that making a great UI is becoming even more complicated, even if the result(s) on average will look much better than before.

I was pleasantly surprised to find out that the Superbowl XL was broadcasted live on a France 2 channel (one of several national channels). What people follow here is rugby (as one commenter called it “a close relative to American football”) and European football or as some would call it “soccer”.

I got interested in American football a few years ago, just prior to coming to France. I liked that the Americans were not shy using high technology to help them decide with the tricky moments. We are not as lucky here in Europe - most of the football (soccer) competitions are plagued with bad judgments that occasionally turn the whole games around in a second even though a simple recording review would show what happened.

It's not easy finding a channel that broadcasts NFL here but apparently American football is gaining traction with more than 200 teams in France competing for the championship and due to the rising popularity of this sport and a few other American sports a new channel called NASN (North American Sports Channel) will soon be available.

Finally a small note - I am not familiar enough with the quality of the teams, but I have incredible talent in picking a team to root for that will end up loosing the game (the same happened last night with Seattle). I guess you could always bet against my judgment and win :)

...do not uninstall MSDN docs that come with Visual Studio 2005 and do not replace them with the January '06 MSDN. For some really bizarre reason, unlike the docs that come with Visual Studio 2005, January '06 MSDN does NOT integrate with it but only with the 2003 version. Huh?

In any case, the home page of the January '06 MSDN announces that the April '06 version will integrate with 2005 version but will not provide “old” information (whatever that means) and that if you want to keep using MSDN with 2003 version you should stick to the January '06 MSDN. This is really confusing.

In the meantime, I'll stick with the docs that come with Visual Studio 2005. They contain all the information that pertains to all relevant versions of Visual Studio and integrate with all of them.