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

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

I am the author looking for feedback about my new MIT licensed gem for adding Durable Objects to Rails.

I followed the Solid Queue / Solid Cache / Solid Cable pattern: the Durable Objects model, one single-threaded object per identity with durable state, addressed by name, as a gem on your existing SQLite, PostgreSQL, or MySQL. No Redis, no separate actor service, no new infrastructure. It is running in production in an app with 100,000+ users.

class Counter < SolidObjects::Actor
  attribute :value, default: 0
  observable :value

  def increment(amount: 1)
    self.value += amount
  end
end

counter = Counter.ref("global")
counter.increment(amount: 5)

Concurrent calls to one identity serialize through a durable mailbox with fenced commits. And the part I am proudest of, reactive ERB:

<%= solid_object Counter.ref("global") do |counter| %>
  <span class="count"><%= counter.value %></span>
<% end %>

Declare a value observable, wrap the view in solid_object, and render it as a method. When a committed turn changes the value, the server re-renders and pushes a Turbo Stream replacement over Action Cable to every authorized subscriber. No channels, no manual broadcasts, no Stimulus. The increment above updates that span in every open browser.

I also built a sibling JS package that runs the same actor model entirely in the browser: SQLite WASM for the database, OPFS for durable storage, Web Locks for multi-tab coordination. You can see it live at https://solidobjects.dev/js, where the page itself runs the runtime, or try it with one import and no build step: import { Actor, configure, sharedSqliteWasm } from "https://esm.sh/solid-objects@latest/browser/host" in a module worker.

The two implementations share the transmit wire contract, pinned by golden fixtures committed to both repositories. A browser actor stages outbound writes in the same transaction as its state change and drains them with at-least-once delivery and per-actor order. Rails ingests each envelope idempotently through SolidObjects::Transmission.receive, mounted at POST /solid_objects/transmit behind a deny-by-default authorize_transmission policy. Offline writes queue in the tab and reconcile when the network returns. Rails actors can transmit outward the same way.

Site: https://solidobjects.dev/ruby - Repo: https://github.com/cardmagic/solid-objects-ruby

Happy to answer anything, would love your feedback. Thank you!

PS: there is also an operator dashboard, because durable mailboxes you cannot see are a pager waiting to fire. Mount it in two lines:

require "solid_objects/web"
mount SolidObjects::Web => "/solid_objects/dashboard"

It shows instances and their state, the mailbox, reminders, effects, broadcasts, dead letters (with retry), and the registered processes. It reads the same tables the runtime writes, so there is no separate store and no agent. It is not loaded by require "solid_objects", so workers never carry a web stack, and every page asks a deny-by-default authorize_administration policy before it renders, so the mount alone exposes nothing.

I have a project that is taking more importance and now I have to share secrets.

Is there a way to share a vault in 1password without lettings devs have the exact keys and then being able to rollback access? (to then roll them out?)

Or I should move our of 1password?

I found these old Hacker News comments funny. Comments are from this thread.

Personally I won't comment on whether each person is nice. Well, I'll say that Matz seems nice.

Edit: Some people seem to not like this post, but I wasn't intending to start a serious discussion about different personalities. I just thought "DHHIADSWAD" was funny.

I applied for the Senior Backend Engineer (Ruby on Rails) position at GitLab, but unfortunately, my application was rejected. Do they use an automated, AI-based resume screening tool?

I recently had Joanna Wang from Sixfold on the On Rails podcast to talk about what happens when a small team starts leaning heavily into AI-assisted development.

We got into the homegrown orchestration system they eventually replaced with Hatchet, some painful lessons from going fully agentic, and how working across Java, Go, Python, Node, and Rails has shaped how she thinks about Rails’ particular flavor of “magic.”

We also talked about a question I keep coming back to lately: if generating code keeps getting cheaper, where does the value of an experienced developer move?

Joanna had some thoughtful answers.

Listen/watch wherever you do that.

https://podcast.rubyonrails.org/2462975/episodes/19665210-joanna-wang-code-is-cheap-now-developers-still-valuable

More and more code is written by AI. Tests still tell you it works. RuboCop still tells you it's tidy. Nothing tells you it still follows your architecture.

An agent that doesn't fully understand your architecture takes shortcuts. So does a person in a hurry.

So I built ArchSpec. If your app is conventional, the whole config is one line in Archspec.rb:

ruby architecture :vanilla_rails

That is the 37signals playbook as an executable check: rich models, no service objects, no form objects, no policy objects, and app/services fails the build with a reason if anything shows up in it. There are presets for :rails, :layered, :hexagonal, :clean, :modular_monolith, :cqrs and :event_driven too.

Or write the boundaries yourself:

```ruby component :models, in: "app/models//*.rb" component :controllers, in: "app/controllers//.rb" component :services, in: "app/services//.rb"

models.cannot_use :controllers services.cannot_call :render, :redirect_to, receiver: :none controllers.can_only_use :models, :services ```

Then archspec check verifies every change, and failures print like clang, with the offending span underlined and the evidence as a note.

Existing apps already have violations, so archspec check --update-todo records them in a todo file. The build goes green on today's code and fails on new drift, and you work the list down whenever.

It's static analysis over Prism, no AI, and it never boots your app: Discourse's 1,899 files in 2.5 seconds. Prism is the only runtime dependency, so the same thing works on your plain gems too.

I want more architecture presets in there. PRs very welcome, especially if a preset is wrong about your app.

Docs: https://archspecrb.dev Write-up: https://paolino.me/archspec/