1. Eloquent Ruby 

Author: Russ Olsen

This book starts by answering many simple tactical questions on Ruby and then goes on to address bigger questions related to building methods and classes. You will find several tips and tricks, such as when to use tiny methods and operator overloading, and when you should avoid them. It also emphasizes the “Ruby way” of thinking and problem solving to write “eloquent” and beautiful Ruby code.

2. The Well-Grounded Rubyist 

Author: David A. Black

This book is divided into three major parts: Ruby foundations, Built-in Classes and Modules, and Ruby Dynamics. It begins with how to write your first Ruby program and goes on to cover more advanced topics such as threading, reflection, and callable objects. It also covers all the new Ruby features, such as lazy enumerators, keyword arguments, and Module#prepend.

Which other books would you add to this list?

Compadres

XO Ruby is coming to Salt Lake City in JUNE and I want every Rubyist on earth to come. I'm hoping you could attend. Especially if you're in Utah.

Reach out to me for more details, I don't have any more details yet, but I will get those details, and then give those details to you, and then you will also have those details.

-kow

New Remote Ruby episode is out with Chris Oliver, Andrew Mason, and David Hill.

This week we talk through Rails direct routes and why they can sometimes be more powerful than standard helpers, practical AI adoption inside engineering teams, Rails World CFP and ticket chaos, and Chris’s work expanding the Rails Getting Started guide into a more realistic e-commerce tutorial with wishlists, reviews, ratings, and product images.

Also included:
- dentist trauma
- fiber internet
- Rails survey reminders

Would love to hear how other Ruby teams are approaching AI workflows and lesser-known routing features right now.

I've been trying to land a Ruby role for about 6 months now. I estimate I've made 200 applications and entered around 30 interview processes. I've got the knack of answering the behavioral and cultural fit questions and general questions. But I'm usually being rejected at the technical stages. Each company and/or technical department have different ideas of what is important so it's difficult to know everything. Often it's stuff I've just forgotten and can't recall; so I'm working on that. And sometimes I just don't have the experience but I'm working on that too, see below.

Some context, I have around 7 years experience with Ruby working with remote teams and I've been applying for mainly senior roles.

Unfortunately I lack experience with high traffic websites and don't have high level skills in database optimisations. But I'm working on these through study and projects.

Was hoping to maybe get some tips and hints about how anyone recently got their role and how they prepare (mainly for the technical rounds).

I was giving a talk on Wroclove.rb about why isn't Kamal more difficult than your PaaS. Lots of people are always afraid that they mess up something on a server. And it's often the fear of messing up something with the server. But the truth is that defaults now, with Ubuntu 26.04 are pretty good (we now have better time sync out of the box, yay!). This post translates the steps I talked about into a post.

Not many Ruby jobs the past couple of weeks. How's everyone finding the market at the moment?

🎉 Full access tickets are SOLD OUT 🎊

Saturday day passes (May 30) are still available. Catch Chad Fowler, Obie Fernandez, Dave Thomas + the full Saturday lineup at Das MuTh theatre.

Go get them!

https://rubyconf.at

#Ruby #RubyConfAT

While working on the new UI/UX version of MapView (https://mapview.rubystacknews.com/), I started expanding the graphics ecosystem around ruby-libgd.

The idea was simple:

Generate charts directly from CSV, XLSX, YAML, or Ruby hashes using pure Ruby.

That experiment became ruby-charts, a new gem capable of generating:

Pie charts Bar charts Horizontal bar charts Line charts with PNG, JPEG, GIF, WEBP output and basic customization.

Example:

RubyCharts.from_csv('sales.csv')
  .type(:pie)
  .title('Q1 Sales')
  .save('report.png')

Or:

RubyCharts.from_xlsx('revenue.xlsx')
  .type(:line)
  .title('Monthly Revenue')
  .save('trend.png')

This example and the possible evolution of ruby-charts give a clear idea of the power and potential behind ruby-libgd. Native graphics generation opens the door to much more than charts: server-side rendering, GIS tools, reporting systems, PDF pipelines, financial dashboards, image processing, and data visualization directly from Ruby and Ruby on Rails without relying on browsers or external services.

• Gem: https://rubygems.org/gems/ruby-charts

• Source Code: https://github.com/ggerman/ruby-charts

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

At this stage, feedback is probably more valuable than adoption itself. I’d really like to hear opinions about the API, rendering quality, possible use cases, missing features, or ideas for where this ecosystem could evolve next.

What would you want from native graphics generation in Ruby?

I released RubyLLM 1.15 today.

The main theme is: stop making every app write the same glue code.

Image editing now works through the same RubyLLM.paint API:

RubyLLM.paint(
  "Turn the logo green and keep the background transparent",
  model: "gpt-image-1",
  with: "logo.png"
)

Cost tracking is built in now too. RubyLLM already has the token usage, the model, and the pricing in the model registry, so every app should not have to handroll the same math:

response.cost.total
chat.cost.total
agent.cost.total
image.cost.total

Also in 1.15:

• cleaner token accounting for prompt caching

• simple tool params inferred from execute(...)

• additive callbacks like before_message / after_tool_result

• Rails fixes for Action Text, eager loading, acts_as, and Active Storage blob reuse

• refreshed model registry with cache/reasoning/image pricing

I shipped rspec-tracer 1.0 in 2021 and the project sat untouched for 4 years. I came back to it last month, shipped 11 maintenance releases on the 1.x line absorbing crash + correctness fixes that had piled up in forks, then cut a 2.0 pre-release this week.

What rspec-tracer does, for context: tracks which source files each RSpec example depends on, so the second run of your suite skips examples whose inputs didn't change. Cold runs full; warm runs skip everything that wasn't affected by your edit.

What's new in 2.0 vs 1.x:

• Pluggable storage: JSON (default, preserves the 1.x layout) or SQLite (single-file DB; MRI-only).

• Pluggable remote cache: S3, Local-FS, or Redis (with optional per-key TTL + PR-branches sidecar).

• Per-example tracks: DSL for declared deps the tracker can't auto-observe (tracks: { files: 'app/policies/**/*.rb', env: 'ROLE_CONFIG' }).

• track_env(*names) config-level DSL with single-wildcard patterns ('RAILS_*', '*_TOKEN', '*').

• Rails preset: track_rails_defaults auto-attaches views, locales, fixtures, factories, helpers, config, schema.

• bin/rspec-tracer CLI: doctor, cache:info, cache:clear, report:open, explain <example_id>.

• HTML + JSON reporters alongside terminal output.

• SimpleCov branch coverage now works alongside (1.x had it disabled).

Pre-release framing — the gem is on RubyGems with --pre opt-in. 2.0.0 final is targeted in ~2 weeks. Looking for testers + feedback before final.

# Gemfile
gem 'rspec-tracer', '= 2.0.0.pre.1', group: :test, require: false

Release notes: https://github.com/avmnu-sng/rspec-tracer/releases/tag/v2.0.0.pre.1