DEV Community: Alexandre Ignjatovic

Ruby's discreet argument forwarding shorthand...

Alexandre Ignjatovic — Fri, 08 Mar 2024 09:14:22 +0000

Yes, those three dots are intentional. Yes it's a pun. No I won't stop. Yes, you'll understand if you read this article to the end.

The problem

Have you ever ended up writing tons of methods doing mostly parameter forwarding?

class Foo
  attr_reader :bar

  # That's the one:
  def do_stuff(x, y:)
    bar.do_stuff(x, y:)
  end
end

Ruby's Forwardable module may be the solution to writing simpler code:

require 'forwardable'

class Foo
  attr_reader :bar
  extend Forwardable
  def_delegator :@bar, :do_stuff
end

But what if I'd like to "do stuff" twice? Or add a log line?

Triple dots to the rescue

Recently, I learned that Ruby includes an argument forwarding shorthand since its version 2.7! (Which exists since 2019)

The syntax

This shorthand is .... Simple as that, and you can add your log line without bothering with how the arguments are going to evolve in the future:

def do_stuff(...)
  puts 'My log line'
  bar.do_stuff(...)
end

The good thing is: if bar#do_stuff is added another argument, my foo#do_stuff method do NOT have to change!

Leading arguments

But what if I'd like to access one of the arguments before forwarding it?

Since its version 3.0, Ruby gained support for leading arguments:

def do_stuff(x, ...)
  bar.do_stuff(x, ...)
end

Hope you'll use it a lot...

Efficient time management for curious Techies

Alexandre Ignjatovic — Fri, 22 Sep 2023 16:35:18 +0000

Oh great, another article explaining how to be a turbocharged productivity monster...

No.

In this article, you won't learn how to become the proverbial 10X developer, or how to be the fastest DevOps of the planet earth.

Because the secret to efficient time management is not doing more, it's actually doing less (and if you don't want to read this long form article, you can skip to the 'wrap up section' ;) ).

As a tech person, your activities usually can be split in 3:

Build: Adding new things to your stack, software, infrastructure, team
Run: Fixing bugs, Running your software, keep things updated
Learn: Grow your expertise, in order to solve new classes of problems

This is true for devs, DevOps, SREs, engineering managers, and probably most of the jobs you can imagine in tech.

Considering this, efficient time management boils down to two things:

Be pragmatic and don't waste time by doing useless tasks
Preserve the balance of your investment between Run, Build and Learn

A time for building

Happily write pragmatic software

Software is immaterial, so how can I be pragmatic while crafting it?

My answer to this is dead simple: challenge the why and the impact of the project

Why am I building this?

If the answer to this is not serving the company's mission, you are wasting your time.

When you answered to this question, if you still don't know if your company need this, use the 5 whys method. If your answers don't climb up to the company strategy after 5 steps, you are most probably doing something useless.

And killing useless tasks is the easiest way to free up time for more relevant tasks.

Estimate project impact

Software is a tool, and not a end goal in itself.

Identify your end-user. Measure what you are willing to change and estimate impact.

A common bias is seeing problems closer to us as more important than problems that don't impact us. Challenge that inclination by estimating business impact of fixing both.

In one of my teams, there was 2 competing productivity problems to solve:

The test suite of the CI was running in 40 minutes, which was painful and frustrating for developers (they had to wait 40 minutes to know if the CI was green and if their work was finished)
The Customer Success Manager team had no proper tools, and were wasting time on brainless tasks

The CI problem was raised at almost all developers' retrospective meetings, and was considered by most of the team as the most pressing problem to solve.
Nobody ever spoke of adding admin tooling for CSMs people.

I taught my team to do a reality-check when setting up priorities by adding numbers:

I opened GitHub in front of them: Each dev was producing one or two PR per week. There was six devs in the team. In a month, that makes 36 opportunities for the whole dev team to tackle another subject (self-training, small bugfixes, quickwins, etc) while the CI runs. This is 24 hours, where devs had to work on "something else than my current task" (easily fixed by giving each of them backlog of tiny tasks to juggle with)
Each people of the CSM team was doing between 200 and 500 phone calls a month. There was 3 of them, which makes around 1000 calls per month. Each call needed to be prepared a couple of minutes ahead (for full context) and could last from a few seconds (if the user does not answer) up to half an hour. Each time a user does not answer the CSM person, it means 2 minutes and 30 seconds have been just lost by that CSM. And conversion rate was very low (less than 1/3 of the users were answering). Each month, CSMs were losing more than 40 hours working on users that never answered calls

The farthest problem, was deemed the less important by the team, but was costing way more to the company than the closest problem.

