DEV Community: Aleksandr Korolev

Ruby: Pass-by-Reference-Value

Aleksandr Korolev — Fri, 26 Dec 2025 09:33:46 +0000

Most Ruby developers are likely familiar with 'Pass-by-Reference-Value'. And if you see something like this:

var1 = "Hello, World"
var2 = var1
var2.gsub!("World", "Ruby")
print var1 # => Hello, Ruby

You can easily figure out what's going on.
But how about a more complex example:

class DummyClass
  attr_accessor :value

  def initialize(value)
    @value = value
  end
end

dummy = DummyClass.new("Hello, World!")

puts "Before service action:"
puts dummy.value

class ServiceClass
  def initialize(value)
    @value = value
  end

  def perform_action
    local_value = @value
    local_value.gsub!("World", "Ruby")
  end
end

service = ServiceClass.new(dummy.value).perform_action

puts "After service action:"
puts dummy.value # => Hello, Ruby!

In this particular example, it's still quite clear, especially after the first example. But it might be a totally different situation when you work on a real project.

The Real-World Trap

While the behavior is clear in a small snippet, it becomes a stealthy bug in a production environment. I recently encountered this while working with:

an ActiveRecord model with a string attribute;
a service for interpolation strings;

The goal was to replace placeholders (e.g., %%BRAND%%) within a template string. The implementation looked something like this:

Interpolator.custom_interpolate(source, brand_name)

Semantically, a method named interpolate suggests it returns a new string. However, because the service used a mutating method (like gsub!) on the source object, it accidentally updated the ActiveRecord model's attribute in memory before the model was even saved.

The Takeaway

Even if you understand Ruby's object model, it is incredibly easy to overlook side effects when passing objects through multiple layers of abstraction. When in doubt, use non-mutating methods or explicitly .dup your inputs to ensure your "read-only" data stays that way.

You stub/mock incorrectly

Aleksandr Korolev — Mon, 13 May 2024 15:47:26 +0000

No one needs to read again about why tests are important and we use tests in all languages and frameworks. And you've probably faced the need to mock some calls or objects during testing.
But firstly, let's refresh our knowledge about these ideas:
mock objects are simulated objects that mimic the behavior of real objects in controlled ways, most often as part of a software testing initiative (from Wikipedia).

In Ruby, we have some utilities that provide abilities to mock anything that you need to mock easily. I will use Rspec for my example.

Just imagine that we have the next code:

class Survey
  class Client
    def publish
      true
    end
  end

  def initialize(client:)
    @client = client
  end

  def publish
    @client.publish
  end
end

And we need to test this class, the straightforward approach can be next:

require "./survey"

RSpec.describe Survey do
  it "publish survey" do
    client = double("client")
    expect(client).to receive(:publish).and_return(true)
    Survey.new(client: client).publish
  end
end

Looks good, the test passes, but what if we change the method for Survey::Client from publish to boom:

  class Client
    def boom
      true
    end
  end

what will happen?

 rspec ./survey_spec.rb 
.

Finished in 0.01933 seconds (files took 0.30562 seconds to load)
1 example, 0 failures

it passed, how can it be? The answer is - double.
How can we fix the problem???

Solution 1 (old school)

What I don't like in languages like Ruby is all objects are quite wage and you need some mental energy to keep track of what really happens in your code. What does Survey expect as an input parameter? Survey::Client? It's easy to think like this but in reality, it accepts any object with a specific interface. So what we send as a parameter to Survey should play a role. Thus in order to avoid this problem we need to check if our client can play this role:

# add a shared example
RSpec.shared_examples "PublisherRole" do
  it "should response to publish" do
    expect(object.respond_to?(:publish)).to be true
  end
end

# add test for our client

RSpec.describe Survey::Client do
  let(:object) { Survey::Client.new }
  include_examples "PublisherRole"
end

and now we get:

$ rspec survey_spec.rb 
.F.

Failures:

  1) Survey::Client should response to publish
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }

       expected true
            got false
     Shared Example Group: "PublisherRole" called from ./survey_spec.rb:17
     # ./publisher_role.rb:3:in `block (2 levels) in <top (required)>'

Finished in 0.05281 seconds (files took 0.34183 seconds to load)
3 examples, 1 failure

Failed examples:

rspec ./survey_spec.rb:15 # Survey::Client should response to publish

