Today I Learned

Giant Monkeys Learning

6 posts about #Rails

rspec --profile gives a performance overview

Using --profile in your rspec command line allows you to see the slowest 10 examples in your test suite, along with a speed benchmark.

For more, see:- https://rspec.info/features/3-13/rspec-core/configuration/profile/

Example:

$ bundle exec rspec ./path/to/my/test.rb:90

Top 10 slowest examples (54.21 seconds, 73.1% of total time):

  # displays list of examples here with benchmark

Finished in 1 minute 7.22 seconds

yes and no are booleans when used as keys in YAML

Whilst fixing a strange bug, I learnt today that yes and no are actually boolean key values in yaml.

E.g. We take this line of ruby:

booking.feedback_done ? I18n.t("billing.billing_public_tours.yes") : I18n.t("billing.billing_public_tours.no"),

calling #feedback_done should simply return a boolean value, so all looks okay right?

[2] pry(#<#<Class:0x0000000162290e60>>)> booking.feedback_done ? true : false
=> false

If we take a look at our YAML:

    billing_public_tours:
      ...
      yes: "Ja"
      no: "Nein"

Our translations look correctly configured. So why do we get this?

[1] pry(#<#<Class:0x0000000162290e60>>)> booking.feedback_done ? I18n.t("billing.billing_public_tours.yes") : I18n.t("billing.billing_public_tours.no")
=> "Translation missing: de.billing.billing_public_tours.no"

Because Booleans are formatted as English words in YAML

If we wrap them in quotes:

    billing_public_tours:
      ...
      "yes": "Ja"
      "no": "Nein"

Our code will now work:

[1] pry(#<#<Class:0x000000016dff30c0>>)> booking.feedback_done ? I18n.t("billing.billing_public_tours.yes") : I18n.t("billing.billing_public_tours.no")
=> "Nein"

Capybara content matchers cheat sheet

There’s a cheat sheet I use to determine the capybara content matcher to use for a specific purpose:

Wait for some text to eventually be there:
expect(page).to have_content('some text')

Succeeds as soon as the text is there and can be very fast.

Wait for some text to be - and stay - there:
expect(page).not_to have_no_content('some text')

Succeeds if the text stays there for the whole default_max_wait_time and is therefore always slow. But sometimes needed.

Wait for some text to eventually disappear:
expect(page).to have_no_content('some text')

Succeeds as soon as this text is not there and can be very fast.

Wait for some text to be - and stay - absent:
expect(page).not_to have_content('some text')

Succeeds if the text stays absent for the whole default_max_wait_time and is therefore always slow. But sometimes needed.

running sidekiq job in console

working with clients database locally has to be done without having sidekiq running to prevent side-effects like causing relay-interactins, mail-sends and others. but. sometimes, to debug burried mantraps you have to use the local connsole and you like to execute a task, which is usually performed by sidekiq. there is a simple way to run those tasks locally.

asuming that you have one item in your queue to execute, you can easy run:

job = Sidekiq::Queue.new("low").first
job.klass.constantize.new.perform(*job.args)

if you have to find something by the id shown in backend, you can utilize the Sidekiq API for distinct access.