Scott Tamosunas's blog



Scott TamosunasScott Tamosunas
Standup - 2/11/09 - Fitter, happier, more productive.
edit Posted by Scott Tamosunas on Wednesday February 11, 2009 at 05:21PM

Help

"I am getting spam from working with rails site about once a week asking me if I am looking for work. I'm not, how do I make it stop?"

Besides the obvious, check the "I don't want email" box, nothing comes to mind.

Interesting things

  • If you are running your site on Engine Yard and you want your site's "heartbeat" monitored, install the fitter_happier plugin. See EY's notes here.

  • Be careful when calling #id on an object that's a Fixnum (especially if you think it's something other than a Fixnum, like say a user object). It will return (value * 2) + 1. Most likely this will go away in the next major revision of ruby given the "warning: Object#id will be deprecated; use Object#object_id".

  • Josh Susser is giving a talk at Ruby Meetup tonight. Topic, Iterations and Blocks.

Scott TamosunasScott Tamosunas
Standup - 2/10/09 - Speeding up RSpec tests and fixtures
edit Posted by Scott Tamosunas on Wednesday February 11, 2009 at 01:26AM

Interesting things

  • After making some changes to our RSpec suite (namely moving to fixture scenarios), we realized almost a 50% improvement on our local dev boxes (generally iMacs with 4G of ram). However the CI box (a Mac Mini) remained at about the same duration. Increasing the InnoDB MySQL settings to the following caused a significant performance boost on our CI box (about 200 seconds down from 350 seconds):
[mysqld]

innodb_buffer_pool_size = 64M
innodb_log_buffer_size = 8M
table_cache = 512

query_cache_size = 8M

The theory is that our local dev boxes have so much ram that the disk reads are cached while the CI box is swapping out to disk often.

  • Fixtures in RSpec can be slow due to nested describe blocks. Each time a new describe block is opened, the fixtures have to load. Therefore, if your test suite has many nested describe blocks with only a few tests in each describe, this will cause lots of fixture loading.

One possible solution is to use the underlying database (e.g.. MySQL SAVEPOINT and ROLLBACK TO SAVEPOINT) to save and reload the fixtures. Another possibility is to group your tests in a less-nested fashion.

Scott TamosunasScott Tamosunas
Standup 2/9/09 - chaining associatons, use_rails_error_handling! and eager_load_paths
edit Posted by Scott Tamosunas on Monday February 09, 2009 at 05:29PM

Interesting things

  • People seem to think it would be useful to chain associations in the same way that named scopes work. E.g., post.comments.authors. We might look at providing a patch to do so.

  • Rspec and Rails 2.2 modifies rails to not rescue exceptions as it normally does. To fix that, add the following to your tests:

describe ThingsController do
   before(:each) do
     controller.use_rails_error_handling!
   end
end
  • A project was running into a problem on non dev/test environments with rails 2.2 where if we did a db:drop and a subsequent db:create, the migrations were blowing up with an exception on the Rails::Initializer.run line in environment.rb. The models were being loaded before any of the migrations had run, thus failing because the tables didn't exist. To work around this, add config.eager_load_paths = [] in your Rails::Initializer. It was suggested this was either a bug in 2.2.2 and/or a bad interaction with desert.

Scott TamosunasScott Tamosunas
Standup 11/6/2008
edit Posted by Scott Tamosunas on Thursday November 06, 2008 at 05:13PM

Ask for Help

"console.log seems to be broken again in Firebug with 1.2.1?"

People have had some success with 1.3 beta. Get Firebug

"Suggestions for creating PDF's in Ruby?"