Clever::Tagline::Pending

Remember all that joy coding with Rails when you were a wee lad? Things seemed so blissful then, metaprogramming voodoo and that complex object relational mapping stuff were all taken care of behind the scenes.

Alas, whence it doth time to unleash your brilliant social networking app onto the unsuspecting public, your Ruby/Rails world came crashing down faster than FSJ can order a chai latte.

FastCGI, SCGI, Mongrel, Rack, Thin, Pound, Nginx, Apache.

Doing a virgin Rails application deployment would have been a trial by fire where you’ll trawl the Ruby and Rails forums looking for advice on which webserver is best suited to serve your future web application superstar or pray to the One and just deploy on faith.

You’ll settle for Mongrel or Rack if you were lucky enough to come across people who have been there before. Otherwise, be prepared to be regaled with war stories about how some web hosts *COUGH* Dreamhost *COUGH* arbitrarily shutdown your Rails processes for consuming a tad too much resources.

Wouldn’t it be nice if I could just do like what I did for PHP applications? Just upload the files onto the webserver and it just works(tm)?

Now you can! Well, technically only the people at Phusion can at this moment. Lai Hongli breaks the news about modrails, complete with requisite cool screencast.

I think this is a really cool development that makes life a whole lot simpler for people who just want to focus their energies on actual development rather than have to worry about how to configure the deployment environment properly. Even if this is Apache2 only now, it should be possible to port it over to other servers like Nginx, licence restrictions notwithholding.

Chris Wanstrath has written about making Rails fixtures less painful than they need to be with the FixtureScenarios plugin. Personally, I prefer the Factory approach, nicely explained by Daniel Manges.

I’ve been using factory methods to create in-database ActiveRecord objects for a project that I’ve been working on in Bezurk. Reading Daniel’s article gave me a few ideas on improving the way I create fixtures and mocks. Since I’ve been using RSpec extensively in this project, I’ll present the examples in RSpec.

As the models evolve with the design and its behaviour change accordingly, there is a need to go through all the specifications that create this model and make sure that its created in a valid state. This is more pronounced with the use of test doubles, the test doubles also need to have its method stubs changed to reflect the latest state of the model that its is representing. I happen to make much use of test doubles for test isolation, so trying to manage all these objects became an exercise in patience. As it was getting painful, It’s time to change the way I create these models and test doubles.

As always, a layer of indirection will always go some way to solving a software problem. We introduce a Factory that encapsulates the creation of ActiveRecord objects by providing creation methods.

[ruby]
module FixtureFactory
def create_user(attributes = {})
User.create!(ModelAttributes.user(attributes))
end
end
[/ruby]
We’ll have a Factory for test doubles too.

[ruby]
module MockFactory
def mock_user(method_stubs = {})
mock_model(User, ModelAttributes.user(method_stubs))
end
end
[/ruby]
And the attributes for this model will be declared in a module that’s used by both Factories

[ruby]
module ModelAttributes
def self.user(attributes)
attributes.reverse_merge({:name => ‘doug’})
end
end
[/ruby]

The Factory modules are then included in Spec::Runnner

[ruby]
Spec::Runner.configure do |config|
include FixtureFactory
include MockFactory
end
[/ruby]

The objects can now be created using the factory methods available to all specifications.

[ruby]
doug = create_user
doppelganger = mock_user
[/ruby]

Update
Added links to Chris Wanstrath and Daniel Manges’ articles on managing Rails fixtures.

The next singapore.rb meeting will be held on the 19th of April 2007 in the Central Lending Library. The National Library Board of Singapore has kindly provided the use of one of their meeting rooms (complete with WIFI). The (tentative) agenda for the meeting is as follows:

7:00pm Rails Plugins Showcase: Dead simple AJAX and Form testing in Rails – Choon Keat
7:30pm FxRuby and ScreenSvr – Sausheong
8:00pm Q&A, discussions
8:30pm End of meeting

My thanks goes out to the NLB’s Ivan Chew for facilitating the use of NLB facilities for a trial session, as well as to Choon Keat and Sausheong for making the presentations.

The Rails Podcast has an excellent interview with Josh Shairbaum and Dan Manges from JP Morgan on using Rails in the enterprise. Do check it out if you’re at all interested in introducting Ruby/Rails to your particular company.

Listening to Josh and Dan made me realise that I’m quite fortunate to be working in a company where there are no corporate traditions to follow when it comes to technology. I’ve developed 2 applications for use by staff and clients alike so far and they’re both powered by Rails. Being the sole developer in my company, Rails is a perfect fit and this combination has shown its worth.

Josh mentioned that his development team of 3 got Rails in the door by using it to develop a reporting application, an app where the implementing technology was not a big issue with corporate managers. By having the reporting application running AND available to end users within 1.5 months demonstrated the productivity gains that can be achieved by Rails. A lot of evangelizing and demonstrations were done to help their cause too. I think that they benefited a fair bit from having key people in other functional units willing to give Rails a try, even though it required them to risk doing something that’s new and by corporate definition, risky.

