Akka.NET, Prism, Unity, and WPF

Since I’ve been reading up on Reactive Extensions, I listened with interest to the recent .NET Rocks! podcast on the subject. During the conversation, Akka.NET was mentioned.

Akka.NET is another reactive technology. It’s an implementation of the Actor model. Basically, you break down an application’s functionality into small computational units called Actors which have limited state and communicate via message passing. There are parallels in Rx’s concept of observables and observers. Akka.NET also provides the kind of supervision hierarchy that you find in erlang, which is that an actor has child actors and when those child actors fail, the parent can resume or restart the failed children. This makes the application ‘self healing’.

I watched two Pluralsight course on Akka.NET by Jason Roberts, Building Concurrent Applications with the Actor Model in Akka.NET and Building Reactive Concurrent WPF Applications with Akka.NET (subscriptions required for both links). The former gives an overview of Akka.NET and the latter applies it to an MVVM WPF application.

In the demo MVVM application, the author uses Akka.NET with Ninject dependency injection and the MVVM Light toolkit. Personally, I prefer Unity and Prism, so as an exercise for myself I created the demo using those two languages. The result is on GitHub at https://github.com/mkb137/AkkaPrismUnityDemo.

The project consists of
* Akka.DI.Unity – A copy of Akka.NET’s Akka.DI.Unity upgraded from Unity 3.5 to Unity 4.0. No code changes were required otherwise.
* AkkaPrismUnityDemo – The Prism shell project
* AkkaPrismUnityDemo.Infrastructure – The common infrastructure project (which in this simple demo only contains the region names)
* AkkaPrismUnityDemo.Modules.Stocks – The main module containing the demo code.

A screenshot of the result is shown at the top of this post. In it, the view model creates actors which then have knowledge of the view model that created them and will call methods on the view model when messages are received and processed.

Here a view model creates an actor and passes it a reference to itself:

this.StockToggleButtonActorRef = 
    this.UnityContainer.Resolve<ActorSystem>()
    .ActorOf( 
        Props.Create( () => new StockToggleButtonActor( 
            this.StocksCoordinatorActorRef, 
            this, 
            this.StockSymbol
        ) 
    ) 
);

Here the actor makes a callback to the view model:

this.Receive<ToggleStockMessage>( message => {
    this._stocksCoordinatorActorRef.Tell( new WatchStockMessage( this._stockSymbol ) );
    this._viewModel.UpdateButtonTextToOn();
    this.Become( this.ToggledOn );
} );

Like Rx and its Observables/Observers, messages are handled on the thread pool so actors will make full use of the processors available on the machine with no extra effort from the developer.

It’s an interesting technology. Compared to Rx, Akka is missing some of Rx’s advanced publish/subscribe methods like the ability to buffer or throttle messages. It does have a Sample equivalent via the scheduler’s ScheduleTellRepeatedly method. On the plus side, it provides the supervision hierarchy and provides a more natural message pipeline. With Rx it seems like having an object that is both observer and observable (i.e. is part of a pipeline), while supported, is somehow discouraged.

Outlook Add-In for Replicon

My employer uses Replicon to track hours against projects and tasks. Its web-based user interface is…adequate. Entering time in an online calendar is fine but I already have an electronic calendar open all day: Microsoft Outlook.

I started a project to create an add-in that adds an “Add to Replicon” menu item to the Outlook calendar. The Replicon Repliconnect API is used to get project and task information and to send the timesheet information back to the server.

It’s still a work in progress. The initial code is up here.

TFS Colorizer extension for Google Chrome

TFS Colorizer extension for Google Chrome

We use Microsoft’s Team Foundation Server at work.  It has a task board showing the development, testing, documentation, and other tasks that go into a release as cards in “Not Started”, “In Progress”, or “Done” columns.  The idea is to let you see the status of your project at a glance, but all the cards are the same color.  What’s the status of the release?  Are we waiting on development?  Testing?  UAT?  You can’t tell without reading every card title.  It would be better if, say, all development tasks were in green, all testing tasks were in orange, and all development tasks were in yellow.  Is the “Not Started” column filled with mostly green?  Yes?  Then we’re still waiting for development.  When we see the “Done” column filling up with green and the “In Progress” columns filling up with orange, we know we’ve entered the testing phase.  If you can colorize the cards on the board, you can see the status of your project at a glance.

That’s what this plugin does.  It lets you associate card colors with text contents.  If the card title starts with “Analysis” it’s red.  If it contains “Testing”, it’s orange, and so on.  It makes the TFS board far, far more useful.

Download the plugin here: TFS Colorizer

The code is up on github.