2016 Retrospective

.NET

It has been a great year for .NET development! A Visual Studio Community is fully featured, .NET Core has arrived, and everything is open source. Regarding .NET Core, I am really enjoying working with it, and I simply cannot wait to get deeper into the Linux world.

Blog

I finally had to downgrade from three posts per month to only two posts per month. Unfortunately writing quality blog posts tasks time, and that was not something that I had in great abundance this year. Fortunately, I do think that the majority of posts this year were very high quality, especially when you look at the most recent ones. I have been working a lot with performance optimization, and have really been enjoying profiling and digging deep into code to see exactly what it is doing and why.

Tact.NET

I am very happy to have launched Tact.NET this year! I have always really enjoyed creating frameworks, so rather than continue to write one off posts on this blog I decide to put all of my extracurricular worth together under one repository. I am really enjoying making Tact, and I have every intention of continuing to grow it.

QQ Cast

Wow, the QQ Cast is back! We took a hiatus for the second half of 2015, but in 2016 we recorded 43 podcasts. Next week is actually going to be our 100th episode, be sure to check it out!

Happy new year,
Tom

Object Pooling and Memory Streams

The theme of this year, which I will talk about in my 2016 retrospective, has been optimization. It's been a fun journey, and I have really enjoyed getting down and dirty with profiling garbage collection, using spin waits, and aggressive inlining.

I want to end this year on a fun note: object pooling.

A great use case for this would be making HTTP requests with serialized objects. When you serialize an object, and then place it in a HttpContent object, you are probable creating several buffers (byte arrays) each time. For example, if you are using Newtonsoft to serialize an object and then adding that to a string content object for your request, then you are probably using more memory than you need. But that is getting ahead of ourselves...

Come back next week for a blog post about efficient JSON Content serialization!

For now, let's focus on building an object pool. Really all that we need is a preallocated array to store unused objects in, and then a super efficient thread safe data structure to pool (get and set) those objects.

How does pooling memory streams help us?

When you create a MemoryStream, it creates a byte array. As that byte array grows, the memory stream resizes it by allocating a new larger array and then copying your bytes into it. This is inefficient not only because it creates new objects and throws the old ones away, but also because it has to do the leg work of copying the content each time it resizes.

How can we reuse memory streams? Just set the length to zero!

Internally this will just set an index and empty the array, but the internal data structures will be preserved for future use. Thus, by putting memory streams into an object pool, we can drastically increase our efficiency.

Here is a demo of using the Tact.NET ObjectPool to pool MemoryStreams...

[Fact]

public void MemoryStreamPoolDemo()

{

    using (var pool = new ObjectPool<MemoryStream>(100, () => new MemoryStream()))

    {

        var memoryStream1 = pool.Acquire();

        memoryStream1.SetLength(0);

        Assert.Equal(0, memoryStream1.Capacity);

        memoryStream1.Write(new byte[] {1, 0, 1, 0, 1}, 0, 5);

        var array1 = memoryStream1.ToArray();

        Assert.Equal(5, array1.Length);

        Assert.Equal(1, array1.First());

        Assert.Equal(1, array1.First());

        pool.Release(memoryStream1);

        var memoryStream2 = pool.Acquire();

        Assert.Same(memoryStream1, memoryStream2);

        memoryStream2.SetLength(0);

        Assert.Equal(256, memoryStream2.Capacity);

        memoryStream2.Write(new byte[] { 0, 1, 0 }, 0, 3);

        var array2 = memoryStream2.ToArray();

        Assert.Equal(3, array2.Length);

        Assert.Equal(0, array2.First());

        Assert.Equal(0, array2.First());

    }

}

Enjoy,
Tom

The Performance Cost of Boxing in .NET

I recently had to do some performance optimizations against a sorted dictionary that yielded some interesting results...

Background: I am used to using Tuples a lot, simply because they are easy to use and normally quite efficient. Please remember that Tuples were changed from structs to classes back in .NET 4.0.

Problem: A struct decreased performance!

I had a SortedDictionary that was using a Tuple as a key, so I thought "hey, I'll just change that tuple to a struct and reduce the memory usage." ...bad news, that made performance WORSE!

Why would using a struct make performance worse? It's actually quite simple and obvious when you think about it: it was causing comparisons to repeatedly box the primitive data structure, thus allocating more memory on the heap and triggering more garbage collections.

Solution: Use a struct with an IComparer.

I then created a custom struct and used that; it was must faster, but it was still causing boxing because of the non-generic IComparable interface. So finally I added a generic IComparer and passed that into my dictionary constructor; my dictionary then ran fast and efficient, causing a total of ZERO garbage collections!

See for yourself:

The Moral of the Story

Try to be aware of what default implementations are doing, and always remember that boxing to object can add up fast. Also, pay attention to the Visual Studio Diagnostics Tools window; it can be very informative!

Here is how many lines of code it took to achieve a 5x performance increase:

private struct MyStruct

{

    public MyStruct(int i, string s) { I = i; S = s; }

    public readonly int I;

    public readonly string S;

}

private class MyStructComparer : IComparer<MyStruct>

{

    public int Compare(MyStruct x, MyStruct y)

    {

        var c = x.I.CompareTo(y.I);

        return c != 0 ? c : StringComparer.Ordinal.Compare(x.S, y.S);

    }

}

Test Program

I have written some detailed comments in the Main function about what each test is doing and how it will affect performance. Let's take a look...

10x faster than Delegate.DynamicInvoke

This is a follow up to my previous blog posts, Optimizing Dynamic Method Invokes in .NET, and Dynamically Invoke Methods Quickly, with InvokeHelpers.EfficientInvoke. Basically, I have re-implemented this for Tact.NET in a way that makes it smaller, faster, and compatible with the .NET Standard.

