For the past year, my team has been working on a project that exposes a GraphQL API, and, since we’ve been doing things quite differently than the rest of the company, I figured some of our ideas might be worth sharing. We’ve been using the graphql-ruby gem, and even though it doesn’t lend itself well to unit testing, we’ve insisted on writing unit tests. What’s more, we’ve also used Sorbet to prevent other categories of errors; in fact, most of our code is using typed: strict! In this post, I’ll share why we went out of our way to do this, and how it can be done.

A few months ago, I found myself trying to explain type variance to a coworker whose experience is mainly Ruby. Dynamically typed languages such as Ruby don’t ask the developers to specify the type variance. I found that while they develop an instinct of what usages are acceptable and which aren’t, these developers don’t codify it in the same way developers in statically typed languages do. In trying to explain, I had great difficulty driving home the difference between covariance and contravariance. Their good instinct made it hard for me to fill the gap in their understanding. After a while, I remembered the way Simon Génier first explained it to me, and that way was a success.

In the first post of this series, I showed how a few APIs afford errors to their users. In the second post, I showed a few examples of how other APIs or languages have avoided or solved the same problems. In this third and final post, we will work through an example of designing an API.

In the first part of this series of three posts, I outlined a few common Ruby and Rails API, and explained the errors they afford their users. In this second post, I’ll discuss how other tools have avoided these problems, and how those solutions may apply to Ruby and Rails. I’ll be reusing the examples from the previous post. If you haven’t read it, I suggest you start there: Affordance for Errors, part 1.

A few years ago, I read Sandi Metz’s blog post about affordances and it stuck with me. I started minding how the APIs I write can be misused; I started noticing the surface I leave for the users of my APIs to make errors. Soon after I started noticing how the APIs we use every day are full of affordance for error.

Following my Short Rant on ActiveSupport::Concern, I’ve been asked how to refactor the code to make it stop using it, or write new code without it. I thought I’d share the patterns that have worked for me so far.

What is ActiveSupport::Concern?

ActiveSupport::Concern is a module which other modules can extend to get its features. It allows for easily (note: easy, not simple) applying modifications to the receiver module and its singleton class, as well as triggering hooks when the module gets include’d.

When I started writing, I picked Medium. I didn’t want to setup a blog, have choose a template or style, or figure out how to use an analytics platform. I just wanted to write.

When writing my Revoking the (Parentheses) Privilege post, it became apparent that Medium failed me. It has no support for syntax highlighting, requiring me to use screenshots from Carbon. I’m considering a post which will require JS to create visualizations, and it would be impossible on Medium.

Recently I was called out. I hypothesized that some bad patterns in Ruby are caused by developers misunderstanding Ruby’s Object Model, but I had not provided them with any learning resources. In fact, I couldn’t find anything satisfying, so I decided to write this post.

For years, Rubyists (including where I work) have enjoyed the privilege of omitting parenthesis around method call arguments. Last week, we merged a pull request to our style guide revoking that privilege: parenthesis will become mandatory for all method calls with arguments.