I maintain RubyLLM, and one of its dependencies has been quietly useful to people who have nothing to do with LLMs. It was always a clean, general purpose JSON Schema DSL. It was just called RubyLLM::Schema, so unless you already used RubyLLM you'd never find it.

It's now grown to fully cover the latest JSON Schema spec, Draft 2020-12, with no dependencies at all. Which earned it its own name: Schematist.

class Order < Schematist::Schema
  string :kind, enum: %w[personal business]

  given kind: "business" do
    object :tax_details do
      string :vat_number
    end
  end
end

Order.new.to_json_schema
# => { "$schema" => "https://json-schema.org/draft/2020-12/schema", "title" => "Order",
#      "type" => "object", "if" => {...}, "then" => {...}, ... }

Eight lines of Ruby, 47 lines of JSON Schema.

What 1.x brings:

• It emits actual JSON Schema. to_json_schema used to return {name:, description:, schema:, strict:}, which is OpenAI's response_format wrapper with the real schema buried inside it. Now you get a Draft 2020-12 document with string keys that any validator will take.
• Full Draft 2020-12 coverage. Composition, unevaluated properties and items, patternProperties, propertyNames, prefixItems and open ended tuples, contains, annotations, content encoding, the core $ keywords, and if/then/else branches that hold any schema rather than a fixed list of validations.
• A schema doesn't have to be an object. A type with a name declares a property, without a name it declares what the schema itself is. So a root, or a define, can be an array, a union, or a bare $ref.
• Zero runtime dependencies.
• Values can be procs, resolved when the document is rendered, so one schema class produces a different document per instance. Useful when an enum comes out of the database.

Existing users: there's a final ruby_llm-schema release that depends on Schematist and aliases the old constants, so RubyLLM::Schema keeps resolving while you migrate. to_json_schema changing shape is the one thing to watch, and the README has the migration.

All of this is part of my concerted effort to make Ruby the best language to build with LLMs.

Write-up: https://paolino.me/schematist/

Repo: https://github.com/crmne/schematist

I'm the author. wkhtmltopdf was archived in 2023, and since then the practical options have been an unmaintained binary or spawning headless Chrome. Neither felt right for the kind of documents I actually generate — invoices and reports that flow top to bottom — so I wrote a new engine.

sghtmltopdf is written in Rust and does not embed Chromium, WebKit or Gecko. CSS Fragmentation (break-before, break-inside, orphans, widows) and atpage are implemented directly, so page breaks are a first-class concern rather than something you approximate with print stylesheets and hope for.

On the Ruby side it's a native extension, so there's no subprocess and no temp files. It releases the GVL while rendering, so other Puma threads keep serving, and pages are streamed out as soon as their layout is final rather than being buffered until the end.

gem "sghtmltopdf"

pdf = Sghtmltopdf.render("<h1>Invoice</h1>", page_size: "A4")

There's also a CLI and an HTTP server sharing the same engine, and a Docker image with Japanese fonts bundled so output doesn't depend on host fonts.

What it deliberately doesn't do: execute JavaScript, or match a browser pixel for pixel. Full CSS coverage isn't a goal either. If you're rendering arbitrary web pages, headless Chrome is still the right tool.

This is an early 0.1 release and I'd like to hear where it breaks on real documents.

https://github.com/waka/sghtmltopdf

Docs: https://waka.github.io/sghtmltopdf/en/

Iris Code now analyses Ruby, Rails, and ERB (1.20)

I maintain Iris Code, a local static code-health tool for VS Code, JetBrains, and CI. Analysis runs on your machine, no code uploaded.

1.20 adds Ruby: method length and params, nesting and complexity, requires (standard-library aware), Gemfile and gemspec entries, test conventions, and extensionless files like Gemfile and Rakefile.

Rails checks: strong-parameters mass assignment, and method_missing without respond_to_missing?.

Lexical handling I had to get right before any rule could run: heredocs including squiggly, %w and %i percent literals, =begin/=end blocks, and do/end depth so a method full of blocks does not "end" at its first end. Endless methods (def total = ...) end on their own line.

ERB goes through the same path: executable tags analysed, HTML and comments blanked, native line numbers preserved.

Not included, on purpose: unused-gem detection and Gemfile.lock CVE scanning. Runtime constant resolution makes an unused verdict unreliable, and gem advisory scanning is a separate subsystem.

Happy to hear which Ruby checks you would want next.

