Today I Learned

5 posts by bryanmacdiarmid

Force push safely using --force-with-lease

We periodically force push feature branches when we rebase them.

To do this safely, I first check manually to see if my pair has pushed any commits I don't yet have in my local branch.

But there's an easier and safer way to do this. The --force-with-lease option will fail if there are upstream changes not yet merged.

It will work smoothly for standard rebasing situations, but protect against any inadvertent destructive force pushes.

Thanks to Jason K for sharing this tip with me!

Chrome: Inspecting DOM elements that require focus

Using Chrome Dev Tools, I occasionally want to inspect an element that requires focus - for example, inspecting a selected date in a date selector.

Problem

As soon as I click the dev tools window, the element loses focus and I can no longer inspect in with the desired state.

Undesirable solution

On occasion when I've run into this scenario, I've placed a breakpoint or debugger statement in the JavaScript function that would be called when focus is lost. The problem with this is that it takes time and I need to locate the appropriate place in code.

Better solution

When in the desired state - for example, with the current date selected - pressing F8 will pause JavaScript execution. I can then inspect the DOM in the desired state.

bundle update --conservative

Let's say you want to update the gem foo. After running bundle update foo you look at your gemfile.lock and find that not only was foo updated, but so were many of its dependencies. You also notice that many of these dependency updates weren't necessary, as the previously installed versions were compatible with the new version of foo.

The default bundle update foo behaviour will unlock and update all dependencies of foo.

If you don't want to update these dependencies unnecessarily, one solution is to add the current versions to your gemfile.lock.

However, an easier way to prevent the updating of shared dependencies is to use bundler's new --conservative flag.

Fetch: two approaches for setting a default value

When using #fetch to assign a default value, the default can be passed either as an argument or as a block.

What are the implications for choosing one approach over the other?

# Option 1: block
setting = settings.fetch('key') { default_setting }

#Option 2: argument
setting = settings.fetch('key', default_setting)

When the default value is passed as a block, it is only evaluated when needed (lazy evaluation).

The argument approach could lead to serious performance issues if the default is an expensive operation.

Quick switching from a class to spec

RubyMine will attempt to open the relevant spec file for a class you're working with when you use the keyboard shortcut CMD + SHIFT + T.