DEV Community: Augusts Bautra

Share your cancer code!

Augusts Bautra — Tue, 24 Mar 2026 13:31:54 +0000

Today I was doing a read-through of existing code to prepare for an upcoming feature, and I came across this abomination.

# controller code
# GET /project_team_tasks
def show
  @teams = project.teams 
  TeamTask.define_teams_quantity_distributions_attr_readers(@teams)  
end

# model code
def self.define_teams_quantity_distributions_attr_readers(teams)
  teams.each do |team|
    Budget.component_groups.each do |component_group|
      define_method("team_#{team.id}_assembled_elements_quantity_#{component_group}") do
        teams_quantity_distributions["team_#{team.id}_assembled_elements_quantity_#{component_group}"]
      end
    end
  end
end

# then in view
team.tasks.send("team_#{team.id}_assembled_elements_quantity_1")

As far as I understand, calling the class method defines an instance method (a getter) for every team*component_group pair. Apparently the underlying data are stored in TeamTask instance teams_quantity_distributions jsonb field.
This code is pernicious because it's a source of memory leak - given a sufficiently large number of teams and component groups we can end up having dynamically defined thousands of instance methods on TeamTask, and this will occur only as action is called for different projects. Plus, it's wholly unnecessary, why not just access the teams_quantity_distributions field in a regular manner (one still needs to compose the method name same as a hash key), or use method_missing metaprogramming to have just one method definition?!

What hairy code have you come across lately?

Versions VS Approvals

Augusts Bautra — Mon, 23 Mar 2026 10:16:48 +0000

Today I encountered a tricky problem in a seemingly simple "one record is not showing up in #index" bugfix task.

The problem stems from this data situation:

Task.pluck(:project_version_id, :is_actual)
#=> [
  [1, true],
  [nil, true]
]

Both versioned and non-versioned records can be :actual, can this be right?

Thinking about it, I came to the realization that working with versioned data requires clear answers to these questions:

Are 'draft' data ever persisted in a sort of 'lobby'?
What is more important - accessing possible draft data or possible latest approved/actual version?
What operation(s) result in new version(s)?

Depending on the answers, you can get one of these two systems:

The key difference for developers is the meaning and importance of unversioned data. In version case, regular data are the actual and special access is needed for historic version data. Whereas in approval pattern it's the opposite - unversioned data is less important, since it's not yet 'approved'.

Naturally, approval workflow will be harder to reason about and will require careful development to communicate that plain project.tasks.actual is not quite project.last_approved_version.tasks.

TIL: Template Strict Locals (TSL)

Augusts Bautra — Fri, 13 Feb 2026 09:22:32 +0000

The other day I was giving Chris' "Powerful Rails Features You Might Not Know" presentation a look, and among many useful tips (date and time helpers, nice) was a particular gem - Template Strict Locals.

Up till now I had been leaving comments like this in view partials:

<%# Partial requires `user: @user, group: user_group` %>

But now we have something better, magic comment that will actually enforce the locals!

<%# locals: (user:, user_group:, last_signed_in: nil) -%>

You can also have optional locals with a default value, and even specify a partial that must not be passed any locals:

# group is now optional
<%# locals: (user:, user_group: nil) -%>

# no locals, please
<%# locals: () -%>

Title credit to Chris Oliver.

TIL: Blazing-fast correlated exists queries

Augusts Bautra — Fri, 09 Jan 2026 14:45:29 +0000

Today I took some time at the end of the first work week of the year to review some metrics and touch up some performance issues.

In one spot we're querying for, using Twitter-clone parlance "Posts with at least one :suggestion Comment", or more generally "gater records from table X that have at least one of association Y matching some conditions".

Usually I solve this with a join or a subquery like so

Post.joins(:comments).merge(Comment.where(type: :suggestion))

But this can get inefficient if there are few Posts and a huge amount of Comments, we're basically redundantly checking all the comments belonging to the same post.

The key idea is to realize that detecting just one matching Comment for a post is sufficient, we don't have to check/join all of them. Think clearly about whether this situation applies in your systems.

We can achieve the same lookup result with a clever use of EXISTS like so:

Post.where(
  Comment
    .where("comments.post_id = posts.id") # IMPORTANT correlation clause
    .where(type: :suggestion)
    .arel.exists
)

For simple datasets Postgres may be smart enough to optimize both approaches to a semi-join, so don't be surprised if there's no improvement in some cases, this is still a useful technique to know.

See also a previous post of mine regarding the power of EXISTS subqueries.

The Secret of Minimum Coverage

Augusts Bautra — Fri, 19 Dec 2025 14:11:42 +0000

Today is the last day of work before holidays and I'm finishing up some chores.
One thing I wanted to do was to improve and increase the required minimum of spec coverage in our project. Get it from 30% to 35%. This is somewhat complexed by there being unspecced legacy code and us being unable to just set a blanket 90% minimum for all new files.

Going through the low offenders I came across a file like this:

The file has no specs, but it gets a surprisingly high coverage because of mere loading of the file. Every inclusion line will artifically pad coverage percent, ditto for various macro calls. No inclusions would still result in a 66% coverage.

This is bad news for our existing attempts to ensure good coverage for new code. Not sure what improvements we could make.
Maybe adding a linter that checks that every source code file has a corresponding spec file could be a simple improvement - reviewers are much more likely to spot an empty rather than altogehter missing spec file.
Another approach could be to subtract some rows (1-2) from total and covered counts, the example's 3/4 could become (3-2)/(4-2) = 1/2 = 50%.
Finally, dramatically increasing the minimum coverage to 76%+ would to the trick, but would require an inordinate amount of work to mark existing offenders with # :nocov:.

