Interesting Things
RailsBridge is organizing a global BugMash to help knock down some of the bugs on the Rails lighthouse this weekend. If your interested in helping out there is more information on their wiki
We started using JRuby for a project and wanted to use JRuby to run our specs. If you install RSpec 1.2.7 or higher you can specify the ruby command used to run your SpecTask in rspec.rake like this:
desc "Run all specs in spec directory (excluding plugin specs)"
Spec::Rake::SpecTask.new(:spec) do |t|
t.spec_opts = ['--options', "\"#{File.dirname(__FILE__)}/../../spec/spec.opts\""]
t.spec_files = FileList['spec/**/*/*_spec.rb']
t.ruby_cmd = 'jruby'
end
Our "Palm webOS Night @ Pivotal Labs" was well attended two weeks ago. Mitch Allen, of Palm introduced talks by Palm's Jesse Donaldson & yours truly. Jesse walked through an overview of how to write a Mojo (the name for Palm's framework) application and I shared our experiences, including how test-driven development can work on the platform. After working with Palm's new operating system for several months it was great finally to be able to share our experiences, talk up agile practices, and answer questions.
But don't take my word for it - go see and/or listen for yourself, or just go read Jesse's slides or my slides.
The following week the San Francisco webOS Meetup was at Palm headquarters on July 28th. The organizers asked we give the same talks. We had a larger crowd but had similar questions about platform direction and experiences. While this event at Palm wasn't recorded, the content was largely the same and it was just as great to hear enthusiasm in the community.
This excitement carries over to this Saturday. August 8th is PreDevCamp, a worldwide, self-organizing event where developers will be hacking together to teach & learn how to write applications for webOS.
I'll be at the San Francisco event, which is going to be at Palm in Sunnyvale (not exactly SF), talkin' agile, helping out and of course, hacking a bit. If you're in the Bay Area, come say, "Hi." If you're not, then register for your local PreDevCamp and go code up some apps.
Interesting Things
We discovered a bug in the load order of CGI extensions in ActionController in Rails 2.3.3. The body of the first request to a Mongrel server after loading the Rails environment will appear empty, even if it's not. The problem is the default CGI::QueryExtension#initialize_query in the Ruby standard library will read the stdinput stream and not rewind it. As a result, future reads of stdinput look empty. In Rails, this behavior is overridden in action_controller/cgi_ext/query_extension.rb. Unfortunately this file isn't loaded until after the first request to a new server, at which point subsequent requests work normally. The Rails ticket is here.
The easiest fix is to require "action_controller/cgi_ext" in your environment file or an initializer file.
Years ago, after I finished college but before I started working professionally with software, I spent a couple years working as a paramedic. I learned a lot from that job, not least about interacting with people who really, really don't want you in their lives.
One of the calls I remember most vividly happened around three in the morning, not long after schools had let out for the summer. A group of recently graduated high school girls had rolled their Ford Bronco on the highway. When we arrived an engine company was on scene, busily cutting the remains of the car into fun size Bronco strips. I followed the trajectory implied by the hole in the windshield and found my patient, the driver, on the pavement some distance from the car.
During the process of upgrading a project from Rails 2.2.2 to Rails 2.3.2 several of our tests were breaking with the error:
Missing host to link to! Please provide :host parameter or set default_url_options[:host]
This error was most commonly occurring in model specs where we had mixed in ActionController::UrlWriter in order to get access the named routes (e.g. invitation_path) inside of the model class. I believe this change in a behavior is the result of this patch to Rails but I am not certain. Interestingly the code falls apart in the tests but it still works fine within the browser.
With the assistance of Adam Milligan we were able to find an acceptable way to handle setting the default_url_options in the test environment.
# app/models/invitation.rb
class Invitation < ActiveRecord::Base
include ActionController::UrlWriter
...
end
# spec/models/invitation_spec.rb
describe "Invitation" do
before(:all) do
Invitation.default_url_options[:host] = 'localhost'
end
after(:all) do
Invitation.default_url_options[:host] = nil
end
...
end
As I wrap up I want take a moment a properly shame myself for generating urls in the model. There is definitely a good argument that you should not be using named_routes in your models and I am eager to agree. Rails makes it hard to do for a reason and if you find yourself ever explicitly including UrlWriter take a step back and think the problem over. You may find yourself needlessly going down the wrong path and a different approach is in order.
Interesting Things
- If you're on Rails 2.3+ you can use NestedScenarios instead of FixtureScenarios and FixtureScenarioBuilder and your life will be better.
Ask for Help
The Pre Dev Camp in San Francisco is looking for a home this weekend. If you have a location you can donate that can hold about 150 people with laptops, has power and wifi, please contact the organizer, Luke Kilpatri at (650) 745-5302 or luke@lukek.ca
"Does anyone have experience, good or bad, with RJB (the Ruby to Java bridge)?" General consensus was murmur murmur murmur no.
Yesterday I wrote about Wapcaplet, which is really little more than a Rails patch that didn't get accepted, but that some of us think Rails actually quite needs. To that end I submitted a second patch, which does the same thing but, by default, outputs a warning rather than raising an exception. I also included some methods for modifying the behavior on ActionController::TestCase. Specifically, if you want to ensure your tests aren't broken:
ActionController::TestCase.treat_parameter_type_warnings_as_errors
Or if you, like Pierre, don't care:
ActionController::TestCase.ignore_parameter_type_warnings
I don't know if these changes will make the behavior of the patch palatable enough for the core team to commit it. We'll see. After creating the ticket I considered pulling the new behavior back into Wapcaplet; I've decided not to for a few reasons:
First and foremost, no one pays attention to warnings. I can't count the times I've preached myself blue about eliminating compiler/interpreter warnings, to little or no effect. I recently broke the builds for several projects by deleting a method that had been deprecated for a year and half, and which generated a fairly annoying deprecation warning on every build for every project that used it (keep in mind that at Pivotal projects will build many times a day).
Any patch applied to Rails will affect every Rails project that upgrades. I believe people should fix their broken tests, but I accept that this change will break a lot of tests. I can accept warnings as a way to show people what may be broken without bringing the world down on their heads. Wapcaplet, on the other hand, is entirely opt-in; no need to handle users with kid gloves.
I believe that a test failure is the right behavior. We're talking about broken tests, they should act that way.
Remember, the lion ate Pierre.
Imagine for a moment that you run a big, important company. It's important to you that your big, important company be successful at promoting, manufacturing, and distributing your big, important product, so you have decreed that the company must show a profit each and every quarter. In fact, your internal accounting software enforces this. For example:
describe "QuarterlyReportsController#create" do
it "should reject quarterly reports that show a net loss" do
post :create, :quarterly_report => { :net => -100 }
response.response_code.should == 400
end
end
Ignoring the somewhat misguided domain requirements, this test is wrong because it probably won't fail when it should. It's an example of a problem in Rails controller testing that bites everyone sooner or later.