How to: disable on screen notifications for Caps Lock/Num Lock/Scroll Lock in Microsoft keyboards

Leave a reply

I wish I didn’t have to write this post, but there was just no easy information available about this seemingly easy task. Normally, I wouldn’t even have bothered, but during playing Battlefield 3 (or other full-screen games), if you happen to hit Caps lock, this popup will cause the game to run in window mode (and having you killed in the process!).

I have a Microsoft Wireless Keyboard 7000, and if your popup looks like the one in the image above, you can disable it with the Microsoft IntelliType software.

Here’s how to disable those annoying on-screen notifications for caps lock, scroll lock and num lock from appearing on your screen:

  1. If you haven’t already, download and install Microsoft IntelliType
  2. Open it by typing “Microsoft Mouse and Keyboard” in Start menu/screen, and select your keyboard
  3. Point your mouse cursor on the key you want to disable (CAPS LOCK, for example):
  4. Click the highlighted CAPS LOCK entry (or click on the CAPS LOCK button with the mouse, and DISABLE “Display CAPS LOCK status on the screen”:
  5. Repeat the process for other keys, if you want
  6. Enjoy bother-free gaming!

First Rule of Unit Testing: Don’t do it! (yet)

Leave a reply

I wasn’t sure how I’d like to begin this blog post. Instead of writing a long and boring introduction that drives my point, I’ll just dump all that boiled inside me for quite a while. Sarcasm and bitterness ahead!

I’ll start from the end: it wasn’t until a former colleague of mine, Gil Zilberfeld, wrote his post about how in our industry we shifted from choosing “individuals and interactions” over “tools and processes” (or whatever the Church of Agile calls it) to having an almost a knee-jerk reaction to someone doing horrible things to our vision of a perfect code.

Think about it, how many times have you started a new job or met a new client, and once you’ve managed to get their code onto your machine, you shrieked in horror and facepalmed over some things “you people wouldn’t believe”? A SomethingManager class that takes in 12 dependencies?! No Unit Tests?! A solution with 180 projects?! Very-similar-but-with-slight-variations duplicated monster classes?! And you think to yourself: surely those people heard of the SOLID principles? Surely they’ve seen a webinar or two on Unit testing and TDD? They might even know what IoC and DI is, and the difference between them. How is it possible, then, that after more than a decade since we got all those wonderful acronyms people still write and maintain horrible mess?

The sad truth is, writing the perfect code is hard. It takes practice, years of experience in doing EXACTLY that – writing good code, and getting better at it. But we are all guilty of writing bad code. Because we don’t know any better. Sure, some are better than others, some have read a book or two on good software practices, some attend conferences and have open source projects – but they are the minority. Most of the time you will be the minority among your peers. Your colleagues don’t have time for your “unit-testing” nonsense, they have bugs to fix and deadlines to miss. If you are in a position of power, you may force some practices on your team because you have seen the light. And you’ll be lucky if they don’t hate you for it.

What does this have to do with unit testing? Well, it depends on who you ask. People who claim to have tried unit testing and found it too hard and a waste of time will generally roll their eyes in your general direction during yet another presentation on “The Benefits of Unit Testing”. People who have never heard about it before (or otherwise completely unfamiliar) will be intrigued – unit testing? Great! “We want something that tests that our distributed systems can communicate with each other under load!”, they exclaim. You politely smile and say: “Well, not so fast! Unit tests are not actually testing anything! If only we could go back in time and remove the word testing from this practice, maybe it would be less confusing…”.

And having seen the presentation, or read a book, or even attending a 3 day course on unit testing, those developers go back to their code bases, trying to apply what they had learned, and suddenly realizing that it’s too difficult! If only in the real world we were all building calculators and logging frameworks, surely the tests could be much simpler! But alas, we write distributed WCF systems, with transactions, states, workflows and proprietary protocols. How on earth are we going to unit test that?!

We as developers often forget our own guidelines and “best practices”, just because doing something right would be too much work. The WCF service now needs to communicate with another external system? Not a problem, just inject that interface (of course an interface, what do you think we are, amateurs?!) in the constructor (it already takes 9, but surely we can fit one more in there)! Code code code, debug debug debug, fix fix fix, debug debug debug, run, done. What did we forget? Of course, the damn unit tests! Now they are all broken because the new interface needs to be mocked and its behavior stubbed. And hey, didn’t we have that “unit testing guy” around? Let him fix it!

Which brings me to the actual point (if there is any) of this rant. It’s not just about unit testing. It’s about everything else too. I just tend to defend unit testing more because I am one of those who “had seen the light”, and I know exactly when to apply (or not) what I’ve learned. I have been practicing unit testing and TDD for years, but only recently had an epiphany. See, I always thought the problem with the term unit tests was the word test – people simply misunderstand the purpose of this – it’s not really testing anything, it is supposed to expose all the problems with using your API. Unit testing novices almost always will attempt to write the tests for the code they just wrote and will beat it into submission, until it passes. By that time, they have spent 20 minutes sweating, swearing and writing a very long test method, which has no real benefit or value.

I came to realize the real problem with the concept of unit testing. This realization came to me shortly after seeking help (see? I am constantly learning!) on refactoring a mess of a WCF service. Steven (@dot_NET_Junkie) posted an amazing, incredibly-detailed answer on how to approach this type of refactoring. By actually breaking responsibilities into smaller, self-contained components, or units, it suddenly became clear to me that the problem might actually be with the word unit itself – it is not a “unit of work” or a “method” or even a “class”, as it is often defined, but rather a level of abstraction. When all you have is a giant Manager class that takes 9 dependencies, and just one public method, the only possible way you can write a unit test for it is by directly invoking those dependencies – in essence, writing tests for the implementation details of the Manager class, and that’s a big no-no in unit testing – you should not write tests for the implementation details. This is why by adding a 10th dependency to the Manager class, you suddenly have to modify all your other tests to wire this dependency in, and mock it until it fits. This is why tests break and they become hard to write and maintain – they are not testing at the right level of abstraction, not at a unit level.

In this order: Better abstractions lead to better design. Better design leads to better unit tests. Better unit tests lead to quicker responsiveness to change. Quicker responsiveness to change leads to predictable release cycles of working software. And isn’t it what it’s all about?

Even more ReSharper Annotations hackery: marking 3rd party code as obsolete

2 Replies

As part of transitioning to a new API, I wanted a way to mark the old API as obsolete, so that Visual Studio (or ReSharper) would flag using of the old API as an error.

Normally, the ObsoleteAttribute does exactly that – marks certain methods or types as obsolete, and has a constructor overload to specify whether the usage will be treated as an error or not. Unfortunately, in my case there was no source code for the old API (it was used as a 3rd-party DLL), and there’s no way to apply the Obsolete attribute to external DLLs without modifying the assembly using IL-rewriting tools.

It had occurred to me that perhaps this would be possible to achieve using one of ReSharper’s External Annotations, but there are no built-in annotations for this kind of task. The annotations mechanism is used to decorate various .NET types and methods with special attributes that provide ReSharper with additional information. Turns out, it is possible to use the same mechanism to apply the Obsolete attribute as well! This way, ReSharper could mark the usage as an error, even if it’s not really a compilation error (which is good enough for me!).

I previously wrote about how to add external annotations using XML files. According to ReSharper’s documentation, external annotation XMLs can be placed in one of the following locations:

  • [ReSharper install directory]\Bin\ExternalAnnotations\[Assembly name].xml
  • [ReSharper install directory]\Bin\ExternalAnnotations\[Assembly name]\[Any name].xml, where [Assembly name] is the assembly name without the version
  • Alongside the assembly, named [Assembly name].ExternalAnnotations.xml

Since the old assembly was under my control, I chose the 3rd option, to place the annotations XML next to the assembly, and in the source control. This way, every team member that uses ReSharper will have this annotation enabled by simply updating to the latest source.

The external annotations XMLs are the same format as XML documentation files, generated by Visual Studio when you build your assembly. Supposing our assembly name is Acme.OldServiceBusImpl.dll, and the type we want to make obsolete is called EventBus, we need to create a file called Acme.OldServiceBusImpl.ExternalAnnotations.xml, and place it beside the DLL. The file has the following content:

<assembly name="Acme.OldEventBusImpl">
  <member name="T:Acme.OldEventBusImpl.EventBus">
    <attribute ctor="M:System.ObsoleteAttribute.#ctor(System.String,System.Boolean)">
      <argument>Use Acme.NewServiceBusImpl.ServiceBus instead.</argument>
      <argument>true</argument>
    </attribute>
  </member>
</assembly>

This specifies that for an assembly named Acme.OldServiceBusImpl, having a type Acme.OldEventBusImpl.EventBus, add an attribute instance of ObsoleteAttribute with the constructor overload ObsoleteAttribute(string, bool), the boolean indicating the usage is considered an error.

After adding the XML file and reloading your project, ReSharper will now mark the usage of this type as an error! Your code will still compile, but you’ll get red on you!

Happy hacking!

More fun with ReSharper annotations in ASP.NET MVC!

5 Replies

After my previous blog post on the subject, my good friend Avi Pinto asked if it was possible to “teach” ReSharper to treat an ASP.NET MVC HtmlHelper extension method to understand and navigate to relative paths within the project. I’m happy to report that not only this is possible, it also requires almost no effort at all!

Considering the following extension method:

public static HtmlString RegisterVersionedScriptInclude(
    this HtmlHelper helper,
    string path)
{
    ...
}

which is used in the following way:

<%= @Html.RegisterVersionedScriptInclude("/Scripts/jquery.ellipsis.js") %>

PathReferenceAttribute

In order to have ReSharper understand the string to be a real path reference, all we need to do is to decorate the path parameter of the extension method with a ReSharper Code Annotation attribute called PathReferenceAttribute. Our extension method will now look like this:

public static HtmlString RegisterVersionedScriptInclude(
    this HtmlHelper helper,
    [PathReference] string path)
{
    ...
}

After adding this attribute, ReSharper will now treat the string as a real path reference, providing us with all the goodness:

Incorrect paths:

Code completion:

Navigation (by holding Ctrl-click, or Go to Declaration):

In addition, since ReSharper 6 the PathReferenceAttribute takes a basePath as a parameter, allowing you to specify the initial directory it will look in. So if we’re always looking for scripts in, say, Scripts directory, we can specify it via

[PathReference("~/Scripts")]

and have our extension method look in Scripts first:

Supercharge your extension methods!

Preventing ReSharper’s “implicitly captured closure” warning in FakeItEasy unit tests

Leave a reply

I noticed that some of my unit tests have a ReSharper warning on the A.CallTo() methods of FakeItEasy, suggesting that some local variables are captured implicitly by the lambda expression.

This warning appears since ReSharper doesn’t know that the lambda expression is executed immediately when the A.CallTo method is invoked. Fortunately, with the help of External Annotations, in particular, the InstantHandle annotation, we can teach ReSharper about it!

The InstantHandle annotation tells ReSharper that the method parameter is completely handled when the invoked method is on the stack. If the parameter is a delegate (which in our case, it is), it indicates that the delegate is executed when the method is executed.

To add this information about FakeItEasy’s A.CallTo() overloads that accept delegates, we can create an external XML file, which looks like this:

<?xml version="1.0" encoding="utf-8"?>
<assembly name="FakeItEasy">
  <member name="M:FakeItEasy.A.CallTo(System.Linq.Expressions.Expression{System.Action})">
    <parameter name="callSpecification">
      <attribute ctor="M:JetBrains.Annotations.InstantHandleAttribute.#ctor" />
    </parameter>
  </member>
  <member name="M:FakeItEasy.A.CallTo``1(System.Linq.Expressions.Expression{System.Func{``0}})">
    <parameter name="callSpecification">
      <attribute ctor="M:JetBrains.Annotations.InstantHandleAttribute.#ctor" />
    </parameter>
  </member> 
</assembly>

Download the XML via GitHub Gist,

This instructs ReSharper to add an instance of the InstantHandleAttribute to a parameter called callSpecification of two CallTo method overloads, once which takes an Expression<Action>, the other, which takes an Expression<Func<T>>. Save this file as FakeItEasy.ExternalAnnotations.xml and place it alongside FakeItEasy.dll (inside libNET40 of your NuGet package, for example). Reload your solution, and the warnings will now disappear!

Stay tuned, as I explain in the next blog post how to create those XML annotations easily with a little known ReSharper trick!

Turning old and busted asynchronous code into new async/await-enabled hotness with TaskCompletionSource

1 Reply

While working with a client to create a new version of their software, one of the tasks was creating a service that talked to a hardware laser tracker, a device which allows tracking certain points (“targets”) over a large distance.

The API provided by the manufacturer was… not ideal, to say the least. The API consisted of a managed wrapper over two classes, we’ll call them Request and Response, providing asynchronous request and callback operations. For each operation on the Request object, a corresponding Answer operation would arrive asynchronously on the Response object, e.g. if a GetPosition method was called on Request, sometime later an OnGetPositionAnswer method would arrive on the Response object, containing the relevant information.

One of the requirements was to be able to wait for several of such callbacks to arrive, before doing another operation. Several options were considered, among them Reactive Extensions (Rx) and TPL Dataflow. In the end, I chose an approach based on the TaskCompletionSource<T> class (part of the TPL), which I describe below.

Having exposed a .NET event in the Response object for each of the callbacks we were interested in, I defined a following method, returning a Task<T>, where T was the object that contained the data I required:

public Task<PositionData> GetPositionAsync()
{
    var tcs = TaskCompletionSource<PositionData>();

    // subscribe to the callback before firing the request
    _response.GetPositionAnswer += (sender, args) =>
    {
        PositionData data = ... // translate position data from the event's arguments
	
        tcs.SetResult(data);
    };

    // perform the actual operation (method is asynchronous, returns immediately)
    _request.GetPosition();

    return tcs.Task;
}

And it worked great! The caller of GetPositionAsync now had a task which he can either await (if using .NET 4.5, or in .NET 4.0 using Async Targeting Pack (now known as Microsoft.Bcl.Async), but only if running in Visual Studio 2012), or using plain old methods, available on the Task object.

However, upon calling this method a second time, an InvalidOperationException “An attempt was made to transition a task to a final state when it had already completed.” was thrown on the tcs.SetResult(data) line. It took me a second to realize the bug, can you see it?

The problem occurred because the event handler was not unsubscribed from, after the task had completed! Since the handler is a lambda expression, it captured the variable tcs when it was created. When we called GetPositionAsync() the second time, we made another subscription to the event handler, but when it fired, the first subscription was handled first, attempting to set the result of the first TaskCompletionSource instance, which had, of course, already finished.

Unsubscribing from an anonymous method (or a lambda expression) is possible, but not very pretty. It requires a small abuse of the C# syntax, to have the handler stored in a local variable, then subscribed and unsubscribed from. After a bit of tweaking, this was the end result, solving the problem:

public Task<PositionData> GetPositionAsync()
{
    var tcs = new TaskCompletionSource<PositionData>();
   
    // Declare and initialize a local variable of type EventHandler to null
    // This is needed to use the variable inside the lambda expression body
    EventHandler handler = null;
    handler += (sender, args) => 
    {
        PositionData data = ... // get the data from event args
        
        tcs.SetResult(data);
        
        // unsubscribe from the event handler when task is complete
        _response.GetPositionAnswer -= handler;
    };
    
    // subscribe to the event handler before executing the operation
    _response.GetPositionAnswer += handler;
    
    _request.GetPosition();
    
    return tcs.Task;
}

It’s not very pretty, but it does the job. If anyone has a better suggestion, please leave a comment!

Until next time, happy asyncing!

Running multithreaded unit tests with FakeItEasy

Leave a reply

While running some of my tests today, I suddenly got an IndexOutOfRangeException, with the following stack trace:

at System.Collections.Generic.List`1.Add(T item)
   at FakeItEasy.Core.FakeScope.AddInterceptedCall(FakeManager fakeManager, ICompletedFakeObjectCall call)
   at FakeItEasy.Core.FakeManager.RecordInterceptedCall(InterceptedCallAdapter interceptedCall)
   at FakeItEasy.Core.FakeManager.Intercept(IWritableFakeObjectCall fakeObjectCall)
   at FakeItEasy.Core.FakeManager.Proxy_CallWasIntercepted(Object sender, CallInterceptedEventArgs e)
   at FakeItEasy.Creation.CastleDynamicProxy.CastleDynamicProxyGenerator.ProxyInterceptor.RaiseCallWasIntercepted(IInvocation invocation)
   at FakeItEasy.Creation.CastleDynamicProxy.CastleDynamicProxyGenerator.ProxyInterceptor.Intercept(IInvocation invocation)
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at Castle.Proxies.ObjectProxy_3.Info(String format, Object[] args)

The code under test was using Tasks to do some work in the background, and was using a fake instance of an ILogger, which was created with FakeItEasy and passed to the code under test.

The above stack trace shows a classic symptom of a thread-safety issue. Searching for this issue led me to this bug report, where a similar problem was described. Patrik Hägne, the creator of FakeItEasy, argues that using threading in tests is always problematic, however provides a nice and elegant solution to work around the problem.

The problem, of course, that the fake instance of the logger was not thread-safe, causing the underlying interceptor to incorrectly record the calls made to the fake logger object. However, when creating fake objects with FakeItEasy, it’s possible to specify build options for the fake instance. This is where Patrik’s solution comes in: wrap the fake instance with a syncronization interceptor, which can be applied in the following way:

A.Fake<ILogger>(x => x.Synchronized());

Where Synchronized() is an extension method you can define in your tests:

public static class MyPersonalFakeExtensions
{
  public static IFakeOptionsBuilder Synchronized(this IFakeOptionsBuilder builder)
  {
    return builder.OnFakeCreated(fake => 
	Fake.GetFakeManager(fake).AddInterceptionListener(new CallSynchronizer()));
  }
}

And CallSynchronizer is an implementation of IInterceptionListener, which simply adds locking around method execution:

public class CallSynchronizer : IInterceptionListener
{
  private static readonly object synchronizationLock = new object();

  public void OnBeforeCallIntercepted(IWritableFakeObjectCall call)
  {
    Monitor.Enter(synchronizationLock);
  }

  public void OnAfterCallIntercepted(IWritableFakeObjectCall call)
  {
    Monitor.Exit(synchronizationLock);
  }	
}

And that’s it – using this code you can create a thread-safe fake objects to use in your tests, if you require.