DEV Community: Brandon Casci

Inter-Process Communication With Ruby

Brandon Casci — Tue, 29 Aug 2023 02:31:00 +0000

2023-08-28

Inter-Process Communication With Ruby 🔄

In 2015, I needed a way to record audio streams on a scheduled basis. To accomplish this, I created a Rails app called Radioshifter that served as a UI for editing and storing schedules. In a separate process, a rufus-scheduler would run and start/stop various command line applications that captured online audio streams to disk and uploaded them to Dropbox.

Radioshifter - R.I.P. 🪦☠

Choosing a Method for Interprocess Communication

I looked at various methods for interprocess communication with Ruby, which included:

pipes
shared memory
message queues
sockets
RPC frameworks
Ruby dRb

dRb: The Right Tool for the Job

I ultimately chose dRb (distributed Ruby) for its simplicity and ease of use.

The dRb fronted process didn’t have too much to worry about in terms of processing messages. All it needed to do was take a message and edit rufus-scheduler’s job list. dRb seemed capable enough for that type of message load.

To enable communication between the Rails app and the scheduler, I used dRb. dRb is a distributed object system for Ruby. It allows you to expose objects to other processes and communicate with them. dRb is a part of the Ruby standard library, so it’s available out of the box. There are two main components to a dRb implementation, whatever you choose to be the server, and a client or clients.

My dRb Implementation in Radioshifter

Things to keep in mind:

I did this in 2015, so some of the code may be a bit dated.
I did this in a hurry, so there are some things that could be improved.
At this point in time, there are probably better ways to do this
There’s no built in or durability or retrying with dRb, like a robust message queue would have.
I’ve never looked into the performace limits of dRb.

With that being said, there is a time and place for dRb, and it’s a good tool know about.

Below are the critical entry points for the dRb implementation, but you can also view the full application source code on the repository. I’m also no longer really fond of the -er -or naming convention that I used for certain classes, but I digress!

# The executable that starts the scheduler which is fronted by dRb

#!/usr/bin/env ruby
require 'drb'
require File.expand_path('../../config/environment', __FILE__ )

ENV['RAILS_ENV'] ||= 'development'
ENV['RUFUS_SCHEDULER_SERVER_PORT'] ||= '9000'
ENV['RECORDINGS_LOG_FOLDER'] ||= File.expand_path('../../log/recordings', __FILE__ )

trap("INT") { exit }

RUFUS_SCHEDULER = Rufus::Scheduler.new

server = Scheduler::Server.new(RUFUS_SCHEDULER)
bootstrapper = Scheduler::ServerBootstrapper.new(server, RecordingSchedule)
bootstrapper.bootstrap

DRb.start_service("druby://localhost:#{ENV['RUFUS_SCHEDULER_SERVER_PORT']}",
  server
)
DRb.thread.join  


# The server class that exposes the scheduler

module Scheduler
  class Server
    include ::Scheduler::JobTransformations

    def initialize(scheduler)
      @scheduler = scheduler
      @job_editor = Scheduler::JobEditor.new(@scheduler)
      @lock = Mutex.new
    end

    def cron(recording_schedule)
      @lock.synchronize do
        @job_editor.cron(recording_schedule)
      end
    end

    def at(recording_schedule)
      @lock.synchronize do
        @job_editor.at(recording_schedule)
      end
    end

    def unschedule(job_id)
      @lock.synchronize do
        @job_editor.unschedule(job_id)
      end
    end

    def job(job_id)
      begin
        job = @scheduler.job(job_id)
        job_to_hash(job) if job
      rescue ArgumentError => e
        nil
      end
    end

    def jobs(job_ids)
      found_jobs = job_ids.map do |id|
        job(id)
      end

      found_jobs.compact
    end
  end
end


# The dRb client initializer.
# In my app this is located at: config/initializers/rufus-scheduler.rb

require 'drb'
RUFUS_SCHEDULER_CLIENT = DRbObject.new(nil, 'druby://localhost:9000')

# Note: this must be called at least once per process to take any effect.
# This is particularly important if your application forks.
DRb.start_service


# Calling the dRb Client.

