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.
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 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.
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.
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.
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.
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.
This is a copy/paste of a comment I made on an internal pull request. I had been tagged on it because on my hard stance against ActiveSupport::Concern, asking me to clarify my objections. I’ve reworded my reply where it made sense.
Here is the code on which I was asked to comment: