I just realized that the 2 GMail Labs experiments “Go to label” and “Quick links” work together, which makes quick links all the more useful. So say you have 2 labels named “Newsletters” and “Notifications”, and one quick link named “ALT.NET” (which finds all the posts from the ALT.NET mailing list). If you summon the “go to label” popup and start typing “n”, it will show all three:

Now, you ask, when should you use a label, and when should you use a quick link?

The main difference is that quick links are only search queries, whereas labels can be both search queries (a filter that automatically assigns that label) or manually maintained containers. If you need the latter, that’s a no brainer. If, however, what you want can be expressed with a search query, you need to choose between labels and quick links.

My method, so far, is based on 2 criteria: complexity and scalability.

• Make a quick link if the search query is simple, and make a filter if it is complex. Typically, finding out all the emails from a specific mailing list is as simple as typing “list:altdotnet” in the search box, so this calls for a quick link. On the other hand, finding the receipts from some company that also sends you various newsletters and announcements can be a bit more complex, so I would make that a filter. The reason for this is that if the search query is complex, there’s a good chance it’s not complex enough. There’s a good chance some emails won’t get caught, because you didn’t think about all the cases or somehow an exceptional case shows up in your inbox. When this happens, you can still tag that message manually and keep going.
• Make a quick link if similar types of containers exist. For example, “ALT.NET” finds all the mail from a specific mailing list. There could be dozen of similar containers if I’m subscribed to a dozen of other mailing lists. I don’t want to clutter my email organisation with dozens of such labels, so I go for a quick link. My labels tend to be generic concepts that won’t scale up much: “Newsletters”, “MailingLists”, “Receipts”, some labels for my different internet identities and/or email accounts, and some GTD-ish labels (“FollowUp”, “Hold”).

I hope this helps.

If you have an iPhone, or any other smartphone for that matter, you will probably by now have set up Google Sync with it so you can synchronize your contacts and calendar.

However, if you’re a bit hasty and follow the simple tutorial that Google provides, you will end up synchronizing  only your main calendar with your phone. It’s easy to miss the fact you can actually synchronize up to 5 (at the time of this writing) calendars. If you go back to Google Sync from your device, you should then be able to select which calendars you wish to synced. This is especially useful if you want to sync your Remember The Milk tasks or your Facebook events.

Note

To get Remember The Milk tasks in your calendar, go here.

To get Facebook events in your calendar, go to your events page, and click “Export Events”, at the top of the page. You’ll get an URL that you can then import in Google Calendar or any other calendar application.

One of my open-source .NET projects, Textile.Net, is now available via Subversion on Codeplex.

A good friend of mine sent me this little “gotcha” a few days ago, so I thought I’d share:

#include <iostream>

#include <string>
void main() {
int a = 0;
int* ptrA = &a;
const int b = 1 ;

const int& refA1 = (ptrA ? *ptrA : 1);
const int& refA2 = (ptrA ? *ptrA : b);

std::cout << refA1 << std::endl;
std::cout << refA2 << std::endl;

a = 42;

std::cout << refA1 << std::endl;
std::cout << refA2 << std::endl;
}

This prints:

0

0

0

0

Turns out I didn’t really know how the “?” operator figures out its overall return type because most of the time I use it with class pointers or strings or something not as complicated as integers with values of 0 or 1 or even (crazy!) 42.

In this case, the “?” operator looks at an “int” and a “const int” and figures, hey, I should really make all this a “const int”! And what better way to make a “const int” out of an “int”? Well, copy it somewhere safe, of course! So you end up with constant copies of “a”. You can print out the addresses of all the variables to see how “refA1” and “refA2” point to new places.

If you remove the “const” from “b”’s declaration, the “?” operator then looks at two integers, makes “refA2” reference “a”’s address directly, and you end up with the following output:

0
0
0
42

Conclusion: watch out when initializing a variable that could either be a constant (earth’s gravity) or a user tweakable value (gravity on the space station in level 3 of your game).

…you go back to Bash, and try to type this:

ls –R | grep “foo”

…and wonder why it’s not finding any file with “foo” in it.

The source code for IronCow and Milkify are now hosted directly on Codeplex. Anybody can therefore checkout the latest source code and submit patches!

I’m a huge fan on pass-phrases. Since Jeff already evangelised them over passwords, giving arguments and advice, there’s no need to add anything…

Except, well, some good old complaining.

It pisses me off that some websites have a limited length for passwords, thus preventing users from using pass-phrases. It’s not a pass-phrase if it can only have a maximum of 12 characters, is it? But the worst is how most of those websites won’t even warn you that your password is too long… they will just truncate it and tell you everything’s okay! And then, the next time you log in, you spend 10 minutes wondering how you can mistype 50 times a passphrase you’re absolutely sure about.

Now, time to point some fingers. Recently, the 2 websites that gave me this kind of crappy user experience were the Archos Store (after creating a new account) and Linked In (after changing my password on an existing account). It’s especially surprising how a high profile website like Linked In can be so poorly implemented.

One of my laptops is getting old and the lid is not as sturdy as it used to be. It now has the unwanted tendency of triggering a “laptop lid open” event when you barely touch it because the lid moves up a bit and back down. This is problematic because it wakes up the operating system, which doesn’t always detect that the lid was closed immediately.

When you run an internet search about laptop lids and putting Windows on stand by or hibernate, you find a lot of stuff, but nothing useful about disabling resume. To solve this problem you need to think like a programmer, i.e. find a solution that kinda makes sense, but not really.

