Forem: Augusts Bautra

TIL: Lexical Fractional Indexing

Augusts Bautra — Tue, 28 Apr 2026 13:38:00 +0000

Today I got a task with one of those things™ again - allow users to order items in a list as they please with drag-and-drop UI.

I'd usually reach for integer :seq column and do a range update, it's performant enough for our needs and I don't need to worry about seq value drift, but today GPT convinced me that there might be a better approach - Fractional Indexing, specifically, it's Lexical variant where order values are strings, not integers (larger value-set, yay).

See https://github.com/sqliteai/fractional-indexing for reference.

The beauty of this approach is that it's O(1) - you only update the one item that changed place!

How it works

You define an alphabet, usually the ASCII-friendly base62 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz and when drag-and-dropping an item in a new position you provide :seq of both neighbours. Out of this we get three cases:

Placed first, there is only right neighbor. Assume left to be 0 or 1 as needed.
Placed in the middle, both neighbors present
Placed last, only left neighbor present. Simply increment left neighbor's :seq by half of alphavet size (31)

In all cases the algo is similar. Convert the neighbor seq lexical values to integers and find the middle value between them. Convert this middle value back to lexical expression and set that as the new :seq of the record. Done.

Over time the :seq values will grow in length to cope with no values being available in gaps, but in practice values should not exceed 10 letters and getting this would require hundreds-to-thousands of tactical worst-case gap repositions.

Implementation tips

I recommend setting a value regex constraint on the column if you're using Postgres, so expected alphabet is enforced.
Start sequences with at least "1" because if first record is of sequence "0", nothing can ever be put before it without updating it also.

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