Rabbit Operations 0.9.0 Released

This version is a minor maintenance release that includes the ability to set a different expiration time for error messages to give you more time to analyze them and possibly replay them. It also includes an upgrade to the latest stable release of RavenDB.  Check out the project website for more information.

The next release, 0.10.0, will include some major improvements including a new GUI and the ability to view and analyze statistics collected from all messages.  You can check out the plan on our Trello board.

Rabbit Operations Version 0.8.0 Released

This is a minor release but it contains one significant goodie: The details dialog for errors now has a section that displays a nicely formatted stack dump. Here are the complete release notes:

  • Nicely formatted stack dump shown on details view of error message
  • Ability to view queue stats as a gauge
  • Improve performance of search screen especially when bringing back large sets of large messages
  • BUG FIX: Small memory leak in poller due to RavenDB profiler stats
  • BUG FIX: Retry to overcome RavenDB transients under high loads when there are more than 40 active queue pollers

Check it out the Project Site for more details.

RabbitOperations Project Launched

An early preview release of my new open source project, RabbitOperations, is now available at https://github.com/SouthsideSoftware/RabbitOperations. The idea is to provide some tools for managing real-world applications that use RabbitMQ. It will support popular message buses like NServiceBus and Rebus with error replay, audit & error logging, sophisticated search capabilities and likely an integration with NewRelic to log stats about queue lengths etc. This very early release lacks a UI and is only suitable for experimentation and potential contributors.

Node.js Library for Delcom Visual Indicator Published

I just published my first npm package, delcom-indicator.  It’s a basic driver for the Delcom Visual Indicator.  I built it to support the node.js build light project I am currently putting together for the Raspberry Pi.  This library supports any platform that supports node-hid, which should include Windows, Mac and most Linux distributions.  It has been tested on Mac OS/X 10.9.2 and Raspian.

The publication process for node packages is a little easier than the one for .NET Nuget packages.  To get started, you need to setup an account at npm and authorize it on your computer:

npm adduser

Assuming you have a node.js project that includes packages.json in your directory, publishing is as simple as:

npm publish

Rolled Up My Sleeves and Got Raspberry Pi Booting

So it appears that my mistake was paying a little extra for the kit.  I reformatted the SD card, downloaded the new out of the box software (NOOBS), copied it onto the SD card, powered up the Pi and about 30 minutes later it was booting just fine into Raspbian Linux.  I’ve got to pick up a supported USB WiFi device today so I can get it onto the network.  I can then start testing some code.  Fun!

I Hope I Like Raspberry Pi

Recently, we spun up a new team at Blinds.com to work on a critical add-on called Blinds Tracker for both our production web platform and our soon-to-be-released Autobahn platform.  In addition to being the Product Owner I am also handling DevOps tasks.  One of the fun things I did for the Autobahn team was to put up a physical build light from Delcom that glows green when all is well, blinks blue when a build is underway and flashes red when the build is broken.  I built the necessary utility in .NET and so the light has to be plugged into a Windows laptop that sits off in a corner polling TeamCity from time to time.

Once I had the new project building on TeamCity I decided I wanted a build light for it too.  Besides being a stop on the company tour, it provides a nice visual indication of the project’s health for me, the other team members and stakeholders that can see it from across our open floor plan office.  It’s a different team so I didn’t want to share the Autobahn build light; When it turns red, it should be because Autobahn is broken.  The teams don’t sit in the same area so I can’t really plug a second light into the existing laptop either.

Sounds simple right?  All I have to do is purchase a Delcom visual indicator, grab an old Windows laptop, install my utility and hook it up.  Unfortunately, we don’t have any unused laptops around so I’d have to requisition one.  I jokingly discussed it with one of the developers on the team and he said, “well, you’ve been working with Node.js.  Why don’t you just get it up on a Raspberry Pi.”

So in typical geek fashion I set out to save a few hundred bucks by spending some indeterminate hours of my personal time putting together a Node.js build light application for Raspberry Pi.  I’m lazy so I ordered the Raspberry Pi B (512MB Ram, 2 USB Ports, HDMI and Ethernet), a USB Wifi dongle, a micro USB power supply, an 8gb SD card and a clear case from Amazon.  I also ordered a tri-color USB visual indicator from Delcom.  It will all arrive at the house early next week.  In the meanwhile, I’m going to start building a Node.js website to configure settings and a TeamCity poller that will eventually drive the light.  I think I can get it setup to work on any platform that supports HID so it will likely work on various flavors of Linux, Mac and PC in addition to the Raspbian Linux distribution for Raspberry Pi.  It will be an open source project and I’ll put the source up on Github.  Should be fun.

Lissome Project

Just started working on the design for the project I discussed in my last post.  I decided to call it Lissome, which means, among other things, “nimble”.  Seems like a decent name for an agile task board.   The Balsamiq mockup can be found in the Lissome repository.

I decided to license it under AGPL .  I realize this license is fussier than many other open source licenses about making source changes freely available, but that is precisely the point.

Building Something Twice (Just for Fun)

