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.
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:
[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");
}
[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
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% |
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!
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.
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
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!
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...
