Archive | October, 2010


29 Oct

With Rx, comes the ability to use different schedulers to have different scheduling effects.  By default the following schedulers are provided via the static Scheduler class.

public static CurrentThreadScheduler CurrentThread { get; }
public static DispatcherScheduler Dispatcher { get; }
public static ImmediateScheduler Immediate { get; }
public static NewThreadScheduler NewThread { get; }
public static TaskPoolScheduler TaskPool { get; }
public static ThreadPoolScheduler ThreadPool { get; } 

As we design our classes for testability, yes you do really, if our class uses Rx and uses a scheduler, such as the NewThreadScheduler, this makes it very hard to test our code.

For this blog post, we’ll be ignoring the TestScheduler as this post is more on class design as to testing the code directly.

The simplest solution, and hence the short blog post, is for once, we have a Microsoft library that uses interfaces. 🙂  All schedulers implement IScheduler which means we can wrap up all the static schedulers into an interface and inject them into our class.  For e.g.

public interface ISchedulerService
public static IScheduler CurrentThread { get; }
public static IScheduler Dispatcher { get; }
public static IScheduler Immediate { get; }
public static IScheduler NewThread { get; }
public static IScheduler TaskPool { get; }
public static IScheduler ThreadPool { get; } }
public class SchedulerService : ISchedulerService
public static IScheduler CurrentThread { get { return Scheduler.CurrentThread; } }
public static IScheduler Dispatcher { get { return Scheduler.Dispatcher ; } }
public static IScheduler Immediate { get { return Scheduler.Immediate ; } }
public static IScheduler NewThread { get { return Scheduler.NewThread ; } }
public static IScheduler TaskPool { get { return Scheduler.TaskPool ; } }
public static IScheduler ThreadPool { get { return Scheduler.ThreadPool ; } }

Now that our scheduler service is interfaced out, this means we can now mock out the ISchedulerService in our tests.

Simple, but neat.


Reactive Extension Design Guidelines

28 Oct

The Rx team have released some official guidelines for our consumption.  It is a pretty interesting read and has some good tips.

My favourites:

Consider drawing a Marble-diagram
Draw a marble-diagram of the observable sequence you want to create. By drawing the diagram, you will get a clearer picture on what operator(s) to use.

Subscribe implementations should not throw

As multiple observable sequences are composed, subscribe to a specific observable sequence might not happen at the time the user calls Subscribe (e.g. Within the Concat operator, the second observable sequence argument to Concat will only be subscribed to once the first observable sequence has completed). Throwing an exception would bring down the program. Instead exceptions in subscribe should be tunneled to the OnError method.

Implement new operators by composing existing operators.
Many operations can be composed from existing operators. This will lead to smaller, easier to maintain code. The Rx team has put a lot of effort in dealing with all corner cases in the base operators. By reusing these operators you’ll get all that work for free in your operator.

Edge UG Videos

21 Oct

Since we created some great content in the 3 or so years, I thought I’d bring a blog post of all the cool videos Ian Smith did for us.  Some great reminiscing here. Smile

When Agile Goes Bad – Seb Lambla

MVC Best Practises – Seb Lambla

Hyper-V – Jeremy Pack

Visual Studio 2010 – Jason Zander

OWASP – Top Ten Vulnerabilities – Barry Dorrans:

Part 1

Part 2

Iron Ruby – Ben Hall

Mix10 Recap – Adam Kinney

Part 1

Part 2

F# – Phil Trelford

.NET Package Management Tools – A thought

18 Oct

I was chatting with Mark Rendle on Twitter this evening about the emergence of some pretty neat package management tools for .NET devs.

My main gist was that I don’t see why there is such a clamouring for these tools.  At the risk of sounding like a 97 1/2 year old developer, I’ve not seen much need for a hard-core package management app.  In the current project that I am involved in, we have aournd 24 assemblies, with probably a total of 20-25 dependencies on external DLLs (RhinoMocks, PRISM, Rx etc.)

At no point do we feel overwhelmed with the number, or the requirement for keeping these up to date.  Our primary concern is the app itself and the intricacies in getting Fx prices onto a screen where a trader can place his/her trades.

While I do see the ability to retrieve and update packages in the Ruby  gem way, I don’t see an uptake that the propaganda seems to be promising.  What we do need however, is the take-up where a software process includes this as a “standard” like source control instead of something that we could have.

I guess in my old age, I’d like to see the feedback loop kick off a little more before I zimmer my way down that road.

Lost Blog Content

12 Oct

It seems I’ve lost the old content from the EdgeUG hosted NonDestructive blog. Pretty sad as I had some cool posts. I’m still trying to recover the content, but I’m not feeling hopeful. Oh well.

Linqpad and the Rx Framework

12 Oct

Linqpad is an indispensible tool for day to day development. Bring in the fact that I am using the Reactive Framework every day means that we definitely want to combine the two.

Good news everyone! With the newer versions of Linqpad, you are able to build up your Rx queries, and at the last minute use the linqpad extension method .Dump() and lo and behold, the query will be subscribed to, with the results of the query appearing in the results window.

Great tip! 🙂

Reactive Extensions – A 7 part series

7 Oct

A good friend of mine, Lee Campbell, has posted a great series of blog posts on Devlabs’ newest toy – Reactive Extensions.