Why real expertise still matters when the tools get smarter

Large Language Models (LLMs) have rapidly taken the spotlight in the tech community. They can seem magical when you first encounter them.

I think of them as powerful code editors with autocomplete on steroids..

They’re fast, adaptable, and incredibly knowledgeable. Need help recalling a rarely used method? Struggling with boilerplate code or syntax? Chances are, an LLM can assist you almost instantly.

However, beneath this impressive capability lies an important reality.

Without solid expertise in your chosen programming language (especially a nuanced one like Ruby), an LLM is merely guessing.

This isn’t to say it guesses poorly, but there’s a stark difference between functioning code and elegant, maintainable, idiomatic code.

‟ A sable brush and a glass palette mean little without knowing light, color, and composition.

A sable brush and a precision Mahl stick mean little without knowing light, color, and composition. ˮ

To illustrate, imagine handing someone exquisite painting tools such as a sable-bristle brush, a precision Mahl stick, and an elegant glass palette.

Without a foundational understanding of artistic concepts like composition, color theory, or lighting, these professional tools won’t produce a masterpiece. Instead, the outcome will be uninspired at best.

Coding, particularly in the Ruby on Rails ecosystem, mirrors this scenario closely. Ruby is nuanced and idiomatic, steeped in carefully honed community standards. Rails, in turn, has well-established conventions, methodologies, and best practices drawn directly from real-world usage.

An LLM might produce functional Rails code snippets, but without deep insight into why certain patterns and idioms exist, the resulting code is often shaky or insecure. This fuels arguments among developers:

• Pro-LLM enthusiasts argue passionately that these models herald the end of traditional coding roles, automating away human error and inefficiency.
• Traditional coders counter just as strongly that LLM-generated code lacks the depth and foresight required to build secure, stable applications. They worry that “AI-assisted coders” produce tools that are superficially functional yet fundamentally fragile.

Here’s my perspective:

As is often the case, the truth lies somewhere in the middle.

When you combine your deep, human understanding of Ruby’s idioms, design patterns, and Rails conventions with the speed and breadth of an LLM, something truly powerful emerges. The result isn’t just functional code; it’s elegant, maintainable, secure, and performant.

In short, LLMs become powerful assistants, enhancing-not replacing-the developer’s craft.

And that’s when things genuinely get interesting.

Just my two cents. 🙏

If you’re on this path and Ruby is part of your journey, it’d be my honour to share what I’ve learned over the years: 👉 https://www.rubycademy.com

Voilà!

My two cents on coding and LLMs was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forget Complicated Scripts, Ruby is Your Secret Weapon for Automation!

Scripting doesn’t have to be a headache. Ruby is uniquely powerful at transforming tedious tasks into quick, elegant solutions. Let’s dive deep into two realistic, everyday scripting challenges to showcase just how clearly and succinctly Ruby handles complex tasks.

CASE STUDY 001 — Compress Your Videos

Imagine finding yourself with a folder filled with large MOV and MP4 video files and needing an efficient way to compress them all. Here’s how easily Ruby accomplishes this:

video_files = Dir.glob("{*.mov,*.mp4}", base: "videos")

Dir.chdir('videos')

video_files.each do |video_file|
  file = video_file.sub(/\.(mov|mp4)$/, '_compressed.\1')
  
`ffmpeg -i #{video_file} -vcodec h264 -acodec mp3 #{file}`
end

Line-by-Line Explanation

The first line uses Ruby’s built-in Dir.glob method to efficiently find and list all .mov and .mp4 video files inside the "videos" directory. The curly braces {*.mov,*.mp4} represent a concise pattern that matches all files ending with either .mov or .mp4.

Next, Dir.chdir('videos') changes the current working directory to the "videos" folder, ensuring the script can execute commands directly on the listed files.

The video_files.each loop iterates through each collected video file, allowing actions to be performed individually on each one.

Within the loop, video_file.sub(/\.(mov|mp4)$/, '_compressed.\1') uses Ruby's powerful regular expression substitution to create a new filename for each video file. The original file extension (.mov or .mp4) is captured by the (mov|mp4) group and then reused (\1) in the new filename, prefixing the file extension with _compressed.