Ultimately, we found a way to provide a properly ordered list of people to reach out for the CSMs (the most likely to answer at the top of this list), and this led to a tremendous decrease in time spent waiting for users to answer.

Understand exactly what you have to build and deliver

Spending time on something that will not be used is a waste of your time. If you spent a day working on something "that we are going to need in the future", I can guarantee you that you could have more fun and have pretty much the same impact by going to the park.

Things that we build "because we may use it at some point" are useless today, and will probably stay useless forever.

Don't build for the future. Solve your actual problems instead of your probable future problems.

Also be sure to double check your understanding of what needs to be built with your stakeholders. You don't want to spend time on something that nobody is waiting for.

Before climbing a mountain, prepare for mountain climbing

To go for a short 1 hour walk in the city, you only need a handful of things: your keys, some change and you are good to go!

But it would be foolish to climb the Everest with only your keys and a few coins.

It's pretty much the same things with tasks: If you start a huge task with no preparation, it's going to end up badly.

As a preliminary task to your huge task, split your huge task in more manageable tasks, and schedule them. If your split tasks are still huge, do it again!

This is what I do when I write a long form article. I split it into several manageable task that I can do under an hour. For example, for this article, I went:

Brainstorm: Collect ideas and tips about time management
Structure: identify my main messages and the plan of the article
Write: Write each section of the article
Edit: Review and edit the article once it's fully written
Publish: Success!

A great side effect of having planned the execution of this task was the ability to pause/resume. Since the plan is written down, I can work on something else without forgetting about what I wanted to write next.

Which leads us to my next advice: Always go from abstract to concrete

If you notice that you are already deep down in the implementation details without having yet figured out the global plan of execution, you need to take a step back.

Don't start the work on the architecture if you are not 100% clear on the requirements. And don't work on the code if you are not 100% clear about your architecture.

A time for operations

Run this software without blasting your productivity

Writing code is cool, but it's nothing if you don't end up with users.

It's OK to build things that are not meant to be deployed as a production environment, as long are you are aware that you are just "practicing".

And as soon as you have end users, you have to keep the pot boiling.

Let's see what we can do to avoid spending too much time on this pot.

Measure operations time costs and optimize your run

While keeping a production up, some things are significative time sinks.

When facing such situation, I ask myself the following questions:

Is this task useless? (kill it)
Can somebody else do it? (delegate it)
Can something else do it? (automate it)

Example: If your support team is asking quite often your tech team to investigate why some users can't use some features of your product, you can either delegate (teach your support team to understand your product configuration and workflows) or automate (build a technical diagnostic page).

Batch small mindless operations to save your deep work time

One underestimated time thief is the context switching. It's commonly accepted that you need between 15 to 30 minutes to be properly focused on a topic while doing deep work (coding or writing for example).

Assuming you worked on 8 different topics on a single day, that's between 2 and 4 hours of concentration time gone with the wind.

If you need to achieve deep work, don't multitask, and avoid context switching.

But wait, there is more!

Let's say that you decided to dedicate your whole day to a deep work task.

Breaking news: you need to refocus even after the most trivial mundane interruption.

Your coworker ask you a question about a technical detail? at least 15 minutes were just tossed into the bin. Your support team ask you to start some jobs in production 8 times in a day? Again, that's between 2 and 4 hours of time lost in refocusing.

The easy solution is to batch non-urgent but important & trivial tasks that don't require deep focus. This way, you limit the interruptions of your deepwork, and you'll get more done at the end of the day (or you will be able to get home earlier, which is a nice bonus, innit?).

A time for learning

Don't let run and build tasks preventing you from growing, for yourself and your company

While working in tech, you will have to work with lots of different stakeholders:

Your project or product manager want you to build tons of things, as fast as possible
Your end users want to use a reliable and nice tool
Your manager want you to reach the goals he gave you
And yourself as well are a stakeholder, since you want to grow and be successful in this company and in your career

The trap is, while trying to meet expectations of all your other stakeholders, you end up being quite the busy person, and you probably forgot to be the own stakeholder of your personal development.

Don't do that! Reserve time for your growth.

Also, be sure to have a sensible training plan: curiosity is not a purpose. Make the better out of your learning time by investing it into something that will serve you, not something shiny.

Learning about a cool tech that nobody heard about 1 year ago is a bet. Sometime you can win and be one of the first to be fluent in an interesting emerging technology, but if can also be a major waste of time.

So before learning about cool tech, learn about plain old boring ones ;)

Understand your ecosystem

Some company value a lot personal learning time, especially if it serves the company mission. Some other don't. and expect you to grow on your own personal time.

