A quick search for singleton implementations yields some very useful results, and given the simplicity of the pattern the language should not be a barrier for anyone. Some of the implementations out there are truly naive, and it shows something extremely common: even the simplest piece of code can have so much depth that people can easily make the wrong choice.

The simplest implementation is the following:

public class Singleton
{
    private static Singleton instance;

    private Singleton() {}

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new Singleton();
            }

            return instance;
        }
    }
}

Is there something wrong with this? Well, the answer is no. If you write this on a college exam, you will most likely get all the points. The catch is that you can’t have multiple threads calling Singleton.Instance, or you risk having multiple Singletons out there, which kind of defeats the purpose of the whole pattern :)

While in general I’m a fan of keeping things as simple as possible, in today’s day and age where almost all computers have at least two cores, there’s really no excuse of designing things for just one thread. So let’s make this solution a thread-safe one:

public class Singleton
{
    private static volatile Singleton instance;
    private static readonly object mutex = new object();

    private Singleton() {}

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock (mutex)
                {
                    if (instance == null)
                    {
                        instance = new Singleton();
                    }
                }
            }

            return instance;
        }
    }
}

For those who are scratching their head about the double-check, just think about what happens if two threads access the first check at the same time, and that should give you the answer ;)

Now this solution will always work, regardless if you have just one thread or thousands accessing Singleton.Instance. The only argument for this code is that it’s not as simple as the first option, and that’s very true. So let’s look at this third solution, which should address this concern while keeping everything we have so far: a multi-threaded Singleton implementation:

public class Singleton
{
    private static readonly Singleton instance;

    static Singleton()
    {
        instance = new Singleton();
    }

    private Singleton() {}

    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

This is a bit specific to .NET, but it works like this: a static constructor is guaranteed to be called only once per AppDomain, and only when it’s needed (a static member is called or an instance of that object is created). So we can safely get rid of our lock and the checks, and rely on the CLR doing the right thing. So we now have a thread-safe, relatively pretty implementation for the Singleton pattern. The only change we can do to this is add lazy loading, which may slightly improve performance if you have other static methods, but chances are that’s not going to be your bottleneck so don’t waste your time.

All-in-all, I think this is a great example of the power of how very subtle changes drastically change the look or behavior of a piece of software. It also forces people to think a lot more than they probably thought they would need to, which will hopefully make it habitual :)

-Cos

The result of that is, among other things, that we get sloppy and start taking shortcuts; one of them involves copy + pasting code from the code you’re actually testing.

For example, let’s say you have a program, which based on some input, will perform some action. It can be as simple as:

   1:  public int ConvertStatus(string status)

   2:  {

   3:          switch(status)

   4:          {

   5:                  case "status - valid":

   6:                        return 123;

   7:                  case "status – invalid":

   8:                        return 456;

   9:           }

  10:   

  11:           return 0;

  12:  }

Unit testing this method is relatively straightforward: pass in the first status and make sure the return code is “123”, pass in the other status and make sure the return code is “456”, pass in a different value, and make sure the return code is “0” (my college courses also tell me to pass in null and empty string and make sure the return code is “0”). What some developers will end up doing is look at the code, copy the statuses and check the return value. All tests pass, the little green check mark is there, and we’re good to go.

So what’s wrong with that? Does the unit test actually test the code? Yes. Do the tests cover all the possible cases? Yes. When you actually run this code in the real world, is it going to perform as designed? Maybe. Let’s look at why.

In a larger organization (where larger is defined as not you and your buddy), there’s usually a delegation of duties, and different individuals will provide input in the process. At Microsoft, usually all engineering work is split between three roles: Program Manager, Developer and Tester. It is the PM who defines the requirements, the dev who designs, codes and unit tests the software, and the tester who will ensure the software developed meets the requirements defined. In our example below, the statuses can be defined either by the PM or the dev, and will be in a document (Functional Specification or Design Document). This ensures that everyone (including people outside the triad mentioned above) can easily read the document and understand what’s being delivered, rather than having to read code. So let’s assume that the PM wrote the statues, and when the dev went to code it, copied the text into their code. Then they wrote the unit test in the manner described above, and decided they’re code complete. However, when the tester runs their automated tests, it fails miserably. The dev’s first reaction is “no way, your test must be invalid; I wrote unit tests, and they passed fine”. How can this be?

