May 2008 Archives

Calling all Ruby on Rails developers in...Kansas?!

This is something that’s been mulling around in my mind for a while now. Unfortunately, I’ve been too busy and distracted with other things to give it any more than a passing thought. However, this is me [finally] taking action.

With the desire to get to meet anybody around the area that’s doing similar work, I’m taking the initiative to officially begin the Wichita Ruby Users Group. That’s right, Wichita. As in Kansas. As in Wyatt Earp. As in the freaking Wizard of Oz (but with no association with either the musical “Oz!” or the hit HBO prison drama “Oz”).

I realize there are [currently] very few people who read this blog of mine, but if you’re in Kansas (or, heck, northern Oklahoma), get in touch with me. And hey, if you know anyone in the area, direct them my way. I’d really appreciate any help I can get on spreading the word on this thing. So, even if you don’t live anywhere near, twitter about it, call around, ping people, email them and just generally annoy everyone you know about this thing. Help me get the word out! If you can, try to convince your Ruby friends to move to Kansas so they can attend the meet-ups; I guarantee they will be the most entertaining programmer meet-ups around, even if it means I have to kick-off every meeting with a live performance by the philharmonic.

We’ll take anyone working with / dabbling in / thinking about / looking at / lusting after / crying over Ruby! If I get desperate enough, we may even start to accept some Django-ers (blasphemy!), although highly doubtful.

And maybe, just maybe, one day Wichita will be home to a beautiful, thriving Ruby community.

To get in touch with me, you can…
Email me: peburrows[at]gmail[dot]com
Call me: 501.278.6321
Twitter me: @peburrows

Posted by Phil Burrows on May 31, 2008

Daily Design

So I’ve started something new. In the spirit of feeding that growling hunger in my stomach for creativity, in the spirit of some day bleeding a shade of photoshop blue, I’ve starting forcing myself to do more design work — forcing myself to try and be more creative…on a daily basis.

Everyday (as time permits) I plan on doing a design journal entry documenting my day in some way. It’ll be like my little diary, except I won’t be writing about the girls I have a crush on — that stuff’s private.

Here are a few quick examples from the first few days of this experiment in forced creativity:

monday may 26, 2008

wednesday may 28, 2008

thursday may 29, 2008

And, if you have the desire (for some odd reason) to keep up with my daily dose of CS3, you can follow the progress on flickr here.

Posted by Phil Burrows on May 29, 2008

Porting Facebox from jQuery to Prototype

The only problem: it uses jQuery, where as pretty much every project I work on uses Prototype. I like Prototype; it’s intuitive and powerful. Yes, it’s a bit bloated, but if you compress your javascript with something like the Rails asset packager plugin (which you should), filesize becomes much less of an issue. That being said, jQuery is also a great JS library.

Anyway, the point is, I couldn’t use Facebox without doing one of two things:

1) include both jQuery and Prototype so all my javascript would continue to work (BTW, jQuery plays really nice with other javascript libraries, but that’s another post for another time)

2) rewrite all my current javascript to use jQuery instead of Prototype.

Neither one of these options really seemed like a good option. Not only that, if I wanted to use Facebox at all in any other project, I would be faced with the same choice with each project.

So, I decided that there was indeed, a third, better option: rewrite Facebox to work with Prototype. Long story short, that’s what I did, and I couldn’t be happier. Here are the results (you’ll have to be reading this on the site not in a feed-reader for these examples to work properly):

With Facebox, you can…

…load a remote page.

…load an image.

…even load a certain section of the current page

By rewriting Facebox to use Prototype, using it in your rails project (or any other project using Prototype) becomes as easy as including the facebox.js file on your page and adding rel=”facebox” to any links you would like to add the functionality to.

Get Facebox for Prototype here: http://dev.philburrows.com/svn/javascript/facebox/

