Hi Reddit! 👋

I'm Hamachang, a software engineer from Japan. 😎

I've been working on a retro-inspired operating system for the Cardputer ADV called AREA 512.

It's built around FemtoRuby, a lightweight subset of Ruby designed for embedded systems.

With AREA 512, you can write Ruby code directly on the Cardputer, compile it, and run it—all on the device itself. That means you can build applications for the hardware without ever leaving the hardware.

It also comes with several built-in applications, including games and small productivity tools, so you can start exploring right away. 🤖

The project is open source on GitHub. If it looks interesting, even giving it a ⭐ would mean a lot to me!

https://github.com/engneer-hamachan/area512

AREA 512 aims to capture the spirit of classic operating systems, so I'd also love contributions from anyone who shares that passion.

Thanks for reading! ✨

See you around! 🚄

Logseq stores everything as plain .md files, but if you ever open one of those files directly on iOS (from Files, iCloud, Dropbox, a backup, etc.) you just get raw text. I built a small viewer to read them rendered on a phone.

Md Preview:

• Renders GitHub-Flavored Markdown — headings, tables, task lists, footnotes

• Code blocks with syntax highlighting, plus LaTeX math and Mermaid diagrams

• Opens .md / .markdown / .mdx / .rmd / .qmd from Files or the Share Sheet

• 100% on-device — no account, no uploads, no ads, no subscriptions

Free on the App Store: https://apps.apple.com/app/id6760341080

Details: https://markdown.cybergame.ai/

Not a Logseq replacement at all — just a quick way to read loose .md files when you're away from the desktop app. Curious how you all read your graph on the go.

Do you use the jemalloc gem?

The original project on GitHub seems to be abandoned for around 12 years, and some incompatibilities with recent Ruby versions have begun to emerge. Additionally, the underlying jemalloc library hasn't been updated during all this time. Because of that, I created a fork and launched a new gem (jemalloc_rb) to keep the project functional, updated, and actively accepting pull requests.

https://github.com/henrique-ft/jemalloc_rb

Today we’re happy to share that Ruby Users Forum will offer a place for Bridgetown discussions.

Hanami 3.0 is here and in full bloom 🌸

This is our most complete release yet: mailers, i18n, and Minitest now built in, your apps faster by default, and plenty more!

https://hanakai.org/blog/2026/06/30/hanami-3-0-in-full-bloom

You ship a /posts index page. It renders 50 posts, and for each one it shows the author's name with post.author.name. QA says the page is slow, and the logs are full of repetitive SQL.

1. What is this problem called, and why is it happening?
2. How would you detect it, in dev and in a running app?
3. How do you fix it, and what's the difference between the main fixing strategies?

Answer: N+1 queries

What it is and why it happens

This is the N+1 query problem. One query loads the 50 posts, then Active Record fires one more query per post to load post.author. That's 1 + N queries (1 for posts, 50 for authors) when it could be 2, or even 1. Active Record associations are lazy by default, so the author isn't loaded until you call post.author. Do that inside a loop and you get a round trip per record.

How to detect it

• Dev logs: you'll see the same SELECT ... FROM authors WHERE id = ? over and over with different IDs. That repetition is the tell.
• The Bullet gem: built for this. It warns you in dev when you should add eager loading, and also when you're eager-loading something you don't need.
• An APM in production (Sentry, New Relic, Scout): flags endpoints firing a lot of queries.
• Tests: assert on query count with something like assert_queries or an RSpec matcher so CI catches a regression before it ships.

How to fix it

Eager-load the association:

# N+1
@posts = Post.all
@posts.each { |p| puts p.author.name }   # 1 + 50 queries

# Fixed
@posts = Post.includes(:author)
@posts.each { |p| puts p.author.name }   # 2 queries

There are four tools, and they don't do the same thing:

The trap: joins alone does not preload. If you joins(:author) and then call p.author.name in the loop, you're right back to N+1. Reach for includes or eager_load when you actually read the association's attributes.

After wrestling with distributed transactions across microservices and watching Sidekiq job chains grow into unmaintainable spaghetti, I built Ruby Reactor — a saga pattern implementation for Ruby that handles the hard parts of workflow orchestration.