Finally, the command enclosed in backticks executes the external command-line tool ffmpeg to compress each video file using the specified codecs: h264 for video and mp3 for audio, writing the compressed output to the newly defined filename.

Ruby’s clarity, concise syntax, and expressive methods significantly enhance script readability, allowing developers to quickly understand and maintain their automation tasks with minimal effort.

CASE STUDY 002 — Bulk Renaming and Organizing Your Photo Library

Imagine having thousands of photos scattered in a directory, each with generic filenames like IMG_1234.JPG. You want to rename them based on the date stored in their EXIF metadata and neatly organize them into folders by year and month. Ruby handles this complex task elegantly:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'mini_exiftool'
end

require 'mini_exiftool'
require 'fileutils'

photos = Dir.glob("photos/*.JPG")

photos.each do |photo|
  exif       = MiniExiftool.new(photo)
  date_taken = exif.date_time_original
  
  next unless date_taken
  
  year_month    = date_taken.strftime("%Y/%m")
  new_directory = "organized_photos/#{year_month}"
  
  FileUtils.mkdir_p(new_directory)
  
  new_filename = date_taken.strftime("%Y-%m-%d_%H-%M-%S.jpg")
  new_filepath = File.join(new_directory, new_filename)
  
  FileUtils.cp(photo, new_filepath)
endruby

Line-by-Line Explanation

First, the bundler/inline method allows including the mini_exiftool gem directly in the script without needing a separate Gemfile.

The inline gemfile do block explicitly declares the required external gem (mini_exiftool) and sets the gem source.

The script then requires the necessary modules: mini_exiftool for EXIF data extraction and Ruby’s built-in fileutils for file operations.

photos = Dir.glob("photos/*.JPG") collects all .JPG photo files within the photos directory.

Within the loop, MiniExiftool.new(photo) creates an object to access the photo's EXIF metadata. date_time_original retrieves the original date and time the photo was taken.

The script uses next unless date_taken to skip files without EXIF date data, ensuring robust handling of incomplete data.

Using strftime, the script formats the date into a year/month structure (YYYY/MM) for the new directories.

FileUtils.mkdir_p(new_directory) creates the directory path (organized_photos/YYYY/MM) if it doesn't already exist.

The filename itself is formatted clearly as YYYY-MM-DD_HH-MM-SS.jpg.

Finally, FileUtils.cp(photo, new_filepath) copies the photo into the newly created directory with its new, meaningful filename.

Ruby turns this potentially complex and tedious manual task into a straightforward, maintainable script.

Conclusion

Forget complicated scripts in other languages. With Ruby, scripting becomes straightforward, powerful, and elegant.

Ready to simplify your scripting life?

Try Ruby. It’s fantastic and unbeatable.

Our first eBook:

🔗 https://gum.co/u/pjpkl7he

Voilà!

The Art of Ruby Scripting was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

A 500–800ms speed boost you didn’t know you had!

Modern web users are impatient — and who can blame them? We’ve all clicked a link, waited a second, and immediately questioned our life choices.

But what if we could make every link in your Rails app feel instant without adding a single spinner or loading bar?

Thanks to Turbo v8, we can. And the secret? Prefetching links on hover.

Let’s dive into what this means for you as a Rails developer using good old link_to, and how you can make the most of it — or disable it where needed.

Turbo v8 Prefetching: What It Actually Does

Turbo now prefetches pages in the background as soon as the user hovers over a link for more than 100ms. That means the content starts loading before they even click.

On average, this gives you a 500–800ms head start. And your app feels blazing fast.

Real-World Rails Example: A Learning Dashboard

Let’s say you’re building a learning dashboard in Rails, where users can quickly jump between “Today’s Lesson,” “Progress,” and “Leaderboard.”

Here’s how you’d typically render those links:

