I build a lot of Rails apps on a regular basis and each one I add to my server takes another bite out of my limited resources. The way I’ve traditionally setup a new Rails app was using a Mongrel cluster. I found it to be a lot more reliable and faster than the fcgi approach people use to use (and some still do). The downside to setting up a few dozen Rails apps on your server with each running a Mongrel cluster is that it eats up all your memory. One of my sites is starting to get a lot more traffic than it has been in the past and its putting additional strain on the server. As a result I decided to find an alternative to Mongrel. I’ve tried searching for alternatives in the past but everything sent me back to Mongrel. Until today of course when I came across Jamie Flournoy’s blog about mod_rails.

Excited for an alternative to raising a pack of resource hungry mongrels on my server I installed the gem and tried it out. It was exactly what I was looking for as far as ease of use straight away. All I needed to do was stop a mongrel cluster and simplify its virtual host directive in Apache to leave out the mod_proxy_rewrite and the other wonky rewrite rules. The first app I tested went smoothly but suddenly the server started misbehaving. Resources were being eaten and it wasn’t clear what was doing it because the app I was testing with is behind an Apache password and I’m the only user. I ended up having to turn off the mod_rails to get my system back in control. The problem turned out to be that by default mod_rails tries to test if your virtual host directory is a rails app or not. I have a few apps that I tossed in an instance of Wordpress into a blog directory inside my rails app directory. I found it convenient to toss them all into the same directory since its all the same website. As a result mod_rails was doing a ../ check to see if the blog directory was a rails app which it decided it was. That’s where the craziness came in because its a php application. Anyway, the quick solution was to move the blog directory out of the Rails app directory.

Other than that my memory usage is way down. I’ve migrated all my low traffic sites to mod_rails and I’m happy with how they’re performing. There is a little delay on the initial load of the app but subsequent calls are quick because its already loaded. I can wait an extra 2-5 seconds for my low traffic apps to load in exchange for hundreds of extra megs of free memory.

I haven’t moved over my higher traffic money making sites yet and I’m not entirely sure I will until I’ve tested mod_rails a bit more. I’m extremely happy with the results thus far though.

I’ve been working with a client to optimize parts of their Rails application. The problem is that a method in the app does some simple updating of a few model objects but because the model has so many relations it goes through a ton of unnecessary callbacks. There are issues related to data concurrency which means you have to do the callbacks but in this particular situation there won’t be any concurrent updates to the data so the callbacks can be omitted. The solution to the problem was trivial when using the save_without_callbacks Rails plugin. Just adding a simple:

before the update_attribute reduced the number of SQL UPDATE queries from 90 to 8. Lesson learned. If you need to skip model relation callbacks on save this plugin is for you. Be careful about data concurrency issues though.

The other day I noticed a pretty significant SEO related problem with using a built in Rails construct. I noticed a problem when I started getting application errors that were letting me know that the user agent was none other than our friendly Googlebot. A closer look at the app shed light on a problem you may not have even expected. When using

it will take a look at the HTTP_REFERRER and redirect the user to that url. The problem, however, is that Googlebot doesn’t send a referrer and neither do a whole bunch of other search engine spiders. The result is that when they visit your site they get a nice 502 server error because Rails raises an exception. It doesn’t know what url to redirect to so it send a 502 error. Googlebot then sees your site as a bunch of 502 errors in the situations where you’re using redirect_to :back. Take a look at the Rails API and you’ll see the last line clearly mentions this.

The solution is to catch the RedirectBackError the redirect_to raises when there’s no referrer. Its a simple fix but one you need to be on the lookout for or else you might end up with a few 502 errors giving you bad mojo with the Google gods.

I’ve made the leap and I’m starting to use Rails 2.x for all my apps now. Overall it was a pretty smooth transition over to 2.x. One thing I noticed immediately after running the scaffold generator, ./script/generate scaffold Something, was that the layout template was named something.html.erb. What’s this new .erb extension I thought to myself. I did a little searching and found Ryan’s Scraps where he explains the reason for the change. Its all about semantics. Notice the post date was back almost a year ago.

It makes me want to reflect about Rails in general. Am I really a year behind here? I’ve been developing in Rails for a few years now and love it for all the right reasons. One of the most important facets the framework offers is its constant adaptation to better ideas. The Rails project seems to be one of the most fluid projects I’ve ever seen in terms of embracing new and better techniques for doing things. I think that simple fact is what gives it an edge.

