It’s now 8 months since I wrote about an inflection point with Claude, Rails and me. In that article I wrote:

Claude Code with Rails feels like magic. I’ve avoided and actively ignored the hype, I’m a professional sceptic, but the last week deep dive has convinced me:

“For experienced Rails developers, there’s orders of magnitude of productivity gains to be had. Right now. No joke.”

It may not be the 10x developer we hear so much about, but without question, 2x to 3x is what I’m experiencing. If we can scale that over teams, it’s transformational.

Fast Forward to Today

Since then I leaned in to using Claude on personal projects and became more and more comfortable with the flow, branch, plan, iterate, review. The first sign that things were accelerating rapidly was when I was hitting timeouts several times a day as I’d hit the limits of the $20 plan. Initially it was a good way to take a break, or go back to coding myself, but it wasn’t long before I upgraded to Max.

Since then my usage and success with Claude Code has been nothing short of exponential. It’s not an exaggeration to say my previous 2x or 3x boost really is in that mythical 10x range.

This acceleration has crept up on me, but I can really say in the last couple of months, since December 2025 at least, Claude seems to have hit another inflection point. Where previously I was reworking things almost all the time, fixing, correcting, that slowly stopped happening to the point now, with carefully curated AGENTS.md and SKILL.md files, Claude is usually on target first time.

Certainly Opus 4.5 has a lot to do with this. But the Claude client has also come on leaps and bounds - those small things you barely notice but make every interaction more polished.

The Word is Out

Yesterday I woke up to a bunch of messages from friends linking to a tweet from Garry Tan where he said:

I think people are sleeping a bit on how much Ruby on Rails + Claude Code is a crazy unlock - I mean Rails was designed for people who love syntactic sugar, and LLMs are sugar fiends.

Took me a while to notice my name was in his screenshot - hence the DMs! Ironically I think that screenshot is from Claude itself, as that’s how attribution links look there, so ‘mileswoodroffe’ means it was attributing that quote to this very blog! Claude quoting me talking about Claude?!?

The key point I was making, as is Garry and many others, is Claude feels particularly suited to Ruby on Rails, and extremely token efficient, due to the well known conventions at its core. Even better, I also think it works in the other direction. When we review the code Claude delivers, due to Ruby’s incredibly clear syntax we can easily and quickly understand the output and know what to do next. When you compound this over a session of a couple of hours, this is a massive boost to flow.

Examples

For example, I’d not worked on my meal planning app 1500cals for close to a year. I use it every day to plan meals, snacks and track exercise. I love it but didn’t have a lot of time or motivation to improve. There were a couple of features I’d long wanted but never quite got to. Time for Claude to help.

The first was around tracking points for exercise. I use Vitality and the points really push me to keep active so I wanted something similar. The 1500cals iOS app already syncs Apple Health steps and workout data so the foundations were there. I literally took a screenshot of the two key screens on Vitality, dragged them in to the Claude Code console, and then explained what they showed and how I wanted to integrate into my app.

Within seconds Claude had parsed this information, and set about with the erb templates. The first result was staggeringly good. What surprises me are the details. Just from this screenshot it could interpret that the circles represented completion of 3, 5 or 8 steps, that I wanted to paginate monthly, it added a summary underneath that I hadn’t described or frankly even considered.

Further, it had proposed database change to persist this data, implemented models and controllers - even added and scheduled a job to update the data each night as Claude knew I was using Solid Queue. And it just worked. I reviewed the code, made a couple of tweaks and had to iterate over some additions but this feature was done and deployed to production in under 30 minutes. If I had to estimate the time to build myself I would say at least a few hours. That’s being optimistic, and the reality also is I’d mulled this over for 6 months or more but hadn’t managed to get started. With the acceleration I get from Claude this opens up much more.

Disposable Code

When ideas can be brought to life at this pace it ushers in a new way of working. I always start a branch, work up an idea and if its not gelling, I just delete the branch and move on. The innovation is and always has been the ideas, the code is just how we present these ideas to users and make them interactive. Previously we laboured over our code, but now we can implement these ideas so effortlessly and cheaply, the code essentially becomes a disposable commodity.

Wrapping Up

8 months ago in the previous Claude article I said I was all in. I have been ever since. Viva Rails. Viva Claude.

Would love to hear your experiences with LLM’s so don’t hesitate to drop me a note at my new favourite place Blue Sky or via any channels listed here

I needed to add a third-party messenger widget to a project I’m working on, and given their widespread use on many sites, I figured this would be a trivial case of dropping some JavaScript into the page and we’d be done. In fact, it was that simple! Until I navigated off the first page, which is when the chat bubble disappeared, and this story begins! What’s going on?

Rails Turbo Drive

For a bit of context, this is of course a modern Rails web site, with all the amazing out-of-the-box benefits we all know and love. On the front end, Turbo is one of these incredible features, and the default Turbo Drive is so transparent it can be easy to forget it’s even there.

With Turbo Drive, unlike a traditional page load that would replace the entire HTML, turbo intercepts link clicks and form submissions, fetches the full HTML with AJAX, and then replaces just the <body> element with the new content. This results in much faster rendering when navigating since all the head content like JavaScript, CSS etc doesn’t need to be re-parsed. Genius!

The Problem

This approach works beautifully for most content, but it creates a problem for third-party widgets that inject themselves into the DOM. When the messenger widget’s JavaScript runs on the initial page load, it inserts the code necessary to render and manage the chat window directly in the document body. As soon as we navigate to another page, Turbo Drive throws away that entire body content—including my carefully positioned chat widget—and replaces it with the fresh HTML that has no knowledge of the messenger integration since the initialiser code does not run.

