I'm in Canada, have about a decade in the field across a few full-stack and back-end contract and permanent roles, all using Rails in some capacity. Seeing almost no remote roles open to me.

There are a handful of remote roles posted in a month at the main remote work job boards such as https://jobs.rubyonrails.org/.

LinkedIn jobs search seems remarkably degraded in its utility from a few years ago -- putting in "Ruby Developer" returns 3000+ results of generic development and development related results. I remember being able to get decent results with a bit of search prompt refinement.

I'm aware that the wider tech market is in a bad recession currently, but our area seems to have been hit even harder. Is everything going through recruiters? Or is hiring for Ruby developers now dead as a door nail?

Two years ago I posted here about Plutonium, a rapid application development toolkit for Rails: https://www.reddit.com/r/rails/comments/1ddxv0b/a_rapid_application_development_toolkit_for_rails/

It's come a long way since and I also finally wrote about it properly (it is AI assisted): https://radioactive-labs.github.io/plutonium-core/blog/introducing-plutonium

What's in it:

- Resources. Your models, automatically exposed with CRUD, nested and action routes

- Portals. Apps, with multi-tenancy built in

- Authorization on ActionPolicy, per field and per action

- Definitions for customization, with everything else detected from your model

- Interactions for business operations

- Search, filters, sorting and CSV exports

- Rodauth for auth, generators for the boring parts

Newer and still experimental:

- kanban boards

- wizards

- async interactions (background actions with progress reporting)

Repo: https://github.com/radioactive-labs/plutonium-core

We are still pre-1.0, but the core is stable and running in production.
Would really appreciate feedback as we prepare for a 1.0 release.

New Remote Ruby episode is out!

This week David and I get into some of the things I’ve learned while building an MCP server for a Rails app, including:
- using the official Ruby MCP SDK
- where MCP resources fall short compared to tools
- OAuth and authorization with Doorkeeper
- some of the practical decisions that come up when adding MCP support to an existing Rails app

We also look ahead to Rails World in Austin and some of the talks we’re interested in, including Active Search, Ractors, Herb, Action Text, Solid Cable, custom Rails generators, and, appropriately enough, MCPs.

Most tutorials suggest setting up a separate Node microservice or heavy SPA frontend just to handle streaming AI responses.

You don't need that. You can stream token-by-token directly inside a pure Rails stack using ActionCable + Turbo Streams:

Wrap your API call (ruby-openai or anthropic) inside a dedicated Service Object.

Pass a chunk-handling block that broadcasts incoming tokens via Turbo Streams.

Target the DOM element directly—zero custom JavaScript state needed.

Keeps your codebase maintainable, fast, and native.

Hello, I'm offering my Rails World registration for a $200 discount. I registered a while back but unfortunately I can no longer go. It's in Austin, Texas, September 22-24. This is the standard $699 registration. The conference organization has an easy way to transfer registrations to a different attendees, so it will become your ticket with your name on it.

If you're interested, please send me a message. I'm happy to talk on the phone, and message through my professional LinkedIn or work email address, so you'll be confident that I'm legit.

I was browsing the new AI eval from the Rails team, and the best open-source LLM on their list is the new Qwen 3.8 28b: https://rubyonrails.org/ai

I've been wanting to try this out on my Mac. I burned a few hours trying several LLM runtimes (Ollama then MTPLX before I figured out oMLX is the best), and then it took quite a lot of tweaking to get it working well within Claude Code.

I rolled up all my tweaks into a simple script, in case anyone wants an offline LLM for Rails. This should save you a few hours:

https://github.com/keithschacht/qwaude

Rails 7.2 reached EOL on August 9. Rails 8.0 will reach EOL on November 7.

You need to upgrade on time. While Rails is supported, your gems and tools work smoothly together. Once it hits EOL, you start facing incompatible dependencies.

Most teams know how to do the upgrade. They create the branch, but it just sits there. Active product work creates merge conflicts, and nobody gets a clear week to finish it.

If your upgrade is stuck, happy to take it over. I run a small Rails agency and handle these regularly.

Ask if you have questions about your upgrade path.

