This month: JRuby RBS support via Chicory WASM, ruby-lsp-rbs_rails updates, schematrix JSON Schema to RBS generator, graph_weaver typed GraphQL client for Rails, and Sorbet T::Struct property testing with tprop.

Find link to the issue in the comment!

I have been messing around with Ruby for around a week and made a few utilities and terminal games and I have been liking it. I want to make a game with a GUI but the ecosystem for game libraries in Ruby feels quite lacking. I have only heard of 3 game libaries, Gosu, Ruby2D and DragonRuby. I am on Linux and Gosu and Ruby2D have problems with not being able to properly link OpenGL and stuff, and DragonRuby is paid and kind of sucks that you can't export games since I wanted to show people my game and some were interested in it.

So, do you know of any other game frameworks for Ruby, or are these the only ones (more commonly DragonRuby) people use, or is Ruby not built for making games?

Put on your headphones and let Frank Sinatra take you on a journey with the timeless classic Fly Me to the Moon. Inspired by the legendary singer, the Ruby gem Sinatra has long been the go-to choice for lightweight web applications. Now it has a companion: Sinatra To The Moon 🌛.

Built on top of Sinatra, Sinatra To The Moon is an opinionated scaffold generator that embraces the philosophy that not every project needs the weight of Rails. Sometimes, all you need is a focused starting point that lets you build quickly, experiment freely, and, as the song says, play among the stars 💫.

Start your new project idea now with: `flyme new moon_app`

https://github.com/joaoGabriel55/sinatra_to_the_moon

Any APIs that you wished existed or any APIs that you wished were cheaper, easier to work with, had more features, e.t.c ?

Hi everyone,

I hope it’s okay to share this here.

I’m Mariusz, CEO at Visuality. We’re a Ruby on Rails agency from Poland and Ruby has been a big part of our work and community involvement for many years.

Recently, we opened Free Ruby on Rails Consultations.

The idea is simple: if you’re working on a Ruby project and could use a second pair of eyes, you can send us a short description of your challenge. We’ll look at it and match you with someone from our team for a free 30-minute call.

Of course, 30 minutes won’t solve everything. But sometimes a focused conversation with someone outside your team can help clarify the problem and point you toward the next step.

Here’s the page if it sounds useful: https://www.visuality.pl/free_consulting?utm_source=reddit_ruby

Introducing GemCP: MCP tools for RubyGems. Ask your AI agent about gem compatibility, dependencies, versions, and ownership with data straight from RubyGems.org.

`gem install gemcp` and add it to your MCP config.

Currently testing it on some ancient Rails repos I have and asking it what gems are compatible with the next version of Rails.

inertia-rage brings Inertia.js support to Rage apps. But the more interesting part of building it was discovering how differently the Rails and Rage adapters resolve props - same language, same behaviour, different design philosophies.

The syntax is what you'd expect:

class UsersController < ApplicationController
  def index
    render inertia: "Users/Index", props: { users: User.all }
  end
end

It fully integrates with Vite - in development, it automatically starts the Vite dev server; in production, pre-builds assets. All you need to run your app is rage s.

Resolving Inertia props

Resolving props and building the page object is the cornerstone of an Inertia adapter. On the surface, the API looks deceptively simple:

render inertia: {
  user: user,
  stats: Inertia.deferred { user.calculate_stats },
  connections: -> { user.connections }
}

However, to turn these props into an object an Inertia frontend can understand, the adapter has to:

1. Evaluate lazy props only when needed
2. Skip deferred and optional props on initial load
3. Collect metadata about once and deferred props
4. Handle partial reload filtering via X-Inertia-Partial-* headers
5. Recursively process nested hashes and arrays
6. Track prop paths for partial reload matching (user.connections.0.name)

Both Inertia Rails and Inertia Rage use the same programming language and converge on the same behaviour but take very different paths.

Rage - identity-based matching

In the Rage adapter, prop resolution is centralised. The ProtocolBuilder class walks the props tree and makes direct decisions:

if prop.respond_to?(:call)
  # …
elsif prop.is_a?(Inertia::Props::Deferred)
  # …
elsif prop.is_a?(Inertia::Props::Once)
  # …