Obviously, the answer lies in the Power Options dialog, but the only setting you have access to is what to do when the lid is closed, not when it is open.

Well, here comes the shocking answer: if you put your computer on stand by when you close your lid, it will wake up when you open it. But if you don’t do anything when you close your lid, it won’t do anything either when you open it!

Setting that first combobox above to “Do nothing” therefore fixed my problem. Now, I can close the lid, let the computer go to sleep after 5 minutes of inactivity, and move it around without fear of it waking up because the lid is too sensitive. I do have to press the power button to wake it up instead of just opening it, but that’s not too awful.

Stephen Walther recently blogged about tricks that every developer should know about Visual Studio. Most of those he mentioned I use on a daily basis, so I highly recommend them. It actually surprises me how many other programmers don’t know about those features. Somehow, most programmers know Visual Studio as much as they know Microsoft Word: there’s a big space in the middle to type your text, and then maybe they know a couple of menus and shortcuts and that’s it.

Anyway, here are a few other features I use frequently:

Tip #1 – Use CTRL-I for incremental search

I’m a big fan of incremental search. It’s actually the reason I originally switch from Internet Explorer to Firefox, back when Firefox was in beta (I already had tabs with Netcaptor). By the way, I’m happy to see IE8 now also features incremental search but, well, I’m hooked on FF now… anyway…

In Visual Studio, the incremental search mode is entered with CTRL-I. Then you can start typing right away what you want to find. You can also use backspace and all, as expected. The only problem is that it uses the last search mode defined in the “Find” dialog, so if the “Match case” option is currently checked, it will only perform incremental search on what you type in a case sensitive way. This may be a bit confusing at first, but using incremental search really makes navigating code faster.

Tip #2 – Use navigate backward and forward

Like the first tip, this tip make it faster to navigate code (because we’re spending more time reading code than writing code).

CTRL– (minus sign) and CTRL-SHIFT– allow you to respectively navigate backward and forward. The first one is the one I use almost all the time: I’m looking at some code, see a call to a function, go to the definition of that function, search for something, and then I want to go back to where I was at first. Well, without having to worry about anything, I can navigate backward twice and I end up where I want. No need to find the correct tab, figure out if I stayed in the same file or not while jumping through the code, etc. Wicked!

Tip #3 – Define some external tools

You can define “external tools” with, surprisingly, the Tools > External Tools menu item. A common thing for me is to define revision control related stuff there because most of the time I don’t like how buggy and slow source control plugins are. I also do this in Visual Studio Express where there is no support for plugins at all in the first place.

For example, say you’re using Perforce. You can create a new external tool like this:

It will checkout the current file (the one you’re editing if the focus is in the text editor, or the one selected in the Solution Explorer if that’s where the focus is). Now you just need to bind “Tools.ExternalCommand2” (because it’s the second external tool) to the keyboard shortcut of you choice (mine is CTRL-K, CTRL-E for “open for edit”). Shazam! Just use your keyboard shortcut and you can checkout a file without leaving the text editor.

You can setup other commands, like show the history of the file or make a diff with the previous version. You can also easily adapt this to other systems, like SubVersion (except in this case you won’t need the “open for edit” command because SVN doesn’t lock files by default).

IronCow is a library that wraps the Remember The Milk (RTM) web services. The “upper layer” of the IronCow API is an object model that stays in sync with the server and is designed with data binding in mind.

Of course, one of the things that went into IronCow’s design was testability. IronCow ships with a suite of unit tests that, well, test that the API is working fine. However, there’s another testability aspect: how the clients of your API are going to test their stuff. These are 2 different things:

• Within IronCow, “design for testability” means I have to be able to mock the underlying client that communicates with the RTM REST API. Then, I can manipulate my objects and check that the correct requests are sent, and that those objects behave correctly according to the responses I give.
• From the point of view of a client, though, “design for testability” means they have to be able to make IronCow behave a certain way, and test that the rest of their application behave accordingly.

The easy way to make an API testing friendly is to put everything behind interfaces. This way, the client can replace your stuff with test objects. But for some reason, I don’t feel like adding this kind of complexity to IronCow. It’s a pretty small API, with an object models that contains less than a dozen of classes, and hiding everything behind interfaces would triple the number of classes, add a couple of abstract factories, and more generally confuse clients that would otherwise expect a straightforward API.

Therefore, right now, to use IronCow in a test environment, you can disable the “syncing” behaviour like this:

Rtm rtm = new Rtm(); // You can also pass in your apiKey and
// sharedSecret here but it doesn't matter.
rtm.DisabledSyncing();
// From now on, there's no requests being sent.

When syncing is disabled, the IronCow object model just acts like a “dumb” object tree. Setting the name of a task or adding a new contact won’t trigger a request to RTM. Instead, it will just modify the objects locally, as if it was just a classic simple in-memory object model.

Note that you can’t reenable syncing.

The problem with this is that although the complexity of the public interface stays the same, the complexity of the internal code increases. I find it doesn’t increase nearly as much as when I tried to hide everything behind interfaces though. The other bigger problem is that it’s more complicated for clients to do behavioural testing. For example, if they want to test what happens in their application when a certain action makes IronCow throw an exception, there’s nothing to help them do that… In that case, they have to mock the IRestClient class, and use it with their Rtm instance. There are helper classes and methods to build RTM XML responses, but it’s not what you would call super user friendly (check the IronCow.UnitTests assembly source code for examples of how to use it).

So is this fine? No? Should I bite the bullet, add interfaces, and make this simple API be 3 times bigger and more complex? Is there a third option?