class RecordingSchedulesController < ApplicationController
  before_action :authenticate_user!
  before_action :redirect_to_time_zone, if: Proc.new { current_user.time_zone.blank? }

  def index
    @recording_schedules = RecordingSchedule.where(user_id: current_user.id).order(:name).decorate
  end

  def new
    @recording_schedule = RecordingSchedule.new
  end

  def create
    @recording_schedule = RecordingSchedule.new(recording_schedule_params).decorate
    @recording_schedule.user = current_user
    notifier = Services::ScheduleNotifier.new(@recording_schedule, RUFUS_SCHEDULER_CLIENT)

    if notifier.save
      redirect_to recording_schedules_path, flash: { success: 'Recording schedule added.' }
    else
      flash.now[:error] = "There were some problems with this recording schedule."
      render :new
    end
  end

  def destroy
    @recording_schedule = RecordingSchedule.find(params[:id]).decorate
    notifier = Services::ScheduleNotifier.new(@recording_schedule, RUFUS_SCHEDULER_CLIENT)
    flash_options = {}

    if notifier.destroy
      flash_options[:success] = 'Recording schedule removed.'
    else
      flash_options[:success] = 'Recording schedule not removed.'
    end

    redirect_to recording_schedules_path, flash_options
  end

  def edit
    @recording_schedule = RecordingSchedule.where(id: params[:id], user_id: current_user.id).first
  end

  def update
    @recording_schedule = RecordingSchedule.where(id: params[:id], user_id: current_user.id)
      .first
      .decorate
    notifier = Services::ScheduleNotifier.new(@recording_schedule, RUFUS_SCHEDULER_CLIENT)

    if notifier.save(recording_schedule_params)
      redirect_to recording_schedules_path, flash: { success: 'Changes saved.' }
    else
      flash.now[:error] = "There were some problems with this recording schedule."
      render :edit
    end
  end

  private

  def recording_schedule_params
    strip_blank_from_days_of_week(
      params
        .require(:recording_schedule)
        .permit(:duration, :stop_time, :name, :recurring,
         :start_on, :start_time, :stream_url, days_of_week: []
        )
    )
  end

  def redirect_to_time_zone
    redirect_to time_zone_path
  end

  def strip_blank_from_days_of_week(permittied_params)
    if permittied_params[:days_of_week].present?
      permittied_params[:days_of_week]
        .reject! {|i|i.blank?}
        .collect!(&:to_i)
    end
    permittied_params
  end
end

Conclusion

Overall, using dRb for interprocess communication in Ruby proved to be a reliable and efficient solution for my audio recording system. While there are other methods available for interprocess communication in Ruby, dRb’s simplicity and ease of use made it a good choice for my use case.

Internationalize and Humanize your Ruby on Rails application

Brandon Casci — Wed, 23 Aug 2023 13:52:47 +0000

Internationalization is the process of designing and developing web applications that can support multiple languages and locales. This is an important consideration for any web application that needs to reach a global audience, as it allows users to interact with the application in their preferred language and format.

Ruby on Rails provides built-in support for I18n, making it easy to create and manage translations for different languages. The humanization helpers of ActiveRecord and ActiveModel I18n, and you can leverage this to make you application support multiple languages, and to also humanize your object names and attributes to generate human readable content and forms.

Take the following two example screens from www.cboflow.com, a Rails application that I maintain. The first is in English, and the second is in Spanish. Using the strategies outlined in this article, I was able to make this application support multiple languages with minimal effort.

I18n and Rails

A new Rails application is configured to use I18n by default.

All of the translations are stored in resource files within the project's config/locales directory. Each file has to end with a language code, and .yml. So for example, you might have a file named config/locales/en.yml, with the following content:



  en:
    hello: "Hello, world!"

In this folder, you can have as many subfolder as you like, and prefix the files as you wish. Some people like to have one large locale file for each supported language, while others like to have one file per object or view. For example, keeping all content in config/locales/en.yml, or breaking the content up into several files like config/locales/author.yml and config/locales/post.yml

The Rails Guide has a lot of information about using this feature.

How I use I18n in my own Rails applications

I try to use the same lingo across my applications.

I will create one locale file for each object that I intent to humanize in a view.

So if I have a Person model, I'll have a person.en.yml file, and more files for other languages like person.es.yml.

The default humanization for an attribute name is to the same as String#humanize, so Person#first_name will become First name by default, and if I am happy with that I probably will not make a translation entry.

I also tend to use gems like simple_form to generate my form HTML, and this saves me from having to maintain a lot of view code to outputting translated content onto forms. Also simple_form has it's own i18n convention that compliments the Rails default pretty well.



 # person.en.yml
  en:
    activerecord:
      models:
        person:
          one: Person
          other: People
    attributes:
      person/hispanic:
        true: 'Yes'
        false: 'No'               
      errors:
        models:
          person:
            attributes:
              birth_date:
                must_be_in_the_past: "can't be before today"
                must_be_formatted_correctly: "must be formatted like yyyy-mm-dd"
              full_name:
                blank: "can't be blank"
              email:
                invalid: "is not valid. It should look like name@domain.com"
              phone_number:
                invalid: "is not valid. It should look like 123-456-7890"