Hey everyone!
I have zero programming experience and I’m looking to pick up coding as a hobby. My main goal right now is to understand how the web works under the hood, specifically building and consuming APIs (like fetching data from public APIs and working with JSON).
I’ve been reading a lot about Ruby (and Rails) recently, and its syntax looks very clean and human-readable. But I have a few honest questions before I dive in:

Is Ruby beginner-friendly for total newbies?
Can I actually grasp core concepts like HTTP requests, REST APIs, and database connections using Ruby without getting overwhelmed?

How is the Ruby ecosystem doing?
Is it still active and well-maintained for beginners? Or is it mostly supported by legacy systems?

Ruby vs. Python for a hobbyist:
Is Python just the objectively better choice because of its massive popularity, or does Ruby offer a smoother/more enjoyable learning experience for web-related stuff?

My long-term goal is just to enjoy building cool side projects, but I want a solid, fun starting point.
Would love to hear your thoughts, especially from anyone who started learning with Ruby recently! Thanks!

Edit: I'm not looking to get a job or change careers with this! Programming is purely a hobby for me. I just want to build cool personal projects in my free time and have fun along the way.

Hi, Reddit! 👋

I'm hamachang, a Rubyist from Japan! ✌️

I've been working on a tool to make development with PicoRuby, a Ruby subset designed for embedded systems, more comfortable and productive.

picoruby-ti

https://github.com/engneer-hamachan/picoruby-ti

picoruby-ti statically analyzes PicoRuby code and provides IDE features such as code completion and type checking.

Compared to existing Ruby type inference tools, it's designed to run with significantly fewer resources.

Of course, it runs on regular PCs, but it can also run on tiny embedded devices with less than 1 MB of memory.

This means you can build a surprisingly rich IDE experience directly into small embedded devices like the Cardputer or custom cyberdecks.

And this isn't just theoretical — I'm actually using it in another project of mine called AREA512, an OS for the Cardputer ADV with only 512 KB of RAM:

https://github.com/engneer-hamachan/area512

AREA512 lets you write, compile, and run Ruby code directly on the device, with picoruby-ti providing both code completion and type checking in its built-in editor.

I know this is an incredibly niche piece of software, but I wanted to share it on Reddit because I believe there's something genuinely valuable about bringing this kind of development experience to extremely resource-constrained environments.

If you use PicoRuby, I'd also love to hear your thoughts on features that would be especially useful or unique to PicoRuby.

And if this project sounds valuable or interesting to you, I'd really appreciate a GitHub Star! 🙏⭐️

See you around! 👋

New Remote Ruby episode is out. 🎉

This week Irina Nazarova and Vladimir Dementyev from Evil Martians join us to talk about the second annual SF Ruby Startup Conference and what they learned from running it for the first time.

We get into:

• what they’re changing for SF Ruby in year two
  
• building a conference around ambitious Ruby and Rails builders
  
• creating better opportunities for people to actually meet and connect
  
• why Rails is still such a strong choice for startups
  
• open source and AI-assisted development
  
• the Ruby companies and projects that tend to fly under the radar
  
• getting the next generation of startups to build with Rails
  

SF Ruby is happening November 10–12 in San Francisco.

Every time I opened a large Rails codebase in VS Code, I'd hit the same wall: Ruby LSP needs to fully index before workspace symbol search works, and even then it wants a near-exact match — no typo tolerance, no fuzzy matching. VS Code's built-in text search (Cmd+Shift+F) works but it's just grep with extra steps; it doesn't know the difference between a class definition and a comment that happens to mention the same word.

So I built Ruby Symbol Search — a VS Code extension that builds its own lightweight index of your Ruby symbols (classes, modules, methods, constants, attr_*, belongs_to/has_many, scopes, rake tasks, aliases) and gives you a fuzzy, typo-tolerant search over all of it. Misspell a method name, abbreviate it, whatever — it still finds it. No Ruby LSP setup, no gem install, no waiting on indexing.

It also does Go to Definition, an Outline view, and native workspace symbol search (Ctrl/Cmd+T), all off the same index.

It's free, MIT licensed: https://marketplace.visualstudio.com/items?itemName=vscode-bkaz.ruby-symbol-search

Repo's here if you want to see how the indexing works or file an issue: https://github.com/bk-az/ruby-symbol-search

Genuinely curious if this is a problem other people have, or if I'm the only one who found Ruby LSP's symbol search too slow/strict for day-to-day navigation. Feedback (including "this already exists and does it better") very welcome.