So, how much faster is this new way of doing things? EfficientInvoker.Invoke is over 10x faster than Delegate.DynamicInvoke, and 10x faster than MethodInfo.Invoke.

Check out the source on GitHub:

• EfficientInvoker.cs
• EfficientInvokerTests.cs

Simple Explanation

Here is an example of a method and a class that we might want to invoke dynamically...

public class Tester

{

    public bool AreEqual(int a, int b)

    {

        return a == b;

    }

}

...and then here is the code that the EfficientInvoker will generate at runtime to call that method:

public static object GeneratedFunction(object target, object[] args)

{

    return (object)((Tester)target).AreEqual((int)args[0], (int)args[1]);

}

See, it's simple!

IOC Container for Tact.NET

Autofac now supports .NET Core, but other IOC frameworks such as Ninject and Unity have yet to port over. While I was looking into IOC frameworks for .NET Core, I had a bad idea...I, for fun, wrote my own Container in Tact.NET!

So, why did I do this? Honestly, it was just a fun academic exercise! I do think that this is a pretty good container, and I intend to use it in some of my personal projects. Would I recommend that YOU use this? Probably not yet, but I would invite you take a look and offer feedback!

Container Design

I have broken the container into two interfaces: IContainer for registration, and IResolver for consumption. There is a abstract class, ContainerBase, that can be inherited to easily create a container that matches other frameworks; for example, I intend to create a IDependencyResolver for ASP.NET.

You may notice that the IContainer does not have any lifetime management methods, that is because ALL of them are implemented as extension methods...

Registrations

To create a new lifetime manager you have to implement the IRegistration interface. There are already implementations for quite a few:

• InstanceRegistration
• PerResolveRegistration
• PerScopeRegistration
• SingletonRegistration
• TransientRegistration

Resolution Handlers

The last part of the container is the IResolutionHandler interface. These resolution handlers are used when an exact registration match is not found during dependency resolution. For example, the EnumerableResolutionHandler will use ResolveAll to get a collection of whatever type is being requested. Another very different example, the ThrowOnFailResolutionHandler will cause an exception to be thrown when no match can be found.

• EnumerableResolutionHandler
• FuncResolutionHandler
• LazyResolutionHandler
• ThrowOnFailResolutionHandler
• UnregisteredResolutionHandler

I think that is a pretty good start, but I am hoping that this will continue to grow with time.

Enjoy,
Tom

Introducing Tact.NET

I have decided to create a project to consolidate all of the utilities that I have authored over the years on this blog...

Tact.NET - A tactful collection of utilities for .NET development.

I believe that this will give me the opportunity to update old code more often, as well as develop new utilities faster. For example, the there is already an ILog interface that optimizes (thank you, Jeremy) the Caller Information Extensions I wrote about about back in May.

Everything that I add to this project will be build for the .NET Standard Library, and should support .NET Core on all platforms. Expect to see NuGet packages soon, and hopefully many more blog posts to come.

Enjoy,
Tom

Host HTTP and WebSockets on the Same Port in ASP.NET

How do you support WebSocket connections on the same port as your HTTP server in .NET? It turns out that this is not that hard, and you even have several choices to do so...

Option 1: TCP Proxy

You could use a TCP proxy port to divide traffic between the two targets. For example, all traffic would come in to port 80, but then HTTP traffic would be routed internally to 8001 and WS traffic to 8002. This is useful because it would allow you to use multiple technologies (in the example on their site, both NancyFX and Fleck) to host your web servers.

• github.com/lifeemotions/websocketproxy

Option 2: SignalR

SignalR is great because of all the backwards compatibility that it supports for both the server and client. However, it is not the most lightweight framework. If you choose to use it, then it will absolutely support both HTTP and WS.

• asp.net/signalr

Option 3: Owin.WebSocket *My Favorite*

Owin supports WebSockets, and that is exactly what SignalR uses to host its WS connections. The awesome Mr. Bryce Godfrey extracted the Owin code from SignalR into a much smaller library called Owin.WebSocket.

The ONLY thing that I did not like about this implementation was that is uses inheritance to define endpoints, whereas I much prefer the ability to use delegates and lambdas. Because of this, I created Owin.WebSocket.Fleck, which allows you to use the Fleck API to map your WebSockets to an Owin context. A pull request is open to merge this into the main repository.

• github.com/bryceg/Owin.WebSocket

Enjoy,
Tom

.NET Asynchronous Parallel Batch Processor

Last year, I wrote about how to handle dynamically sized batches of data in an asynchronous manner. That original implementation used an abstract base class, and only supported a single background processing thread. I recently updated that implementation to support lambdas rather than requiring inheritance, and support a dynamic number of background threads.

...basically, this is a ConcurrentQueue that supports taking a lambda and thread count to asynchronously process enqueued items.

Unit Tests

public class ParallelProcessorTests

{

    [Fact]

    public async Task NoDisposeTimeout()

    {

        var results = new ConcurrentQueue<int>();

        using (var processor = new ParallelProcessor<int>(2, async (i, token) =>

        {

            await Task.Delay(200, token).ConfigureAwait(false);

            results.Enqueue(i);

        }, disposeTimeoutMs: 0))

        {

            processor.Enqueue(1);

            processor.Enqueue(2);

            processor.Enqueue(3);

            processor.Enqueue(4);

            processor.Enqueue(5);

            await Task.Delay(300).ConfigureAwait(false);

        }

        Assert.Equal(2, results.Count);

    }

    [Fact]

    public void MaxParallelizationLimit()

