Many people use the ultra popular Paperclip library to handle file attachments in Rails. Unfortunately the Paperclip documentation does not cover how to stub out calls to ImageMagick in your test suite. Without the proper stubs in place a test suite that uses Paperclip will take much, much longer to run.

In the grease your suite presentation by Nick Gauthier it has a slide titled Quickerclip that describes what needs to be done to spend up Paperclip in tests, basically you need to keep it from shelling out to ImageMagick. Alas, the presentation does include code for how to achieve Quickerclip.

As the presentation shows Paperclip.run is the method that needs to be changed. The first parameter passed to Paperclip.run is the ImageMagick command be executed. Paperclip uses the identify and convert commands. The identify command is used to determine the dimensions of an image. The convert command is the really heavy one that does image manipulation and thumbnail generation. Here is a redefinition of Paperclip.run with sensible behavior for tests.

module Paperclip
  def self.run cmd, params = "", expected_outcodes = 0
    case cmd
    when "identify"
      return "100x100"
    when "convert"
      return
    else
      super
    end
  end
end

class Paperclip::Attachment
  def post_process
  end
end

Redefining post_process in Paperclip::Attachment is an optional additional optimization. In Paperclip, post_process eventually calls Paperclip.run("convert") and by short-circuiting the method earlier in the chain we save a few cycles.

Ask for Help

Passenger Memory Bloat

"We found one of our passenger workers is using around 900MB of memory. Has anyone has problem with Passenger memory usage? We are using REE 1.8.7-2009.10."

Solr Master-Slave Replication

"We are interested in adding automatic failover to our Solr slave when the master fails. What are some strategies for doing this?"

Interesting Things

Git Push --force Blocked
If you find your git push being rejected, even when you use git push -f, it's probably because your git server is configured to not allow non fast-forward pushes. You'll need to change the server configuration to allow them.

spec --timeout
Be careful when running rspec with the --timeout option. When the timeout occurs the test process will be interrupted and it will print out a stack trace for wherever it was executing when it was interrupted. This can lead to a lot of confusion if you do not immediately realize it was the result of timing out and instead think that an exception actually occurred at that point.

Ask for Help

Paperclip Slowness

"In one web request we are collecting the file paths of about 250 objects that have attachments via Paperclip. Unfortunately this is really slow and takes a couple seconds to finish. Does anyone have thoughts on how we could speed this up? Is de-normalizing the file path a reasonable solution?"

Moderation of Solr Search Results

"One of our projects uses Solr and acts_as_solr to provide search results to users. One particular result is showing up far higher than we want. What is the best way to use boosting to downgrade the score of an individual result in Solr?"

Interesting Things

Bike to Work Day
May 13th is Bike to Work Day in San Francisco. We are hoping more people take advantage of this to try biking to work for the first time. To mix things up for those that normally bike to work we are planning a Bike to Lunch.

Happy Star Wars Day!

Ask for Help

"While Apache is serving a large static file it becomes slow to serve other requests. We think this may be an Apache configuration issue. Any suggestions?"

Interesting Things

Enable-pthreads Headache
In Ruby 1.8 the --enable-pthreads build option will dramatically slow down your program, as documented here and here. Do not enable it unless you need it, which is unlikely.

Don't need a primary key? Think again
You might think that you can get away with not having a primary key on a table and just rely on a database index for lookups. This is very dangerous because MySQL will no longer be able to store the records on disk sorted by primary key. Not having this ordering becomes an issue if you want to operate on the records in batches. For instance, normally you ask for all the records having an id between 0 and 1000. Because they are stored by primary key these 1000 records will be in a group on the disk and the lookup will be quick. When doing the same thing with an index instead of a primary key, and a primary key does not exist, the records will be in scattered locations on the disk and the hard drive will have to do many seeks to access them all. The time to do query will be orders of magnitude greater.