Permanent

Of course, Rails has data-turbo-permanent for this kind of situation right? From the documentation:

Turbo Drive allows you to mark certain elements as permanent. Permanent elements persist across page loads, so that any changes you make to those elements do not need to be reapplied after navigation.

This sounds like the solution right? It’s a little tricky because the dixa-messenger markup is dynamically loaded after the page is rendered so we can’t just add data-turbo-permanent easily. To get around this I added a new <div id="dixa-permanent-container" data-turbo-permanent></div> to our layout and then adapted the JavaScript adding a MutationObserver that watched the page and as soon as the dixa widget had been added asynchronously, moves it to our data-turbo-permanent div. Clever huh? Well.. no

iFrames

Since the widget is implemented with an iFrame, as far as I can ascertain, iFrames lose all their state and crucially the connection to the third party remote widget platform. So despite our efforts the widget still does not survive across Turbo Drive navigations. We can see the chat bubble circle and ghostly image of where the chat window previously was, but the content rendered from the remote service is lost.

Out of Body Experience

Now I understood the issue was Turbo replacing the body, and that due to being an iFrame that turbo-permanent would not resolve the issue, I had an idea to move the widget completely outside of the body tag. This seemed wrong but worth a try. Bingo! Using the same trick to observe the page and then move the div, but this time move it outside the body of the page worked perfectly. Our widget icon persists across navigations, and even with the chat window open, state is maintained!

Rails World 2025

It just so happens that Rails World conference was last week, so I took this opportunity to ask some of the best and brightest in the business. Great and helpful conversations with many, but DHH himself pointed me to this issue which describes the same problem and suggests intercepting the body replacement with turbo:before-render and then using an inner div that Turbo Drive replaces on each page render. That means our widget is not replaced and functions as we expect. It’s a bunch more code though, and despite not being technically ‘legal’ HTML markup, the out of body fix described previously is still my preference.

Wrapping Up

If you have any ideas, opinions, or better suggestions, don’t hesitate to let me know. I spent way longer than I should have trying to work this out so sharing this post in case anyone else out there finds it of any use. As always, find me on Blue Sky or via any channels listed here

Claude Code with Rails feels like magic. I’ve avoided and actively ignored the hype, I’m a professional sceptic, but the last week deep dive has convinced me:

For experienced Rails developers, there’s orders of magnitude of productivity gains to be had. Right now. No joke.

It may not be the 10x developer we hear so much about, but without question, 2x to 3x is what I’m experiencing. If we can scale that over teams, it’s transformational. Read on…

The Rise of the Transformer

Like many others in tech, the launch of ChatGPT from OpenAI a few years ago was such an unexpected but exciting development. I too jumped in and spent a lot of time playing with this new technology, but it really didn’t click at all outside of the fun. I couldn’t see an application of it that would solve real problems “for me”.

That persisted for at least a year. I subscribed for $20/month and continued to experiment. I still found it incredibly interesting and a complete game changer, but most coding exercises were simply taking longer and leading me down strange paths. Don’t get me wrong the transformer architecture and capabilities were mind boggling, but it just didnt work “for me”.

Anthropic

I tried Claude.ai from Anthropic and immediately subscribed. It seemed leaps ahead in my use case which was essentially typing out questions in the web UI, copying in code, and copying out answers. I really don’t like the code completion or IDE integrations yet, so while clunky, it works. The artefact model was also really well implemented. But still, it really wasn’t net positive “for me”. I excitedly tried Claude Code and that was intriguing but left me running in circles.

Inflection Point

Claude Sonnet 4’s release has changed my workflow entirely. I have a couple of Rails side projects I’ve been working on and Claude Code has been just sensational. I’m not sure what happened but I’m honestly shocked.

Claude Code with Sonnet 4 is incredibly good at understanding what I’m trying to do when I interact like a pair. I’ve been powering through some new features at a phenomenal pace. I’ll stick to focused tasks, work in branches and not be afraid to roll back, but it’s really working well. After initially being very doubtful, I’m convinced now this has changed my specific scenario as an experienced Rails developer, I can talk through features, easily give feedback and suggest alternatives, suggest better patterns, and the pace is breathtaking.

Sure, Claude struggles and makes mistakes, but so do I, and I think this flow of pairing with Claude is the way “for me”. It seems to struggle most with tests - as do I - and sometimes makes stupid decisions that can distract eg it decided to override my log_in_as_user helper, and often adds JavaScript inline, but a quick correction “lets always use stimulus” is all that’s needed. Renaming a model is also a refactoring that I’ve done so many times, but Claude handles it in seconds. And completely.

In the past when testing I’ve been annoyed within a short period of time, but in the last couple of days I’ve been flying. As you can see by the above, just the last few days is when this really clicked for me. My usage is up 10x from May, which was itself 10x from April.

Wrapping Up

A bit of a different post, and just opinion, but I truly have seen a massive change in the last couple of months with Claude and for Rails development specifically, and I’m all in.

Would love to hear your experiences with LLM’s so don’t hesitate to drop me a note at my new favourite place Blue Sky or via any channels listed here

I noticed a lot of new “users” in one of my side projects, and immediately wondered what was going on, was this it, had I finally struck the startup gold?! Obviously I hadn’t, but nice to dream for a moment.

On closer inspection, I noticed a barrage of posts to my sign-in form with interesting user names like these:

"cmee7uvb'; waitfor delay '0:0:15' --",
"0qjninbk' or 915=(select 915 from pg_sleep(15))--",
"a77t30jc'; waitfor delay '0:0:15' --",
"kxvmfhk6') or 273=(select 273 from pg_sleep(15))--",
"a9vxyx7i' or 135=(select 135 from pg_sleep(15))--",