    {

        const int parallelism = 3;

        var results = new ConcurrentQueue<Tuple<int, int>>();

        var active = 0;

        using (var processor = new ParallelProcessor<int>(parallelism, async (i, token) =>

        {

            Interlocked.Increment(ref active);

            await Task.Delay(200, token).ConfigureAwait(false);

            var currentActive = Interlocked.Decrement(ref active) + 1;

            var tuple = Tuple.Create(currentActive, i);

            results.Enqueue(tuple);

        }))

        {

            processor.Enqueue(1);

            processor.Enqueue(2);

            processor.Enqueue(3);

            processor.Enqueue(4);

            processor.Enqueue(5);

        }

        Assert.Equal(5, results.Count);

        var maxParallelism = results.Max(t => t.Item1);

        Assert.Equal(parallelism, maxParallelism);

    }

    [Fact]

    public void BatchProcessor()

    {

        var results = new List<Tuple<long, List<int>>>();

        var sw = Stopwatch.StartNew();

        using (var processor = new BatchParallelProcessor<int>(1, 2, async (ints, token) =>

        {

            await Task.Delay(100, token).ConfigureAwait(false);

            var tuple = Tuple.Create(sw.ElapsedMilliseconds, ints);

            results.Add(tuple);

        }))

        {

            processor.Enqueue(1);

            processor.Enqueue(2);

            processor.Enqueue(3);

            processor.Enqueue(4);

            processor.Enqueue(5);

        }

        Assert.Equal(3, results.Count);

        Assert.Equal(2, results[0].Item2.Count);

        Assert.Equal(1, results[0].Item2[0]);

        Assert.Equal(2, results[0].Item2[1]);

        Assert.True(results[0].Item1 < results[1].Item1);

        Assert.Equal(2, results[1].Item2.Count);

        Assert.Equal(3, results[1].Item2[0]);

        Assert.Equal(4, results[1].Item2[1]);

        Assert.True(results[1].Item1 < results[2].Item1);

        Assert.Equal(1, results[2].Item2.Count);

        Assert.Equal(5, results[2].Item2[0]);

    }

}

Dynamically Invoke Methods Quickly, with InvokeHelpers.EfficientInvoke

In my previous blog post, I talked about Optimizing Dynamic Method Invokes in .NET. In this post, we will use that information to create a static helper method that is twice as fast as MethodInfo.Invoke.

Basically, we create and cache a delegate in a concurrent dictionary, and then cast both it and it's arguments to dynamics and invoke them directly. The concurrent dictionary introduces overhead, but it still more than twice as fast as calling MethodInfo.Invoke. Please note that this method is highly optimized to reduce the use of hash code look ups, property getters, closure allocations, and if checks.

let's take a look at the code...

InvokeHelpers.EfficientInvoke

public static class InvokeHelpers

{

    private const string TooManyArgsMessage = "Invokes for more than 10 args are not yet implemented";

    private static readonly Type VoidType = typeof(void);

    private static readonly ConcurrentDictionary<Tuple<string, object>, DelegatePair> DelegateMap 

        = new ConcurrentDictionary<Tuple<string, object>, DelegatePair>();

    public static object EfficientInvoke(object obj, string methodName, params object[] args)

    {

        var key = Tuple.Create(methodName, obj);

        var delPair = DelegateMap.GetOrAdd(key, CreateDelegate);

        if (delPair.HasReturnValue)

        {

            switch (delPair.ArgumentCount)

            {

                case 0: return delPair.Delegate();

                case 1: return delPair.Delegate((dynamic)args[0]);

                case 2: return delPair.Delegate((dynamic)args[0], (dynamic)args[1]);

                case 3: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2]);

                case 4: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3]);

                case 5: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4]);

                case 6: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5]);

                case 7: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6]);

                case 8: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7]);

                case 9: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8]);

                case 10: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8], (dynamic)args[9]);

                default: throw new NotImplementedException(TooManyArgsMessage);

            }

        }

        switch (delPair.ArgumentCount)

        {

            case 0: delPair.Delegate(); break;

            case 1: delPair.Delegate((dynamic)args[0]); break;

            case 2: delPair.Delegate((dynamic)args[0], (dynamic)args[1]); break;

            case 3: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2]); break;

            case 4: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3]); break;

            case 5: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4]); break;

            case 6: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5]); break;

            case 7: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6]); break;

            case 8: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7]); break;

            case 9: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8]); break;

            case 10: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8], (dynamic)args[9]); break;

            default: throw new NotImplementedException(TooManyArgsMessage);

        }

        return null;

    }

    private static DelegatePair CreateDelegate(Tuple<string, object> key)

    {

        var method = key.Item2

            .GetType()

            .GetMethod(key.Item1);

        var argTypes = method

            .GetParameters()

            .Select(p => p.ParameterType)

            .Concat(new[] { method.ReturnType })

            .ToArray();

        var newDelType = Expression.GetDelegateType(argTypes);

        var newDel = Delegate.CreateDelegate(newDelType, key.Item2, method);

        return new DelegatePair(newDel, argTypes.Length - 1, method.ReturnType != VoidType);

    }

    private class DelegatePair

    {

        public DelegatePair(dynamic del, int argumentCount, bool hasReturnValue)

        {

            Delegate = del;

            ArgumentCount = argumentCount;

            HasReturnValue = hasReturnValue;

        }

        public readonly dynamic Delegate;

        public readonly int ArgumentCount;

        public readonly bool HasReturnValue;

    }

}

Now let's take a look at some performance tests...

Optimizing Dynamic Method Invokes in .NET

I recently had a lot of fun helping to optimize some RPC code that was using reflection to dynamically invoke methods in a C# application. Below are a list of implementations that we experimented with, and their performance.

