PhatBoyG.com

So I’ve been writing a rules engine for .NET for many years (on and off, but mostly off unfortunately). Lately, I picked it up again and yesterday published an early version on NuGet (OdoyuleRules). The implementation at this point is capable of pretty extensive matching, but testing is light at this point so there are probably some rough edges.

One of my favorite features is the visualization of the RETE graph once the engine has been loaded with rules. An example is shown below.

You can download the Visualizer and install it in Visual Studio 2010 (unzip the contents to your My Document/Visual Studio 2010/Visualizers folder). Then, mouse over a reference to a rules engine while debugging and you should be able to select and display the RETE graph of the engine.

Download the visualizer assemblies here: OdoyuleRulesVisualizer.zip

The project is hosted on GitHub, at http://phatboyg.github.com/OdoyuleRules

Enjoy!

When you pull down the samples I’ve linked, the packages folder is not included (mostly because it is huge).

To restore, the packages folder in Visual Studio 2010, right-click on the Solution and Enable the Package Restore option. This is really useful for both these downloads, and if you are building your solutions on a CI server so that you don’t need to check the packages folder into Git (saving space on your source code repository as well).

If you attended my presentation at the Dallas Day of .NET on SignalR, the source for the demo is available below.

The demo uses SignalR, ASP.NET MVC, and MassTransit to communicate between an external service (the console app), the web site, and the browser application, showing how an end-to-end solution with back-end events being published out to the browser could be accomplished.

SignalBusDemo.zip

If you attended my talk at Dallas Day of .NET 2012 and would like the bits from the MassTransit session, you can download them below:

MTLearn.zip

The actor programming model is a software development method that encourages the decomposition of applications into autonomous components which are self-contained and operate asynchronously and independently from one another. This model is well aligned with the nondeterministic nature of distributed systems, including mobile systems, interactive systems, and the internet.

As I mentioned previously, I didn’t invent it. I’m merely leveraging the information obtained from a number of sources and applying it in a way that I think makes it easier to build certain types of applications. Applications that can benefit from a highly concurrent actor-based programming model include reactive systems — ones that respond to nondeterministic external events. Since many applications can be described as “a program that responds to external events” it only makes sense that the actor programming model can be applied to many domains.

Here are some papers that I’ve read on the actor model, some of which have influenced me in how I think about concurrent programming and others that have merely provided background information or depicted ways in which concurrent programming should not be approached.

Actors, Rajesh K. Karmani, Gul Agha

Actors: A Model of Concurrent Computation In Distributed Systems, Gul A. Agha (out of print)

Actor Languages for Specification of Parallel Computations, Gul Agha, Wooyoung Kim, Rajendra Panwar

An Actor-Based Framework for Heterogeneous Computing Systems, Gul Agha, Rajendra Panwar

Actors that Unify Threads and Events, Philipp Haller, Martin Odersky

Lightweight Language Support for Type-Based, Concurrent Event Processing, Philipp Haller

Compilation of a Highly Parallel Actor-Based Language, WooYoung Kim, Gul Agha

These are some of the more involved works from which I’ve found many useful bits of information. I’ve got them permanently stored in GoodReader so I can keep looking back to them (and my associated annotations as well). Hopefully anyone looking to build systems using the actor model (and hopefully, using Stact if you’re on the .NET platform) can get a better understanding of the model by reviewing these papers.

At the end of October, we released MassTransit v2.0.1 to GitHub and NuGet. This release only included a few fixes that didn’t make it into the v2.0 release. Since I never made an official announcement of v2.0 on the blog, some links to the project, documentation, and mailing list are included below.

For those using the 1.x lineage of MassTransit, v2.0 includes several breaking changes in the API. This was necessary to reduce the complexity of getting new users up-to-speed, as well as eliminating some common areas of confusion. The API for v2.x should remain consistent from this point forward (well, until we start working on v3.x, which is a long ways off honestly).

Project Site (hosted on GitHub)
NuGet Project
Documentation
Mailing List
Ohloh Metrics

It’s worth noting that the MassTransit organization on GitHub is the ‘official’ repository. Please file any issues on that repository so that all of the MassTransit team members can help with any issues. However, you are encouraged to check the mailing list first as many first-time issues are discussed there.

This release was a long road and involved a lot of internal code cleanup, API grooming, and support for a new transport (RabbitMQ). We welcome your feedback, questions, and suggestions.

Enjoy!

Last week, I had the pleasure of attending Øredev in Malmö, Sweden. While at the conference, I presented two sessions — including a new talk on Actor Model Programming in C#. This was the first official presentation I’ve given on the subject, having done an ad-hoc version of the session at Pablo’s Fiesta this year (which went fairly well, likely due to the awesome Chicken and Waffles at 24 Diner the night before). Early feedback from the Øredev session was positive, which is encouraging since I will be giving an updated version of the talk at CodeMash 2.0.1.2 in January.

First, I wanted to share a few links to the content discussed in the session, including the GitHub Project, the NuGet package, and the TeamCity build. I will update the post with the video link once the presentation video is available, along with the slide deck.

Second, I plan to post a series of blog posts explaining how actor model programming is a great model for building concurrent applications, despite the difficulties that the actor model has had in becoming more mainstream (some of those difficulties are explaining in this article by Paul Mackay).

In the meantime, I’m going to take a hard look at how different languages have implemented the actor model (many of which have influenced the current syntax used in Stact). I’m also taking a step back and identifying other ways the model can be implemented the minimize many of the difficulties and bring some modern programming style to the model. Concurrency is certainly difficult, but I’m convinced that many aspects can be made more approachable by applying some existing idioms to the problem.

If you do take a look at Stact, please offer any feedback you have via Twitter (I’m @PhatBoyG) or GitHub (using issues, whatever). If the traffic grows, we’ll setup a Google group to keep things manageable.

Until next time…