ThoughtWorks Technology Radar: Adopt capturing client-side JavaScript errors

ThoughtWorks has released their 2014 Technology Radar.

The Technology Radar is a very cool concept: lock a bunch of very smart people in a room and have then evaluate and rank the top trending technologies of the day. While not everyone is going to agree with the resulting assessment, it is still a wonderful way to spread awareness and share opinions regarding all this new tech!

I was excited to see that capturing client-side JavaScript errors has made its way to the top of the adopt list!

In 2013 this technique was on the "assess" list, and now in 2014, only one year later, it has jumped up right past the "trail" list and directly on to the "adopt" list. I could not agree more, this is a fantastic technique and I am surprised that it is not more widely adopted...so get to it!

How do you capture client-side JavaScript errors?

Last year wrote a blog post about this very subject. In that post is a description of difficulties and pitfalls in implementing your own client side error capturer, and includes a jQuery specific implementation.

Report Unhandled Errors from JavaScript
JavaScriptErrorReporter on GitHub

So what are you going to do once you have captured these errors? You can start off by simply logging them, as that is always better than nothing. However, it would be ideal to aggregate these exceptions, send notifications regarding them, and even report on their frequency. Well good news: Exceptionless just went open source!

Exceptionless Homepage
Exceptionless on GitHub

Enjoy,
Tom

Deserialize to ExpandoObject with Json.NET

I absolutely love Json.NET!

What I don't like is calling the non-generic DeserializeObject method and then having to deal with JToken wrappers. While these objects can be useful, I almost always want to just work directly with the data.

Good news, everyone! Newtonsoft natively supports deserializing to an ExpandoObject!

For anyone who does not know, ExpandoObjects are what .NET uses to let you create your own dynamic objects whose members can be dynamically added and removed at run time. The following two lines of code are ALL that you need to deserialize straight to an ExpandObjects:

var converter = new ExpandoObjectConverter();

dynamic obj = JsonConvert.DeserializeObject<ExpandoObject>(json, converter);

So why is this useful? To find out, let's take a look at some unit tests!

Understanding Unity Named Registration and ResolveAll

I have a love hate relationship with Microsoft Unity, the dependency injection container.

Unity is a very powerful tool, it is an extensible industrial strength container that comes equipped with a ton of features right out of box. However my big beef with it is how those features are not always discoverable, and often they are less than intuitive.

For example, let's talk about named registration. You can register a type from the container with or without a name. This means you can then ask the container to Resolve just the type itself, getting back the unnamed registration, or you can ask the container to Resolve that type for a particular name. That is great, it is a feature required to register multiple implementations of the same interface.

The ResolveAll method, however, is only for use with named registrations.

There is no way to resolve a collection of both named and unnamed registrations. That is not a bad thing in and of iteself, but it does mean that if you want to register a "default" type you will need to register it twice. (For more help with that see my previous blog post: Understanding Unity Lifetime Managers)

Equally interesting is how ResolveAll returns you an IEnumerable by reference.

This means that that enumerable you get back will dynamically change with registrations being made against the container. This might sound neat, but it raises a few big questions...

Is it thread safe? Nope!
Is that documented? Nope!

How to Combine Hash Codes: GetHashCodeAggregate

How do you efficiently combine hash codes?

When combining hash codes I started by generating a large string and then hashing that. However that was inefficient, so instead I was referred to this simple arithmetic solution on StackOverflow provided by Jon Skeet himself!

unchecked

{

    int hash = 17;

    hash = hash * 31 + firstField.GetHashCode();

    hash = hash * 31 + secondField.GetHashCode();

    return hash;

}

How much more efficient is this than string concatenation?

TLDR: Very! Below is a chart of the average number of ticks it takes to calculate a hash by both generating a string and Jon's method of adding ints. Each test is an average of 100,000 iterations.

Number of Keys	Avg Ticks for String	Avg Ticks for Int	Performance Increase
2	0.90	0.15	500%
5	2.08	0.25	732%
10	3.77	0.37	918%
20	7.30	0.64	1040%
50	18.97	1.33	1326%