shakycode

I agree, the guide should be updated to it's more clear. There's also another way to create a database user manually.

sudo su - postgres
psql
Once you're in Postgres issue this command:
create USER databaseuser with password 'yourpassword';

Where databaseuser is the name of the user you want to create and yourpassword is the password you'd like to assign.

That's how I usually do it when spinning up a new instance.

Peter, is this in development or in production? If it's Linux and your on production you can do a service postgresql status to see if it it's running or a ps aux | grep -i post to see if there are any Postgres processes running.

As Chris mentioned, you'd be better off moving to a shared database such as MySQL or PostgreSQL. This way the data persists in production. All you need to do is configure the database information and connector in your database.yml file. sqlite is fine for small apps and playing around in development but I'd highly recommend moving to Postgres or the like. It's also really helpful to have the same database engine in development as you do in production. That's why I run Postgres locally and in production.

You can move the production.sqlite3 file into the app/shared folder and symlink it, but you're better off in the long run moving to a real database.

I'm with you on using iTerm2. It's pretty, and has better functionality than the standard OSX terminal. ZSH is good, but I'm still a Bash guy myself. Old habits and all.

Did you install Postgres via homebrew on your development machine? Or is this in production?

If you installed it locally (especially in OSX) you can access the Postgres cli by simply typing psql and it will use your current credentials to log you into the cli. From there you can create/delete/modify databases/roles/etc.

Glad you found it. Here's a protip. If you ever want to test out different code, queries, or manipulate data without permanently writing to the database use the sandbox option.

RAILS_ENV=production bundle exec rails c --sandbox

This will give you a Rails console where you can test out your code and manipulate data in realtime to see what the effects are. Once you exit the console, all changes are rolledback so it's a really safe way to play with production data before you manipulate anything permanently.

+1 on using Passenger over Unicorn. I've tried both but I prefer Passenger. Plus it's bundled natively with Nginx which is nice. Configuration takes 30 seconds and you're done. And Chris is right, benchmarks point out that it performs just as good as Unicorn. There is some tuning you can do to make it run even better. If you need some help let me know, I'm very familiar with Nginx/Passenger and use it on all my apps.

So the problem wasn't with Amazon S3 but was an issue with rmagick/ImageMagick?

I'm using CarrierWave and looking to do auto-resize of images on upload. Is there any configuration that needs to happen in production after you install ImageMagick using apt? I'd really like to get the auto-resize functionality working in my app.

Glad you got the problem solved.