What's new in Ruby 4.0 and Bundler 4.0, a brief talk for the SF Ruby meetup in Dec 2025

Ruby rewards thinking about types with a dynamic mindset instead of a static one. In this workshop, we'll show how use Ruby's dynamism to your advantage.

(This video is only the screen, not on me). It's A nostalgic and insightful journey into what makes Ruby uniquely expressive and joyful, by exploring Ruby's most Ruby-ish features.

New Ruby developers often wonder how to write safe code in Ruby without static typing. In this workshop, we’re going to refactor working code to get the data validation and safety of static typing, but using Ruby’s existing features.

A look at new Ruby features in Ruby 3.x versions, with a discussion of which ones have caught on and why.

Ruby puts the Ruby in “Ruby on Rails”! It’s the Ruby language that makes Rails flexible, powerful, and with a developer-friendly API. How does Rails take advantage of Ruby’s flexibility and metaprogramming to make it so useful? And how can you take advantage of those features in your Rails app?

If you’ve learned Ruby recently, you’ve likely been told to avoid using Ruby’s metaprogramming features because they are “dangerous”. Here at RubyConf, we laugh at danger. Or at least chuckle nervously at it. Ruby’s flexibility is one of the features that makes Ruby powerful, and ignoring it limits what you can do with the language. Plus, metaprogramming is fun.

There is a value in writing tests and there is also a cost. The currency is time. The trade-offs are difficult to evaluate because the cost and value are often seen by different people. The writer of the test bears much of the short term cost while long term benefits and cost are borne by the rest of the team. By planning around both the the cost and value of your tests, you’ll improve your tests and your code.

Legacy code. We’ve all dealt with it, we’ve all screamed at it. And we’ve all written it. A project becomes legacy when developers no longer have the context of old decisions. The transition to legacy status happens step by step, decision by decision.

Test doubles (which you may know under the alias “mock objects”) are the most misunderstood and misused testing tools we've got. Starting with the fact that nobody can agree on what to call them. Contrary to what you may have heard, test doubles do not inherently lead to fragile tests.

"Red. Green. Refactor" is a great slogan for Test-Driven Development. It's less great as a guide to actual TDD practice. The slogan provides no guidance for two very important questions in a TDD process: "What do I test next?" and "How do I break my problem into testable pieces".