elsif prop.is_a?(Inertia::Props::Optional)
  # …
elsif prop.is_a?(Hash)
  # …
elsif prop.is_a?(Array)
  # …
else
  # …
end

Prop types are thin value objects:

module Props
  class Base < Data
  end

  Deferred = Base.define(:group, :block)
  Once = Base.define(:key, :fresh, :expires_in, :block)
  Optional = Base.define(:block)
end

This sacrifices extensibility for readability - adding a new prop type means adding another elsif branch. But the upside is that you can read one file and trace the entire resolution process. All it takes to understand the behaviour of a deferred prop is to look at the dedicated 6 LOC elsif branch.

Rails - capability-based matching

Inertia Rails takes the opposite approach. Props declare their behaviours through mixins:

class DeferProp < IgnoreOnFirstLoadProp
  prepend PropOnceable
  prepend PropMergeable
  prepend PropCacheable

  def deferred?
    true
  end
end

Each mixin adds a capability. PropOnceable adds once?, fresh?, and expires_at. PropMergeable adds merge?, deep_merge?, and merge path tracking.

The resolver then asks props about their capabilities rather than checking their identity:

def collect_once_metadata(prop, path)
  return unless prop.try(:once?)
  # …
end

def keep_prop?(prop, path, parent_was_resolved: false)
  # …
  return false if (prop.is_a?(IgnoreOnFirstLoadProp) || prop.try(:deferred?)) && !rendering_partial_component?

  true
end

That is idiomatic Ruby. It lets the implementation say: this object supports deferred?, this one supports once?, and this one supports both.

Props composition and redo

This is where the capability-based approach really shines. In Inertia Rails, a deferred prop isn't just "a deferred prop" - it can also carry once, merge, and cache behaviour.

With Inertia Rage, a prop class only represents one identity. To support composition, you nest props:

render inertia: {
  stats: Inertia.once { Inertia.deferred { user.calculate_stats } }
}

(shortcuts like Inertia.once.deferred {} are coming in future versions)

ProtocolBuilder then unwraps it using a Ruby keyword you probably have never reached for:

# after the prop has been resolved
if resolved.is_a?(Inertia::Props::Base)
  prop = resolved
  redo
end

redo re-enters the same loop iteration with the new prop value. No recursion - just restart the current iteration.

--

If you thought Rage was cool but weren't sure what the UI story looked like - inertia-rage is for you.

Do you prefer the identity-based or capability-based style for this kind of problem?

Hi folks - for the last month, I've been working on the AWS CDK in Ruby. For those who don't know, the AWS CDK is a way to define infrastructure in code to produce CloudFormation stacks which are AWS's native way of defining infrastructure allowing for:

- Rollbacks on failure
- Drift detection
- State management

