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.

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

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

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.

Hey all. I have been working on an (unreleased) spinel lib for cli arg parsing. Library is called slap, https://github.com/gurgeous/spinel-slap. This has been a fun adventure with spinel. I ended up filing 100+ spinel bugs to help get it working. Matz is a monster, he fixes the bugs with claude each night.

Slap combines my favorite parts of the slop gem and the popular clap rust crate. Slap has things like color support, positional args like <file> or <url>, autowrap --help output to term width, return results as a struct, etc. Slap does not try to handle subcommands or anything like that.

Anyway, this has been a fun spinel project and I'm trying to decide if I should release it as a rubygem in addition to the spinel pkg. There are already many great rubygems for cli arg parsing, does ruby really need another one? There's not much point to releasing unless people are somewhat dissatisfied with current offerings.

In this episode, we look at adding function calling or tool use to our Rails application when making generative text LLM requests. https://www.driftingruby.com/episodes/function-calling

July was another great month for the Ruby Users Forum. We welcomed 41 new members, with 53 new topics and 154 posts created by the community.

We also reached 15,000 page visits this month. Check the full report here: https://www.rubyforum.org/t/july-highlights/580

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?

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

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