Timothy Sherratt

When Rails projects get *very* large or complex, development and developer efficiency typically slows down due to the interdependent (ball-of-mud) nature of the typical Rails app.

This is the cost of all the wonderful magic that Rails provides, and it means that you can get your projects up and running extremely quickly.

To combat this inevitable slow-down, I built a data mapper style ORM that sits on top of Active Record (i.e., uses its SQL generation, etc.). This enables different engines that do not depend on one another, giving much greater flexibility (at the cost of a little more typing) as products grow very large.

This forced separation means that once a large scale is reached, developers will not be dealing with a web of dependencies, and ultimately, it will be more easily able to split out apps that provide a subset of the main app's functionality, easing the path to an SOA architecture when this becomes inevitable.

See http://cbra.info/ for other people thinking around this topic.

This is a sample showing error handling for a Ruby on Rails API. It gracefully captures all appropriate errors raised throughout the other controllers and returns relevant errors and status codes.

This particular code is within a Rails Concern, allowing it to be reused across a huge app, where much of the code is separated into various Rails engines.

This is an application that I worked on, starting with a simple MVP and currently undergoing updates to replace the front-end with React.js, and back-end with an appropriate API to support it.

Included here to demonstrate full-stack ability, as one of the few public-facing projects I worked on.