Web Site Design and Development

Even though I’m nowhere near finished with my study for 70-536, I’ve begun to start thinking about and working toward my next study goal, 70-562, Microsoft .NET Framework 3.5, ASP.NET Application Development.  The Self-Paced training kit came from Amazon last night, and I’ll have the subject outline up here soon and start filling it in as I’m already doing for 70-536.  As I’m writing this, SQL Server 2008 Management Studio Express is installing away in the background, because as I discovered this evening, trying to get any kind of serious database scripting done inside of Visual Studio alone is like trying to program C Sharp in isql. 

Oh alright, it’s not that bad, but if you can’t be inaccurate using a metaphor, then what good are metaphors, anyway?

The next phase of our little certification pony show is likely to be a good deal more labor intensive than the first phase.  The nice thing about studying for 70-536 is that it lends itself readily to sort of brain dead little “Hello World” example that I used to write twenty years ago when I was first learning to code in C.  This is good for blogging in the evening after a somewhat tiring day in the procedural salt mines.  The study for 70-562, in contrast, is likely to require bigger bits of code, especially if I want to get to something I can not only learn from in a quick and dirty way, but also publish.

I have a few ideas for how that will go, and now I have a new domain to host it on, but there’s nothing there yet. 

I’m not all that discontent – just weary, and I thought it was a cool title, what with old Sigmund having anticipated it and all.

I’m told that somewhere around the dawn of software development, when processor time was hugely expensive and multiple university departments shared a single computing resource, it was common to have to work out your software problems using a sharpened pencil or similar Flintstones-level tool before your code ever felt the warm embrace of powered silicon. 

I wouldn’t know about that.  I’m old, but I’m not THAT old.

These days, doing such a thing would be pretty much unthinkable, which is why it’s nice to be able to report that having sacrificed the Windows partition of my desktop machine to the dubious goal of getting faster Ruby on Rails unit tests working, I’m not content to envision my Microsoft Certification on Ubuntu, but have treated myself to a new Dell laptop.  It’s a Studio 17”, model s1737-020B, and it’s quite the spiffy little workhorse so far.  It’s fairly light for the size and price, has plenty of USB holes so the USB can get in, but also sports an HDMI hole so the digital video can go somewhere – though I must say that even though setting up an extended desktop was the first thing I did, so far I’ve spent most of my time looking at the built-in display for most tasks.  It found my wireless network with no fuss at all.

Battery life is supposed to be quite good though I’ve yet to test that.  4 gig of RAM, half a terabyte hard drive, $749 at Best Buy.  The front side bus speed is 800 MHz, the two processors runs at 2.1 GHz, so those numbers are a tad lower than some of seen out there, but I don’t think I’ll be doing huge builds just yet so that’s probably all I need, and all things considered I’m very happy with it.  Hat tip to the Best Buy folks in Folsom, a very congenial and generally fairly knowledgeable bunch.

About every six months or so, I completely change platforms and direction in my software career. That may be because I’m a head case, but if you read “How the Mind Works”, you’ll stumble upon the more charitable explanation that as the last born in my family my personality developed with a view to embracing change.

Charity begins at home.

I probably need to get certified, on some level. I don’t mean I need it or I won’t have a job, per se, although it’s the kind of thing that may open up opportunities around here. As you might expect, the Sacramento programmer market has a lot of government work going on, and government hiring tends to be driven by the check box. And of course, being the kind of late born head case that I am, I need to have more opportunities than if I were a conservative first born drudge.

I usually start thinking about certification in response to reaching a trough in fretting about my status. (The wave itself runs perpetually.) I have this relentless need to make some pathetic mark on the world, as if that could be done with a keyboard and a Microsoft Certification. Perhaps fortunately, I’m generally able to suppress my ambition in order to grab whatever tarnished brass ring of a maintenance job happens to fly by my little software hobby horse of life. It’s a late born head case thing: we know how to make do with hand-me-downs, all the while secretly plotting to someday have our own pair of jeans for once. As with pants, so with code.

Well, that was maudlin. Both my older siblings were sisters, so the truth is I got my own clothes. My parents were wonderful people, and like most folks they weren’t about to go raising any de facto transvestites.

Hey look, if you’re a transvestite, nothing personal, OK? Jeesh.

Anyway, if I make good on my threat, then I’ll have something to write about. No longer will I be working on a double secret probation Rails project where I can’t share my code. Instead, I’ll be working on code so trivial in all but a pedagogical sense that only a Cheney-level paranoid would keep it in a man-sized office safe.

Meet the new blog. Same as the old blog.

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.