Beautiful Ruby

I've been running SQLite in production on a few Rails apps. No Postgres process to manage, no connection pool to tune, backups are just file copies. But one thing caught me off guard: how do you replace the database file on a running server?

## The problem

Say you have a content-heavy Rails app. You build the SQLite database locally (import from a CMS, run transforms, generate search indexes) then ship that file to production. With Postgres you'd `pg_restore` into the running database. With SQLite, the database *is* a file. You need to swap it.

The naive approach is `scp` the file over and restart the server. That works, but it means downtime. Your app is offline while Puma restarts, reconnects, and warms up. For a content update that should take milliseconds, you're paying seconds.

You could try `mv new.db production.db` while the app is running, but that's a race condition. ActiveRecord might be mid-query when you yank the file out from under it. You'll get `BusyException` or worse, a corrupted read.

I wanted something like `pg_restore` but for SQLite: push a new database to the running server, validate it, pause requests for a few microseconds while it swaps, then resume.

## What Hotswap does

[Hotswap](https://github.com/rubymonolith/hotswap) adds a Unix socket server to your Rails app. You send it a new SQLite database, it validates the file, then atomically swaps it into place. Incoming requests queue for microseconds during the swap, then resume on the new database.

```ruby
gem "hotswap"
```

The railtie handles everything: it inserts a Rack middleware that wraps requests in a mutex, starts the socket server when Puma boots, and discovers your SQLite databases from `database.yml`.

### Pushing a database

```bash
bin/hotswap cp ./new.sqlite3 db/production.sqlite3
```

Here's what happens:

1. The CLI connects to the socket server inside your running Rails process
2. The database streams to a temp file on the server
3. `PRAGMA integrity_check` verifies the file isn't corrupt
4. Schema is compared against the running database
5. Swap lock acquired, incoming requests queue
6. ActiveRecord disconnects, temp file is atomically renamed, ActiveRecord reconnects
7. Lock releases, queued requests resume on the new database

If the integrity check or schema check fails, the running database is untouched. Nothing gets swapped.

I've been playing around with adding AI features to Rails apps and ran into a problem: tool calling doesn't scale.

The standard approach is to define discrete functions, the LLM picks which one to call, and I execute it. That works great for fixed actions like "cancel order" or "send refund". But then a customer asks "what's my total spend on shipped orders this year?" and I realize I need a `total_spend_by_status_and_date_range` tool I didn't build.

I could add that tool. Then add another one for "average order value by month". Then another for "orders over $100 in Q3". The tool list grows with every new question, each one is a round-trip, and I'm forever playing catch-up.

## What if the LLM just wrote the code?

One `eval` call replaces dozens of specialized tools:

```ruby
orders().select { |o| o["status"] == "shipped" }.sum { |o| o["total"] }
```

The LLM can reason in code. It fetches data, filters it, computes a result. No back-and-forth. No predefined tool for every possible query.

The problem is obvious: `eval` in your Ruby process is catastrophic. The LLM can do anything your app can do. `User.destroy_all`. `File.read("/etc/passwd")`. `system("curl attacker.com")`. One prompt injection in a ticket body and you're done.

## What Enclave does

[Enclave](https://github.com/rubymonolith/enclave) lets you run LLM-generated Ruby without giving it access to your system. It embeds [MRuby](https://mruby.org), a lightweight Ruby interpreter, as a separate VM inside your process. This VM has no file system, no network, no access to your CRuby runtime.

Here's what a tools class looks like for a customer service agent:

```ruby
class CustomerServiceTools
  def initialize(customer)
    @customer = customer
  end

  def customer_info
    { id: @customer.id, name: @customer.name, email: @customer.email,
      plan: @customer.plan, created_at: @customer.created_at.to_s }
  end

  def orders
    @customer.orders.order(created_at: :desc).map do |o|
      { id: o.id, total: o.total.to_f, status: o.status, created_at: o.created_at.to_s }
    end
  end

After building pricing objects in [last week's post](./superfeature-price), the next challenge was figuring out how to organize features across different pricing tiers. Every SaaS product I've worked on eventually becomes a tangled mess of `if current_user.plan == "pro"` checks scattered throughout the codebase.

I decided to solve this problem in the [Superfeature gem](https://github.com/rubymonolith/superfeature) by creating a `Plan` class that makes defining SaaS pricing tiers declarative and maintainable.

## Defining a plan

Plans are Ruby classes that inherit from `Superfeature::Plan`:

```ruby
class Plans::Website::Free < Superfeature::Plan
  def name = "Free"
  def tagline = "Get started for free"
  def price = Price(0)
end
```

This gives you a clean interface for plan metadata. The `Price()` method is from [Superfeature::Price](./superfeature-price), so pricing and plans work together naturally.

## Plan inheritance

Here's where things get interesting. Plans can inherit from each other:

```ruby
class Plans::Website::Creator < Plans::Website::Free
  def name = "Creator"
  def tagline = "For content creators"
  def price = Price(19)
end

class Plans::Website::Business < Plans::Website::Creator
  def name = "Business"
  def tagline = "For growing businesses"
  def price = Price(99)
end
```

This inheritance isn't just for code reuse—it represents the natural hierarchy of SaaS tiers where higher tiers include everything from lower tiers. I'm still learning if it makes sense to inherit from the previous plan or from a base plan.

## Limits

I've worked with enough SaaS products to know that prices are a bit of a pain in the butt. At first, they seem like numbers, but then you have your first Black Friday sale and begin to understand how tedious it is to display discounts throughout a website.

I decided to end this battle once and for all while working on my latest project, [OpenGraph+](https://og.plus), by directing Claude Code to build a `Price` object that makes working with prices and discounts straightforward in the [Superfeature gem](https://github.com/rubymonolith/superfeature).

## Setting prices

Creating prices is straightforward:

```ruby
price = Superfeature::Price.new(49.99)
price.amount  # => BigDecimal("49.99")
price.to_f    # => 49.99
price.to_i    # => 49
```

There's also a handy `Price()` method for when you want something more concise:

```ruby
price = Price(29)
price.to_formatted_s           # => "29.00"
price.to_formatted_s(decimals: 0) # => "29"
```

## Discounts

This is where things get interesting. You can apply discounts in several ways:

```ruby
price = Price(100)
price.discount_fixed(20).amount    # => 80.0
price.discount_percent(25).amount  # => 75.0
price.discount_to(79).amount       # => 79.0
```

Superfeature also parses discount strings naturally. "20%" applies a percentage reduction, "$15" subtracts dollars, and a plain number defaults to dollars:

```ruby
price = Price(100)
price.apply_discount("20%").amount  # => 80.0
price.apply_discount("$15").amount  # => 85.0

One thing I really like about Phlex is how easy it is to group concerns into one place. Consider this Turbo Pagemorphs example. The view has a section in it with a bunch of `turbo_` methods.

```ruby
class View::Post < View::Base
  # Includes the turbo_stream_from method
  include Phlex::Rails::Helpers::TurboStreamFrom

  def initialize(post:)
    @post = post
  end

  # All of our Turbo Stream behavior is configured from one place.
  def turbo_refresh_method = "replace"
  def turbo_refresh_scroll = "preserve"
  def turbo_streams
    turbo_stream_from @post.comments
  end

  def view_template
    h1 { @post.title }
    main(class: "prose"){
      safe render @post.body, type: :md
    }
    div(id: "comments") do
      comments.each do |comment|
        div(class: "comment") do
          p { comment.body }
        end
      end
    end
  end
end
```

The base layout then implements those methods in the `head` and `body` tags.

```ruby
class View::Base < View::Component
  # Default to `nil` so we're not morphing all pages
  def turbo_refresh_method = nil

When I evaluate code libraries, I like to open it up and get a sense of what it does at its very core. At the heart of Phlex is a string that Phlex appends HTML to for rendering in the browser. That string is named `buffer`, which is defaulted to `+""`.

```ruby
# frozen_string_literal: true

class Phlex::SGML
  # ...
  def call(buffer = +"", context: {}, fragments: nil, &)
  	state = Phlex::SGML::State.new(
  		user_context: context,
  		output_buffer: buffer,
  		fragments: fragments&.to_set,
  	)

  	internal_call(parent: nil, state:, &)

  	state.output_buffer << state.buffer
  end
  # ...
end
```

## What is `+""`?

I never bothered to understand what `+""` meant in Ruby until I looked under the hood of Phlex. You know that annoying `# frozen_string_literal: true` you see at the top of Ruby files? That tells Ruby that you can't modify the string in place with operators like `"fizz".upcase!` or `"fizz".concat("buzz")`.