



Full-time web developer. Part-time smart ass.

I'm Brent Collier.



Configuring Redis Store for Rails 2.3.x

Posted on 05/23/2012

I wanted to use Redis as the cache store for a Rails 2.3.8 app. After a little shopping around, I settled on RedisStore as the cache adapter. I following the configuration directions on the RedisStore website and restarted the app, expecting everything to be hunky-dory. Instead, I was kicked in the face with this:

uninitialized constant ActiveSupport::Cache::RedisStore

My redis-store configuration looked like this:

redis_config = YAML.load_file(RAILS_ROOT + '/config/redis.yml')[RAILS_ENV]
config.cache_store = :redis_store, redis_config

I took another look at the config instructions and realized I was using the Rails 3.x setup. Following the 2.x instructions, I updated the configuration to look like this:

config.gem 'redis-store'
config.cache_store = :redis_store, redis_config

After restarting the app, I was still seeing the same uninitialized constant error. Finally, a bit more googling revealed that v1.1.0 of redis-store didn't jive with Rails 2.3.8. Evidently what I needed was v1.0.0.1. I'm not sure why it's v1.0.0.1 and not v1.0.1, but I checked and saw that v1.0.0 was yanked for some reason.

alt text

Anyway, so I updated my Gemfile to specify version v1.0.0.1 of redis-store and bam! The app starts up without yelling at me. Good stuff. Or so I thought.

Everything was hunky-dory in my local development environment, but when I started testing in our staging environment, something was up. Our staging environment consists of two app servers, one of which has the Redis instance running on it.

Attempts to connect to Redis repeated failed with an "unable to connect" error on one web server, but not the other. Examining the redis connection, it was clear that the app was trying to access Redis via localhost, the default when no valid connection options were supplied. This explained why it worked on one app server and not the other, since Redis was in fact running locally on one of them.

A little console debugging demonstrated that the redis config expected a hash with symbol keys, whereas the config hash loaded from the yaml file had string keys.

config.cache_store = :redis_store, redis_config.symbolize_keys

Updating the redis-store config to symbolize the keys allowed the connection to be properly created, and everything was working as intended.


Sass'd Bootstrap Even Better

Posted on 11/14/2011

A while back I wrote a post on how to use the Sass version of Twitter's Bootstrap toolkit in your Rails 3.1 app. You had to clone a repo and copy a bunch of files over, blah, blah, blah. That's so last week.

Now there's a new, much better way to include all the Sass and Bootstrap goodness. Here's how it works:

1) Add the bootstrap-sass gem from Thomas McDonald to your Gemfile like so

gem 'bootstrap-sass'

2) Update your bundle

3) Add this line to your application.css

*= require bootstrap

4) High-five yourself

That's all it takes and you're up and running with the Bootstrap styles. What's that you say? You want the Bootstrap JS libraries also? No problem. Just add them to your application.js like this

//= require bootstrap

Or if you want to pick and choose which JS to include, like this

//= require bootstrap-scrollspy
//= require bootstrap-modal
//= require bootstrap-dropdown

Very nice.


Kicking Assets and Taking Names

Posted on 11/01/2011

There's a couple of simple things you can do to really make your Rails 3.1 app more responsive...

  1. Precompile your assets in your production environment. I think this pretty much goes without saying, but if for some reason you're not doing this, then you should be.
  2. If you are precompiling your assets, make sure you turn on digests. Digests are the long alphanumeric strings that you'll sometime see appended to the end of an asset url. They intelligently cache your static assets since the digest will change if the asset is changed. Digests are turned on by default in the production environment, but if you have a staging environment, you may need to explicitly enable them.
  3. Also, precompiling your assets is pointless if your web server isn't serving them up. With the default Passenger configuration, Apache will serve up static assets without a problem, but if your're running on Nginx it may not work out of the box. Recompiling Nginx with the gzip_static module may be necessary.

Doing these three things should dramatically reduce page load times and give your app a much snappier feel.


Rails 3.1 Asset Pipeline Not Serving Up Images

Posted on 10/04/2011

New features were developed, tests were passing, and everything was running great in the local dev environment.

Then I deployed to the staging server.

WTF? None of the image assets were displaying. The user-uploaded images on S3 were fine, but nothing under assets/images was rendering. It was midnight with a client demo the next morning. I was ready to pull my hair out.

I checked the logs. No errors. The server seemed to be serving up image assets w/o a problem. The logs lied and I knew better.

My first thought; this is what I get for saying I didn't understand people's complaints about the asset pipeline. My second thought; precompile. I rm'd the public/assets directory and ran the precompile rake task. No dice. Still no images.

The staging server was running on Bluebox, so I had hit them up in the support chat. We both poked around and tried a few things, but nothing was working. Then finally one of the support guys found it.

In the staging environment file, this line needed to be changed since we were using Nginx:

config.action_dispatch.x_sendfile_header = "X-Sendfile" # Use 'X-Accel-Redirect' for nginx

Once that was changed and the app was restarted, everything worked as expected.