<ul class="sidebar-nav">
  <li><%= link_to "Today's Lesson", todays_lesson_path %></li>
  <li><%= link_to "Progress", progress_path %></li>
  <li><%= link_to "Leaderboard", leaderboard_path %></li>
</ul>

With Turbo v8 installed (included in Rails 7+ apps using Hotwire), each of these links will prefetch their destination page as soon as the user hovers.

No extra markup. No JavaScript needed.

So when the user finally clicks “Leaderboard,” it loads like lightning ⚡

Why Does This Feel So Fast?

Because most latency isn’t the page load — it’s the network roundtrip. Turbo removes that by starting the request early, while the user is still thinking.

This works especially well for:

• Sidebar or dashboard menus

• Article indexes

• Multi-step workflows (e.g., onboarding wizards)

When You Don’t Want to Prefetch

Some pages don’t benefit from this, or even suffer from it.

Say you have a link that triggers expensive database queries or a Data Export that takes a while to prepare... No point preloading it unless the user clicks.

Let’s imagine a Data Export page that takes a while to prepare.

You can disable prefetching for just that link:

<%= link_to "Data Export", export_path, data: { turbo_prefetch: false } %>

Turbo will skip prefetching this one while keeping the rest of the app fast.

Scoping: Enable and Disable in Sections

Imagine this layout:

<div class="admin-dashboard">
  <aside data-turbo-prefetch="true">
    <%= link_to "Overview", admin_overview_path %>
    <%= link_to "Users", admin_users_path %>
  </aside>

  <main data-turbo-prefetch="false">
    <%= link_to "Heavy Report", analytics_report_path %>
    <%= link_to "Export Logs", logs_path %>
  </main>
</div>

Here’s what happens:

• All links inside <aside> are prefetched.

• All links inside <main> are not prefetched.

This gives you precise control, letting fast, frequent links get the speed boost, while leaving heavier ones alone.

Bonus: Disable Prefetching for Mobile Users or Slow Networks

Want to be respectful to users with limited data?

You can disable prefetching dynamically using JavaScript:

document.addEventListener("turbo:before-prefetch", (event) => {
  if (navigator.connection?.saveData || isSlowConnection()) {
    event.preventDefault()
  }
});

function isSlowConnection() {
  return ["slow-2g", "2g"].includes(navigator.connection?.effectiveType)
}

This ensures you’re not fetching pages the user may never click, especially on metered or slow connections.

✅ TL;DR

• Turbo v8 prefetches links on hover, giving you ~500ms of perceived speed boost

• Works automatically with Rails link_to

• Disable globally with <meta name=＂turbo-prefetch＂ content=＂false＂>

• Disable per-link or per-section with data: { turbo_prefetch: false }

• You can re-enable selectively inside disabled areas

• Use turbo:before-prefetch to cancel based on network conditions

🧵 Final Thought

Prefetching might sound like a small optimization — but it’s one of those feel improvements that makes your app seem much faster than it really is.

The best part? You don’t have to change your app.

You’re already writing link_to. Turbo just makes it smarter.

Want more modern Rails tricks like this?

Check out RubyCademy where we turn everyday Ruby, Rails, and Hotwire into your superpower.

Voilà!

How link_to + Turbo Prefetching Speeds Up Navigation was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every developer knows the feeling: you’ve inherited a codebase that’s seen too many cooks in the kitchen. The classes are bloated, methods are sprawling, and the thought of refactoring it all — making it better, and more efficient — feels both exciting and overwhelming.

So where do you start? How do you get through it without getting caught in the complexity trap?

Complexity Is an Invitation to Simplify

There’s a misconception that refactoring is only for “big-brain moments” — those times when you’re ready to throw all the old code away and build something elegant from scratch. But refactoring doesn’t need to be a complete rebuild. It doesn’t have to be daunting.

The goal of refactoring isn’t to make code perfect. It’s to make it better. A small improvement is still an improvement.

It could be as simple as:

• Renaming a method to better describe what it does.
• Extracting a few lines of code into a clearly named helper function.
• Moving a related chunk of code into its own object.

