Pete's IT

I set myself the task of designing and building a tremolo guitar effects box. I'm quite pleased with the result: if there’s ever a Mark II, I could improve some things but it's a fully usable unit.

Here's a little demo video I made with two original and one borrowed bits of music to show the process and demonstrate the effect. It's fair to say that Boss will not be on the 'phone to employ me as an effects pedal demo guy, but hopefully you get the idea.

So you know foreach, do you?

I would have said I understood C#’s foreach statement, but I learnt a subtlety of it today. Occasionally, it will help.

The foreach statement is usually used with an IEnumerable<T>, or maybe a plain IEnumerable, but in fact does not require either. The compile-time type of the parameter only has to support a method called GetEnumerator(), which returns an object of a type that supports MoveNext() and Current; it does not have to be IDisposable.

Importantly, there’s no problem using a value type for either the parameter itself or the enumerator that it returns. With care, the allocation involved with classes can be avoided.

I keep finding this useful, but not often enough actually to remember the contents. Hopefully, others will find it useful too.

There are two key Git concepts involved: -

git filter-branch for stripping a respository down to just one subdirectory. It can do other stuff, too: see its documentation

Switch Solution in VS2017 via Solution Explorer

Visual Studio 2017 has added a little feature where it will scan the directory containing the current solution for further solutions. Then you can drop down a list of those that it finds. It's just a wee bit more convenient than File-Open or even File-Recent.

In the https://en.wikipedia.org/wiki/Null_Object_pattern#C.23, checks for null are avoided by using a special object instead of a null reference. The special object - the "null object" - is typically a do-nothing or minimal implementation of an interface.

For instance, say a particular class might want to do some logging. It might accept an ILogger as constructor parameter. But some clients of the class might have no way to do logging. One solution to this would be to allow the constructor to accept a null reference as the ILogger. But then every place in the class has to check for null before invoking an ILogger method. Instead, the Null Object Pattern requires a do-nothing implementation of ILogger to be created and used wherever one might otherwise have passed a null reference. Because null reference will not now be encountered, null checks are avoided.

It's called the null object pattern, because there is typically no need for more than one instance of the null implementation, because it will have no state and do nothing. So typically the null implementation should have a private constructor and a single public instance - the "null object".

So, this is all great, but like most patterns, it can be misused so there are some things to check about your proposed use of it: -

Liskov must be respected: the null object must be usable without knowing it is the null object

If you find yourself checking whether an object in your hand is the null object, or an instance of the null implementation, that's not the Null Object Pattern

If some methods of the interface you're implemented have no sensible null implementation, you can't use the Null Object Pattern. For instance, if you end up throwing NotImplementedException or NotSupportedException, then this isn't a good place for Null Object Pattern

There should only be one null implementation. If you find there is more than one possible interpretation of what a null implementation of the interface should do, then none of them can really be a null implementation and you can't use Null Object Pattern

When testing synchronous code, one sometimes wants to assert that a certain method has been called on a substitute object. NSubstitute has Received(), and its variants, for that: http://nsubstitute.github.io/help/received-calls/

NUnit, these days, is pretty good at testing async code. A test method can be declared async Task and can then use async/await. NUnit will "do the right thing".

However, trying to combine the two does not go smoothly. Received() either crashes or does the wrong thing, when async methods have been awaited.

Luckily there is a fairly simple solution. NSubstitute has the class Received with method InOrder(), taking an Action delegate. The delegate can be async and can use await.

Received.InOrder() is documented here: http://nsubstitute.github.io/help/received-in-order/ . It does not have to be used with async/await, but unlike Received(), it works fine with async/await.

Example

Received.InOrder( async () => { await um.CreateUserAsync(Arg.Is<User>(a => a.UserName == "a")); await um.CreateUserAsync(Arg.Is<User>(a => a.UserName == "b")); });

IPv6 - you don't understand it, but System.Uri does

Old code, and a depressing amount of new code, is full of code that passes around strings presenting URLs, then does ad-hoc parsing of the string into its components. Most of this code probably has some bugs, even in an IPv4 world, but when IPv6 addresses are added into the pot, much of it is just totally broken.

The biggest pitfall is that IPv6 addresses contain colon characters where they would never appear in an IPv4 world. But fixing your ad-hoc parsing code to account for that is not the solution.

The .Net Framework has excellent classes for parsing and creating URLs/URIs. They understand every nuance of every part of every applicable specification. These include System.Uri and System.UriBuilder. Use them.

Of course, URLs that are user-entered or configuration parameters will initially come in as text. But, as soon as possible, parse them into a System.Uri and then use that throughout your code. Don't pass URLs around as strings.

Equally, your code will sometimes need to emit URLs as text. Fine, you can get a textual representation out of a System.Uri, but do so at the last possible moment.

Finally, when constructing a URL, do not do it using string operations. Use a System.UriBuilder.

In .Net Framework, String.Contains(String) always uses Ordinal comparison. There's no culture-sensitive or case-insensitive option.

To work around this, one often sees a programmer convert both strings to lower or upper case with something like String.ToLowerInvariant() before comparison. This is both inefficient (lots of new objects - big ones if the strings are big) and ugly.

Instead, the simple solution is to use String.IndexOf(String, StringComparison). This has all the usual string comparison options.

Slightly disappointingly, IndexOf() methods return an int which is positive if found or negative if not found. This makes for slightly ugly call-sites.

To avoid such ugliness, it's trivial to make an extension method on String called Contains() that takes a StringComparison and internally uses IndexOf().

LINQ to Objects gives you two very similar methods: GroupBy() and ToLookup().

