Dotmad.net

The Singleton pattern is very well known to .Net developers, especially the static implementation.
Lately I have encountered several versions of the generic Singleton, among them the one described in Arnon’s post.

However, there is one possible pitfall to this approach, as it makes this code possible:
Singleton<myclass> obj = Singleton<myclass>.Instance;
MyClass obj2 = new MyClass();

While I personally like the idea of having the freedom to use the same class in two different ways throughout the application, I know some people like their Singletons - well, single.
On the other hand, if you write a class from the start as a Singleton this is not an issue.

There is an inherit risk in decoupling a class from it’s expected behavior, so take this into consideration before using this pattern.

I had previously tried using the WebBrowser class to retrieve a web page for analysis (using the DocumentText property).
The problem was determining the state of the page load (since a page requires several hits before completion on average).

Turns out I need to check on track backs to my post, as Anthony Stevens (you should read his “about” page) found a solution to my problem:
Once the page load is complete WebBrowser.ReadyState property will be set to Complete, and then you can take the loaded page and wreak havoc on it.

As a .Net developer you are not bothered by trivialities such as character encoding, since the framework uses Unicode by default.

But what happens when you need to encode your text so someone else (non .Net) will decrypt it, and that someone uses a single byte per character?

Let’s start with few definitions:

• ASCII - a standard that uses a single byte for each character, but only defines 128 possible symbols. There is no such thing as “Hebrew ASCII”.
• ANSI - Same idea, but here you can use the remaining bits (out of a byte) to encode non-English specific characters. The problem is every language uses a specific version. The ANSI character table may look different on different computers, depending on the configuration.
• Unicode, UTF-8, etc - Using 2 or more bytes for each character, allowing room for all languages (as long as both sides agree to use the same encoding)

(If you wish to learn more, you should read Joel Spolsky’s “The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)“)

Here are your options:

• Encoding.ASCII - Your basic ASCII (7 bits) encoding.
• Encoding.Unicode - Unicode encoding.
• Encoding.UTF8 - Will encode ASCII text with a single-byte representation, but will switch to a longer representation for non-ASCII strings.
• Encoding.Default - ANSI encoding based on the computer’s configuration, meaning both sender and receiver should share the same locale.
• Encoding.GetEncoding - Uses a specific code-page to determine the desired encoding. You should try using this method if you need ANSI encoding. However, you still need to determine the code page you require.
• Encoding.GetEncoding(862) - Uses MS-DOS Hebrew encoding, with Hebrew characters starting at bit 128.
• Encoding.GetEncoding(1255) - Uses Windows-1255 Hebrew encoding, with Hebrew characters starting at bit 224. This encoding matches the ISO 8859-8 standard, which is also used by Unix.

Steve Yegge wrote a loooong post with tips for finding a job at Google.
He gave all sort of tips, most of them self-explainatory (you should know about Hashtables, Algorithms etc).

But there was one golden advice:
Don’t let the Interview Anti-Loop get you down.

But what is the Interview Anti-Loop?
Every single employee E at any company has at least one “Interview Anti-Loop”: a set of other employees S who would not hire E.

The solution is simple:

“The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. Just as long as you don’t feel meta-bad, everything is OK. You should feel good that you feel bad after this happens, because hey, it means you’re human.

And then you should wait 6-12 months and re-apply. That’s pretty much the best solution we (or anyone else I know of) could come up with for the false-negative problem. We wipe the slate clean and start over again. There are lots of people here who got in on their second or third attempt, and they’re kicking butt.

You can too.”

When you leave work this weekend, turn off your computer, light and air conditioner - and try to keep doing this every day.
And there are other ways to help the environment.
More info - on the Earth Hour 2008 web site.

After going this week to the Microsoft performance open house, here are few things to consider:

• Create performance counters of your own to measure various statistics.
• Try to avoid using interfaces and virtual methods to supports inlining.
• If you use a “Contains” method of a collection on structs, be sure to override the “Equals” method, since the default Object.Eqauls method used boxing twice - once for the parameter and the once for “this“.
• Similarly, you should override the GetHashCode methods for structs, since the default implementation for a struct is very inefficient.
• Use Perfmon.exe to monitor the “% time in GC” - a high value may indicate mid-life crisis.

This is a great way to create a Singleton instance of an exiting class without needing to specifically design it as a singleton:

// Singleton factory implementation
public static class Singleton where T : class
{
static Singleton()
{
// create the single instance of the type T using reflection
Instance = (T)Activator.CreateInstance(typeof(T), true);
}
public static T Instance { private set; get; }
}

class Program
{
public static void Main()
{
// test
Console.WriteLine(Object.ReferenceEquals(Singleton.Instance, Singleton.Instance));
}
}