These changes aren’t rocket science. But they matter — they reduce cognitive load for the next developer (or yourself in a few months). They build momentum, instill confidence, and make working with the code enjoyable again.

Avoid the Overengineering Trap

It’s easy to get carried away when refactoring. You start by extracting some logic into a method, and before you know it, you’re building a new class with multiple dependencies, a new inheritance tree, and mixins to “keep it clean.”

Refactoring isn’t about adding complexity. It’s about removing what’s unnecessary and improving readability. Often, the best refactor makes the code more direct — clearer, more explicit, and more focused.

If you’re like me, you’ve experienced this firsthand: the deeper you go into refactoring, the greater the temptation to do a full architectural overhaul. But the beauty of refactoring lies in the small, incremental changes that guide the code towards simplicity.

Start Small and Build Confidence

The trick is to begin with something tiny — a change that doesn’t require weeks of rewriting and testing. These small wins lead to bigger wins. Start with one method. Or refactor a flaky test. The key is to keep it simple and maintain momentum.

For example, if you have a method that’s doing three different things — parsing data, calculating a value, and saving it to the database — you don’t need to split it into an entire suite of classes. Instead, start by extracting each responsibility into a small, named helper function within the same class. Suddenly, the method reads like a story — easy to follow and understand.

You Don’t Need Complexity to Prove Your Worth

We’ve all heard that little voice telling us a complicated solution shows off our skills. But the truth is, clean code speaks louder than clever code. Anyone can create something convoluted that no one else can understand. The real skill is making code easy to read, easy to modify, and easy to maintain.

Next time you’re refactoring, challenge yourself to simplify. Find ways to make the code more approachable. Leave it in a better state than you found it — without turning it into a massive new refactor project.

The Path Forward

Refactoring doesn’t have to be complicated or overwhelming. It can be a rewarding process of simplifying step by step. If you want to explore a no-nonsense approach to refactoring — one that encourages improvement without over-complication — I’ve got just the thing for you.

Let’s not overcomplicate refactoring. Let’s make it a habit, not a headache.

If this resonates with you, check out our “Don’t Overcomplicate Refactoring!” course and see how simple, effective changes can transform your code — and your workflow.

Voilà!

Don’t Overcomplicate Refactoring! was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

A complete overview of blocks, block references, and procs.

Feel free to have a look at The yield Keyword in Ruby if you’re not familiar the yield keyword and block arguments.

The Ampersand Colon (&:) operator

Ruby proposes a shorthand to call a method on a block argument

[1, 2, 3].map(&:to_f) # => [2.0, 4.0, 6.0]

Is equivalent to

[1, 2, 3].map { |x| x.to_f } # => [2.0, 4.0, 6.0]

By passing &:to_i to Enumerable#map, each element of the[1, 2, 3] array calls to_i.

It works just fine. It’s magic... So let’s reveal the magic trick! 😉

This operator is also called Pretzel colon operator. 🥨 ☕

Symbol#to_proc

When & prepends an argument during a method call, Ruby expects the object passed as an argument to respond to to_proc

module InspectToProc
  def to_proc
    puts "to_proc is called upon :#{self.to_s}"
    
    super
  end
end

Symbol.prepend InspectToProc

method_name = :to_f

[1, 2, 3].map(&method_name) # => [1.0, 2.0, 3.0]

produces

to_proc is called upon :to_f

Symbol#to_proc is called when &:to_f is passed as an argument of map — which is a method that expects a block.

Then within each iteration of map, this freshly created proc will be used as the method’s block.

So let’s re-implement Symbol#to_proc to illustrate the above explanation

module InspectToProc
  def to_proc = lambda {|elem| elem.send(self)} # returns a proc that expects one argument (elem) and calls self (:to_s in this case) upon elem.
end

Symbol.prepend InspectToProc

[1, 2, 3].map(&:to_s) # => ["1", "2", "3"]

is equivalent to

to_string = lambda { |x| x.to_s }

[1, 2, 3].map {|x| to_string.yield(x) } # => ["1", "2", "3"]

to_string is a lambda proc that converts an object into a string.