It’s encouraging to listen to them and their passion for Rails was apparent in the way they talked about and how they dealt with people who did not understand what it was.

I’ve started using RSpec in my Rails projects. Besides serving the purposes of testing my application, it has also become an extremely useful design tool. Comparing the DSLs for Test::Unit and RSpec, the latter expresses the intention of the tests much more clearly and quickly. Luke Redpath does a great job of explaining the basics of Behaviour Driven Development using RSpec on Rails. Its a must read if you’re interested in exploring BDD for your Rails development.

Technorati Tags: Rails, Ruby, Testing

Rick Olsen, a member of the Rails core team has a good writeup on working with ActiveResource. It seems that Beast is taking advantage of ARes to provide a RESTful API while keeping all the heavy lifting transparent to the user of the resource.

The documentation on ActiveResource is really scarce at the moment and posts like Rick’s are hugely useful to Rails developers who are looking to leverage ARes in their applications. Speaking on which, I would be refactoring an internal app used within my agency for ARes soon. I just have to implement the remaining user stories and take it to 1.0 first.

More on that as I get deeper into development.

The Rails core team released 1.1.6 of the framework today, a day after 1.1.5 was released. This was to fix a serious vulnerability in the Routes module. The core team has been extremely prompt in publicising the hole and in releasing fixes.

However(you know there had to be one), I take issue with how the first fix release (1.1.5) was handled. It appears that this release did not fully rectify the problem, hence the need for 1.1.6. While DHH revealed the reasons for 1.1.5, he did not detail exactly what was wrong, opting for a security through obscurity approach.

In retrospect, a full disclosure policy would have been a better move. This would have given developers more information in deciding whether to shut down their sites, in view of the implications(data loss/theft et al) of having it compromised.

That said, if you’re running a rails web application in the wild, UPGRADE NOW.

EDIT: mixed up my rails versions, doh!

I wanted to be able to have my testing regime automatically create files associated with model fixtures defined in the fixture files. Coincidentally, I’m using Sebastien Kanthak’s file_column plugin for managing files in models.

After looking at the Fixture class and the FileColumn module, I realised that I needed a way to store the model attribute(s) that were passed in the call to file_column. What FileColumn did was create the methods according to the attribute passed into the method but the attribute itself is not actually stored anywhere.

Time to extend FileColumn:

[ruby]require File.join(RAILS_ROOT, ‘vendor’, ‘plugins’, ‘file_column’, ‘lib’, ‘file_column’)

module FileColumn
module ClassMethods
@@file_column_attributes = {}
alias :aliased_file_column :file_column
def file_column(attr, options = {})
aliased_file_column(attr, options)
klass = self.name.constantize
@@file_column_attributes[klass] ||= []
@@file_column_attributes[klass] << attr
end

def file_attributes
@@file_column_attributes[self.name.constantize]
end
end
end[/ruby]

As the name implies, the methods in ClassMethods are class methods on the including class. So in order to store the file_column attributes, we need a class variable, @@file_column_attributes. This variable is a hash with the model class name as the key and an array containing the attributes.I’ll also implement a class method so that I’ll be able to do Model.file_attributes and know what attributes have been file_columnised.

Next, we’ll need to change the way fixtures are populated to the test database. This involves extending the Fixtures class.

We’ll do this in test_helper.rb

[ruby]
require ‘fileutils’
class Fixtures
SAMPLE_FILE = File.join(Test::Unit::TestCase.fixture_path, ‘files’, ’sample.pdf’)
include FileUtils

alias riginal_insert_fixtures :insert_fixtures

def insert_fixtures
original_insert_fixtures
create_files(@class_name, values) unless @class_name.constantize.file_attributes.nil?
rescue NameError
# workaround for HABTM fixtures
end

def create_files(klass, values)
model_dir = File.join(Test::Unit::TestCase.fixture_path, ‘media’, ‘uploads’, klass.downcase)
values.each do |fixture|
klass.constantize.file_attributes.each do |attr|
create_file(fixture, attr, model_dir) unless attr.nil?
end
end
def create_file(fixture, attribute, parent_dir)
attribute = attr.to_s
dest_dir = mkpath(File.join(parent_dir, attribute, fixture['id'].to_s))
file_dest = File.join(dest_dir, fixture[attribute])
cp(SAMPLE_FILE, file_dest) unless fixture[attribute].nil? or File.exists?(file_dest)
end
end
[/ruby]

The extended insert_fixtures method first invokes original_insert_fixtures, then checks whether the model has any file_column attributes. If it does, the files defined in the fixtures will be created if they don’t already exist.

EDIT: Running functional tests with rake test:functionals fails miserably even though running the tests individually is just fine.