It’s been about 10 days since I returned home from MicroConf Europe 2016. MicroConf is a special event for those in attendance - part industry event, part seminar, part summer camp, part support group. And every year, I come away with a shopping list of tactics to try and tasks to be done AND the motivation to dig in and get started on them. This year was no different. Since getting back to my desk, I’ve already:

  • Collected relevant statistics my sales funnel since the beginning of 2016.
  • Filled in my content calendar for September and October.
  • Finished half of the book that was recommended to me by three different people.
  • Sketched out the broad strokes for two new projects.
  • Planned a head to head test to compare the two and decide which one to work on first later this year.

Setting aside the tactical for a moment though, a lot the value of MicroConf comes from the larger lessons drawn from the talks and hallway conversations. Sometimes, these are common threads that run through many interactions but never appear on a slide. Now that I’ve had some time for rest and recovery, I took some time this week to think through some of the broader themes from this year’s conference.

(Special thanks to Christoph Engelhardt, the official MicroConf Europe scribe. Without his always great conference notes to refer to, I wouldn’t have been able to collect my thoughts nearly as easily.)

Recently I came across a post that called out a perceived lack of available documentation and other learning material for Minitest in contrast with RSpec. And while I’m not entirely sure I agree with the premise, the main point of the article had the ring of truth to it:

If there’s a problem to be solved here, it’s that the obvious parts of Minitest need to be better documented. Organize the new documentation in the format of “I want to do xyz thing”,with an example.

Honestly, what project couldn’t use better docs - more focused, more examples, and detailed explanations? That was exactly the same line of thinking that got me thinking about writing The Minitest Cookbook.

I released a cheat sheet with the book that I thought might provide people with a partial solution, so I prepared a simplified version that includes a reference to the basic methods and syntax for Minitest and Minitest::Spec as well as a full listing of all assertions and expectations for each along with simple code examples for context. (The full version also includes Rails-specific helpers and assertions and a list of the most commonly used Capybara methods.)

When it was released in Rails 4.2, Active Job was an important addition to the platform. Background jobs have been a part of the ecosystem for a long time, but this was the first time that developers had a single API to work with a variety of job queuing frameworks. Having a common interface has led to a shared base of knowledge and patterns for developing and testing workers.

In the last post, we looked at some good practices for writing well-designed background jobs in Rails using Active Job, but we didn’t get around to the question of how to test them. This post will focus on a step-by-step strategy for testing all of your application’s “set it and forget it” code - one that leverages the unified Active Job interface and the tools Rails and Minitest provide us.

The ability to run operations with long or uncertain execution times in the background has become a standard tool for modern web applications, and most frameworks and platforms now include some sort of support for encapsulating pieces of logic that involve heavy lifting out of the main request/response cycle. For example, I recently finished work on a relatively simple Rails application that had about a dozen different background jobs written for a whole range of standard-ish use cases:

  • Sending bulk notifications to a group of users
  • Consuming data from external APIs and updating the database
  • Batch creation of work items to users
  • Importing records from an uploaded data file
  • Complex object state manipulation that doesn’t fit in an AR callback
  • Refreshing scores cached in the database after an admin changes the weights used to calculate them

The way I write and test background workers has evolved over the years, and since I’m getting ready to start a new project that will have a big background processing component, I thought it would be a good time to reflect on my approach and what I’ve learned.

I just finished reading Jared Friedman’s Why I wouldn’t use rails for a new company. Mr. Friedman is the founding CTO of Scribd which means he’s overseen the development of one of the biggest Rails-based applications on the web, and he’s been notably ahead of the curve on important matters of technology (Scribd’s transition from Flash to HTML5) and policy (SOPA). In short, when he says something about building businesses on the back of Rails-based software, it’s probably worth paying attention.

Which is probably why I found reading this article so frustrating. I expected a well-informed argument combining technology- and business-oriented reasons that Rails was no longer where it’s at, but what I got was a mixture of opinion and cherry-picked facts that were at best selective and at worst intentionally misleading. It was a missed opportunity to have a serious discussion about the directions of Ruby and Rails as technologies and the factors that businesses should consider when deciding what tools to use when building out their applications.

I still like Rails for new application development - not just because of the time I’ve spent learning the framework, but because I still believe Rails is a force multiplier for software development. In this response to Mr. Friedman’s piece, I want to examine the points he made in more detail, calling bullshit where necessary, and then add my two cents to the discussion by assessing what Rails does right and where it can still improve.