I’ve been playing with Node.js a bit lately and have been looking for something fun and useful to do with it.  Along the way, I’ve also developed a curiosity about how a well-written, non-trivial Node.js application might compare to an equally well-written .NET application in terms of features, quality and development time.  Today, I am starting a spare time project to satisfy my curiosity.

The idea is to develop an agile task board application with a highly-interactive web front end and two different fully scalable backends: the first in Node.js and the second in .NET.  My goal is to make the backends as interchangeable as possible.  My initial guess is that the only difference in how the client will communicate with the backend is in the area of server notifications, which will probable use socket.io with the Node.js backend and SignalR with the .NET backend.  For simplicity, both backends will use the same hosted NoSQL and search facilities.  I’m leanings towards RavenDB hosted by RavenHQ simply because I am familiar with it and because it includes powerful search capabilities.

The whole thing will be open source and I’ll blog about it as I progress.  I’ll start by sketching a basic UI wireframe so I can put together an initial product backlog.  Wish me luck.

A Tale of Five IoC Containers

In my spare time over the last week or so I added a very simple IoC container abstraction to ProjectExtensions.Azure.ServiceBus. Incidentally, if you are interested in building scalable applications that use a service bus, the ProjectExtensions version is a great lightweight choice whether your application lives on Azure or not. The Azure Service Bus API is fairly simple itself until you start dealing with tricky bits like transient faults and the need to poll intelligently to pick up new messages. The ProjectExtensions library takes care of all the nasty details so all you have to do is put messages on the bus and define classes to consume them. Although it does not have nearly all the features of NServiceBus, it doesn’t have all the complexity either. I should also note that the Azure service bus is easy to configure, very fast and extremely inexpensive. In many ways, it is even a better choice than MSMQ for applications that live outside Azure if you want your application to be easy to deploy and manage. Anyway, enough digression; I’m here to talk a little about the IoC container abstraction I put together for the ProjectExtensions Azure bus project.

Well, that’s not exactly true either. I’m not going to talk about the implementation. There’s nothing particularly interesting, complex or tricky about it. If you don’t believe me, go look at it on Github. I’ll wait. Boring huh? Anyway, many open source projects implement a minimal application-specific IoC abstraction. On the service bus side, you can find IoC abstractions in both NServiceBus and Rhino Service Bus. I would guess MassTransit has one too. Does anyone use MassTransit anymore? Geez, I’m digressing again. What was my point?

Ahh, I remember now. It sure was easy to put together a simple IoC abstraction for ProjectExtensions.Azure.ServiceBus because at their core all five popular IoC containers I used, Autofac, Castle Windsor, Ninject, Structure Map and Unity, have similar capabilities, similar APIs and perfectly adequate performance. Certainly, they all have slightly different philosophies and, when you dig deep, significant differences in their APIs. I am simply not the right guy to get into those details here. I am fairly expert with Castle Windsor and Autofac, but knew very little about the others until a couple days ago. If you want an expert, in-depth analysis, along with some great insight into how and why to use DI/IoC, go get a copy of “Dependency Injection in .NET” from Manning Press. My only intent here is to point out that they all work and they all work well for the basic use cases in ProjectExtensions.

So what does ProjectExtensions do with the IoC? Well, it’s as simple as the following:

/// <summary>
/// Generic IOC container interface
/// </summary>
public interface IAzureBusContainer {
    /// <summary>
    /// Resolve component type of T with optional arguments.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    T Resolve<T>() where T : class;

    /// <summary>
    /// Resolve component with optional arguments.
    /// </summary>
    /// <param name="t">The type to resolve</param>
    /// <returns></returns>
    object Resolve(Type t);

    /// <summary>
    /// Register an implementation for a service type.
    /// </summary>
    /// <param name="serviceType">The service type.</param>
    /// <param name="implementationType">The implementation type.</param>
    /// <param name="perInstance">
    /// True creates an instance each time resolved.  
    /// False uses a singleton instance for the entire lifetime of the process.
    /// </param>
    void Register(Type serviceType, Type implementationType, bool perInstance = false);

    /// <summary>
    /// Registers the configuration instance with the bus if it is not already registered
    /// </summary>
    void RegisterConfiguration();

    /// <summary>
    /// Build the container if needed.
    /// </summary>
    void Build();

    /// <summary>
    /// Return true if the given type is registered with the container.
    /// </summary>
    /// <param name="type"></param>
    /// <returns></returns>
    bool IsRegistered(Type type);

Pretty simple huh? Given the requirement to support any IoC, this kind of interface works pretty well. It gives us everything we need to allow library users to leverage the IoC container of their choice without making our lives too difficult. Because the interface is very simple, it is also quite easy for library users to roll their own support for any IoC they use that we don’t happen to support ourselves. If we settled for supporting only one container, we could have a far more elegant implementation. In fact, that’s what we had when we started with Autofac. However, consumers wanted to use the IoC of their choice with minimal fuss and this interface makes that possible.

There is one little twist left and that’s disposal of per-instance components that happen to implement IDisposable. Castle Windsor, for example, will hold onto disposable components until they are released. There are a couple ways to solve this. For example, some of the containers have the concept of a subcontainer that releases disposables when it goes out of scope. However, I want to keep this implementation simple so a little more investigation is needed. I’ll post the solution I settle on next time.