When starting off on the path to integrate Rails into an existing environment, one of the key questions is to decide when to use Rails and when to stick with your "legacy" language.
Unless your site consists of a single unified application, you're probably not going to be in a situation where you'd simply port everything over to Rails. And, there are plenty of good arguments against halting development to complete a wholesale port. We also have a number of major projects built in PHP. We're keeping those in PHP for now, at least until the costs outweigh the benefits.
So, we're only creating a Rails project when we're faced with either a brand new project, or if the existing codebase is so creaky and worn out that it just isn't worth continuing. In our case, we had a number of projects that met the latter criteria.
We also had been using PHP heavily on our "static" pages. We used PHP to include common elements, such as navigation and branding, and to show/hide content depending on the user's context. There isn't a clear migration path into Rails for this type of functionality, short of either deploying everything into a content management system, or treating every page as a view. Neither option seemed palatable, so PHP has maintained its place in the front-end of our website.
It should not be surprising that we're using Rails solely in the "application" space. In our case, however, sometimes an "application" ends up being a single-page form. As long as there is significantly complicated stuff happening behind the scenes, it it worth using the power (and server resources) of Rails. So, our Rails apps tend to be things like event calendars, membership signup/management systems, and authentication systems.
For the foreseeable future, our site will remain a mix of PHP and Rails.
(I'll dive into more technical details in the next post.)
Some background is in order before we dive into the specifics of our Rails installation.
Here's the situation:
In many ways, we're pretty typical (excepting probably the Pubcookie part).
So, why Rails? I choose Rails for many of the same reasons anyone would. I'd been growing a bit disenchanted with PHP--or rather, our ways of using it. You see, with employees and various contractors, we'd had five or six people develop various applications on our site. We had no coding conventions, and each system had its own idiosyncratic style. Maintaining these projects was becoming a pain. The Rails philosophy of "convention over configuration" had a lot of appeal in this situation. Other Rails philosophies -- "Don't Repeat Yourself" and the idea that elegant code is good code -- mapped well to my experiences as a developer.
But, I also liked Rails' deployment possibilities (Capistrano), as well as the knowledge that Rails apps could scale (with caching and multiple servers) to meet a high load. And, to cap it all off, Ruby is a nice language to work in. I had been a fan of Python, and enjoyed working with these dynamic languages. (In fact, had I not committed to Rails, I'd have probably ended up looking pretty seriously at Django.)
RoR has been hyped--and rightly so--as hitting the sweet spot for greenfield development. That is, when you're starting a fresh project, and can commit to configuring everything--from web server to database schema to deployment strategy--to Rails' liking. True enough. But many of us are not working with a blank slate. We have to deal with existing servers and databases. New projects need to be integrated into existing websites and interop with legacy systems. What then? Is Rails still a good choice?
To explore this question, I'm going to recount some of the strategies I've used in deploying Rails applications into an existing website.
First, some caveats:
I'll use this post as the table of contents, and update it as I add new entries.
Table of Contents:
Upgrading the memory on a Mac Mini is officially a huge pain. I just spent, oh, about an hour or so cracking the case and swapping out the memory. Apple really would rather you didn't do this yourself, I guess. The hassle is almost not worth the markup you pay by ordering the machine with extra memory to start with. In fact, I'm probably going to order a mini for the office soon, and I'll just buy it pre-installed with 2GB.
Anyway, should you feel like you want to venture inside your mini, watch this video first. Very helpful. Anyway, now I'm zipping along with 2GB of memory...
Oren Sreebny at the University of Washington has some interesting looking jobs open working in his "Emerging Technology" group.
If I wasn't otherwise engaged, I'd be really interested in this type of work. Oren is a good guy, and based on his blog, I think they're doing interesting work. Anyway, all you information management types should check it out.
Also, I looked at one of the job descriptions and was mildly amused to see Ruby on Rails listed as a "modern enterprise web application development platform". While I wouldn't quibble with that language (especially since I've shifted most of our development at work to Rails), it is funny in the context of the debates that raged through the blogosphere a few months back about ruby and/or Rails not being ready for the "enterprise". Heh. Now that Oren has labeled it enterprise-class, I should get going on that series of blog posts I've been planning on how we've integrated Rails into our little mini-enterprise. Maybe this weekend...