Phil Burrows, Ruby on Rails Web Developer

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

Sat, 31 May 2008 20:54:24 GMT

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

Daily Design

Thu, 29 May 2008 20:17:26 GMT

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.

Porting Facebox from jQuery to Prototype

Mon, 05 May 2008 02:09:02 GMT

If you haven’t seen ErrFree’s Facebox jQuery plugin, go check it out. It’s a great little lightbox mod that works with the excellent, lightweight jQuery javascript library. It’s based on the way Facebook often “pops-open” a new modal window on top of the currently loaded page. It’s a handy little way of doing things, and the first time I saw Chris Wanstrath’s Facebox plugin, I thought, “This could be perfect for a few different things I’ve got coming up.”

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…

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

Sat, 03 May 2008 23:25:39 GMT

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.

Rails Namespaces Rock. Rails Namespaces Suck.

Fri, 02 May 2008 04:34:43 GMT

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.

New Song From My Band

Thu, 01 May 2008 15:09:13 GMT

My band ( the philharmonic ) has a new demo up on the site. Go check it out. Comment and tell me how much you hate it and how much you wish I would actually write something of substance in this blog... .phil.

SXSW. Top Ten Lessons Learned in E-Commerce

Sat, 08 Mar 2008 12:10:28 GMT

top 10 lessons learned in e-commerce

THE E-COMMERCE BUSINESS IS BUILT ON REPEAT CUSTOMERS.
WORD OF MOUTH REALLY WORKS ONLINE.
DON'T COMPETE ON PRICE.
MAKE SURE YOUR WEBSITE INVENTORY IS 100% ACCURATE.
CENTRALLY LOCATE YOUR DISTRIBUTION.
CUSTOMER SERVICE IS AN INVESTMENT, NOT AN EXPENSE.
START SMALL AND STAY FOCUSED.
DON'T BE SECRETIVE. DON'T WORRY ABOUT COMPETITORS.
YOU NEED TO ACTIVELY MANAGE YOUR COMPANY CULTURE.
BE WARY OF SO-CALLED EXPERTS

CONCLUSIONS

Customer Service is of the utmost importance

SXSW. Design Is In The Details

Sat, 08 Mar 2008 11:11:43 GMT

I plan on posting my notes from the different sessions I attend here at SXSW. First up: Design is in the Details—Naz Hamid.

design checklist

01 EXPERIMENT

beautiful mistakes

02 CHOICES

choose simplicity and what makes sense
complexity may be a (bad) sign

03 STAY CONSISTENT

especially important when working on internal pages

04 COMPLETENESS

don’t let the clients get hung up on the little details that should be completed

05 STEP IN, STEP OUT, STEP BACK: BALANCE

taking breaks can help you be objective about your design
do it, then forget it, then come back with fresh eyes
take notes on what stood out when you looked at it the first time back

06 BE YOUR OWN CRITIC

have sound explanations for your decisions

07 COMPLEXITY IN SIMPLICITY: LESS IS MORE

don’t include what we don’t need

08 OBSESSION IS HEALTHY

dedication to the design is essential
take the time to focus on the little details

THOUGHTS, BREAKTHROUGHS & REVELATIONS

make sure you’re pleased with what you’re presenting

SXSW Rails Happy Hour

Fri, 07 Mar 2008 23:56:52 GMT

Just a quick mention of something that’s going on at SXSW—

We’re having a Rails Happy Hour sponsored by Five Runs. Come on over and enjoy free drinks, food and seasoned conversation if you’re in Austin for SXSW (or any other reason).

Snaptweet

Tue, 26 Feb 2008 00:08:21 GMT

So Damon Clinkscales (a guy I work with) has put together this nifty little app called SnapTweet that integrates with Twitter and Flickr. Check it out, it’s pretty neat-o.

BTW:

Me on twitter
Me on flickr
Me on snaptweet

...and we're back

Thu, 21 Feb 2008 21:01:59 GMT

So posting to this thing has proven to be less frequent than I had hoped, but I’m here to say that [hopefully] it should become more of a routine. I’m going to make myself do it.

So there are a few things I’ve been meaning to document. Like I said in my first post, I did a custom Radiant CMS for vitalsource.com:http://vitalsource.com/ although I didn’t do the design on that site, I just ported over the content to the new CMS. Anyway, I put together a few custom extensions for the site. They may be useful for one of your project, and if so, feel free to use them as you wish. I’d love to know if you find them useful and how you’ve implemented them on your site. Now, on to an overview.

Translator

http://dev.philburrows.com/svn/radiant-extensions/translator/trunk/

Yeah, I’m still using subversion. Sorry I haven’t jumped on the git train just yet for my personal stuff.

The Translator extension is for localization. It’s not really an issue I’ve ever had to deal with, so, initially, I figured the best thing to do was use something someone else had put together and a number of people had used with success. But I looked at all the other localization options for Radiant, and none of them seemed to do what I wanted a localization solution to do for me. Other localization options (i.e. Language Redirect) seemed to require way too much duplication of content. Not only that, but there wasn’t a way to reliably fall back to default content (or a default language) if the content in the requested language did not exist. So, localization was an “all or nothing” option. Unfortunately, the VitalSource website only has certain, important pages translated. Using any of the available localization extensions, foreign language visitors would end up getting a BUNCH of 404s.

So, what could be done? We don’t want to give a user a 404 just cuz we haven’t had the chance (or ability) to translate a certain page into your language of choice. So here’s what we’re doing…

In Radiant, every page can have any number of parts. So, the typical page will have something like a “body” part and maybe an “extended” or “intro” or “sidebar” part. So, instead of duplicating entire pages in different languages, why not just create a different page part for each language? And then, if the page part isn’t available in the requested language, we can just fall back to rendering the default language.

Honestly, that was a terrible description. The concept is explained a bit better in the README.

Regular Expression URLs

http://dev.philburrows.com/svn/radiant-extensions/reg_exp_urls/trunk/

With the handy Copy and Move extension it becomes really easy to move your pages around and reorganize the hierarchical arrangement of your site. BUT, by doing this kind of thing, it also becomes really easy to break links within your site. “Regular Expression URLs” to the rescue. Create links that look for a page that match a certain regular expression and output the proper URL, instead of just blindly spitting out a URL that may no longer be correct.

Again, check out the README for syntax overview.

The First of [Hopefully] Many

Wed, 13 Feb 2008 02:44:17 GMT

So here it is—this is the beginning of something good, I think. Today is the day (early as it is), that I finally get this blog online.