Megablaix The blog

When I first tried to use foxy fixtures in rails, it didn't work. The ids it was assigning for foreign keys were way off. The problem seemed to be the fact that I was specifying the primary keys explicitly. I removed the id: attribute on all my fixtures and everything worked.

So this...

# in authors.yml
justin:
  id: 1
  name: Justin

# in articles.yml
how_to_fry_turkeys:
  id: 1
  author_id: 1
  title: How to Fry Turkeys

Didn't work when I changed it to this:

# in authors.yml
justin:
  id: 1
  name: Justin

# in articles.yml
how_to_fry_turkeys:
  id: 1
  author: justin
  title: How to Fry Turkeys

But did when I changed it to this:

# in authors.yml
justin:
  name: Justin

# in articles.yml
how_to_fry_turkeys:
  author: justin
  title: How to Fry Turkeys

After a fresh install of Leopard (good stuff), I installed ruby, installed rails, and fired up script/server on one of my sites, fully expecting it to barf out some gem I was missing. Instead, I got this error:

$ script/server
...
/opt/local/lib/ruby/vendor_ruby/1.8/rubygems.rb:246:in `activate': can't activate rails (= 2.0.2), already activated rails-1.2.6] (Gem::Exception)

Turns out there's a bug in rails 2.0.x causing MissingSourceFile exceptions to not bubble up to script/server. Being the lazy (busy?) man that I am, I found a solution that gets around the issue, rather than digging in, finding the problem, and creating and submitting a patch: Simply run mongrel_rails start instead of script/server. That seems to handle MissingSourceFile errors just fine:

$ mongrel_rails start
...
/opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- ferret (MissingSourceFile)

Bingo! That's what I was looking for!

On a side note, rest assured the fact that I'm still torturing myself with ferret causes me great shame and embarrassment.

I was getting this error on some pre-2.0 rails sites when trying to run rake after upgrading it to 0.8.1:

rake aborted!
undefined method `last' for {}:Hash

Luckily gem lets you have multiple versions installed and I was able to add this to my .profile:

alias old_rake="rake _0.7.3_"

Now I just run old_rake whenever I want to use rake on those sites and I don't get the error. I know this is a sucky, hackish solution, but I'm too lazy to find the real problem. Especially when I only work on a couple sites not on rails 2 yet.

Thinking of doing something like this for cases where I need to search or list records from multiple models:

class AnyItem
  def self.find(*args)
    returning([]) do |items|
      all_models.each do |model|
        items << model.find(args)
      end
    end.flatten
  end

  private
  def self.all_models
    # TODO: Best way to implement this?
    # Possibly something like this? http://pastie.caboo.se/130731
  end
end

(Obviously needs to be fleshed out a bit)

Terrible idea? Probably...

One of the cool new features in Rails 2.0 is smart record identification that lets you do things like this:

redirect_to(biscuit)
link_to(biscuit.name, biscuit)
form_for(biscuit)

At first, I just assumed this wouldn't work for namespaced resources (another new feature). Not true! If you are using a namespace like this:

map.namespace(:admin) do |admin|
  admin.resources :biscuits
end

You can reference them like this:

redirect_to([:admin, biscuit])
link_to(biscuit.name, [:admin, biscuit])
form_for([:admin, biscuit])

Neato!

I'm never quite sure what the best way to write specs for assocations is. This is how I usually do it:

describe Butter do
  it "should belong to a biscuit"
    butter = Butter.new
    biscuit = Biscuit.new

    butter.should respond_to(:biscuit=)
    butter.biscuit = biscuit

    butter.should respond_to(:biscuit)
    butter.bicsuit.should == biscuit
  end
end

Really I'm just asserting that Butter has a biscuit attribute that I can use to set and get a Biscuit object. I do pretty much the same thing for all of the association types. I never really test that the association is actually a belongs_to association, or a has_one association, or any of the other types. But I'm not sure I actually WANT to test for that. Because that's technically not behavior, that's implementation. I'd just be testing rails internals instead of writing a spec for how my app should behave. Am I making any sense...?