P.S. I ended up combining spec file presence check and high minimum coverage for all files except a special list of legacy offenders in a SimpleCov.at_exit block.

TIL: Inspect Rails app routes from info panel

Augusts Bautra — Mon, 01 Dec 2025 14:08:39 +0000

I usually run $ rails routes | grep ... from console, but today I had to find a pesky excess route definition for a very popular resource that appears in many namespaces. If only there was a way to inspect the exact line in routes.rb that defines the route...

There is! At /rails/info/routes path of the app. The search is not entirely helpful, but should allow narrowing the results down a bit.

TIL: Explode Hash keys into variables in Ruby 3.2+

Augusts Bautra — Tue, 28 Oct 2025 11:49:26 +0000

Oftentimes we're looping over an array of hashes:

data = [{a: 1}, {a: 2}]
data.each do |data|
  some_logic(data[:a])
  # OR
  a = data[:a]
  some_logic(a)
end

But what if we have several keys in the hash? Assigning everything to a variable can get verbose.

Luckily, modern Ruby provides a neat way to explode the data in a oneliner:

data = [{a: 1}, {a: 2}]
data.each do |data|
  data => { a: }
  some_logic(a)  
end

Furthermore, you can specify a custom variable name to use:

data = [{a: 1}, {a: 2}]
data.each do |data|
  data => { a: the_value }
  some_logic(the_value)  
end

Finally, nested hashes can also be exploded easily:

data = [{namespace: {foo: 1, bar: {baz: 2}}}]
data.each do |data|
  data => { namespace: { foo:, bar: { baz: } } }
  # Only terminal nodes without further nesting get variables
  some_logic(foo, baz)  
end

TIL: define custom flash types in Rails

Augusts Bautra — Fri, 24 Oct 2025 11:20:26 +0000

We've been using a custom :warning flash type beyond Rails' default :notice and :alert, but passing it was cumbersome, had to put it in flash manually, the common way of just passing a key to redirect_to like redirect_to(root_path, warning: "Try again!") did not work.

Turns out you can define custom flash types and have Rails expose the convenience keys automagically.

class ApplicationController < ActionController::Base
  add_flash_types :warning

TIL: DB constraints for column values in Rails

Augusts Bautra — Thu, 23 Oct 2025 08:06:02 +0000

Today I used the opportunity to try out Rails' #add_check_constraint migration helper to constrain a new coefficient column's permitted values to only positive ones.

It's really simple!

add_check_constraint :my_things, "some_coefficient > 0",
  name: "my_things_some_coefficient_positive",
  if_not_exists: true

This technique will help improve the data consistency and quality in the Rails app I maintain, alongside such long-standing techniques as disallowing NULLs, limiting length, and adding foreign-key constraints.

Make your feature specs 69%™ more stable

Augusts Bautra — Wed, 22 Oct 2025 13:26:42 +0000

These past couple of weeks we've been improving our existing feature spec suite to prepare it for switching over to --headless=new chrome option.
Several of the existing specs had to be updated with proper awaiting, for example

click_button "Update"

expect(record.reload.field).to eq("new value")

oftentimes failed because the button click hadn't been fully processed yet, so

click_button "Update"

expect(page).to have_flash_message("Update successful")

expect(record.reload.field).to eq("new value")

Another source of deeper fragility was the behavior of .set and fill_in - sometimes, especially if an input already had a value, the new value would either be appended or not inputted at all.

We significanly reduced the incidence of these fails by specifying a clear option like this:

config.before(:each, :js) do
  Capybara.default_set_options = { clear: :backspace }
end

HTTP status VS response body

Augusts Bautra — Thu, 09 Oct 2025 14:19:04 +0000

TL;DR

When designing a (JSON) API, pay extra attention to HTTP statuses used. I usually refer to Rails status cheat-sheet.

Quick tips:

For 201 :created prefer no body, just a HEAD response.
Be on top of your 4** code use
- 401 :unauthorized (actually "unauthenticated") if no session/token to identify 'user'. Use response body to specify details (no token, expired token, invalid token etc.)
- 403 :forbidden if user is known, but lacks permissions to interact with the resource. Use response body for details about resource and lacking permission.
- 400 :bad_request if something off with params or format etc. I use this if, for example, filtering params are wrong, page size is exceeded and other meta-probems. Use response body to explain the problem.
- 422 :unprocessable_entity for generic validation errors where user should review submitted data and try again. Think extra hard about how to standardize the response so that you can inform the user about the exact (possibly nested, array) field that is problematic. "Dig" string a-la "data", "users", 0, "email" is useful to specify the "path" inside the submitted structure.

The story

Today I was struggling with legacy API comms.

The logic was simple

if response.code.between?(200, 299)
  yay_success
else
  ...

But responses like

{"success":false, "message":"ERR: No vendor found for ABC"}

and even

{"success":true, "message":"ERR: No item found for 123"}

were naturally tripping us up, because apparently parsing the response JSON is now also necessary. This is further complexed by lack of docs and consistency, some endpoints respond with "OK", which is not valid JSON, sigh.
It would be really nice, if responses of problems of this kind were not of the 2** group, but a 422 or somesuch. In that case knowledge and parsing issues for the body become irrelevant, things become slef-documenting™, yada, yada.