Institutional Knowledge

“Like an air conditioned gypsy” and other obscure Who references.

Last week one of our mission critical systems hit a bump in the road and was offline a better part of the day. We have a web application called System Status that is used by the help desk to track the availability of such systems. Having resolved all the issues we left the building only to realize that we needed to update the System Status application to notify the help desk and end-users that the system was back online.

Three of us immediately whipped out our iPhones to access the site and change the status flag. At that moment it hit me, why on earth isn’t this optimized for mobile devices? Having found a practical place to experiment with the iUI framework, I set about creating a parallel mobile interface for System Status. This interface, which uses the iPhone interface metaphors, will allow help desk support staff to check and update the status of our systems while out in the field or away on business.

Here are a couple of screenshots to give you an idea of how the interface would look on an iPhone.

Well, it’s be a long, hard road…but we are complete with “Phase 1” of our development of Omni. This application will help the Information Security department deal with the servers on campus. But that isn’t the interesting part. The best part was this is the first application to enjoy living on our new production server.

Previously we were deploying our Rails applications with Apache & FastCGI. It was functional, but not quite optimal. If the FastCGI processes weren’t routinely reaped they would just linger around sucking up RAM. We also ran into a slew of problems while trying to do simple things with Capistrano. All of these problems were our fault and stemmed from the fact that we never cleaned up our production/deployment model once we got things “working.” So we took the opportunity of a new server to get a fresh start on how we deploy our applications.

So, with a clean slate what did we fix/change?

Mongrel & mongrel_cluster

Goodbye FastCGI! We’ve been using mongrel for local development and have been quite happy with it. It’s well written and well documented. We’re deploying behind Apache 2.0.x without using pen or pound in the middle. We are eagerly awaiting RHEL 5 which comes with Apache 2.2 and mod_proxy_balancer.

Running a cluster means that sessions are going to need to go in a central place accessible to each mongrel instance. We choose the database because it was drop dead simple. We’re using a 1.0.x pre-release of mongrel_cluster and it’s been a dream. The Capistrano recipes are so nice to have. We still marvel at doing simple things like cap update_current and have it “just work.” Obviously we’ve been living far too long with a spit and duct tape setup. Good riddance.

Rails 1.2.x

While we were working on Omni, Rails progressed from 1.1.x to 1.2.x. This was a big jump, but well worth it and allowed us to use a few less plugins. The story of taking our existing apps to 1.2 is a post for another day.

A number of things didn’t change. We’re still happy with Subversion and MySQL. Things that come stock with RHEL make our lives easier. Of course, we’re still on version 4 so we did need to upgrade Ruby.

In the last two days, we’ve launched two Rails apps. The first was Omni, a secret sauce intranet application designed to support staff in various issues. It’s been a bit of a beast having taken over 6 months to develop. It feels good to get v1.0 out the door and switch into a triage bug fix mode.

The second app is the Casper Pledge Form which I actually just put some finishing touches on and deployed. Roberta Roebuck was the actual designer/programmer behind the application.

Rails rocks. It make it easy to get stuff out the door and can really aid you in developing larger scale applications. Bug fixes and improvements are super easy with the development model and the logical placement of certain type of files. If you haven’t checked it out yet, do so today.

Now has a Google Group. Join up and introduce yourself.

Scott made sure we got in on the academia thread over at the Rails Weblog. I guess they started moderating their comments because mine hasn’t showed up yet. So, here is what I submitted in case it gets eaten by their system.

I’m at California State University, Chico (Chico State for short) and we’ve developed and deployed four rails apps (mostly internal to the IT department) and have a couple in development. We also run an instance of typo for one of our developer blogs. Our development used to center around PHP or perl for “small jobs” with most of the “big stuff” being done in J2EE.

The J2EE stuff isn’t going anyway (uPortal/CAS), but a lot of the new development, at least in our area, is going to rails. In the move to rails we also jumped from cvs to svn, BBEdit to TextMate and started using Capistrano to ease deployment. We develop on OS X and deploy on RHEL 4/Apache2/MySQL4/FastCGI.

We never want to go back and we’re slowly infecting other departments. Rails is a great tool to have in our box of developer goodies. We got started with the AWDwR book and went on to Rails Recipes and Enterprise Integration with Ruby and of course the Pick Axe 2nd Ed.