You can utilize this feature by calling git blame with --ignore-rev or --ignore-revs-file flag, or set blame.ignoreRevsFile config. There’s a good blog post by Micheal Heap about this feature here:

A better `git blame` with `--ignore-rev`

So, the reason I want to write about this feature despite it’s already available for a while now is that GitHub now officially supports it!

Ignore commits in the blame view (Beta) | GitHub Changelog

You can now add a .git-blame-ignore-revs file to the root of your repository, and GitHub will now exclude those revisions from the blame view.

You can see an example usage of this feature on Ruby’s Git repository, where they use this feature to exclude a commit that changes the whitespaces of the whole project.

ruby/.git-blame-ignore-revs at 55c771c302f94f1d1d95bf41b42459b4d2d1c337 · ruby/ruby

If you ever thinking about cleaning up the code style of your repositories so they would be consistent, I think now is the right time!

Ignore Git revisions in git blame was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The easiest way to do this is to call ActiveRecord::Base.connection_db_config from the console:

> ActiveRecord::Base.connection_db_config
=> 
#<ActiveRecord::DatabaseConfigurations::UrlConfig:0x123456
 @configuration_hash={...},
 @env_name="production",
 @name="main",
 @url="...">

You can see right away that we’re connecting to the main writer database.

If you want to switch your current database for the remaining of your session, you can use ActiveRecord::Base.connecting_to:

> ActiveRecord::Base.connecting_to(role: :reading)
=> [{:role=>:reading, :shard=>:default, :prevent_writes=>true, :klasses=>[ActiveRecord::Base]}]
> ActiveRecord::Base.connection_db_config.name
=> "reader"

Confirm current database connection in Rails console was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

After a quick Googling for “vim magic comment”, I found this amazing tips:

Modeline magic

This is exactly what I wanted. So, I just added this on the top of my file:

# vim: set filetype=bash:

And Voilà! Custom syntax highlight for this particular file. 💯

Vim modeline magic was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

def self.run(*args, &block)
  new.run(*args, &block)
end

With the addition of keyword arguments in Ruby 2.0, things have gotten a bit crazier since you may want to pass all the keyword arguments to the underlying method as well. So, you’d want to update your method above to:

def self.run(*args, **opts, &block)
  new.run(*args, **opts, &block)
end

However, starting from Ruby 2.7, you no longer need to do that as you can now use the new “forward everything” syntax. So, you can now rewrite the code above to look like this:

def self.run(...)
  new.run(...)
end

… which is much cleaner than before!

If you would like to learn more about the development of this new syntax, you can look at the Redmine issue. Special thanks to Jean Boussier for submitting this pull request to Rails so I learned that this feature exist in Ruby 2.7.

Writing a pass-through method, Ruby 2.7 edition was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

 > RUBY_VERSION
 => "3.1.2" 
 > require "benchmark/ips"
 => true 
 > Benchmark.ips do |x|
 >   x.report("fetch") { {}.fetch(:non_existance, true) }
 >   x.report("[] ||") { {}[:non_existance] || true }
 > end; nil
Warming up --------------------------------------
               fetch     1.480M i/100ms
               [] ||     1.394M i/100ms
Calculating -------------------------------------
               fetch     14.812M (± 0.3%) i/s -     75.460M in   5.094490s
               [] ||     13.898M (± 0.9%) i/s -     69.715M in   5.016568s
 => nil 

So, you should be fine using #fetch with default value anywhere now!

The original version of this blog post was written around Ruby 2.6 and stated that the only reason you want to use #fetch is when you want your code to raise KeyError when a key is not found. However, the Ruby Core team has since updated the performance of Hash#fetch and fixed the problem. Hence, I updated this blog post to reflect the change.

fetch vs. [] || for default value in Ruby was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years back, Rails 4.1.0 introducedraise_on_missing_translations flag for Action View. Setting this key to true in your environment configuration will make Rails raises exception if you have a missing translation keys:

# In config/environments/test.rb (and development.rb)
config.action_view.raise_on_missing_translations = true

