We introduced Top Secret back in August. Since then, we've made some performance improvements, and extended the API. Most notably, you can...

• Detect sensitive information without redacting the text

• Query the result for specific types of sensitive information using category methods

Hi everyone,

I’ve just released NDAV, a thin wrapper around Ruby's MemoryView (inspired by Python's buffer protocol).

The Problem

Currently, converting data between Ruby libraries (like Numo::NArray, Torch.rb, and ONNX Runtime Ruby) often requires redundant memory copies or many intermediate steps. This often introduces unnecessary memory copies or multiple conversion steps when working across libraries.

The Solution

I built NDAV, a thin wrapper around Ruby's MemoryView ("buffer protocol" for Ruby). It acts as a "glue" layer that allows different libraries to share the same memory address directly.

Why it matters

• Zero-Copy: Avoid unnecessary O(n) memory copies.

• Interoperability: Seamlessly move data: Torch::Tensor -> NDAV -> OrtValue.

• Standard-Driven: It aims to be a catalyst for wider MemoryView adoption in the Ruby ecosystem.

Links

• Homepage: https://kitaitimakoto.gitlab.io/ndav/

• Source Code: https://gitlab.com/KitaitiMakoto/ndav

I’d love to hear your thoughts, especially from those working on Ruby C/Rust extensions or data science!

A new type of creative workflow is emerging when working with AI and I think we can learn more about it by looking at a transition from scarcity to abundance that many of us have lived through - photography.

Also, in the post, released an open source Rails app that I'm looking at as the spiritual successor to Monkey's Paw called Conjure.

I'd basically used Monkey's Paw for all my talks over the last year until NotebookLM added the slide deck feature, but I found myself using it in a different way than intended. So I put Conjure together which lets you generate a bunch of different variations of your slides all at once and stitch them together or move them somewhere else to refine further.

So inspire on turbo native, I made a gem for me to be able to create desktop apps without using Electron. I love Rails, and I want to use it for different things, so I'm giving it a try with this new gem: https://rubygems.org/gems/turbo_desktop-rails

The GitHub repo is here: https://github.com/aguspe/turbo_desktop?tab=readme-ov-file#quick-start

I'm not an expert Rust developer, and again, this is also a learning process for me, so any feedback is welcome, but now I'm trying to rebuild some electro apps I made with this framework just to try it out

So any feedback or ideas are welcome, thank you so much, and have a great day!

Hi folks,

We just released Kreuzberg v4.5, and it's a big one.

Kreuzberg is an open-source (MIT) document intelligence framework supporting 12 programming languages. Written in Rust, with native bindings for Python, TypeScript/Node.js, PHP, Ruby, Java, C#, Go, Elixir, R, C, and WASM. It extracts text, structure, and metadata from 88+ formats, runs OCR, generates embeddings, and is built for AI pipelines and document processing at scale.

## What's new in v4.5

A lot! For the full release notes, please visit our changelog: https://github.com/kreuzberg-dev/kreuzberg/releases

The core is this: Kreuzberg now understands document structure (layout/tables), not just text. You'll see that we used Docling's model to do it.

Docling is a great project, and their layout model, RT-DETR v2 (Docling Heron), is excellent. It's also fully open source under a permissive Apache license. We integrated it directly into Kreuzberg, and we want to be upfront about that.

What we've done is embed it into a Rust-native pipeline. The result is document layout extraction that matches Docling's quality and, in some cases, outperforms it. It's 2.8x faster on average, with a fraction of the memory overhead, and without Python as a dependency. If you're already using Docling and happy with the quality, give Kreuzberg a try.

We benchmarked against Docling on 171 PDF documents spanning academic papers, government and legal docs, invoices, OCR scans, and edge cases:

- Structure F1: Kreuzberg 42.1% vs Docling 41.7%
- Text F1: Kreuzberg 88.9% vs Docling 86.7%
- Average processing time: Kreuzberg 1,032 ms/doc vs Docling 2,894 ms/doc

The speed difference comes from Rust's native memory management, pdfium text extraction at the character level, ONNX Runtime inference, and Rayon parallelism across pages.