Aha! It’s a visit from our old friend Little Bobby Tables!

xkcd.com

Ok! So now we can see someone with way too much time on their hands is attacking my little site for some nefarious reason or other. Just like Bobby Tables they’re probing and trying to use SQL-injection to cause some kind of mayhem. Thankfully I’m using Rails and the way Rails handles sanitisation of inputs to queries is already really solid.

Still it’s annoying, and it made me remember that there was a new Rate Limiting feature added to Rails 7.2 that I’d not tried out. Great opportunity to do that now.

What is Rate Limiting?

In short, rate limiting is a way to control the number or rate of requests to a service, in my case, HTTP requests to my Rails app. This technique is often used as a first step to restrict the number of requests to a particular endpoint from the same IP. It’s one of many ways to mitigate attacks, but the one we’re looking at today.

The Rails way

Historically I would reach for rack-attack which is a very robust, battle-tested and configurable solution, but since Rails 7.2 we have an option for a simpler way, out of the box with an expressive syntax where we can just add rate_limit in a controller and be done!

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create
end

This one-liner is all we need to limit any IP to a maximum of 10 requests to our create action over a 3 minute period. delightful. On the 11th request, the server will return a “429 Too Many Requests” response.

We can add a bit more logic to the rule using the by: and with: parameters, where by takes a function to determine what is counted to be rate limited, and with lets us redirect to a specific location with another message. eg.

class SignupsController < ApplicationController
  rate_limit to: 10, within: 3.minutes,
    by: -> { request.domain }, with: -> { redirect_to busy_controller_url, alert: "Too many signups on domain!" }, only: :new
end

Lastly there’s a store: parameter you can pass in to specify the ActiveSupport::Cache cache store you want to use. It will default to use config.cache_store from your environment file. In this case, to keep it simple I’ve added config.cache_store = :memory_store to test.rb, development.rb and production.rb, but you can use any ActiveSupport::Cache backend.

Testing

To confirm this works as we expect, lets add a simple Minitest test to confirm the rate limiting kicks in. The first one POST’s an email address to our SessionsController#create action 10 times and asserts we get the expected redirect. It then fires one more POST and we assert that we get the “too many requests” response.

The second test also POST’s to the same action 10 times, but then travels 3 minutes 1 second to the future and confirms it can make a further POST since our 3 minute window has now expired. Neat!

test "should enforce rate limit for create action" do
  10.times do |i|
    post sessions_url, params: { email: "user#{i}@example.com" }
    assert_response :redirect
  end
  
  post sessions_url, params: { email: "overlimit@example.com" }
  assert_response :too_many_requests
end

test "should reset rate limit after the time window" do
  10.times do |i|
    post sessions_url, params: { email: "user#{i}@example.com" }
    assert_response :redirect
  end
  
  travel 3.minutes + 1.second do
    post sessions_url, params: { email: "newuser@example.com" }
    assert_response :redirect
  end
end

One mini gotcha is you may need to add Rails.cache.clear in your test_helper or setup block just to make sure the cache is reset for the tests.

Wrapping Up

Short post this week, but hopefully of use. Don’t hesitate to drop me a note at my new favourite place Blue Sky or via any channels listed here

Last week I wrote about Solid Cable and how amazingly easy it was to get up and running and add real time web socket magic to a Rails app. Rails 8 and the solid trifecta of Solid Cache, Solid Queue and Solid Cable, is a massive unlock to productivity, particularly evident when adding some of these historically pretty complicated capabilities and services: caching, job queues and web sockets respectively.

When I went to move this to production, I realised that there often aren’t that many blog posts or examples - including my own previous posts - that go into details beyond a demo on localhost. Lets fix that now! It was pretty straightforward, but a couple of tiny details caught me out, so wanted to capture those for next time!

Managing Multiple Databases in Rails

In the previous post we set up the “primary” and “cable” databases both with SQLite in the development environment as that’s the default in Rails 8, and also the simplest. But in my production app - and I suspect like many others - I was already using PostgreSQL as my main “primary” database. So we need to add SQLite in production to run alongside - in my case - Postgres. We configure database connections in config/database.yml so open this up and have a look at what you currently have.

In my case I had a &default YAML anchor to set up the common configs, then a key each for development, test and production that pulls in the &default config with a merge key and adds the environment specific configs in each as needed. I had postgresql set up for all three environments as shown below. You may have something different, like sqlite3 or mysql as your primary, but the general idea is the same.

# Existing database.yml
default: &default
  adapter: postgresql
  encoding: unicode
  port: 5432
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: myapp_development

test:
  <<: *default
  database: myapp_test

production:
  <<: *default
  host: <%= ENV["DB_HOST"] %>
  database: <%= ENV["POSTGRES_DB"] %>
  username: <%= ENV["POSTGRES_USER"] %>
  password: <%= ENV["POSTGRES_PASSWORD"] %>

Ok. So now to use Solid Cable with SQLite while keeping PostgreSQL for the main app database we need to update database.yml to support multiple databases ie. SQLite as well as our existing PostgreSQL. This capability was introduced in Rails 6 I think, and you can read all about it in the excellent Rails Guides if you want to get some more background.

Firstly, lets add a new YAML anchor for sqlite to config/database.yml as shown here. Put it just below the existing &default anchor block.

sqlite: &sqlite
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

When using multiple databases in an environment, we can specify them by adding a configuration key for each under the environment key. Here’s how my database.yml file looked after adding the &sqlite anchor and then adding primary and cable configurations for each environment:

default: &default
  adapter: postgresql
  encoding: unicode
  port: 5432
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

