Rails scraps

Posted by Daniel Wed, 16 May 2007 22:14:00 GMT

There’s some Rails things that I can’t seem to remember… because I often don’t think about them until first deployment. Here’s a few.

rake rails:freeze:gems (moves and unpacks Rails and it's gems into vendor)
rake rails:unfreeze (reverses the above)
rake rails:freeze:edge TAG=rel_1-0-0 (freezes to a specific version, modify the tag to suit)
rake rails:freeze:edge(freezes you to the latest version in the repository (usually unreleased))

Next we have the same routine for any other Gems you might need:

'gem unpack ???????' while in your vendor folder.

Replace the ? with the name of the gem you wish to unpack.

Having done that… you’ll need to add something like this to your environment file:

[There’s some notes about this in the comments, which brings about a way of DRYing some of the requires… and seems to change the number of times something is loaded. There’s also more information here.]
 config.load_paths += %W( #{RAILS_ROOT}/vendor/???????/lib )

Then you can ‘require’ your gem in your controllers or libs etc.

All the “freezing” is about ensuring that the version that you’ve tested is the version your application uses in production. Much deployment peace is found here. I tell you three times.

Posted in , ,  | 2 comments | no trackbacks

On minimalism in software

Posted by Daniel Wed, 16 May 2007 20:34:43 GMT

A long time ago I started writing code because I needed solutions for *my* problems. Not thirty other problems which made it difficult for me to get stuff done. I like getting stuff done.

Ruby continues to attract me after nearly 4 years. I’m amused at how little Ruby I’ve actually written. It’s the nature of the problems I solve with it, in combination with the incredible power of it’s terseness and well written libraries.

For example, a client has data in a MySQL database. The app that put it there seems to have gone missing in a move, and until recently the data was not required. As these things go, it went from “huh?” to “sound the alarms” in short order. My solution to their emergency? Roughly equivelant to:

require 'rubygems'
require 'active_record'


ActiveRecord::Base.establish_connection(
        :adapter => 'mysql',
            :host => '127.0.0.1',
            :database => 'something')

class User <ActiveRecord::Base; end

User.find(:all).each do |f|
  puts "#{f.name}'s email address is #{f.email}"
end

Sure, someone wrote a lot of smart stuff that I relied on… but isn’t that always the case? Well, it is for me. But that’s very little code to set up an ORM and return a useful object.

I recently worked with a C# implementation of the Active Record pattern and was amazed at how much more code (and config) there was involved in getting the same result. That’s not a knock on C# or even the implementation, but it seems that it is in the nature of Rubyists (and Ruby) to produce such minimalist design. I enjoy that.

Posted in , , ,  | no comments | no trackbacks

Distributed Ruby Workers on EC2

Posted by Daniel Tue, 15 May 2007 15:02:00 GMT

Distributed Ruby Workers on EC2: Simply put, DRb allows you to interact with remote objects via TCP as if they were located right on your system. Hence, to avoid locking our server, we will simply get another computer to perform the time-consuming task for us. Of course, now you’re saying: where am I going to get another computer? Well, how about Amazon’s EC2 [EC2 is clearly a game changer.]

Posted in , , ,  | no comments | no trackbacks