Transcript:
Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll
be taking a look at the
derailed_benchmarks gem,
and how you can use it to benchmark your Rails application and find, and
hopefully fix bottlenecks in your code.
One of the hardest failing tests to debug are those which fail randomly, also known as “flaky” tests. You write your test cases, you run the tests in your environment (in random order), and see them all pass. Afterwards, you push your code, your CI server runs them and one test fails.
This is not an uncommon scenario, and one too common when using integration
tests which use JS, with Capybara-Webkit or Selenium.
But if your failing test doesn’t communicate with an external API, doesn’t use
JS, and passes locally, it can be a bit nerve-wracking.
After you have identified the failing test, and it still passes after running it locally, one way to figure out why it’s failing is running its context multiple times.
To automate this process a bit, I like to use the following command:
Read more »I have been using the capybara-webkit gem for a while now since I first tried it out after making the switch from Capybara + Selenium.
Using capybara-webkit speeds up my Selenium tests due to its headless nature, and it’s very straightforward. However, I had some trouble testing a Rails based React app.
In this post, I will explain how I worked around the issues that came up when trying to use capybara-webkit with React.
Read more »How many times did you come across a great gem you wanted to try out in a production console, like benchmark-ips or awesome-print?
Be it for performance or for readability, sometimes it’s nice to be able to try out something new quickly without going through a pull request + deployment process. This is possible by modifying the $LOAD_PATH Ruby global variable and requiring the gem manually.
Read more »When working on a Rails project, you may have seen present? calls on
ActiveRecord relationships. This might feel natural, mostly because present?
exists on all objects via ActiveSupport, so you expect the relationship to respond to it,
but it’s actually not a very good idea. If all we want to do is check if the
scope returns any results from the database, there are better ways than using
present?.
A few weeks ago, I noticed weird output in the RSpec test suite (~4000 tests) for a Rails application:
.............................................................................................unknown OID 353414: failed to recognize type of '<field>'. It will be treated as String ...........................................................................................................................................
This Rails app uses a PostgreSQL database. After some Googling, it turns out that this is a warning from PostgreSQL. When the database doesn’t recognize the type to use for a column, it casts to string by default.
Read more »When writing tests for services, you may sometimes want to use mock objects instead of real objects. In case you’re using ActiveRecord and real objects, your tests may hit the database and slow down your suite. The latest release of the rspec-mocks library bundled with RSpec 3 includes at least three different ways to implement a mock object.
Let’s discuss some of the differences between a spy, a double and an
instance_double. First, the spy:
[1] pry(main)> require 'rspec/mocks/standalone'
=> true
[2] pry(main)> user_spy = spy(User)
=> #<Double User>
[3] pry(main)> spy.whatever_method
=> #<Double (anonymous)>
A few times in the past I’ve had to interact with IMAP via Ruby, and wrapping your head around its API is not so easy. Not only is the IMAP API a bit obscure and cryptic, but Ruby’s IMAP documentation is not so great either.
Searching the internet for examples doesn’t yield too many results, so I’ll try to write down some of the things I’ve learned. The examples I’ll show use Gmail as the target IMAP server.
Read more »A few weeks ago, I found an interesting project called
Bumbler. If your project uses Bundler,
Bumbler shows you your project’s largest dependencies.
When you find yourself staring at the screen after running
bundle exec rails c, you may want to give this tool a try.
Recently, we started using Skylight in production for one of our clients’ Rails applications, in an attempt to try to improve the performance of some of the more critical API endpoints.
Skylight reports on:
I noticed an unusually large amount of allocated objects for one request:
This request would take anywhere from 400ms to 3000ms to respond, which is WAY too long.
Read more »Hubot makes it incredibly easy to setup on a Heroku
server, by taking advantage of its Procfile support. Simply running
git push heroku master deploys the app and starts it.
When it comes to deploying to your own Linux server, given that
foreman doesn’t really like background processes (see:
ddollar/foreman#65), you need to
use something like monit, systemd or tmux to better manage your Hubot
process.
We have been using Slack at OmbuLabs for a while now after switching from HipChat, and haven’t looked back. It looks and feels much better than any other available platform of its kind. Slack provides WebHooks, which you can use to post messages to your team’s channels.
Read more »default_scope is a method provided by ActiveRecord, which allows you to set
a default scope (as its name implies) for all operations done on a given model.
It can be useful for allowing soft-deletion in your models, by having a
deleted_on column on your model and setting the default scope to
deleted_on: nil
Often, Enumerable#select is the chosen method to obtain elements from an
Array for a given block. Without thinking twice, we may be doing more work than
necessary by not taking advantage of another method from the Enumerable module,
Enumerable#grep.
If you are using git in 2015, you are probably also using Github, unless you’re self-hosting or still betting on Bitbucket.
Below are some cool, useful tricks you can use on Github which can probably make your life easier:
Read more »