Solution 2 (use RSpec specifics)

What allows you to achieve the same result with less code? - instance_double:

RSpec.describe Survey do
  it "publish survey" do
    # use instance_double instead of double
    # client = double("client")
    client = instance_double("Survey::Client", publish: true)
    expect(client).to receive(:publish).and_return(true)
    Survey.new(client: client).publish
  end
end

Conclusion

The main idea of my post is - to be aware of what you have and how you test it. Try to think maybe in one level up, not just test direct calls and objects.

AWS Lambda + Athena + RDS

Aleksandr Korolev — Wed, 21 Feb 2024 16:26:19 +0000

I suppose that it is not a secret now that Serverless is quite popular nowadays. I still prefer to use a more old-school approach with the classic applications (in my case Rails apps) but it turned out quite convenient in some cases.

So what was the task:

write the Lambda that should read data from the Athema table and check and do some stuff.

When you create a lambda by default it has very limited permissions. If you want your lambda to make requests to Athena tables you need to add next permissions:
- "athena:StartQueryExecution" - "athena:GetQueryExecution" - "athena:GetQueryResults" - "athena:GetDataCatalog"
that allows a lambda call athens APIs, but probably you will need to add more: permissions for S3 and in some cases for Glue.
But if you have datacatalog that reflects any RDS tables you have to add special permission:
- "lambda:InvokeFunction"
because access to RDS tables happens via a special lambda connector. Unfortunately, the error message doesn't explicitly say about it, requests just fail if a lambda doesn't have this permission.

Rails: has_many relationships by two columns

Aleksandr Korolev — Tue, 29 Aug 2023 09:53:38 +0000

You probably use has_many relationships very often. This stuff is very useful and helps to reflect a lot of relationships from the real world. For example, a car has many parts:

class Car < ApplicationRecord
  has_many :parts
end

On database level, the Parts table should have a link to the Car table, usually some sort of foreign key ( car_id column in the Parts table).

But what if you need to create a has_many relationship by two columns?

Let's imagine that we have next: except Car, there are next models:

class Inventory < ApplicationRecord
  # it stores all possible parts that we can use for your cars
end

class CarInventory < ApplicationRecord
  # join model
  belongs_to :car
  belongs_to :inventory
end

class Analogs < ApplicationRecord
  belongs_to :car
  belongs_to :inventory
  has_many :inventories
end

Our task is to be able to get all analogs for a specific detail.
The simplest way is just to add a link to the CarInventory in Analog model - create a database migration and probably data migration).
But we use pure SQL we can fetch required data without any changes:

SELECT *
FROM Analogs as an
JOIN CarInventory as ci on ci.inventory_id = an.inventory_id and ci.car_id = an.car_id
WHERE ci.car = <car_id> and ci.inventory_id = <inv_id> and ci.id = <car_inventory.id>

In order to achieve this we can write the next code:

# in CarInventory model
has_many :analogs, ->(car_inventory) do
    Analog.where(car: car_inventory.car, inventory: car_inventory.inventory)
  end, through: :Inventory

The example probably doesn't reflect real life but I hope can reveal the idea.

Breaking interfaces

Aleksandr Korolev — Tue, 18 Jul 2023 08:12:47 +0000

Let's imagine that we have two apps:

App A - a server or a data source - this app should initiate the process.
App B - a client or service - this app serves the specific aim.

Initially, App A sends some data to App B (just HTTP request) and App B then sent a request to App A in order to get additional info that App B needed for the process of the request from App A. It sounds like it was too chatty and it was it.

Once upon a time, we decided to fix this communication approach in a way where App A will send all required info in the first request and App B will not need to request any additional info. Sounds reasonable, doesn't it?

Here, one problem pops up in our heads - backward compatibility. Because both apps are under our control, we decided that we can make breaking changes and not support both implementations at the same time. It sounded doable - proper testing, sync deployment, not a big deal...

The day of deployment had come and we executed your plan. Test on production - works fine, all sides are happy.

But in 2 days our operation team reported that something was wrong with data acquisition. Here I have to add some technical details: App B generates an HTML page that has a link to React app, and this page goes to the advertising network (a tag in the DSP world). The React app also was changed because the interface and corresponding data structure were change. Thus tags that are live had links to the updated React app but this new version cannot work with old data structure.

