Google Maps version 3 intellisense

Intellisense is one of those killer-features of Visual Studio. I love that I can just drop in an assembly in VS and start poking around in an editor to get a feel of the API. If the API i properly documented and layed out in a .netty way I can immediately start working with it.

The flipside of intellisense is that once you get used to it you feel severely limited when you encounter a project without intellisense. That's what happened to me today.

I was integrating the excellent Google Maps library into one of our websites and decided that I should use the latest and greatest release - Google Maps v3. I fired up VS and started hacking away in a .js file until i got flashbacks from back in the days when I developed PHP. I was toggling between writing code in my IDE and reading the api documentation in my browser. It was horrifying!

-vsdoc to the rescue

At some point I realized that since I can get intellisense for jQuery I should be able to get it for Google Maps as well so I started googling and found this single commit project at codeplex that did offer an intellisense file for Google Maps v2 but not for v3.

That's when I started looking at writing my own intellisense file. I tried to validate the Google API reference in the W3 Validator only to find out that the king of all web doesn't always produce the best markup.

Not to fear; I've written a couple of screen scraping utilities before and I know that there's one project that makes dealing with badly formatted html a breeze: Html Agility Pack. The agility pack parses almost any amount of bad markup and gives you a nice little XPath interface for poking around inside the DOM.

The result

After some hackish (screen scrapers are always messy) code I was able to produce a basic intellisense file that covers most of the Google Maps API.

The files

The js intellisense file and usage instructions can be found over at http://www.freakcode.com/projects/google-maps-v3-vsdoc.

Licensing information

Introducing exception signatures

At work we develop, maintain and host a web solution which consists of a fair amount of assemblies and spans across several websites. Although we might like to think that we develop perfect code that certainly isn't always the case. And as with all non-djb applications ours sometimes generates a few exceptions.

Now please don't think of us as bad people, exceptions are an unfortunate part of nature and not all exceptions are the result of our bad programming, quite often we get exceptions from external libraries, from asp.net (viewstate exceptions, forbidden input exceptions and so on).

Keeping track of exceptions

Quite early on in our development process we decided that we needed a way of reacting to these exceptions as they happened. Our solution was to implement global exception handlers which sent an email to us whenever an unhandled exception occurred.

This worked great and in our early days it was more than enough. We could immediately react to an exception and we could often deploy a fix rapidly.

If you don't keep track of your exception at all you're probably in trouble. See this post by Jeff Atwood for a better explanation of why than I could ever come up with.

Keeping track of large amounts of exceptions

When our sites had been live for a while and started to get some serious use we noticed that it was getting really hard to keep track of all incoming exception mails. From looking at the stack trace we had no idea if an exception had been resolved, if someone was working on it, it's priority and so on. Troubled by the need to keep a bunch of stack traces in (my) memory I started thinking about ways of solving the problem.

My idea was to convert the exceptions into issue tickets. We use Trac at work so I started looking at simply redirecting all of our exception email there. Getting the exception mails converted to tickets wasn't really a problem but it didn't help at all with organization since every exception spawned a new ticket and we still had to manually merge the duplicates.

Enter Exception Signatures

In order to enable organization I started looking at generating a fingerprint for every exception. Some sort of string generated by looking at the stack traces of the exception, its inner exceptions and meta information of each exception. I wanted a solution which could be intelligent enough to differentiate between two exceptions thrown from the same place but for different reasons (i.e., the algorithm should look at the entire exception chain instead of only the base exception target site).

Handling dynamic data in exception messages

I also wanted it to be able to detect and disregard dynamic data in exception messages. Ever heard of Exception.Data? That's where we store extra information that we want to tack along for debugging purposes. Exception.Data is great but sometimes it's to much work and you just want to throw in some debugging data in the Exception.Message string like this:

public void RefundPurchase() {
    if(PurchaseState != "completed")
        throw new InvalidOperationException(
            "Invalid state for refund: " + PurchaseState
        );
}

In order to handle these cases I made the algorithm aware of three "pretty standard" ways of including dynamic data in exception messages.

1. Text after a colon ':'. Invalid state for refund: inprogress
2. Text within single and double quotes. Invalid state for refund "inprogress"
3. Text within balanced parenthesis, brackets and braces. Invalid state for refund (state was inprogress)

Handling localized exceptions

