I maintain Grape, the Ruby framework for REST-like APIs. 4.0.0 shipped today and it's the fastest yet.

Ruby 4.0.6, single-threaded Benchmark.ips :

+80% without a JIT, +70% with YJIT. It's a micro-benchmark — one tiny JSON endpoint, in-process, no database — so it measures framework overhead and nothing else. Harness is in benchmark/version_throughput if you want to run it.

The biggest single win: helpers were being included into a fresh singleton class on every request, so every request started with a cold method cache. That now happens once, at compile time. TLDR: lot of improvements in terms of memory allocations.

Also new: QUERY (RFC 10008) — safe and idempotent like GET, but the query rides in the request content.

It's a major, so deprecated surface from 3.2 and 3.3 is gone.

Happy to answer questions.

Hello guys, as university student that wants to apply to junior Rails dev, i made project that even you can try.

It works as stock broker portfolio agregator (Trading212 and Etoro), that takes snapshots of current account balance, exchange it to live EUR rate, and sums them into nice looking chart.

Its all happening in background job so you dont need to worry about that.

Then it notifies you each day about the difference summary, or if your API keys are wrong.

i deployed it on my VPS with kamal (easier than i thought) so you can try that yourself (you can set your API keys to read-only, but i respect that prolly noone will put it there).

Also you can try that yourself as i already set it up with Docker for you.

Deployed: https://railsfinancemanager.online/

Github: https://github.com/TheP4trik-tech/Portfolio-Manager

I am open to any critism or ideas :)

I built a gem for fundamental analysis of stocks with the API style of RubyLLM: value objects, BigDecimal figures, nil on missing data, to_h and to_json everywhere.

company = Fundamentalista.company("AAPL")
year = company.financials.latest
year.ratios.roe
year.ratios.cash_conversion_cycle
company.valuation(price: 230).intrinsic_value(growth: 0.06, discount_rate: 0.09)

Providers: SEC EDGAR (free, only needs a User-Agent) and Financial Modeling Prep. Annual, quarterly and TTM periods, 40+ ratios, Piotroski, Altman, Beneish, DCF and reverse DCF, EPV, residual income, WACC, banking and insurance lines, peer comparison with the magic formula, and provenance for every line item back to the XBRL concept and filing.

The EDGAR side is where most of the work went: the concept map is validated over the 500 largest filers with a script in the repo, and 0.6.0 comes from a round of simulated users hitting real filings (derived fourth quarters, multi-currency filers, IFRS tags, filer sign conventions).

There is also a fundamentalista-rails engine with watchlists and snapshots.

Repo: https://github.com/bruno-costanzo/fundamentalista

Gem: https://rubygems.org/gems/fundamentalista

Happy to hear where the ratio definitions disagree with yours.

If memes aren't allowed or frowned upon, please tell me, I made sure the rules allowed it. Also this is satire and I know ruby is much better with parentheses in some situations.

Hey r/ruby,

I wanted to share ruby-utcp, a Ruby implementation of the Universal Tool Calling Protocol (UTCP) 1.1.

The idea is straightforward: describe your tools, their inputs, and how to call them in a UTCP “manual.” The client discovers those tools, makes them searchable, and calls them directly over their native protocols. This gives Ruby apps and AI agents a common interface for working with different services.

Once you’ve registered a manual, usage looks like this:

client.search_tools("weather", limit: 5)

result = client.call_tool(
  "weather_service.get_weather",
  location: "Warsaw"
)

A few things it supports:

• 12 transports, including HTTP, CLI, WebSocket, gRPC, GraphQL, and MCP.
• OpenAPI and Swagger discovery, so existing API descriptions can become tools.
• Streaming through Ruby enumerators.
• Code Mode, which lets you chain tool calls and transform their results using a constrained Ruby subset with execution limits.
• Protocol restrictions by default: a manual discovered over HTTP needs explicit permission to expose CLI tools.

It’s MIT licensed, and the repository includes examples for every transport. The core supports Ruby 2.6+; gRPC and WebRTC have optional dependencies, with the default WebRTC backend requiring Ruby 3.1+.

I’d appreciate feedback on the Ruby API and examples. If you’re building agents or automation in Ruby, what would make this useful in your workflow?

I recently had a nice chat with Erroll Schmidt on the Technology for Humans podcast about the past, present and future of JRuby... including some myth debunking that might help Ruby folks look past the "J" to the amazing tech underneath. Check out the video and let me know if you have questions!

Watch two talks so far, the audio quality this year is absolute garbage (as if they recorded it on a phone that was located directly next to a speaker that was way too loud). I hope I was just unlucky and the rest is better.

in RubyGems

