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.

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.

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.

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.

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.

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.