NOTE: at the time of this writing, in order for things to look just right, you’ll need to go grab the required images and CSS file from the official Facebox page( http://famspam.com/facebox/ ).

BTW, I really need to create some sort of commenting system for this blog of mine…

Posted by Phil Burrows on May 05, 2008

Hacking attachment_fu to cut down on image size while keeping things pretty

You guys aren’t gonna know what to do with yourselves if I keep up this trend of writing a blog post more often than once a month. If if makes you feel any better, I’m not sure I’ll manage either.

Anwyay, on to the substance.

So, like I mentioned in my last post, I’m working on a site for a photographer friend. Obviously, the main purpose of the site is to display pictures. That being the case, the obvious choice for a Rails app needing to upload files is Rick Olson’s wonderful attachment_fu plugin. For the site, I’m going to need quite a few different image sizes, and attachment_fu handles that wonderfully (If you’ll notice, we’re also using Amazon’s S3 storage service—there was some hacking done on the plugin for some tweaks to that as well; maybe another blog post coming soon?). Check it out:

  has_attachment  :content_type => :image,
                  :max_size     => 5.megabytes,
                  :resize_to    => '800x800>',
                  :storage      => :s3,
                  :s3_access    => :authenticated_read,
                  :thumbnails   => {
                    :thumb      => '100x100>',
                    :small      => '168x168>',
                    :mid        => '400x400>'
                  }

So, there are a couple things to note here. First, we’re resizing the original image to fit within 800px x 800px; attachment_fu handles this just fine. Secondly, we’re also creating four different thumbnails.

At this point, those of you familiar with the attachment_fu plugin are thinking, “So what, I do this on every project.” Yes, yes you do. But here’s what you probably don’t do: compress your images on resize. And, if you do compress your images, your thumbnails probably aren’t very pretty—they probably have visible artifacts from the multiple-JPEG-compression.

“Multiple-JPEG-compression?” I hear you ask. Yes, multiple-JPEG-compression. Maybe it’s a phrase I’ve just made up, but “multiple-JPEG-compression” is not a good thing. JPEG is a lossy format, so every time you save a JPEG image with any kind of compression, you lose a bit of the quality. Eventually, you’ll start to notice. The issue with compressing images in attachment_fu is that 1) it doesn’t do it unless you change some code, and 2) if you changed your code, you’re probably compressing the original image and then creating compressed thumbnails from that compressed, resized original. And that, my friends, is what I would call multiple-JPEG-compression.

But first, let’s back up for a bit…

The reason I even started exploring this was only because of necessity. Originally I hadn’t even thought of compressing the images; I guess assumed anything that needed to be done on the resize would be taken care of by the attachment_fu plugin. And, for the most part it is. By default, it drops any color-profile that could be included with the image (this behavior can, of course, be over-written; just specify :keep_profile => true in the has_attachment options). This is a really good thing for a couple reasons: 1) color-profiles can really increase an image’s filesize 2) color-profiles aren’t really even taken into account by most browsers. But one thing the attachment_fu plugin doesn’t do by default is compress images. So, after checking out the RMagick documentation, I figured the solution would be an easy one; all I had to do was specify a quality in the Image#to_blob call, like so:

# in attachment_fu/lib/technoweenie/attachment_fu/processors/rmagick_processor.rb
def resize_image(img, size)
  # # ...code not relevant to us right now...
  # set
  self.temp_path = write_to_temp_file(img.to_blob {self.quality = 75})
end

And that did exactly what it should: it compressed all my images on resize. But the issue I was having was the multiple-JPEG-compression; my thumbnails were turning out ugly, which is not acceptable for a photographer’s website. Here’s how they were turning out:

As you can see, this wasn’t gonna work. So, what could I do to fix it. Well, first I had to hunt down the root of the problem. After some digging, the issue was what I’ve mentioned before, the original was getting resized and compressed, and then the thumbnails were being resized and compressed from that initial resize and compress. Multiple-JPEG-compression. So, my first thought was “Oh, well I’ll just pass in the original, full-resolution image to the resize method so each thumbnail can be created from a fresh copy and will only be compressed once.”

Bad Idea. Ever heard anything about RMagick being a memory hog? Well, it’s never a good idea to feed RMagick’s addiction to hogged resources. And, having RMagick resize an image five time that could possibly be up to 5 megabytes in size is not a good idea. Duh, Phil.

So, what was the solution to the problem. After thinking about it for a bit, I arrived on the solution I moved forward with, and it appears to be working quite well. Here’s a run-through of the plan I formulated in my mind:

1) resize the original image, but without compression
2) send that resized, uncompressed image to the resize method for thumbnail creation
2b) make sure that the thumbnails are compressed (but maybe not as much as the original)
3) after all the thumbnails are created and compressed, compress the original image and save it as well

So, the next step was to figure out a way to implement my plan. Long story short, here are the re-written methods in the plugin (i’m not a fan of monkey-patching):

# in attachment_fu/lib/technoweenie/attachment_fu.rb
def after_process_attachment
  if @saved_attachment
    if respond_to?(:process_attachment_with_processing) &&
       thumbnailable? &&
       !attachment_options[:thumbnails].blank? &&
       parent_id.nil?
      temp_file = temp_path || create_temp_file
      attachment_options[:thumbnails].each{|suffix, size|
        create_or_update_thumbnail(temp_file, suffix, *size)
      }
    end
    #############################
    # now compress the original #
    #############################
    with_image do |temp_file|
      resize_image_or_thumbnail!(temp_file, true)
    end
    save_to_storage
    @temp_paths.clear
    @saved_attachment = nil
    callback :after_attachment_saved
  end
end

#
#...
#

