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.

I didn't give a talk here, but they let me introduce the lightning talks, which was fun, here's my brief introduction.

(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.

Rails is powerful, but it doesn't do everything. Sometimes you want to build your own tool that adds functionality to Rails. If it's something that might be useful for other people, you can write a Ruby Gem and distribute it. In this workshop, we will go through the entire process of creating a gem, starting with `bundle gem` and ending with how to publish it with `gem push`.

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.

The 2021 remote version of my workshop on building front-end apps with Hotwire.

Mentorship is a great way for a newer developer to benefit from the experience of a more senior developer. While there are lots of available resources on how to be a good mentor or mentee, there are far fewer guidelines on how to set up a mentoring program within your engineering organization.

As developers, our work is mediated through many tools besides languages. We use terminals, browsers, git, and the os. Not to mention editors. These are powerful tools that can be infinitely customized and extended. The tools can make common tasks easier or less error prone to perform. Or they can give you visibility into system behavior.

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.

Having a structure where developers feel supported makes them happier, and less likely to leave. How can you manage reviews and goal structures to benefit your team.

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.

Your customers have money, and you’d like them to give it to you. Payment gateways, such as Stripe, Braintree, and Paypal, make it easy to start charging credit cards and get the money flowing. But charging cards is only the beginning. Learn from some of my mistakes and build a robust financial application.

Noel Rappin shares his experience running HR for a year as a developer, offering insights and answering questions about the intersection of technology and human resources.

Estimates are like weather forecasts. Getting them right is hard, and everybody complains when you are wrong. Estimating projects is often critically important to the people who pay us to develop software. We can do better.

Estimates are like weather forecasts. Getting them right is hard, and everybody complains when you are wrong. Estimating projects is often critically important to the people who pay us to develop software. We can do better.

"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".

RSpec is often described with the word “magic” by both its users and its detractors. Understanding how RSpec matchers, doubles, and specifications work will help you as an RSpec user. You will be able to take advantage of RSpec’s flexibility to make your tests clearer and more expressive. You’ll also get some exposure to new RSpec features, like compound matchers.

Estimates are like weather forecasts. Getting them right is hard, and everybody complains when you are wrong. Estimating projects is often critically important to the people who pay us to develop software. We can do better.

This is a panel discussion featuring Ben Orenstein, Bree Thomas, Jeff Casimir, Jen Meyers, Kathryn Exline, and Liz Abinante about how best to bring new developers into the field, and what kind of knowledge they will need to be successful. What can we, as a community, do to improve our management of new developers? What can new developers do to give themselves the best chance of success?

Smalltalk has mystique. We talk about it more than we use it. It seems like it should be so similar to Ruby. It has similar Object-Oriented structures, it even has blocks. But everything is so slightly different, from the programming environment, to the 1-based arrays, to the simple syntax. Using Smalltalk will make you look at familiar constructs with new eyes. We'll show you how to get started on Smalltalk, and walk through some sample code. Live coding may be involved. You'll never look at objects the same way again.

Two completely different ways have emerged for using Rails as the back end to a rich client-side JavaScript application. We will look at code to see the structural difference between these two approaches and see what the speed, extensibility, and maintainability trade-offs are.

In this workshop, we'll focus on two specific problems that plague testing complex systems: how do I create useful test data, and how do I limit my test to only the part of the system that I want tested. We'll cover data creation tools like factories and fixtures. We will also talk about how to effectively use mock objects. And we'll do all that against some code that shows off potental testing problems.

I don't think I'm alone in being drawn to TDD at first because it was fun. The quick and consistent feedback and the ability to turn complicated problems into a series of smaller problems to be solved made TDD development seem more like a game than work.

Another talk about the mechanics of testing. Introducing the tortured acronym SWIFT for the five habits: Simple, Well-Defined, Independent, Fast, Truthful

Five minute lightning talk about setting up your developer mis-en-place.

Everybody wants to do test-driven development, but switching to TDD or BDD on an existing project that doesn't have tests presents special challenges. Often, the current code is a tangled mess of dependencies that defeats the very concept of unit testing. Worse, if somebody has attempted TDD in the past, you might have a test suite that needs to be fixed before any new tests can be written.

You, yes you, could write a technical book about a subject that you are interested in and want to excite others about. But how should you pick a topic? How can you stay excited as you write the book? How should you distribute the book?