Code Beast

I recently got a new workstation with lots of memory (3 GB) and a big disk (750 GB), and it has significantly improved my life. Here’s how:

1) Since we’ve got MSDN, I get Virtual PC for free. Not as cool as VMWare, which has neat ways to manage the changes to your VM, but still good enough for me.

2) I did a patched up XP install and save the VM definition + the disk (vhd and vmc files) in VMs/Base XP. I seem to remember having to hack up the .vmc file to have it use a relative path to the disk. The disk is named ‘disk.vhd’ to save me work.

3) Whenever I want to do something possibly invasive, like test a beta of Visual Studio or something else that I would be pretty stupid to do on my main dev box, I simple clone the directory, rename the files, and go from there. The copy takes about 5-10 minutes, depending on what else I’m doing at the time.

4) I’ve also got a ‘Base XP Dev’ image with my development environment all set up that I can use for extended debugging sessions without having to tie up my normal environment. Particularly useful when doing a long-running automated test on an old version, when there are outdated COM APIs (I know, I know).

I don’t think I’m ready to go full-on virtual yet. I tried that once, but the responsiveness of the VM just wasn’t where it needed to be. Immediate feedback is very important to me, since I tend to move pretty fast through systems that I know well. Maybe someday when I get a quad core box and the VM apps can spread across multiple cores, I’ll give it another try.

In summary: virtualization makes me happy.

Technorati Tags: programming, virtualization

Neal Ford wrote some interesting things about naming conventions: Eating Sacred Hamburger. And even though I agree with everything he says, I think he draws the wrong conclusions.

He first argues the relative merits of various naming conventions, preferring ruby_case to CamelCase, especially for very_long_and_drawn_out_method_names. It think he hits it right on the button, though I personally prefer lisp-case for very-long-and-drawn-out-method-names, since it’s easier to type.

He also argues against Hungarian notation, which I agree is a blight upon all that is good and green. And the IInterface notation is also a little silly, but…

It’s convention. We should follow the convention.

Did I just say that? Giving up progress, and readable code, just to do it in the same way it’s always been done?

Well, yes. Remember in C++, when you were using STL sometimes and MFC sometimes? They used different naming conventions entirely. And you could never remember what goes with what. Intellisense helps with that some, but it’s still awkward. And what about reading the code? While it may be a little clumsy to read long names in camel case, it’s far better to have the formatting match. The overall codebase is more beautiful as a result.

So, I say: bring on the IInterfaces! At the end of the day, I don’t care how we name things as long as we name them the same way. Or, to quote my boss: “standard is better than better.”

