Engineering a Collection Equality Function

I’ve mentioned before that collection equality is a relatively common and useful operation that has no built-in implementation in the .NET framework:

bool CollectionEquals<t>(
    this IEnumerable</t><t> @this, 
    IEnumerable</t><t> that, 
    IEqualityComparer</t><t> comparer = null);

Here I’m differentiating collection equality from sequence or set equality: I want two collections to be considered equal if and only if they contain exact same elements, respecting duplicates but disregarding order. While I’ve implemented this functionality in the past, for a new utility library I’m creating I wanted to see how much I could tune the implementation.

Continue reading Engineering a Collection Equality Function

Distributed Locking with .NET and SQLServer

Locks are probably the most prolific synchronization construct in all of programming. The premise is simple: carve out a region of code that only one thread can enter at a time. Most programming languages provide support for locking mechanisms in their standard libraries if not (as in C#) in the languages themselves.

Unfortunately, these default tools often start to break down when we start to think about distributed locking. That is, when we don’t want to limit execution just to one thread in the current process but instead to one thread in an entire system or even in a cluster of systems.

Continue reading Distributed Locking with .NET and SQLServer

$q.allSettled – Q.allSettled for angular promises

Q has Q.allSettled. $q does not. The main difference between $q.all and $q.allSettled is that $q.allSettled waits for all promises to resolve or reject (i.e. “settle”). Then it resolves. $q.all rejects when the first project is rejected.

Paraphrased from Q’s documentation:

$q.allSettled returns a promise that is fulfilled with an array of promise state snapshots, but only after all the original promises have settled, i.e. become either fulfilled or rejected.

This method is often used in order to execute a number of operations concurrently and be notified when they all finish, regardless of success or failure.

I’ve noticed a lot of Angular devs request $q.allSettled. So here it is! JS Fiddle.

Continue reading $q.allSettled – Q.allSettled for angular promises

$q.serial – execute promises serially in AngularJS.

Hey AngularJS devs! Let’s talk about executing async tasks serially with promises and how $q.serial can help.

First, we notice .then allows our success/fail callbacks to return a promise. $q treats success/fail callbacks that return promises specially. We’ll look at two examples to see how $q treats success/fail functions that return promises differently from those that don’t.
Continue reading $q.serial – execute promises serially in AngularJS.

The Power of Parameter Names

C# 4 introduced named and optional parameters: the ability to set default values for arguments and explicitly label arguments by name instead of just position. Despite being a relatively minor features, named and optional parameters actually do quite a lot to make coding simpler to write, read, and consume. So much so, that I find myself sorely missing this feature when working in languages without it (e. g. JavaScript).

Continue reading The Power of Parameter Names

Better validation with yield and async/await: the wrapper pattern

Recently, I’ve been writing a lot of code which gets packaged up into libraries to be consumed by other developers. One of the key aspects of writing this sort of code effectively is to be stringent about argument validation. The earlier your code detects invalid arguments, the easier it is for consumers of your APIs to diagnose errors. Argument checking is fairly straight-forward, but I recently came upon an interesting subtlety when working with the C# yield keyword.

Continue reading Better validation with yield and async/await: the wrapper pattern