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.

The meat of it is this, which I like because it simultaneously shows you how to set up your environment correctly for the console, and for rake. Not a bad little tutorial for two lines worth of stuff:

rake db:fixtures:load RAILS_ENV=test
script/console test


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.

svn status | grep ?

Enjoy!

In a couple of weeks, the age of fifty will come out to greet me, as the windshield greets the mayfly. The local bimbos being unforthcoming, and Harley Davidsons being too noisy, I am learning a new text editor.

For many years, my editor of choice has been Visual SlickEdit, with Brief emulation turned on. This worked fine for me, especially as long as I was coding web sites for my real estate business and not really feeling myself to be in the Programmer Swing of Things.

Over the years when I was in the Programmer Swing of Things, however, I had previously spent hundreds of dollars on SlickEdit upgrades. I can count no less than seven SlickEdit boxes here in the study, which tells me I’ve been through one Linux version and at least six versions of the Windows product. So naturally lately when I started to really get into Ruby on Rails, I thought I’d check out what kind of upgrade I’d be eligible for, so I could take advantage of the latest language support feature.

It turns out I’m not eligible for an upgrade. The SlickEdit site has a tool where you enter your license number, and the web site says, in effect: S-U-C-K-E-R! You want to develop on Linux and Windows and get the latest features after buying seven licenses already? Sorry, that’ll be six hundred dollars more.

They’re not Microsoft, but they’re in the same religion.

I decided at this point that VIM was really worth taking another look at. I’ve used it sporadically over the years, usually when connecting to an ISP on a shell account and needing to get something done in a hurry. In the last few weeks, I decided to start using it systematically, remembering from my Brief days that after a couple of weeks of pain I’d be liking the world again. Now I’m up to the point where I’m somewhat competent. Some things still go too slowly, but I’ve found that if I open up SlickEdit my fingers are already trying to make GVIM work, not Brief.

On the Ruby front, Tim Pope’s Vim Ruby Plugin is a solidly competent free tool for navigating Rails code and getting pretty much anything else done in Rails without resorting to the terminal (unless you happen to feel like resorting to the terminal, of course).

GVIM works great on Linux, of course, and with a minor wrinkle or two (like using CTRL-Q for “Visual Block” instead of CTRL-V), it works great on Windows, too. If you find it useful you’re asked to help the Ugandan Children, but outside of that it’s free.

So that’s my midlife crisis, in its nerdly nutshell. No harlot, no Harley: just me and my new editor, which I like very much, and a lot of useless SlickEdit boxes.

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.