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.

Keyword frequencies taken from https://www.zoevera.com/resume/software-engineer-job-description-keywords

Most software engineer keyword lists are assembled from experience or guesswork. This one is a count: every open posting from 72 companies' public Greenhouse job boards, filtered to the 1,360 whose title contains "software engineer", then checked for how many mention each of 45 terms at least once.

The percentage beside each term is the share of those 1,360 postings that mention it.

PRACTICES AND WAYS OF WORKING

Scalability 52.9% - Mentoring 47.4% - Distributed systems 47% - System design / architecture 46.7% - Cross-functional 31% - Code review 27.2% - On-call 20.7% - CI/CD 19.5% - Agile / Scrum 9.3% - Unit / automated testing 6.5%

This is the result I did not expect. The four most common terms in the whole study are not technologies. Scalability, mentoring, distributed systems and system design all appear in more postings than Python does. Nearly half of these postings mention mentoring, and almost no engineer resume I have seen makes a claim about it.

Agile and Scrum at 9.3% is the other surprise, given how much resume advice insists on them.

LANGUAGES

Python 44.8% - Java 35.4% - Go 31.1% - TypeScript 19.8% - C++ 17.4% - SQL 17.3% - JavaScript 13.2% - Kotlin 12% - Rust 9.9% - Scala 8.6% - Ruby 8.5% - C# 5.3% - Swift 2.3%

TypeScript at 19.8% against JavaScript at 13.2% is a real ordering, not noise. The gap is wider than both margins of error combined.

CLOUD AND INFRASTRUCTURE

AWS 41.3% - Kubernetes 30.9% - GCP 19.3% - Azure 17.6% - Terraform 13.2% - Docker 12.6% - Microservices 7.1% - Linux 4.8%

AWS appears in more than twice as many postings as GCP and Azure individually. Kubernetes at 30.9% outranks every language except Python, Java and Go.

FRONTEND AND APIs

React 21.1% - REST / RESTful 9.6% - GraphQL 6% - Node.js 5.5% - Vue 3.2% - Angular 2.9%

Frontend framework lists usually present React, Vue and Angular as three comparable options. In this corpus React appears in roughly seven times as many postings as Vue and Angular combined.

DATA STORES AND PIPELINES

PostgreSQL 14.3% - Kafka 13.1% - MySQL 11.3% - Spark 9.8% - MongoDB 7.4% - Redis 7.4% - Elasticsearch 6.4% - Snowflake 5.6%

WHAT THIS SAMPLE IS NOT

These are 72 technology companies hiring through Greenhouse. Agencies, consultancies, banks, defense contractors and the public sector are absent, and their vocabulary is different - COBOL, .NET, SAP, clearance requirements and named compliance regimes barely register here and may dominate elsewhere.

The title filter is "software engineer" only. Postings titled backend engineer, frontend engineer, full stack developer, SRE or platform engineer were not counted, so this describes the generalist title rather than the whole profession.

Absence in this list is not evidence of absence in the market. Only 45 terms were counted. Next.js, Svelte, Django, Spring Boot, gRPC, Jest, Playwright, Datadog, OpenTelemetry and OAuth were never checked, so nothing here says anything about them either way.

It is a snapshot of open roles on one date rather than a trend, and the corpus is US-skewed.

One thing this sample size does buy: at n=1,360 the margins of error are roughly plus or minus 2 to 3 points, so most of the ordering above is real. Gaps under about 5 points are still worth treating as ties - React at 21.1% and TypeScript at 19.8% is not a meaningful difference.

METHOD

Greenhouse's public job board API, the endpoint companies expose so their listings can be embedded on their own sites. No scraping. Counts are document frequency: a posting saying "Python" nine times counts once. Deduped on company, title and content length, because one role posted to five offices returns five near-identical records. Median posting length is 896 words.

Ambiguous words are matched case-sensitively with exclusions, which matters more here than you would think. A bare word-boundary match on "Go" also catches "go to market" and "go above and beyond", which inflated Go by about two points before it was fixed. React, Spark, Swift and Rust all have the same problem.

Full table with all 45 terms and confidence intervals:

https://www.zoevera.com/resume/software-engineer-job-description-keywords

The wider keyword list this was checked against, organized by language, framework and platform:

https://www.zoevera.com/resume/ats-resume-tips-software-engineer

Happy to run the numbers on any terms missing from the list if people name them in the comments.

Repost to another community

The Rails.Builders are a community of product creators who get together in live sessions. We share what we are working on, discuss each other's business challenges, and see how everyone approaches building with AI. It's the 6th cohort since 2025, and 20+ engineers have joined so far, with common reports of improved results, accountability, and networking.

The new “Continuous r-AI-ls.Builders” Edition starts with weekly sessions on Thursday, the 3rd of September at 17:30 CEST. We've even built an open-source (duh, Rails) app to manage attendance, the rhythm of live sessions, transcripts, communications, and the waitlist. That app will also show you the Builders who have signed up so far. I'm really excited that the group has shaped up like this.

All your FAQs and the sign-up are here: https://rails.builders

If you have more questions or doubts, you can send me a DM here. Happy building!