Jerome Dalbert

We currently monitor performance with the following tools:

1. Heroku Metrics: our main app is Hosted on Heroku, so it is the best place to get quick server metrics like memory usage, load averages, or response times.
2. Good old New Relic for detailed general metrics, including transaction times.
3. Skylight for more specific Rails Controller#action transaction times. Navigating those timings is much better than with New Relic, as you get a clear full breakdown of everything that happens for a given request.

Skylight offers better Rails performance insights, so why use New Relic? Because it does frontend monitoring, while Skylight doesn't. Now that we have a separate frontend app though, our frontend engineers are looking into more specialized frontend monitoring solutions.

Finally, if one of our apps go down, Pingdom alerts us on Slack and texts some of us.

We use OmniAuth with Devise to authenticate users via Twitter, GitHub, Bitbucket and Gitlab. Adding a new OmniAuth authentication provider is basically as easy as adding a new Ruby gem!

The only drawback I could see is that your OmniAuth+Devise OmniauthCallbacksController redirection logic can easily get hairy over time. So you have to be vigilant to keep it in check.

We use Calendly to schedule hiring interviews. You just share your Calendly link and people can pick a free time slot without any back and forth.

I connected it to my work calendar and refined my availabilities further in their settings, so I know I won't get a meeting at a bad time.

I wouldn't use it to set up meetings with coworkers though. It is just easier to use your work calendar and check their availabilities there.

The continuous integration process for our Rails backend app starts by opening a GitHub pull request. This triggers a CircleCI build and some Code Climate checks.

The CircleCI build is a workflow that runs the following jobs:

• check for security vulnerabilities with Brakeman
• check code quality with RuboCop
• run RSpec tests in parallel with the knapsack gem, and output test coverage reports with the simplecov gem
• upload test coverage to Code Climate

Code Climate checks the following:

• code quality metrics like code complexity
• test coverage minimum thresholds

The CircleCI jobs and Code Climate checks above have corresponding GitHub status checks.

Once all the mandatory GitHub checks pass and the code+functionality have been reviewed, developers can merge their pull request into our Git master branch. Code is then ready to deploy!

#ContinuousIntegration

We use Sidekiq to process millions of Ruby background jobs a day under normal loads. We sometimes process more than that when running one-off backfill tasks.

With so many jobs, it wouldn't really make sense to use delayed_job, as it would put our main database under unnecessary load, which would make it a bottleneck with most DB queries serving jobs and not end users. I suppose you could create a separate DB just for jobs, but that can be a hassle. Sidekiq uses a separate Redis instance so you don't have this problem. And it is very performant!

I also like that its free version comes "batteries included" with:

• A web monitoring UI that provides some nice stats.
• An API that can come in handy for one-off tasks, like changing the queue of certain already enqueued jobs.

Sidekiq is a pleasure to use. All our engineers love it!

Our legacy HAML pages use Bootstrap as a basic styling framework.

Love it or hate it, but for full-stack developers, Bootstrap is still one of the quickest ways to hit the ground running. All startup websites had to start somewhere, and we are no exception at StackShare!

These days, our frontend team writes or rewrites all our new pages with React components that each have their own CSS styling.

We switched from Unicorn (process model) to Puma (threaded model) to decrease the memory footprint of our Rails production web server. Memory indeed dropped from 6GB to only 1GB!

We just had to decrease our worker count and increase our thread count instead. Performance (response time and throughput) remained the same, if not slightly better. We had no thread-safety errors, which was good.

Free bonus points are:

• Requests are blazing fast on our dev and staging environments!
• Puma has first-class support for WebSockets, so we know for sure that Rails ActionCable or GraphQL subscriptions will work great.
• Being on Puma makes us even more "default Rails"-compliant since it is the default Rails web server these days.

We use RSpec because it is a de-facto Rails industry standard.

minitest was an interesting alternative because it was part of the Ruby standard library, but this is not the case any more. Also, at the time of writing, the real-world-rails collection shows that it is used in only 31 Gemfiles vs 135 Gemfiles for RSpec.

RSpec works reliably well for an overwhelming majority of people who are used to it, so I guess that is why they don't see a need to change.

In the Rails app I work on, I was recently wondering where to put a Ruby constant shared by 2 classes that belong to the same module.

That constant didn't really belong to either class... Then I remembered that you can just define the constant at the module level:

# app/services/m/my_constant.rb
module M
  MY_CONSTANT = 'blah'
end

# app/services/m/a.rb
module M
  class A
    def do_something
      puts MY_CONSTANT
    end
  end
end

# app/services/m/b.rb
module M
  class B
    def do_something
      puts MY_CONSTANT
    end
  end
end

The constant is in its own file, and the Rails autoloader picks it up fine.

This is similar to what Bundler does when you create a new gem: bundle gem my_gem creates a VERSION constant in lib/my_gem/version.rb. This is a good reminder, as I sometimes forget these kinds of Ruby idioms after long periods of traditional Rails work. :-)

Sometimes I need a quick way to store a list of things, without new PostgreSQL tables and Rails associations. I just want to add a field to an existing table and call it a day. This is useful for simple features, or when the future is uncertain.

For example, you could store T-shirt sizes in a 'S,M,L,XL' string, but then you'd have to join/split when storing/reading. What if I told you that you could delegate all this dirty work to Postgres?

You can store a ['S','M','L','XL'] array with the Postgres array type:

add_column :products, :sizes, :string, array: true, default: []

When reading the value from the DB, Rails will present it to you as a Ruby array. Nice!

And if you want to store hashes like [{ 'size': 'S', 'color': 'Red' }, { 'size': 'M', 'color': 'Green' }], Postgres' jsonb type has you covered too:

add_column :products, :sizes, :jsonb, default: []

Happy #Hacking!

#DataTypes