1. Directly Invoking the Method
2. Using MethodInfo.Invoke
3. Using Delegate.DynamicInvoke
4. Casting to a Func
5. Casting a Delegate to Dynamic

Spoilers: Here are the results. (The tests for this can be see below.)

Name	First Call (Ticks)	Next Million Calls	Invoke Comparison
Invoke	1	39795	-
MethodInfo.Invoke	12	967523	x24
Delegate.DynamicInvoke	32	1580086	x39
Func Invoke	731	41331	x1
Dynamic Cast	1126896	85495	x2

Conclusion: Invoking a method or delegate directly is always fastest, but when you need to execute code dynamically, then (after the first invoke) the dynamic invoke of a delegate is significantly faster than using reflection.

Let's take a look at the test code...

Can I port my application to .NET Core?

I am very excited about .NET Core, and I am looking forward to porting my projects to it. Generally porting your own code is a straight forward task, but updating all of your dependencies can be quite daunting. Good news: the guys over at Octopus have built an awesome little site that helps you determine the state of your dependencies!

I Can Has .NET Core

Enjoy,
Tom

Make your NuGet Server use NLog

The latest version of NuGet.Server is fast, stable, and super simple to setup. As for most .NET tools, Scott Hanselman already create a great write up about how to use it.

However, I was very disappointed at how unintuitive it was to get wire up a custom logger!

You need to take several steps to make the official NuGet server write to something like NLog:

1. Create a log wrapper.
2. Implement NuGet.Server.Logging.ILogger.
3. Implement NuGet.ILogger...
4. ...which also makes you implement NuGet.IFileConflictResolver!
5. Implement your own NuGet.Server.IServiceResolver
6. When instantiating ServerPackageRepository...
7. ...pass in the ILogger...
8. ...AND set the Logger property!

Still confused? Pull the code here, or take a look below!

Should you open source your software?

Every Tuesday I help host the QQ Cast, where we fabricate answers to geek culture's most superfluous questions. For our 50th Quest, my good friend Matt Stevenson joined us to talk about open source software.

QQ Cast - Quest 50 - Should you open source your software?

• 00:00 - Mic Check and Introductions
• 05:30 - Is "Expand Enhance Extinguish" still alive and well?
• 19:40 - Can we build a sustainable infrastructure without open source software?
• 33:00 - How much structure do we like to see in our frameworks?
• 40:50 - What are some great open source projects?
• 47:15 - Was heartbleed a good thing or a bad thing?
• 54:30 - Does contributing to open source projects help your resume?
• 60:00 - Should you open source your software?
• 70:00 - Wrap up!

Please always remember that all views and opinions expressed on the podcast are representative solely of the person expressing them; not of their friends and family, not of their coworkers, and certainly not of their employers, past, present, or future.

Enjoy,
Tom

Updating Default Parameters in .NET Assemblies

One of the things that I love about C# is how so many of it's features are just very conveniently designed compiler tricks. This means that, just like any other magic trick, once you know how the trick is performed you immediately realize that there really is nothing magical about it.

So, let's talk about default parameters. They are actually just constant values that get compiled into your code when you go to use a method that has them. Let's look at an example...

The Code

public enum Country

{

    US,

    CA

}

public static class SharedUtility

{

    public static bool CanDrink(

        int age, 

        Country country = Country.CA)

    {

        switch (country)

        {

            case Country.US:

                return age >= 21;

            case Country.CA:

                return age >= 18;

            default:

                throw new ArgumentException(

                    "Invalid Country",

                    nameof(country));

        }

    }

}

public class SharedUtilityTests

{

    [Fact]

    public void CanDrink()

    {

        var result = SharedUtility.CanDrink(20);

        // The line above will compile into the following:

        // var result = SharedUtility.CanDrink(20, Country.CA);

        // Thus, the Assert below will succeed!

        Assert.True(result, "The default was not US!");

    }

}

So, now that you know how the trick is performed, how could this cause a problem for you? Specifically, what happens if you update a library that exposes methods with default parameters?

Nothing will change, until you recompile against the library!

If another library changes their default parameters, but you do not recompile your code against it, then your code will be using the old default values! Let's look back at the previous example and see why this could cause confusion...

MP3 Playlist for Chromecast

Come to find out, I am a very retro guy when it comes to music. I have these old things that I like to use to play music, you may not have heard of them, they are called MP3s. They are kind of like 8-track tapes, but digital, not in the cloud, and not old enough to be cool yet.

How do you play MP3s via Chromecast?

The official answer is to use Google Play, but that implies that you want to both pay for that service and upload your files to the cloud. The unofficial answer is to drag and drop your MP3s into a Chrome tab and cast that tab, however this does not allow you to create a playlist.

Introducing Playlist for Chromecast

I have created a simple single page HTML 5 application that will act as a playlist for MP3s on your computer. Just download the project and open up release/playlist.html in Chrome, then drag and drop MP3s on to the page.

Development

I had a lot of fun making this, and I'm not done. I intend to use this project as a case study to talk about VSCode, TypeScript, SASS, HTML5 Audio, NPM, and unit testing. For now, I just wanted to start by getting this initial post up, but expect more to follow.

• Source on GitHub

What's next?

• Update project documentation.
• Create unit tests.
• Add theme support.
• Write blog posts about development.
• Maybe host it on a domain.
• Maybe submit it as a Chrome application.

Enjoy,
Tom

Client Side Caching for jQuery

Updates: 6/26/16

• Fixed bug where triple equals null check would miss.
• Added support for data driven cache key.
• Removed let and const statements (some minifiers were having a hard time with them)

Original:

There is great question on Stack Overflow about caching a jquery ajax response in javascript/browser. Unfortunately, even thought it was a good solution, it did not do quite what I needed it to.