sqlite: &sqlite
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  primary:
    <<: *default
    database: myapp_development
  cable:
    <<: *sqlite
    database: storage/myapp_development_cable.sqlite3
    migrations_paths: db/cable_migrate

test:
  primary:
    <<: *default
    database: myapp_test
  cable:
    <<: *sqlite
    database: storage/myapp_test_cable.sqlite3
    migrations_paths: db/cable_migrate

production:
  primary:
    <<: *default
    host: <%= ENV["DB_HOST"] %>
    database: <%= ENV["POSTGRES_DB"] %>
    username: <%= ENV["POSTGRES_USER"] %>
    password: <%= ENV["POSTGRES_PASSWORD"] %>
  cable:
    <<: *sqlite
    database: /data/myapp_production_cable.sqlite3
    migrations_paths: db/cable_migrate

We’re only really interested in the “production” settings in the context of this post but I’ve left the rest in for completeness.

So, lets go over this line by line:

• primary: specifies the primary database. In our case that’s our existing “main” application database. It should always be named “primary” to keep things clear.
• <<: *default is a YAML merge key that pulls in the configuration from the &default anchor
• host, database, username and password obviously are the location, name and auth credentials for your database. Best practice is to pass these in from environment variables as shown
• cable is the configuration key for our Solid Cable SQLite instance! It’s important that we name it “cable” so it matches with the name in config/cable.yml
• <<: *sqlite is another YAML merge key that pulls in the config from the &sqlite anchor
• database pay close attention here! this is the path to the SQLite database file in production. In my case I have this in a volume mounted by Kamal. More on that later
• migrations_paths is the path in our codebase where we can add migrations specific to the SQL database

Solid Cable Configuration

Nothing to change here but as a reminder, Solid Cable is configured in config/cable.yml and important as mentioned above that the production database configuration key for the SQLite database we’re using for Solid Cable is named the same here. ie “cable”

production:
  adapter: solid_cable
  connects_to:
    database:
      writing: cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

Kamal SQLite Location

As I’ve written about numerous times in the past like here and here, I’m all in on Kamal! It’s a fantastic tool for deploying web apps. Previously I had only used PostgreSQL and only one database per app. Now we need to add SQLite to the mix. Fortunately it’s super simple, but I had one gotcha that took some fiddling to get right and wanted to capture here.

As you saw above, in the database.yml file we need to specify the name and location of the SQLite database file. The Rails default is to set this to database: storage/production_cable.sqlite3 which makes sense as a default.

In our case with Kamal, we want to make sure that this database persists across deployments, so we need to make sure it’s mounted on the server’s file system outside the docker container but still accessible from the container each time it’s deployed with Kamal.

Fortunately this is really easy too with the volumes key in config/deploy.yml. With this setting, Kamal will automatically make a persistent storage volume at /data on our server.

## config/deploy.yml
volumes:
  - "myapp_data:/data"

Then we need to make sure we are using this volume in the database.yml config so that Rails knows where to find the file. In my case above it’s database: /data/myapp_production_cable.sqlite3

The embarrassing “gotcha” I mentioned above was I was missing / in front of data so Rails was trying to put the database in the relative path /rails/data and not the volume I had mounted at /data! Very annoying but didn’t take long to realise :)

Deploying

Finally we just need to deploy the app! Kamal always runs rails db:prepare which will create our SQLite database the first time and that should be it! Solid Cable in production

Verifying

To double check our SQLite instance is up and running and brokering our web socket messages as we expect, we can jump in to the console in production to see if we have any messages. Make sure to trigger an event in your app first and then check if the message was persisted:

kamal app exec -i 'bin/rails console'

> SolidCable::Message.last
#<SolidCable::Message:0x00007ff53fe4b8f8
 id: 12,
 channel: "item_106",
 payload: "\"\\u003cturbo-stream action=\\\"prepend\\\" target=\\\"un...",
 created_at: "2024-11-30 12:26:30.443258000 +0000",
 channel_hash: -7306872458338484105>

Lovely! Here we can see a payload was captured to prepend some content on channel “item_106”.

Wrapping Up

OK! I didn’t find any articles specifically on actually deploying Solid Cable to production with SQLite while maintaining the primary database on PostgreSQL which prompted me to write this one. Future me thanks myself at least.

Don’t hesitate to drop me a note at my new favourite place Blue Sky or via any channels listed here

Solid Cable is a new adapter for Action Cable - now the default in Rails 8 - that brings the magic of web sockets and real time updates to your Rails app.

I’d never had chance to really use Action Cable before, but a colleague gave me a great suggestion to improve an internal tool I’ve been building, and that coincided with me having just reviewed some upcoming videos for the Rails Foundation - including solid cable - and a 90 minute train journey from Bristol to London!

How far could I get introducing real time updates to my app on a train to London I wondered? What could go wrong? Well, Solid Cable is so ridiculously simple that I’d finished before I even got to Paddington! Now en-route home on the same journey, I thought I would write up a blog post, as always, for future me. So, here we go.

Simple Demo App

Just to keep things really simple, lets create a new Rails 8 app that lets people chat. Here’s the simplest thing I could come up with but will be perfect to illustrate how to use Solid Cable.

First up you’ll need Ruby and Rails 8 on your machine. If you don’t yet, follow the steps in section 3.1 of the fantastic, newly polished and updated Rails Guides here

OK, lets go ahead and create our new Rails app:

rails new super-simple-chat -c tailwind

Next, we’re going to create a model, a controller and some views to play with. Initially we’ll use standard rails and the app will be feature complete. First we’ll cd into the app directory and generate the model, controller and index view by running these commands on the console:

