# Ruby on Rails Published articles for Ruby on 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. ## Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures DevFeed: [Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures]() Original publisher: [Read original article]() Author: PULKIT GARG Published: 2026-08-11T05:58:23Z Content type: article Language: en Sources: [Housing.com]() Topics: [ephemeral ports](), [incident](), [Kernel]() Tags: [incident](), [port](), [production-issue](), [rate-limiting](), [ruby-on-rails](), [tcp]() ### AI overview An engineering incident report explains how a neighboring bulk job exhausted the shared operating system's ephemeral TCP port pool, causing scheduled background jobs to fail until the temporary traffic pressure subsided. ### Source excerpt A neighbor's bulk job drained every ephemeral port on a shared box. Twice. Here's the one kernel setting that would have stopped it -- and the architecture that makes it a non-issue. At 1:38 AM, one of our background-job services started failing. Scheduled jobs -- the nudges and reminders we send users overnight -- began throwing an error most engineers rarely see: Errno::EADDRNOTAVAIL -- Cannot assign requested address Not "connection refused." Not "timeout." Cannot assign requested address. The machine wasn't saying the other end was down. It was saying it had run out of addresses to call from. Here's the strange part: we hadn't deployed anything. Our code was untouched for days. And by ~3 AM it healed itself, with nobody doing a thing. Two nights later, same window, it happened again. The bug wasn't in our service. It was in a service we don't own -- and don't even talk to. Act 1: A crime scene with no suspect ~7,800 job executions failed across the two nights. The first night slipped in under the alerting threshold entirely -- we only found it in the errors inbox after the fact. Everything about it was confusing: Our service hadn't changed. The internal APIs we call were all healthy. It happened in a tight window (~1:30-3:00 AM), then vanished. No human fixed it. It just... stopped. An outage that fixes itself is telling you something important: the thing that broke wasn't yours, and the pressure that caused it was temporary. Act 2: The noisy neighbor That service doesn't run on its own machine. It shares one box with about ten other apps -- a normal, cost-efficient setup. What's easy to forget is what they silently share: not just CPU and memory, but the operating system's ephemeral port pool. Quick refresher. Every time a program opens an outbound TCP connection, the OS assigns it a temporary "ephemeral" source port. That pool is finite -- by default, roughly 28,000 ports. And on a shared box, every app draws from the same pool. Ephemeral ports are an unmonitored, multi ## 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 [...] ## 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. ## Best CI/CD Tools in 2026: Performance and Cost Compared DevFeed: [Best CI/CD Tools in 2026: Performance and Cost Compared]() Original publisher: [Read original article]() Author: Pete Miloravac Published: 2026-07-02T14:00:53Z Content type: article Language: en Sources: [Semaphore Engineering]() Topics: [CI/CD](), [benchmarking](), [Ruby on Rails](), [PostgreSQL](), [Linux](), [GitHub Actions]() Tags: [2026](), [benchmark](), [ci-cd](), [cost](), [linux](), [performance](), [pipelines](), [postgresql](), [ruby-on-rails]() ### AI overview The article benchmarks five CI/CD platforms using the Redmine Ruby on Rails application, standardized 2 vCPU environments, and ten post-cache-warm-up runs per provider. It reports that Semaphore ranked first for both speed and cost, with an average build time of 5m 01s and a cost of $0.04 per run. ### Source excerpt Choosing a CI/CD tool in 2026 isn't just a technical decision -- it's a cost and productivity decision. Slow pipelines mean slower shipping, and opaque pricing means budget surprises at the end of the month. We benchmarked five of the most widely used CI/CD platforms against the same workload: a real Ruby on Rails application [...] The post Best CI/CD Tools in 2026: Performance and Cost Compared appeared first on Semaphore. ## 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 ## 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 [...] ## Persisting nested form attribute indexes through Turbo updates DevFeed: [Persisting nested form attribute indexes through Turbo updates]() Original publisher: [Read original article]() Author: georgebaker Published: 2026-01-08T12:57:43Z Content type: article Language: en Sources: [FreeAgent]() Topics: [Ruby on Rails](), [Forms](), [JavaScript](), [web applications]() Tags: [forms](), [html](), [javascript](), [rails](), [ruby](), [ruby-on-rails](), [server-side-rendering](), [software-engineering](), [turbo](), [uncategorized]() ### AI overview This article examines a problem with maintaining nested form attribute indexes when Turbo Streams update part of a Ruby on Rails form. It explains how indexes are generated during server rendering and in browser-side JavaScript, and why introducing server-side Turbo Stream rendering creates additional complexity. ### Source excerpt Introduction We recently encountered an interesting problem when using Turbo Streams to update part of a complex nested form in FreeAgent's main Ruby on Rails web application. For those unfamiliar, nested forms allow a user to enter data relating to both a main parent object and its associated objects. This could be, for example, a [...] ## Creating a Custom Mobile Integration for a Board Game Using Ruby on Rails DevFeed: [Creating a Custom Mobile Integration for a Board Game Using Ruby on Rails]() Original publisher: [Read original article]() Author: Craig Hafer Published: 2025-12-04T14:00:00Z Content type: tutorial Language: en Sources: [Hashrocket]() Topics: [board-game](), [Ruby on Rails](), [Mobile](), [Tailwind CSS](), [Database](), [Stimulus]() Tags: [board-game-app](), [mobile](), [postgresql](), [rails](), [ruby](), [ruby-on-rails](), [stimulus](), [tailwind]() ### AI overview A tutorial on building a mobile version of the Analyzer mechanism from the 1973 Parker Brothers board game Billionare. The project uses Ruby on Rails, Tailwind, PostgreSQL, and Stimulus, with the goal of supporting a broader library of board game helpers. ### Source excerpt Picture this: you find a charming old board game at a garage sale, bring it home, gather some friends--and snap. The 50-year-old plastic components break instantly. You search the web for help to replace this fun and unique game mechanic but there's nothing to be found. So naturally, you roll up your sleeves and build your own mobile version. No one else does this? Just me? Well, in case you ever find yourself in a similar boat, I figured I would walk you through what I did when building my own mobile integration to the 1973 Parker Brothers classic Billionare. As I said, right when I went to try out this cool "new" board game for the first time, the plastic ends of the Analyzer snapped. The analyzer is basically a plastic rod with 2 floating spinners on them. The spinners, when rotated, will either land with a red face or a green face. You then refer to the chart to see what action to take. I thought this was such a unique way to give a random effect in a game, without relying on dice. It essentially is just a random binary spinner that counts up to 4. Here is what it looks like for reference: So, without any 4 sided die lying around, and not wanting to use a boring random number generator, my brain went right to what it knows best---Ruby on Rails. So without further ado, here's what I did and how you can do something similar yourself. Creating the app Sure, Rails could be considered overkill for such a simple app. But my idea is to allow this project to scale into a whole library of board game helpers that can all live within the same app. So, to start off I ran the old trusty rails new command, with a couple preferences I like to pass in to make my life easier as a developer. rails new board_game_library --css tailwind --database=postgresql One of the main tools I leveraged for this project besides Rails was Tailwind. Tailwind makes styling so easy. Here at Hashrocket Tailwind is pretty standard for all of us, so if you're interested in any tips or tricks, we have ## Speed Up Your Rails App by Squashing N+1 Queries DevFeed: [Speed Up Your Rails App by Squashing N+1 Queries]() Original publisher: [Read original article]() Author: Tony Yunker Published: 2025-11-20T14:00:00Z Content type: tutorial Language: en Sources: [Hashrocket]() Topics: [Rails](), [Databases](), [Code]() Tags: [activerecord](), [code](), [database](), [performance](), [rails](), [ruby-on-rails]() ### AI overview This tutorial explains how N+1 queries arise in Rails applications when associated ActiveRecord records are accessed during iteration. It uses nested authors, posts, and tags as a case study, showing how eager loading can reduce a workload from 1,101 database queries to 3. ### Source excerpt N+1 queries are one of the most common performance killers in Rails apps, but also one of the easiest to fix. In this post, we'll see how a single line of code can reduce 1,101 database queries down to 3. N+1s occur in rails when you have associated ActiveRecord models, and iterate over one model while accessing fields on the associated records. This might be easier to explain with an example. Let's say you have the following ActiveRecord models: class Author < ApplicationRecord has_many :posts end class Post < ApplicationRecord belongs_to :author has_many :tags end class Tag < ApplicationRecord belongs_to :post end An author has many posts, and each post can have many tags. If we want to list each author and their blog posts like below, then we'll make 1 query to the database for the authors, and then another query for each author's blog posts. For N authors, that's 1 + N queries to the database. Author.take(3).each do |author| puts author.name author.posts.each do |post| puts post.title end end We can see all the queries in the logs - 1 query for authors, then 3 queries for each author's blog posts: Author Load (31.4ms) SELECT "authors".* FROM "authors" Post Load (2.4ms) SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 163 Post Load (0.4ms) SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 164 Post Load (0.1ms) SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 165 In small doses this isn't a big deal - these are small, quick queries. However, as soon as the data gets larger, the queries more complex, or the cardinality of these queries grow, then things can really slow down. Let's look at a case study, where we start with an unoptimized query with 2 layers of N+1s, and see how much faster we can make it. Case 1 - The Unoptimized Query Let's take the example above, and add another layer to it. On our authors index page, we want to list each author, then each of their blog posts, including their associated tags. With a totally unoptimized qu ## A refreshing take: using serverside rendering to reduce fragile DOM state DevFeed: [A refreshing take: using serverside rendering to reduce fragile DOM state]() Original publisher: [Read original article]() Author: Simon Fish Published: 2025-10-17T08:33:59Z Content type: article Language: en Sources: [FreeAgent]() Topics: [Hotwire](), [Front end](), [Rails](), [Stimulus](), [WebSocket](), [Document Object Model (DOM)](), [tbox]() Tags: [browser](), [development](), [frontend](), [hotwire](), [html-elements](), [js](), [rails](), [ruby-on-rails](), [stimulus](), [streams](), [websocket]() ### AI overview This article examines FreeAgent's use of server-side rendering with Hotwire, Turbo, Stimulus, and Rails to reduce fragile DOM state. It explains how Turbo Streams and Action Cable can update browser pages asynchronously, contrasting these behaviors with the original DOM-manipulation actions. ### Source excerpt Hotwire is central to how we drive the frontend at FreeAgent, and Action Cable allows us to send Turbo Streams as users browse the site, adding a layer of richness to the user experience. ## A decade in the tech industry DevFeed: [A decade in the tech industry]() Original publisher: [Read original article]() Published: 2025-05-30T00:00:00Z Content type: opinion Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Development](), [Ruby](), [Ruby on Rails](), [Angular]() Tags: [angular](), [career](), [development](), [experience](), [ruby](), [ruby-on-rails](), [tech]() ### AI overview A personal reflection on completing a decade in the technology industry, covering the author's first job after college, early software employment in India, startup work, changing career opportunities, and the technologies that were prominent at the start of the author's career. ### Source excerpt I just realised that I completed a decade in the tech industry this month. 17th May 2015, was my joining date in my first ever big boy job... ## Announcing Hotwire Native 1.2 DevFeed: [Announcing Hotwire Native 1.2]() Original publisher: [Read original article]() Author: Jay Ohms Published: 2025-04-23T17:00:00Z Content type: release Language: en Sources: [37signals Dev]() Topics: [Hotwire](), [Android](), [iOS](), [Ruby on Rails]() Tags: [android](), [api](), [bug-fixes](), [documentation](), [hotwire](), [ios](), [rails](), [ruby-on-rails](), [update]() ### AI overview Hotwire Native 1.2 is a major update for iOS and Android that adds route decision handlers, built-in handling for server-driven historical location URLs, official bottom-tab navigation support, and new demo apps. ### Source excerpt A big update to Hotwire Native for iOS and Android. ## Make streaming APIs easy with enumerable methods DevFeed: [Make streaming APIs easy with enumerable methods]() Original publisher: [Read original article]() Published: 2024-12-20T00:00:00Z Content type: tutorial Language: en Sources: [Aha! Engineering Blog]() Topics: [Ruby on Rails](), [Ruby](), [Streaming](), [Large Language Model](), [OpenAI](), [Code]() Tags: [code](), [large-language-model](), [openai](), [rails](), [ruby](), [ruby-on-rails](), [streaming]() ### AI overview This tutorial explains how Ruby enumerable methods can make streaming API responses easier to transform and compose. It uses large language model APIs, including the OpenAI chat API, as an example and describes converting block-yielded values into an enumerator. ### Source excerpt When you first discover Ruby on Rails, some things might strike you right away: namely the large number of enumerable methods and the blocks to run code in the middle of another method. Those features helped me translate my thoughts directly into c ## Turso Adds Ruby on Rails Support DevFeed: [Turso Adds Ruby on Rails Support]() Original publisher: [Read original article]() Author: Levy Albuquerque Published: 2024-12-18T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Turso](), [Rails](), [Ruby](), [Embedded Replicas](), [CRUD](), [migration]() Tags: [activerecord](), [embedded-replicas](), [latency](), [ruby](), [ruby-on-rails](), [sql](), [testing](), [turso]() ### AI overview Turso announces a technical-preview Ruby gem for ActiveRecord with Rails support. The article explains how to configure Turso in Rails, use embedded replicas to work offline and reduce network latency, run migrations, and perform CRUD operations. It also demonstrates usage with standalone Ruby applications and Sinatra. ### Source excerpt Today we are excited to announce the first technical preview of the Rubygem for ActiveRecord that supports Rails. ## Choosing a technology stack for a full-stack to-do list side project DevFeed: [Choosing a technology stack for a full-stack to-do list side project]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2024-11-06T00:00:00Z Content type: article Language: en Sources: [Jeroen Mols]() Topics: [Learning](), [Go Language](), [Back end](), [Ruby](), [Ruby on Rails](), [JavaScript]() Tags: [backend](), [blogs](), [full-stack](), [go](), [golang](), [javascript](), [learning](), [playwright](), [ruby-on-rails](), [side-project](), [svelte](), [tech-stack](), [typescript]() ### AI overview The article examines technology choices for a full-stack to-do list side project. It compares NodeJS, Ruby on Rails, and Go for the backend, and explains why the author chose Go after considering asynchronous JavaScript, Rails' batteries-included approach, and Go's static typing, concurrency, compilation speed, and performance. ### Source excerpt One of my main drivers for this side project was to make all technology choices myself. To do that effectively, I would have to consider the pros and cons of different options and frankly learn many new things. ## Tropical.rb Conference and Rails Girls São Paulo DevFeed: [Tropical.rb Conference and Rails Girls São Paulo]() Original publisher: [Read original article]() Author: Doximity Published: 2024-05-22T16:12:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Ruby on Rails](), [Ruby](), [Development](), [Programming](), [software-development](), [Software Engineering]() Tags: [brazil](), [community](), [conference](), [developers](), [development](), [engineering](), [event](), [global](), [junior](), [learning](), [programming](), [projects](), [ruby](), [ruby-on-rails](), [skills](), [software-development]() ### AI overview Doximity sponsored the Tropical.rb Rails conference in São Paulo and the following Rails Girls São Paulo event. The events covered Ruby on Rails, its community and upcoming Rails 8 features, while Rails Girls participants collaborated on a mentoring app and received guidance toward advancing their software development skills. ### Source excerpt On April 4th and 5th, 2024, Doximity sponsored Tropical.rb, also known as "The Latin America Rails Conference," in São Paulo, Brazil. This event gathered developers from across Latin America and beyond. It served as a dynamic platform for discussing Ruby on Rails, sharing knowledge, and networking among professionals in the field. The Doximity team at Tropical.rb Doximity has utilized Ruby on Rails since its founding, attributing significant success to the framework. The timing of the recent conference coincided with a resurgence in Rails' popularity, marked by new features and increased adoption among start-ups and new companies.The framework's robust foundation is evidenced by its daily use in major companies such as Doximity, Shopify, AppSignal, and 37Signals. The Tropical.rb conference featured keynotes from prominent Rails core team members Aaron Patterson and Eileen Uchitelle, who provided deep dives into the internals of Rails, explaining some of its magic. Rafael França shared insights on his experiences and the pivotal role of the Ruby on Rails community. The event highlighted numerous success stories of projects and companies built using Rails. Further excitement was generated by discussions on upcoming features in Rails 8, such as Propshaft, Kamal, and Thruster, detailed in Breno Gazzola's keynote. A central theme of the conference was Rails' suitability as a "one-person framework", with Rails 8 advancements reinforcing this concept. Rails Girls São Paulo The day after Tropical.rb, Doximity, in partnership with The Rails Foundation, sponsored the latest edition of Rails Girls São Paulo, a global non-profit initiative dedicated to introducing women of all ages to the world of software development. This edition of Rails Girls focused on empowering women with a programming background to improve their skills and guide them in their journey from junior to mid-level positions and beyond. Our SVP of Engineering, Bruno Miranda, attended the event, along with a fe ## Modularizing Rails Monoliths One Bite at a Time DevFeed: [Modularizing Rails Monoliths One Bite at a Time]() Original publisher: [Read original article]() Author: Doximity Published: 2023-12-05T13:00:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Ruby on Rails](), [Refactoring](), [modules](), [Architecture & Design](), [Microservices]() Tags: [microservices](), [modular-monolith](), [modularization](), [modules](), [rails](), [refactoring](), [ruby](), [ruby-on-rails]() ### AI overview The article describes using a phased refactoring approach and the packwerk gem to modularize growing Rails monoliths into modules with enforced boundaries. It presents the modular monolith as a lower-complexity alternative to adopting microservices and references Doximity's experience. ### Source excerpt As Rails monoliths grow, coupling becomes increasingly difficult to manage. Developers often reach for microservices to help simplify things, but instead find higher complexity. The Modular Monolith approach is a proven, lightweight alternative that offers the benefits of enforced boundaries without being cumbersome. I spoke at the 2023 Rocky Mountain Ruby conference on how teams can use a phased approach to refactoring toward this style using the packwerk gem. At Doximity, we've used this gem and a phased approach to break some of our most critical rails applications into modules that are easier for our teams to work with. In November, 2023, I also chatted with Elise Shaffer on The Ruby on Rails Podcast about our experience with application modularization at Doximity. Be sure to follow @doximity_tech if you'd like to be notified about new blog posts. ## A Pre-Deployment Checklist for Risky Data Migrations DevFeed: [A Pre-Deployment Checklist for Risky Data Migrations]() Original publisher: [Read original article]() Published: 2023-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Artsy]() Topics: [Command-line interface](), [Docker](), [Kubernetes](), [Sidekiq](), [Latency]() Tags: [command-line](), [data-migrations](), [deploy-process](), [docker](), [error-reporting](), [kubernetes](), [latency](), [logs](), [migrations](), [retry](), [ruby-on-rails](), [sidekiq]() ### AI overview This article presents a pre-deployment checklist for risky data migrations and other changes that could affect production services. It recommends planning rollback steps and monitoring error rates, reported errors, latency, logs, functionality, and failing Sidekiq retries after deployment. ### Source excerpt Lately, I've been getting involved with some sketchy stuff. You know what I'm talking about-data migrations. I've been rolling out changes that have a significant risk of breaking our production environment for mission-critical services. It's been exciting work (keep your eyes out for more posts on the exact project, coming soon™), but I've definitely caused a couple incidents along the way. After accidentally taking down a key service for a couple hours, I decided I needed to have a better pre-deploy process for these changes. I did some thinking and came up with a short checklist to run through before I press the shiny green button. Here's the checklist I came up with: What is your plan if something goes wrong? Run through ramifications of rolling back. If there's a reason you're worried about rolling back, then you're not ready to deploy the change yet! Figure out exactly what command(s) you will need to run to roll back. At Artsy, this is usually a one-liner using Hokusai, our command-line Docker/Kubernetes CLI How will you tell if something is going wrong after you deploy? Error rate (DataDog) Specific error reporting (Sentry) Latency (DataDog) Logs (Papertrail) Functionality (does it still work? Are people using it successfully? Important for things where errors may not be bubbled up correctly or reported immediately) Sidekiq (are there lots of jobs queued to retry that are failing?) With this checklist in hand, I'm deploying more confidently and causing fewer incidents along the way. Do you have something similar? Are there things you think this checklist should include? Let me know in the comments! ## The Rails Foundation DevFeed: [The Rails Foundation]() Original publisher: [Read original article]() Author: Doximity Published: 2022-11-14T08:10:00Z Content type: release Language: en Sources: [Doximity]() Topics: [Ruby on Rails](), [Ruby](), [Framework]() Tags: [announce](), [ecosystem](), [rails](), [resources](), [ruby](), [ruby-on-rails]() ### AI overview Doximity describes how it has used Ruby on Rails to build products and services for U.S. medical professionals. It announces that Doximity is joining the Rails Foundation as one of eight founding core members and plans to contribute resources to support the Ruby on Rails ecosystem. ### Source excerpt Physicians First has been our mantra from day one. Over the last twelve years, we've leveraged Ruby on Rails to build the largest network of U.S. medical professionals. Our mission is to help physicians be more productive so they can provide better care for their patients. Ruby on Rails has enabled us to build products that provide doctors with modern telehealth, communication, workflow, and continuing medical education. We love building innovative technology that has a real, meaningful impact on physicians' and patients' lives. We will continue investing and building products to help make medical professionals more effective. To us, the Ruby on Rails framework and its ecosystem is still the best tool for the job. We're happy to announce that we're joining the Rails Foundation as one of eight founding core members. We look forward to contributing to this non-profit organization and providing important resources to help ensure the Ruby on Rails ecosystem remains healthy and continues to thrive for decades to come. -- Bruno Miranda vp, eng ## Strava's Transition from a Ruby on Rails Monolith to Scala Microservices DevFeed: [Strava's Transition from a Ruby on Rails Monolith to Scala Microservices]() Original publisher: [Read original article]() Author: Avery Dunn Published: 2022-11-01T16:02:01Z Content type: opinion Language: en Sources: [Strava Engineering]() Topics: [Microservices](), [Scala](), [Ruby on Rails](), [Developer experience](), [GraphQL]() Tags: [api](), [graphql](), [internships](), [microservices](), [ruby-on-rails](), [scala](), [software-development]() ### AI overview A Strava software engineering intern reflects on the company's transition from a Ruby on Rails monolith to Scala microservices. The article describes the intended benefits for team independence and developer experience, and notes that the API is evolving from REST to GraphQL. ### Source excerpt My name is Avery Dunn and I am a rising master's student at Washington University in St. Louis studying computer science. For the past 12 weeks, I have been a software engineering intern on the API & Platform pod of the Foundation team. I am an active Strava user and have been for approximately 3 years with my favorite activity being running. Some other activities I enjoy are playing the piano, reading novels, or skiing (more of a luxury rather than a hobby). My internship at Strava has been a wonderful experience to help me learn, grow, and develop into becoming a more well-rounded, conscientious software engineer. Whether it was working with a recent hire or seasoned "Stravioli," the positive and ambitious company culture shined brightly throughout the course of the summer. In Transition From a Monolithic to Microservice Architecture Strava currently maintains a code monolith-a huge Ruby on Rails codebase that controls the user interface, business logic, and database access. For a growing company like Strava and the continuous development of ideas being made into new features, a code monolith doesn't make for a great developer experience. Trying to parse through a massive codebase and making sure that all the moving parts are in order so that a typo that was somehow glossed over can successfully be changed makes me a little dizzy, personally. The developers at Strava thought so too, and decided to embark on a transition from the Ruby on Rails singular software application to Scala microservices. Over the course of my internship, I gained insight into the process of restructuring a singular software application into Scala microservices and the benefits of that result. Scala microservices can be thought of as modules that work together but separately. They encourage diversification of teams such that each team has less of a dependence on one another like they would for a monolithic codebase. Figure 1: Comparison of a monolithic codebase architecture versus distribut ## Mexico City Rails Meet-up Reboot DevFeed: [Mexico City Rails Meet-up Reboot]() Original publisher: [Read original article]() Author: Doximity Published: 2022-11-01T10:39:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Ruby on Rails](), [Kafka](), [Microservice](), [Architecture & Design](), [Publish-subscribe pattern](), [Bootcamp]() Tags: [architecture](), [developers](), [development](), [kafka](), [microservices](), [rails](), [ruby-on-rails](), [services]() ### AI overview This article describes the restart of the Mexico on Rails meetup in Mexico City after pandemic-related disruption. It covers the event, its attendees, a presentation on syncing data across Rails microservices, Kafka as publish-subscribe middleware, and discussion about software education and in-person community. ### Source excerpt In recent years Mexico City has developed a thriving tech scene, with new startups putting roots, vying for talent, and contributing to a slew of events and conferences in the city. Mexico on Rails meetup has been an integral part of the ecosystem, meeting regularly to connect and discuss Ruby on Rails and web development. But the pandemic put most of this activity on hold. While discussing this recently with my Doximity colleague Samus Gray, who also lives in Mexico City, he suggested we try and restart the meetup activity. I nodded along, as something that would be nice to do. A few days later, Samus had already convinced the previous meetup organizer to transfer the group to us, found a venue, and got Doximity to sponsor it. That's when I realized he meant it. Last week we met in Le Wagon, a Rails Bootcamp in the fashionable Roma Norte neighborhood. Despite a rainy day, about 20 people showed up. This was a diverse crowd of seasoned developers working for local startups such as Telos Labs and Jetty, Bootcamp students, and digital nomads working remotely. After breaking the ice over Detroit-style pizza and beers, we moved to a classroom, where I gave a presentation on data syncing between Rails microservices. Presented originally by our colleague Austin Story in RailsConf 2021, it tracked Doximity's thorny path from a monolith app with a limited number of data sources to an architecture in which multiple rails applications and services can consume and sync over billions of data updates from a myriad of sources. During the Q&A session, Samus shared his experience working with Kafka, Doximity's tool of choice for our publish-subscribe middleware. Finally, Le Wagon co-founder Mathiew Le Roux took the floor to share his vision for the future of software education. Eager to connect, most of us stayed long after the formal part was over, chatting and sharing our experiences. The enthusiasm shared by everyone for the meetup reboot was a reminder of the importance of meet [Next page]()