[self.todo] - Some things that might be worth checking out

• InterLINQ - Linq over the WCF (finally forget about XPO gateway?)
• Umbrella project - helper/utility library for C# 3.0
• NServiceBus - .NET communications framework
• Mass Transit - another service bus implementation for .NET
• Launchy - another launcher for Winfows (seems to be too popular)
• FinalBuilder - another build scripting tool with rich task set (not free, yet got some popularity)

XPO hosted on a web site (remoting with binary encoding + http channel)

Below you will find an extremely simple prototype that uses XPO hosted within web application (http channel) with the binary encoding. You will need to have DevExpress components installed and Visual Studio 2008.

Now, before you continue, here is an important caveat - don't use XPO in any complex project. It will just become bottle-neck there.

In my case complex project means:

• 41 Visual Studio projects (74k LOC and 35k statements)
• 3 integration projects on CC.NET
• 417 revisions over 6 months
• 2Gb+ FileStore in production system
• All the features of the xLim 2 approach (and some more)

Here's the Kiviat metrics graph:

And these are some of the problems with the XPO:

• Linq2XPO implementation is horrible (I'm not even talking about decent documentation)
• Flexibility is extremely low (most of all I miss custom mapping routines and ability to specify custom queries)
• Generated SQL is quite inefficient in complex requests
• Remote communication is too chatty by default

As you can see, these problems of mine mostly come from the Lego scenario.

If I were able to start the project from scratch, then I'd probably (would have to do some prototyping first) use NHibernate. Half a year ago there was no chance of using it, since DX controls would not be able to work with NHibernate in server mode.

Ok, you have been warned. Now you finally can download sample of XPO hosted on a web site (remoting with binary encoding + http channel).

Learning how to implement business workflows with DSL

Ok, writing your own DSL seems to be way too easy (so probably I'm missing a whole bunch of problems here).

Here's the story:

In one project I have to set up a whole bunch of request workflows (workflow depends on the type of request), i.e.: cancel program request, retrieve approval to change conditions, submit question etc. Some steps of this workflow could happen within the Smart Client UI, others - within the Web interface, and some more - executed by the automation engine.

Since I'm tired of handcoding the workflows in .NET C#, I've turned to the SimpleStateMachine demo for the help. The actual SSM project seemed to be too heavy for me (reimplementing lightweight WWF is still too much), so I've just used it as a reference.

Ingredients:

• Boo
• Rhino.DSL
• IDE - VS 2008 Trial (running on Windows Server 2008 64 bit, BTW)

After 4-6 hours of playing with the idea I've got the following messy code to compile at run-time:

When the assembled workflow is executed in design more, then it produces the following output (note how new request id is passed to the second action when the active request is being approved):

There is even more fun:

Resume:

• DSL is definitely something worth looking at if you have a lot of workflows or complex business rules to implement and maintain
• Initial learning barrier is quite low (just use Rhino.DSL and SimpleStateMachine as a reference), but then you'll have to learn the theory behind Boo compiler and Expression (that's what I'll have to study next here).

Shell - the google way

What I like about Google is that they often mix different concepts in an unusual way. The one that makes you wonder about the other options that are yet hidden from your vision.

Page rank search, big table, google analytics, google sites etc. And now there is the unofficial google shell...

CPU cycle inflation

CPU cycles get cheaper and cheaper. Here's a nice example: a linux cluster in a IKEA Helmer cabinet. According to the site it has 24 cores running at 2.4Mhz, 48Gb of RAM and uses just 400W (approx 186 Gflops). The cost is just $3500.

Now, if the tech keeps on rolling this way, how many new devs would really bother about sub-optimal GC or efficient codeflow in their code? Most likely the joke about having "processor core leaks" and "processor core collector" could turn true.

Some notes from out of the trenches

• Long time ago I hated when the project did not compile. Later I've learned to despise broken unit tests. Now I'm feeling myself uncomfortable if there are broken projects flashing at CCTray. What will come next?
*

Long time ago (a couple of months are really a long time in a fast-paced environment) I did write a post on implementing DSL functionality efficiently with .NET. Well, it turns out that I was wrong in a couple of spots:

• DSL could be really efficient and easy to implement (Ayende has pointed out this to me really quick by mentioning Boo)
• When you get really complex workflows (40+ nodes, 90+ interactions) C# "noise" becomes too loud to handle.

So right now I'm at the point where I have to look for the approaches like SimpleStateMachine in order to still be able to manage development project efficiently.

Some notes on XPO and continuous validation testing

I'm really "deep in the trenches" right now due to two concurrent projects running. Nonetheless, here are just some quick notes:

• Avoid using DevExpress XPO for large-scale projects where the future requirements could change. It is extremely easy to get started with that, but in the long term your DAL could become a bottleneck in the process of the project evolution (flexibility is too limited).
• Do not use XPO 2 Linq! It supports only basic queries and has absolutely no documentation/matrix/test suite to validate and tell what's working and what is not. Test suite of NHibernate 2 Linq is something I would expect to find in such a product.
• There is another option for the single gateway interface (as in DevExpress XPO) utilized by xLim projects. That's the WCF 2 Linq project or any other analogue (there surely be more of these as the technology gets adopted).
• Some say that the combination of Final Builder and TeamCity is the most flexible for the integration purposes. Well, this could be true - FB even has tasks to deal with VMs.

Inspired by the abovementioned NHibernate 2 Linq test suite (it utilizes the power of MBUnit) I recently implemented a nice business test suite for the xLim2-2 application. Basically this is the test suite that re-uses connectivity and logic modules implemented with the help of Autofac IoC container (simple config is used to get them setup and running). The initialization happens in the global setup routine (supported by MBUnit). And then the actual tests just resolve some components/services from the main container (every test is running within its own container scope) and run simple assertions around these.

Example of an assert could be - "make sure that there are no critical errors in the system log", "make sure that loose object references in the database point to each other" or "make sure that file store is in consistent state with the DB".

So, provided you have the proper config and the compiled unit test, you just can point it to any production system and check its status in simple manner.

If we take the idea further, then these tests could be uploaded to the CruiseControl.NET to let them run against production on a schedule. And if something breaks - you'll get the notification immediately (CC.NET will handle that).

Additionally it is easy to set up continuous statistics capturing via the same tech. So we get continuous system validation here and continuous system monitoring at the expense of writing just some validation tests and doing one-time setups.