# change into the app directory
cd super-simple-chat

# generate the Chat model and controller
rails g model chat message:string
rails g controller chats index create

# migrate the database
rails db:migrate

We need to add a bit of code here, and I won’t explain this in detail since it’s very basic Rails. I’ll save the more detailed descriptions for when we add the real time Solid Cable magic coming up. So, open up each of these files and replace the existing code in each with the code below:

config/routes.rb

Rails.application.routes.draw do
  resources :chats
  root "chats#index"
end

app/controllers/chats_controller.rb

class ChatsController < ApplicationController
  def index
    @chats = Chat.all
  end

  def create
    @chat = Chat.build(chat_params)
    @chat.save

    redirect_to chats_path
  end

  private

  def chat_params
    params.require(:chat).permit(:message)
  end
end

app/views/chats/index.html.erb

<div class="w-1/2">
  <h1 class="mb-6 text-slate-700 font-bold text-2xl">Chats</h1>
  <div class="space-y-4 mb-8">
    <div id="chats">
      <%= render @chats %>
    </div>
  </div>
  <%= render "form" %>
</div>

And then we need to create two partials, one for the input form, and one for the individual chat messages:

app/views/chats/_form.html.erb

<%= form_with model: Chat.new, local: false do |f| %>
  <div class="flex">
    <%= f.text_field :message,
        autocomplete: :off,
        class: "block w-2/3 rounded-md bg-white px-3 py-1.5 text-base text-gray-900 outline outline-1 -outline-offset-1 outline-gray-300 placeholder:text-gray-400",
        placeholder: "enter message..." %>
    <%= f.submit "Send",
        class: "inline-flex w-1/3 items-center justify-center rounded-md bg-slate-400 ml-3 px-3 py-2 text-sm font-semibold text-white shadow-sm" %>
  </div>
<% end %>

app/views/chats/_chat.html.erb

<div>
  <div class="flex justify-between items-start">
    <div class="text-gray-700">
      <%= chat.message %>
    </div>
    <div class="text-sm text-gray-400">
      <%= time_ago_in_words(chat.created_at) %> ago
    </div>
  </div>
</div>

The Basic App

OK! If you followed the instructions above, you should be able to run the app with bin/dev in the console and visit http://localhost:3000. It should look like the screenshot above, and you can type in chats and see them rendered above the input box. Try it out!

This actually works great, and shows the power of Rails out of the box. Whats happening is the text input is posted to the server and the page is reloaded rendering the list of messages.

If someone else sends a message from another server though, we won’t see it unless we reload the page. We want to see these messages in real time, that’s how we roll, so lets bring the magic with Solid Cable!

Introducing Solid Cable

We’ve built the basics, and this is essentially where I was with my app. To introduce Solid Cable we need to have the gem in our Gemfile and some minor configuration set up.

If you’re using Rails 8.0.0, you’re in luck. You don’t need to do anything! Solid Cable is available by default. If you don’t have Solid Cable for some reason, like an older version of Rails, you’ll need to add the gem and install as follows:

bundle add solid_cable
bin/rails solid_cable:install

Configuring Solid Cable

The main configuration file for Action Cable is config/cable.yml and by default in “development” the adapter is set to “async”. Since we want to enable Solid Cable on localhost, we need to update this file, so open it up and change:

development:
  adapter: async

to:

development:
  adapter: solid_cable
  connects_to:
    database:
      writing: cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

Then lastly we need to set up a cable database for Solid Cable to store our messages. Unlike the typical way Action Cable is used where events are published to Redis then immediately broadcast back to Action Cable with a pub/sub strategy, with Solid Cable, messages are written to a database and Solid Cable polls for new ones, broadcasting them back to clients when found. Solid Cable also cleans up after itself, trimming data older than message_retention above.

So we need to set up a new database to accept the events from Solid Cable. SQLite is perfect for this task so similar to the cable config above, we need to set up the “cable” database in our development environment. Open up the config/database.yml file and change the following:

development:
  <<: *default
  database: storage/development.sqlite3

to

development:
  primary:
    <<: *default
    database: storage/development.sqlite3
  cable:
    <<: *default
    database: storage/development_cable.sqlite3
    migrations_paths: db/cable_migrate

Now lets initialise the database with rails db:prepare

Unleash the Web Sockets

OK! Back to our app now. We’re going to add some real time web socket goodness with just a few lines of code!

Firstly we need to web socket enable our view so that newly broadcasted Chats can be rendered. Open up the app/views/chats/index.html.erb file and insert the turbo_stream_from tag on line 4 as shown here

<div class="w-1/2">
  <h1 class="mb-6 text-slate-700 font-bold text-2xl">Chats</h1>
  <div class="space-y-4 mb-8">
    <%= turbo_stream_from "chats" %>
    <div id="chats">
      <%= render @chats %>
    </div>
  </div>
  <%= render "form" %>
</div>

And then we just need to update our Chat model to broadcast when a new Chat is created. Open up app/models/chat.rb and replace the code with the following:

class Chat < ApplicationRecord
  after_create_commit :broadcast_chat

  def broadcast_chat
    broadcast_append_to(
      "chats",
      target: "chats",
      partial: "chats/chat",
      locals: { chat: self }
    )
  end
end

One last tidy up is we don’t need to redirect to the index page in the controller after a Chat is created. We’ll be updating the page via websockets, so we can just return nothing. In the app/controllers/chats_controller.rb file “create” action, simple replace the line

redirect_to chats_path

with

render json: {}, status: :no_content

Now you may not believe this. But thats it. You’re done! Restart your server, then open up two browsers and behold the magic! When you send a chat in one, you should see it in the other in real time, no refresh required!