As I discovered recently while doing a code review, word processors have a nifty way of changing your characters. For example, if you type “word1”, space, “-“, space, “word2”, the “-“ will actually become “–”. In a document, that actually does look better, but in actual code, nobody could care less.

So what happened above is exactly that: in the second status, instead of having a regular “-“, we ended up with a “–” (copy this text in a hex editor, or change the encoding to UTF-8 and you’ll notice). In order to make sure we don’t have any typos, the developer copied and pasted the text from the Functional Specification into their code. Afterwards, that same text was copied into the unit tests, thus ensuring everything passes. The tester however typed it by hand, and now we broke.

So what? If the system has that status everywhere, what’s the problem? Well, the other developer who wrote the component which stores the status in the database didn’t actually copy + paste the values, for one. Or this method can be part of a public API, and you have no idea who’s calling it. Chances are, 99% of your users won’t put the text in a document first and then copy + paste the value, but rather type it by hand.

So after this long story, the morale is pretty clear – don’t copy + paste things from a text document, just write it by hand. Actually, there can be problems with that too – and the most obivous is a typo. You copy + paste the typo in your unit tests, things pass again, yet you’ve got the same problem. This is how you end up with some APIs that have typos in them, and cannot be fixed due to backwards compatibility.

Whether you copy the text from a document, or you type it by hand in your code, you should always write your unit tests from scratch. Anytime you use Ctrl-C, Ctrl-V in a unit tests you risk masking a bug. Other than increasing your time, actually typing your unit tests can lead to one of three things:

1. You do a good job, and the tests that pass are actually proper
2. You write the proper test, and discover a bug in the code.
3. You make a mistake in the test, and it will fail. You will take a look and fix the mistake (either in the code or the test)

Finding these types of bugs is usually a pain. Even when you have an error, it’s hard to spot because our brain masks this and interprets the correct thing. Unit tests are the best, and in the end fastest way to find these issues early and isolate the problem easily.

The actual Windows installation took under 1 hour (I'd say in the 40 minute range), and went very smoothly. There were 2 devices (webcam – has always been flaky on this laptop – and fingerprint reader) which were not detected out-of-the-box but Windows picked them up in the first update.

Skype was the only software which had some compatibility issues and in the new Action Center I was provided with a link to the beta which works fine.

The interface is very snappy and I really enjoy the new features. There are also some neat shortcuts which make life a lot better.

Also used the Send Feedback feature a couple of times already. Perhaps they should leave it there after they ship too :)

Overall, kudos to the Win 7 team so far. I’m really looking forward to the RC and RTM! On a scale from 1-10, I give it a 9.5, which is great considering it’s a beta software.

The conversation continued, and I soon learned that the database contains HTML, and the UI just gets the appropriate value and displays it. Needless to say, I HATE that. There’s a reason we have different layers, and we should use them appropriately. I’ve seen this happen several times, and it never ends up well.

So why do people do it? Well, there’s some immediate advantages to it:

1. There’s no recompile necessary for changes: there’s a bug, just have an ALTER statement ready with your fix, or just DROP and add the fixed version.
2. Shortcuts – if you have some complex data which you need to store, it sure as heck seems easier to store the HTML blob needed, rather than serialize/deserialize things.
3. Personnel – if you have some SQL-heavy developers in your team, their first instinct is to put it in the database. If you ask a brain surgeon about a medical mystery, he’ll probably see brain damage. If you ask an oncologist, he’ll see cancer. It’s just human nature.

So at this point some of you might ask yourselves, so what’s the problem? Well, there are several issues with using your data layer for more than data:

1. It doesn’t “scale” – you are now limited to SQL, and for all the power that it provides, there’s LOTS of stuff missing because it’s not what it was intended to do – want to do any advanced XML stuff? need to call a web service? how about some localization?
2. It’s not strongly-typed – just because you have basic types, tables and columns, it’s not the same thing. Going back to the example at hand – you can store WHATEVER you want in those columns, it’s just ntext or nvarchar. Which brings me to the last point
3. It’s not secure – so assume my friends writes his Silverlight HTML control, and is now able to get the html blob from the database and just display it, so links work and all. There is absolutely NO way (short of parsing the content – and at that point you have more work to do than you signed up in the first place) to know what that HTML contains. Can you spell Cross Site Scripting vulnerabilities?

