I’ve been wanting to post a list of software engineering books I like, but, while I still may do so, some Jurgen Appelo fellow just posted a pretty good list to start off with, so huzzah for you.

I am not always as pragmatic as I should be. This is mainly due to the fact that I’m a moron.

I was reading this post by Scott Hanselman (his voice is so soothing… almost dreamy…) and I realized that I am not terribly good at being pragmatic. I fall into a pretty big trap I think a lot of us nerdy folk fall into: trying to do things right the first time.

Mr. Hanselman was discussing how his past experienced with Win16/Win32/WinForms/Etc. (Thunking? WTF is thunking? I’m pretty sure I don’t want to know.) clouded his conceptions of how to develop a WPF application. He is well versed in the best practices of those older technologies, but WPF is a pretty new animal, and a lot of those assumptions will not carry over. We have to be willing to accept that fact, otherwise we become an obstacle to our own growth (I love Raganwald).

Hanselman started the WPF project with two goals: get it working, and make it clean. He had a revelation, and reading about his revelation caused a revelation by proxy in myself. Getting it working is the more important goal. Making it clean is the secondary goal.

When you have experience with a technology or technique, I believe these goals can be accomplished simultaneously and with no extra cost; however, when learning a new technology, it is hard to make it clean without knowing the best practices for that given technology. Best practices are hard to learn except through experience. You can read blogs all day and talk to people and debate the pro’s and con’s of different approaches, but really until you get in there and actually taste the code, you won’t be qualified to make a judgement one way or the other for your particular application.

That’s the trap I fall into. When starting a new bit o’ code, I read about how it should be done and spend an inordinate amount of time trying to do it right, when really I should just get it working.

Before you jump down my throat with, "Omgponies! The design! The design!", let me clarify a bit. Making it clean is still a goal. After you get it working, you have to revisit it and make it clean.

Maybe you were lucky and did it right the first time. However, for those of us on Earth, we more than likely noticed friction points while writing our code: places where the code resisted our will. We must subjugate these code modules so that they do our bidding without giving us any lip. We must teach them a lesson through the art of Refactoring as handed down from up on high by Martin Fowler (PBH).

So my new mantra: "I can’t do it right the first time, but it’s ok, because I can fix it later."

Oh and caveat emptor: if you don’t have ReSharper, you can’t reasonably fix it later.

Ok so maybe it’s not a dark art: I just don’t have the book yet. It could be argued the book doesn’t exist yet, but now we’re getting sidetracked.

I was trying to write a DetachedCriteria for a type hierarchy and was stumbling hard. I have 3 classes NationalX, StateX, and OrganizationX that derive from a base type X. X is QualificationType, but I don’t really feel like typing that 50 million times (Does Live Writer needs intellisense?  :) )

I need to pull all X’s with State = state (type: StateX), Organization = organization (type: OrganizationX), and all records of type NationalX.

I got this far and hit a wall. This pulls out all the StateX’s and OrganizationX’s I’m interested in:

DetachedCriteria criteria = DetachedCriteria
     .For(typeof(QualificationType))
     .Add(Expression.Or(
              Expression.Eq("State", state),
              Expression.Eq("Organization", org)
              ));

Great!  I love NHibernate.  But how do I get those damn NationalX’s? There is no unique property in NationalX that is common across all the records I want aside from their type. I did not want to add a type property to my base, that seemed messy and a horrible idea.

Chris Bilson, god love him, saved my bacon. Every NHibernate entity has a Property you can query against, "class", that does pretty much exactly what you think it would.  I still can’t find any docs as to what this magical thing is really called. It’s probably in that damned book I don’t have. This is what I ended up with.

DetachedCriteria criteria = DetachedCriteria
    .For(typeof (QualificationType))
    .Add(Expression.Or(
             Expression.Or(
                 Expression.Eq("State", state),
                 Expression.Eq("class", typeof (NationalQualificationType))),
             Expression.Eq("Organization", org))
    );

This works, And how! I begin the descent into learning NHibernate.  Heaven help me.

PS- Expression.Or() should accept a paramarray.  That’d be hot.

I just spent 40 minutes banging my head against a pointy sharp wall. I’m using NVelocity as my view engine on a Monorail project and couldn’t figure out how to access an element of a collection.

$collection[0]          // Doesn't work
$collection(0)          // Nuh-uh
$collection.[0]         // Nope
$collection.get(0)      // As per Velocity Docs.  Nope
$collection.get_Item(0) // THIS WORKS!

Ok, so that’s incredibly not obvious. I couldn’t find any reference to it on the Castle Project Website, the Velocity docs the Castle site refers you to, or pretty much anywhere.  I did find it in the google group though, but only after a lot lot lot of searching. So hopefully this will save someone out there a few minutes of their life.

Or maybe I should just switch to Brail.