Maybe the issue is the terminology I'm using. I considered saying "should have a biscuit attribute", but that felt... wrong. If I do that I might as well spec out all my attributes, and that is lame.

I also sometimes have a problem with the "should" terminology for associations. If I say "should belong to a biscuit" it seems to imply my object would be invalid if there was no biscuit object assigned, but that's not always the case. I considered "can belong to a biscuit", but... I just don't know.

I'm going to pretend like I have an actual reader-base and ask... any ideas?

In part 1, I started using the creation of a Biscuit resource to demonstrate the way I approach Behavior Driven Development. I do not start with the business logic, domain model, or whatever you want to call it... I start by thinking at the highest possible level: "What should it do?" (in other words, how should it behave?). I determined that that there should at least be a biscuits homepage. So I created the specs for a biscuit controller with an index action and wrote the code to make the specs pass. I ended the post by thinking what the biscuits index should actually _do_. That is, of course: display a list of all existing biscuits. Sounds like I'm talking about the view, and I am. So I fire up autotest and create the index view spec:

It's finally official.

Usually I get really excited when rails hits a new significant version, but this time, I've actually been on rails edge for a while, so these features aren't really as new and exciting as they usually are. Though it's still nice to see it hit an "official" release for cases where being "on the edge" isn't an option.

I've been loving Behavior Driven Development pretty hard. This post made me think of the way I usually approach it, which led to a deep inner need to document that approach...

A lot of times I'll throw up a rails app that includes a handful of "static" pages. About, Contact, etc. are usually just an empty controller and a big view. It's not long before I want to edit some of that content. Editing the view, committing the changes, and deploying just for content updates is really lame. So is trying to custom-fit a full-blown CMS into my existing app. So I made my very first publicly-available rails plugin: unstatic

Now I can just drop a simple call to the unstatic_content() helper anywhere I want editable content, and I'm all set. Other than setting up a password and some extra routes, there's no configuration. It uses my existing views, layouts, etc. I don't have to have a separate /admin section, learn a new templating language, or tweak any code to get it working with my app. It's a quick, drop-in mini-cms for anything written on rails.

Installation and usage instructions in the README.

I recently wanted to mimic the model.errors functionality in a non-activerecord object in my rails project...

One of the first things I do when checking in a new rails project is set svn:ignore to ignore db/schema.rb. Well, it looks like the new rake db:* tasks in rails are making schema.rb a first-class citizen. Or maybe it always was, and I was just ignorant...?

Anyway, read the changes to the comments in schema.rb for exactly what schema.rb is and how it's used. Or read the relevant bits right here:

Note that this schema.rb definition is the authoritative source for your database schema. If you need to create the application database on another system, you should be using db:schema:load, not running all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations you'll amass, the slower it'll run and the greater likelihood for issues).

It's strongly recommended to check this file into your version control system.

I've definitely had headaches when running migrations for large projects for the first time on new systems. This looks like a much better way.

By default, running rake by itself just runs the "test" task. You can add more tasks by creating a file called lib/tasks/default.rake, containing:

task :default => "name:of:task"
task :default => "name:of:another:task"
etc...

Mine looks like this:

task :default => "spec"
task :default => "spec:plugins"

If you'd like to completely bypass the default task defined by rails, put this at the top of your file:

Rake::Task[:default].prerequisites.clear

After installing the rails 2.0 preview release, I created a fresh app with the rails command and noticed that environment.rb is still requiring gem version 1.2.3. Looking at my installed gems I could see that the 2.0 preview is still technically 1.2.3:

$: gem list | grep rails
rails (1.2.3.7707, 1.2.3, ...

This was causing a problem since it was breaking my other sites that were expecting the "old" 1.2.3. To fix it in those sites, I altered this line in environment.rb:

RAILS_GEM_VERSION = '1.2.3'

to this:

RAILS_GEM_VERSION = '1.2.3.0'

It seems to be including the proper gems for those sites now.

A very specific post here to serve as a reminder the next time I have to do this: Setting up Ubuntu 7.04 with rails, Apache 2.2, mongrel (clustered), MySQL5, subversion, and deploying with capistrano 2.0. So bleeding edge!