Then we pass x as argument of to_string.yield (the proc acting as a block) — which calls to_s upon x.

Method#to_proc

Another class that natively responds to #to_proc is Method. An instance of Method is the object-oriented representation of a method.

Instances can only be generated through the method(method_id) shorthand

Method.new(:puts) # ❌ => NoMethodError: undefined method `new' for Method:Class
method(:puts)     # ✅ => #<Method: Object(Kernel)#puts>

Let’s see how to use Method objects with the & ampersand operator

def double(x) = x * 2 # I 💚 the shorthand syntax for single line methods!

[1, 2, 3].map &method(:double) # => [2, 4, 6]

is equivalent to

def double(x) = x * 2

[1, 2, 3].map { |x| double(x) } # => [2, 4, 6]

Here x is passed as an argument of double (double(x)) while in the previous section, to_s was called upon x (x.to_s).

It’s also possible to refer to a method encapsulated in another class

require 'date'

datetimes = %w(
  2001-02-03T04:05:06+07:00
  2002-03-04T04:05:06+08:00
  2003-04-05T04:05:06+09:00
)

datetimes.map(&DateTime.method(:strptime)) # => [#<DateTime: 2001-02-03T04:05:06+07:00 ((2451943j,75906s,0n),+25200s,2299161j)>,                                         #<DateTime: 2002-03-04T04:05:06+08:00 ((2452337j,72306s,0n),+28800s,2299161j)>, #<DateTime: 2003-04-05T04:05:06+09:00 ((2452734j,68706s,0n),+32400s,2299161j)>] 

is equivalent to

require 'date'

datetimes = %w(
  2001-02-03T04:05:06+07:00
  2002-03-04T04:05:06+08:00
  2003-04-05T04:05:06+09:00
)

datetimes.map do |datetime|
  DateTime.strptime(datetime)
end # => [#<DateTime: 2001-02-03T04:05:06+07:00 ((2451943j,75906s,0n),+25200s,2299161j)>,                                         #<DateTime: 2002-03-04T04:05:06+08:00 ((2452337j,72306s,0n),+28800s,2299161j)>, #<DateTime: 2003-04-05T04:05:06+09:00 ((2452734j,68706s,0n),+32400s,2299161j)>]

DateTime.strptime is a helper provided by the date standard library to parse string representations of date and time.

DateTime.method(:strptime) returns the object-oriented representation of strptime scoped under the DateTime class.

So the & ampersand operator uses this instance of Method like in the previous example.

A concrete implementation: BaseBuilder.to_proc

# Input: Content of a JSON or CSV file uploaded to SFTP server for instance.
raw_users = [{email: 'a@a.com'}, {email: 'b@b.com'}, {email: 'c@c.com'}]


# Let's assume User to be an ActiveRecord model
User = Struct.new(:email, keyword_init: true)


# BaseBuilder: it defines the Builder interface
class BaseBuilder
  attr :params

  def initialize(user_params) = @params = user_params
  
  # Emulated interface
  def build = raise(NotImplementedError)

  # Define to_proc at a class level
  def self.to_proc = proc { |user_params| new(user_params).build }
end


# UserBuilder
class UserBuilder < BaseBuilder
  def build = User.new(params)
end


raw_users.map &UserBuilder # => [#<struct User email="a@a.com">, #<struct User email="b@b.com">, #<struct User email="c@c.com">]

So let’s detail what happens in the above code snippet.

Here we define BaseBuilder which is a basic implementation of the Builder design pattern:

• it inits params (Each line of raw_users)
• it emulates an interface contract with the build method.
• it defines to_proc at a class level. this method returns a proc that instantiates a new builder and calls the build instance method on it.

Then we define UserBuilder which derivates from BaseBuilder. So in order to be able to pass this class as a block reference to map, we must comply with the interface contract defined by BaseBuilder.

This means that we must define UserBuilder#build. If not, BaseBuilder#build is called and NotImplementedError is then raised.

As BaseBuilder.to_proc returns a proc and UserBuilder inherits from BaseBuilder then a call to raw_users.map &UserBuilder calls BaseBuilder.to_proc.

