Recently I was hanging out with some dev bootcamp folks, both students and staff when a a student was struggling with getting their PostgreSQL setup working correctly. I've got a lot of PostgreSQL experience, so I knew it was a pg_hba.conf issue off the bat, but I said this outloud rather than the fix:
"Pull a docker container"
Everyone looked at me like I was speaking Swahili. They asked "What?" so I repeated myself.
More weird looks.
So if you're new at this sort of thing, here's an expectation you should have about your environments outside your laptop: you should be able to throw them away, you shouldn't spend any time caressing and loving them, they should be disposable and you should discard them at will, database included. So why should you spend any time at all working on setting up your development environment to actually install all these things on your laptop when you shouldn't expect to do this outside your laptop.
If it doesn't work, throw it away. Dispose of it with extreme vengence.
Or go ahead. Have some Postgres install in your laptop that holds every development and test DB for every app you've ever worked till you get to the point where you have no idea where the schema line up with projects.
It's far more complicated under the hood, but for the sake of conversation, a docker container is a small linux box that runs inside a linux box or vm. Instead of setting up entire virtual machines for things, with Docker, you just pull the app you need and boom, it's running on your laptop.
So how is this different than a native install?
If it doesn't work? Boom, it's gone -- totally gone. Need to run 20 copies of it in isolation for some reason? No problem. Need to start 20 copies all of a sudden for some reason? You can start 20 copies of the app on your laptop in isolation from each other in under a second. And trash them again. And start them again.
Another plus with working with your app's dependencies as Dockerized containers is that if you build your app in a container, or your app has other dependencies, you can limit network traffic to that particular stack of containers. This means if you're working on seperate projects, you're essentially running the services in isolation like you would be in prod. And you can run different versions of things. And all sorts of other good things.
And here's the swell part I won't cover here: you can actually ship your whole stack to prod as it exists in your laptop if you'd want to.
There's a ton of other plusses. I won't burden you with reading all that.
Use Linux for Rails dev? You're already ahead of the game. If you want to go from zero to running Postgres locally, or redis, memcached, or whatever else it's as simple as:
docker run -d -p 5432:5432 --name postgres -e POSTGRES_PASSWORD=mysecretpassword postgres:9.4.1
Yup. It'll download the image, start a container with that version of postgres with the password as specified there and you're up and running with postgres running on port 5432 of your local box. Start your Rails instance with the DATABASE_URL set as an environmental variable and you have no files to modify, nothing to do.
Want to stop it? Done with it for now? Made some screwed up decision you regret?
docker stop postgres docker rm postgres
Now you've stopped the container and removed any trace of it existing. Alternatively, you could have just stopped it and started it again when you wanted to start working on it again. Removing the container removes the data, stopping the container just stops it from running and preserves your data.
If you aren't running on Linux try boot2docker, which puts a small vm on your machine running linux (it's 23 megs!) so you can run docker containers.
But it's too hard!
Well, first off, I think you're weak if you think this. You should put down the Sublime Text and your frappucino, brew some engeineer class shit coffee and get to using vim and other unix tools. Second, I'm lazy and kind of agree since I don't like to do anything that I can't automate easily. So enter fig.
Fig allows you to set a fig.yml file in the root of your app which will create and maintain all the moving parts your app has as well as link them together. With something as simple as a fig up command, you don't even need to have Ruby installed to get to work. The fig.yml file, as you may have guessed is a yaml file defines your app and all the moving parts around it like Postgres, etc., and it ties them all together for you. So go check out the link, it's super easy to start with and works with boot2docker as well as native installations of things.
That's it for now. Tweet at me if you want to know more or where else to look.