Under the Hood

If you take a look in your Rails log you should be able to see not only the Chat record being inserted when a chat message is sent, but also the event being inserted in the cable database. It will looks something like this:

SolidCable::Message Insert (0.5ms)  INSERT INTO "solid_cable_messages" ("created_at","channel",
"payload","channel_hash") VALUES ('2024-11-26 06:23:40.882477', x'6368617473', x'225c753030336
3747572626f2d73747265616d20616374696f6e3d5c22617070656e645c22207461726765743d5c2263686174735c2
25c75303033655c753030336374656d706c6174655c75303033655c7530303363212d2d20424547494e206170702f7
6696577732f63686174732f5f636861742e68746d6c2e657262202d2d5c75303033655c75303033636469765c75303
033655c6e20205c753030336364697620636c6173733d5c22666c6578206a7573746966792d6265747765656e20697
f6469765c75303033655c6e202020205c753030336364697620636c6173733d5c22746578742d736d20746578742d6
77261792d3430305c225c75303033655c6e2020202020206c657373207468616e2061206d696e7574652061676f5c6
e202020205c75303033632f6469765c75303033655c6e20205c75303033632f6469765c75303033655c6e5c7530303
3632f6469765c75303033655c6e5c7530303363212d2d20454e44206170702f76696577732f63686174732f5f63686
1742e68746d6c2e657262202d2d5c75303033655c75303033632f74656d706c6174655c75303033655c75303033632
f747572626f2d73747265616d5c753030336522', -2034957492849835134) ON CONFLICT  DO NOTHING RETURNING
"id" /*action='create',application='SuperSolidCable',controller='chats'*/

and then also you can see our partial being broadcast out to clients with the “append” action

Turbo::StreamsChannel transmitting "<turbo-stream action=\"append\" target=\"chats\"><template>
<!-- BEGIN app/views/chats/_chat.html.erb --><div>\n  <div class=\"flex justify-between items-
start\">\n    <div class=\"text-gray-700\">\n      solid cable\n    </div>\n    <div class=\"te
xt-sm text-gray-400\">\n      less than a minute... (via streamed from chats)

Pretty damn cool!

Wrapping Up

This is quite a long blog post to demonstrate how you can add web sockets and real time updates in your Rails apps with a few lines of code, I know, but hopefully its been fun.

As always, oh wait, not as always as I moved to Blue Sky mostly, but yes, don’t hesitate to drop me a note there at https://bsky.app/profile/mileswoodroffe.com or via any channels listed here

Back in February I wrote about an exciting new deployment tool called Kamal announced by DHH and 37signals. It really was a great gift and I quickly switched my personal projects over to Kamal and hosting on cheap VPS’s a Hetzner. The cool-aid was flowing and it tasted.. well, great!

It was a bit fiddly to get working and had a few limitations - such as deploying multiple apps on one host was a challenge - but for my use case it was perfect. Been using it ever since.

Kamal 2

Just in time for Rails World 2024, Donal from 37signals announced Kamal 2 which introduced some key enhancements:

• kamal-proxy that replaces traefik
• automatic HTTPS and provisioning with Let’s Encrypt
• support for multiple apps on one server
• command aliases
• move away from .env for secrets

Upgrading to Kamal 2

I spent some time cautiously setting up a beta subdomain and deployed a second instance of my app to fresh servers just for testing the upgrade, but it was unbelievably straightforward. So much so, I was convinced it hadn’t changed anything but yep, it was that seamless!

The official upgrade guide is likely all you’ll need but I made the following brief notes to capture some nuances that tripped me up, and mainly to remind future me, but hopefully may help someone who stumbles on this page in the future.

1. Upgrade the Kamal gem

First things first, we need to update the gem! The guide tells us to make sure we have v1.9.0 or install if not, and then confirm we can do a deploy, since this is the first version that can reverse the upgrade we’re about to perform.

gem install kamal --version 1.9.0

Once we’ve deployed to confirm its all still working, we now can upgrade kamal to the latest. At the time of writing this is 2.1.1 but lets get the latest

gem install kamal

2. Deploy.yml Configuration Changes

OK! Now we’ve tested 1.9.0 and have a way back, and then installed the latest 2.x version of Kamal we’re ready to update the configurations.

Firstly we need to specify the architecture we’re building for. Remember Kamal uses Docker, and in my case its amd64. You can still do multi-architecture builds by adding another attribute eg arm64 but in my case, I dont need that.

builder:
  arch: amd64

The big change in Kamal 2 is kamal-proxy coming in to replace Traefik. So, we can remove all the previous configurations we had for traefik which in my case looked like this:

# Remove everything under `traefik:`
# traefik:
#   options:
#     publish:
#       - 443:443
#   args:
#     entryPoints.websecure.address: ":443"
#     api: true
#   labels:
#     traefik.http.routers.dashboard.rule: ...

Having removed the traefik config above, we need to configure kamal-proxy. Fortunately this is super simple. Add the following, ensuring to substitute in your-domain of course:

proxy:
  ssl: true
  host: your-domain.com

Some notes here. The docs were a bit confusing since setting ssl: true seemingly sets up Let’s Encrypt to issue an SSL cert, but only when you have one server.

In my case I’m using Cloudflare for SSL/TLS encryption, and despite reading I should set ssl: false, after much fiddling around, I found I did indeed need to set it to true and make sure Cloudflare Encryption Mode was set to “Full”.

The other gotcha for me was with Kamal 1.x traefik accepted the incoming connections on port 443 and expected the Rails server to be running on port 3000.

The default behaviour for Kamal 2.x and kamal-proxy is it to connect to port 80 on the Rails server. This is due to the addition of Thruster - more on that in a minute - but for now just know if you don’t plan to add Thruster, you need to tell the proxy to use port 3000 by adding app_port: 3000 under the proxy: key.

Lastly for the deploy.yml, you can optionally add aliases in Kamal 2.x. This is pretty handy. I was always looking up how to connect to the rails console on my app server for example. These are the defaults, but feel free to add your own too as needed

aliases:
  console: app exec --interactive --reuse "bin/rails console"
  shell: app exec --interactive --reuse "bash"
  logs: app logs -f
  dbc: app exec --interactive --reuse "bin/rails dbconsole"

So now you can just enter kamal console on the command line and boom, you’re dropped right into the console!

3. Move .env to .kamal/secrets

Next we need to update our secrets! Previously in Kamal 1.x it simply used the .env file for secrets which is really convenient but somewhat fragile as they serve other purposes too.

In Kamal 2.x a new .kamal/secrets file was introduced specifically for your secrets. The easiest way if you’re upgrading is to reference the env vars in .env that you need for your app. Create the file .kamal/secrets and add the following:

KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD
RAILS_MASTER_KEY=$(cat config/master.key)
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
S3_ACCESS_KEY_ID=$S3_ACCESS_KEY_ID
S3_SECRET_ACCESS_KEY=$S3_SECRET_ACCESS_KEY

One gotcha: I found I needed to prefix kamal commands with dotenv now to have the secrets available, so just fyi if you have issues with secrets, it may be this! eg. dotenv kamal deploy

4. Thruster

Thruster wraps Puma and provides some great features like Basic HTTP Caching, X-Sendfile support and compression, HTTP/2 support and Automatic TLS certificate management with Let’s Encrypt

It so simple to add, and since it default in Rails 8, lets go for it. First we need to add the gem:

bundle add thruster

Next, if you’re not using Rails 8 yet, you’ll need to add the command script, so create a new file bin/thrust and copy in the following, being sure to set the permission on that file after creating it with chmod 755 bin/thrust from your root directory:

#!/usr/bin/env ruby
require "rubygems"
require "bundler/setup"

load Gem.bin_path("thruster", "thrust")

Lastly we need to configure Docker to fire up Thruster by updating Dockerfile as below. Replace the first three lines with the second three lines:

- # Start the server by default, this can be overwritten at runtime
- EXPOSE 3000
- CMD ["./bin/rails", "server"]
+ # Start server via Thruster by default, this can be overwritten at runtime
+ EXPOSE 80
+ CMD ["./bin/thrust", "./bin/rails", "server"]

As you can see, this is where we’re setting Rails to run on port 80 as mentioned in step 2 above.

5. Run the upgrade command

OK!! Now we’re ready to rumble. WARNING run this on a test server first!

Here we go. Simply run the following to initiate the in-place upgrade process

kamal upgrade

This will remove traefik from your containers, add kamal-proxy and then reboot the current app.

Amazingly in my case, it Just Worked(TM)! I was so surprised I had to double check processes on the server to make sure, but yes, worked first time!

6. Rolling Back

If things didn’t go to plan, since we installed 1.9.0 (hopefully you did) then we can rollback.

Firstly, lets uninstall kamal 2.x. Make sure to set the version to the one you installed. In my case it was 2.1.1

gem uninstall kamal -v 2.1.1

Now lets check you have kamal 1.9.0 ready. Running the command below should return the output 1.9.0

kamal version

Next you need to revert the changes to deploy.yml and Dockerfile from steps 2 and 3 above, and then finally we can run the downgrade command that removes kamal-proxy and adds traefik back to your containers

kamal downgrade

Wrapping up

This is a really niche post. Only helpful if you a) installed Kamal 1.0 and b) for some reason don’t want to follow the official guides, but I like to document this stuff if only for myself. If it helps someone else. That’s a bonus!

