# Rails Published articles for Rails. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Rails Hyperdrive: supercharged agentic development for Rails DevFeed: [Rails Hyperdrive: supercharged agentic development for Rails]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-09-15T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Ruby on Rails](), [AI-assisted coding](), [Model Context Protocol]() Tags: [agent-experience](), [ai](), [ai-coding-agents](), [claude-code](), [mcp](), [open-source](), [rails](), [ruby-on-rails](), [ruby-on-rails-consulting]() ### AI overview This tutorial introduces Rails Hyperdrive, a development-only Rails engine that gives AI coding agents live answers from a booted Rails application and lets gems provide agent guidance through Gemfile-gated knowledge. It covers installation, MCP server setup, skills, sub-agents, slash commands, upgrades, and integration for gem authors. ### Source excerpt Introducing Rails Hyperdrive: a development-only Rails engine that gives AI coding agents live answers from your booted app and lets any gem in your bundle ship guidance gated to your Gemfile. Convention over configuration, applied to agent knowledge. ## Why Gusto hired Evil Martians for Sidekiq infrastructure DevFeed: [Why Gusto hired Evil Martians for Sidekiq infrastructure]() Original publisher: [Read original article]() Author: Irina Nazarova (inazarova@evilmartians.com) Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [Evil Martians]() Topics: [Sidekiq](), [Rails](), [Redis](), [Ruby]() Tags: [ai](), [case-study](), [engineering](), [infrastructure](), [rails](), [redis](), [ruby](), [scale](), [sidekiq]() ### AI overview This case study examines why Gusto hired Evil Martians to work on the Sidekiq and Redis infrastructure supporting background jobs in its large Rails monolith. It discusses the operational demands of running payroll-related jobs at scale and the tradeoffs involved when a company uses consultants instead of waiting for a perfect hire. ### Source excerpt Gusto runs payroll for 500,000+ businesses on one of the largest Rails monoliths anywhere. Why a team this strong hired Evil Martians for Sidekiq at scale, what running background jobs at that size actually takes, and when to stop waiting for the perfect hire. ## Why engineers should come to the SF Ruby Startup Conference in 2026 DevFeed: [Why engineers should come to the SF Ruby Startup Conference in 2026]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-08-26T00:00:00Z Content type: opinion Language: en Sources: [Evil Martians]() Topics: [Ruby](), [Rails](), [Open Source](), [Development](), [React]() Tags: [2026](), [agentic](), [ai](), [conference](), [developer-community](), [llms](), [open-source](), [rails](), [react](), [ruby]() ### AI overview The SF Ruby Startup Conference is presented as an engineers' conference focused on Ruby, Rails, open source, production systems, and community connections. The article explains its emphasis on building Ruby success stories and highlights Inertia Rails as an approach for building Rails applications with React. ### Source excerpt The SF Ruby Startup Conference is an engineers' conference: meet the people building Ruby open source, scaling Rails in production, and shaping what agentic Rails looks like next. ## Access control for AI agents on Rails: gating SQL with Action Policy DevFeed: [Access control for AI agents on Rails: gating SQL with Action Policy]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-08-25T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Access Control](), [Authorization](), [Rails](), [SQL](), [agent observability]() Tags: [access-control](), [agents](), [ai](), [ai-agents](), [llms](), [open-source](), [prompt-injection](), [rails](), [ruby](), [sql]() ### AI overview This article explains how Evil Martians protected sensitive data in an internal Rails AI assistant that uses open-ended SQL analytics. It describes moving authorization from prompts into Action Policy so read-only database access also respects which rows and fields an employee may reveal. ### Source excerpt Our Rails AI assistant had read-only SQL access and could still return peer review scores. Learn how we kept open-ended analytics in an in-app AI assistant while making database access honor application permissions. ## How to reduce Rails boot time with require-profiler and Bootsnap DevFeed: [How to reduce Rails boot time with require-profiler and Bootsnap]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-08-19T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Rails](), [Optimization](), [Ruby](), [Instrumentation](), [Docker](), [Development]() Tags: [development](), [docker](), [dx](), [instrumentation](), [optimization](), [performance](), [rails](), [ruby]() ### AI overview This guide explains how to profile and reduce Rails application boot time using require-profiler, sampling profilers, and Bootsnap. It describes profiling results from real projects, including a 40% reduction for a 200-component monolith, and covers cache precompilation and verification in Docker-based production builds. ### Source excerpt Rails boot time is a DX metric in the AI age: meet require-profiler, learn to actually read sampling profilers, and see the pit stop that cut a 200-component monolith's boot by 40%. ## Ruby Instance Variables Are Not Inherited (and Why That Breaks Your DSL) DevFeed: [Ruby Instance Variables Are Not Inherited (and Why That Breaks Your DSL)]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2026-08-14T00:00:00Z Content type: article Language: en Sources: [Daniel Doubrovkine]() Topics: [Ruby](), [bug](), [Library](), [Development](), [Rails]() Tags: [bug](), [development](), [library](), [open-source](), [pull-requests](), [rails](), [ruby]() ### AI overview This article explains how Ruby instance variables used by the ruby-enum gem are not inherited by subclasses, causing failures involving subclassing, class reloading, and redundant module inclusion. It describes fixes shipped in ruby-enum 1.2.0, including lazy defaults and explicit merging of inherited enums. ### Source excerpt The ruby-enum gem is a small library I maintain that adds enum-like behavior to a class via include Ruby::Enum and define :KEY, value. Four pull requests landed against it recently, each fixing a different symptom, and all four turned out to be the same underlying bug: class-level instance variables set in a module's included hook are not inherited by subclasses the way you might expect. All of these fixes shipped in ruby-enum 1.2.0. Ruby::Enum stores its keys and values in instance variables on the class itself, set up when the module is included. def self.included(base) base.extend ClassMethods base.instance_variable_set(:@_enum_hash, {}) base.instance_variable_set(:@_enums_by_value, {}) end This works fine for a single class. It gets interesting the moment subclasses or class reloading show up. A user opened #56, reporting DuplicateKeyError from a Rails console after a class that had already defined its enums got reloaded. It reproduces without Rails. class_body = proc do include Ruby::Enum define :RED, 'red' end Colors = Class.new(&class_body) Colors.class_eval(&class_body) # raises DuplicateKeyError Rails' development-mode autoloader re-evaluates a class body, and the second define :RED sees @_enum_hash still holding RED from the first load, so the duplicate-key check fires. The fix clears the hash whenever Ruby::Enum is included, rather than assuming it's always a fresh class. The contributor that reported the problem and submitted the fix also caught a sneakier variant: a subclass that redundantly re-includes Ruby::Enum (include is supposed to be idempotent, right?) was wiping out enums inherited from its parent, because included unconditionally reset the instance variables: class OtherSecondSubclass < FirstSubclass include Ruby::Enum # redundant, but shouldn't lose FirstSubclass's enums define :MAGENTA, 'magenta' end Thanks, Nazar, for tracking both of these down with tests. Months later, #49 surfaced a related crash: a subclass that never calls define itsel ## Fair by design: orchestrating background jobs in Ruby DevFeed: [Fair by design: orchestrating background jobs in Ruby]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-08-11T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Ruby](), [jobs](), [Latency](), [autoscaling]() Tags: [autoscaling](), [how-to](), [jobs](), [latency](), [performance](), [rails](), [redis](), [ruby](), [sidekiq]() ### AI overview This tutorial examines fairness in Ruby background-job processing. It explains how queue latency affects quality of service, why adding workers or autoscaling may be limited by shared resources and operational cost, and introduces background-job prioritization as a way to address bottlenecks. ### Source excerpt Are you treating your users fairly? They could be stuck in the queue while a greedy user monopolizes resources. And you might not even know it! In this post, you'll see if it's time for you to take background job prioritization seriously, and how to make it fair for all users. ## Upgrading Rails 4.2 to Rails 8: Count Sites, Not Warnings DevFeed: [Upgrading Rails 4.2 to Rails 8: Count Sites, Not Warnings]() Original publisher: [Read original article]() Published: 2026-08-08T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Rails](), [upgrade](), [version](), [Test coverage](), [RSpec](), [Docker Compose](), [Ruby]() Tags: [coverage](), [docker-compose](), [rails](), [rspec](), [ruby](), [upgrade](), [version]() ### AI overview An account of upgrading a multi-tenant JSON API from Rails 4.2.7.1 to Rails 8. The author argues that estimates focused on version gates missed the actual risks, and describes how characterization tests, an extracted frontend, and containerized development reduced the work. ### Source excerpt . [Upgrading Rails 4... ## The Fellowship of Code: My Quest at Ruby for Good in Ghent DevFeed: [The Fellowship of Code: My Quest at Ruby for Good in Ghent]() Original publisher: [Read original article]() Author: Fiona McLaren Published: 2026-07-27T14:09:36Z Content type: opinion Language: en Sources: [FreeAgent]() Topics: [Ruby](), [Rails](), [Azure](), [Content Management System](), [Open Source]() Tags: [azure](), [cms](), [coding](), [conferences](), [culture](), [development](), [open-source](), [open-source-code](), [rails](), [ruby](), [ruby-on-rails]() ### AI overview A junior developer describes attending Ruby for Good in Ghent and contributing to SkillRX, a project providing medical education materials in low-resource areas. The team addressed inefficient Azure file-storage synchronization by planning Beacons that communicate directly with the health professionals' CMS. ### Source excerpt It isn't very hard to pitch tech conferences. Offering a getaway from the usual desk work, a chance to pick up on new wisdoms from like-minded and genuinely inspiring folk, and room in the itinerary for sightseeing and socialising in the hip host city in between times? It's a no-brainer... well, for most. I had [...] ## Detecting Full Table Scans With SQLite DevFeed: [Detecting Full Table Scans With SQLite]() Original publisher: [Read original article]() Published: 2026-07-15T15:26:22Z Content type: tutorial Language: en Sources: [Aaron Patterson]() Topics: [SQLite](), [Databases](), [Development](), [Rails]() Tags: [database](), [index](), [query](), [rails](), [sqlite](), [test]() ### AI overview This tutorial shows how to detect full table scans in SQLite by inspecting prepared-statement statistics after executing a query. It demonstrates checking full-scan steps, then adding an index to eliminate the scan, and discusses possible Rails integration for test or development warnings. ### Source excerpt I'm at RubyConf this week, and it's great! I recently read that lobste.rs is now running on SQLite. One part from the post caught my attention: I wish we could say in a test, "Fail if you encounter any full table scans". Which would have caught the perf issues we experienced during the first deploy. SQLite collects information about prepared statements and exposes those statistics though an API. The upshot of this is that we can tell whether a statement did a full table scan after executing the statement without using an EXPLAIN. Here's an example program that demonstrates detecting a query did a full table scan: db = SQLite3::Database.new(":memory:") db.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER)") # Insert a bunch of records 1_000.times do |i| db.execute("INSERT INTO users (name, age) VALUES (?, ?)", ["user#{i}", i % 100]) end def query(db) # Prepare a statement and query it stmt = db.prepare("SELECT * FROM users WHERE age = ?") stmt.bind_param(1, 42) stmt.to_a # Check the number of full scan steps to detect full table scan fullscan_steps = stmt.stat(:fullscan_steps) puts "fullscan_steps: #{fullscan_steps}" if fullscan_steps > 0 puts " => query performed a full table scan" else puts " => no full table scan" end end # No index, so we'll see a full table scan query(db) # Create an index db.execute("CREATE INDEX idx_users_age ON users(age)") # Added an index, so no full table scan query(db) Feels like we could integrate this in to Rails and warn or raise in test / development. I'm not sure if we'd want to check this all the time in production, but maybe it would be fine? ## The joy of Inertia Rails: painting your own with 50 happy little lines DevFeed: [The joy of Inertia Rails: painting your own with 50 happy little lines]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-07-14T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Rails](), [Single-page application (SPA)](), [React](), [JavaScript](), [Web Development]() Tags: [hotwire](), [javascript](), [open-source](), [rails](), [react](), [turbo]() ### AI overview This tutorial rebuilds the Inertia Rails protocol on a real Rails app using a 50-line React client and a 16-line Rails renderer. It explains how rendering JSON instead of HTML on later visits connects server-owned navigation with a frontend component model, and audits what the official gem adds. ### Source excerpt Inertia is Turbolinks with one twist: render JSON instead of HTML on the second visit. We rebuild the whole protocol on a real Rails app with a 50-line client and a 16-line server, then audit what the real gem adds on top. ## Writing expressive RSpec tests for Ruby objects and Rails views DevFeed: [Writing expressive RSpec tests for Ruby objects and Rails views]() Original publisher: [Read original article]() Author: Simon Fish Published: 2026-07-07T13:26:00Z Content type: tutorial Language: en Sources: [FreeAgent]() Topics: [RSpec](), [Testing](), [Ruby](), [Rails](), [render]() Tags: [rails](), [render](), [rspec](), [ruby](), [ruby-on-rails](), [testing](), [tooling]() ### AI overview The article explains how to use RSpec expressively to separate test phases, clarify expected behavior, and document interfaces. It also discusses why this approach needs adjustment when testing Rails views, which are rendered templates rather than ordinary Ruby objects. ### Source excerpt Using RSpec's functionality expressively helps to draw focus to the right parts of a test, but it's not always easy to understand how best to use it. ## 2 Martians, greenfield to MVP in 4 weeks: agentic coding on Rails DevFeed: [2 Martians, greenfield to MVP in 4 weeks: agentic coding on Rails]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-06-09T00:00:00Z Content type: article Language: en Sources: [Evil Martians]() Topics: [agentic-coding](), [Rails](), [coding](), [React](), [Storybook](), [Open Source](), [stripe]() Tags: [agentic](), [agentic-coding](), [ai](), [app](), [authentication](), [building](), [case-study](), [coding](), [designer](), [developer-marketing](), [developer-products](), [google-analytics](), [onboarding](), [open-source](), [payments](), [platform](), [product](), [product-development](), [production](), [prototype](), [rails](), [react](), [skills](), [storybook]() ### AI overview A designer and an engineer describe how they shipped Thicket, a production MVP, in four weeks using agentic coding with Rails, Inertia, React, and Storybook. They discuss their workflow, project-specific skills, user validation, and the resulting open-source practices. ### Source excerpt A designer and an engineer shipped a production MVP in four weeks on Rails + Inertia. In this post, we share our agentic coding stack, the skills we built, and why it clicked. ## Your AI Coding Rules Should Not Live in Cursor Rules DevFeed: [Your AI Coding Rules Should Not Live in Cursor Rules]() Original publisher: [Read original article]() Author: Ivan Morgillo Published: 2026-05-29T16:42:19Z Content type: opinion Language: en Sources: [Ivan Morgillo]() Topics: [Rails](), [AI-assisted coding](), [Flutter](), [Markdown](), [coding]() Tags: [ai-coding](), [coding-agents](), [flutter](), [maintenance](), [markdown](), [rails]() ### AI overview The author argues that AI coding instructions should not be maintained separately in editor-specific files. Instead, shared development standards for Rails and Flutter projects should live in versioned Markdown files, while tool-specific files act as adapters and local project rules handle exceptions. ### Source excerpt I stopped treating editor-specific AI rule files as the source of truth and moved my Rails and Flutter standards into plain Markdown that Cursor, Claude, Codex, Copilot, and future agents can all discover. ## Rails Security, AI, and IBB DevFeed: [Rails Security, AI, and IBB]() Original publisher: [Read original article]() Published: 2026-05-06T17:31:54Z Content type: opinion Language: en Sources: [Aaron Patterson]() Topics: [Rails](), [Artificial Intelligence](), [Bug Bounty](), [Security]() Tags: [ai](), [bug-bounty](), [rails](), [security]() ### AI overview A Rails team member reflects on the Internet Bug Bounty program, describing how AI-generated low-quality security reports overwhelmed the team and contributed to the program stopping new submissions and bounty payments. The change also removed incentives for legitimate researchers and left Rails handling payment-related questions. ### Source excerpt For quite a few years the Rails project has been working with the Internet Bug Bounty (IBB). The IBB is an organization that awarded cash to security researchers that reported issues to OSS projects participating in the IBB. For quite a while I wasn't certain about my feelings toward the program because I felt like cash rewards could incentivize low quality reports as well as encourage reporters to "haggle" about the severity of a particular bug (the IBB paid more when the bug was more severe). In the beginning that certainly was the case. We were fielding many low quality reports, and people were haggling over severity. But the program evolved, and despite the never-ending haggling, I felt it did more good (rewarding security researchers) than bad (forcing the security team to wade through low quality reports). That is, until AI came along. Sometime in 2025 our team started getting inundated with low quality AI generated reports. I know for sure this wasn't unique to just our team as well. Anyway, AI lowered the barrier to generate reports, so we were back in the era of wading through low quality reports. Only this time, the low quality reports were masquerading as high quality reports. AI made it easy to turn a bullshit problem into something that looked legit, and since there's a possibility of money involved people tried to take advantage of the situation. We even had a report where someone forgot to delete the AI generated output and just uploaded the report as-is with the following text: ## ✅ READY TO SUBMIT! *All information prepared for professional Rails bug bounty submission.* *Expected Outcome:* Rails Team Response: 1-2 weeks Fix Development: 2-8 weeks Security Release: 8-12 weeks IBB Bounty: $1,040-1,600 (80% of $1,300-2,000) *Next Step:* Copy information above into HackerOne form and submit! I enjoy using AI, but I really don't like AI being used on me. But that's not what this post is about. Recently the IBB stopped accepting new submissions. In other ## CVE-2026-41316: ERB @\_init deserialization guard bypass via def\_module / def\_method / def\_class DevFeed: [CVE-2026-41316: ERB @\_init deserialization guard bypass via def\_module / def\_method / def\_class]() Original publisher: [Read original article]() Published: 2026-04-21T07:51:00Z Content type: news Language: en Sources: [Ruby-lang]() Topics: [vulnerability](), [Security](), [Ruby](), [Rails]() Tags: [cve](), [rails](), [ruby](), [ruby-on-rails](), [security](), [update](), [vulnerability]() ### AI overview Ruby reports CVE-2026-41316, a deserialization vulnerability in ERB. Ruby applications that call Marshal.load on untrusted data with erb and activesupport loaded may be vulnerable to arbitrary code execution. The advisory recommends upgrading the erb gem to a fixed version. ### Source excerpt We published security advisory for CVE-2026-41316. CVE-2026-41316: ERB @_init deserialization guard bypass via def_module / def_method / def_class A deserialization vulnerability exists in ERB. This vulnerability has been assigned the CVE identifier CVE-2026-41316. We recommend upgrading the erb gem. Scope Any Ruby application that calls Marshal.load on untrusted data AND has both erb and activesupport loaded is vulnerable to arbitrary code execution. This includes: Ruby on Rails applications that import untrusted serialized data - any Rails app (every Rails app loads both ActiveSupport and ERB) using Marshal.load for caching, data import, or IPC Ruby tools that import untrusted serialized data - any tool using Marshal.load for caching, data import, or IPC Legacy Rails apps (pre-7.0) that still use Marshal for cookie session serialization Details ERB implements an @_init guard to prevent code execution when ERB objects are reconstructed via Marshal.load on untrusted data. However, ERB#def_method, ERB#def_module, and ERB#def_class evaluate the template source without checking this guard, allowing an attacker who controls the data passed to Marshal.load to bypass the protection and execute arbitrary code. In particular, def_module takes no arguments, making it straightforward to invoke as part of a deserialization gadget chain. Please update the erb gem to version 4.0.3.1, 4.0.4.1, 6.0.1.1, 6.0.4 or later. Affected versions erb gem 6.0.3 or lower Credits Thanks to TristanInSec for discovering this issue. History Originally published at 2026-04-21 07:51:00 (UTC) Posted by k0kubun on 21 Apr 2026 ## Rails Payments in 2026: Beyond Stripe DevFeed: [Rails Payments in 2026: Beyond Stripe]() Original publisher: [Read original article]() Author: Ayush Agarwal Published: 2026-03-29T00:00:00Z Content type: opinion Language: en Sources: [Dodo Payments Blog]() Topics: [Rails](), [stripe](), [Ruby](), [Security]() Tags: [2026](), [billing](), [compliance](), [developer-tools](), [global](), [how-to](), [merchant-of-record](), [payments](), [rails](), [ruby](), [ruby-on-rails](), [stripe](), [subscriptions](), [tax]() ### AI overview This article explains how payment integration for Ruby on Rails applications has become more complex because of global tax compliance, regional billing rules, payment methods, and revenue recovery. It presents the Merchant of Record model, including Dodo Payments, as an alternative to traditional gateway arrangements such as Stripe. ### Source excerpt Modern payment integration for Ruby on Rails apps. Move beyond Stripe to a Merchant of Record for simpler billing, automatic tax compliance, and global payment support. ## Testing Readonly Models DevFeed: [Testing Readonly Models]() Original publisher: [Read original article]() Author: Tony Yunker Published: 2026-03-17T13:00:00Z Content type: tutorial Language: en Sources: [Hashrocket]() Topics: [Rails](), [Testing](), [Ruby](), [Databases](), [Code]() Tags: [activerecord](), [code](), [database](), [rails](), [ruby](), [ruby-on-rails](), [testing]() ### AI overview A Rails tutorial explains how to test readonly models that normally reject database writes. It proposes a narrowly scoped test-only override that temporarily permits persistence during setup and restores readonly behavior before the test runs. ### Source excerpt I was working with a readonly model in Rails the other day and ran into an issue whilst testing it. Here's what I ran into and the solution I came up with. Readonly models are a great way to signal that, well, you should only ever read them, not write them. Maybe you have some external system that connects to the database for writes, or maybe your Rails app connects to some data warehouse for some queries or reports. It's can be useful to have a safeguard to prevent accidental errant writes. It's actually really simple to make a model readonly, you just need to override the readonly? method: class ReadOnlyPost < ApplicationRecord def readonly? = true end Now any attempt to create/save/update/delete a ReadOnlyPost will raise a friendly ActiveRecord::ReadOnlyRecord exception. The Problem You might be able to see where this is going. For any tests that can avoid saving this readonly model to the database, (i.e. using ReadOnlyPost.new or FactoryBot.build), then we're all good. But often tests need to persist some records to the test database. And if I try to create a ReadOnlyPost, I'm going to have a bad time. RSpec.describe ReadOnlyPost, type: :model do let(:post) { ReadOnlyPost.create(title: "Title", body: "body") } it "can create a post" do expect(post).to be_a(ReadOnlyPost) end end % bundle exec rspec F Failures: 1) ReadOnlyPost can create a post Failure/Error: let(:post) { ReadOnlyPost.create(title: "Title", body: "body") } ActiveRecord::ReadOnlyRecord: ReadOnlyPost is marked as readonly # ./spec/models/read_only_post_spec.rb:4:in `block (2 levels) in ' # ./spec/models/read_only_post_spec.rb:7:in `block (2 levels) in ' This makes sense, the readonly property of the model doesn't go away in test - creating a record is creating a record is writing to the database, so it will fail. The Solution What we want to do is override this constraint to temporarily allow us to persist data. Ideally, we do this very narrowly to not impact the syst ## Introducing Upright: An Open Source Synthetic Monitoring System DevFeed: [Introducing Upright: An Open Source Synthetic Monitoring System]() Original publisher: [Read original article]() Author: Lewis Buckley Published: 2026-02-16T18:00:00Z Content type: release Language: en Sources: [37signals Dev]() Topics: [synthetic monitoring](), [Monitoring](), [Open Source](), [Playwright](), [Rails](), [Prometheus](), [Grafana](), [Deployment](), [SQLite]() Tags: [deployment](), [grafana](), [monitoring](), [open-source](), [playwright](), [prometheus](), [rails](), [sqlite](), [synthetic-monitoring]() ### AI overview 37signals is open-sourcing Upright, a synthetic monitoring system built to monitor Basecamp, HEY, Fizzy, and other services. Upright runs health checks from multiple geographic locations and reports results through Prometheus metrics for alerting and Grafana visualization. ### Source excerpt We're open-sourcing Upright, the synthetic monitoring system we built to watch over Basecamp, HEY, Fizzy and our many other services. ## Rails Multi-Tenancy DevFeed: [Rails Multi-Tenancy]() Original publisher: [Read original article]() Author: Mike Dalessio, Kimberly Rhodes, Fernando Olivares Published: 2026-02-13T18:00:00Z Content type: article Language: en Sources: [37signals Dev]() Topics: [Multi-tenancy](), [Rails](), [SQLite](), [Databases](), [MySQL](), [Open Source](), [Replication]() Tags: [active-record](), [databases](), [demo](), [developer](), [multi-tenancy](), [mysql](), [open-source](), [rails](), [replication](), [sqlite]() ### AI overview Lead Programmer Mike Dalessio discusses multi-tenancy in Rails, including 37signals' work moving Fizzy toward separate customer databases, the Active Record Tenanted gem, safeguards against accidental data leaks, and challenges involving SQLite replication and failover. ### Source excerpt Lead Programmer Mike Dalessio shares the benefits of multi-tenant databases and how his work with Fizzy led to the the Active Record Tenanted gem. ## Naming Things Is Hard DevFeed: [Naming Things Is Hard]() Original publisher: [Read original article]() Author: Simon Fish Published: 2026-02-02T09:37:06Z Content type: article Language: en Sources: [FreeAgent]() Topics: [Code](), [Rails](), [Architecture & Design](), [Requirements]() Tags: [architecture](), [code](), [debugging](), [development](), [general](), [rails](), [requirements](), [ruby](), [ruby-on-rails](), [software](), [software-engineer](), [software-engineering]() ### AI overview The article examines why naming objects and methods in code is difficult, especially when domain models such as Rails Active Record models have broad responsibilities. It argues that precise names should reflect purpose and that clarifying requirements can reveal when complex concepts should be broken into smaller parts. ### Source excerpt Choosing good names for objects and methods in code is one of the toughest things to do as a software engineer. It comes with the great and invisible reward of simplicity - second only to having less code in the first place, having code that's easy to reason with makes extending it and debugging it in [...] ## Two Engineers, One Mentoring Story: Why Both Sides Win DevFeed: [Two Engineers, One Mentoring Story: Why Both Sides Win]() Original publisher: [Read original article]() Author: Mila Kirova Published: 2026-01-27T14:05:40Z Content type: opinion Language: en Sources: [FreeAgent]() Topics: [Learning](), [Rails](), [Ruby]() Tags: [blog](), [career-progression](), [careers](), [culture](), [development](), [experience](), [insights](), [mentoring](), [rails](), [ruby]() ### AI overview FreeAgent engineers Carme and Mila discuss their three-year mentoring relationship, including how Carme strengthened her Ruby and Rails knowledge through guided study, practical exercises, and increasingly self-directed learning. ### Source excerpt We are Carme and Mila, both software engineers at FreeAgent, where we collaborate as mentee and mentor. In this blog we interview each other about our mentoring relationship. We're hoping that our experience is universal and sharing our insights will be useful to anyone who is interested in mentoring. If you like what you read, [...] ## Some notes on starting to use Django DevFeed: [Some notes on starting to use Django]() Original publisher: [Read original article]() Author: Julia Evans Published: 2026-01-27T00:00:00Z Content type: article Language: en Sources: [Julia Evans]() Topics: [Django](), [Framework](), [Object-relational mapping](), [Website](), [Database](), [Rails](), [Laravel]() Tags: [database](), [django](), [framework](), [laravel](), [orm](), [rails](), [web]() ### AI overview A developer shares notes from starting to use Django after previously trying Rails. They find Django's explicit project structure easier to return to after long breaks, appreciate its built-in and customizable admin interface, and are enjoying its ORM for expressing database relationships and queries with less code. ### Source excerpt Hello! One of my favourite things is starting to learn an Old Boring Technology that I've never tried before but that has been around for 20+ years. It feels really good when every problem I'm ever going to have has been solved already 1000 times and I can just get stuff done easily. I've thought it would be cool to learn a popular web framework like Rails or Django or Laravel for a long time, but I'd never really managed to make it happen. But I started learning Django to make a website a few months back, I've been liking it so far, and here are a few quick notes! less magic than Rails I spent some time trying to learn Rails in 2020, and while it was cool and I really wanted to like Rails (the Ruby community is great!), I found that if I left my Rails project alone for months, when I came back to it it was hard for me to remember how to get anything done because (for example) if it says resources :topics in your routes.rb, on its own that doesn't tell you where the topics routes are configured, you need to remember or look up the convention. Being able to abandon a project for months or years and then come back to it is really important to me (that's how all my projects work!), and Django feels easier to me because things are more explicit. In my small Django project it feels like I just have 5 main files (other than the settings files): urls.py, models.py, views.py, admin.py, and tests.py, and if I want to know where something else is (like an HTML template) is then it's usually explicitly referenced from one of those files. a built-in admin For this project I wanted to have an admin interface to manually edit or view some of the data in the database. Django has a really nice built-in admin interface, and I can customize it with just a little bit of code. For example, here's part of one of my admin classes, which sets up which fields to display in the "list" view, which field to search on, and how to order them by default. @admin.register(Zine) class ZineAdmin(adm ## Why 37signals' Code Looks Different: Small Teams, Narrow Scope, and Selective Hiring DevFeed: [Why 37signals' Code Looks Different: Small Teams, Narrow Scope, and Selective Hiring]() Original publisher: [Read original article]() Published: 2026-01-27T00:00:00Z Content type: opinion Language: en Sources: [Nate Berkopec]() Topics: [Rails](), [Code](), [Software as a service]() Tags: [code](), [open-source](), [rails](), [saas](), [team-building]() ### AI overview The article argues that 37signals' clean-looking Rails code reflects a distinct engineering strategy rather than inherently superior developers. That strategy emphasizes small teams, aggressively limited product scope, and hiring highly capable engineers. ### Source excerpt A recent episode of the Rails Business Podcast was about "striving for ideal code". The hosts are both typical "Rails Indie" owner/operators: a small team building a small SaaS. They were discussing a new podcast which is out from 37signals called "Recordables". The discussion was envy for how good and clean 37signals' code was. This is a fair assessment. They've been open-sourcing a lot of real world products lately, including: Campfire, the chat app. Fizzy, the Kanban tool. If you read them, the code looks great. We've only seen glimpses of this Rails style, which David has alluded to or shown small parts of in interviews or conference talks. Until now, we couldn't see what the Rails "house style" is because we never had a real open source application written in that style. Now we do. The discussion on the podcast was mostly a sense of envy of how good the good was, and wondering: "Why doesn't our code look that good?" Covet not thy neighbor's codebase. The reason why your code doesn't look "as good" as 37signals' is because your engineering strategy is not the same as theirs. 37signals, for all of its faults, has a unique engineering strategy, which I would summarize as: Stay small in terms of headcount to revenue ratio. Ruthlessly cut scope. 37signals' products usually do far, far less than their competition. Hire the top 10% of engineers. Most of the businesses I've ever worked for cannot say that any of these three points are honestly part of their strategy. Every time 37signals puts out a codebase or talks about their size in public, I am always shocked at how few LOC they are. Basecamp Next/2 was originally 10,000 LOC. Basecamp 3 was 18,000 LOC when released. Fizzy is 7,500 non-test LOC. Campfire is just 2,500 non-test LOC. That is fucking insane. 37signals employs 25-30 technical employees, meaning that for each individual codebase, they're maintaining under 2,500 lines per person. Most companies manage 10x that per headcount. Most indies ship 100,000+ line [Next page]()