In this industry, a developer has to constantly stay ahead of the curve and always be thinking of how to do things better. I end up getting into the trenches and working on a project for a while but by the time I come up for air I’m doing things the old way already. Here I am upgrading my skills to Rails 2.x and I’m already feeling like I’m old school. Rails apps move quickly and if you don’t pay attention you’ll just as quickly get behind. Other frameworks seem like they’re more consistent over time and as a programmer there’s often little to learn on new releases. Rails is different. It forces you to reconsider what you already know. Take routes for instance. Now everyone is using RESTful routes. You learn the old way and they reinvent it under your noes. Its a beautiful dynamic that forces me as a developer to stay on my toes and to constantly improve my own skill set.

One problem that I face, however, is the complexity of managing multiple project across multiple Rails versions. Rails luckily allows me to freeze the framework into a project so my problem isn’t in incompatibilities. Its in the complexity that arises from having 20 or so projects all running different Rails versions. Some of my projects run older versions of Rails 1.x. Some run the newest 1.x version and even newer projects are now running 2.x. Sure you can say that I should upgrade all those projects but that works in theory. In practice, however, resources are limited and some projects have a priority over others. Time is limited so its usually spent where its needed most. Smaller projects fall through the cracks and sooner or later they seem like old legacy apps even though they’re only maybe a year old. I suppose its just another part of this industry: dealing with legacy systems. Not every legacy system can be upgraded to the latest and greatest. Of course the purist programmers out there want to keep everything current and doing every single best practice you can consider best. Practicality reins supreme though and resources will always remain limited. The best any developer can do is to constantly try to reinvent themselves and never close the door to new ideas. Once you become comfortable in what you know is when you’re going to miss the next big idea.

I was surprised to come up empty handed when searching for a Google Base Rails plugin. I wanted something that would allow me to easily create a feed into Google Base using their API. I didn’t find anything so I took the quick and short term solution and created my own Google Base xml feed. Its based on RSS 2.0 so its not incredibly difficult but I could have saved a few minutes if it was already written for me so here it is. My Google Base xml generator in Ruby on Rails. Its not complete and only has the fields that I specifically wanted for my products. Your feed will likely contain other fields so check the Google Base docs for more information on customizing it. You’ll notice that I thought Google Base was going to pull my xml feed when I initially wrote this but it turns out I have to use the API and this is just good for generating the xml file which you then have to manually upload to Google Base.

First, I added this to route.rb

Then I created controllers/google_controller.rb

And finally, I create views/google/base_feed.rxml

There are obviously calls to helper methods in the base_feed.rxml file like product_url and photo_url. I use those so I can easily generate pretty seo urls anywhere I need them. You’ll need to replace those with however you create your urls.

This should suffice for at most 31 days when all the products I just added will expire in Google Base. I doubt I’ll bother creating a Google Base Rails plugin unless I see a noticeable increase in traffic and sales so don’t hold your breath.

I’ve often come across situations while developing Rails apps where I just want a simple integer drop-down box. The default Rails helpers for selects and its options aren’t really geared for something simple like that. I don’t want to have to create a collection of integers and pass them into blocks or any other ridiculous workaround in my views. I want them clean and simple. I created a helper function which allows you to easily create integer drop downs. Just toss this in your application_helper.rb.

And in your view simply call:

And you have yourself an integer dropdown from 1-20. I tried to make the options and select formatting and id/name conventions the same as the rest of the Rails select/option helper methods to keep things consistent.

If I have:

The problem is that:

returns all the Products tagged with ‘test’ rather than all Subproducts. So I tried:

but that does the same thing. The problem boils down to the find_tagged_with! method using acts_as_taggable_options[:taggable_type] which is defined as class_name_of_active_record_descendant elsewhere in the acts_as_taggable plugin. The solution is to rewrite find_tagged_with! to :

This should work even for classes that aren’t using class table inheritance since it’ll just use the class name.

Refs: http://wiki.rubyonrails.org/rails/pages/ActsAsTaggablePluginHowto

I’m not sure why it took me a while to figure this out but it did. The Ruby CSV documentation is really weak and really only explains how to read from a file. I googled around and couldn’t find anyone else talking about how to parse a CSV file sent via a form post (StringIO). I didn’t want to save it to a temp file just so I could follow the CSV docs examples. Here’s what I eventually got to work. Its so short and simple I feel silly for not figuring it out sooner.


parsed_file = CSV::Reader.parse(params[:dump][:file])
parsed_file.each do |row|
p row[0]
end


I’ve searched around for a decent tag cloud for Rails and really liked this Rails Tag Cloud solution. Its simple, easy to setup, and I like how it separates the cloud from my other code. I made some comments to the post which improves the cloud by ordering tags better.

I’ve just started using Mongrel instead of fastcgi for my Rails apps. Its only been a few days but I’m already loving the difference. Its so much faster than before. It wasn’t hard setting up either. Now Apache just proxies requests to Mongrel. I used this article titled Using Mongrel Cluster to set most of it up. I added a few minor customizations for my situation but nothing you can’t figure out from reading the article.