(Maybe they got rid of Hungarian notation not because it sucks (which it does), but because they couldn’t get everybody to agree on it. A convention is only useful if everybody does it. And right now, in C# at least, everybody does do it. It’s great for an old C++ hacker like me. So please, don’t break it!)

Technorati Tags: c#, naming, programming

I’m no Windows dev expert, but I’ve been doing it long enough to have collected a set of tools that go with me. They sit in a nice little rectangle on my desktop, and I also have a USB key to carry them with. Not all people know about them though, or maybe have seen them and haven’t learned to use them. I recommend at least familiarity with the following:

1. OleView I do a lot of COM work. I try to make it go away, but it keeps coming back. As such, my first choice of debugging tool is good old oleview. Every time our install breaks because of some munged dependency, the first step is to fire up oleview and check that all needed objects are registered, and that they can all be instantiated. That last bit is non-obvious but very cool - when you expand an object in the list and it turns bold, the object is actually being instantiated. So just expanding each one you care about is a good smoke test.
2. Filemon Everybody probably knows this one already, but it’s so important that I can’t leave it out. If you haven’t used it, do yourself a favor and get familiar. It can be used for any program running on windows, so it’s good even for you Java folks. My strategy with Filemon is usually to first figure out a concise way to reproduce the problem, then do a specific session to see what’s happening. I usually forego the filters (remember the COM I’m running from? Lots of out-of-process servers there.) and just start/stop event logging at the right times.
3. .NET Reflector Ah, what would we do without Lutz Roeder? I’ve used this to read my own (decompiled) code while working through a bug on a test machine. Saved me some walking back and forth at least, plus I felt like such an incredible badass doing it. It’s also good for determining that the localizer sent you back an assembly built with .NET 2.0, when you very clearly asked for 1.1. (A co-worker’s find, not my own)
4. Spy++ Are you noticing a theme here? All the old tools that let us observe the bowels of the system are still useful. Sometimes you just want to watch the messages fly by, and Spy++ is still the way to do it. ManagedSpy may be worth a look too.

As mentioned above, what I find compelling and useful about these tools is that they take a step away from what your software is supposed to do (that’s what the source is for) and let you know what it’s actually doing. There’s an entire class of subtle bugs that such insight enables you to diagnose - the first two tools have saved my ass on multiple occasions.

Technorati Tags: c#, debugging, programming, windows

I called it MagicCache at first, thinking I’d come up with something new and cool! But, as usual, I’d actually just forgotten the name.

Memoization is a useful but intrusive technique. It’s the kind of thing that I want to be able to wield around my code and put it where I need it, almost as a configuration-time parameter. So I’m not quite satisfied with just writing the code myself each time I need it. This is a perfect case for AOP.

The approach I took was not to use an existing AOP framework, since I think that would freak my coworkers out a little, but rather to do my own simple system. It uses the fantastic DynamicProxy (as do all C# AOP systems I know of) to inject code, and I use a custom attribute to mark the invocations I care about. The result is quite pleasant to work with:

[Memoize]
virtual int Sum(int a, int b)
{
    return a+b;
}

Or, in more complicated cases:

[Memoize(MaxCount=100)]
virtual object BuildObject(string paramA, int paramB)
{
    …
}

I like this particular method because the caching policy is nicely separated from the actual logic, but has enough proximity to see what’s going on. And I don’t have to write the caching code again and again, which means I’m free to enhance the general caching algorithm.

Of course it’s not quite as easy as all that. Memoized methods must be virtual, for DynamicProxy to be able to intercept the invocation, and the object in question must be wrapped in a proxy object. In my case I wrapped it all up in a single method call, Memoizer.CreateProxy(obj). For objects that are already built in a factory this is not problem at all, but sometimes it’s kind of inconvenient.

I’ve also added the ability to treat returned strings as paths to files which are deleted when they are removed from the cache, though I haven’t thought through it well enough to be generally useful.

Technorati Tags: aop, c#, memoization

I would like to take a moment to espouse the wonders of mbUnit. It is to NUnit as C++ is to C, as Perl is to Bourne shell, as Milk Duds are to milk. That is, the former supports the same basic principles as the latter, but gives you more rope with which to hang yourself. And really, who can resist that?

It supports the same "idiomatic" syntax as NUnit, which is a good start, since that's really the only way to do unit tests in C#. And you can do the usual TestFixture/Test stuff, which works, but is kind of clunky and unwieldy.

But the mbUnit folks have taken it a step further. The old way always involved writing cumbersome loops over sets of input and trying a particular call/assertion for each of them. Boring, repetitive, not ultimately traceable. But by allowing tests to have parameters and creating a configurable binding phase, all that goes away. It works like this:


[RowTest]
[Row(1,2)]
[Row(3,4)]
void TestSomething(int a, int b) { …


That's just the binding, straight up, as a set of rows. Simple but useful, and far cleaner than the alternative. In the testrunner, you'll see that as two tests. This really is the right way to do it, I think, since you can easily trace failed tests to a particular set of inputs. But it really gets cool with CombinatorialTest. I find myself most often using the trivial case:


[Factory(typeof(string)]
public IEnumerable InputFiles()
{
return System.IO.Directory.GetFiles("inputDir");
}

[CombinatorialTest]
public MyTest( [UsingFactories("InputFiles")] string filename )
{ … }
Now that's downright great. And there are all kinds of other useful generators, like UsingValues and UsingLinear. With multiple parameters, Combinatorial test evidently combines them in some significant way, but I honestly don't understand the whole thing. I'm just willing to let it work.

My only complaint? I haven't yet found a good project template for visual studio. I'm sure I could make one, but my laziness is still fighting itself on that one. I know, it's supposed to be easier in VS2005, but my wounds have yet to heal from the last attempt.