I built this gem based on my experience of implementing very similar (perhaps even identical) services in extremely different business domains. For example, I currently work in a Payroll SaaS, which calculates payslips using "concepts" (which are basically calculated formulas at a certain point in time, for example, a concept may be "health insurance discount", "performance bonus"). I supported a system like that when I worked at a delivery app, for supporting dynamic checkouts. I imagine you can use the same to calculate the premiums in a car insurance calculation, and a plethora of other domains.

The idea is simple; you mix the gem into your models

class Employee < ApplicationRecord
  include ActsAsCalculator::Calculable
end

Then, you have two classes, ActsAsCalculator::Formula + ActsAsCalculator::FormulaVersion , so each formula version is accesible from a slice window (effective_from | effective_to),

formula = ActsAsCalculator::Formula.create!(key: "monthly_taxes", scope: "payroll")
puts employee.salary
5000.0
ActsAsCalculator::PublishFormulaVersion.(
  formula: formula,
  expression: "salary * 0.22",
  effective_from: Date.new(2026, 1, 1),
  effective_to:   Date.new(2026, 6, 30),
  variables: [{ name: "salary", source_type: "attribute" }]
)

You can now use these formulas to discount a tax from the employee salary. Important to note, formulas are parsed and calculated through Dentaku, which long ago already solved safe logic eval.

employee = Employee.last

result = employee.calculate(
  :monthly_taxes,
  as_of: Date.new(2026, 3, 15)
)


puts result.inspect

#<data ActsAsCalculator::Result value=0.11e4, breakdown={:expression=>"salary * 0.22", :inputs=>{"salary"=>0.5e4}, :value=>0.11e4}, formula_version=#<ActsAsCalculator::FormulaVersion id: 17, formula_id: 10, version_number: 6, expression: "salary * 0.22", effective_from: "2026-01-01", effective_to: "2026-06-30", status: "active", change_note: nil, created_at: "2026-09-01 01:26:15.204120000 +0000", updated_at: "2026-09-01 01:26:15.204120000 +0000">, as_of=Sun, 15 Mar 2026>
puts result.value
1100.0

(ActsAsCalculator::Result is a value object)

Then, a key feature, you can also template the result using sandboxed Liquid (this templating is functional but not yet feature-complete, I have a small roadmap still planned for this)

template = ActsAsCalculator::Template.create!(
  key: "payslip", scope: "payroll", format: "text",
  body: "Gross: {{ result.value | currency }}\n }}"
)

employee.render(:payslip, calculate: :monthly_taxes, as_of: Date.today)

=> "Gross: 1,100.00 "

The engine also has support (experimental for now) for JSON imports, and exports are still on the roadmap.

The engine also supports exposing HTTP endpoints for managing formulas/templates, but this is disabled by default — you opt in via a config flag before mounting it.ActsAsCalculator.configure { |c| c.enable_api = true }

The gem has also a supporting frontend engine, acts_as_calculator_editor, built upon Hotwire and Lexxy.

A couple of notes:

the base gem acts_as_calculator is human-made, written from my experience of building from scratch an identical but way-less generic production-used implementation of this, so most of the architecture is already proven at scale. I used AI to add a couple helper methods, to do code review, to complete documentation and to write several unit tests. The supporting gem acts_as_calculator_editor was fully built with an AI agentic workflow.

I haven't yet published the 1.0.0 version since I still have a key feature to implement (chaineable formulas, so a formula is able to call other formulas directly).

The gem also exposes a lot of apportionment, distribution and allocation helper strategies (:proportional, :equal, :largest_remainder), which are one of the main motivations I had for creating this gem. In the v1 version, I will add comprehensive api docs for them.

The gem is also intended to be used with ActiveRecord, but should be framework agnostic for most things.

If you have any feedback to give about the gem and the idea, please leave a comment. This is my first experience building something for the OSS space that has given me so much, so feel free to contribute and criticize.

Here’s the SolidQueue batches 2.5 year architectural journey, filled with O(n^2) algorithms, hot row contention, excessive jobs, and much in between.

There’s a strong chance you’ll learn a thing or two - I certainly did 😮‍💨

I'm a Ruby engineer in Japan, and I recently started participating in open source (OSS) activities.

With the goal of understanding what perspectives other engineers have, I turned on notifications for several GitHub repositories so I could receive contributions in real time.
Then I got notifications that one particular individual had created nearly 100 PRs in an hour across several repositories.

When I checked, all the commit messages were written using the exact same template, and the wording was extremely mechanical.
They were also contributing to multiple repositories in different languages at the same time, so I believe this was most likely done using AI combined with automation tools.

What I want to know is whether this kind of behavior is welcomed within the OSS community.

This is just my personal opinion, but I see the OSS community as a very fragile kind of organization, one that is held together by human elements — the goodwill, trust, and motivation of its participants.
It feels to me like this kind of behavior could damage the relationship between the maintainers who manage OSS projects and the members who contribute to them, and that makes me feel quite uneasy.