DEV Community: Alexander Budchanov

Rails 5.2 changes in callbacks

Alexander Budchanov — Tue, 17 Sep 2019 14:16:02 +0000

In version 5.1 you may see deprecation warnings in after_save callbacks (related to changes in ActiveRecord::Dirty module).
But since 5.2 these changes were applied.

For examples, I will use Rails 4.2.11 and Rails 5.2.3 and model User with email attribute. Let's do:

u = User.new(email: 'old@domain.com')
u.save
u.email = 'new@domain.com'
u.save

and look at after_save callback in time of last save.

1. attribute_changed?

Rails 4

> email_changed?
=> true

Rails 5.2

> email_changed?
=> false

but you can use saved_changes?

> saved_change_to_email?
=> true

2. changed?

Rails 4

> changed?
=> true

Rails 5.2

> changed?
=> false

but you can use saved_changes?

> saved_changes?
=> true

3. changes

Rails 4

> changes
=> {"email"=>["old@domain.com", "new@domain.com"]}

Rails 5.2

> changes
=> {}

but you can use saved_changes

> saved_changes
=> {"email"=>["old@domain.com", "new@domain.com"]}

4. previous_changes

Rails 4

> previous_changes
=> {"email"=>[nil, "old@domain.com"]}

Rails 5.2
Now, this method returns the changes that were just saved (like saved_changes).

> previous_changes
=> {"email"=>["old@domain.com", "new@domain.com"]}

this method has no replacement.

Safe Navigation vs Try in Rails (Part 2: Performance)

Alexander Budchanov — Wed, 03 Jul 2019 07:06:18 +0000

This Note is an extension of Safe Navigation vs Try in Rails (Part 1: Basic Differences)

Method try() comes from Active Support component of Ruby on Rails. Safe Navigation Operator is Ruby native feature.

Let's check performance!

require 'benchmark'

class Foo
  attr_accessor :name
end

foo = Foo.new
bar = nil

Benchmark.bm(35) do |x|
  x.report('Successful access: try(...): ')         { 1_000_000.times { foo.try(:name) } }
  x.report('Successful access: &.: ')               { 1_000_000.times { foo&.name } }
  x.report('Successful access: control sample: ')   { 1_000_000.times { foo.name } }
  x.report('Failed access: try(...): ')             { 1_000_000.times { bar.try(:nonexistent) } }
  x.report('Failed access: safe navigation: ')      { 1_000_000.times { bar&.nonexistent } }
end;nil

                                          user     system      total        real
Successful access: try(...):          0.498216   0.005748   0.503964 (  0.530010)
Successful access: &.:                0.062146   0.000943   0.063089 (  0.069714)
Successful access: control sample:    0.062411   0.001098   0.063509 (  0.069603)
Failed access: try(...):              0.172535   0.004374   0.176909 (  0.194386)
Failed access: safe navigation:       0.054141   0.001029   0.055170 (  0.065502)

Safe navigation is about 7 times faster than method try() for successful navigation and 3 times faster for unsuccessful.

Safe Navigation vs Try in Rails (Part 1: Basic Differences)

Alexander Budchanov — Wed, 03 Jul 2019 07:06:10 +0000

There are some ways of preventing errors like undefined method for nil:NilClass.

Rails Method try(...)
Safe Navigation Operator (&.)
Logical operator && (AND)

Here is how these options look like:

user.try(:company).try(:name)

user&.company&.name

user && user.company && user.company.name

But there are some differences.

1. If model User hasn't relation compppany (it may be just a typo or renamed model relation/attribute):

user.try(:compppany).try(:name)
=> nil

You will receive nil and never been know about this typo.

user&.compppany&.name
=> NoMethodError: undefined method `compppany' for #<User:0x000000123456789>

and

user && user.compppany && user.compppany.name
=> NoMethodError: undefined method `compppany' for #<User:0x000000123456789>

Looks better!

2. If model User has relation company, but company is false. User.new(company: false):

