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.

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.

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.

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.

One of the things that I don’t think people understand about Streamlined is that it is designed for “back end” interfaces. The screens that only a few people see and use to administer an application. For those situations it seems to be pretty nice. I cranked out a small app in an hour and a half this morning that deals with a HABTM situation and it worked out quite well.

In other words it seems to be designed to deal with a very limited scope of a rails app. It will not solve all of your user interface problems. It will just make some of them a lot easier to deal with.

Omni presently has no user interface or logic controlling the handling of information. It’s just models, associations, and tests. It’ll be interesting to see how big it will grow over the next couple of weeks.

This also marks the beginning of our public Subversion repository allowing other developers to access our code via SVN. Currently, the CASLogin plugin is the only source available and only Web Services has write permissions to the repository.

Links

• http://developer.csuchico.edu/wiki/ruby_on_rails:caslogin_plugin
• http://developer.csuhico.edu/svn

technorati tags:cas, wiki, plugin, rubyonrails

Things called a CMS are notoriously complex. Cheers for keeping it simple.

No truer words…

Could Chico use something like this? Doubtful. Will we keep our eye on it? Of course!

That’s it. Did you expect more?