What it does:

• Builds a DAG (directed acyclic graph) from your step definitions, so independent steps run in parallel
• Runs async via Sidekiq with back-pressure and batching
• Automatically rolls back completed steps when something fails (compensation)
• Supports interrupts — pause a workflow mid-flight and resume it later via webhook or manual trigger
• Includes a built-in web dashboard to inspect every execution
• Has locks, semaphores, and rate limits built in (Redis-backed)
• Ships with RSpec test helpers — test_reactor, mock_step, chainable matchers

Why I built it:

I kept hitting the same wall: complex business transactions that span multiple services need coordination. dry-transaction handles linear pipelines well, but when you need parallel execution, async processing, automatic rollback on failure, or the ability to pause and wait for external events, you're on your own. Trailblazer operations can do some of this, but the undo logic and parallelism are manual.

Ruby Reactor fills the gap — it's the only Ruby library that combines DAG planning + async execution + compensation + interrupts + a dashboard in one package.

Quick example — an e-commerce checkout with fraud detection:

class CheckoutReactor < RubyReactor::Reactor
  input :order_id

  step :reserve_inventory do
    argument :order_id, input(:order_id)
    run { |args| Inventory.reserve(args[:order_id]) }
    undo { |_err, args| Inventory.release(args[:order_id]) }
  end

  step :charge_card do
    argument :order_id, input(:order_id)
    run { |args| Payment.charge(args[:order_id]) }
    undo { |_err, args| Payment.refund(args[:order_id]) }
  end

  # Pause here — wait for Stripe webhook
  interrupt :wait_for_fraud_check do
    wait_for :charge_card
    correlation_id { |ctx| "order-#{ctx.input(:order_id)}" }
    timeout 3600, strategy: :active
  end

  step :ship_order do
    argument :status, result(:wait_for_fraud_check, :status)
    run { |args| Shipping.create_label(args[:order_id]) }
    undo { |_err, args| Shipping.cancel(args[:order_id]) }
  end

  returns :ship_order
end

It's at v0.4.1 now with ~3,300 downloads on Rubygems. The v0.4.0 release just added interrupts, the web dashboard, RSpec helpers, and Redis-backed coordination primitives (locks, semaphores, rate limits, periods).

How it compares:

I'd love honest feedback — especially from people who've built complex workflows in production. What did I miss? What's over-engineered? What would make you actually use this instead of raw Sidekiq jobs?

Repo: https://github.com/arturictus/ruby_reactor Rubygems: gem 'ruby_reactor', '~> 0.5' Docs: Full guides for every feature in the repo's documentation/ directory

Thanks for reading! I'll be in the comments.

Like a lot of you I use Claude Code daily. The code it writes usually works, but on our codebase it kept doing the small wrong things: importing axios when we standardized on our own http wrapper, rewriting a date helper that already existed, building a service that ignored the base class every other service extends. Caught in review, every time.

So I built chameleon. It parses your repo with real ASTs (the TypeScript compiler, Ruby's Prism, Python's libcst), learns the conventions for each kind of file, and then before Claude edits a file it injects a real example from your own codebase plus your team's idioms and the anti-pattern to avoid. The model copies how your repo actually does it instead of guessing.

Being honest about what it is:

- Advisory by default. It nudges; you opt into hard blocking.

- Hot path is offline. No telemetry, no repo-code execution by default.

- It costs extra tokens and a little latency per turn (it injects context and runs a turn-end review).

That is the tradeoff.

- TS/JS, Ruby, and Python only right now.

- I don't have a published "makes Claude X% better" number and won't invent one. The A/B eval harness ships with it; point it at your repo and see.

MIT licensed. Install is two lines:

/plugin marketplace add crisnahine/chameleon
/plugin install chameleon@chameleon

GitHub: https://github.com/crisnahine/chameleon
Claude Plugin Hub: https://www.claudepluginhub.com/plugins/crisnahine-chameleon

I'm the author. Genuinely after feedback, especially what breaks or annoys you. Roast it.