Building a Coaching Engine with Ruby on Rails

Introduction

In our latest iteration of the rails-stupid-coaching project, we focused on building a specialized coaching engine designed to help users refine their communication skills. By leveraging the power of Ruby on Rails, we aimed to create a predictable feedback loop where user input is processed against a set of predetermined logic rules.

The Problem

Initially, we lacked a robust way to handle programmatic responses to user input. The challenge was to create a controller-based system that could parse a request, apply logic based on the content of the message, and return a contextualized response without manual intervention.

The Implementation

To address this, we implemented a modular approach within the Rails framework. By isolating the logic layer from the controller, we ensured that the coaching engine remained testable and extensible.

Here is a simplified look at how the decision logic is structured:

class CoachEngine
  def self.answer(your_message)
    if your_message == "I am going to work right now!"
      "Great!"
    elsif your_message.end_with?("?")
      "Silly question, get dressed and go to work!"
    else
      "I don't care, get dressed and go to work!"
    end
  end
end

By separating the business logic into a dedicated service class, the controller remains clean and focused solely on handling the request and response lifecycle. This adheres to the "fat model, skinny controller" principle, which is essential for maintaining a healthy Rails application.

Results and Learnings

Moving the coaching logic into a standalone class significantly improved our testing process. We can now write RSpec or Minitest suites that verify the engine's response for a variety of inputs without needing to simulate full controller requests. This modularity makes it trivial to add new "coaching styles" or complex decision trees in the future.

Key Insight

Complex decision-making doesn't always require an external state machine or heavy configuration. Sometimes, a well-structured set of conditional methods is enough to get started. As your logic grows, this structure provides a clear path to refactor into strategies or command patterns.

Getting Started

If you are building a feature that involves processing user input:

1. Define your core logic in a plain Ruby class (PORO) first.
2. Keep your Rails controllers responsible only for HTTP concerns.
3. Test the logic class in isolation to verify edge cases.
4. Introduce specific patterns (like Strategy) only when the conditional statements become difficult to manage.

Generated with Gitvlg.com