Web Site Design and Development

Some time ago I waxed ecstatic over JUnit automated unit tests here, and I think the software community has gotten even more wild-eyed over automated tests in the meantime, with the latest buzz about Behavior Driven Development. For my part, lately I’ve begun to question all this conventional wisdom. I’ve begun to believe that the fact that programmers love testing so much for the same reason Twitter is so popular: writing short little works is more fun than reading something long and difficult.

You see, MY test case is elegant and concise, whereas YOUR legacy code is convoluted and difficult.

Don’t get me wrong. My legacy code is convoluted and difficult, too, but it’s a lot more convoluted and difficult for you than it is for me, because I wrote it, and I have a better than even chance of knowing where the tasty bits are and what I was thinking. Your code is sometimes worse than mine, and sometimes better, but either way I don’t know it as well as my code until I start grepping and reading and stepping through it in the debugger. After a while doing that, I become more proficient in your code, but it’s still YOUR code.

During the day I make my living reading and fixing YOUR code. Well not yours exactly, but Other People’s Code. The particular compilation of Other People’s Code that pays my bills lately has been evolving since the 1980s, with very little in the way of automated testing. Yet my employers are selling the product and making enough revenue to hire me and a bunch of other guys to work on it. To be sure, it may be nearing the end of its life cycle, in which case I may need to find OTHER Other People’s code to go work on, but I guarantee you that in the meantime my wife doesn’t mind when she cooks dinner.

When I first got to this job I lamented the fact that there were no native automated unit tests. I wrote a few, but not nearly as many as I’d like, nor nearly as many as we need. QA has also been recently trying to add a lot more automation, though they’re written in the tool we’re developing — not the language I’m working in. More and more I just try to bite the bullet and debug and fix the problems that get logged by ad hoc testing against Other People’s Code, and I try not to let my overwhelming agile genius keep me from having a good time.

As a younger programmer than I am now, at my first true development job, my agile genius was at the height of his awesome career. As I was explaining some ingenious and difficult idea to my manager, he detected my agile genius at work. He rewarded my heroic efforts with the following response, which I offer up to you now as a Development Driven Development manifesto:

He said, “Just write the damned code.”

Just Write The Damned Code

I don’t think many developers are going to go for this as a way of doing business, because just writing the damned code is not really theoretical, and we developers love our theories. This sounds too much like chaos, and too many of us have suffered from chaos as a model of software development.

And do I really mean we should give up all testing, finish our edits and just do an svn commit without further ado? No, of course I mean that we should test our code, step through it in the debugger, examine it, review it, think about it, clean it up and the like. In fact, I submit that the compelling love of automated testing is precisely a reflection of the fact that while I’m an accomplished professional with a serious work ethic who always debugs and tests his code before checking it in, Other People as we all know are the dreaded perpetrators of Other People’s Code.

The sleight of hand here of course is that Other People are also the dreaded perpetrators of Other People’s Automated Tests. In my non-day job, rather than getting paid to work on a codebase that has no unit tests, I’m not paid (yet) to work on a project written in Ruby, where automated testing is “baked-right-in”. Of course, the tests that script/generate will spit out as a by-product of its work all pass, but more importantly, one of the Ruby third party gems I use heavily has sucked up more of its fair share of my time because its tests fail whenever I start running a new version of Ruby or make another change.

Am I just being ornery and jealous of my time that I don’t want to spend the happy part of my coding weekend updating tests that say that a user should end up on page X when they’re finished with some task, after I just explicitly made the change so they’d end up on a page Y? Really, we need tests to tell us what page people are going to now? Did we think they’d suddenly start hopping over to pets.com? And do I care that the string format of a DateTime object changed and now your tests are failing not because the dates are wrong but because of that incidental?

Test Driven Development works like this:

1) Write test case, color should be red.
2) Watch test case fail, color is not red.
3) Write code to make red.
4) Test case passes.

Development Driven Development works like this:

1) Write code to make red.
2) Verify red.

Yes, I’ve had cases where automated tests have alerted me to real bugs, so I don’t want to damn them out of hand. But I think a lot of the religious fervor surrounding unit testing boils down to something like this: “I don’t want to step through your code, and I haven’t yet created anything valuable enough that some other poor sap has to step through mine and I can get paid for it while being cursed as a fool.”

So I’m changing my goal, from writing unit tests for Other People’s Code to just debugging that code as best I can while writing my own code.

I’d rather be a hammer than a nail. As the great software engineer, Louis XIV, said, “Other People, C’est Moi!”

I had to figure out Ruby on Rails enumerations and fixtures today.

The solution will be here in just a moment, but first, some gratuitous background: I was working on a Person resource — or a “Contact” resource if you prefer your people to have a CRM flare to them. Naturally, hanging off of these People (or Contacts) are as many phone numbers as they might have.

Twenty-first century people have a lot of phones.

Once you start having contacts who own lots of phones, naturally you want to know if you’re bugging someone to buy your widgets on their cell phone or their home phone or what have you.

You don’t want to store whole strings to do this, so probably you end up with a line in your schema that looks something like this:

t.integer "phone_type"


Well, that’s fine, but in your code you don’t want to be saying “p.phone_type = 2″, because that’s not all that readable.

Now Ruby doesn’t have enums (BAD language — just for that you’re going straight to bed with no strong typing, young man). It does, however, have constants, and this Rails tip shows you how to use them.

Like me you may have opted for the simple “first approach” of adding the constants to your model, like so.