I also wanted localized exceptions to produce the same signature when possible. We have a windows app used by some of our customers and we wanted exceptions from them to produce the same signature regardless of their OS language. To accommodate this I added some custom code for exceptions which contain an ErrorCode (SocketException and Win32Exception) and use that instead of the message.

Human semi-friendly signatures

My last requirement was that the signatures generated would be short so that we could display them to our users when they encounter one of our error-pages. This enables our customer service to provide status updates to calling customers by simply looking up the signature in trac and looking at its status.

As such the signatures are no-crazy-signs 8 character hex strings, like "617c1de5" and "1570d6d7"

Conclusion and possible solution

I think I've covered all my requirements and I must say that it has worked great for us. All of our exceptions end up in trac where we can prioritize, assign and catalogue them. We even have a great way of knowing when exceptions that we think we've squashed re-appear because then the ticket just get re-opened.

Jeff Atwood wrote about using exception logs as a de-facto to do list a while ago and that's exactly what we have accomplished using this technique. We even did it long before he published his post but no one will ever believe that =)

What about ELMAH?

I have not used ELMAH personally but I've certainly heard many great things about it. From what I've read about ELMAH it seems that they have some great features for filtering unwanted exceptions but I haven't seen anything about grouping exceptions. The ideal thing would of course be if existing frameworks like ELMAH used this implementation to provide simple grouping.

Our end result

This is an example of how it looks when we encounter an exception in our system. Note that although the exception was thrown twice there’s only one ticket.

Get the code and abuse it

This is the part which makes my stomach ache... The code, complete with a couple of unit tests and an example program plus more information is available at http://www.freakcode.com/projects/exception-signatures.

Licensing information

IIS7 Certificate binding issue

I recently tried installing a certificate into IIS7 on an new Windows 2008 server at work. The import whent well but when I tried to bind a site to use the new certificate I got a dialog box with the following message

---------------------------
Add Site Binding
---------------------------
There was an error while performing this operation.

Details: 

A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)
---------------------------
OK   
---------------------------

(Note: The above text was produced by simply focusing the dialog window and pressing CTRL+C; really neat trick!)

After a lot of debugging/googling I managed to find a solution; you have to check the "Allow this certificate to be exported" box when you import the cert. Really strange and really not good practice but until I find another solution that's the way it has to be. If you've got another solution please comment!

Little bobby tables

Hilarious!

From http://xkcd.com/327/

ToTitleCase

Not to long ago I had to write a method to convert lowercase names to proper case for display on a website I was working on. I started rolling my own but then I thought that such a feature would be nice to have in the framework. So I hit google with a query and sure enough the framework authors had thought of it. The method was well hidden though ;)

CultureInfo.InvariantCulture.TextInfo.ToTitleCase("hELLo wORLd");
// Will return "Hello World"

This fits quite well in as an extension method

/// <summary>
/// Creates a new string with Title Case (ie "hEllO wORLd" becomes  "Hello World") using the Invariant Culture
/// </summary>
/// <param name="s">The string to convert</param>
/// <returns>The string in title case</returns>
public static string ToTitleCaseInvariant(this string s)
{
    return ToTitleCase(s, CultureInfo.InvariantCulture);
}

/// <summary>
/// Creates a new string with Title Case (ie "hEllO wORLd" becomes  "Hello World")
/// </summary>
/// <param name="s">The string to convert</param>
/// <returns>The string in title case</returns>
public static string ToTitleCase(this string s)
{
    return ToTitleCase(s, CultureInfo.CurrentCulture);
}

/// <summary>
/// Creates a new string with Title Case (ie "hEllO wORLd" becomes  "Hello World")
/// </summary>
/// <param name="s">The string to convert</param>
/// <param name="ci">The culture to use when creating title case</param>
/// <returns>The string in title case</returns>
public static string ToTitleCase(this string s, CultureInfo ci)
{
    if (s == null)
        throw new ArgumentNullException("s");

    return ci.TextInfo.ToTitleCase(s);
}

Now you can just call the ToTitleCase on your string objects like this:

var s = "george washington";
s.ToTitleCase();

Licensing information

Single instance Calculator.NET

Everyone has their set of utility programs that they need to be productive. I've got lots of them. Whenever I change computers or reinstall windows I've got a list of about 10-15 essential apps that needs to be installed before I do anything else. One of these programs is Calculator.NET by Paul Welter