Be sure to understand for which of those two you work for.

And once you know, reserve, formally, some time for learning. Your internal stakeholder will thank you later.

Wrap up

Here is a digest of the time management principles I use on a daily basis:

Understand the why
Challenge tasks usefulness
Set priorities based on impact
Do a reality-check from time to time
Reserve time for deep work
Reserve time for batch of brainless tasks
Reserve time for learning
Split big tasks in smaller tasks
Eat the frog in the morning

What are yours?

Learn about Ractors and build a mini sidekiq

Alexandre Ignjatovic — Wed, 10 Mar 2021 10:31:35 +0000

In this article, you'll learn more about Ractor, and how you can use them to build your own clone of sidekiq (a background processing framework for Ruby).

What is Ractor?

Ruby 3.0 introduced the Ractor class. This is Ruby's Actor-like concurrent abstraction, and its goal is to provide a parallel execution feature of Ruby without thread-safety concerns.

According to wikipedia:

The actor model in computer science is a mathematical model of concurrent computation that treats actor as the universal primitive of concurrent computation.

Actors are able to:

Create more actors
Receive messages
Send messages
Take local decisions

Be aware that the Ractor implementation is not stable yet, do NOT use them for production code. See the warning displayed when you use them if you still need to be convinced to not use it (yet) in production:

warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.

Creating a ractor

Creating a ractor is as simple as using Ractor.new:

ractor = Ractor.new { puts 'Hello Ractor!' }

Receiving a message

There are two ways to receive a message, depending if you have a reference on the ractor sending it.

Use Ractor.receive if you don't know who is sending the message:

message = Ractor.receive

And use Ractor#take if you have a reference on the ractor sending the message:

message = ractor.take

As those method calls are blocking until you receive a message, avoid expecting a message from a ractor that will never send one, or your program is going to be stuck forever.

Also, please be aware that the objects you are sending must be shareable.

Sending a message

If you know your recipient:

ractor.send(message)
# or
ractor << message # `<<` is an alias to `send`

And if you don't:

Ractor.yield(message)

Ractor.yield is blocking as well until some ractor receive your message.

Taking local decision

You can do pretty much anything you want in the block given to Ractor.new. Unless accessing shared objects. An exception will be raised if you try to use a variable defined outside of your block. In order to share a variable between several ractors, you can, for example, use the Ractor::TVar gem.

Another interesting method I'm going to use later on is the Ractor.select(*actors) method. It takes several ractors as an input, and returns the first ractor to send something, and its output:

slow_ractor = Ractor.new { sleep 2; Ractor.yield(:too_late) }
fast_ractor = Ractor.new { Ractor.yield(:fast) }
ractor, output = Ractor.select(slow_ractor, fast_ractor)
# output == :fast && ractor == fast_ractor

Let's build a mini sidekiq!

Please be aware that this crude POC will only allow you to use a pool of 10 ractors to achieve parallel execution of jobs. It won't handle error flow control, statistics, queueing and all the other features that make sidekiq a super useful project.

We'll build a simple design with:

A WorkerPool, taking care of our pool of ractors
A Job base class, that all our dedicated jobs will inherit from.

The goal being to allow people to easily implement their own jobs without having to handle all the pool logic.

WorkerPool

class WorkerPool
  attr_reader :ractors

  def initialize
    @ractors = 10.times.map { spawn_worker }
  end

  def spawn_worker
    Ractor.new do
      Ractor.yield(:ready)
      loop { Ractor.yield Job.run(Ractor.receive) }
    end
  end

  def self.run(parameters)
    ractor, _ignored_result =
      Ractor.select(*(@instance ||= new).ractors)
    ractor << parameters
  end
end

There is a trick here. When using Ractor.yield(:ready), we are just making sure that the ractors of the pool have something to send for the initial Ractor.select to work (remember, it's blocking).

Job base class

class Job
  def self.process(*args)
    WorkerPool.run({ class: self, args: args })
  end

  def self.run(hash)
    case hash
      in { class: klass, args: args }
      klass.new.process(*args)
    end
  end
end

Be aware that anything you will provide as argument must be shareable.

Implementing a specific job

Let's say that we'd like to create an asynchronous job that prints something:

class PrintJob < Job
  def process(message)
    puts message
  end
end

Using it asynchronously is now as simple as:

PrintJob.process('Hello World!')

Conclusion

Ractor introduces a new and interesting model for parallel execution in Ruby.

If you found the ractor topic interesting, I suggest you check out these interesting resources:

And if you liked this post, check out our awesome weekly tech newsletter. We are regularly sharing top ruby & javascript content!

Photo by Mark Thompson