The application I was trying to optimize sometimes made redundant parallel requests, and I needed my caching solution to include a queuing system to prevent duplicate fetches.

Below is a simple solution that uses jQuery.ajaxPrefilter to check a local cache prior to making GET requests. Additionally, it will queue the callback if the request is already in flight. The cache stores the queue in both memory and local storage, ensuring that the cache will persist across page loads.

Implementation

(function ($) {

  "use strict";

  var timeout = 60000;

  var cache = {};

  $.ajaxPrefilter(onPrefilter);

  function onPrefilter(options, originalOptions) {

    if (options.cache !== true) {

      return;

    }

    var callback = originalOptions.complete || $.noop;

    var cacheKey = getCacheKey(originalOptions);

    options.cache = false;

    options.beforeSend = onBeforeSend;

    options.complete = onComplete;

    function onBeforeSend() {

      var cachedItem = tryGet(cacheKey);

      if (!!cachedItem) {

        if (cachedItem.data === null) {

          cachedItem.queue.push(callback);

        } else {

          setTimeout(onCacheHit, 0);

        }

        return false;

      }

      cachedItem = createCachedItem();

      cachedItem.queue.push(callback);

      setCache(cacheKey, cachedItem);

      return true;

      function onCacheHit() {

        invoke(callback, cachedItem);

      }

    }

    function onComplete(data, textStatus) {

      var cachedItem = tryGet(cacheKey);

      if (!!cachedItem) {

        cachedItem.data = data;

        cachedItem.status = textStatus;

        setCache(cacheKey, cachedItem);

        var queuedCallback;

        while (!!(queuedCallback = cachedItem.queue.pop())) {

          invoke(queuedCallback, cachedItem);

        }

        return;

      }

      cachedItem = createCachedItem(data, textStatus);

      setCache(cacheKey, cachedItem);

      invoke(callback, cachedItem);

    }

  }

  function tryGet(cacheKey) {

    var cachedItem = cache[cacheKey];

    if (!!cachedItem) {

      var diff = new Date().getTime() - cachedItem.created;

      if (diff < timeout) {

        return cachedItem;

      }

    }

    var item = localStorage.getItem(cacheKey);

    if (!!item) {

      cachedItem = JSON.parse(item);

      var diff = new Date().getTime() - cachedItem.created;

      if (diff < timeout) {

        return cachedItem;

      }

      localStorage.removeItem(cacheKey);

    }

    return null;

  }

  function setCache(cacheKey, cachedItem) {

    cache[cacheKey] = cachedItem;

    var clone = createCachedItem(cachedItem.data, cachedItem.status, cachedItem.created);

    var json = JSON.stringify(clone);

    localStorage.setItem(cacheKey, json);

  }

  function createCachedItem(data, status, created) {

    return {

      data: data || null,

      status: status,

      created: created || new Date().getTime(),

      queue: []

    };

  }

  function invoke(callback, cachedItem) {

    if ($.isFunction(callback)) {

      callback(cachedItem.data, cachedItem.status);

    }

  }

  function getCacheKey(originalOptions) {

    if (!!originalOptions.data) {

      return originalOptions.url + "?" + JSON.stringify(originalOptions.data);

    }

    return originalOptions.url;

  }

})(jQuery);

Enjoy,
Tom

Word Boundaries Regex

\b

This is the second time this week where I have had to ask myself "how did I not know about this?"

There is a regex character to identify word boundaries: \b This is a zero length match, similar to the caret and dollar sign. It finds the boundaries between words, allowing you to search for a whole word match.

Below is a sample extension method that uses this to replace words in a string.

Implementation

public static class StringExtensions

{

    private static readonly Regex WordRegex = new Regex(@"\b\w+\b", RegexOptions.Compiled);

    public static string ReplaceWords(

        this string input,

        string find,

        string replace,

        StringComparison comparison = StringComparison.InvariantCulture)

    {

        return WordRegex.Replace(input, m => m.Value.Equals(find, comparison)

            ? replace

            : m.Value);

    }

}

Common Logging Extensions with Caller Information

Update: Added the BreakParameter.

I have made it an (arguably bad) habit of manually adding the class and method name as a prefix to all my log lines. It is not that I enjoy typing out the same strings over and over, it's that I do not always trust things like the NLog callsite. Using the stack frame to identify a calling method always requires a bit of cleverness on the part of the author, as you never can be totally sure when you are dealing with a wrapper class or an async call stack.

I was recently introduced to the Caller Information attributes in C# 5, and now I think I am in love.

Disclaimer: I have not used this very much yet, but I intend to start! I think that these attributes are absolutely brilliant in their simplicity: a compiler trick to insert debug information directly into your code. That is freak'n sweet, and it's performant! I am not sure how this flew under my radar, but now that I know about it....

Below is a little T4 template that I wrote up to generate overloads for Common Logging that will include caller information. To customize this for your needs, just update the the GetFormat method at the bottom of the template.