It's one of those small apps that does exactly what you expect of it and nothing more. It's got a clean nice history and some built in conversion utilities but other that that it's just a calculator. It has a built in option (menu item toggle) for setting it to be the default calculator for windows. Simple, and without any hassle.

There's one tiny thing that bothers me though. At work I've got a MS Wireless Desktop 7000 keyboard with one of those neat calculator shortcut buttons right above the numpad and whenever I press it a new instance of Calculator.NET starts up. Ideally though I'd like for my existing Calculator.NET instance (if any) to be focused and restored (if minimized).

Open source to the rescue

Paul was kind enough to provide the source to Calculator.NET and being a curious developer I loaded it up to see if I perhaps could add my little feature myself instead of bugging Paul with a feature request. About half an hour later I was done.

Enter Calculator.NET single instance patch

It ensures that only one instance of the calculator is active at any one time but you can override that behavior by passing -force as the first argument or by pressing CTRL+N or by just clicking on the new window icon in the toolbar/menu.

And here is the code

It uses a named mutex to ensure that only one instance can run at any given moment.

static void Main(string[] args)
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);

    string optStr = string.Empty;

    if(args.Length > 0)
        optStr = args[0].Trim().ToLower();

    if (optStr != "-force" && Settings.Default["SingleInstanceMode"] != null &&  Settings.Default.SingleInstanceMode)
    {
        using (Mutex m = new Mutex(false, "Calulator.NET single instance"))
        {
            if (!m.WaitOne(0, false))
            {
                // There is already an instance of Calculator.NET running.
                // Attempt to locate the window and bring it to front
                IntPtr hWnd = FindWindow(null, "Calculator.NET");

                if (hWnd.ToInt32() != 0)
                {
                    ShowWindow(hWnd, SW_RESTORE);
                    SetForegroundWindow(hWnd);
                }
            }
            else
            {
                RunApp();
            }
        }
    }
    else
    {
        RunApp();
    }
}

private static void RunApp()
{
    Application.Run(new CalculatorForm());
}

const int SW_RESTORE = 9;

[DllImport("user32.dll", SetLastError = true)]
static extern IntPtr FindWindow(string lpClassName, string lpWindowName);

[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool SetForegroundWindow(IntPtr hWnd);

[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

If you want to apply it to your build begin by downloading the source to Calculator.NET and then go get my patch Calculator.NET-singleinstance-patch.zip.

Just unpack the Calculator.NET zip file and then copy the contents of my zip into that directory and you're good to go. I'll drop a comment over at Paul's weblog and then we'll see if it's something he'd consider adding to the official version.

If you don't want the build hassle you can simply download the binary Calculator.NET-singleinstance.exe

Licensing information

High precision performance measurement

Sometimes you need to get a feel for how performant a specific method is. I've seen lots of developers use DateTime.Now for this. Like this:

DateTime start = DateTime.Now;
PerformWork();
TimeSpan ts = DateTime.Now - start
Console.WriteLine("Time taken: {0}ms", ts.TotalMilliseconds);

Now, there's a couple of problems with this. First off, DateTime.Now performs way worse than DateTime.UtcNow since it has to get the UTC time and the calculate timezone and DST offsets.

The second and more concerning problem is that DateTime has a resolution of about 15ms, it can't be more precise than that. Now, in development code you could of course get around this by running your code a couple of thousand time to compensate for the low precision but what if you're code can't easily be run more than one time (perhaps it performs expensive and hard-to-recover database work).

Stopwatch to the rescue

The System.Diagnostics.Stopwatch class provides high-precision measurement of elapsed time. Using hardware frequency counters it achieves nanosecond precision and it's really easy to use.

Stopwatch sw = Stopwatch.StartNew();
PerformWork();
sw.Stop();

Console.WriteLine("Time taken: {0}ms", sw.Elapsed.TotalMilliseconds);

The stopwatch falls back on DateTime.UtcNow if your hardware doesn't support a high frequency counter. You can check to see if Stopwatch utilizes hardware to achieve high precision by looking at the static field Stopwatch.IsHighResolution.

This post is essentially a ripoff of my answer to a question regarding time measurement on the kickass Q/A site stackoverflow.com (not open to public yet).

Licensing information