As always, any questions of feedback, don’t hesitate to drop me a note on twitter or via any other channels listed here

I’m running out of superlatives! This time last year I was euphorically writing about Rails World on returning from Amsterdam as it was simply spectacular. Fast forward to today as I sit in my hotel room about to head home from Rails World 2024 in Toronto, the feeling is only amplified tenfold. This extraordinary bringing together of the Rails community to celebrate, share and learn is something truly special.

Highlights

The announcements in DHH’s keynote and release of Rails 8 were obvious highlights, but the energy and excitement that seems to be only getting more amplified since last year is what left the biggest impression.

The singular highlight was the moment David presented Matz with the Rails lifetime achievement award, and the sheer surprise and joy in Matz’ face that I managed to capture in this photo and tweet from the front row! (noticed DHH used this in his blog post too :D)

All of the sessions will be released on the official Rails YouTube channel over the next couple of weeks so make sure to check and enjoy any you missed or if you weren’t lucky enough to attend.

Rails Foundation

Lastly, I must thank Cookpad for supporting me and - with the other founding members - for their continued support of the Rails Foundation, without which none of this would happen.

Here’s a quick post just to document how I got video uploads working in Action Text, again mostly for “future me”, but hopefully helpful for others!

Let me say, I love Action Text and Trix. For me at least its exactly what I need for simple text input that users can format and also upload images. I won’t go into the details of how to set it up as there are countless great sources for that, the primary one of course being the Rails Guides which are great.

File uploads

One of the killer features of Action Text in my opinion is the way it handles file uploads so simply with a WYSIWYG interface. This is great for images but I couldn’t figure out why I couldn’t play uploaded .mov video files. And I really needed this for my use case of sharing technical issues and bug reports.