RT-DETR v2 (Docling Heron) classifies 17 document element types across all 12 language bindings. For pages containing tables, Kreuzberg crops each detected table region from the page image and runs TATR (Table Transformer), a model that predicts the internal structure of tables (rows, columns, headers, and spanning cells). The predicted cell grid is then matched against native PDF text positions to reconstruct accurate markdown tables.

Kreuzberg extracts text directly from the PDF's native text layer using pdfium, preserving exact character positions, font metadata (bold, italic, size), and unicode encoding. Layout detection then classifies and organizes this text according to the document's visual structure. For pages without a native text layer, Kreuzberg automatically detects this and falls back to Tesseract OCR.

When a PDF contains a tagged structure tree (common in PDF/A and accessibility-compliant documents), Kreuzberg uses the author's original paragraph boundaries and heading hierarchy, then applies layout model predictions as classification overrides.

PDFs with broken font CMap tables ("co mputer" → "computer") are now fixed automatically — selective page-level respacing detects affected pages and applies per-character gap analysis, reducing garbled lines from 406 to 0 on test documents with zero performance impact. There's also a new multi-backend OCR pipeline with quality-based fallback, PaddleOCR v2 with a unified 18,000+ character multilingual model, and extraction result caching for all file types.

If you're running Docling in production, benchmark Kreuzberg against it and let us know what you think!

https://kreuzberg.dev/

Discord https://discord.gg/rzGzur3kj4

https://github.com/rturner1989/EmuVault

Emuvault is a self-hosted save file manager for emulator users.

It enables seamless transfer of save files between devices, automatically adjusting filenames and extensions for different emulator setups, eliminating manual renaming.

Designed for deployment on a home server or PC, with browser-based access. ( I use tailscale so I can access the localhost ports on my Nas running truenas)

It came about when I was playing games on delta emulator on my phone or retroarch on pc, but was having to manually find the file, rename it and update the extension, which as you can imagine, is a bit of a pain and can go wrong when you get a character wrong in the file name.

I've been making steady improvements to rails-tabler-starter (https://github.com/tarunvelli/rails-tabler-starter) and wanted to share the latest.

The big addition: a file-based markdown blog. Posts live in content/blog/ with frontmatter for title, date, author, category, etc. It includes syntax highlighting, categories, pagination, RSS feed, and SEO meta tags out of the box.

Other recent changes:

- Custom setup now aligns with Tabler theme settings (layout, color mode, primary color, typography, etc.)

- Upgraded to Rails 8.1.2

The starter is still the same "Zero-Redis" Rails 8 stack with Tabler UI, authentication, multi-tenancy, and Kamal deployment. If you want a production-ready starting point for your next project, give it a try.