From the outside, their signatures look almost the same. GroupBy() returns an enumerable of groupings. ToLookup() returns an ILookup, which is (via inheritance) an enumerable of groupings. It just adds a Count property.

GroupBy() does almost no work when you call it. However, when you enumerate it, this constructs a Lookup and gives you its enumerator. To construct and enumerate the Lookup, it enumerates the whole original enumerable. If you enumerate the GroupBy() again, it makes another Lookup and enumerates the whole original enumerable again.

ToLookup() constructs a Lookup immediately, so it does more work when you call it. But when you enumerate it, this enumerates the already-existing Lookup. If you enumerate the result of ToLookup() again, it uses the Lookup it's already got and does not enumerate the original enumerable again.

Thus: -

It is usually better to use ToLookup(), because the possibility of expensively re-enumerating the original enumerable is eliminated. In addition, its Count property is sometimes useful.

The rare case where GroupBy() is better is when you are not sure that you will ever enumerate its results.

I just got caught out by this. Straw poll suggests not everyone else knows it, so here’s a quick note…

LINQ All() returns true when the enumerable is empty. This was not expected by me, although a colleague made a convincing mathematical explanation. It was the cause of I bug that I just fixed. MSDN Docs

LINQ Any() returns false when the enumerable is empty. I did expect this, but I include it here for completeness.

A Little Mod

I’ve been moving the man-cave into the 2010s, adding the ability to stream audio and video. But being me, I didn’t want to buy anything new or expensive. So it’s done with a second-hand Apple TV 3.

But there’s no analog audio output on an Apple TV and there’s no digital input on my old SoundCraft powered mixer. I already had a cheap converter, but it didn’t come with a power supply. I had a drawer full of old power supplies and one that supplied the right voltage. But it wasn’t very well regulated and made a nasty hum on the audio.

But we can fix that, right? Capacitor across the power supply is the standard solution. And I’m still the sort of geek who has a little drawer of capacitors to hand.

Well, on opening the box, it turned out that the manufacturer had helpfully provided a place on the PCB for such a capacitor but hadn’t fitted one. So it was dead easy to add one.

Most C#.Net programmers will be using LINQ ToArray<T>() often: -

MSDN docs

Usually, the generic type argument <T> is inferred by the compiler from the type of the source IEnumerable<T> on which it is called. This results in an array whose element type is exactly the same as that of the source IEnumerable<T>.

But sometimes, one wants an array whose element type is a supertype of T. The naive code is: -

IEnumerable<Subclass> e = GetEnumerable(); Superclass[] a = e.ToArray();

This compiles, but the array is not actually of the declared type. Sometimes that can cause problems. So, to ensure the array is of the exact declared type, one may be tempted to use: -

IEnumerable<Subclass> e = GetEnumerable(); Superclass[] a = e.Cast<Superclass>().ToArray();

This compiles and does obtain an array of the exact declared type. But it is slower than it needs to be: -

That Cast<T>() call isn't free in itself

More importantly, Cast<T>() always returns a plain IEnumerable<T> which does not know its Count. So, even if the original enumerable was a collection, ToArray<T>() cannot use the collection's count to right-size the array immediately; it has to use an intermediate List-like collection, which it re-sizes until the enumeration has finished.

To do it without performance loss, the solution is to specify the type explicitly on ToArray<T>(): -

IEnumerable<Subclass> e = GetEnumerable(); Superclass[] a = e.ToArray<Superclass>();

With the above, if the enumerable was really a collection, the array can be immediately right-sized and there's no intermediate List-like collection or wasteful resizing.

I like to make the following distinction: -

throw new NotImplementedException() should be the only statement in a method implementation. It indicates that the method is intended to be implemented in the class, but it has not yet been implemented. It generally indicates work in progress and hence should rarely be seen in released code.

throw new NotSupportedException() is typically the only statement in a method implementation, but might sometimes be predicated. It indicates that, while the method call theoretically makes sense for the class, it has been explicitly decided not to implement it. There's no implementation coming, any time soon. It might often be seen in a method that a base class or interface forces one to include in the class, but for which it has been decided not to provide a proper implementation. Be aware that this is probably a Liskov Substitution Rule violation, so should rarely be seen in SOLID code.

I have seen some posts saying that they think NotSupportedException should only be used where there exists some property for checking whether the method is supported. I wouldn't want to be that restrictive. However, where the base class/interface is available for modification, adding such properties does eliminate the Liskov violation, albeit still ending up with a bit of a "code smell".

throw new InvalidOperationException() typically is thrown only in a particular situation, within the implementation of a method. It indicates that the caller has asked the class to do something that turns out not to make sense. However, it shouldn't be used for argument checks, as there exists ArgumentException for that.

The article referenced in the above StackOverflow question gave me the chills initially, when it got to “Read Introduction”.

I was concerned that this unhelpful optimisation could make unsafe all the code I’ve written that avoids null-pointer exceptions when raising an event. The pattern is get the event into a local variable, check if the local variable is null, invoke the local variable. Read Introduction looked like it could make this wrong.

However, this fear was unfounded. When accessing an event, one is not directly accessing a field. The access to the underlying field is protected by a lock (before .Net 4) or Interlocked (from .Net 4), so Read Introduction is not going to break that code.

Phew!

I was doing some reflection of the properties of a C# interface type and was surprised to discover that I never got the properties of super-interfaces. When reflecting a class, one does get the properties, unless specifying the BindingFlags value DeclaredOnly.

It turns out that this is a well-known (but not to me) surprising behaviour, due to how interface inheritance is implemented in C#.Net. Here’s an example of others discussing it: -

http://stackoverflow.com/questions/358835/getproperties-to-return-all-properties-for-an-interface-inheritance-hierarchy