Metaprogramming in Ruby: Intermediate Level

Practical Ruby Metaprogramming Example

With that out of the way, let’s examine our solution! We’ll go through the most important aspects of the code here; see the GitHub repository for more information. Please note that this example uses Ruby 3.0.0 and Rails 7.0.4.

Creating a Builder with Ruby define_method

At the core of our solution is a concern that we’ll call MinutesTilBuilder. This will build our [station_name]_minutes_til_next methods, which will provide us with the minutes until the next inbound or outbound train arrives.

module MinutesTilBuilder
 extend ActiveSupport::Concern

 included do
   def self.build_minutes_til_methods(station_name:, train_lines:, arrival_times:)
     define_method("#{station_name}_minutes_til_next") do |direction, current_time|
       return nil if no_service(current_time)

       minutes = minutes_til(station_name, direction, train_lines, arrival_times, current_time)
       minutes&.ceil ||= nil
     end
   end
 end
 # ...calculations down here
end

So given our parameters, build_minutes_til_methods could generate the following methods:

• porter_minutes_til_next
• union_minutes_til_next
• park_minutes_til_next

We won’t drill down into the calculations associated with the minutes_til method, since those aren’t crucial to understanding the metaprogramming concepts. In a nutshell, it determines the nearest train (either inbound or outbound, depending on the direction argument) for a given station, as defined by the station_name argument. Note that the method returns the minutes until that train’s arrival regardless of the line that train is on.

Calling build_minutes_til_methods

To build our methods, we include the MinutesTilBuilder concern in the HasMinutesTil module. In our example, our schedule is defined by the constant called ARRIVAL_TIMES.

module HasMinutesTil
 extend ActiveSupport::Concern
 include MinutesTilBuilder

 PORTER_ARRIVAL_TIMES = { red: { outbound: 45, inbound: 40 } }.freeze
 UNION_ARRIVAL_TIMES = { green: { outbound: 25, inbound: 20 } }.freeze
 PARK_ARRIVAL_TIMES = {
   red: { outbound: 55, inbound: 50 },
   green: { outbound: 15, inbound: 10 }
 }.freeze

 ARRIVAL_TIMES = {
   porter: PORTER_ARRIVAL_TIMES,
   union: UNION_ARRIVAL_TIMES,
   park: PARK_ARRIVAL_TIMES
 }.freeze

 included do
   build_minutes_til_methods(station_name: 'porter', train_lines: %w[red], arrival_times: ARRIVAL_TIMES)
   build_minutes_til_methods(station_name: 'union', train_lines: %w[green], arrival_times: ARRIVAL_TIMES)
   build_minutes_til_methods(station_name: 'park', train_lines: %w[red green], arrival_times: ARRIVAL_TIMES)
 end
end

Calling Methods for User-specific Stations

Any given user will have a set of stations they want to track. So we’ll create a User class that includes HasMinutesTil and calls the builder methods created by MinutesTilBuilder for the stations they want to track. The user-specified stations are defined by the USER_TRAIN_STATIONS constant in this example; in practice, you would need to fetch this data wherever it’s persisted.

class User
 include HasMinutesTil

 USER_TRAIN_STATIONS = %i[porter, union, park].freeze

 def incoming_trains(stations:, direction:, current_time:)
   stations.each_with_object({}) do |station_name, hash|
     hash[station_name] = send("#{station_name}_minutes_til_next", direction, current_time) || "No service"
   end
 end
end

Loading Data into Our Controller

From our controller, we can call user.incoming_trains to get the nearest incoming trains for the user-specified stations.

class OutboundController < ApplicationController
 def index
   user = User.new

   # This is here purely so we can we can easily
   # specify different times for this example.
   @current_time = Time.current

   @minutes_til_next = user.incoming_trains(
     stations: User::USER_TRAIN_STATIONS,
     direction: "outbound",
     current_time: @current_time
   )
 end
end

Displaying the Data in Our View

We can then add the data into our view using a partial that I’ll call _stations.html.erb. I’m using tailwindcss here, but the styling is immaterial for this example.

<div class="grid grid-flow-col grid-cols-3 gap-6 mb-6">
   <div class="bg-gray-200 py-8 px-4">
       <h2 class="text-xl pb-3">Porter</h2>
       <div class="grid grid-rows-2">
           <div><span class="text-4xl"><%= @minutes_til_next[:porter] %><span></div>
       </div>
   </div>
   <div class="bg-gray-200 py-6 px-3">
       <h2 class="text-xl pb-3">Union</h2>
       <div class="grid grid-rows-2">
           <div><span class="text-4xl"><%= @minutes_til_next[:union] %><span></div>
       </div>
   </div>
   <div class="bg-gray-200 py-6 px-3">
       <h2 class="text-xl pb-3">Park</h2>
       <div class="grid grid-rows-2">
           <div><span class="text-4xl"><%= @minutes_til_next[:park] %><span></div>
       </div>
   </div>
</div>

Checking Out the Results

By modifying the @current_time in our OutboundController, we can see how our station methods are calculating the minutes until train arrival. For example, if we specify the time as 3/10/23 10:00 AM with Time.new(2023, 3, 10, 10), we get this result on the /outbound route:

Porter and Park stations both serve the Red line, so their arrival times make perfect sense. Service isn’t available at Union station since it doesn’t open until noon. What happens if we set the time to 3/10/23 1:05 PM with Time.new(2023, 3, 10, 13, 5)?

Union station is now open! We can also see that the Park street station displays 10 minutes, since it serves both the Red and Green lines, and the next Green line train will arrive at 1:15 PM.