Speakerline

Edit a proposal

Title Tags (comma-separated, max 3) Body

# Description

Working with Ruby and Rails affords access to a wealth of convenience, power and productivity. It also gives us a bunch of similar but distinct ways for checking objects' equality, modeling datetimes, checking strings against regular expressions and accomplishing other common tasks. Sometimes, this leads to confusion; other times, we simply pick one option that works and might miss out something that handles a particular use case better.

In this talk, we'll take a look at groups of patterns, classes and methods often seen in Rails code that might seem similar or equivalent at first glance. We’ll see how they differ and look at any pros, cons or edge cases worth considering for each group so that we can make more informed decisions when writing our code.

# Session format

Talk

# Level

Introductory and Overview

# Details

On its own, Ruby has a number of ways to accomplish the same goal. If you want the number of elements in some kind of enumerable object, you’ve got `size` and `length`; if you want to get the current time, should you do `Time.now` or `DateTime.now`? When we add Rails into the mix, we now have to consider whether we’re hitting the database when we check for the number of elements in some collection, and we have a whole new class meant to represent datetimes in the form of `ActiveSupport::TimeWithZone`. This talk will provide a list of these types of “this-or-that”s and go into depth on some of the most important.

This talk is intended to be digestible by and helpful for Ruby developers of all experience levels, though I expect people who have worked with Ruby for close to a decade or longer will see significantly less novel information than those who have worked with Ruby for, say, 0-5 years. Attendees and viewers will leave feeling more informed and ready to choose between the various this-or-thats when writing code at work or at home.

I currently have a list of this-or-that topics that numbers in the dozens which is far too many to cover in this talk and would likely be better served by a listicle than a conference talk. As such, I’m planning on including the overall list as a resource at the end of the slides with links to documentation, blog posts and other resources for the topics that I won’t cover in the talk itself. The subset of topics that I’ll cover is chosen based on several factors including quality of documentation, significance of differences, commonality of usage, number and severity of related bugs I’ve seen and other factors.

For the topics that I cover, I’ll include pros, cons and other good to know information for each option. Depending on the particular topic, this will include information like return values, performance differences, how different arguments are handled, what versions of Ruby or Rails they’re available in, unit-testing considerations or differences in their side effects.

Examples of this-or-thats that will be included in the overall list at the end of the slides but will have very little dedicated time in the talk include easily and commonly searched topics like `count` versus `length` versus `size` and `alias` versus `alias_method`.

Examples of topics that will be included in depth are `delegate` versus `SimpleDelegator` versus `method_missing`, `match` versus `match?` versus `=~` and `each` versus `find_each` versus `find_in_batches`.

# Pitch

I gave a version of this talk at work to an audience of about 60 people several months ago that went over extremely well. By the end of the week in which I gave the talk, I received messages from several teams stating that the talk had already impacted multiple pull requests as well as notes of appreciation from engineers with a wide range of experience levels in Ruby development letting me know the various things they learned or surprises they experienced through the talk.

Since then, I’ve developed a list of refinements that I plan to make to tighten up the talk and add topics that I originally missed.

In addition to this experience speaking on this topic, I have a decade of experience working with Ruby and Rails professionally. Much of that experience was in a consulting environment where my responsibilities were mixed between feature development on the latest versions of Ruby and Rails and maintenance on legacy projects, so I’ve had the chance to see how the language and framework and their usage has evolved over more than just the ten years I’ve been in the industry. I also created and regularly maintain my current employer’s wiki for Ruby and Rails tips, tricks and gotchas used for new engineer onboarding and have been an active contributor to org-wide norming and linter configuration at each of my jobs which prompts a lot of thinking on this topic.

In that time, I’ve also sought out as many mentoring opportunities as I’ve had the bandwidth for, and a common source of confusion for my mentees is how many ways there appear to be to solve the same problem with Ruby and Rails. I’ve noticed this regardless of whether the mentee is new to professional software development or is an experienced engineer that’s new to Ruby and Rails. There are lots of resources out there on specific topics, like the differences between `Time`, `DateTime` and `ActiveSupport::TimeWithZone`, but I haven’t had much luck finding resources that have both the breadth and depth of different topics that this talk will cover. I’m hoping that this balance of breadth and depth will make this talk and the list at the end of the slides a resource both for people who want to know the differences between different options on a specific topic as well as for people who are in the “I don’t know what I don’t know” stage.

Additionally, I intend to crowd-source ideas that I missed in Slack after the talk and enable commenting in the slides to foster engagement to make the slides an even more valuable resource for future viewers.

Back to Speaker Directory