I've released a new gem which adds an implements_role macro, closing the loop when mocking roles rather than objects, for use with rspec-fire. See the README for rationale and the Relish documentation for a to-the-point worked example.

After reading "Growing Object-Oriented Software Guided by Tests" (GOOS), I finally stopped worrying and learned to love the "mockist" or "London School" of TDD. However, the unfortunate fact of this style in Ruby is that tests using mocks can easily find themselves out of sync with the concrete implementations instructed into existence by those mocks, especially when making adjustments to the design of the system.

To that end, I imagined an approach which could resolve the issue with minimal effort. This is a hypothetical syntax, and I haven't started actually implementing it. I thought I'd throw it out to the community for discussion and maybe get the ball rolling on something like it (or something better). See the Gist.

In a recent project, I had the opportunity to explore taking an MVP and turning it into something scalable, ahead of an announcement which would send tons of users to the app at once. I thought I'd share some pointers along with our findings, including which EC2 instance type we found to be most cost-effective as a Rails app server running under Nginx + Unicorn.

A possible new alternative to keeping certain kinds of specs DRY without deep-diving into nested describe hell.

With all the talk about putting models on a diet with DCI, I thought I'd write about how I used the Command Pattern to achieve similar goals in my aptly-named turn-based strategy game Elite Command.

Funnel tracking is a very useful device for measuring and improving user acquisition and retention. Here's how I did it in my Rails-based strategy game, Elite Command.