Unit Tests

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using Common.Logging.Simple;

   4:  using Xunit;

   5:   

   6:  namespace Common.Logging.Tests

   7:  {

   8:      /// <summary>

   9:      /// Tests for Common Logging extensions that use Caller Information

  10:      /// https://msdn.microsoft.com/en-us/library/mt653988.aspx

  11:      /// </summary>

  12:      public class LogCallTests

  13:      {

  14:          [Fact]

  15:          public void LogFromMethod()

  16:          {

  17:              var log = new QueueSimpleLogger();

  18:              var ex = new Exception("Boom");

  19:   

  20:              log.Debug("Hello");

  21:              log.Debug("World", ex);

  22:   

  23:              log.DebugCall("Hello");

  24:              log.DebugCall("World", ex);

  25:   

  26:              log.WarnFormat("Hello - {0}", "Zero");

  27:              log.WarnFormat("World - {0}", ex, "Zero");

  28:   

  29:              log.WarnFormatCall("Hello - {0}", "Zero");

  30:              log.WarnFormatCall("World - {0}", ex, "Zero");

  31:   

  32:              Assert.Equal(8, log.Queue.Count);

  33:   

  34:              Assert.Equal("Hello", log.Queue.Dequeue());

  35:              Assert.Equal("World - Ex: Boom", log.Queue.Dequeue());

  36:   

  37:              Assert.Equal("LogCallTests.LogFromMethod(23) - Hello", log.Queue.Dequeue());

  38:              Assert.Equal("LogCallTests.LogFromMethod(24) - World - Ex: Boom", log.Queue.Dequeue());

  39:   

  40:              Assert.Equal("Hello - Zero", log.Queue.Dequeue());

  41:              Assert.Equal("World - Zero - Ex: Boom", log.Queue.Dequeue());

  42:   

  43:              Assert.Equal("LogCallTests.LogFromMethod(29) - Hello - Zero", log.Queue.Dequeue());

  44:              Assert.Equal("LogCallTests.LogFromMethod(30) - World - Zero - Ex: Boom", log.Queue.Dequeue());

  45:          }

  46:   

  47:          [Fact]

  48:          public void LogFromAction()

  49:          {

  50:              var log = new QueueSimpleLogger();

  51:              var ex = new Exception("Boom");

  52:              Action action = () =>

  53:              {

  54:                  log.Debug("Hello");

  55:                  log.Debug("World", ex);

  56:   

  57:                  log.DebugCall("Hello");

  58:                  log.DebugCall("World", ex);

  59:   

  60:                  log.WarnFormat("Hello - {0}", "Zero");

  61:                  log.WarnFormat("World - {0}", ex, "Zero");

  62:   

  63:                  log.WarnFormatCall("Hello - {0}", "Zero");

  64:                  log.WarnFormatCall("World - {0}", ex, "Zero");

  65:              };

  66:   

  67:              action();

  68:   

  69:              Assert.Equal(8, log.Queue.Count);

  70:   

  71:              Assert.Equal("Hello", log.Queue.Dequeue());

  72:              Assert.Equal("World - Ex: Boom", log.Queue.Dequeue());

  73:   

  74:              Assert.Equal("LogCallTests.LogFromAction(57) - Hello", log.Queue.Dequeue());

  75:              Assert.Equal("LogCallTests.LogFromAction(58) - World - Ex: Boom", log.Queue.Dequeue());

  76:   

  77:              Assert.Equal("Hello - Zero", log.Queue.Dequeue());

  78:              Assert.Equal("World - Zero - Ex: Boom", log.Queue.Dequeue());

  79:   

  80:              Assert.Equal("LogCallTests.LogFromAction(63) - Hello - Zero", log.Queue.Dequeue());

  81:              Assert.Equal("LogCallTests.LogFromAction(64) - World - Zero - Ex: Boom", log.Queue.Dequeue());

  82:          }

  83:   

  84:          private class QueueSimpleLogger : AbstractSimpleLogger

  85:          {

  86:              public readonly Queue<string> Queue = new Queue<string>(); 

  87:   

  88:              public QueueSimpleLogger()

  89:                  : base(string.Empty, LogLevel.All, true, true, true, string.Empty)

  90:              {

  91:              }

  92:   

  93:              protected override void WriteInternal(LogLevel level, object message, Exception exception)

  94:              {

  95:                  var s = message.ToString();

  96:                  if (exception != null) s += " - Ex: " + exception.Message;

  97:                  Queue.Enqueue(s);

  98:              }

  99:          }

 100:      }

 101:  }

IResourceLoader: Balancing Semaphores

Recently I need to get balance getting resources from a restricted number of sources. So, for example...

I am getting resource R, and I have factories A, B and C creating those Rs. Each of those factories has a very limited capacity for creating those resources, and can only create two Rs at a time. It is easy to put the factories behind a semaphore and limit how many threads can be requesting resources from each factory at a time.

The challenge is evenly balancing the workload between all three factories. Also, please note that you can't just round robin the semaphores because there is no way to ensure that each operation will complete in the same amount of time.

To do this I created a generic IResourceLoader interface, and made two implementations: one to wrap a semaphore, and the other to wrap and balance a collection of IResourceLoaders. Below is the implementation, complete with unit tests; let's take a look!

Interface

public interface IResourceLoader<T>

{

    int Available { get; }

    int Count { get; }

    int MaxConcurrency { get; }

    Task<T> GetAsync(CancellationToken cancelToken = default(CancellationToken));

    bool TryGet(out Task<T> resource, CancellationToken cancelToken = default(CancellationToken));

}

How to Order xUnit Tests and Collections

xUnit is an extremely extensible unit testing framework!

If you need to control the order of your unit tests, then all you have to do is implement an ITestCaseOrderer. Once implemented, you just add a TestCaseOrdererAttribute to the top of your test class to use it. Below we use a custom OrderAttribute to order the tests.

To control the order of the test collections you can do a very similar trick by implementing an ITestCollectionOrderer. However, an ITestCollection is not neccessarily associated with a specific class, so to to use attributes to order them you need to use a little reflection. Check out the sample below for details.

Implementation

/// <summary>

/// Used by CustomOrderer

/// </summary>

public class OrderAttribute : Attribute

{

    public int I { get; }

    public OrderAttribute(int i)

    {

        I = i;

    }

}

/// <summary>

/// Custom xUnit test collection orderer that uses the OrderAttribute

/// </summary>

public class CustomTestCollectionOrderer : ITestCollectionOrderer