class Phone < ActiveRecord::Base
# Type constants
HOME = 1
WORK = 2
CELL = 3
# ... more model code ...
end


Well, all that's well and good, but then what do you do about your fixtures? Remember, your whole point in starting on this Enumeration journey was to get your code more readable, not less, so if you end up having fixtures that look like this, that's not a good outcome:

et_the_extra_terestrial:
id: 1
person_id: 1
phone_num: 9165551212
phone_type: 1


Phone_type: 1
At about this point, I remembered that one of my Rails books said something about dynamic fixtures. Looking those up, it was easy enough to get ET's phone looking the way it should in no time.


et_the_extra_terestrial:
id: 1
person_id: 1
phone_num: 9165551212
phone_type: <%= Phone::HOME %>


And there you have it, Bob's you're uncle, and Drew Barrymore's your hot aunt.

I’ve been working on a Rails application, not all the live long day, but generally on a long Friday night and part of Saturday.

Being self-employed during the boom years, now that we’re in a recession I own a real estate company for pin money, and have a full time ecological niche banging on legacy C code in a cube forest.  Following my ancestors, the hunter-gatherers, I am a typer-debugger.

On Friday nights I cut loose from the dusty streets of this one horse Bruce Springsteen song, and do, what exactly?

More typing.

Because I hope to get paid for this Rails application eventually, I have to go at it weekend after weekend.  But because I’m not yet getting paid for it yet, and because even if I ever will I’ll be more or less in charge of its direction, I enjoy it as a creative outlet.

The speed of part time takes some getting used to.   Software is one of those things where you start to really get rolling on whatever language it is you happen to be using this year after several weeks of being back in that environment.  Sure, you can be semi-productive on day one, but by week 12 you’re cruising along nicely.

When we say week twelve, though, that’s for a full time gig.  When you get a day of programming per week, then multiply everything by five, given what would have been your five day work week.  So twelve weeks becomes sixty.

Programming at the speed of part time, a six month project takes two and a half years.

To be sure, you have a bit more than a day per weekend you can conceivably put in, but on the minus side, you’re having to keep it all in memory after flushing C through your brain all week.

Needless to say, the hardest part of such a project is staying encouraged after four months or so, with a mere few weeks of progress seeming to show for one’s efforts.

It’s amazing to see how “the economy” changes things.  It seems like all the coffee shops around here are closed.  During the boom years, when one could make a living by blogging alone, I used to go out with all the other high-on-the-hog heloc bailout recipients and enjoy my French roasts.

Today I went out for my birthday mocha, and my old shop was closed, and the place I would go before I went to my old shop was closed.  To be sure, the coffee shops inside the supermarkets are still doing OK, rescued from collapse by their proximity to the produce.

I wonder if any of the old baristas who lost their jobs are now inside Safeway coffee shops, while working on their own chai latte projects on Friday nights.

I hope not.

Try this:

svn status | grep ?

Enjoy!

In my last post I discussed some of the pros and cons of Ruby on Rails versus .NET. One of my complaints at the time was that Ruby lacks a good graphical unit test runner, because I’m a sucker for a green bar. I also complained that running tests is cumbersome on Windows.

Tonight I decided to see if there was a green bar to be had anywhere in the Ruby world, and the answer is this: well, yes, if you’re running on Linux, and if you’re running Windows, well, sort of. The good news is that Ruby does have a graphical test runner — in my case it lives in ruby\lib\ruby\1.8\test\unit\ui\gtk2. You can learn how to set up Ruby GTK on Windows here. Also even though the source clearly wants gtk2, and the web site warns that that’s not fully supported on Windows, it does appear to be working. I must say the treeview is a lot more primitive than NUnit’s, and you don’t get to see which tests passed — though of course you get the more important information about which ones failed and where. And most of all, you get the green bar. Sweet, beautiful green telling you the world is OK.

And in spite of what the docs say about ActiveSupport::TestCase being derived from Object, it’s not — it’s derived from ::Test::Unit::TestCase as it should be, at least in the code I’m looking at. Like I said before: Ruby documentation makes Jesus cry. And I’m not even religious.

Do you remember blogging?

I think when the history of the current economic depression is written, historians are likely to draw a parallel between the bloggers of 2007 (or thereabouts) and the flappers of the roaring twenties. 

Do you remember blogging?  Do you remember having the money to blog?  That brings me to my next point: what happened to me, and why am I not blogging any more?  The short answer to that is that the money started to go away, so I went and got me a day job.

You know:  a day job, with a boss and a 401K and a W2 at the end of the year.  Yikes!

I’m a fortunate man to not be unemployed right now.  I’m fortunate because I’m self-employed when times are good and — so far at least, knock keyboard — I have a day job when times are bad.  In my day job I’m back to my old day job of programming software using Microsoft’s Visual Studio.  As it happens, the software I’m working on in my day job is a legacy C and C++ Windows codebase.  I maintain the database layer, which at times is a proprietary collection of drivers accessing Oracle, ODBC, etc., and at times is just an OLEDB connection.

On the weekends, when I’m not spending ten minutes with my family, I’m working on creating some vertical applications using more recent Microsoft technologies, ASP.NET 3.5, C Sharp 3.0, and LINQ to SQL.  One might say, to paraphrase Michael Steele, that I’m bringing my core programming values and applying them to “urban-suburban hip-hop settings.”

I have a Republican friend at work.  Some of my best friends are Republicans.  Does saying that make me a racist?

I apologize that I don’t have more code to share here yet.  I’m too busy writing code to have much time to write about writing code, but I do remember blogging.