user.try(:company).try(:name)
=> nil

user&.company&.name
=> NoMethodError: undefined method `name' for false:FalseClass

Safe Navigation recognized false. Awesome!

user && user.company && user.company.name
=> false

Hmmm, it does not look like we want.

3. Performance
Read the second part Safe Navigation vs Try in Rails (Part 2: Performance)

Force Downloading of File instead of Opening in Browser

Alexander Budchanov — Wed, 03 Jul 2019 07:06:01 +0000

When you go through the link, some files will be opened in the browser. Such behavior is typical for some content types (e.g., images, pdf, etc.)

However, you can force file downloading instead of opening when an user clicks on the link though.

1st way (frontend):

HTML attribute download allows you to do this.

<a href="/public/report.pdf" download="stat_report">

If the value of the attribute is omitted, the original filename would be used.
However, be careful. This attribute isn’t supported in some old browsers without HTML5 support.
Renaming does not work if the given file stored on another host.

2nd way (backend):

You can set HTTP header Content-disposition.

for Nginx:

location ~* /public/(.+\.pdf)$ {
    add_header Content-disposition "attachment; filename=$1";
}

for Apache:

<IfModule mod_headers.c>
    <FilesMatch "\.(?i:pdf)$">
        ForceType application/octet-stream
        Header set Content-Disposition "attachment"
    </FilesMatch>
</IfModule>

Sidekiq Stats in Rails

Alexander Budchanov — Wed, 03 Jul 2019 07:05:53 +0000

If you use Sidekiq in your Rails project, you can watch tasks statistics through the web interface. Usually, you can find it here: https://yourdomain.com**/sidekiq** (but in your project path may be different).
If you don't have access there, you can get the same data in Rails console.

To get statistics (number of tasks) by each queue:

Sidekiq::Stats.new.queues
=> {"local_cache"=>0, "default"=>0, "ts_delta"=>0, "mailchimp"=>0, "recorder"=>0}

Global statistics are available this way:

Sidekiq::Stats.new.fetch_stats!
=> {:processed=>61390,
 :failed=>3220,
 :scheduled_size=>0,
 :retry_size=>0,
 :dead_size=>4,
 :processes_size=>1,
 :default_queue_latency=>0,
 :workers_size=>0,
 :enqueued=>0}

The same stats are available separately:

stats = Sidekiq::Stats.new
stats.processed # number of processed tasks
stats.failed # number of failed tasks
stats.enqueued # number of enqueued tasks

and etc.

Also Sidekiq::Stats allows to look historical data. You can specify period. Something like:

s = Sidekiq::Stats::History.new(2, Date.parse('2019-02-05'))

first argument: number of days,
second argument: date until which return stats (default value is today and can be omitted)

s.processed
=> {"2019-02-05"=>0, "2019-02-04"=>0}
s.failed
=> {"2019-02-05"=>0, "2019-02-04"=>0}

Keep clean your git repos!

Alexander Budchanov — Wed, 03 Jul 2019 07:05:24 +0000

Many developers don't keep their local repositories clean. There is a way how to automate it though. Let's look at a few useful commands:

To clean refs to nonexistent branches in the remote:

$ git fetch --prune

--prune before fetching, remove any remote-tracking references that no longer exist on the remote.

To estimate how many branches merged into dev:

$ git branch --merged dev | wc -l

--merged option can filter list to branches that you have merged into the given branch. Squash and rebase merges usually aren't detected by --merged.

List of branches merged into dev:

$ git branch --merged dev

List of remote branches merged into dev:

$ git branch --merged dev --remote

If you are courageous then:

$ git branch --merged dev | egrep -v "(^\*|master|dev)" | xargs git branch -d

It removes all local branches that merged into dev (except dev and master).
This is a potentially damaging operation. It can delete branches actually needed.
So if you use the different approach to work with Git, you could remove some of branches manually instead. I hope you do not store all old branches, do you?