I build a lot of Rails apps on a regular basis and each one I add to my server takes another bite out of my limited resources. The way I’ve traditionally setup a new Rails app was using a Mongrel cluster. I found it to be a lot more reliable and faster than the fcgi approach people use to use (and some still do). The downside to setting up a few dozen Rails apps on your server with each running a Mongrel cluster is that it eats up all your memory. One of my sites is starting to get a lot more traffic than it has been in the past and its putting additional strain on the server. As a result I decided to find an alternative to Mongrel. I’ve tried searching for alternatives in the past but everything sent me back to Mongrel. Until today of course when I came across Jamie Flournoy’s blog about mod_rails.

Excited for an alternative to raising a pack of resource hungry mongrels on my server I installed the gem and tried it out. It was exactly what I was looking for as far as ease of use straight away. All I needed to do was stop a mongrel cluster and simplify its virtual host directive in Apache to leave out the mod_proxy_rewrite and the other wonky rewrite rules. The first app I tested went smoothly but suddenly the server started misbehaving. Resources were being eaten and it wasn’t clear what was doing it because the app I was testing with is behind an Apache password and I’m the only user. I ended up having to turn off the mod_rails to get my system back in control. The problem turned out to be that by default mod_rails tries to test if your virtual host directory is a rails app or not. I have a few apps that I tossed in an instance of Wordpress into a blog directory inside my rails app directory. I found it convenient to toss them all into the same directory since its all the same website. As a result mod_rails was doing a ../ check to see if the blog directory was a rails app which it decided it was. That’s where the craziness came in because its a php application. Anyway, the quick solution was to move the blog directory out of the Rails app directory.

Other than that my memory usage is way down. I’ve migrated all my low traffic sites to mod_rails and I’m happy with how they’re performing. There is a little delay on the initial load of the app but subsequent calls are quick because its already loaded. I can wait an extra 2-5 seconds for my low traffic apps to load in exchange for hundreds of extra megs of free memory.

I haven’t moved over my higher traffic money making sites yet and I’m not entirely sure I will until I’ve tested mod_rails a bit more. I’m extremely happy with the results thus far though.

Its been a long time coming but we’ve finally got our new site design finished for Onomojo. We’ve also expanded our services to include graphics design, logo design, web design, and a whole slew of other graphics related services. That’s in addition to the services we already provided which were primarily programming, seo, and marketing related. Here’s a screenshot of the new design.

I’ve made the leap and I’m starting to use Rails 2.x for all my apps now. Overall it was a pretty smooth transition over to 2.x. One thing I noticed immediately after running the scaffold generator, ./script/generate scaffold Something, was that the layout template was named something.html.erb. What’s this new .erb extension I thought to myself. I did a little searching and found Ryan’s Scraps where he explains the reason for the change. Its all about semantics. Notice the post date was back almost a year ago.

It makes me want to reflect about Rails in general. Am I really a year behind here? I’ve been developing in Rails for a few years now and love it for all the right reasons. One of the most important facets the framework offers is its constant adaptation to better ideas. The Rails project seems to be one of the most fluid projects I’ve ever seen in terms of embracing new and better techniques for doing things. I think that simple fact is what gives it an edge.

In this industry, a developer has to constantly stay ahead of the curve and always be thinking of how to do things better. I end up getting into the trenches and working on a project for a while but by the time I come up for air I’m doing things the old way already. Here I am upgrading my skills to Rails 2.x and I’m already feeling like I’m old school. Rails apps move quickly and if you don’t pay attention you’ll just as quickly get behind. Other frameworks seem like they’re more consistent over time and as a programmer there’s often little to learn on new releases. Rails is different. It forces you to reconsider what you already know. Take routes for instance. Now everyone is using RESTful routes. You learn the old way and they reinvent it under your noes. Its a beautiful dynamic that forces me as a developer to stay on my toes and to constantly improve my own skill set.

One problem that I face, however, is the complexity of managing multiple project across multiple Rails versions. Rails luckily allows me to freeze the framework into a project so my problem isn’t in incompatibilities. Its in the complexity that arises from having 20 or so projects all running different Rails versions. Some of my projects run older versions of Rails 1.x. Some run the newest 1.x version and even newer projects are now running 2.x. Sure you can say that I should upgrade all those projects but that works in theory. In practice, however, resources are limited and some projects have a priority over others. Time is limited so its usually spent where its needed most. Smaller projects fall through the cracks and sooner or later they seem like old legacy apps even though they’re only maybe a year old. I suppose its just another part of this industry: dealing with legacy systems. Not every legacy system can be upgraded to the latest and greatest. Of course the purist programmers out there want to keep everything current and doing every single best practice you can consider best. Practicality reins supreme though and resources will always remain limited. The best any developer can do is to constantly try to reinvent themselves and never close the door to new ideas. Once you become comfortable in what you know is when you’re going to miss the next big idea.

Let me start off by saying the project I work on suffers some major flaws from lack of any testing framework to a lack of any design structure at all. For the past few weeks, I’ve been tasked to research our options and find a framework that fits our particular project.

I searched long and hard and there isn’t any doubt in my mind that Ruby on Rails is the best framework available right now and it fits our project perfectly. There’s just one hangup for the team: Ruby. Most people haven’t even heard of Ruby (head in the clouds or they just aren’t web developers). Today in the morning, the boss told me we were going with Rails. The word spred quickly and within minutes he was hounded with objections. The Java kiddies don’t want to learn a new language and want to have Java on the resume. Other folks would prefer C# to Java. And everyone else, I’m not sure they know enough about web development to really make a good arguement one way or another.

I was tasked to find the best framework for our environment and I did. Later in the day, I was told we were going with Java due to popular demand. Basically the Java guys threw a fit and said they’d quit because it won’t benefit them to put Ruby on Rails in their resume. I say screw them. The direction of the project shouldn’t be determined because of what someone want’s to put on their resume. It should be determined based on facts and the facts are that Ruby on Rails (RoR) is hands down the best framework. There really isn’t any argueing that. What people are argueing is that Ruby isn’t popular so we shouldn’t use it.

Corey mentioned that we could still benefit from the power of a scripting language and use a Java framework. He was talking about Jython or JRuby. Since the Ruby ship has apparently sailed, Jython is looking better and better. Alex Greif has a blog post about using Spring as the framework using Jython for the controller actions. Thomas Risberg talks about something very similar in his blog. Let’s take that one step further and integrate Jython into Velocity as mentioned by Jason R. Briggs. This essentially takes Java out of the picture as far as development is concerned. Combining these two approaches will allow us to use a Python for both the view and the controller. Of course there’s still going to be all those XML files to deal with but I suppose we’ll have to live with it.

I tried to slowly introduce Ruby to members of the team but when I did they just seem dumb founded at where to begin and didn’t really even seem to put much effort into learning something new. I think the Python approach might be an easier sell to the bosses since they’re Python programmers and the Java guys are going to have to learn a new language and develop with it whether they like it or not. Good developers shouldn’t be affraid to learn new things and those that are certainly shouldn’t have an influence on major decisions. I’m no expert at Ruby on Rails (RoR). I only looked at it seriously for about two weeks but I certainly feel confident enough that I can go build whatever I need to with it. In fact, I already had a prototype for our project built in Rails which I did in two days. It’s practically fully functional.

In the end, the decision needs to be concrete by this Friday. The funniest thing is that I’m tasked to fix up the trade study document justifying our position. I wonder how that’s going to look in the end? I’ll try to post an update as to our direction next week when all is said and done.