@brentmc79

My wife was out of town and I wasn't in the mood for Xbox, so I thought I'd resume work on a personal project that I hadn't touched in a while. I cd'd into the project directory, started the rails server, and hit up localhost:3000 in Chrome. That's when I was hit with this lovely little gem:

psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Ahh, fuck. I knew, or at least I thought I knew, that Postgres was running. I had a launch agent set up for it, so it should be running. I consulted the process list...

ps aux | grep postgres

...which returned nothing. Well shit. I tried a quick reboot. No luck. Still not running. Tried to start it manually with:

$ pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
pg_ctl: another server might be running; trying to start server anyway
server starting

Sure it says "server starting", but what does that really mean? Nothing evidently. After a bit more console hackery and rabid googling, I determined that Postgres was probably in a bad state after one of several recent kernel panics as a result of simultaneously using POW and Cisco's AnyConnect VPN client. This would explain why there was a postmaster pid file, but Postgres wasn't running.

Google told me that my transaction logs were probably in shit-shape, which meant they would need to be cleaned up using pg_resetxlog like so:

$ pg_resetxlog /usr/local/var/postgres
pg_resetxlog: lock file "/usr/local/var/postgres/postmaster.pid" exists
Is a server running?  If not, delete the lock file and try again.
$ rm /usr/local/var/postgres/postmaster.pid
$ pg_resetxlog /usr/local/var/postgres
The database server was not shut down cleanly.
Resetting the transaction log might cause data to be lost.
If you want to proceed anyway, use -f to force reset.
$ pg_resetxlog -f /usr/local/var/postgres
Transaction log reset

Finally, after a manual start up:

$ pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
server starting

Things were in good working order, and I was able start up the dbconsole and connect without a problem.

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.

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.

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.