标签：#ruby

In release 4.0, the Ruby Powers-That-Be have brought class Pathname into the Ruby core. This is a Very Good Thing. Through its many instance methods, a Pathname object provides a consistent and convenient interface to numerous methods in other classes and modules: Wraps almost all methods in class File and module FileTest . Wraps some methods in class Dir and module FileUtils . Advantages of using Pathname instead of these others: You don’t have to know which class or module has which methods. You don’t have to keep typing the class name and path variable. However, for many of the Pathname methods, the existing documentation merely links to another method in another class, with scant or no local examples. That documentation may be seen in Ruby 4.0 . I've completed a re-write of the documentation (with the usual excellent reviewing by Peter Zhu). It may be seen for now in Ruby master , and which will be release with Ruby 4.1 later this year. The re-write gives a Pathname -local description and example for each method. (No more linking to a similar or underlying method elsewhere.) I've also revised the documentation for the class itself, and added a "What's Here" section. Happy Pathnames!

Fixing "g++ Not Found" When Debugging Rails in RubyMine on Fedora TL;DR: If clicking "Debug" in RubyMine on Fedora fails to install debase because of a missing g++ compiler, the standard @development-tools group might not be enough. Run sudo dnf install gcc-c++ make redhat-rpm-config to get the explicit C++ compiler and tools Ruby needs to build native extensions. I was recently working on a Rails app on my Fedora machine and wanted to step through some code. I fired up RubyMine, set my breakpoints, and clicked the "Debug" button, fully expecting everything to just work. Instead, RubyMine tried to automatically install the debase and ruby-debug-ide gems—which it needs under the hood to hook into the Ruby process—and threw a massive wall of error text at me. The core of the failure looked like this: Building native extensions. This could take a while ... ERROR: Error installing debase-3.0.17.gem: ERROR: Failed to build gem native extension. ... /path/to/extconf_common.rb:80:in 'Kernel#`' : No such file or directory - g++ ( Errno::ENOENT ) My system was essentially complaining that it couldn't find g++ , the C++ compiler. The Initial (Failed) Attempt My first thought was, "Oh, I must have forgotten to install the base build tools on this machine." Since I'm on Fedora, I reached for the standard DNF command to pull in the development group: sudo dnf install @development-tools (Note: If you're on older versions of Fedora, you might be used to dnf groupinstall "Development Tools" , but DNF5 uses the @ syntax or space-separated group install ). It downloaded and installed a bunch of packages. I felt confident, went back to RubyMine, clicked "Debug" again, and... got the exact same No such file or directory - g++ error. Why Didn't That Work? When you install Ruby gems that contain native C or C++ extensions (like debase ), Ruby doesn't just download a pre-built binary. It actually compiles the raw source code down to machine code directly on your machine so it runs as fast

When a build breaks, the bug fixes itself We stopped babysitting CI failures. Now a red build files its own bug — and an AI agent picks it up and ships the fix. PROBLEM — A failed build told no one Our CI would fail, and then… nothing would happen. The failure sat quietly in a build console that nobody keeps open. Eventually someone would notice a change hadn't gone out, go digging, and realize the build had been red for hours. And noticing was the easy part. Actually resolving it meant a whole code session: pull up the logs, find the failing step, reproduce it, and have an engineer sit down and personally shepherd the fix from broken to green. Every red build cost real human hours — plus the invisible tax of the delay before anyone even knew there was a problem. The true cost of a broken build was never the build. It was a person having to find it, understand it, and hand-fix it. SOLUTION — The failure files its own ticket — and an agent takes it from there Now nobody watches a console and nobody triages. The moment a build fails, it automatically files a bug in Shipeasy — our ops platform — as a real, prioritized ticket with the failing step, the branch, and a link to the logs already attached. From there it leaves human hands entirely. Shipeasy hands the bug to an AI agent, which investigates the failure, writes the patch, and opens a pull request against it. The loop that used to be "human notices → human reads logs → human fixes" is now "build fails → bug appears → agent fixes." The engineer's job shrank to reviewing a PR that already exists. DESIGN — How the whole thing hangs together The pipeline is deliberately boring — every hop is either something the cloud already does for free, or a service we already run: Cloud Build — build fails: a red deploy on main publishes automatically Pub/Sub topic → push subscription: filters to FAILURE · TIMEOUT · INTERNAL_ERROR HTTPS POST /webhooks/cloud_build Webhooks::CloudBuildController: verify token · decode · dedupe by

Hello! It has been a couple of months since I announced my latest project, Testing Rails from Scratch: A practical, (mostly) out-of-the-box approach to test-driven development in Ruby on Rails . The book is a thought experiment of sorts, as I revisit the default Rails testing stack after years of RSpec. I've been incrementally exploring the defaults and building tests from the foundational building block, on to more complex test cases and tools. This is the same approach I took to learn RSpec to begin with, and the same approach I took in the RSpec book on which Testing Rails from Scratch is based. It's been slower-going than I'd planned due to unexpected life circumstances this summer, so I wanted to share what is available now, and what's left. Quick plug for anyone still holding off: I'm running a work-in-progress special, $9 for lifetime updates to Testing Rails from Scratch until I'm finished. Purchasing work-in-progress books is a wonderful way to support independent authors, just saying! What's there now As I write this, the first five chapters of the new book are available for purchase on Leanpub. Chapters 1 and 3 are available as a free sample/preview download, no strings attached. An introduction to the problem being solved and my approach to learning and teaching Exploring the default Rails testing setup Testing Active Directory models Addressing DRY in tests, and when not to Using fixtures to create and manage test data Each chapter builds off the concepts and code from the previous one, and full source code for each chapter is provided. What's to come One interesting thing about my approach is I sometimes learn things as I'm writing and refining that affect future chapters. Case in point, I'd planned a single chapter on test data, decided to split it into two smaller, more digestible chapters. As of now, the remaining material will be broken up as: Managing test data with factories Testing units together with integrations Testing end-to-end with system

Lucian Ghinda published a post arguing you should tell your coding agent to write its throwaway scripts in Ruby. Here is the block he tells you to paste into your agent's instruction file, in full: ## Scripts Write throwaway and utility scripts (data munging, one-off migrations, file renames, glue code) in Ruby, even in projects written in another language. If it needs a pipe, a loop, a conditional, or more than one line, it is a script: write it in Ruby, not Python, Node, or bash. Single self-contained commands ( `grep` , `git status` ) are fine as-is. Use only the Ruby standard library. If a gem would clearly save significant effort, stop and ask before using it. Put temporary scripts in a scratch or temp directory, not the repo root, and delete them when done unless asked to keep them. I pasted it into my global CLAUDE.md the same evening. His argument is about review: he reads Ruby daily, so when the agent writes Ruby he stays a reviewer instead of nodding at a diff. He gives three reasons and not one of them is cost. So I went looking for the number he left out. "Does the rule save tokens" only means something against what the agent writes otherwise, so the first thing I had to do was take the block back out of my global config. An agent that already carries the rule cannot tell you what it would do without it. Measuring an agent without your config in the room Every arm below runs through claude --safe-mode on Claude Opus 5, which loads no CLAUDE.md , no skills, no plugins and no hooks. Two arms deliberately skip that flag, and I name them where they appear: they are the ones that measure what my own setup does to the result. It is worth knowing that my global config alone still carries a line telling the agent to write the minimum code that does the job, and another preferring bun over node. Four tasks, one for each kind of script the rule names: munge a log, rename a key across a tree of config files, renumber a pile of screenshots, turn one CSV into another

Wide Events is a Rails gem that puts the production context a coding agent needs onto one OpenTelemetry root span per request or job. In one production search request, the root event showed 30.0 seconds total duration, 446 ms of Postgres time, and 29.4 seconds of outbound HTTP time. That was enough to focus the investigation on an external dependency. The trace then identified a POST that took 28.9 seconds. The trace contained 82 spans and 20,261 bytes of attribute JSON. The root event contained 40 attributes and 1,420 bytes. This is not a token benchmark, but it shows why the root event is a more compact starting point for an agent. Agents can read the code, but not the running system A coding agent starts with an unusual advantage: it can search every model, controller, job, migration, and test in a few seconds. It also starts with a serious blind spot. The repository cannot tell it: which account experienced the problem which build was running which feature-flag variant was active how many queries the request issued whether a semantic-search leg degraded how much an LLM call cost whether the same symptom appears in one tenant or every tenant Those answers often exist somewhere, but “somewhere” might mean a trace waterfall, application logs, a feature-flag service, product analytics, and a database console. Pulling all of that into a context window is expensive and usually requires several joins that were never designed in advance. A wide event changes the starting point. The app accumulates the context it learns while processing one unit of work, then attaches the completed flat map to the OpenTelemetry root span. The span is marked main=true , so every request or job can be queried as one row. request or job -> Rails and domain context accumulate -> child spans contribute dependency counts and timings -> one flat map is flushed onto the root span -> ClickHouse stores one queryable row The trace still exists. Wide Events gives it an application-shaped index. If y

I often see people using the term "namespace" incorrectly. Even when explanations of what a namespace is are presented, they only go as far as describing its function, neglecting to properly define the name "namespace" itself. Definition of the Namespace A namespace is literally the space to which a name belongs . If we were to classify the term namespace, it would be a specification (concept), not a tool. In namespaces, the higher level is represented as outer and the lower level as inner . In terms of class structure, this corresponds to outer classes and inner classes. In other words, to explain it from a different perspective, it looks like this. Representation of namespaces from the outer perspective Build namespaces (best) Define namespaces (to fit many programming language implementations) Open namespaces (such as Ruby's class definition and module definition ) Create namespaces (such as the pseudo-namespace hack in older JavaScript) Declare namespaces (such as the package declaration in Java or the namespace declaration in PHP) Representation of namespaces from the inner perspective Belong to a namespace (best) Entering the namespace (This is entirely from an inner perspective, so it might feel out of place depending on the context) Be included in the namespace (this is a reasonable explanation if explained objectively). Incorrect expression From the definition above, it is clear that the following expressions are incorrect. Add/Paste a namespace (the expression "add/paste a space" is grammatically incorrect). Use namespaces (not to the point of being completely broken, but treating namespaces as a tool) Separate/Cut namespaces (While "Separated by namespaces" is understandable, "separate/cut" can be misleading) Meaning of "Name" in Namespace The "names" referred to here can be class names, module names, or package names. What they represent varies depending on the language that implements namespaces. For example, in Ruby, it refers to constant names. In Rub

A few weeks ago I needed to check something in the Action Mailer docs, just a quick lookup. I ended up spending much more time there than expected and found a few features I had no idea existed, even though I've been using Action Mailer in production for a while. One of them lets you see an email before it's ever sent. Another lets you modify an email right before it goes out. And the third one allows you to override the default delivery options dynamically. I figured I probably wasn't the only one who had missed these, so here are three Action Mailer features that caught my attention. If you want to explore more, the official Action Mailer documentation is always a great place to start. 1. Previews Before I found this, testing an email meant sending it to myself, checking my inbox, tweaking the template, and repeating. Turns out ActionMailer has a built-in way to preview emails in the browser, without sending anything. You add a preview class in test/mailers/previews like: class InvitationMailerPreview < ActionMailer :: Preview def team_invitation InvitationMailer . with ( user: User . first , company: Company . first ). team_invitation end end And visit http://localhost:3000/rails/mailers/invitation_mailer/team_invitation . This removes the usual feedback loop of tweaking a template. You just refresh the browser instead. Rails also allows custom preview paths if you want to keep previews in a different location: config . action_mailer . preview_paths << " #{ Rails . root } /lib/mailer_previews" This was a small discovery, but it immediately improved my workflow. 2. Interceptors An interceptor is a hook that runs right before an email is handed off for delivery, letting you modify it. A common use case is preventing mistakes in staging environments. Nobody wants to accidentally send a real looking email from a staging application to an actual customer. Another common approach is redirecting all outgoing mail in staging or development environments to a single defaul

Four ways to orchestrate business logic in Ruby. One map to find yours. You're building something that involves multiple steps. Charge a card, send an email, update inventory. Simple. Then someone says "What if step 3 fails? What undoes steps 1 and 2?" and suddenly you're evaluating workflow libraries. There are four mainstream approaches in Ruby today — Ruby Reactor , dry-transaction , Trailblazer , and raw Sidekiq jobs. This guide helps you pick the right one — not by ranking them, but by mapping them to the problem you're actually solving. The 30-Second Decision Matrix If you only have 30 seconds, start here: You want... Pick... A simple pipeline — 3-5 steps, top-to-bottom, no parallelism dry-transaction Railway-oriented programming with success/failure tracks, already in the Trailblazer ecosystem Trailblazer A full saga orchestrator — DAG dependency resolution, Sidekiq async, auto-compensation, locks, dashboard Ruby Reactor One-off fire-and-forget jobs, no coordination needed Raw Sidekiq None of these are "better" than the others. They solve different problems. Let's walk through each one. Meet the Libraries dry-transaction (v0.16.0) dry-transaction is a thin, focused gem from the dry-rb ecosystem. It wraps a series of operations in a sequential pipeline with a clean step DSL: class CreateUser < Dry :: Transaction step :validate step :persist step :send_welcome_email def validate ( input ) = # ... def persist ( input ) = # ... def send_welcome_email ( input ) = # ... end Steps run top-to-bottom. If any step returns a Failure , the pipeline stops immediately — no further steps execute. It's a railway under the hood: each step can produce Success(value) or Failure(error) , and the pipeline routes accordingly. What it's great at: Simple, synchronous pipelines. It's the Ruby equivalent of an Either monad chained with bind — clean, predictable, and minimal. If you're already in the dry-rb ecosystem (dry-validation, dry-types, dry-monads), it fits naturally. What it d

(Translated from the Japanese article .) This is a quiz about Ruby's Bundler! Add 8 characters to the following Gemfile so that bundle install fails (with non-zero exit code) for the second time or later. source "https://rubygems.org" gemspec Notes: Bundler is a fairly recent version (approximately version 3 or later). The first invocation succeeds. If you find the answer (on your own), please send me a direct message on ruby.social or email, etc.! Wrong Answers An invalid URL like https://rubygems.org12345678 : It doesn't fail since Bundler doesn't refer to the URL. An invalid URL and gems: It fails on the first run. It must fail only on the second or later runs. License Copyright (C) 2026 gemmaro Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.

GitHub热门项目 | Open source DocuSign alternative. Create, fill, and sign digital documents ✍️ | Stars: 17,719 | 152 stars today | 语言: Ruby

Users are creating accounts on your new Saas. Yay (and not just family and friends or bots). Yay! Now comes the next step from every marketing handbook: capturing newsletter subscriptions. This article builds on Add Sign Up to Rails 8’ Authentication . Add a simple checkbox to let users opt in to product updates during signup. Store their preference using Rails Vault and manage the subscription with Rails Courrier . First, add Rails Vault and Rails Courrier to your Gemfile: gem "rails_vault" gem "rails_courrier" Rails Vault adds simple and easy settings, preferences and so on to any ActiveRecord model (I recently pushed 1.0.0). Courrier is API-powered email delivery for Ruby apps with support for Mailgun, Postmark, Resend and more. Rails Courrier is the Rails “wrapper” for Courrier. These two gems work really nicely together for this feature. Run bundle install and generate the Rails Vault migration: rails generate rails_vault:install rails db:migrate It creates a new file app/models/user/subscriptions.rb : class User::Subscriptions < Vault vault_attribute :product_emails_subscribed_at , :datetime # Add more subscription types as needed: # vault_attribute :marketing_emails_subscribed_at, :datetime # vault_attribute :weekly_digest_subscribed_at, :datetime end And updates your User model to use this vault: # app/models/user.rb class User < ApplicationRecord + vault :subscriptions has_secure_password has_many :sessions , dependent: :destroy end This keeps subscription data organized without cluttering your User table. More subscription types can be added later without database migrations. Now the plumbing is done, add a checkbox to your signup form in app/views/signups/new.html.erb : <%= form . check_box :product_emails %> <%= form . label :product_emails , "Subscribe to product updates" %> Update the Signup model to accept this parameter: # app/models/signup.rb class Signup include ActiveModel :: Model include ActiveModel :: Attributes attribute :email_address , :stri

There's a comfortable thing people say when they see an AI agent query a code map. "Nice crutch. For now." The logic underneath it is reasonable. Coding agents are young. Context windows are small and getting bigger. Models are dumb today and will be smart tomorrow. So a structural index, the thing that hands the agent a dependency graph it would otherwise have to reconstruct, looks like a patch over a temporary weakness. Wait two releases. The model will just hold the whole repo in its head and the map becomes a quaint workaround, like a spellchecker for someone who learned to spell. I build one of those maps Sense . I went looking for the data that would kill it. I didn't find it. I found the opposite. What a map hands an agent is a computed fact. What a better model hands you is a more confident guess . No amount of model progress turns the second into the first, because the difference between them isn't a quality gap that closes with scale. It's a difference of kind. The rest of this piece is the two findings that forced me there. The belief, stated fairly The claim at full strength, because a weak version is easy to knock over. A code map exists to compensate for what the model can't do yet. Today's agent greps, samples, and guesses at structure because it can't read the whole codebase at once. Tomorrow's agent reads all of it, reasons over all of it, and the guessing stops. Bigger windows plus better weights equal no more blind spots. The map is scaffolding you'll tear down once the building stands. If that's true, the right move is to skip the tool and wait. Both findings, in order. Proof one: the best model available was still blind The benchmark ran the same task on thirteen real Ruby repos. Pick the hub model of an app, the Inbox , the MergeRequest , the Spree::Order , and ask the agent to find every place that depends on it before a teardown change. The non-obvious dependents, the ones scattered through concerns and workers and config-string registries, w

You've seen the claim in every Ruby thread for the past year. Ruby and Rails are the most AI-friendly stack. Fewer tokens, less hallucination, the model just writes it cleanly. Half of that claim I'll concede without a fight . The other half I measured, across thirteen real Ruby codebases, and that's where a line shows up, sharp enough to put every repo on one side or the other. Including yours. The half that's true: writing Ruby is solved Start with the part that holds up, because it really does. A model that has seen ten thousand Rails apps knows where the model lives, where the job goes, what a concern does, what has_many implies, before it reads a line of yours. Convention over configuration was always written partly for the next human reading the code. It turns out the model is the next reader too, and the conventions answer half its questions before it asks them. So "write me a service object," "add a scope," "refactor this controller"? The stack carries the model. Fewer wrong guesses, tighter loops, less to hallucinate because the shape is already known. Anyone who builds on Rails has lived this, and the AI-friendly reputation earned it. I'm not here to take that away. I'm here to point out it answers a question nobody dangerous is asking. The half that isn't: navigating Ruby at scale "Can AI write Ruby" is settled. The question that ships broken deploys is different: can AI navigate Ruby? What breaks if this model changes, who depends on it, where the blast radius ends. Reading and navigating feel like the same skill when you're fluent. They are not the same skill for an agent. Reading a file is local, the answer is right there in the text. Navigating is structural, the answer lives in the edges between files, what calls what, what breaks what, and no single file contains it. So I ran the structural question on all thirteen repos. Same task each time: take the hub model, the Inbox , the MergeRequest , the Spree::Order , and find every dependent before a tear

I Built Commercial Redis CDC Source Drivers for Ruby — Here's What I Learned For the past couple of years I've been building a Change Data Capture (CDC) ecosystem for Ruby. Like many CDC projects, it started with PostgreSQL. PostgreSQL's Write-Ahead Log (WAL) is an excellent source of truth: durable, ordered, replayable, and well understood. It provides exactly the properties you want when you're building reliable event pipelines. But the deeper I went into distributed systems, the more I realized something important. Many systems don't observe change from PostgreSQL first. They observe it from Redis. Redis often sits at the front of modern architectures: Redis Streams carry application events. Pub/Sub distributes transient state changes. Keyspace notifications react to cache invalidation and key expiry. Redis Cluster routes events across multiple primaries. In many systems, Redis sees a change before PostgreSQL ever commits it. That raised an interesting question: Can Redis become a first-class Change Data Capture source? The obvious answer is "yes." The interesting answer is "yes—but not in the same way PostgreSQL does." That distinction eventually became cdc-redis-pro , a commercial Redis source driver for the Ruby CDC ecosystem. This article isn't a product announcement. It's an engineering write-up about the architectural decisions behind the project, the tradeoffs Redis forces you to make, and the execution model that ultimately emerged. Redis Doesn't Have One CDC Interface One misconception I frequently encounter is the assumption that Redis has an equivalent of PostgreSQL's WAL. It doesn't. Instead, Redis exposes several completely different mechanisms for observing change. Source Delivery Replay Streams At-least-once Yes Pub/Sub At-most-once No Sharded Pub/Sub At-most-once No Keyspace Notifications At-most-once No At first glance they all look like "events." Operationally they're completely different systems. Streams are durable. Pub/Sub isn't. Keyspace not

You've built a checkout reactor that reserves inventory, charges a card, generates a shipping label, and sends a confirmation email. It runs through Sidekiq. When something fails, compensation logic rolls it back. It works. Then your team asks: "How many checkouts failed this week? Which step? How long does the charge step take at p99? Can we see a trace through the entire system?" Before v0.5.0, you'd need to add logging calls to every step, build a custom Sidekiq middleware, and figure out how to correlate traces across async job boundaries. Now it's one line of config. Enter Middlewares Ruby Reactor 0.5.0 introduces a middleware pipeline — the same pattern that powers Rack, but designed for saga execution. A middleware is a plain Ruby object that hooks into the reactor lifecycle: class TimingMiddleware < RubyReactor :: Middleware def initialize ( ** options ) super @started = {} end def on_start_step ( step_name , _arguments , _context ) @started [ step_name ] = Process . clock_gettime ( Process :: CLOCK_MONOTONIC ) end def on_complete_step ( step_name , _result , _context ) started = @started . delete ( step_name ) return unless started elapsed = Process . clock_gettime ( Process :: CLOCK_MONOTONIC ) - started logger . info ( "step #{ step_name } took #{ elapsed . round ( 4 ) } s" ) end end This middleware times every step. Register it globally: RubyReactor . configure do | config | config . middlewares = [ TimingMiddleware ] end Now every reactor — every checkout, every refund, every data import — gets step-level timing, for free. The full lifecycle (20+ events) Middlewares can observe the complete execution lifecycle: Phase Events Reactor on_start_reactor , on_complete_reactor , on_failed_reactor Step on_start_step , on_complete_step , on_failed_step , on_retry_attempt Compensation on_start_compensation , on_complete_compensation , on_failed_compensation Undo on_start_undo , on_complete_undo , on_failed_undo Coordination on_lock_acquired , on_lock_failed , on_

GSoC 2026 | CircuitVerse × Canvas LMS LTI 1.3 Integration If Week 1 was about getting familiar with the codebase and understanding what needed to be built, Week 2 was about learning the hard way that writing code is only half the job. The other half — the messier, more humbling half — is getting that code accepted by the people who actually maintain the project. This week was full of detours, rejected pull requests, reviewer feedback that stung a little, and a surprisingly frustrating fight with a two-letter word in Ruby. But by the end of it, I had something real to show: a clean, reviewed, and submitted change to CircuitVerse that lays the foundation for the entire LTI 1.3 integration. Let me walk you through it. A Quick Refresher: What Are We Building? CircuitVerse is an open-source platform where students can build and simulate digital circuits right in their browser. The project I'm working on aims to connect CircuitVerse with Canvas, one of the most widely used Learning Management Systems (LMS) in universities around the world. The technology that makes this connection possible is called LTI — Learning Tools Interoperability. Think of it as a universal plug that lets any educational tool (like CircuitVerse) slot into any LMS (like Canvas) so that students can log in once, get assignments, submit work, and have their grades flow back automatically — all without leaving their course page. There are two versions of this plug: LTI 1.1 , which is old and uses a simpler (but outdated) security mechanism, and LTI 1.3 , which is newer, more secure, and what Canvas actually recommends today. My job is to bring CircuitVerse fully up to LTI 1.3 standards. Monday–Tuesday: A Pull Request That Taught Me to Read Diffs I started the week with what I thought was a solid pull request (PR) — a fix for a bug in CircuitVerse's existing LTI 1.1 grade passback feature. "Grade passback" is the process where CircuitVerse sends a student's score back to Canvas after they complete an as

GitHub热门项目 | Open-source live-chat, email support, omni-channel desk. An alternative to Intercom, Zendesk, Salesforce Service Cloud etc. 🔥💬 | Stars: 30,663 | 86 stars today | 语言: Ruby

RubyConf holds a special place in my heart. It was the very first tech conference I attended after receiving a scholarship fresh out of Flatiron School back in 2017 (you can read about my experience here ), and then in 2021, it was the stage for my first conference talk in Denver. Now, in another first, I joined the Program Committee for RubyConf 2026 to help put the program together, and what a program it is! We have an absolutely amazing lineup this year, and I'm so excited to see it come to life! Who else is planning on attending? Let's make plans to meet up and say hi!

Rails GuardDog: Advanced Security Scanner for Rails Introduction Today I'm excited to announce Rails GuardDog v0.1.0 — an open-source security scanner for Rails that goes beyond traditional tools like Brakeman. While Brakeman is excellent for catching basic Rails vulnerabilities, Rails GuardDog focuses on newer vulnerability classes that most tools miss: AI/LLM prompt injection, DoS/ReDoS patterns, supply chain attacks, and more. The Problem Modern Rails applications face new security challenges: AI/LLM Integration - How do you prevent prompt injection when integrating with ChatGPT, Claude, or Anthropic? ReDoS Attacks - Catastrophic backtracking in regex can bring down your app Supply Chain Attacks - Typosquatted gems that look like popular libraries IDOR Gaps - Objects accessible without proper authorization checks Advanced Secrets - Hardcoded API keys that Brakeman misses Rails GuardDog detects all of these. What is Rails GuardDog? Rails GuardDog is a lightweight gem that adds comprehensive security scanning directly to your Rails applications. 12 Security Checkers SQL Injection - String interpolation in queries XSS - Unescaped output in views CSRF - Disabled protection verification Mass Assignment - permit! vulnerabilities (fixes Brakeman #1942, #1918) Open Redirect - User input in redirects Hardcoded Secrets - API keys, tokens, passwords (always-on, fixes #1989) DoS/ReDoS - Unbounded queries, dangerous regex patterns IDOR - Object access without authorization AI/LLM Prompt Injection - User input flowing to LLMs Rate Limiting - Missing rack-attack configuration Supply Chain - Typosquatted gems using Levenshtein distance GraphQL - Missing field-level authorization Features 📊 Multiple report formats : Console, HTML, JSON 🔍 AST-based analysis : Uses parser gem for deep code understanding ⚡ Async support : Built-in Sidekiq integration 📈 Zero dependencies : Only requires parser and ast gems 🚀 Production-ready : Tested and battle-ready 📝 CWE/OWASP mappings : Every find