{

    public const string TypeName = "xUnitCustom.CustomTestCollectionOrderer";

    public const string AssembyName = "xUnitCustom";

    public IEnumerable<ITestCollection> OrderTestCollections(

        IEnumerable<ITestCollection> testCollections)

    {

        return testCollections.OrderBy(GetOrder);

    }

    /// <summary>

    /// Test collections are not bound to a specific class, however they

    /// are named by default with the type name as a suffix. We try to

    /// get the class name from the DisplayName and then use reflection to

    /// find the class and OrderAttribute.

    /// </summary>

    private static int GetOrder(

        ITestCollection testCollection)

    {

        var i = testCollection.DisplayName.LastIndexOf(' ');

        if (i <= -1)

            return 0;

        var className = testCollection.DisplayName.Substring(i + 1);

        var type = Type.GetType(className);

        if (type == null)

            return 0;

        var attr = type.GetCustomAttribute<OrderAttribute>();

        return attr?.I ?? 0;

    }

}

RangeSet for .NET

Update 4/13 - Added support for single value ranges.

What data structure do you use when you need to efficiently check if a number is within a large set of ranges?

If you require that the ranges do not overlap, then it is simple to keep a balanced binary tree of the ranges. Finding if a number is within one of those ranges should only take O(log n) to find. Below is an implementation of a RangedSet that uses a standard .NET SortedSet to store the ranges.

IRangeSet Interface

public interface IRangeSet<in T> where T : IComparable

{

    void AddRange(T min, T max);

    bool Contains(T findValue);

}

programmer.fail

Fun fact: http://programmer.fail/ redirects to this blog.

That is not an April fools joke.

Enjoy,
Tom

xUnit.net: Extensions Config v3.3.0

I recently made several updates to the xunit.extensions.config library, which allows you to configure theory data from your app.config file. Here are the links to the source and the NuGet package:

• GitHub - Source and Tests
• NuGet - xunit.extensions.config

New Features

• Named Parameter Support

You no longer need to configure your data by parameter index. You can now name your data for each parameter, making the configuration much easier to read and understand.

• AppSettings Support

You can now use the standard AppSettings section of the App.config to configure your data. If no settings are found, then the framework will fallback to trying to use the standard config section.

• Default Namespace Option

You can now provide a default namespace for your tests. This reduced the amount of redundant text in your config file, and makes test names much more concise and easy to read.

• Extensible Data Provider

Don't want to use the existing data providers? Would you rather use a database? Now you can! Just add an AppSettings key for "TestData.ServiceFactory" that provides the fully qualified name of a static method that returns an IConfigTestDataService, and the framework will try to use that to load configuration data.

Why method that return a Task should end with Async

I have spoken before about using the Fleck WebSocket server library for .NET, but recently I experienced a small problem with it. Pull request #126 changed several public methods to become async and return a Task instead of void.

This did not follow the recommended naming convention of naming all async methods with the Async suffix.

In my case, this caused us to introduce a bug to a project that was using Fleck. We would ignore Task returned from IWebSocketConnection.Send, and under high load the task scheduler would get backed up.

Even though I do not think that they are going to use it, I created a pull request that updated the the public methods to include the Async suffix. Also, in order to maintain backwards compatibility, I also added obsolete methods to the interfaces without the suffix.

What did I do with the tasks? Rather than write in parallel, I used a concurrent queue and had a background task serially write messages to the connection.

Enjoy,
Tom

How to Release a Semaphore with a Using Block

I love that .NET has so many useful utilities available in the base framework. I often use the SemaphoreSlim, and I love that it supports async await. However, I don't like always having to create a try finally block around every use call to ensure that the release method gets called.

Below is a simple little extension method that will allow you to place the result of the Semaphore wait into a using block, thus ensuring that the dispose will always release the lock.

SemaphoreSlim Extensions

public static class SemaphoreSlimExtensions

{

    public static async Task<IDisposable> UseWaitAsync(

        this SemaphoreSlim semaphore, 

        CancellationToken cancelToken = default(CancellationToken))

    {

        await semaphore.WaitAsync(cancelToken).ConfigureAwait(false);

        return new ReleaseWrapper(semaphore);

    }

    private class ReleaseWrapper : IDisposable

    {

        private readonly SemaphoreSlim _semaphore;

        private bool _isDisposed;

        public ReleaseWrapper(SemaphoreSlim semaphore)

        {

            _semaphore = semaphore;

        }

        public void Dispose()

        {

            if (_isDisposed)

                return;

            _semaphore.Release();

            _isDisposed = true;

        }

    }

}

Podcast - What should all software developers want in their applications?

Each week, my good friend Zach Mayer and I answer geek culture's most superfluous questions on the QQ-Cast. This past week we turned to the subject of software development, and did a retrospective on my series of blog posts, Three Things that all Applications MUST Have.

QQ Cast - Quest 40 - What should all software developers want in their applications?

• 00:00 - Mic Check and Introductions
• 03:55 - Why isn't your application logging?
• 06:15 - Where is your configuration coming from?
• 11:00 - Can we talk about Unit Tests for 18 minutes?
• 29:00 - Is continuous integration necessary?
• 30:30 - Does automated deployment speed up development?
• 38:00 - When should you use inversion of control?
• 49:30 - How intrusive is error reporting for end users?
• 59:00 - Do you remove user impersonation from production builds?
• 63:30 - Why is continuous deployment so controversial?
• 72:15 - Wrap up!

Enjoy,
Tom

Async Cache Repository v2

Three years ago (wow, time flies) I wrote a generic Cache Repository that has become one of my more popular open source projects. It is 2016, so was definitely time to create an async version of that cache repository! This new implementation has all of the same features as the original, only now it is completely async from top to bottom.