However, one thing that people may have missed is that this configuration only applies to Rails views. If you call I18n.translate or I18n.t directly from your specs, or when you build a JSON output, Rails won’t raise any exception at all.

So, instead, you will want to directly set an I18n exception handler like this:

# config/initializers/i18n.rb
if Rails.env.in?(%(development test))
  I18n.exception_handler = Proc.new do |exception, *_|
    raise exception.to_exception
  end
end

Missing translations keys — Gotta Catch ’Em All was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s a simple benchmark:

require "benchmark/ips"

def option_hash(options = {}); end
def double_splat(**options); end

Benchmark.ips do |x|
  x.report("option_hash") { option_hash(foo: 1, bar: 2) }
  x.report("double_splat") { double_splat(foo: 1, bar: 2) }
end

… and result (bigger number is better):

Warming up --------------------------------------
         option_hash   123.232k i/100ms
        double_splat    61.146k i/100ms
Calculating -------------------------------------
         option_hash      1.798M (± 3.6%) i/s -      8.996M in   5.011461s
        double_splat    708.545k (± 5.4%) i/s -      3.546M in   5.020927s

What’s the optimal usage of double splat?

You should use double splat in the method definition only if that method defines optional arguments.

# This is a valid use case since otherwise Ruby will set a hash
# in argument name `optional`.
def valid_use_of_double_splat(optional = nil, **options)

# Both of these use case can just use `options = {}` 
def perform_delivery(recipient:, **options)
def associate_user(user, **options)

Think twice before using double splat in Ruby was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Added time helper method `freeze_time` which is an alias for `travel_to Time.now` by prathamesh-sonpatki · Pull Request #29681 · rails/rails

So, in Rails 5.2, instead of you doing:

travel_to(Time.current) do
  # ...
end

You can actually use this new freeze_time helper:

freeze_time do
  # ...
end

Internally, both of these methods are just mocking Time.current or Time.now to return given time, essentially “freezing the time”. I’m never a fan of travel_to(current_time) as I feel that it reads weird. I’m going to just use freeze_time from now on if the situation allows.

A new helper to freeze time in Rails 5.2 was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

$ rails routes --expanded
--[ Route 1 ]-------------------------------------------------------
Prefix            | high_scores
Verb              | GET
URI               | /high_scores(.:format)
Controller#Action | high_scores#index
--[ Route 2 ]-------------------------------------------------------
Prefix            | new_high_score
Verb              | GET
URI               | /high_scores/new(.:format)
Controller#Action | high_scores#new
--[ Route 3 ]-------------------------------------------------------
Prefix            | blog
Verb              |
URI               | /blog
Controller#Action | Blog::Engine

[ Routes for Blog::Engine ]
--[ Route 1 ]-------------------------------------------------------
Prefix            | cart
Verb              | GET
URI               | /cart(.:format)
Controller#Action | cart#show

I think this is very useful for when you have a lot of complex routes and it’s hard to see unless you have a very huge display.

You can find more details in the pull request from Benoit Tigeot here:

Add "rails routes --expanded" mode by benoittgt · Pull Request #32130 · rails/rails

Expanded rails routes in Rails 6.0 was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

> User.pluck(:id)
#=> [1, 2, 3]

But what if you need just the first value from the result? You will probably have to use .limit and #first:

> User.limit(1).pluck(:id).first
#=> 1

Now, starting from Rails 6.0, you will be able to use .pick to pick out a single value. It also accepts multiple values, so you can get value from multiple columns at the same time:

> User.pick(:id)
#=> 1
> User.pick(:id, :username)
#=> [1, "sikachu"]

However, you should note that this code is just a shorthand for limit(1).pluck(*column_names).first. It does not guaranteed the first value ordered by any column, so you may need to do .order(:id).pick(___) if you really want the first row of your result set.

You can look at the actual patch in this PR from DHH:

Add Relation#pick as short-hand for single-value plucks by dhh · Pull Request #31941 · rails/rails

Relation.pick in Rails 6.0 was originally published in Sikachu's Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.