DEV Community: Augusts Bautra

Thoughts on Codingame 2026 Spring challenge

Augusts Bautra — Mon, 25 May 2026 09:24:06 +0000

Thoughts on Codingame 2026 Spring challenge (Trolls in woods)

I liked the challenge a lot, the most enjoyable experience so far! I even reached legend league, a first or me, placing 60th/2k (dangit, lost best Rubyist spot at the last minute).
Kudos to developers for interesting mechanics and nice graphics. Of particular note was the good mix of static VS dynamic elements in the game world - the grid never changes, which is a relief! And various QoL features such as turn time exceeding allowance, input data copying etc.

Some citicisms:

As always, the game docs could have been more detailed, for example, what are the conditions for early termination of the game (no trees, and no score changes for a number of turns?), and how exactly is wood distributed if both players chop and workers have the same chop power, who gets a wood first?
It took too long to get new arena score, iterating in legend league was impossible for me, almost every change I tried in the final weekend resulted in a reduced score and it took 15mins to resolve. I blame this on excessive game length, maybe 250, 200 turns would have been sufficient.

I had good results with a mix of aggressive and passively scaling strategies - if I get ahead, I seek to hobble opponent's lemon gathering, preventing them from reaching my potential, and winning in the long run due to better points/turn; all the while being OK to invest several turns into growing trees and gathering significantly more resources if it's likely to pay off in the long run. I think the best scoring players leaned even harder into this, training not just one or two, but three and four workers, each even better.

My biggest struggle, as always, was the multi-agent aspect of this challenge. Preventing the workers from getting in each other's way was a problem I struggled throughout.

My bot is mere 2k lines, you have check it out here.

Plans as 1st class concepts

Using plain commands array and then puts commands.join("; ") may work for a while, but it becomes unworkable once multiple agents are in play and you need introspection like "is this agent doing anything this turn?" or "is any other agent already going here?".

Do yourself a favour and introduce a Plan concept like

Plan = Struct.new(:name, :worker_id, :type, :node, :weight)

Furthermore, distinguish "ultimate goal" from "command to result for this turn". This can help further improve plan collision (there's an interesting 2x2 possibility matrix here:

ultimate goals and turn command match, very bad
ultimate goals match, but turn commands differ (workers on different squares, no surprise), still bad.
ultimate goals differ, but turn commands match, uhg, gotta look for pathing alternatives or somesuch
ultimate goal and commands differ, yay )

Timing tracking

Save turn start time at the very beginning of turn.
Be able to tell how long you've taken so far. This allows early-termination in case of deep prediction or, inversely, using leftover time in simpler turns to do some pre-crunching for next turns.

In this challenge I used this technique to lazily pre-fill pathing to trees, since their positions only become available on 1st turn.

# @return Numeric # in ms
def turn_time_taken
  t1 = Process.clock_gettime(Process::CLOCK_MONOTONIC)
  elapsed_ms = ((t1 - t0) * 1000.0).round
end

# using a value somewhat lower than 50ms stated in rules for safety
# @return Numeric # in ms
TURN_TIME = 45
def turn_time_remaining
  45 - turn_time_taken
end

State VS de-novo

Say I see an opponent does something the bot should take note of and remember, to then use in later turns. This complexes spec setup and testing, necessitates an easy way to feed the internal state in initializer, which can get cumbersome.

Strongly prefer deciding on best move solely based on info given that turn, but sometimes memory is really helpful, YMMV.

Override #inspect

Does your main object vomit out hundreds of lines of irrelevant ivar data when inspected in console? Override its def inspect for what you need!

def inspect
  ivars = instance_variables - [:@row] # or whatever you want to hide

  attrs = ivars.map do |ivar|
    "#{ivar}=#{instance_variable_get(ivar).inspect}"
  end.join(", ")

  "#<#{self.class} #{attrs}>"
end

In Rails systems you can try the more targeted override for #pretty_print_instance_variables

def pretty_print_instance_variables
  instance_variables - [:@file]
end

Subpath memoization

This is big. Say you run your shortest path algo and it gives you a four-node long path [1, 2, 3, 4]. What you've actually gotten is all shortest subpaths - [1, 2], [2, 3], [3, 4], [1, 2, 3], and [2, 3, 4]. Memoize these alongside the main path!

Short-circuiting sorting

Consider sorting optimization that uses short-circuiting - if there is just one element in a collection, sorting it can be skipped altogether. This is useful if the sorting block does expensive things like pathing calculations:

def quick_max_by(&block)
  if one?
    first
  else
    max_by(&block)
  end
end

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.