So to define another enumerable builder, you just have to follow 2 rules:

• Make sure that your builder inherits from BaseBuilder
• Define the #build method

Cool! Isn’t it? 😁

Now to finish, let’s have a look at a particular use case where to_proc is not called when using block reference (&object) as an argument.

When to_proc is not called

When & prepends an argument during a method call, Ruby expects the object passed as an argument to respond to to_proc.

But this is not always the case

module InspectToProc
  def to_proc
    puts "to_proc is called upon :#{self.to_s}"
    
    super
  end
end

Proc.prepend InspectToProc

double = proc {|x| x * 2}

[1, 2, 3].map(&double) # => [2, 4, 6]

Here InspectToProc#to_proc is never called as double is already an instance of Proc.

Conclusion

The Ampersand operator + Block pattern is widely used within the Ruby Standard Library and within multiple well-known gems (devise, etc..).

We all know this pattern through the famous Ampersand Colon operator (&:).

But with a bit more knowledge, you are now able to extend the possibility of your Ruby code to another level!

RubyCademy’s Newsletter

In the RubyCademy newsletter, I share what I’m learning about Ruby & Rails, including helpful tips, code insights, and exclusive Ruby Cards with detailed explanations.

If it sounds helpful, feel free to subscribe for free:

Thank you for taking the time to read this message!

Mastering the unary ampersand operator (&object) as a block argument was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

An exhaustive book list about Ruby and Ruby on Rails

Introduction

We all want to become better programmers, and there is a tonne of books that’ll help you along your journey. In this blog, We’re going to list 3 Ruby and Ruby on Rails books that can have a big impact on your thought process as a Rubyist.

Eloquent Ruby by Russ Olsen

This book will help you to start writing code the “Ruby way”.

Indeed, it’s easy to write correct Ruby code but to gain the fluency needed to write great Ruby code, you must go beyond syntax and absorb the “Ruby way” of thinking and problem-solving. In Eloquent Ruby, Russ Olsen helps you write Ruby as true Rubyists do.

Here is a link to acquire this book:

Eloquent Ruby (Addison-Wesley Professional Ruby Series)

Practical Object-Oriented Design: An Agile Primer Using Ruby by Sandi Metz

The book to learn to write long-term maintainable code for your Ruby and Ruby on Rails application.

Ruby’s widely admired simplicity has a downside: too many Ruby and Rails applications have been created without concern for their long-term maintenance or evolution. The Web is awash in Ruby code that is now virtually impossible to change or extend. This text helps you solve that problem by using powerful real-world object-oriented design techniques, thoroughly explained via simple and practical Ruby examples.

Here is a link to acquire this book:

Practical Object-Oriented Design: An Agile Primer Using Ruby

Agile Web Development With Rails 6

Learn how to write Ruby on Rails applications the way the Rails core team recommends it.

If you’re new to Rails, you’ll get step-by-step guidance. If you’re an experienced developer, get the comprehensive, insider information you need for the latest version of Ruby on Rails. The new edition of this award-winning classic is completely updated for Rails 6 and Ruby 2.6+, with information on system testing, Webpack, and advanced JavaScript.

Here is a link to acquire this book:

Agile Web Development with Rails 6

Ruby Mastery

We’re currently finalizing our first online course: Ruby Mastery.

Join the list for an exclusive release alert! 🔔

🔗 Ruby Mastery by RubyCademy

Also, you can follow us on x.com as we’re very active on this platform. Indeed, we post elaborate code examples every day.

💚

3 Must-Read Classic Books about Ruby and Ruby on Rails in 2021 was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overriding private methods of the superclass in Ruby

What happens when a private method of the superclass is overridden in Ruby?

As Ruby is an OOP language, a class can inherit from another one. In Ruby, the inherited class is commonly referred to as superclass — This name comes from the Class#superclass method that returns the directly inherited class of the receiver

Here, Parent defines the role method. Child that directly inherits from Parent, can call this method. This is due to the Method Lookup Path mechanism.