We had to roll back changes for React app and use an explicit version in the new implementation.

What is your approach in such a situation? Do you support old versions of interfaces or small "fire" can be acceptable?

Tools: quickly connect to pods in your Kubernetes cluster

Aleksandr Korolev — Wed, 18 Jan 2023 15:43:23 +0000

It seems that almost all companies use or try to use Kubernetes. And you, as a developer, need from time to time connect to your app, but when it is in a Kubernetes cluster, it is not so simple.
How it can look like in your case:

# switch to appropriate context 
kubectl ctx your-context
# get pods
kubectl -n namespace get pods
# connect to the pod
kubectl -n nameapce exec -it pod/#{pod-name-from-previous-step} -- bash

Do it every time - tedious, isn't it?
In my team, we are using next script:

#!/bin/bash

# how make script executable

# chmod +x k8s.sh

# this is necessary to split the command output on new lines

IFS='

'

show_help () {

  echo "Usage: k8s.sh [environment] [SUBENV] - ssh to a pod from the environment-subenv"

  echo "Example: k8s.sh staging web - connect to the web pod in the staging environment"

  echo "It uses current directory in order to build the pod name"

}




if [ "$1" = "-h" ] || [ "$1" = "--help" ]; then

  show_help

  exit 1

fi




ENVIRONMENT=$1

SUBENV=$2




working_dir=${PWD##*/}

project=$(echo "$working_dir" | tr '[:upper:]' '[:lower:]' )

namespace="$project-$ENVIRONMENT"




kubectl ctx |  grep "$ENVIRONMENT" | tr -d '\n'  | xargs -0 kubectl ctx




output=$(kubectl -n "$namespace" get pods | grep "$SUBENV" | Head -n 1)

podname=${output%% *}; remainder="${remainder#* }"




echo "ssh-ing you into $podname . . ."




kubectl --namespace=${namespace} exec -it pod/${podname} -- bash

It allows easily connect to pods from a specific namespace (a namespace depends on current directory - current project).
Subenv is necessary because we have different types of pods (web, activejobs, migration).

Don't like long, verbose Docker-compose command?

Aleksandr Korolev — Tue, 22 Mar 2022 08:08:56 +0000

Nowadays many developers and companies use Docker and Docker-compose in everyday live. I don't want to repeat what Docker is and why you might want to use it. But what I don't like when I work with Docker (if be more precisely with Docker-compose) - verbosity of commands.

It is hard to argue that Docker-compose provide good alternative compare with pure Docker interface but commands are still long and verbose. "It is not a problem" - you could reply, - "just add appropriate alias for the command and save time and effort". Yes, right, it can help in terminal but you are as a developer probably use IDE or at least text editor and often you have mechanisms for interact with your application somehow: run test, initialise building process etc. And not all IDEs and text-editors know how work with Docker.

From my point of view, the ideal setup is when you don't need to think about if you use Docker or not. For example, I need to run my tests with rspec (I'm a Rails-developers and all examples below are from Rails world), it would be great not to think about what should I do in order to run them - my habit is rspec path/to/specs but when my app is in Docker I should do something like this:

docker-compose run -rm container-name command

And in this case this utility can safe us.
DIP has two possible modes:

dip your_command - in this mode you just need to type dip before your command, something like this: dip rails c
your_command - DIP can be injected into the current shell and it analyses current directory if there is an dip.yml file, if the file is exist it runs a command in docker if not in a shell. But before this sunny live you need to create dip.yml - a configuration file when you should make mapping specific commands to appropriate container.

Possible pitfalls:
I use vim for development and by default vim didn't use dip when I tried to run command from vim. The problem was in an approach which vim uses when run external command - it doesn't load your shell's profile by default. In order to force it I've added next to my .vimrc

set shell=bash\ -l

Rails design pattern

Aleksandr Korolev — Thu, 18 Nov 2021 10:13:40 +0000

If you are a Rails-developer you know at least MVC pattern. Most of us know of course that it has some limitations in terms of structuring your code (fat controllers/models) and in some point of your developer's path you start thinking about code quality and here I mean not code style and other minor things but more general - single responsibility principal (SRP) and how we can organize code in order to make it real, Liskov’s Substitution Principle etc.

Ok, we have spotted a problem and what can we do with it?
As you can have noticed - SOLID principles and general OO design are our tools. But they are too general. Are there something more specific? Googling will provide you at least next possible patterns:

Builder
Decorator
Form
Interactor
Observer
Policy
Presenter
Query
Service
Value

I am not going to retell them, you can easily find definitions. But I want to light on next moment: how many from them you are using in yours projects? Is it straightforward which pattern you need to use?

Let take for example Service and Interactor:

The service design pattern breaks down a program into its functional constituents. Each service object completes one task, such as running payment for a customer, completing a bank transaction, etc.

You can use the interactor design pattern to split a large task into a series of small, inter-dependent steps. If any of the steps fail, the flow stops, and a relevant message appears about why the execution failed.

The definitions are different but the aim is the same - breaks down something big into small blocks. From my point of view, the interactor pattern is a special case of service.

class AuthenticateUser
  include Interactor

  def call
    if user = User.authenticate(context.email, context.password)
      context.user = user
      context.token = user.secret_token
    else
      context.fail!(message: "authenticate_user.failure")
    end
  end
end

This excerpt was written in context of interactor gem.
and

class AuthenticateUserService < BaseService
  def perform
    if (user = User.authenticate(context.email, context.password))
      success_result(status: :success, message: nil, data: user) # this method as and error_result are implemented in BaseService
    else
      error_result(status: :error, message: user.errors, data: {})
    end
  end
end

Does it look similar? From my perspective, they are not different patterns but one pattern with slightly different implementation.

Let's take anther one confusing couple: Decorator vs Presenter:

The Decorator pattern adds new functionality to an existing object by wrapping it with additional objects containing the new features. This helps to modify an instance of a class for extra features and not define new static subclasses in the code.

The Presenter design pattern aims to isolate view rendering logic from the controller and model and encapsulate it into a reusable component. It makes the controller and models leaner and enhances code readability.

Let's take a look into code snippets:

class PostPresenter
  def initialize(post)
    @post = post
  end

  def image
    @post.image? ? @post.image.url : 'no-image.png'
  end

  # similary define other methods with their logic

end

class Car
  def roof
    "fixed"
  end
end

class ConvertibleDecorator < SimpleDelegator
  def roof
    "collapsible"
  end

  def self.decorate(car)
        new(car)
  end

 private

 def model
   __getobj__
 end
end

#using 
basicCar1 = Car.new()
basicCar2 = Car.new()

basicCar1 = ConvertibleDecorator.decorate(basicCar1)

puts(basicCar1.roof) # => collapsible
puts(basicCar2.roof) # => fixed

You can argue that is different approach... but I would like to say - different implementation but the aim is the same. Both examples are trying to separate some additional(auxiliary) logic in separate place. And there are other way for do it, for example:

class Car
  def roof
    "fixed"
  end
end

module ConvertibleDecorator
  def roof
    "collapsible"
  end
end

#using 
basicCar1 = Car.new()
basicCar2 = Car.new()

basicCar1 = basicCar1.extend ConvertibleDecorator

puts(basicCar1.roof) # => collapsible
puts(basicCar2.roof) # => fixed

Some other patterns are more straightforward and not so confusing. But the main idea of the post is:

try to use general principle when you structure the code (SOLID);
not use patterns because it is just the best practice but when you can see that it makes sense; if you cannot match you class with one of this patterns it is ok if you use something new what related to you problem (often developers see Services in a project and try to put all new classes there however it can be QueryObject or ValueObject).

The definitions of the patterns and part of examples were taken from here

MySql: Shrink DB partially

Aleksandr Korolev — Tue, 25 May 2021 13:10:54 +0000

Prerequisites

We have a Rails application and with time some tables in our Database (DB) became too big. For example, one of them is 2.7Tb, another one which is in use with high frequency has a size 5.5Tb. This fact with some not optimal structure of DB brought us problems with operating data. We had implemented the process for deleting old data from the DB but when it runs it is impossible to do everyday work with data — the application is struggling a lot.
We had decided to cut some tables totally (if be more precisely leave just data but 3 months) and rest copy totally. The main question was how can we do it without long downtime. Even if we cut the biggest tables it would be around 500Gb.

Initial idea

The difficult part of the process was partially copying data from the same tables. The simple way which goes to mind is to stop the application, delete data, run optimize table. But with our size, it takes too long. So another brave idea was nominated: create a replica, initialize it only with tables which we need fully, and start replicating from scratch those which we want to reduce. “Hm… sounds cool”: thought we, the man who had met replication only in the format press button create a new replica in AWS.