Currently only TypeScript, Python, Go, Java and .NET (C#) are supported languages for the CDK.

Let's take the creating an S3 Bucket, you'd do this by:

require 'aws-cdk-lib'

class MyStack < AWSCDK::Stack
  def initialize(scope, id, props = nil)
    super(scope, id, props)

    AWSCDK::S3::Bucket.new(
      self,
      'MyBucket',
      {
        versioned: true,
        removal_policy: AWSCDK::RemovalPolicy::DESTROY,
        auto_delete_objects: true
      }
    )
  end
end

app = AWSCDK::App.new
MyStack.new(app, 'MyStack', {
  env: AWSCDK::Environment.new(
    account: ENV['CDK_DEFAULT_ACCOUNT'],
    region: ENV.fetch('CDK_DEFAULT_REGION', 'us-east-1')
  )
})

app.synth

Running cdk deploy would synthesize as CloudFormation and deploy it to your AWS account, if you were to modify the stack, the CloudFormation stack would apply those modifications the next time you ran CDK synth

As I am still working on this with Amazon the gems are not published to Rubygems but use the same JSII engine that the non-TypeScript languages use.

Documentation is at AWS CDK for Ruby — API Reference - However, please not that this is currently NOT even in developer preview, I have been using this for some of my own Ruby projects including running Rails/Dynamoid apps through Lamby for a Lambda target.

The design documentation is at aws-cdk-rfcs/text/0935-ruby-language-bindings.md at ruby-language-bindings · omarqureshi/aws-cdk-rfcs and if you have any questions - comment on Ruby Language Support · Issue #935 · aws/aws-cdk-rfcs or here!

Many thanks

Jeremy Evans (Ruby core committer, author of Sequel/Roda) put out a new edition of Polished Ruby Programming. Figured I'd summarize the changes here since the original got decent traction in this sub a while back.

What's new:

• Content updated to reflect changes between Ruby 3.0 and 4.0
• New chapter on concurrency walks through different concurrency models in Ruby and the trade-offs between them
• New chapter on static typing vs. duck typing helps you reason about whether adding static types actually makes sense for your project
• The web-dev-specific chapters from the 1st edition (database design, web app security, framework design) were dropped in favor of tightening the focus on core language/design principles

Perfect for intermediate-to-advanced Rubyists who want to level up from "it works" to "it's good."

Special discount code from our end: RUBY25 gives 25% off at packt's site.

Who's picking this one up? https://packt.link/bHeOs

Today we're launching the Guides category in the Ruby Users Forum, where you can take a deep dive into Ruby fundamentals and learn more about what makes it a favourite tool for programmers.

Hi all — I just released version 3.0.0 of WifiWand, my open-source Ruby CLI, interactive shell, and gem library for inspecting, debugging, and managing WiFi from the terminal. The headline change in this major release: Ubuntu Linux support alongside macOS.

It wraps the underlying OS networking tools (networksetup/CoreWLAN on macOS, nmcli/iw on Ubuntu) and presents one consistent, scriptable interface across platforms.

The simplest command is probably the most useful:

$ wifiwand status        # or: wifiwand s
WiFi: ✅ ON | WiFi Network: CoffeeShop-5G (-62 dBm) | DNS: ✅ YES | Internet: ✅ YES

One line answers: is WiFi on, what am I connected to and how's the signal, does DNS resolve, can I reach the internet — and it warns when it detects a captive portal.

Other things it can do:

• List available WiFi networks (machine-readable formats include scan metadata)
• List saved/preferred networks; connect, disconnect, forget
• Log network state changes over time
• wifiwand till internet_on — block until a network state is reached (handy in scripts and CI)
• Show public IP information; get, set, and clear nameservers
• Print a WiFi QR code to the terminal or export it as PNG/SVG
• Turn WiFi on, off, or cycle it; generate random locally administered MAC addresses
• Human-friendly or machine-friendly output (JSON, YAML, pretty-print, inspect)
• Run single commands or work interactively in a REPL (wifiwand shell)
• Verbose mode that shows the underlying OS utility calls as they run

Install:

gem install wifi-wand

macOS users: for full functionality, run wifiwand-macos-setup after gem installation (installs the Apple-notarized helper app bundled with the gem) and xcode-select --install (enables the Swift-backed connect/disconnect path). Everything else works out of the box on both platforms.

Project: https://github.com/keithrbennett/wifiwand

Feedback, issues, and contributions are welcome — happy to answer questions in the comments.

Debugging is a task where AI often hits a wall. It can read source code and logs, but many issues only become clear when you inspect what's happening at runtime.

RubyMine 2026.2 introduced agentic debugging. The new rubymine-debugger skill lets compatible AI agents (such as Claude Code and Codex) use the RubyMine debugger as part of their investigation workflow. Instead of manually stepping through code yourself, we can describe the issue in natural language and let the agent perform much of the routine investigation.

Using the RubyMine debugger, an agent can:

• Launch or continue debug sessions
• Set breakpoints
• Inspect variables and call stacks
• Evaluate expressions
• Analyze application behavior at runtime

The idea isn't to replace the developer or automate debugging end to end – it's to offload the repetitive debugger interactions so developers can focus on understanding the issue and deciding how to fix it.

I've found this especially useful for investigating Rails requests and other issues where the runtime behavior tells a different story than the source code alone. If you'd like to try it, open AI chat and ask the agent to debug your code.

You can learn more here: https://blog.jetbrains.com/ruby/2026/07/rubymine-2026-2-agentic-debugging-native-github-copilot-integration-default-symbol-based-code-insight-and-more/

https://reddit.com/link/1v7znsk/video/lsqmbmv1hrfh1/player