1 of 31

What do you call a Pokemon who likes to code?

A GEEK-achu!

Emily Giurleo • WNB.rb

*

* I didn’t write that joke

**

** This talk isn’t about Pokemon

2 of 31

upgrading ruby gems

what to do when

v

^

causes an error in your application

Emily Giurleo • WNB.rb

3 of 31

Emily Giurleo • WNB.rb

Warning: Using the last argument as keyword parameters is deprecated;

maybe ** should be added to the call

deprecation warning

4 of 31

you encounter when upgrading your gems, and how to fix them

Emily Giurleo • WNB.rb, March 2021

5 of 31

Nottabug�

The breaking change with a heart of gold

Googlit�

The one everyone knows about

Didjuread�

The one you should have known about

Brokagem�

The dependency devil

Ohshoot�

The actual bug

Emily Giurleo • WNB.rb

6 of 31

The one everyone knows about

Characteristics:

Well-documented in the gem release notes

Strongest move:

None :(

Least effective against:

Google searches

Googlit

Emily Giurleo • WNB.rb

7 of 31

The one you should have known about

Characteristics:

There was a deprecation warning about it in the last version

Strongest move:

Hide (amongst other unread warnings)

Least effective against:

Developers who read deprecation warnings

Didjuread

Emily Giurleo • WNB.rb

8 of 31

def validate(password, strict: false)

...

end

validate(‘12345’, { strict: true })

warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call

ArgumentError (wrong number of arguments (given 2, expected 1; required keyword: strict))

Emily Giurleo • WNB.rb

Ruby 2.7

Ruby 3.0

A great example that could be used for either of these types is the keyword argument change in Ruby 3.0 and Ruby 2.7.

Let’s say you wrote a method that validates a user’s password. It takes two arguments, a password, and then a keyword argument called strict that decides whether or not to use the strict validation rules.

In versions of Ruby prior to 2.7, you could call this method like this, by passing in a Hash as the final argument, which contains the keyword. However, this behavior changed in Ruby 2.7, which added a deprecation warning stating that passing keyword arguments as a hash in the last parameter was deprecated.

Then, in Ruby 3, this functionality was removed altogether, and trying to pass a Hash for keyword arguments now causes an error.

Did I catch all of these deprecation warnings before upgrading to Ruby 3? No. There were definitely errors in our application after I upgraded to Ruby 3 that I hadn't caught before. However, everyone in the Ruby community has been talking about this error for over a year, so it was pretty easy to Google and figure out the solution.

9 of 31

You grew to Lvl 2!

New move: Google search

A good first step!

New move: Read deprecation warning

Eliminate deprecation warnings now instead of debugging errors later.

Emily Giurleo • WNB.rb

10 of 31

The dependency devil

Characteristics:

Upgrading one gem breaks a different gem

Strongest move:

“Well, it works on my machine”

Least effective against:

Responsive gem maintainers
Well-maintained alternative gems
Temporary code patches

Brokagem

Emily Giurleo • WNB.rb

11 of 31

fixture_file_upload

rspec-rails

Emily Giurleo • WNB.rb

NoMethodError:

undefined method `file_fixture_path' for RSpec::Rails::FixtureFileUploadSupport

::RailsFixtureFileWrapper:Class

Did you mean? fixture_path

12 of 31

Wait it out

Write patch

Switch gems

Emily Giurleo • WNB.rb

13 of 31

You used wait it out!

Wait for gem maintainers to fix the issue and release a new version.

Most effective when:

Upgrade isn’t urgent
Gem is actively maintained

Benefits:

You can focus on other work while you wait for this issue to be resolved

Emily Giurleo • WNB.rb

14 of 31

You used write patch!

Make a change in your application to fix the broken gem until a new version is released.

Most effective when:

Error is small/contained
Gem is actively maintained

Benefits:

You can finish the upgrade quickly, and easily remove your custom code once the gem is fixed.

Emily Giurleo • WNB.rb

15 of 31

You used switch gems!

Switch to a different gem with the same features.

Most effective when:

Gem is NOT maintained
There are well-maintained alternatives

Benefits:

It can be a lot of work to switch between two gems, but it will be less work than continuously fixing issues with an unmaintained gem.

Emily Giurleo • WNB.rb

16 of 31

def file_fixture_upload(path, mime_type = nil, binary = false)

...

[25 more lines of code I didn’t need]

...

Rack::Test::UploadedFile.new(path, mime_type, binary)

end

Emily Giurleo • WNB.rb

17 of 31

You grew to Lvl 3!

New move: Wait it out

Focus on other work while a gem is being fixed.

New move: Write patch

Temporarily fix the error in your application while you wait for a release.

New move: Switch gems

Switch to a different, well-maintained gem with the same features.

Emily Giurleo • WNB.rb

18 of 31

The breaking change (with a heart of gold)

Characteristics:

Technically, it’s a breaking change in a minor version upgrade, but it’s for a good reason!

Strongest move:

Imitate (bug type)

Least effective against:

Descriptive issues with failing tests

Nottabug

Emily Giurleo • WNB.rb

19 of 31

account

.contacts

.where(id: [])

.pluck(‘count(id)’, ‘sum(ask_amount)’)

#=> [[0, nil]]

Rails 6.0

#=> []

Rails 6.1

Let me give you an example.

Our Rails application has a method that performs multiple aggregations with one query, using the ActiveRecord pluck method. Now, I would say this is an edge case for using the pluck method, and the behavior of this method has always been kind of weird.

For example, before the upgrade, in Rails 6.0, if you’re performing the pluck method on an empty query result, it would return a nested array of 0’s and nils. Why did it behave this way? I can’t tell you, but I can tell you that we had written our application to account for this behavior.

However, when we upgraded to Rails 6.1, this behavior changed. Instead of returning a nested array of 0’s and nils, this method started returning an empty array. Of course, this broke our app, and I couldn’t find any mention of the change anywhere on the internet.

This seemed like a bug… but was it?

20 of 31

You used write issue!

Open an issue on the gem’s GitHub repository.

Most effective when:

You describe expected behavior vs experienced behavior
Issue includes a failing test
You ask nicely :-)

Benefits:

You save yourself time by asking for help from the people who understand the gem best.

Emily Giurleo • WNB.rb

21 of 31

Emily Giurleo • WNB.rb

22 of 31

You grew to Lvl 4!

New move: Write issue

Help the gem maintainers help you.

Emily Giurleo • WNB.rb

23 of 31

The Bug

Characteristics:

Oh, shoot. It’s a bug in the gem.

Strongest move:

Sow doubt

Least effective against:

Source diving

Ohshoot

Emily Giurleo • WNB.rb

24 of 31

calculate_fees(1000) #=> 3500

Ruby 2.7

Emily Giurleo • WNB.rb

Ruby 3.0

calculate_fees(1000) #=> 3501

25 of 31

You used source dive!

Dig into a gem’s source code to find the cause of the bug.

Most effective when:

You have tried literally everything else.

Benefits:

Once you find out what’s causing the bug, you can use open issue!

Emily Giurleo • WNB.rb

26 of 31

def calculate_fees(amount_in_dollars)

byebug

...

end

Emily Giurleo • WNB.rb

27 of 31

Our application

Monetize gem

Money gem

28 of 31

bundle open money

Emily Giurleo • WNB.rb

29 of 31

require 'bigdecimal/util'

num = 98.00000000000001.to_d

num.round(0, 1)

=> 0.99e2

Emily Giurleo • WNB.rb

30 of 31

You grew to Lvl 5!

New move: Source dive

Become one with the code.

Emily Giurleo • WNB.rb

31 of 31

Nottabug�

The breaking change with a heart of gold

Googlit�

The one everyone knows about

Didjuread�

The one you should have known about

Brokagem�

The dependency devil

Ohshoot�

The actual bug

Emily Giurleo • WNB.rb