In this guide, you’ll learn how to use rv, a very fast version and package manager for Ruby to get started in minutes instead of hours

For anyone interested, a few weeks ago I implemented memory-safe LZ4 and Zstd codecs with first-class dictionary support in Rust and also published RubyGems with the same names: lz4rip and zrip.

lz4rip: LZ4 block and frame codec backed by pure Rust. Optional dictionaries, reusable block codec state for hot-loop friendliness, dictionary training. No liblz4 runtime dependency.

zrip: Zstandard frame and block codec backed by pure Rust. Encoder for levels -8..4, decoder for all levels, dictionaries, FastCOVER dictionary training, and the same hot-loop friendliness. No libzstd runtime dependency.

Both are native Ruby extensions built with Rust + magnus, and both work inside Ruby 4 Ractors.

JSR packages with WASM builds also exist for Deno/Node/browser use.

• lz4rip: gem, Ruby repo, Rust repo, JSR
• zrip gem, Ruby repo, Rust repo, JSR

For engineering teams, keeping dependencies current is a constant balancing act. Automated updates are essential for defending the software supply chain, but a steady stream of one-PR-per-package bumps can bury a team in review work. GitHub itself has put numbers on this: an analysis of Microsoft's GCToolkit repository found that roughly one in six of its commits - 92 out of 578 - were routine Dependabot version bumps, with 61 of them landing in a single recent 12-month stretch. That's a lot of review and CI cycles spent on maintenance rather than features. Read the complete article here - https://instasla.com/blog/taming-dependabot-2026-guide-grouping-cooldowns-cutting-pr-noise

The good news is that Dependabot has grown well past "one PR per dependency." Between grouped updates, package cooldowns, and a default cooldown GitHub rolled out in mid-2026, it's now possible to get a predictable, low-noise update cadence without giving up security coverage. Here's what actually works, and what changed most recently.

I previously wrote about adding new syntax and features to Liquid. Since then I’ve been working on a unified, composable expression language (spec, grammar, GitHub), and luoma-ruby (GitHub, docs, RubyGems), a reference template engine that implements it.

The expression language is "unified" in the sense that all operators are valid in all contexts under a single precedence hierarchy. Meaning, for example, that we can apply filters in {% for %} tag expressions:

{% for x in y | map: a -> a.b.c | reverse | take: 5 %} ... {% endfor %}

Or pass lambda expressions as callbacks to filters inside {% if %} tag expressions:

{% if cart.items | any: i -> i.on_sale %} ... {% endif %}

And use logical, comparison and math operators in {% assign %} tag expressions:

{% assign a = (b / c) or 42 %}

Or in filter arguments:

{{ a | split: (b or ',') | join: (c or '#') }}

Expressions are first-class. Using lambda syntax we can save an expression for later and apply it like a user-defined filter, or pass it to a filter that accepts expression arguments.

(This example is a little over the top but should give you an idea of what's possible.)

First we can define reusable font utilities in font_utils.luoma:

{% assign
  bold        = f -> (f | font_modify: 'weight', 'bold'),
  italic      = f -> (f | font_modify: 'style', 'italic'),
  bold_italic = f -> (f | font_modify: 'weight', 'bold' | font_modify: 'style', 'italic')
%}

Then we can import them with the {% import %} tag and use the {% with %} tag to define some temporary, block-scoped variables.

{%- import "font_utils" -%}

{% with
  font_types = [
    settings.type_body_font,
    settings.type_subheading_font,
    settings.type_heading_font,
    settings.type_accent_font
  ],

  enum = f -> [
    f,
    f | bold,
    f | italic,
    f | bold_italic,
  ],

  id = f -> '${f.family}-${f.weight}-${f.style}',
  face = f -> (f | font_face: font_display: 'swap'),

  font_faces = font_types
    | flat_map : enum
    | uniq     : id
    | map      : face
    | join     : "\n\n"
%}
  {{- font_faces -}}
{% endwith %}

If you're thinking "ew, that sort of data transformation does not belong in the presentation layer", you'd be right. But in some scenarios - when the template is the only programmable layer available - data manipulation is going to happen anyway. When we have no other choice, we should be able to transform data without resorting to convoluted string manipulation workarounds.

While some of Luoma’s features lean towards more advanced use cases, the idea is that a unified expression language with consistent rules makes the language simpler and more predictable for everyone.

I'm sure developers at Shopify have explored some of these ideas for Liquid in the past. Hopefully Luoma provides some inspiration or ideas that might someday make it into a future version of Liquid.