Additional Rails setup

When we approach application development we are probably all familiar with DRY - Don't Repeat Yourself. This is a good thing to learn in everything you do in life. If we're going to do things time and time again let's try and make it as efficient as possible. And not to mention let's make our life easier so we don't have to remember everything.

There have been countless times this week I've checked out a new project.

bundle install
bundle exec rake db:drop
bundle exec rake db:create
bundle exec rake db:migrate
bundle exec rake db:seed
RAILS_ENV=test bundle exec rake db:schema:load

For a start there's a great way to reduce rake tasks down

bundle install
bundle exec environment rake db:{drop,create,migrate,seed}
RAILS_ENV=test rake db:schema:load

That's still four tasks reduced to one, they're all run from our shell so let's just put it in a ./bin/setup file

#!/bin/bash

bundle install
bundle exec environment rake db:{drop,create,migrate,seed}
RAILS_ENV=test rake db:schema:load

Make sure it's executable

chmod 750 ./bin/setup
# then we can run it with
./bin/setup

I tend to put scripts into ./bin/ to just speed up even just booting a rails server. What's wrong with

rails s

Well, nothing. Unless you're running 5 different applications on localhost at the same time. They can't all share port 3000. If you're working on a project where many applications interact with one another. Or your focus changes multiple times a day, which is often does. So how about ./bin/server

#!/bin.bash
rails server -b 0.0.0.0 --port=8042

Just be to sure to assign a valid port to each of your applications to save you clashing. Well, since we've done that we're now going to have to remember all the port numbers for each of our apps. No, let's refactor that. That's what they invented DNS for.

Let's install puma-dev. https://github.com/puma/puma-dev

brew install puma-dev
sudo puma-dev -setup
puma-dev -install

puma-dev is great. It effectively hijacks your local machine's DNS resolver for the .test Top Level Domain. Looks up the hostname against the existing files in your ~/.puma-dev/ directory. In my case it's something like.

~/.puma-dev/iplayred

8000

~/.puma-dev/robl

8001

Then I can visit https://iplayred.test or https://robl.test and it will load my application. Your web browser makes the request, and looks up your hostname, determines it is for the local machine and then Puma-dev running on port 80 and 443 proxy and forwards requests to your application on localhost port 'whatever was in my config' and it also manages SSL - which is the icing on the cake if you're looking to do any development testing against anything that requires SSL e.g. OAuth workflow redirect urls or say Rails apps that are SSL Only.

I could at this point write a script to dump these scripts into a new application based on what ports are already allocated, insert all my setup scripts so I don't have to do this again and again. One day I will.