Toluu

techno weenie - Home

Rails Migrations in Git BranchesMarch 25

For those of you that don’t stalk follow my other streams:

Migration Buddy

Or, “the inevitable renumbering and conflict-resolution of miggy tardust”

This is a tool to help merge rails branches with conflicting migrations. The basic idea goes like this:

• First you migrate down to the migration you were at when you branched.
• Renumber any new migrations you created that conflict with any new migrations in the target branch.
• Commit the renames.
• Merge to the target branch (usually ‘master’).
• Migrate back up.

Wow, what a pain, right? (Apologies to Saul Williams, you rock).

I keep threatening, but I may have to replace this blog with a combination twitter / tumblr / github stream.

moving to githubMarch 4

I’ve been using git for several months now, waiting for a reason to keep my svn habits around. So far, it’s been pretty smooth sailing. There were some squalls along the way as I unlearned some habits from svn though. I even moved active development of my various open source projects to git. Well, today I’ve moved most of my “active” (and I say that in the loosest of terms) projects to github.

Github is fantastic, but why?. The core repository browser stuff looks and works great, but is nothing revolutionary, to be honest. What’s amazing about Github is how it really brings the social aspect into play. Chris and Tom are showing us all visually how git development is supposed to work. I know I personally had some bing moments once I started pulling in commits from external git repos.

For what it’s worth, Gitorious is another great community of git hackers. They’ve also added merge requests to the mix since the last time I looked at it. The differences with Gitorious are that it’s exclusively geared for open source projects, and that Gitorious itself is open source. That’s wild.

The great thing about git is that it doesn’t matter which you choose. You can easily add a git remote for both, and keep your origin on your own server. I hope we can see some collaboration between the tw

Giles is Proud Not to Understand has_many :throughFebruary 13

Apparently, the number of exception classes related to has_many :through (HM:T) scared Giles away. I think most of them are there because I put the original ones there. Course, looking at them highlighted does make it seem a bit ridiculous.

HM:T associations are the only associations that actually look at other associations to figure out how to query the database. There aren’t a simple set of conventions to go by that raise simple errors like “couldn’t find the `suspended_users` table”. If you actually look at the associations, they’re not much more than simple ActiveRecordError subclasses with a custom message. It gives you nice, helpful messages like this:

class Post < ActiveRecord::Base end class User < ActiveRecord::Base end class Topic < ActiveRecord::Base has_many :posts belongs_to :user end class Forum < ActiveRecord::Base # commented out bits are things # i conveniently 'forgot' in this contrived example. # # has_many :topics has_many :posts, :through => :topics has_many :creators, :through => :topics# , :source => :user end Forum.find(:first).posts # => ActiveRecord::HasManyThroughAssociationNotFoundError: Could not find the association :topics in model Forum Forum.find(:first).creators # => ActiveRecord::HasManyThroughSourceAssociationNotFoundError: Could not find the source association(s) :cr

Timezone awareness in RailsFebruary 6

I just committed another piece of the puzzle to Rails’ new time zone support, coming in Rails 2.0. This takes a different approach than my previous attempt at timezone-aware activerecord attributes. The whole idea behind this approach, is that times appear in the local time zone while you work with them, but are persisted to the database in UTC.

>> Time.zone = "Pacific Time (US & Canada)" >> @status = Status.find :first >> @status.created_at => Tue, 29 Jan 2008 15:30:09 PST -08:00

If you set the time, it makes any necessary conversions to your current time zone.

>> @status.created_at = Time.utc 2008, 1, 1 >> @status.created_at => Mon, 31 Dec 2007 16:00:00 PST -08:00

Multiparameter attributes (say, from a time select box) are changed to the current time zone properly.

>> @status.attributes = { ?> "created_at(1i)" => "2008", "created_at(2i)" => "1", "created_at(3i)" => "1", ?> "created_at(4i)" => "0", "created_at(5i)" => "0", "created_at(6i)" => "0" } >> @status.created_at => Tue, 01 Jan 2008 00:00:00 PST -08:00

Now in our particular app, it’s very important that each user sets up their own timezone. The easiest way, we’

Controller specs are a dragDecember 26 2007

Ever since Jamis taught us about fat models and skinny controllers, the controller’s importance has dipped a bit (for the best). Controllers should only be testing the basic things, such as the fact that it’s using the params correctly to retrieve and create records, and returning the right response. Any more details about the model are usually exercised in model specs. This can make the examples incredibly repetitive:

it "should set @records when accessing GET /index" do get :index assigns[:records].should_not be_nil end

• For those not using rspec, you can pretty much replace ‘spec’ with ‘test case’ and ‘example’ with ‘test’. It’s all the same, really.

Rspec tends to encourage that the controller examples be broken up into finer contexts, such as by action. (You can do this with test/unit of course, but it’s not nearly as common). You’re also encouraged to keep to a “single assertion per example” discipline. This way if one assertion fails, the other assertions are still run in other examples. Good practice to follow, but it results in a lot of extra time spent writing more spec examples. Here’s what I came up with: (old and busted