So we’ve created a new instance in AWS RDS, copied the schema of the database, took Percona pt-table-sync (https://www.percona.com/doc/percona-toolkit/LATEST/pt-table-sync.html) for copying the tables which we wanted to have fully, and setup external master for replication with https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_set_external_master.html this function (we used this because the standard way for making replication on AWS RDS makes snapshots).
We’d started with a staging environment and it looked like a working solution. However, Percona recommends using replication for copying data we used direct mode because pt-table-sync tries to set up replication mode to STATEMENT but RDS doesn’t allow it from SQL command.

Problems

It’s time to try the same on the production. We’ve made all the same steps, run the replication but at the same time got the replication error: 1032 HA_ERR_KEY_NOT_FOUND. Googling and reading documentation gave us the view that a table has no record which should be updated. You can say: but you’ve said that worked for staging. Yes, it worked sometimes but we didn’t pay attention to this after a long time and also environments have some differences (not all background jobs work on staging and loading much less).
But these errors happened on tables which we wanted to reduce, thus we can ignore it — we thought. MySQL allows you to ignore any errors by simply setting a list of these errors in the config file:

slave-skip-errors=1032,1062,1146

Cool, let’s do it. But wait, we are using RDS and don’t have the ability to change MySQL settings directly. Even more, you cannot do it through a parameters group. What AWS allows you to do is skip just one error at a time — we had thousands.
Game is up? No! Engineers never give up we’ve made from steel.

Final solution

We appreciate the care of AWS about us through limitations. If we cannot do it on RDS what if set up our own MySQL server — no problem. We’ve run a new EC2 instance, installed the MySQL — here we can do all that we want!
So the idea was: set up a replication process to the main DB and ignore all those errors that interrupted us on the RDS instance. After 3 months of replication, we will be ready for using this database. But we don’t want to use a standalone server, we want to continue to use RDS. For this step we considered two possibilities: 1) use mysqldump and setup replication on a new RDS instance from the same point at which we make dump 2) use AWS DMS service.

Look to the process more details:

Setup standalone MySQL server
Make a clone of the source database through the process of creating a Read replica on RDS
Stop replication on this replica (remember the point in binary log when replication will stop)
Dump database with specific tables
Load dump to the database on the standalone server.
Setup the replication process from the point at which we stop it on step 3.
When we have enough data to switch to the new DB — stop replication on a standalone server (also need to remember the point of the replication process).
Initialize a new RDS instance with data from the standalone server.
Setup replication at the same point but for the main server for catching up on new data which can be written while we load data to a new RDS instance.
Switch the application to the new database.

Conclusion

It is not a proper way of using replication, thus it can bring some troubles during the process. Some additional steps were involved because of the limitations of MySQL.
But the main outcome: try to not allow DB to go in this direction when you cannot work with it smoothly.

Rails find_each/ find_in_batches pitfalls

Aleksandr Korolev — Mon, 17 May 2021 12:27:33 +0000

Every rails-developer knows about method find_each or find_in_batches (if you check the implementation for the first one you find that it uses the second one under the hood) from ActiveRecord. Even more, it is a good practice to use these methods when you need to iterate throw a big amount of records in DB.
If you don't familiar with it you can check this https://apidock.com/rails/ActiveRecord/Batches/find_each.

Looks like, we always can/must use find_each instead of each when we need to iterate throw some bunch of records. We also thought this way. But one of our applications struggled with DB: load for DB was around 95%, it was obvious that DB is a bottleneck.

I'd started to analyze slow-query logs in MySQL and reports in NewRelic. It was quite simple to find the place in the code which produce this SQL query:

 Survey.select(:id, :offer_uuid).active.where(provider: provider).where.not(survey_id: current_surveys).find_in_batches(batch_size: 10) do |survey_batch|
  DeactivateSurveysService.perform(survey_batch, provider)
end

Because of using where.not MySQL should fetch all records in order to sort them by id (this sorting used in find_each/find_in_batches) and only after this takes 10 records - it can very slow if a scope of the records is big how we had.

CONCLUSION

It is good practice using find_each/find_in_batches in order to not consume a lot of memory but need to be aware of what resulting SQL is.