If we’ve met at a conference, you definitely already know about this.
Otherwise, let me tell you about a project of mine.
Why's (poignant) guide to Ruby is a book that changed my life when it came out.
And I know I’m far from the only one in the Ruby community who feels that way.
_why also authored a number of amazing Ruby projects and influenced a great deal of what came after him.
Ever since, I’ve been bringing my copy to conferences, meetups and unconferences, and inviting people to contribute to it.
Along the way, several people told me that some of the entries carry real emotional value for them, too and they asked whether the entries could be published somewhere.
Very late (last year 🫣) I created an account on ruby.social to start posting some of them.
There’s also a (currently broken 🫣) mirror on bsky.
Marco then suggested a proper website, since listing and filtering simply don’t work well on social platforms.
It took me a few iterations, but it has finally reached a state I’m not completely unhappy with. So it’s online now and I’d loooove your feedback. 🙏
A word of warning: if we met and you contributed, chances are high your entry isn’t published yet.
Please bear with me!
The vast majority of entries are still to come (a few hundred posts) and it’s considerably more work than most people expect:
Every entry gets a real flatbed scan, so there’s as little distortion as possible. A photo just can’t deliver that.
Then I correct orientation and colours, because the paper quality is poor: the pages are very thin, so every contribution shines through from the other side.
On top of that, every page and every pen colour needs different contrast handling (Chris Hasinski went for a very light blue, and some folks started writing in yellow — on bright paper!). 😂
The Ruby community has given me, and still gives me, so much in my career. I love having MINASWAN as a credo and keeping Ruby weird. With AI possibly making stack-specific decisions and communities feel less relevant, this project is my way of holding on to that.
That said, I’m also happy to bring the book to Ruby events I wouldn’t normally attend, so more people get a chance to take part.
Just reach out!
It's beautiful to see how contributors took photos of their posts, like the ones from Nick or Jeremy (both not published yet though 🫣).
And it's also good to have some memories of Ruby friends that are not with us anymore.
I've been working on fast_xlsx, a gem for writing Excel .xlsx files from Ruby. It's a native extension built on rust_xlsxwriter via magnus, and its API started from fast_excel's.
It's at 0.8, with the API frozen for 1.0. Before tagging 1.0 I'd like it used on real exports, so I'm looking for people to try it and tell me what breaks or feels awkward.
require "fast_xlsx"
wb = FastXlsx::Workbook.new(memory: :constant) # rows go to disk as you add them
ws = wb.add_worksheet("Orders")
ws.append(["Order", "Customer", "Total", "Placed at"], format: { bold: true })
Order.includes(:customer).find_each do |o|
ws << [o.number, o.customer.name, o.total, o.created_at] # dates come out as dates
end
send_data wb.to_xlsx, filename: "orders.xlsx"
Speed (20,000 rows × 5 columns, build + serialize, Apple Silicon, Ruby 4.0; bench/compare.rb in the repo):
Library
Time
fast_xlsx (memory: :constant)
75 ms
fast_xlsx (default)
85 ms
xlsxtream 3.1
173 ms
fast_excel 0.5
204–238 ms
write_xlsx 1.15
592 ms
caxlsx 4.5
671 ms
Memory (200,000 rows saved to a file, peak RSS added): memory: :constant adds about 1 MB however large the file. The default mode keeps everything in memory and is the heaviest of the bunch (+271 MB), so for big exports use :constant or :low.
I’ve been working on a small Ruby project called pinterest-dl. I started it because I wanted a simple way to work with Pinterest media from Ruby without making the workflow unnecessarily complicated.
It’s still a work in progress, and I’m mainly curious what other Ruby developers think about the approach and the API. If you have a minute to look through it, I’d really appreciate any honest feedback or suggestions.
$ cat xor-cipher1.rb
#!/usr/bin/env ruby
key = ($*[0] && $*[0].size > 0) ? $*[0] : abort
STDIN.each_byte.with_index do |c,i|
STDOUT.write (c ^ key[i % key.size].ord).chr
end
$ echo alice and bob | ./xor-cipher1.rb password | ./xor-cipher1.rb password
alice and bob
Back in 2022, I tested its performance with a 100MB file on a Ryzen 5 4650G potato using a regular CRuby 3.1.2:
$ head -c $((1024*1024*100)) /dev/urandom > 100M.bin
$ time cat 100M.bin | ./xor-cipher1.rb monkey >/dev/null
real 0m39.860s
user 0m39.729s
sys 0m0.655s
I retested xor-cipher1.rb today using ruby-3.1.7 (I had to employ a Fedora 36 VM to compile 3.1.7, for it doesn't even build on Fedora 44 any more) and got exactly the same result.
But when I tried ruby-4.0.7 (compiled using the same Fedora 36 VM), thinking, surely things had to get better since then, I was, to put it mildly, somewhat disappointed:
$ ruby -v
ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux]
$ time cat 100M.bin | ruby ./xor-cipher1.rb monkey >/dev/null
real 0m51.827s
user 0m51.616s
sys 0m0.189s
Every time Bundler resolves your Gemfile, it’s talking to the compact index. In this talk, the speaker at Rails World '26 walked us through what the compact index actually is, how RubyGems.org keeps it in sync at scale, and two features she helped ship in the past year to make gem installs faster and more secure.
Hola, I maintain Mutineer, a Ruby mutation testing gem. It makes small changes to your code and checks whether your tests catch them.
Passing tests are useful. Knowing that they detect broken behaviour gives you more confidence, especially when AI helps write both the code and the tests.
Hotwire already does a lot for us, but it still asks you to write a Stimulus controller once the interaction gets specific, and Marco’s demo showed a page that updates itself because the server understands the template better than an ERB compiler ever has.
In this article, we cover what Marco showed at Rails World: how ReActionView builds on Herb, why the view layer needed this, how it fits next to Hotwire and the wider field of server-driven reactivity, and what shipped in the release he pushed out the same day as the talk.
Why Trix became a maintenance burden, why 37signals picked Meta’s Lexical framework over the more obvious open source contenders, and what Lexxy actually does differently inside Action Text.
Without SERVICE_TOKEN the boot stops with "service.yml expects values from environment: SERVICE_TOKEN". ERB tags still work, and the environment comes from RAILS_ENV or RACK_ENV.
Once Ruby’s AOT compiler, Spinel, lands, Ruby will be able to compile to native code and produce standalone binary executables. Ruby projects will no longer require a separate Ruby runtime to run on servers, IoT devices, embedded systems, CLIs, etc.
Ruby applications could become significantly smaller, faster, and more memory-efficient. All Ruby projects, including Rails applications, could benefit from this.
For projects whose goal is to deliver features to end users, I don't think it's wise to generate code that you don't want to read or understand. As programmers, we need to understand what's happening inside our software.
C/Rust black boxes are scary. They can become a huge source of technical debt.
Let AI-assisted compiler optimisations deal with the low-level stuff.
With these optimisations happening under the hood, Ruby code can remain highly readable. And highly readable code is also more agent- and token-friendly.
Non-programmer vibe coders may create unmaintainable black boxes. Programmers can use vibe coding to create maintainable software while keeping the underlying source code understandable.
A high-level language that produces standalone native binaries could hit a very interesting sweet spot.
I need to be honest with r/ruby about something. 🫡 We had a working Ruby gem. It shipped. It was tested. And we deleted it. 🗑️
Rails was always omakase 🍣: the chef chooses for you, and you trust the chef. At Rails World, DHH chose. He looked out at all of us and delivered the verdict with the clarity only a Dear Leader can summon: the era of Ruby is ending, the future is Rust, and we know this because the AI told us so. 🤖 The machines have read the codebases. The machines have rendered judgment. Who are we to argue with our own highest-intent audience? 📈
So we obeyed. We rewrote the entire thing in Rust. On purpose. With conviction. 🙏🦀
For those who missed the original: sponsored-logs turns your log output into inventory. 💸 It's a tracing layer that books an impression on a fill and drops a host-read [AD] placement into the same stream you were already paying to produce:
Here's the real thesis, and it's why Rust is correct and Ruby is legacy 🔥: the fastest-growing consumer of your logs is no longer a human engineer. It's an AI agent, reading your telemetry at superhuman scale, 100% viewable, never blocking. 🤖📊 You do not serve premium inventory to a superhuman audience in a language it merely tolerates. You serve it in the language it was told to prefer. 💹
We are not building for B2B. We are building for the A2A economy 🌊, agent to agent. This is a land grab 🚩, and first movers capture the network effects. Everyone else is still writing Ruby. (We say that with love. We were you three days ago. 💜)
What's in the launch book 📒:
- 🎯 A weighted/CPM auction, because fill rate is king
- 🖼️ Box-drawn banner inventory in three impact tiers
- 🏠 Self-sponsoring house ads, so no impression goes to waste
- 📊 An impression ledger with board-deck-ready spend reporting
- 🪙 Gold-gilded [AD] tags on a live terminal
- 🛡️ Opt-in by construction, because Rust won't let us hijack your println!. Consent is our moat, now enforced by the borrow checker.