Feel free to read the Ruby Object Model article if you’re not familiar with this mechanism

Inheritance and private methods

In Ruby, a private method is a method that can only be called with an implicit receiver — or with self as a receiver since Ruby 2.7.

In this area, the self refers to the eigenclass (a.k.a the shadow class.)

Here, the role private method is accessible in the inheriting Child class. So the state of an inherited method is kept through inheritance.

Now, what happens if we override the role private method?

Overriding a private method

Here, Child class overrides Parent#role private method. In this case, we can see that role is defined as a public method after this overriding. Also, private_methods does not include #role even though this method is private in the ancestor chain of Child — through Parent#role method.

Indeed, private_methods knows that Child defines a role method. and as Child is the first entry of the ancestor chain (and the message handler during Method Lookup Path for a call to Child#role), it’ll be considered as the right version of #role to check by *_methods routines. So as Child#role isn’t defined as private, the private state of Parent#role isn’t inherited by Child#role.

Conclusion

So, always be careful when overriding methods defined with specific access control. Indeed, this state won’t be shared amongst the different versions of your method.

RubyCademy’s Newsletter

In the RubyCademy newsletter, I share what I’m learning about Ruby & Rails, including helpful tips, code insights, and exclusive Ruby Cards with detailed explanations.

If it sounds helpful, feel free to subscribe for free:

Thank you for taking the time to read this message!

Overriding private superclass methods in Ruby was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to 3-dots operator can be used to automatically forward arguments to another method call

In Ruby, it occurs that a method directly forwards arguments to another one

Here, forwarding *args, **kwargs, &blk is redundant and it impacts the readability of the code. To overcome this problem, Ruby 2.7 introduced the arguments forwarding shorthand

In the above example, everything passed to Exporter.run is forwarded to new. As new calls initialize then Exporter#initialize receives all the arguments passed to the call of Exporter.run.

Neat!

Now, what happens if Exporter.run needs to manipulate arguments to instantiate the right exporter, for example?

produces

syntax error, unexpected def self.run(type, ...)
                                            ^^^

Indeed, the arguments forwarding shorthand can’t be mixed with other arguments and it also can’t be destructured.

The above feature enhancement is in discussion since December 2019. So what if you still want to manipulate arguments before forwarding them to another method call?

Feel free to have a look at the module_function vs extend self article if you’re not familiar with the module_function method.

In Exporter.run method, we declare a proc that takes 2 arguments:

• *_ : regular arguments (unused in the block)
• **kwarg : keywords arguments

In this block, we check if type passed as a keyword argument is whitelisted by Exporter. If so, we instantiate the right exporter by forwarding all the arguments using the Argument Forwarding shorthand—we instantiate Exporter::CSVExporter in this case.

Finally, we call the generate_export method on our freshly instantiated exporter.

The block passed to our proc can manipulate the arguments because the Argument Forwarding shorthand is passed to call. So the arguments passed to call are directly passed as arguments of the block.

UPDATE: Ruby 3

Arguments forwarding now supports leading arguments:

def method_missing(meth, ...)
  send(:"do_#{ meth }", ...)
end

RubyCademy’s Newsletter

In the RubyCademy newsletter, I share what I’m learning about Ruby & Rails, including helpful tips, code insights, and exclusive Ruby Cards with detailed explanations.

If it sounds helpful, feel free to subscribe for free:

Thank you for taking the time to read this message!

The Arguments Forwarding shorthand in Ruby 2.7 was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

An overview of the defined? keyword with a use case from the Ruby source code.. and an optimization tip!

In this article, we’re going to explore the following topics:

• the defined? keyword
• defined? in the context of resolv-replace
• defined? yield vs block_given?

The defined? keyword

In Ruby, the defined? keyword returns a string that represents the type of entity passed as an argument. Here is an exhaustive list of what you can pass to defined?

Here, we can see that defined? handles a maximum of cases. But some cases are more relevant than others. For example, let’s see how the resolv-replace library — available in the Ruby Standard Library — takes advantage of this keyword to handle a really “tricky” case.

defined? in the context of resolv-replace

This library simply monkey-patches (IP|TCP|UDP|SOCKS)Socket classes provided by the socket library to use the Resolv DNS resolver.

In the case of SOCKSSocket, the monkey-patching only intervenes when the Ruby interpreter is compiled with the --enable-socks flag. So let’s see how the resolv-replace library handles this tricky case

Notice the modifier-if line 10. Indeed, to choose whether to monkey-patch this class or not, the resolv-replace library simply checks if the SOCKSSocket constant is defined using the defined? keyword. Indeed, as seen in the previous section, SOCKSSocket is only defined if the Ruby interpreter is compiled using the --enable-flag.

So, as the class keyword is only syntactic sugar for class definition and class opening, then you can call a modifier-if to execute this code (or not).

Now let’s see how using defined? can positively impact the performance of your application.

defined?(yield) vs block_given?

If in your program you deal with a huge amount of blocks, then defined? yield can definitely become a real optimization for your program performance. Indeed, to check if a block is passed to your method, you normally use the Kernel#block_given? method

Here method_with_block_given checks if a block is passed as an argument by using Kernel#block_given?. If so, then yield is called and the block is executed. Otherwise, block_given? returns false and yield is never executed.

Ruby provides another way to achieve the same result: defined?(yield)

The main difference between these 2 expressions is that defined?(yield) is faster than Kernel#block_given?. Indeed, it’s a keyword when the block_given? is a method. So block_given? is slower because of the cost of the method call added to the cost of the Method Lookup Path.

Let’s generate benchmark-ips reports to see what’s the difference between defined?(yield) and block_given?

We can see that block_given? is 1.27x slower than defined?(yield).

But as seen in the above benchmark, we’re able to call block_given 9.897M times in a second. So keep in mind that this optimization is only relevant on a huge amount of block calls.

Conclusion

defined? isn’t the most popular keyword in Ruby. Nevertheless, in some situations, this keyword becomes a powerful asset to enhance your program performance or to handle tricky cases where a constant, method, etc... is conditionally loaded. Please feel free to share with us your experience with this keyword in the comments section.

RubyCademy’s Newsletter

In the RubyCademy newsletter, I share what I’m learning about Ruby & Rails, including helpful tips, code insights, and exclusive Ruby Cards with detailed explanations.

If it sounds helpful, feel free to subscribe for free:

Thank you for taking the time to read this message!

The defined? keyword in Ruby was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.

An overview of the different ways to make class methods private in Ruby

In this article we’re going to explore the following topics:

• private_class_method
• class << self and private

private_class_method

This method takes one or more method_ids as an argument. A method_id can be either a String or a Symbol that represents an existing class method in the context of self. The private_class_method makes the method correspond to the method_id passed as argument private

Here we can see that by passing :hello as argument of private_class_method the A::hello class method becomes private.

Now let’s see another way to make class methods private by also using private_class_method

Here private_class_method takes the hello class method definition as an argument. Then we can see that our hello class method is private.

To understand what happens here, let’s slightly modify our code

Here we store the return value of the hello class method definition in method_id. Then we pass method_id (which contains :hello) to private_class_method. At this moment, the hello class method becomes private.

So as a method definition returns the method identifier, we can directly pass the method definition as an argument of private_class_method.

class << self and private

The classic way to make class methods private is to open the eigenclass and use the private keyword on the instance methods of the eigenclass — which is what you commonly refer to as class methods.

Feel free to have a quick look to my article about the eigenclass if you’re not familiar with this concept.

Here, we simply open the eigenclass and make the hello class method private.

RubyCademy’s Newsletter

In the RubyCademy newsletter, I share what I’m learning about Ruby & Rails, including helpful tips, code insights, and exclusive Ruby Cards with detailed explanations.

If it sounds helpful, feel free to subscribe for free:

Thank you for taking the time to read this message!

3 ways to make class methods private in Ruby was originally published in RubyCademy on Medium, where people are continuing the conversation by highlighting and responding to this story.