Default Templates

When you install Action Text with bin/rails action_text:install the default template for representing attachments will be generated in app/views/active_storage/blobs/_blob.html.erb and looks like this (Rails 8.0.0.alpha)

<figure class="attachment attachment--<%= blob.representable? ? "preview" : "file" %> attachment--<%= blob.filename.extension %>">
  <% if blob.representable? %>
    <%= image_tag blob.representation(resize_to_limit: local_assigns[:in_gallery] ? [ 800, 600 ] : [ 1024, 768 ]) %>
  <% end %>

  <figcaption class="attachment__caption">
    <% if caption = blob.try(:caption) %>
      <%= caption %>
    <% else %>
      <span class="attachment__name"><%= blob.filename %></span>
      <span class="attachment__size"><%= number_to_human_size blob.byte_size %></span>
    <% end %>
  </figcaption>
</figure>

I found that a thumbnail of the video was generated and displayed when I rendered out the content but I wanted to play the video! I expected adding something like this using the AssetTagHelper for video would render accordingly:

<% if blob.video? %>
    <%= video_tag url_for(blob), controls: true, preload: "metadata", class: "attachment__video" %>
...

but while I got a great preview still image of the video, I couldn’t play it…

Sanitization

Finally after a lot of head scratching I discovered that the tags were being sanitized away. Sanitizing the form input is critical since users may try all kinds of nefarious exploits to compromise our sites, but in this case supporting video seemed to be an ok trade-off.

The trick then is to allow the video related tags in the HTML to be rendered when showing Action Text content. To do this we need to add the following initializer in config/initializers/action_text.rb:

Rails.application.config.after_initialize do
  default_allowed_attributes = Rails::HTML5::Sanitizer.safe_list_sanitizer.allowed_attributes + ActionText::Attachment::ATTRIBUTES.to_set
  custom_allowed_attributes = Set.new(%w[controls])
  ActionText::ContentHelper.allowed_attributes = (default_allowed_attributes + custom_allowed_attributes).freeze

  default_allowed_tags = Rails::HTML5::Sanitizer.safe_list_sanitizer.allowed_tags + Set.new([ ActionText::Attachment.tag_name, "figure", "figcaption" ])
  custom_allowed_tags = Set.new(%w[audio video source])
  ActionText::ContentHelper.allowed_tags = (default_allowed_tags + custom_allowed_tags).freeze
end

What this is doing is telling Action Text to allow a “controls” HTML attribute and “audio”, “video” and “source” tags to be rendered from user uploaded content.

After restarting the server.. voila! You should see a video play button and scrub control!

Wrap Up

As always, don’t hesitate to drop me a note via twitter or any other channels listed here.

A quick note and recognition what a huge milestone just came with the 20th anniversary of the launch of Ruby on Rails, which was originally announced on July 25th, 2004!

A truly groundbreaking framework that is behind so many of the service we know and love over the last 20 years, it made me reflect on my journey and how grateful I am I found Rails.

My Rails Story

Back then I was living in San Francisco, having hung up the headphones on my touring sound engineer days, and was 4 years into turning my hobby in to work as a software developer. I was working in the ringtone business by then - remember those? - and our tech stack was Java, JSP, Servlets. You get the picture.

It wasn’t until late 2005 when I saw the seminal “How to Build a Blog Engine in 15 Minutes with Ruby on Rails” video from dhh when I first heard of Rails. I was immediately intrigued enough to build the blog from the demo, then start putting together some very simple reporting interfaces and tools for work. It really was groundbreaking and fun.

My office at the time was in the “Organic” building at 3rd & Bryant, directly over the road from South Park where another little Ruby on Rails project was getting started, called “Twitter”! or “Twttr” as it was. My memory is a bit fuzzy but I’m certain there were Ruby meetups at the Odeo/Twitter office, and definitely at CNET where a young chap called Chris Wandstrath was often talking about one new plugin or another like cache_fu. I wonder what ever happened to him? ;)

I went on to work at a few more startups in San Francisco over the next few years, always with Rails, before moving to Japan in 2010 to join Cookpad, who were famously one of the biggest Ruby on Rails services at the time. Exciting!

Community

Ruby and Rails has always seemed to have an incredible community, and it’s another thing I am immensely grateful for. I’ve had the chance to meet and work with some incredible folks, and with massive thanks to Cookpad, was able to lead the charge in supporting and attending numerous events and conferences worldwide. Again. Thanks Rails!

Ruby

Rails also introduced me to Ruby, like so many others, and I’ve been fortunate to be working with this incredible match up of expressive language and impressive framework ever since for the last 18 years! After moving back to the UK with Cookpad I was able to invite Matz, Koichi and Endoh-san to Bristol where somehow I manage to pull off an event that is almost unimaginable with Raphael, Tenderlove, and a whole host of open source Ruby and Rails developers.

The Rail Foundation

Lastly, when DHH contacted me in 2021 to pitch his idea of a Foundation to support the future success of Rails I immediately wanted to help. Fortunately through the incredible generosity of the leadership, Cookpad became one of the founding members of the Rails Foundation, and I was nominated to sit on the board. Through the foundation we’ve been able to launch an annual conference which got off to a spectacular start last year in Amsterdam and will be back in Toronto next month as well as numerous programs to improve documentation, tutorials and provide opportunities for people new to the framework.

Thanks DHH, the Core Team, and all contributors

I owe so much of my career and experiences to the joy I’ve had from working with Ruby, working with Rails, working with Ruby people. I can’t thank all those involved enough. What a ride. And here’s to the next 20!

Wrap Up

As always, don’t hesitate to drop me a note via twitter or any other channels listed here.