Features

• Thread Safe GetOrSet
• Configurable Expiration Enums
• Transparent Cache Key Management By Type
• A Web Implementation

NuGet Package and Source

• GitHub - Source Code, Tests, & Sample
• NuGet Gallery - CacheRepository.Web

Enjoy,
Tom

How To: Kill child process when parent process is killed v2

Working with unmanaged memory is not my forte. Thus I am very appreciative of when someone not only reads my blog, but then takes the time to do their own research and leave comments and suggest updates. TLDR: Thank you, Steven Pereyda!

Last year I blogged about how to kill a child process when the parent process is killed. The solution involves using the operating system by invoking Kenral32. However, as mentioned above, there was a small memory leak and a few other optimizations that we should have made; so let's take a look at how to fix those!

Fixes and Optimizations in v2

1. There was a small memory leak.

In the job constructor we used Marshal.AllocHGlobal to create an unmanaged copy of the JobObjectExtendedLimitInformation object, but we never freed that memory. The new constructor how has a finally block that ensures we invoke Marshal.FreeHGlobal.

2. We should use SafeHandles.

.NET has a SafeHandle class that can be used as a wrapper around unmanaged handles, which can help you prevent memory leaks; and I learned how to use this by reading a code project article by the always awesome Stephen Cleary. Please note that in v2 there is a now a JobObjectHandle class that extends SafeHandle, and we use this instead of storing the IntPtr ourselves.

3. We moved the GC.SuppressFinalize into the public dispose method.

Yes, this is the right way to do it. So why didn't I do it that way the first time? Because ReSharper was warning me that I wasn't using the isDisposing param...and hate warnings!

4. Follow the best practices of hosting all external calls in a single Native Methods class.

Microsoft recommends that you keep all of your external calls in one NativeMethods class, and then decorate that class with attributes to avoid security warnings. Sounds like a good idea to me.

C# Interfaces and Default Parameters

How does a default parameter work?

One of the things that I love about C# is how so many of it's features are just very conveniently designed compiler tricks. This means that, just like any other magic trick, once you know how the trick is performed you immediately realize that there is nothing magical about it all!

So, let's talk about default parameters. They are actually just constant values that get compiled into your code when you go to use a method that has them. Let's look at an example...

public class DefaultParamTests1

{

    [Fact]

    public void WhatYouWrite()

    {

        var actual = Double();

        Assert.Equal(2, actual);

    }

    private static int Double(int i = 1)

    {

        return i * 2;

    }

}

public class DefaultParamTests2

{

    [Fact]

    public void WhatItCompilesTo()

    {

        var actual = Double(1);

        Assert.Equal(2, actual);

    }

    private static int Double(int i)

    {

        return i * 2;

    }

}

What happens when interfaces and methods don't match?

So, now that you know how the trick is performed, what happens if you use a different default value for a parameter defined by an interface and a class?

The answer is simple: if your object is cast as the class, then it will use the class value. If your object is cast as the interface, it will use the interface value instead. Let's take a look at another example...

How to Optimize Json.NET Serialization Performance

Newtonsoft is a pretty fast JSON serializer, but you can make it even faster!

By default, JsonConvert uses reflection to recursively search through the structure of an object during the serialization process. By implementing a custom JsonConverter that already knows the exact structure of the object, you can significantly increase serialization performance.

How much faster? That depends! The more complicated the data structure, the larger the performance gain. Below is a simple example...

Action	Method	Milliseconds	Performance Increase
Serialize	Standard	1134	115.59%
	Custom	526
Deserialize	Standard	1488	62.98%
	Custom	913

Why do you enjoy programming?

Recently a friend of mine asked me to participate in a study that he is conducting. He asked me to answer the following questions, and I thought that they were interesting enough to share...

1. You’ve mentioned before how you enjoy programming and choose to do it in your free time, and I was wondering what aspects of the work do you enjoy the most and what reasons you think you have for enjoying it?

I am going to try to answer those questions in reverse order.

What reasons do I have for enjoying programming? I think that programming is problem solving its purest form; it is the application of raw logic to a very specific and well defined problem. As a person who has always enjoyed math and science, my brain just seems to naturally gravitate towards computer science. To me programming is like solving a puzzle, and I get the same high from making my code compile as I do from beating a video game.

What aspects of the work do I enjoy the most? This question is much easier to answer! Anyone can solve any problem using only their mind. You can define languages and protocols to meet your needs. You can communicate between any number or parties at the speed of light. You can literally engineer entire worlds. It’s fun, it's challenging, and it is always rewarding when you build something that impacts others in a positive way.

2. In addition to that, how do you view the projects you are working on while you are working on them, and how do you view them once they are done?

These are opinions that have evolved overtime, often through trial by fire.

How do you view projects while you are working on them? During a project you need to keep your eyes on the prize, the best thing any engineer can do is to try and deliver the minimal viable product as soon as possible. During this time engineers need to engage in a very difficult balancing act of trying to make the best long term decisions, while still tempering their ideas and ambitions with more reasonable compromises to achieve short term goals and deliverables. After you have something that works, then designs can be iterated upon, implementations refactored, and schedules revised. In short, I think every project that does not ship is a failure, regardless of how perfectly it was designed or optimally it was implemented.

How do you view projects once they are done? First and foremost, I feel that the quote "art is never done" applies to software. There are almost infinite ways to solve a problem, each with their own set of pros and cons, so projects can always be improved. That being said, after a project is complete you need to be honest about it. You can, and should, be proud of what worked. You should also be open to talking about what didn't. No matter how good a project was, you can always do it better next time!

Those are my answers...what are yours?

Thanks,
Tom