Keyword frequencies taken from https://www.zoevera.com/resume/software-engineer-job-description-keywords

Most software engineer keyword lists are assembled from experience or guesswork. This one is a count: every open posting from 72 companies' public Greenhouse job boards, filtered to the 1,360 whose title contains "software engineer", then checked for how many mention each of 45 terms at least once.

The percentage beside each term is the share of those 1,360 postings that mention it.

PRACTICES AND WAYS OF WORKING

Scalability 52.9% - Mentoring 47.4% - Distributed systems 47% - System design / architecture 46.7% - Cross-functional 31% - Code review 27.2% - On-call 20.7% - CI/CD 19.5% - Agile / Scrum 9.3% - Unit / automated testing 6.5%

This is the result I did not expect. The four most common terms in the whole study are not technologies. Scalability, mentoring, distributed systems and system design all appear in more postings than Python does. Nearly half of these postings mention mentoring, and almost no engineer resume I have seen makes a claim about it.

Agile and Scrum at 9.3% is the other surprise, given how much resume advice insists on them.

LANGUAGES

Python 44.8% - Java 35.4% - Go 31.1% - TypeScript 19.8% - C++ 17.4% - SQL 17.3% - JavaScript 13.2% - Kotlin 12% - Rust 9.9% - Scala 8.6% - Ruby 8.5% - C# 5.3% - Swift 2.3%

TypeScript at 19.8% against JavaScript at 13.2% is a real ordering, not noise. The gap is wider than both margins of error combined.

CLOUD AND INFRASTRUCTURE

AWS 41.3% - Kubernetes 30.9% - GCP 19.3% - Azure 17.6% - Terraform 13.2% - Docker 12.6% - Microservices 7.1% - Linux 4.8%

AWS appears in more than twice as many postings as GCP and Azure individually. Kubernetes at 30.9% outranks every language except Python, Java and Go.

FRONTEND AND APIs

React 21.1% - REST / RESTful 9.6% - GraphQL 6% - Node.js 5.5% - Vue 3.2% - Angular 2.9%

Frontend framework lists usually present React, Vue and Angular as three comparable options. In this corpus React appears in roughly seven times as many postings as Vue and Angular combined.

DATA STORES AND PIPELINES

PostgreSQL 14.3% - Kafka 13.1% - MySQL 11.3% - Spark 9.8% - MongoDB 7.4% - Redis 7.4% - Elasticsearch 6.4% - Snowflake 5.6%

WHAT THIS SAMPLE IS NOT

These are 72 technology companies hiring through Greenhouse. Agencies, consultancies, banks, defense contractors and the public sector are absent, and their vocabulary is different - COBOL, .NET, SAP, clearance requirements and named compliance regimes barely register here and may dominate elsewhere.

The title filter is "software engineer" only. Postings titled backend engineer, frontend engineer, full stack developer, SRE or platform engineer were not counted, so this describes the generalist title rather than the whole profession.

Absence in this list is not evidence of absence in the market. Only 45 terms were counted. Next.js, Svelte, Django, Spring Boot, gRPC, Jest, Playwright, Datadog, OpenTelemetry and OAuth were never checked, so nothing here says anything about them either way.

It is a snapshot of open roles on one date rather than a trend, and the corpus is US-skewed.

One thing this sample size does buy: at n=1,360 the margins of error are roughly plus or minus 2 to 3 points, so most of the ordering above is real. Gaps under about 5 points are still worth treating as ties - React at 21.1% and TypeScript at 19.8% is not a meaningful difference.

METHOD

Greenhouse's public job board API, the endpoint companies expose so their listings can be embedded on their own sites. No scraping. Counts are document frequency: a posting saying "Python" nine times counts once. Deduped on company, title and content length, because one role posted to five offices returns five near-identical records. Median posting length is 896 words.

Ambiguous words are matched case-sensitively with exclusions, which matters more here than you would think. A bare word-boundary match on "Go" also catches "go to market" and "go above and beyond", which inflated Go by about two points before it was fixed. React, Spark, Swift and Rust all have the same problem.

Full table with all 45 terms and confidence intervals:

https://www.zoevera.com/resume/software-engineer-job-description-keywords

The wider keyword list this was checked against, organized by language, framework and platform:

https://www.zoevera.com/resume/ats-resume-tips-software-engineer

Happy to run the numbers on any terms missing from the list if people name them in the comments.

The Rails.Builders are a community of product creators who get together in live sessions. We share what we are working on, discuss each other's business challenges, and see how everyone approaches building with AI. It's the 6th cohort since 2025, and 20+ engineers have joined so far, with common reports of improved results, accountability, and networking.

The new “Continuous r-AI-ls.Builders” Edition starts with weekly sessions on Thursday, the 3rd of September at 17:30 CEST. We've even built an open-source (duh, Rails) app to manage attendance, the rhythm of live sessions, transcripts, communications, and the waitlist. That app will also show you the Builders who have signed up so far. I'm really excited that the group has shaped up like this.

All your FAQs and the sign-up are here: https://rails.builders

If you have more questions or doubts, you can send me a DM here. Happy building!

I've been building LiveCable for a bit now — it's a gem that gives you Phoenix LiveView-style components in Rails. State lives on the server, it's held over ActionCable, the DOM gets morphed, and you drive it from a handful of HTML attributes plus Stimulus.

Three things went in:

Loading states — while a message is in flight, LiveCable puts a live-loading attribute on the component root and on whatever triggered it, so you can style pending state with plain CSS and no JavaScript. live-disable-with on a button disables it for the round trip and optionally swaps the label; form values get serialized before anything is disabled. Reactive inputs get the attribute but are never disabled, so typing doesn't get interrupted.

Server-dispatched DOM events — dispatch_event('toast:show', message: 'Profile saved') from an action or a lifecycle callback. The event ships with the next broadcast and fires after the DOM has been morphed, so your handler sees the updated markup. They're bubbling CustomEvents from the component root (or from window), which means ordinary Stimulus data-action syntax handles them — there's nothing LiveCable-specific to write on the client.

A component test harness — include LiveCable::Testing, then live_mount('counter') and counter.perform(:increment). No browser, no real cable connection, runs in milliseconds. But actions go through the real message pipeline, so action whitelisting, param parsing, change tracking and re-rendering all get exercised for real.

LiveCable's template compiler is a Herb::Engine subclass, so live templates get parsed HTML-aware instead of as strings. This release bumped Herb from 0.8 to 0.10 — and a few days later Rails merged Herb into Action View as an HTML-aware ERB implementation, with actionview now depending on herb >= 0.10. It isn't the default engine yet (Erubi still is, and the opt-in config is a follow-up PR), but it's nice that Herb won't be an extra dependency now.

There's already a 0.2.1 out with a couple of fixes worth having: a race where the opening render could get dropped on subscribe (component would just sit there showing disconnected), and components not reattaching after a Turbo Drive navigation.

Docs: https://livecable.io

Source: https://github.com/isometriks/live_cable

Sandbox app if you want to poke at it: https://github.com/isometriks/live_cable_app

The next thing I have been working on is handling streaming data better. For instance, in a chat app, you would want to be able to add a message or delete it and only have that message changed instead of updating the entire chat frame. Happy to hear any thoughts if anyone has any other features in mind.

Disclaimer: Used AI to help me write the text:

Hey everyone,

I’m a full-stack developer, although a significant part of my experience has been on the frontend. I’ve worked quite a bit with React, TypeScript, Tailwind, etc., but I’ve always really enjoyed Ruby and Rails.

I’ve recently found myself with some extra time and would like to use it to contribute to the Ruby/Rails ecosystem through open source. I’d especially like to contribute in an area where my frontend experience could actually be useful.

I came across Glimmer DSL for Web. I found the idea of building interactive web applications with Ruby really interesting, especially coming from a frontend background. So i thought about starting porting Shadcn to Glimmer as a project to help the community.

It also got me thinking about the broader Ruby frontend ecosystem. There are quite a few different approaches now, Glimmer, Phlex, ViewComponent, Stimulus/Hotwire, and I'm trying to figure out where contributing my time would actually be most valuable.