I was briefly working on a project a few months ago which was VERY data-heavy (let’s just say that having html in some columns was the LEAST of my worries), and I had to debug a very simple UI issue (hyperlink wasn’t pointing to the right thing). Instead of being a simple fix in a resource file, it resulted in a 2-hour investigation which resulted in editing a stored procedure to fix this.

So as a last word of advice – please, please, please stop abusing you database and use it for what it’s meant – storing your data. Do it in a smart manner (normalize your data, use indexes, use stored procedures instead of dynamic sql etc.) and get the most out of it. But do not store everything in there just to save some code higher in the stack. Else, you’ll have major headaches down the road, and pulling stuff out of the database is not as easy as you’d imagine.

   1:  string someRandomText;

   2:  UTF8Encoding encoder = new UTF8Encoding();

   3:  byte[] bytes = Encoding.UTF8.GetBytes(someRandomText);

   4:  string utf8ReturnString = encoder.GetString(bytes);

I actually didn’t noticed this on my first glance, but then I actually went back and thought about it. Can you figure it out? I’ll give you a few seconds … If you actually do a search, you’ll find something pretty similar. Given how it’s the top post for both search engines, I figured it’s worth talking about and analyzing this really simple code.

So what do we have here? Line 1 is just to demonstrate this. Assume someRandomText contains some .. err .. random text :) Assume it contains a bunch of characters, not just your usual ASCII text. Line 2 simply initializes the encoder. So far so good. Even line 3 is perfectly OK. You can just convert the string into a byte array. As you probably suspected, line 4 is the culprit here.

I guess it’s only fair give a little history of how strings are stored in C#. The short answer is UTF-16. Normally, this is perfectly fine, and for most application, UTF-16 should be the default encoding. However, for web services, UTF-8 is the usual encoding. XML is usually encoded in UTF-8, and since web services work over SOAP, it’s only natural to encode the text similarly.

Now, back to our little problem. Do you notice what’s going on here? The schema would look something like:

string (UTF-16) –> bytes[] (UTF-8) –> string (UTF-16)

So we’re really not doing anything. You might as well have just returned someRandomText and save some processor cycles.

If you really want to encode things properly, you’ll have to walk the byte array and extract the characters from there in hex format. A little bit more work, but at least it will do what you wanted it to do :)

-Cos

Since I mentioned that my work is for an online platform, I had some people come ask me what the difference between a platform and a framework are. Based on my current experience, I'm going to give a simple explanation. Others might have contradictory experiences, so feel free to share.

• A framework is a set of APIs which allow the consumer (3rd party developer most of the times) to perform some actions.
• A platform is a set of services and APIs which allow the consumer (3rd party company most of the time) to perform some actions.

You can now see why we have the confusion. Until the emergence of the Internet, a platform was pretty synonymous with a framework. Now, platforms usually represent some web services, and at times frameworks (or SDKs, if you wanted to have more complicated buzzwords). Let's take a look at 2 examples, one for consumers and one for businesses:

1. XNA - consumer platform enabling hobbyists develop and publish video games. On one hand, it has a bunch of services, which allow developers to interact with it (Blog, Creators Club etc), and on the other it has a full framework which hides the complexity of DirectX development rather nicely.
2. OCP - a commercial platform enabling businesses integrate, sell, advertise and bill their services online. Our current architecture is comprised of several web services which perform different duties. Companies can plug into our environment and start using the web service APIs. There are some high level APIs, for general abstract things (eg. billing a customer), and lots of lower level APIs which the web services use to talk to each other and perform their duties. Currently there is no public framework in place, and I'm not sure given the current model one would be needed.
3. Facebook - everybody knows that Facebook is a social site, but for developers it is a platform - it has a set of public APIs which developers can call to get different information and provide whatever they seem worthy to their customers (and if you didn't notice the tons of apps for Facebook it means you're not using it often enough)

When I refer to a framework, I usually expect to download some DLLs, and be able to reference them in my code. .NET is a perfect example of a framework. While the complexity of .NET is significantly higher (it's also a runtime, among other things), it is a set of DLLs which can be referenced within a 3rd party's code.

As I initially said, there's a pretty thin line between a framework and a platform, but one that will probably become more clear in the future, when I expect services to become more relevant and common.

-Cos

I hope to have some time soon to post some fresh content here.

-Cos