RDF, printf() Debugging, Testing

When the large distributed system going gets tough, the tough add printf calls. And when the tough can no longer keep track of all the printf calls, the tough start calling the printfs a "Trace System" and add it to the development schedule. We're using log4net instead of printf, but the principle is the same.

Large program traces can get tough to read, so you generally end up writing little tools to help process them. It's enough of a problem that the supercomputing people (big fans of parallel programming) have come up with trace-file format standards and a slew of utilities for dealing with them.

Sadly, what I needed (dumping application state as well as program trace info) didn't fit well into the existing standards, so I was stumbling along with ad-hoc log messages that I post-processed with awk. I was in the middle of writing a tiny app to graph the post-processed output and show object linkages when I realized I was being silly. There was already a perfect data format with tons of associated filtering tools and visualizers: RDF.

Although I sometimes rant against the more extreme goals of the Semantic Web effort, I find some of the underlying technology useful. RDF can be a pretty nifty tool if you don't let it go to your head.

It worked great. Using RDF doesn't allow anything I couldn't have in theory done before, but it means I can take advantage of tons of existing tools and expertise. (You can buy a book on RDF, but you're never going to buy a book on whatever internal debug format you come up with.) I've been processing the RDF with cwm and viewing it with IsaViz and Welkin, and there are many other tools I haven't had a chance to try yet.

I'm certainly not the first person to think of this (it looks like the W3C uses RDF as the format for test results for conformance suites), but I haven't seen a lot of buzz about it. I think that's a shame.

I've imposed a one-week moratorium on any further RDF research (it was getting a little out of hand), but I think when the time's up I'm going to investigatge using N3 rules to validate test output (dump state, do an operation, re-dump state, compare states with reasoning engine, etc).

Has anybody out there heard of any existing efforts along these lines? Google turns up tons of references, but none seemed to match exactly...

tags: printf, debugging, trace, parallel, distributed, software, development, rdf, semantic, web, september, 2005, n3

The '#region' Directive in C# : Chocolate Covered Rat Turds Not Actually a Good Idea

Those of us who suffered through C and C++ preprocessor nightmares were happy to leave them behind when programming in Java. I was less than thrilled to get them back again in C#, but I try to keep an open mind.

One of the more interesting directives introduced with C# is '#region'. It's meant to make overlong source files filled with ugly methods look prettier to the casual browser. It comes in especially handy when hiding the large chunks of autogenerated code ('turds') produced when working with forms in Visual Studio.

Browsing through code with #region is a little like biting into chocolates from the "Whizzo Quality Assortment"[1]. No matter how pretty it looks, it's still a thin chocolate coating around crunchy raw unboned real dead frog bits.

If you sweep rotting pieces of implementation under the rug, then nobody is going to be cleaning them up, are they? If you make a 5000 line long source file look like it's 300 lines long by compressing up the view in outline mode, it's not actually 300 lines long, is it? If you shove your ugly method implementation under the couch cushions, then it doesn't magically become a good implementation, it's just a sticky surprise for the next person to reach under there looking for loose change.

To put it another way, imagine this: a novel that comes with #region directives so that you can avoid reading the badly written parts. Is that the sort of book you want to write?

Like preprocessor directives in C, there are legitimate uses for #region. Despite the title of this post, I was serious about covering up Visual Studio turds. It's not like you can do anything about them, and they're not meant to be hand-edited, so there's no deep harm in covering them up. And sometimes a badly written framework can force you to have dozens of boilerplate methods that nobody really needs to look at. But, overall, #region is a tool for people who'd rather hide their mistakes than clean them up. It should be avoided.

[1] "Ah - now, that's our speciality - covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks." - Monty Python "Crunchy Frog" sketch. After a couple of "Spring Surprises", people lean to avoid popping unfamiliar code into their mouth.

tags:blog, september, 2005, code, software, aesthetics, style, csharp, visualstudio, preprocessor, region