config.gem 'rspec'

I finally got rspec to install using config.gem (in Rails) with these lines:

  config.gem 'rspec',       :lib => 'spec'
  config.gem 'rspec-rails', :lib => false # Note this hack keeps it from failing on this gem.

...That allowed me to install/unpack them.  Which is all well and good.  But when I ran my specs, it failed, complaining about an "undefined method `evaluate_value_proc' for class `Spec::Matchers::Change'". Looking around, the claim was that this error was caused by "incompatible versions of rspec and rspec-rails". But that didn't jive with the versions I had installed.

So I commented out my two lines, above.  ...At least I had them in vendor/gems, (and my "script/generate rspec" bootstrap command ran fine, earlier).

With the gems commented out, everything worked.

[shrug]  Go figure.

Updating to RubyGems 1.3.1 on OS X

As much as I enjoy ruby and rails, I don't keep up with the community much.

This has its price... sometimes I'm blindsided by things that I imagine are "common knowledge" on the mailing-lists, but aren't documented anywhere that we lesser mortals actually notice.

The problem I had this morning was mentioned, in obfuscated form, on one blog, at least.  I thought I would state it more explicitly:

I updated to Rails 2.2.2, but it complained that I needed to update to RubyGems 1.3.1.  When I tried (sudo gem update --system), I got this message:

Updating RubyGems
Nothing to update

...It turns out you need to use the "alternate install" for RubyGems.  ...despite the fact that the documentation says explicitly that you won't need to if you have a more recent version.  Do this:

> sudo gem install rubygems-update
> sudo update_rubygems

...Now you're running 1.3.1, and Rails will be supplicated.

Bugs Me:

script/console test
mongrel -e test
rake db:migrate RAILS_ENV=test

Why?

Consistency is a good thing.

IE6

I generally don't pay attention to server stats, but recently I was getitng frustrated with IE6, so I asked those in the know how prevalent IE6 was.  The reply:

"...as a total, IE 6 is about 22% of all users"

My response: holy shit. That's obscene! IE6 is broken, and to think that over 1 in 5 people are still using that crap-tastic browser is an offense to the internet.  Sure, sure, I can understand needing to keep IE6 on some fragile server somewhere that, if you update it, your entire site breaks.  Fine.  But stop browsing with the damn machine!  There's no good reason to keep using IE6.

One in five!!!

People: switch!

Composite Primary Keys (everyone's got an opinion)

Tonight I was playing around with some of the "cooler" things that Rails can do, and I thought I would try them out on our code.

Namely, there are two features that I'd like to use: nested_has_many_through, and named_scope.

This would allow us to write code like "taxon_concept.data_objects.images.visible" without having to go through a hairy find_by_sql, and it would allow us to more easily make changes to the DB (like, say, how we define "visible" for data_objects).  It would have made one of today's changes painless, too (long story).

It would also reduce the amount of code we have by a significant amount.  ...I like less code.

...The problem, though, is that DHH doesn't understand composite primary keys (CPKs) *at all*, and his framework reflects that.  Even with the CPK plugin, things don't work right.  ...That is, when you declare a CPK on a model, it seems that it expects every reference to it to contain all of the PKs.  I tried doing something like (pseudo-code): "DataObject.has_many :data_objects_taxa, :foreign_key => :data_object_id ; DataObjectsTaxon.has_many :data_objects, :foreign_key => :id" (DataObjectsTaxon has a CPK)... but this doesn't work: it STILL tries to pass in two key values.  The resulting queries are actually rather asinine (notice the 1,4 at the end), and fails miserably:

    SELECT * FROM `data_objects` WHERE (data_objects.id = 1,4)

...I could delve into the CPK plugin code and try to resolve this, but I might be gone for days.  ; )

You can kind of get around this by using a habtm relationship.  ...But that only works for that one hop.  So I can get data_object.taxa, but I can't get data_object.resources, using this code:

    has_and_belongs_to_many :taxa
    has_many :resources, :through => :taxa

This throws "Unknown column 'taxa.data_object_id'"... and the docs even warn about this ("You can only use a :through query through a belongs_to or has_many association on the join model").

So.

What I would like to do--knowing full well that this is the wrong thing to do, but bending to the will of Rails--is change our CPKs to Unique Indexes, and add autoincrements to those tables.  I could write the migrations to do such things without too much trouble, but I worry about the affect it would have on the related PHP code (I hope none, since the autoinc should just merrily do its thang).

Again: from a database level of understanding, this irks me.  Where we use CPKs is where they are uniquely identifying entries, and that's how its sputta be.  ...but Rails thinks otherwise.

...Unless someone knows a way to keep things as-is and get the has_many relationships working in both directions.  There my be some trick to it that I'm unaware of. That would be cool, too.

If we could get this to work, I think our code would be much, *much* more elegant (and thus, maintainable/extensible).  I'd be happy, assuming there isn't a noticeable performance hit (but from what people are saying, it's actually quite efficient).

Thoughts?


And: ...apologies to California Pizza Kitchen (CPK).

Murphy's Law of Variable Names

There are at least six appropriate names for any given variable, method, column, or table.

You will not choose one of them.

You might be a geek if

..."too much rails" sounds grammatical to you.