The Resource Validator

A week ago I gave a talk at the IDCC about how to create a testing Eco-System for your project. It was a great fun, and I got a little carried away with the random tests, and had to neglect talking about the concept of a Resource Validator in your application, as an important past of a standard deployment test. (I’ll probably blog about the other topics sometime soon. Stay tuned.)

The talk (Hebrew) is available online, btw, courtesy of Sela.

So in the context of my talk, when we run a deployment test* – we want to know quickly, and with as little “custom” assertions that the application is properly installed and can do its job. The best way to do this is to make sure that the application can “Start” or “Load” only if “it is properly installed”.

We’re saying that the application should test itself.

We’re saying the application should make sure it is ABLE to do any operation it might be REQUIRED to do in the future.

We’re saying the application should crash early, even if it could have gone on for hours, maybe weeks, without failing.

Why?

Ever hear of Fail Fast?

The same reasoning which stands behind the notorious BSOD stands here – if you don’t know how your application will behave in the future due to an error caused in the present – crash in the present. It will make problem solving easier.

I cannot even count how many times I’ve had an application “miss-installed” by QA, and followed by them opening a flurry of “wrong” bugs. You know what saved the day (other then a smarter installer)? The fact that whenever an application got “miss-installed” – it wouldn’t start.

The responsibility of the Resource Validator is exactly that – when the app loads – try to perform all the possibly risky operations once, to make sure they work. Wait for the exception from those calls to tell you something is wrong. Operations like:

• Do you have any file dependencies (XML, config, data dictionaries, resource files) – call the methods which require the data from those files ("string GetTranslationFor(string)”). That covered the file’s existence, the fact that it’s in the “right place”, the fact you have the proper ACEs on it, and that you have CAS permissions to access it.
• Do you use a COM component? Invoke a simple method on it. That covered the fact that the file is there, that it was properly registered, and that it can properly load (including dependencies).
• Do you have a logger? Write a log message. That made sure the logger component exists, and that you have permissions to do whatever the appender wanted to do.
• Do you have a DB? Run a silly query on it. That covered connection string, database (server and instance) security, intermediary firewalls, etc. (For extra credit – add a stored function on the DB which returns the “DB Schema Version”, and add some custom logic to see if the app version is compatible with the DB version).
• Writing to custom performance counters? Write to each of them once to make sure they’re there. (same with WMI)
• Using some queuing mechanism? Enqueue a “test” message (if you don’t have an avid receiver – try to dequeue the message).
• Etc… **

So now we have some component which verifies that our app can do all those actions by simply doing those actions. This is GREAT for seldom-loading-long-running-services, but not so great for user-interactive-applications which need fast startup times.***

I’ve mentioned before that you should perform those actions and just wait for an exception to tell you something went wrong. The “exception” part is important here – simply don’t catch it. Let the exception bubble all the way and crash the app. If you’re running the Resource Validator during a Windows Service’s “Starting” stage – any exception will cause the service to move to the “stopped” state, and the exception details will be written to the Windows EventLog. Convenient. (user applications should catch the exception, write it to some log, and rethrow it).

So now you have a ResVal. What do you need to do in order to perform a detailed deployment test? Just run the app (start the service) and check that it stays up. EASY.

---

* Making sure a complete application deployment package (MSI or otherwise) is actually installable, and working properly

** Recent studies have shown that “Etc…” is the number one application deployment problem.

*** A college of mine suggested the concept of “A-sync Resource Validator”. Sounds interesting, didn’t have the need to implement such a thing yet, so I don’t know what possible pitfalls are there.

IDCC Sessions – why YOU will be Interested in Attending

Sessions were selected, registration is open! Hurrah!

http://www.idcc.co.il/sessions

http://www.idcc.co.il/register

For you lazy non-clickers – the concept is that there are five “concrete” sessions and ten “abstract” stand-by sessions in a “queue”, which will be “implemented” if there will be enough “delegates”. Attendants. Registrations. Gaah.

They weren’t kidding about that “by developers for developers”.

Just look at some of the amazing talks from the stand-by list (with a short comment from me about the lectures):

Alon Fliess’s talk Dive into the Internals of Windows.

I’ve had the pleasure of attending Sasha Goldshtein’s Windows Internals 5-day course at Sela, and it was a humbling eye-opening experience. There was so much information there I could not have possibly hoped to remember it all. A refresh could be me just fine. If you haven’t enjoyed such a deep review of Windows Internals – you at least owe yourself this brief review.

Ariel Ben Horesh’s talk Patterns of a successful application.

Ariel is going to talk about four patterns (or products) for client side applications (IoC, MVVM, MEF and Prism) which could benefit everyone who isn’t familiar with them. Personally I want to be there for the MVVM part and shout out that the ViewModel should NOT know anything about the View. My personal sort of crazy.

Dror Helper’s talk .NET developer introduction to IronPython.

I’m not a big “Dynamic languages" guy, but I agree that there’s room for it. I’m generous that way. I would have liked C#4.0 to be less dynamic and more contractual (less python, more Spec#). Maybe Dror would convince me.

Noam King’s talk Do it right - Building a Complete Site with ASP.NET MVC FW.

Again, not a big “web” guy, but I have had the chance to hear a great overview about Monorail from Ken, so it’s only fair to hear the ASP.NET MVC side too. :)

Oren Ellenbogen’s talk Rewrite your brain, rewrite your code; concurrent programming with MS CCR.

If you’ve ever wrote “new Thread(action).Start();” you NEED to hear this talk. Oren talked about this in the first Israeli Alt.Net open conference and it was a smashing hit. Many brains were re-written. GO SEE THIS TALK.

Roy Osherove’s talk Beautiful teams and code leaders.

I have no ides what Roy is going to talk about, and that’s exactly why I’ll attend. It defiantly sounds promising.

Vlad Azarkhin’s talk Introduction to jQuery development.

From the abstract: “This session is about improving your quality of life“. I can’t say no to that.

Regions, Regioning, Regonism

Liran wrote a post (Hebrew) about the use of regions and how he hates it. Or them. I’m not sure.

I basically agree.

But the use of regions in code could be done for two purposes – regioning and hiding.

Actually – three: regioning, hiding and tradition.

The act of separating chunks of code to different regions in a class is probably the foulest code smell that the SRP was broken. If you have two distinct functionality sets in a class that need differentiation – differentiate using the curly braces, and create a new class.

Yes, partial classes are considered cheating.

And as always – there’s an exception to that “rule” – the initialization parts of a class. While it IS possible to separate the initialization from the “regular operation” of a class – it seems unintuitive to me and I usually do wrap the initialization part with a region.

But I mainly use regions in another manor – I use them to hide code. And that abstract term “to hide code” has only been converted into one valid scenario for me: I wrap logging code with regions.

This is a classic pattern for me:

#region Log

_Logger.WriteLogEntry(string.Format("Doing things on the {0} entity", entity.Name));

#endregion

I even have a template for creating those chunks, and a template for wrapping logging chunks.

I can’t seem to find any other piece of code that I would not have wanted to see if it’s there. Feel free to offer such “Ignore” patterns in the comments.

Now, the last reason for using regions is tradition. I can certainly argue, but I have found it futile. I’ll just say it once: No one cares about the fact that all of your “Protected Methods” are in this block. Same goes for any other structural division. Stop wasting time.

(But if you’re still convinced that it isn’t pointless – at least do yourself a favor, and really stop wasting time on it – use Regionerate.)