The bin/dev script Ruby on Rails ships with, if you for example init the app with --css=tailwind or --css=bootstrap is great. It comes with auto-generated Procfile that will launch the web server and the Tailwind CSS (or other) preprocessors. In addition bin/dev will install the foreman gem if it does not exist on your system.

At some point however, you’ll want to run multiple Rails applications on your developer machine. Doing that with localhost:3000 will get annoying at some point (cookie sharing, changing ports, everyone in the team handling it differently, no HTTPS to test with…).

puma-dev has been around for a long time to solve this. However while it takes care of running the web server part for you (in the background), you still want to see the logs, run your CSS (or JS) preprocessor or compiler, job workers, etc. I figured out it’s simply about adjusting the Procfile and bin/dev slightly and one can use the familiar approach in conjunction with all the puma-dev features.

This is what I do:

My Procfile.dev looks like this:

web: tail -f log/development.log
css: bin/rails tailwindcss:watch

The change is in the web: stanza. Instead of launching puma server, we simply tail the logs, as puma will be run by puma-dev in the background for you, as soon as you visit your local .test domain.

My bin/dev looks like this:

#!/usr/bin/env bash

if ! command -v foreman &> /dev/null
then
  echo "Installing foreman..."
  gem install foreman
fi

if ! command -v puma-dev &> /dev/null
then
  echo "Installing puma-dev..."
  brew install puma/puma/puma-dev
  echo ""
  echo "To finish puma-dev setup run:"
  echo "sudo puma-dev -setup"
  echo "puma-dev -install"
  echo "puma-dev link -n myapp ."
  echo ""
fi

foreman start -f Procfile.dev

I’ve added a section that installs puma-dev (if your team is using Homebrew) and prints out instructions on how to complete the setup.

For your use case, simple replace “myapp” above with the name of your app.

This feels like sticking to the Rails way and is easily extensible if you also want to launch other services in development, like job workers, by simply adding a stanza in the Procfile.dev. Neat.

I just learned about rake db:system:change task that Rails provides, to speed up switching between different database engines. If you’re experimenting with something, or benchmarking things, this is super useful.

I had a simple PostgreSQL app and running rake db:system:change --to=sqlite3 and afterwards rake db:setup got me going with my task in seconds.

Small detail I noticed, rake -T which should list all available tasks, does not show anything about db:system for some reason.

It’s been a while since I reviewed the documentation for rails new console command. There are a few useful features that I didn’t know about:

Most of the times, for database engine, PostgreSQL is my choice. This is easily accomplished with the -d switch, but even more convenient is adding this as a preset to your environment, using the .railsrc dotfile. Configuring such on your system will allow you to just stick to rails new appname without having to add switches.

The second useful thing I didn’t know exists is the Rails Application Templates which makes it faster to start new Rails applications with the same set of gems and configuration that you might be reusing across your apps.

Recently I was working on a Rails application on Heroku living behind a reverse proxy. This application serves requests coming to a specific folder on the target domain. For it to correctly generate full URLs, you have to somehow tell this app the hostname you want it to use. In Rails, you can configure a hostname in the environment config file, but that’s a static value, which has to be maintained and changed per environment. Also it does not work well if you want to access the application from multiple domains.

It’s much better to be able to set something up on the proxy itself. For this reason the X-Forwarded-Host HTTP header exists. Rails–being a good web citizen–supports it out of the box.

Before I learned about this header, I even implemented my own middleware to deal with this issue and a custom header. I was able to dump that extra code once I stumbled at this header.