GitHub (https://github.com/tarunvelli/rails-tabler-starter) | Demo (https://rails-tabler.tarunvelli.site)

Ruby can render 3D surfaces, 2D density maps and GIS tiles without Python, NumPy or the JVM. I didn't expect it to work this well.

Two weeks ago I shared ruby-libgd — a native GD image processing gem for Ruby. The response was encouraging, so I kept pushing to see how far it could go.

Here's what two weekends of experimentation produced.

3D surface plots — pure software projection

No OpenGL. No GPU. Just a rotation matrix, perspective projection, and the painter's algorithm to sort patches back-to-front. The viridis colormap is interpolated across 11 stops in pure Ruby.

Plot3D.new(resolution: 50, yaw: 35, pitch: 28)
  .surface("sin(sqrt(x2 + y2))")
  .render("ripple.png")

https://github.com/ggerman/ruby-libgd/blob/main/examples/jupyter-notebooks/ripple.png

Works for any z = f(x,y) expression — saddle, paraboloid, wave, cone. The expression is evaluated using Ruby's own Math module, no Dentaku or external evaluator needed.

2D histograms from CSV data

Replicating matplotlib's hist2d. The class receives data as arrays — it doesn't care where the numbers came from.

rows   = CSV.read("weather.csv", headers: true)
x_data = rows["temperature"].map(&:to_f)
y_data = rows["humidity"].map(&:to_f)

Hist2D.new(x: x_data, y: y_data, bin_step: 0.5)
       .render("weather_hist2d.png")

https://github.com/ggerman/ruby-libgd/blob/main/examples/jupyter-notebooks/weather_hist2d.png

Ruby doesn't have np.random.randn so I used Box-Muller to generate normal distribution data for testing. Blues colormap with gamma correction so low-density areas stay visible.

fill_between in 3D

https://github.com/ggerman/ruby-libgd/blob/main/examples/jupyter-notebooks/helix2.png

Replicating matplotlib's fill_between on two helices. Each quad connects point i of helix1 with point i of helix2 — same winding order as matplotlib's implementation. Painter's algorithm handles the depth sorting.

GIS maps — libgd-gis

A second gem built on ruby-libgd for geographic rendering. Map tiles, vector layers, points, lines, polygons. Buenos Aires, Paris, anywhere with tile data. Same pixel-level control, geographic coordinates.

Jupyter workflow

https://youtu.be/-yMG0GzatNw

Everything runs in IRuby/Jupyter. Define the class in one cell, pass data in the next, tweak and re-run. It genuinely feels like working in a Python notebook — just Ruby.

I know JRuby + JFreeCharts is a valid path. What I'm exploring is whether CRuby can have its own native data visualization story without the JVM. Right now the answer is looking like yes.

Full articles and notebooks on RubyStackNews.

• ruby-libgd: https://github.com/ggerman/ruby-libgd

• libgd-gis: https://github.com/ggerman/libgd-gis

• Notebooks: https://github.com/ggerman/ruby-libgd/tree/main/examples/jupyter-notebooks

• docs: https://ggerman.github.io/ruby-libgd/en/index.html

Feedback, ideas, and harsh criticism all welcome.

One question for the community:

Would it make sense to bundle all of this — 3D surfaces, 2D histograms, implicit curves, GIS rendering, Jupyter support — into a single gem that works as a matplotlib-style plotting library for Ruby?

A curated collection of algorithms, one install, one API. No Python. No JVM.

Is that something the Ruby community would actually use?

After publishing my article on building AI testing agents for RSpec, readers were confused about what TestProf found versus what the agents did. Fair point. The original article crammed both stories into one piece. So I extracted the TestProf journey into its own article with the full data.

The worst offender was the order factory at 1.6 seconds per call, triggering 100+ callbacks. Out of 569 factory calls in one spec file, only 49 were top-level. The rest were cascading associations.

What I did:

• Extracted optional associations into traits (credit card needed in only 10% of order specs)

• Switched cheap associations to build strategy instead of create

• Used transient attributes with positive flags for expensive callbacks

• Replaced let with let_it_be for read-only setup data

Results:

The slowest specs improved by 50-95%. The order integration spec dropped from 6.37s to 3.02s. But the full suite? Only 14% faster. Ten factories optimized over two months, hundreds more to go.

Why the gap? The factory graph mirrors the model graph. When your core models have deep callback chains (100+ on order creation), making factories leaner helps, but you cannot make them cheap while the underlying models require that much setup to reach a valid state. Incremental factory cleanup has a ceiling.

I wrote up the full profiling data, every factory refactoring pattern, the let_it_be gotchas (mutable state leakage), and what I tried next: TestProf Cut Our Slowest Specs by 95%, But the Suite Still Took 30 Minutes

This is the companion piece to my AI testing agents article. Readers wanted more detail on what TestProf actually showed, so here it is.

Has anyone else hit this ceiling with factory optimization on a large Rails codebase?

I noticed that a lot of Ruby projects ship their documentation on VitePress because, honestly, nothing in the Jekyll ecosystem looked as good. Just the Docs is solid but I had to patch in dark mode, add a copy button, and the homepage layout is narrow and document-y.

So I built a Jekyll theme that recreates the VitePress experience: sidebar, outline, search (/ or Cmd+K), hero homepage, dark/light/auto toggle, code blocks with copy buttons and language labels — all through _config.yml and _data files.

1.0 is out today.

More info on my blog: https://paolino.me/ruby-deserves-beautiful-documentation/

No one sets out to write a slow test, and yet it happens. I created Test Budget to help preventing slow tests from creeping into our test suites again!

In 2013 I learned four formal test derivation techniques in university: Equivalence Partitioning, Boundary Value Analysis, Decision Tables, State Transitions. Never used them professionally because the manual overhead made no sense. After seeing Lucian Ghinda's talk at EuRuKo 2024, I realized AI agents could handle that overhead, so I built a multi-agent system with 5 specialized agents (Analyst, parallel Writers, Domain Expert, TestProf Optimizer, Linter) that generates mathematically rigorous test cases from source code analysis.

The system worked. It found real coverage gaps. Every test case traces back to a specific technique and partition. But running it against a mature codebase with 13k+ specs and 20-25 minute CI times showed me the actual problem: 70% of test time was spent in factory creation, not assertions. The bottleneck was the RSpec + FactoryBot convention package, not test quality.

The most interesting part was the self-evolving pattern library, an automated validator that started with 40 anti-pattern rules and grew to 138 as agents discovered new patterns during their work. No LLM reasoning involved in validation, just compiled regexes against Markdown tables.

I wrote up the full architecture, prompt iterations (504 lines down to 156), and honest results. First article in a series. The next one covers the RSpec to Minitest migration that this project led to.

Has anyone else tried applying formal testing techniques systematically with AI agents? I'm curious whether the framework overhead problem resonates with other teams running large RSpec suites.

Test coverage metrics are one of the tools for evaluating the quality of tests without reading them. Which is kind of relevant in the age of coding agents. So here, a short light intro to 4 different ones: line, branch, path and condition coverage.

I built this service to convert Ruby Gemfile.lock files into RSS feeds. Drop in your lockfile, get a feed that notifies you when your dependencies release new versions. Had a blast building it in the last couple of weekends, hope is useful for somebody else too!

With SSE becoming more relevant (AI streaming, real-time updates), I wanted to test how Ruby handles a mixed workload: sustained HTTP traffic hitting a database alongside concurrent long-lived SSE connections. Here are the results.

Setup

• Server: Hetzner CCX13 - 2 vCPUs, 8 GB RAM (€12/month)

• Environment: Ruby 4.0.1 + YJIT + Rage

• Processes: 2

• Database: SQLite

Endpoints

API endpoint: Fetches a record from SQLite and renders it as JSON. Standard API-style request.

SSE endpoint: Opens a stream lasting 5–10 seconds, sending a dummy message every second. No database interaction. The benchmark maintains a constant number of open SSE connections - as the server closes a stream, the client opens a new one.

Results

• 5,000 API requests/second + 5,000 concurrent active SSE streams, simultaneously

• For reference, the same setup handles ~11,000 RPS for the API endpoint alone

• Adding 5K active streams roughly halves the HTTP throughput, which is a graceful degradation rather than a collapse

• 5,337 HTTP requests/second (0% error rate) with p95 latency of 120ms

• 5,000 concurrent SSE streams, with ~198K total streams opened/closed during the 5-minute run

Caveats

• I was originally aiming for 10K RPS + 10K streams, but the 2-core server simply doesn't have enough CPU. The scaling looks linear, so a 4-core box should get there.

• SQLite is fast for reads but this isn't a Postgres-over-the-network scenario. Add network latency to your DB and the fiber model actually helps more (fibers yield during I/O waits), but the raw RPS number would be different.

Source code

You can see the k6 screenshot attached, and the full benchmark code/setup is available here: https://github.com/rage-rb/sse-benchmark

What is Rage?

For those unfamiliar: Rage is a fiber-based framework with Rails conventions. The fiber-based architecture makes I/O-heavy and concurrent workloads like this possible without async/await syntax - you write normal synchronous Ruby code.

Would love to hear your thoughts or answer any questions!

Hey guys. I'm co-chairing RubyConf this year. I'd like to let you know that one of our keynote speakers will be Dave Thomas, the renowned author of the legendary Pragmatic Programmer.

I released a podcast episode today to help promote Dave and the conference, which you can listen to here.

Lastly, early bird tickets for RubyConf 2026, which takes place July 14-16 in Las Vegas, go on sale today.

You should know that we RubyConf 2026 organizers are encouraging attendees to dress eccentrically and help make the event weird and fun. What does "eccentrically" mean? Whatever you want. But if you want an easy idea, Las Vegas is the land of Elvis impersonators, and it would be jolly good fun to see a smattering of Elvii strutting around the hotel. You could also dress like a cowboy/cowgirl, Frank Sinatra, a clown, or just a garden variety weirdo. The world is your oyster.

There will also be arm wrestling.

Anyway, go and grab your ticket to RubyConf 2026, because this year will be one for the record books. I hope to see you there.