curves

The last six months we’ve been dealing a lot with Rails at work. I wouldn’t say I’m an old school perl guy but it’s what I cut my web teeth on and the language I know best. I have been a perl-ie man for the bulk of the last 10 years. As my current position is now sysadmin I met “the Rails way” with a lot of skepticism and would say I wasn’t exactly a fan of the shift. The reputation for Rails to be a resource hog and putting much of the database handling directly in hands of the developers didn’t sit well with me. Migrations give me the heebie jeebies. Over the last few months I’ve come around a little and can see why the guys like it, the framework itself in abstract is a decently clean idea. From the little experience I’ve managed to have playing with it outside work there are a lot of pieces you don’t have to code up that you would in the traditional perl world. I find myself authoring much less code than I previously would, but I believe I could find perl frameworks that will do most of this ( see Gantry). I would say in the work environment to make a change though, it is very hard to justify getting rid of the old if you are not bringing in the new and it’s a challenge to get people energized doing the same thing over again.

My main point that I wanted to make though is that for the developer Rails is easy, for the sysadmin it is not. When running perl apps you really have a standard, which is mod_perl and Apache. I suppose there are other choices out there, but my guess is that maybe 1 in 100 applications run in an environment different than this. In the Ruby on Rails world this is not so simple. First there is the framework you are going to use, which is kind of silly when we are talking about Ruby on Rails as that is the framework, but there seems to be quite a few notable Ruby frameworks such as Merb, Ruby Waves and Camping, thus it’s possible Rails isn’t the only thing to consider. A glut of frameworks one of the anti-perl flags that gets waved. Next you need to look at which application piece you will be running, Mongrel, Thin, Webrick(not), mod_ruby(Apache, Lighttpd) or one of the other host of up and comers. On top of that there will be your load balancing and static serving piece which you could use Apache, Lighttpd, Ngix and more to make up another equally extensive list of options. If you are going to do an application of any decent size you’re going to need that latter piece in there. In my experience, with mongrel at least, your application server it’s going to make a memory footprint to which your largest mod_perl app will look miniscule. Keeping your static requests apart from your dynamic ones becomes a necessary thing rather than a nice option you could add in later if traffic causes problems. Addins which are gems in the ruby world become an issue, in my time I’ve created and experienced some pretty nasty perl module hell. From what I’ve seen with gems thus far it’s not a big change to that problem or anything revolutionary to fix it. Why the hell does the latter versions of RMagick need Rails 2.0, to me it seems like Image::Magick telling you it needs a certain version of Catalyst? With all of this in mind since I’m using Redhat, it additionally put me back to compiling things by hand as there are no rpms for the base packages, I always have the option of creating them myself I suppose. As Ruby frameworks are fairly new on the scene there hasn’t been enough time to really congeal around front runners for all of these options and at time I feel like I’m dealing with perl back in 2001.

Rails is nice for the developer, but the sysadmin… not so much.