Sunday, April 6, 2014

Deserialize Abstract Classes with Json.NET

Here is a fun problem: how do you deserialize an array of objects with different types, but all of which inherit from the same super class?

If you are using Newtonsoft's Json.NET, then this is actually rather easy to implement!

Example

Here are three classes...

public abstract class Pet { public string Name { get; set; } }
public class Dog : Pet { public string FavoriteToy { get; set; } }
public class Cat : Pet { public bool WantsToKillYou { get; set; } }

...here is an array with instances of those objects mixed together...

new Pet[]
{
    new Cat { Name = "Sql", WantsToKillYou = true },
    new Cat { Name = "Linq", WantsToKillYou = false },
    new Dog { Name = "Taboo", FavoriteToy = "Sql" }
}

...and now let's make it serialize and deseriailze! :)

Extending the JsonConverter

This tactic is actually quite simple! You need to extend a JsonConverter for your specific super class that is able to somehow uniquely identify each child class. In this example we look for a specific property that only exists on the child class, and Newtonsoft's JObjects and JTokens make this very easy to do!

Tuesday, April 1, 2014

TypeScript Definition Files on NuGet: Always have the latest and greatest IntelliSense!

The strongly typed nature of TypeScript offers the potential for amazing IntelliSense!

Open Source TypeScript Definitions

Some people do not realize that there is already a vast library of community authored definition files for just about every JavaScript framework out there. By including these definition files in your project, you can unlock the full potential TypeScript's IntelliSense.

The Original DefinitelyTyped Repository on GitHub

TypeScript Definitions on NuGet

The best thing about the open source community: whenever someone has a great idea, other people gladly line up to help improve it. To that end people have forked Boris's DefinitelyTyped, created NuGet packages, and automated their deployment!

DefinitelyTyped NuGet Repository on GitHub
jquery.TypeScript.DefinitelyTyped on NuGet

jQuery Example

If you want to use jQuery, just install the jquery.TypeScript.DefinitelyTyped NuGet package...

Saturday, March 15, 2014

String.Concat vs StringBuilder Performance

Time for yet another micro-optimization!

Everyone knows that Strings are immutable in .NET, thus the StringBuilder class is very important for saving memory when dealing with manipulating large strings.

...but what about performance?

Interestingly, StringBuilder is just an all around better way to combine strings! It is more memory efficient, and less processor intensive; but not by much. Below is a comparison of performance between different ways of combine strings.

Tuesday, March 11, 2014

Migrating from Moq to NSubstitute

Mocking is a necessary evil for unit testing.

Fortunately frameworks like NSubstitute make it painless setup your mock services. NSubstitute offers a fluent API that requires few lambdas and no calls to an Object property. You just get back the interface that you are substituting and work with it directly. Frankly, NSubstitute is so easy to work with that it almost seems like magic!

Below is a visual representation of equivalent commands between Moq and NSubstitute:

NSubstitute

[Fact]
public void NSubstitute()
{
    var tester = Substitute.For<ITester>();
 
--------------------------------------------
            
    var voidArg = String.Empty;
 
    tester
        .When(t => t.Void(Arg.Any<string>()))
        .Do(i => voidArg = i.Arg<string>());
 
    tester.Void("A");
    Assert.Equal("A", voidArg);
 
--------------------------------------------
 
    tester
        .Bool()
        .Returns(true);
                
    var boolResult = tester.Bool();
    Assert.Equal(true, boolResult);
 
--------------------------------------------
 
    tester
        .Int
        .Returns(1);
 
    var intResult = tester.Int;
    Assert.Equal(1, intResult);
 
--------------------------------------------
 
    tester.Received(1).Void("A");
 
--------------------------------------------
 
    tester.DidNotReceive().Void("B");
}

Moq

[Fact]
public void Moq()
{
    var tester = new Mock<ITester>();
            
    // Setup a callback for a void method. -------
 
    var voidArg = String.Empty;
 
    tester
        .Setup(t => t.Void(It.IsAny<string>()))
        .Callback<string>(s => voidArg = s);
 
    tester.Object.Void("A");
    Assert.Equal("A", voidArg);
 
    // Setup the result of a method. -------------
 
    tester
        .Setup(t => t.Bool())
        .Returns(true);
 
    var boolResult = tester.Object.Bool();
    Assert.Equal(true, boolResult);
 
    // Setup the result of a property. -----------
 
    tester
        .SetupGet(t => t.Int)
        .Returns(1);
 
    var intResult = tester.Object.Int;
    Assert.Equal(1, intResult);
 
    // Ensure that a function was called. --------
 
    tester.Verify(m => m.Void("A"), Times.Once);
 
    // Ensure that a function was NOT called. ----
 
    tester.Verify(m => m.Void("B"), Times.Never);
}

Enjoy,
Tom

Saturday, March 8, 2014

String.Concat vs String.Format Performance

Time for another micro-optimization!

When building strings it is almost always easiest to write and maintain a typical format statement. However, what is the cost of that over just concatenating strings? When building strings for cache keys (which I know are going to get called a lot) I try to use String.Concat instead of String.Format. Let's look at why!

Below is a table showing a comparison the performance difference between String.Concat and String.Format. The Y axis is the number of arguments being concatenated. The X axis is the number of milliseconds it takes to complete 100,000 runs.

Number
of Args
String.Concat
Milliseconds
String.Format
Milliseconds
Concat
Percent Faster
2 4ms 10ms 150%
3 3ms 13ms 333%
4 4ms 16ms 300%
5 12ms 21ms 75%
6 14ms 24ms 71%
7 16ms 28ms 75%
8 18ms 31ms 72%

Sunday, March 2, 2014

Log Performance in a Using Block with Common.Logging

You should be using Common.Logging to share your logger between projects.

Common.Logging is a great and lightweight way to share dependencies without requiring that you also share implementation. It is how several of my projects that use Log4Net are able to shares resources with another team that uses NLog. But that is not what I am here to talk about!

How do you log performance quickly and easily?

No, I do not mean performance counters. No, I do not mean interceptors for dependency injection. I want something far more lightweight and simplistic! What I want is the ability to simply log if too much time is spent in a specific block of code. For example...

public void MyMethod1(ILog log)
{
    // If this using block takes more than 100 milliseconds,
    // then I want it to write to my Info log. However
    // if this using block takes more than 1 second,
    // then I want it to write to my Warn log instead.
    using (log.PerfElapsedTimer("MyMethod took too long!"))
    {
        var obj = GetFromApi();
        SaveToDatabase(obj);
    }
}

The PerfElapsedTimer is just a simple little extension method that I wrote, under the hood it just wraps a Stopwatch in an IDisposable. Feel free to grab the code from below and start using it yourself.

Wednesday, February 26, 2014

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

Real Time Web Analytics