{ "version": "https://jsonfeed.org/version/1", "title": "Ruby on enumerator.dev", "icon": "", "home_page_url": "https://enumerator.dev/", "feed_url": "https://enumerator.dev/feed.json", "items": [ { "id": "https://enumerator.dev/naming-things-for-what-they-do/", "title": "Naming Things for What They Do", "content_html": "

I just saw the Rails World announcement that flavorjones is working on ActiveRecord::Tenanted and all I can say is, “What a reasonable name!”

\n

When I started willow.camp I chose not to use apartment partially because the name and the metaphor were too confusing. I didn’t like tho have to get used to the idea of requests taking “elevators” and all that. The “apartment” metaphor doesn’t work for databases even though “tenant” does.

\n

Always choose descriptive names over clever ones. It doesn’t matter how well you think the metaphor fits; you’ll always end up with something confusing in the end.

\n", "date_published": "2025-09-09T11:23:33+00:00", "url": "https://enumerator.dev/naming-things-for-what-they-do/", "tags": ["ruby","rails"] }, { "id": "https://enumerator.dev/use-precomputed-hashes-instead-of-bcrypt-in-test/", "title": "Use Precomputed Hashes Instead of BCrypt in Test", "content_html": "

I asked Claude to find the slowest test file again after my success earlier today and Claude found a call to BCrypt in my fixtures that was gobbling up time.

\n

I need user records all over the place in my test and each new user is a new call to encrypt a password.

\n

Here is Claude’s summary, with my Grammarly edits:

\n
\n

Problem: The PreviewsControllerTest#test_should_show_preview_for_own_unpublished_post test was taking 2.95 seconds due to BCrypt password hashing being computed dynamically in fixtures with <%= BCrypt::Password.create("password") %>.

\n

Solution: Replaced the dynamic BCrypt computation with a pre-computed hash $2a$12$dapdHZiOTxAL8OT9yNI6e.hhTjRhWgXq7kx737/xf8tBfQbMD2bi for all user fixtures.

\n

Result: The slowest test now runs in ~0.25-0.52 seconds (82% improvement) and all tests pass. The overall test suite performance has been significantly improved, as this optimization affects all tests that use user fixtures.

\n
\n", "date_published": "2025-07-21T00:55:00+00:00", "url": "https://enumerator.dev/use-precomputed-hashes-instead-of-bcrypt-in-test/", "tags": ["willow-camp","performance","ruby","rails"] }, { "id": "https://enumerator.dev/speeding-up-willow-camp-s-post_test-rb-by-99/", "title": "Speeding Up willow.camp's post_test.rb by 99%", "content_html": "

I just asked Claude to speed up the slowest test file in willow.camp. post_test.rb was taking over 1 second to execute. For a tiny Ruby app, that’s a long time.

\n

Here’s what Claude did. I was not expecting such a simple fix!

\n
\n

Test: test_should_detect_mermaid_diagrams_and_set_has_mermaid_diagrams_flag in test/models/post_test.rb:82

\n

Issue: The test was using an unnecessarily large markdown string that required\nexpensive processing through the Commonmarker library.

\n

Optimization: Reduced the test markdown from a multi-section document to a minimal string that still tests the same functionality:

\n\n
\n

The original test was designed to evaluate a full-fledged Markdown document that was about 10 lines long. I didn’t need that in this case because I just needed to test that my custom mermaid code block worked.

\n

Thanks Claude!

\n", "date_published": "2025-07-20T14:05:00+00:00", "url": "https://enumerator.dev/speeding-up-willow-camp-s-post_test-rb-by-99/", "tags": ["willow-camp","performance","ruby","rails"] }, { "id": "https://enumerator.dev/how-rack-timeout-keeps-your-app-alive/", "title": "How Rack::Timeout Keeps Your App Alive", "content_html": "

Rack::Timeout is a library that monitors long-running requests in a Ruby app and kills them if they take too long. The default configuration in Rack::Timeout is to kill requests that take 15 seconds or longer.

\n

Why Requests Take A Long Time?

\n

The answer here will vary from one app to another. A frequent culprit is database transactions taking too long or outgoing requests to other resources hanging.

\n

How Does This Keep My App Alive if it Kills Things?

\n

In a typical Ruby app using Puma, you will have a few processes to manage a Ruby Thread collection. Rack::Timeout will send SIGTERM to a process if it breaches the timeout.

\n

Your Ruby app and Puma process will remain alive, but the stuck process will be terminated.

\n

Puma will notice that this process has terminated and will boot up a new one.

\n

When is Rack::Timeout Unsafe?

\n

Killing a running process is often unsafe. Fortunately, Rack::Timeout uses a “polite” kill message, SIGTERM, which requests that the process shut down and clean up its resources.

\n

SIGTERM is less severe than SIGKILL, but still poses risks.

\n

A Ruby thread could be in the middle of creating database records when it is killed, which would result in things being left in a broken state.

\n

Where Does Rack::Timeout Run in My App?

\n

Rack::Timeout runs in Rack, an interface between web servers, like Puma, and Rails applications. Puma receives a request, hands it off to a thread, which passes it through Rack before it reaches your application code.

\n

When Rack handles the request, it monitors the request duration and kills the process if the request takes too long.

\n

Rack::Timeout keeps your application alive by killing hanging processes and allowing Puma to boot up a new process to handle the next request.

\n
graph TD\nClient[Client Requests] --> LB[Load Balancer\nnginx/HAProxy]\nLB --> Container1[Container 1\nRails App]\nLB --> Container2[Container 2\nRails App]\nContainer1 --> PumaServer1[Puma Server 1]\nContainer2 --> PumaServer2[Puma Server 2]\nPumaServer1 --> Worker1_1[Worker 1]\nPumaServer1 --> Worker1_2[Worker 2]\nPumaServer2 --> Worker2_1[Worker 1]\nPumaServer2 --> Worker2_2[Worker 2]\nWorker1_1 --> RackTimeout1_1[Rack::Timeout\nMiddleware]\nWorker1_2 --> RackTimeout1_2[Rack::Timeout\nMiddleware]\nWorker2_1 --> RackTimeout2_1[Rack::Timeout\nMiddleware]\nWorker2_2 --> RackTimeout2_2[Rack::Timeout\nMiddleware]\nRackTimeout1_1 --> Threads1_1[3 Threads\nThread Pool\n_timeout monitored per thread_]\nRackTimeout1_2 --> Threads1_2[3 Threads\nThread Pool\n_timeout monitored per thread_]\nRackTimeout2_1 --> Threads2_1[3 Threads\nThread Pool\n_timeout monitored per thread_]\nRackTimeout2_2 --> Threads2_2[3 Threads\nThread Pool\n_timeout monitored per thread_]\nclassDef container fill:#e1f5fe\nclassDef worker fill:#f3e5f5\nclassDef thread fill:#e8f5e8\nclassDef loadbalancer fill:#fce4ec\nclassDef middleware fill:#fff3e0\nclass Container1,Container2 container\nclass Worker1_1,Worker1_2,Worker2_1,Worker2_2 worker\nclass Threads1_1,Threads1_2,Threads2_1,Threads2_2 thread\nclass LB loadbalancer\nclass RackTimeout1_1,RackTimeout1_2,RackTimeout2_1,RackTimeout2_2 middleware
\n", "date_published": "2025-06-05T00:00:00+00:00", "url": "https://enumerator.dev/how-rack-timeout-keeps-your-app-alive/", "tags": ["performance","ruby","rails"] }, { "id": "https://enumerator.dev/migrating-from-standalone-sidekiq-to-an-activejob-adapter/", "title": "Migrating from Standalone Sidekiq to an ActiveJob Adapter", "content_html": "

I paired on this problem with my coworker Hannah Yeates. The examples below are from this pairing session. Thanks for working on this together, Hannah!

\n
\n

I am working on a project right now that uses Sidekiq without the ActiveJob adapter. This means that our Sidekiq jobs look something like this:

\n
class ExampleWorker\n  include Sidekiq::Worker\n\n  def perform(arg)\n    puts "Hello, the arg was #{arg}"\n  end\nend\n

And we call them like this:

\n
ExampleWorker.perform_async("a nice arg")\n

And in dev they’ll execute like this:

\n
2024-01-17T15:05:31.455Z pid=45599 tid=18gj\n  class=TestWorker \n  jid=8d32dcd88b1de2ed3a5419eb \n  INFO: start\nHello, the arg was foo\n

However, we want to switch over to GoodJob so that we have a transactionally safe background job processor. Our steps for doing this are:

\n
    \n
  1. Set up Sidekiq as an ActiveJob adapter instead of using Sidekiq on its own.
    2. \n
  2. Install GoodJob and replace Sidekiq with GoodJob.
    3. \n
  3. Run Sidekiq and GoodJob in parallel so that Sidekiq finishes all the work in Redis.
    4. \n
  4. Shut down Sidekiq and remove it from the application code.
    5. \n
\n

This post is about step 1, making Sidekiq the ActiveJob adapter instead of using it on its own.

\n

Step 1 : Configure ActiveJob

\n

Our first step is to configure the application to use Sidekiq for ActiveJob

\n
# in application.rb\nconfig.active_job.queue_adapter = :sidekiq\n

Then we created an empty ApplicationJob (more on this later).

\n
# application_job.rb\nclass ApplicationJob < ActiveJob::Base\n  # leave this empty for now\nend\n

Step 2: Convert Workers to ApplicationJob

\n

Next we updated our jobs to inherit from application job:

\n
class ExampleWorker < ApplicationJob # Add this\n  # remove this: include Sidekiq::Worker\n\n  # The rest of the code remains the same\nend\n

And finally, we changed all our method calls from ExampleWorker.perform_async("a nice arg") to ExampleWorker.perform_later("a nice arg").

\n

Step 3: See What Breaks

\n

So far, so good! Next, we had a question: What happens when a job is enqueued by Sidekiq but processed by ActiveJob? To emulate this we:

\n
    \n
  1. Booted a Rails console locally.
    2. \n
  2. Use the original code to enqueue a job.
    3. \n
  3. Modify the worker to use ApplicationJob.
    4. \n
  4. Boot Sidekiq locally and see what errors we get.
    5. \n
\n

In the real world, this would happen when the new code is deployed and there are jobs in the queue that were put there by Sidekiq. Here’s the first error we got:

\n
WARN: NoMethodError: undefined method `jid=' for #<TestWorker:...>\n

We resolved this by creating an alias to ActiveJob’s provider_job_id= and tested again. In the end we had three NoMethodError messages to resolve. We updated our ApplicationJob to respond to those methods.

\n
class ApplicationJob\n  def jid=(arg)\n    provider_job_id = arg\n  end\n\n  def jid\n    provider_job_id\n  end\n\n  def bid=(arg);\n    # We are lucky to not need batching, so we let this return `nil`\n  end\nend\n

Wrapping Up

\n

Making the switch to ActiveJob was easier than we expected. We now have a backwards compatible way of moving from standalone Sidekiq to ActiveJob. Our next step is to swap out Sidekiq for GoodJob.

\n

If you are planning on using GoodJob, or Solid Queue, check out this article on making the switch once you’re using ActiveJob:

\n

Migrating from Sidekiq to Solid Queue | Kyle Keesling

\n", "date_published": "2024-01-17T00:00:00+00:00", "url": "https://enumerator.dev/migrating-from-standalone-sidekiq-to-an-activejob-adapter/", "tags": ["sidekiq","activejob","ruby","rails"] }, { "id": "https://enumerator.dev/weird-method-signatures-in-ruby-with-keyword-arguments/", "title": "Weird Method Signatures in Ruby with Keyword Arguments", "content_html": "

In a recent project, I was working with a method call from a library that used some meta-programming to define a get method. I wasn’t certain what the correct signature was, so I thought I’d try some things out.

\n
api_client.get('my/path')\n# Success, got at 200!\n

I knew that the method accepted a request body but I wasn’t sure how to pass the body. So I tried this next call.

\n
api_client.get('my/path', 'body')\n# => ArgumentError: wrong number of arguments (given 2, expected 1)\n

Okay, this tells me something, but I’m a bit confused. How did it expect one argument when I know a successful call can have more than one argument?

\n

So I tried this, something you might recognize from a Ruby 2 project (more on that later):

\n
api_client.get('my/path', { body: 'body' })\n# => ArgumentError: wrong number of arguments (given 2, expected 1)\n

The same error! What does that tell us? It wasn’t immediately obvious to me so I tried the next iteration:

\n
api_client.get('my/path', body: 'body')\n# Success, got at 200!\n

Let’s break down what’s happening here

\n
    \n
  1. We’re using a variable called api_client in this example. Pretend this is a wrapper that can make HTTP calls to a remote service.
    2. \n
  2. We’re calling the get method which presumably uses HTTP GET to fetch data.
    3. \n
  3. The get method accepts a positional argument, a string, that represents the URL path we’re fetching.
    4. \n
\n

All good so far, right? The next step is where things get weird.

\n

What is the next argument? I didn’t know until I tried all the options. It turns out body: is a keyword argument, or kwarg, and it has a default. So the method signature must look something like this.

\n
def get(path, body: {}, headers: {})\n  # Perform get request\nend\n

So what’s with this error? ArgumentError: wrong number of arguments (given 2, expected 1) The method only requires one positional argument to work. So even though it can accept three arguments, it is only expecting one. The result is a message that is a bit misleading because you can correctly call the method with one, two, or three arguments, but the second and third need to be keywords.

\n

Let’s Make Things Weird

\n

In Ruby land, especially applications that existed before Ruby 2, it is reasonable to see a method signature like this.

\n
def get(path, options: {})\n  body = options[:body]\n  headers = options[:headers]\n  # Perform get request\nend\n

Calling this method can look the same as a call with kwargs because the curly braces around a hash in Ruby are optional. That’s why I tried wrapping the second argument in a hash. I wanted to know if we were dealing with an options hash or a keyword.

\n

As a consumer of an interface like this, it can take a bit of poking around to know if you’re dealing with an options hash or keywords.

\n

Let’s Make Things Better

\n

Kwargs are great for helping developers understand a method signature, but if they’re not used carefully they result in confusing error messages.

\n

To make this method call better, I’d suggest defining it entirely with kwargs and doing away with the positional argument.

\n
def get(path:, body: {}, headers: {})\n  # Perform GET\nend\n

Let’s see what usage looks like on this. Let’s do something wild and call the method with no arguments.

\n
get\n# => ArgumentError: missing keyword: :path\n

Oh! That’s helpful. I need to give it a path.

\n
get(path: 'my/path')\n# Success!\n

What about some obviously wrong method calls?

\n
get(path: 'my/path', 'body')\n# SyntaxError: unexpected ')', expecting =>\n# get(path: 'my/path', 'body')\n\nget(path: 'my/path', { body: 'body' })\n# SyntaxError: unexpected ')', expecting =>\n# get(path: 'my/path', { body: 'body' })\n

SyntaxError! Neat! Because Ruby knows this method needs keywords, it doesn’t know how to parse these two calls. This prevents you from even calling the method at all.

\n

Let’s make a typo:

\n
get(path: 'my/path', bdy: 'body')\n# => ArgumentError: unknown keyword: :bdy\n

That’s helpful too! It puts the typo right in front of my eyes.

\n

And finally, let’s use all keywords:

\n
get(path: 'my/path', body: 'body' )\n# Success!\n

But Why is it This Way? A History of Keyword Arguments in Ruby

\n

Before keyword arguments existed in Ruby, the method signature would have had an options hash, as I noted above.

\n
def get(path, options = {})\n  headers = options[:headers]\n  body = options[:body]\n  # insert remaining http client code here\nend\n

We had a few options for how we called the method, depending on our syntax preferences. Most commonly, you’d see something like this:

\n
get('my/path', body: {}, headers: {})\n

But if you prefer to be explicit about what you are passing to a method you might wrap the hash in curly braces:

\n
get('my/path', { body: {}, headers: {} })\n

Enter Keyword Arguments

\n

Keyword arguments were introduced in Ruby 2.0. Ruby 2!!!! “Isn’t that like eons ago?” you say. Yes, it is eons ago, but code practices change very slowly. So the two examples above were very common in Ruby 2.

\n

In fact, in early versions of Ruby 2 you could define a method using kwargs and call the method with a hash. Ruby would see the hash and automatically convert it to kwargs.

\n

So that meant a method like this:

\n
def get(path, body:, headers:)\nend\n

Could be called like this:

\n
get('my/path', body: 'body', headers: { auth: 'auth' })\n

Or like this:

\n
get('my/path', { body: 'body', headers: { auth: 'auth' } })\n

Ruby would figure out that the second argument, the hash, is the keyword argument. To the developer using the get method, there is no difference between using kwargs or an options hash, provided the use the right keywords.

\n

Additionally, developers often chose to use a hash as the last positional argument for flexibility. Imagine an options hash with five or more options. Using kwargs the method signature would make the method unreadable!

\n
def get(path, body:, headers:, retry:, retry_delay:, admin:, on_error: ...)\nend\n

A contrived example of a long kwargs list

\n

With kwargs users need to know the kwargs and the method signature is locked into the kwargs that the developer chose. But with an options hash, there is some flexibility to add or remove options if things change.

\n

But in Ruby 3 all that changed and Ruby stopped automatically converting positional hashes to keyword arguments.

\n

Today we get a slightly ambiguous message when we use signatures that mix positional and keyword arguments, but in Ruby 2, a positional argument could be converted to a keyword argument unexpectedly. An excerpt from the post above shows how keyword arguments were confusing:

\n
\n

Automatic conversion does not work well when a method accepts optional positional arguments and keyword arguments. Some people expect the last Hash object to be treated as a positional argument, and others expect it to be converted to keyword arguments.

\n
\n

Let’s rewrite the get method to demonstrate how this can be confusing. (Note: this is my rewording of the example that the authors of the Ruby blog post wrote).

\n
# Using Ruby 2.6\ndef get(path, body: {}, headers: {})\n  p [path, body, headers]\nend\n\nget({})\n# => [{}, {}, {}]\n\ndef get_with_default(path = 'home', body: {}, headers: {})\n  p [path, body, headers]\nend\n\nget_with_default({})\n=> ["home", {}, {}]\n

get_with_default has an unexpected behaviour here. Since we’re only passing one argument, the method should see that as the first positional argument. But because we’re passing it a hash, it parses this hash as the keyword arguments. Let’s try to put something in that hash to test this out.

\n
# Again, we're in Ruby 2.6 here!\n\nget_with_default({body: 'body'})\n=> ["home", 'body', {}]\n

There is a reason for this, but the behaviour is not intuitive. Since the first argument has a default, we don’t need to pass it, so when Ruby 2.6 sees a hash it automatically parses the hash as keyword arguments.

\n

In the Ruby blog post about separating positional and keyword arguments, they suggest a workaround one might think is clever but produces unexpected results as well.

\n
# Still Ruby 2.6 here\n\nget({}, **{})\n=> expected: [{}, {}]\n=> actual: ['home', {}]\n

The **{} here is telling Ruby, “I’m passing you a hash and I’d like you to treat it as keyword arguments.” However, Ruby just ignores it because the parser sees the first hash and uses that as the kwargs!

\n

To quote the Ruby post you need to call get({}, {}) to get this to work, “which is very weird.”

\n
# Still Ruby 2.6 here\n\nget({}, {})\n=> expected: [{}, {}]\n=> actual: [{}, {}]\n

Enter Ruby 3

\n

And finally! Here we are at Ruby 3 where you can’t mix hashes with kwargs…err, wait..but you can still mix positional arguments with kwargs!

\n

Summing Up

\n

Ruby method signatures can be kinda funky, especially when they’re peppered with the history of the language itself.

\n

My take here is that we should always write the most human-intelligible code possible. If you have a simple method call where the arguments are straightforward, positional arguments are fine.

\n

However, it helps to name things, so go with keyword arguments all the way. Mixing the two can get a bit messy.

\n", "date_published": "2024-01-10T00:00:00+00:00", "url": "https://enumerator.dev/weird-method-signatures-in-ruby-with-keyword-arguments/", "tags": ["weird","ruby","coding-style"] }, { "id": "https://enumerator.dev/two-tools-for-diagnosing-slow-endpoints-in-rails/", "title": "Two Tools for Diagnosing Slow Endpoints in Rails", "content_html": "

Intro

\n

In general, I see two types of slow endpoints when I am doing performance work: endpoints that have bad code causing a slow response, and endpoints that have a bad query causing a slow response. This post will focus on endpoints that have bad code.

\n

Slow endpoints can be identified using an application performance monitor like NewRelic. These endpoints usually either have N + 1 queries, or they spend lots of time in Ruby. You’ll see them in NewRelic, but if you want to hit an endpoint in real-time with production data, see the tip below about Rack MiniProfiler.

\n

NewRelic

\n

The transactions monitor is a good place to start. Pick a broad time range (7 days) and look at the “Transaction Traces” that New Relic has captured. If a transaction trace here includes a long query or lots of queries to the DB, it is likely a good transaction to look into.

\n

There will likely also be some obvious problem queries in the top “Most Time Consuming” transactions. Click through each transaction here and take a look at the transaction traces that NewRelic captured.

\n

The example below has two N + 1 problems! First you see that we hit Memcached 62 times, then we hit the relational database 47 times! Eeep! Looks like this is a good endpoint to work on.

\n

\n

“Most Time Consuming” is not a bad thing. If we have a really fast endpoint that is hit tens of thousands of time per minute, it is not really a problem. But if a relatively busy endpoint has a slow average response time, it likely is a problem!

\n

Rack MiniProfiler

\n

Development and staging data can differ wildly from production data, which makes query performance differ wildly between the environments.

\n

Running Rack MiniProfiler in production gives you a real-time stack trace of live production data! Check out the Rack MiniProfiler docs on how to run it in a production environment

\n

I like to be able to selectively turn Rack MiniProfiler on and off, so I usually set it up so that you have to log in as an admin user and then you have to have turned it on for your session by adding ?rmp=on to the first request.

\n

Once Rack MiniProfiler is turned on, you can hit one of the problem endpoints that you see in NewRelic and get more detailed information on what is slowing that request down.

\n

4 Possible Ways to Resolve Slow Endpoints

\n

This is a non-exhaustive list of possible solutions.

\n\n

Remember, performance work can take a few passes to get it right. Try one strategy at a time, deploy, and monitor until your response time is back to an acceptable level.

\n

I’d love to hear your favourite strategies for tackling slow endpoints.

\n", "date_published": "2021-03-29T12:00:00+00:00", "url": "https://enumerator.dev/two-tools-for-diagnosing-slow-endpoints-in-rails/", "tags": ["performance","ruby","rails"] } ] }