Living in the Tech Avalanche Generation

Well it hasn’t taken long to get some excellent bang for buck from IronPython. The entire team with whom I currently work are all furiously learning Python courtesy of an almost Googlesque free learning time and I have already documented my learning path with respect to Python here before.

As I said at the top of this post, we are already reaping some benefit and there is certainly not an Python guru amongst us (yet). Most recently we were asked for a fairly trivial application (as far as complexity goes) but one that was very valuable to the business nonetheless. Without going into the gory details, what was requested was a desktop application that digitally processed documents (imaging) and produced the output fast, and I mean really fast. The last part of the request was for a design that would allow the document list to be compiled from almost any source, database, xml, Microsoft Office files, txt, etc etc. Let’s deal with each of these concerns in order of their being mentioned.

Steroidal Processing Speed

This part was really not that hard to design and the choice was a simple one, in one word, NServiceBus. What was needed essentially was many workers all doing the same work on a given set of files and this of course mapped brilliantly to one way messaging using NServiceBus and it’s distributor to manage balancing the load amongst the workers. By spreading out the work across any number of worker nodes, our project managers could scale up and down according to their needs to adhere to a given SLA. If you want to read more about the Distributor in NServiceBus please check out Ayende’s review.

Convention to the Rescue

As I said earlier, we were asked to provide a method of very quickly adding or “plugging in” new ways to access data that would produce the list of files for processing  and furthermore this needed to work without needing to recompile any part of the application. Given these conditions and the convention that our messages were always derived from data that included a list of files to be processed, it was pretty clear that IronPython was a perfect fit.

The UI itself was built using C# with the exception that the list box contents would be populated by an IronPython script and the same script would call-back into the C# code with the list of results (file paths). Having IronPython scripts call-back into managed code is trivial, you just need to pass a function from the executing managed assembly and have that function stored as a variable on the executing Script Scope. Then you just call the function. For example:

public void callback()
{
    Debug.WriteLine(“Test Callback method got called”);
}

public string funcback(string calledwith)
{
    Console.WriteLine(“Test Callback function got called with “ +
        calledwith);
    return calledwith;
}

private void SetDefaultScopeVariables(ScriptScope scope)
{
    scope.SetVariable(“test_callback_method”,
        new Action(callback));
    scope.SetVariable(“test_callback_function”,
        new Func<string, string>(funcback));
}

What the sketch of the UI (above) points out (see the red arrow), is that by dropping scripts into the application we were able to load up any number of ways in reading data to produce the list of files that would be used in creating our messages (sent via the distributor). So by simply dropping in a new IronPython script, another item would be loaded into the list box, offering a new method of accessing data requiring processing. Every scripted plug-in would provide an input, a description and it’s own particular method of accessing data (which could be anything).

On a side note, the UI sketch was produced using SketchFlow in Expression Blend 3 which looks quite promising.