Rails Quick Tip - Use Private Debugging Aliases

Debugging in Rails app is represented by a rubber duck. Photo by Timothy Dykes on Unsplash

I don’t like to type much. Even minor improvements in your debugging workflow are likely to accumulate into huge keystrokes savings over time. In this blog post, I’ll describe a simple way to add debugging shortcuts to the project without modifying the codebase shared with other team members.

My aliases good, your aliases bad

In one of my previous posts, I described a way to improve your productivity by using Rails console aliases. The downside of the described approach is that the .irbrc file is usually committed to the repository.

If you’re working in a larger team, it might be challenging to agree on a definitive list of aliases that everyone finds useful. So instead of starting code review battles on which aliases are worth committing to the shared repo, you can keep your private aliases collection.

In theory, you could leverage an ~/.irbrc file to define them. But, the problem is that if you start an IRB session outside of the context of a Rails project, any of the calls to the custom classes or included gems would break. Also, it does not seem correct to include per-project customizations in global dotfiles.

Instead, you can customize a project without modifying its shared source code. You’ll have to configure git to parse the file with a list of entries that should never be committed to any of the local repositories:


  excludesfile = ~/.gitignore_global

You can now define any file to be excluded from git commits:



I use a Rails initializer file to define my custom aliases and local tweaks. Files from config/initializers/ are called when the app’s models have already been loaded so you can interact with all the app’s classes:


User.filter_attributes = []

def me
  User.find_by(email: "[email protected]")

def pr1
  Project.find_by(slug: "my-debug-project")

def pr2
  Project.find_by(slug: "my-other-debug-project")

def refr

# ...
Sample project-specific aliases and tweaks

I usually keep a dozen of three max four-letters aliases per project. They represent objects and methods I often interact with when debugging locally. Smuggling such global methods past code review would probably not be possible, hence the private aliases workaround.


I regularly inspect the list of my Rails console commands for potential alias candidates using the lazyme gem. Correctly configured aliases can save you hundreds of keystrokes in just a single day of work. Your fingers will appreciate it.

Back to index