I’m not sure if it’s a fine line or a broad one between programming-in-the-small and programming-in-the-large, but at hotelicopter, we’ve definitely stepped over that line. Along the way, in a very short amount of time (6 months, give or take), we’ve begun moving to the cloud (aws), adopted distributed source code control (git), automated deployment (capistrano), continuous integration (hudson), unit testing, Ruby on Rails, lost a key developer, and hired a new rockstar.
Just to confuse things, the majority of our site - the importantest parts, anyway – are still written in PHP, on a code base now 2+ years old and about a decade behind the times. (Can you say “monolithic”? I knew you could!)
The place we’re aiming for is a highly decoupled (and scalable), cohesive set of services, joined through REST APIs and/or fully reused common business models. We have multiple “applications” now, all operating on a couple of common databases. We’ve officially run headlong into one of Ruby on Rails’ deficiencies: programming in the large. We’re not interested in computer science-y solutions, only pragmatic ones.
I suspect as we muddle along we’ll develop a component-level (service level if you prefer) version of the Law of Demeter, which will drive us to make the right decisions for decoupling. I’m not too worried about that. However, we definitely have issues with reuse. Currently the Ruby on Rails state of the art solution for reuse is the gem. Which, let’s face it, is a pathetic solution.
We’ve begun rolling what we call our “common” system, composed of a set of models, migrations, configuration artifacts, etc., shared between applications, wedged carefully into the RoR framework, and superglued in. It supports use standalone, outside of a RoR application environment (though definitely somewhat hobbled in that case), and allows application-specific specialization of common models.
I’m not sure it will be sufficient in the long run, but thus far it is supporting a large degree of reuse between three RoR apps and our PHP site.
[...] Colin Steele writes about the challenges that he and his team are facing at Hotelicopter: We’ve officially run headlong into one of Ruby on Rails’ deficiencies: programming in the large. We’re not interested in computer science-y solutions, only pragmatic ones. [...]