On the RevolutionOnRails blog, Aaron Batalion says "Our passion is to end the Rails enterprise argument." On their team blog, the corporate development team is certainly showing their passion. In the past three weeks they have released two Rails plugins and a javascript extension library. They have also teased us with their secret to corporate Ruby on Rails development: PluGems.
PluGems is a RubyGem based solution that combines "plugins, gems, Rails Engines, with baked in deployment, version constraints, and more" according to Batalion. They have written a four-part introduction of this soon to be shared solution.
The basic concept allows for extending Rails plugins to include the versioning power of Ruby Gems. They extended Rails itself to look at the plugins directory first for views and layouts. This idea was borrowed and extended from the Rails Engines project. Now sharing a common look and feel across an array of corporate sites and subdomains is as simple as installing the gem-based default style and overriding the pieces that will be different for each implementation. With a well-defined dependency structure, overriding a default theme is as easy as creating a layout file in your app folder in Rails.
The Revolution Health development team put a lot of energy in to making their environment easy to use. In one blog entry they describe how each new developer on the team gets a Mac Book Pro, then goes on to use a combination of gems and Rake tasks to configure the development environment automatically. The Plugems platform that they use actually deploys entire Rails applications in the RubyGems installation folders. A simple Rake task creates the necessary symbolic links to serve these gems as applications in the development directory.
An Alexa search for Revolution Health shows that they are getting fantastic traffic in their first few weeks after going live. The site is always responsive and smooth, so whatever their secrets are, we hope they'll come to light soon. Perhaps the team will be answering the deployment questions by RailsConf 2007 in May.
The full text of the interview with Aaron Batalion is listed below. We would like to thank him and his team for taking time from their busy post-launch schedule to discuss their exciting corporate development with InfoQ.
The myth that Rails doesn't scale has been disproven by many Rails sites handling high traffic loads. What remains a bit of a mystery how these sites are deployed. What platform did you use for deployment of RevolutionHealth.com? What platforms did you try, and how long did it take you to come to your final deployment platform? NetCraft says you've got Oracle Application Server 10g as the final public facing piece. How much of Oracle's Application Server is in your architecture?
The deployment of RevolutionHealth.com is an ongoing exercise. We're constantly looking for better ways to not only deploy our software, but to also improve our performance and scalability. With lighttpd and Mongrel being common choices for Rails deployment these days, I think the progress being made with JRuby will only help winning over an existing IT department. I'm excited to see Sun take an active role is supporting the project and I wish those guys much success.
What we do believe is unique is our software deployment solution called Plugems, which is 100% gem-based. We've begun a discussion of the ideas here, here, and here. Because we have a handful of front-end applications, all with shared andversioned dependencies, we built Plugems to be a combination of plugins, gems, Rails Engines, with baked-in deployment, version constraints, and more.
The pragmatic approach to design suggests that you shouldn't worry about performance until performance is a problem. You designed and built your site from the ground up expecting a higher load of traffic than most sites will ever see. How did performance mold your design and development practices? At what point did you start optimizing your architecture? What snags did you hit along the way?
We definitely didn't start optimizing up front. Like any startup, our requirements were changing constantly and any potential optimization may not have been required a few weeks later. That being said, we build tools like Browser Profiler, to catch problems quickly and even once deployed. We also have a custom performance monitoring plugin, which is configured to log anytime (action, db query, web service call, etc) that takes longer than an acceptable threshold. Overall, we pushed to keep things simple and cached where possible.
Ruby is a rapidly growing language, but it still isn't as popular as Java, C# and PHP. How hard was it to find talented developers for your project? Did you train good people who knew another platform or did you recruit Ruby on Rails developers?
Finding great engineers is never easy, no matter the language or technology. Since many of our folks didn't start with Ruby or Rails knowledge, we're very grateful that Rails makes so much of traditional web development easier. Most of our folks picked up Rails very quickly and were productive in days or weeks. With respect to recruiting, we are always looking for Rails rockstars, but it's not a requirement for a job. Smart people, with web experience and a hunger to build great applications is what we look for.
The RevolutionOnRails blog is a great view into the corporate Rails development world. What was the goal of creating this team blog?
We spent the past year behind a closed curtain of startup secrecy. During that time, we saw the rails community grow from a small wave to a tsunami. Luckily, we are now becoming more involved in the community, by releasing source code and blogging about our work at RevolutionOnRails. We've released a couple plugins so far (BrowserLogger, BrowserProfiler), as well as a couple of JavaScript posts with source code included. Our plan is to release other plugins in the coming months, which we hope others will use and contribute to. Something we most look forward to outside feedback on is our Plugems solution.
You've extracted several of your processes into public plugins and released them on RubyForge. Did using an Open Source platform like Ruby on Rails encourage your team to contribute back to the community? What was the reaction of the Revolution Health management team?
Our technology leadership understands the importance of the community as well as our involvement with it. The Rails community has helped us in so many ways that is would be a mistake not to give back. We hope our blog, along with our current and future open source projects, are at least something in return.