# person.es.yml
  es:
    activerecord:
      models:
        person:
          one: "Persona"
          other: "Personas"
      attributes:
        person:
          birth_date: "Fecha de nacimiento"
          email: "Correo electrónico"
          full_name: "Nombre completo"
          hispanic: "Hispano"
          personal_information: "Información personal"
          phone_number: "Número de teléfono"
          self_described_gender: "Género autodescrito"
          self_described_race: "Raza autodescrita" 
        person/hispanic:
          true: "Sí"
          false: "No"
      errors:
        models:
          person:
            attributes:
              birth_date:
                must_be_in_the_past: "no puede ser antes de hoy"
                must_be_formatted_correctly: "debe tener el formato yyyy-mm-dd"
              full_name:
                blank: "no puede estar en blanco"
              email:
                invalid: "no es válido. Debe parecerse a nombre@dominio.com"
              phone_number:
                invalid: "no es válido. Debe parecerse a 123-456-7890"

Gems like simple_form will label your forms with the correct languages, but you will have to call the model humanization helpers when outputting other types of content. You can also clean this up with your pwn helpers or presentation objets.

You manually pull translations like this:



Person.human_attribute_name(:first_name) # -> First name

  Person.model_name.human # -> Person

  Person.model_name.human(count: 2) # -> People

  Person.human_attribute_name("hispanic.#{person.hispanic}") %> # -> Yes

Humanizing Context and Service Objects with I18n.

Sometimes it will make sense to humanize one object's names and attributes with a totally new name in different parts of an app. For example, maybe it makes sense on one screen to refer to Person ans Profile, or Household Member.

Sometimes it also makes sense to wrap a sequence of steps into a service object that someone can initiate by filling out a form and clicking a button.

I'll use something like what's below to accomplish that.

Now you can do things like Clients::ChangeProfile.model_name.human or Clients::ChangeProfile.human_attribute_name(:first_name).



module Clients

  class ChangeProfile < BaseCommand

    attribute :full_name, :string

    attribute :birth_date, :date

    attribute :email, :string

    attribute :phone_number, :string

    attribute :hispanic, :boolean, default: false

    attribute :race_list, default: []

    attribute :self_described_race, :string

    attribute :gender_list, default: []

    attribute :self_described_gender, :string

    attribute :user

validates :user, presence: true


def run
  context = {}
  validate!
  context[:person] = person

  # While the implementation is not shown in this code sample, the attributes
  # for this ActiveModel based Command/Service Object are written across
  # several models within a transaction
  save!

  result(true, **context)
rescue ActiveRecord::RecordInvalid, ActiveModel::ValidationError
  rollup_errors(person) if person
  result(false, **context)
end

# overriding model name here, so this command can be bound to a form
# with ActionView and humanized with full I18n support

def self.model_name
  ActiveModel::Name.new(self, nil, 'Profile')
end

# other implementation details and methods
# ...
# ...
# ...



end

end



en:

  activerecord:

    models:

      person:

        one: Person

        other: People

      clients/profile:

        one: Profile

        other: Profiles

      household_member:

        one: Household Member

        other:  Household Members


    attributes:

      person/hispanic:

        true: 'Yes'

        false: 'No'

errors:
  models:
    person:
      attributes:  &amp;person_error_attributes
        birth_date:
          must_be_in_the_past: "can't be before today"
          must_be_formatted_correctly: "must be formatted like yyyy-mm-dd"
        full_name:
          blank: "can't be blank"
        email:
          invalid: "is not valid. It should look like name@domain.com"
        phone_number:
          invalid: "is not valid. It should look like 123-456-7890"
    household_member:
      attributes:
        &lt;&lt;: *person_error_attributes

Navigational links and contextual information

I may place all of my navigational and contextual information into a locale file like what's below.

This enables me to do things like this:



<%= link_to t(:add_action, subject: Person.model_name.human), new_manage_client_care_distribution_path, class: 'btn btn-info' %>



en:

  add: Add

  add_action: "Add %{subject}"

  all: All

  back: Back

  basic_information: Basic Information

  client_profile: Client Profile

  confirm: Are you sure?

  empty_search: "No %{subject} found"

  delete: Delete

  edit: Edit

  hello: "Hello world"

  history_action: "%{subject} History"


  insights: Insights

  invite_action: "Invite %{subject}"


  loading: Loading...

  provide_action: "Provide %{subject}"

  missing_object: "No %{subject}"

  new: New

  new_action: "New %{subject}"

  register_action: "Register %{subject}"

  summary: Summary

  view: View

  view_action: "View %{subject}"

Conclusion

I18n is powerful and flexible, and really makes it easy to humanize your applications. There are other complexities that I have not covered here, like right-to-left languages, supporting many languages at once, and long form content, but I hope this article has given you a good starting point.