def resize_image_or_thumbnail!(img, compress=false)
  if (!respond_to?(:parent_id) || parent_id.nil?) &&
     attachment_options[:resize_to] # parent image
    resize_image(img, attachment_options[:resize_to], compress)
  elsif thumbnail_resize_options # thumbnail
    # we want to always compress the thumbnails
    resize_image(img, thumbnail_resize_options, true)
  end
end

# in attachment_fu/lib/technoweenie/attachment_fu/processors/rmagick_processor.rb
# Performs the actual resizing operation for a thumbnail
def resize_image(img, size, compress=false)
  size = size.first if size.is_a?(Array) && size.length == 1 && !size.first.is_a?(Fixnum)
  if size.is_a?(Fixnum) || (size.is_a?(Array) && size.first.is_a?(Fixnum))
    size = [size, size] if size.is_a?(Fixnum)
    img.thumbnail!(*size)
  else
    img.change_geometry(size.to_s) {|cols, rows, image|
      image.resize!(cols<1 ? 1 : cols, rows<1 ? 1 : rows)
    }
  end
  if compress && !self.thumbnail
    self.temp_path = write_to_temp_file(img.to_blob {self.quality = 75})
  elsif self.thumbnail
    self.temp_path = write_to_temp_file(img.to_blob {self.quality = 90})
  else
    self.temp_path = write_to_temp_file(img.to_blob)
  end
end

This uses a compression level of 75 for the original full-size image and 90 for the thumbnails, compressing each image only a single time. And, after those changes, here’s the kind of thumbnails we get:

And now for a comparison:

Can you tell which is which? I sure can, and the difference in quality is well worth the time it took to figure out how to get things right.

Posted by Phil Burrows on May 03, 2008

Rails Namespaces Rock. Rails Namespaces Suck.

So this evening (can we still call it evening at 4:30am?) I encountered a frustrating issue. I’m working on a rails site for a photographer friend and it’s been coming along rather smoothly. However, tonight I ran into an annoyingly frustrating issue that turns out to have been caused some routes namespace gotchas.

Let me explain:

The site I’m putting together has an admin section, a client section and (of course) a public section. It only seems logical to namespace the different sections of the site for pretty urls and easier controller management. With that in mind, I needed a few controllers to handle the three sections. So, for instance, I had PicturesController, Client::PicturesController and Admin::PicturesController. And here’s what I initially had in my routes.rb file to handle the routing:

  map.namespace :client do |client|
    client.resources :pictures, :member => { :approve => :put, :reject => :put }
    client.resources :albums, :has_many => [:pictures]
  end

  map.namespace :admin do |admin|
    admin.resources :pictures, :collection => {:bulk_edit => :put, :bulk_update => :post}
    admin.resources :albums
    admin.resources :clients, :has_many => [:pictures, :albums]
  end

  # and of course the default
  map.connect ':controller/:action/:id'

With those namespaces in place, I aught to have been able to navigate to the following urls with no problem:

/admin/pictures/*
/client/pictures/*
/pictures/*
/admin/albums/*
/client/albums/*

And, when running things locally, I could. Not only that, when the app was running in production mode on the server, I could navigate to those URLs without problem as well…sometimes. But every once in a while (and it seemed to become more frequent the longer the mongrel process had been running), I would get a 404 error in the browser. You could usually get through to the actual page by refreshing a few times, but who wants to (or should have to) to that?! Frankly, it was pissing me off. On to the logs…

Checking the production.log was no help — ActionController::UnknownAction (No action responded to index) — really?! really?! Because I’m looking at the index action right now. Don’t try to tell me that it’s not there!

So, since production.log wasn’t playing by my rules, I decided to peruse the mongrel log. And this is what I found:

warning: toplevel constant PicturesController referenced by Admin::PicturesController

It was a warning I had never seen before. A little strange, but basically the toplevel PicturesController was stepping on the Admin::PicturesController’s toes, stomping all up and down on its methods. It’s a strange thing, but apparently there are issues with route namespaces in rails. To be honest though, I’m not sure it’s a flaw in Rails—it may be the nature of Ruby and the fact that you can’t have a class and a module of the same name. Either way, it was a frustrating thing to try and figure out. Eventually I found a bit of direction via a thread in the Ruby on Rails Google group (http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/e4a1e5f532f53785/f9a982286459d74c?lnk=raot).

All’s well that ends well, but I have to say, this one was a doozy—it’s always a pain to track down a bug that can’t be reproduced locally and also happens only intermittently. Hope this is helpful to someone.

And I’m still not tired…

UPDATE: I just realized I didn’t mention what the solution was to this problem. Basically, just rename your controllers so that they each have a unique name (this could be as simple as making one singular and the other plural). Kind of annoying, but it’s a pretty easy solution to a very frustrating problem.

Posted by Phil Burrows on May 02, 2008

New Song From My Band

Posted by Phil Burrows on May 01, 2008