So I’d love to get some feedback about your opinion.

• Is Glimmer DSL for Web something you think would benefit from more contributors? Does the approach have enough potential that investing time into its ecosystem, documentation, components, etc. would be valuable?
• Or would it be more useful to contribute to something like Phlex, ViewComponent, Stimulus/Hotwire, or another existing Ruby frontend approach?
• Do you think there is a real opportunity for Ruby to provide a better frontend experience, or is the ecosystem already in a pretty good place with Hotwire + Stimulus + server-rendered views?
• And from a practical perspective, what would you actually like to see someone build? Better component libraries, JavaScript-free interactions, accessibility-focused components, documentation, integrations, tooling, etc.?

I love Ruby, but in a lot of my professional work I've ended up reaching for JavaScript and other frontend ecosystems when building more sophisticated interfaces. Now that I have some time to contribute, I'd really like to see if I can help make the Ruby side of frontend development a little better.

So if you've used Glimmer, Phlex, ViewComponent, Stimulus/Hotwire, or other approaches, I'd especially love to hear what you think is promising, what's missing, and where you think a frontend-focused contributor could have the biggest impact.

Thanks!

Disclosure: I build r/lucanto, the Rails app described here. I used an AI assistant to help edit this post; the architecture, measurements, and deployment mistakes are from our production repo and runbook.

We recently moved our Rails 8 web and Solid Queue workloads from a Render to Hetzner, deployed with Kamal 2. Our setup is two CX23 web nodes behind a Hetzner LB, plus one CX43 for Solid Queue and the operational Postgres databases used by Queue/Cache/Cable. The primary Postgres remains still Render managed service (until we prepare our own setup for backup and restore - any tips are welcome).

The reason? We were looking for cheaper option and wanted to have the same environment for testing and production. The same setup would cost us maybe 395 EUR / month. Now it is around 35 EUR / month.

How we did the setup:

• boot.limit: 1 replaces one web host at a time;
• Kamal Proxy sends traffic to the new container only after `/ready` returns 200;
• /read checks the primary DB, but deliberately not Cache/Queue/Cable, so a degraded auxiliary DB cannot eject every web node from the LB;
• the old target drains for 30 seconds;
• asset_pathbridges fingerprinted assets between releases.

The more interesting failure was a deploy that looked completely healthy. We originally released web and jobs separately. One command resolved the movinglatest-production image instead of the exact SHA. Web ended up on one commit and the Solid Queue job role on another. Both roles were healthy, jobs were running, and normal uptime monitoring had nothing to complain about. The skew lasted few minutes until I noticed.

We now deploy both roles with one kamal deploy, from one image tagged with the Git SHA, and fail the post-deploy check unless web and jobs each report one identical SHA.

The main conclusion for us: Kamal can make the container swap without "gaps", but it cannot make an incompatible release safe. We still need expand/migrate/contract DB changes, capacity for old/new container overlap, meaningful readiness checks, externalized state, and a separate rolling procedure for rebooting Kamal Proxy itself.

So the claim I am comfortable with is “routine web releases without a planned maintenance window,” not “the whole stack is HA.” The job host and its operational Postgres are still one failure domain.

Do you have experience with deployments like this? If you can share, what could be improved, I would be truly glad to hear that. Also if you have any recommendations for DB backup and restore - I like the option Render have - select few minutes before and just restore that database.

https://minitestrails.com/blog/testing-user-registration-rails-minitest/

Learn how you can add registration feature to the auth setup generated by the Rails 8 authentication generator and then test it with Minitest.

You will add:

- Model validations for registration related rules

- Comprehensive integration tests covering all edge cases possible for the registration flow

- Smoke styled system test to test the happy path of registration: visit registration page, enter valid input, submit the form and assert user is signed in to the app

...or RubyLLM 🤖 meets Action Policy 🛡️.

Learn how we try to keep our in-app AI assistance (chat) flexible (and powerful) while not compromising the users.

RubyLLM tools, SQL analyzer, policies integration and more.

The man who set back programming by years, but at least it worked, well sort of.

https://www.youtube.com/watch?v=NYFGCESmikA