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.

There are a ton of applications being developed locally at your institution and you have no way of knowing who is doing what or how they are doing it. You don’t know what data they are pulling, where they are pulling it from, what they are gathering and where they are storing it all. You don’t know if you’re re-inventing a wheel that another department already developed. Worse, you don’t even really know what defines an “application.” Even if you did know all of those things, how would you keep that knowledge current? You, are in the dark.

Welcome. Unfortunately this isn’t a typical IK post where we go into detail on how to deal with a technical issue or show you pretty stat graphs. No, this is where I’m simply going to outline the issues associated with this problem and hope that somebody has already gone down this path…and that it didn’t lead to madness.

Defining an Application

Is a script an application? What about a script that takes form input and sends it to an e-mail address with no database involved at all? How small do you go? Before you start you need to agree on what makes an application. This, could take a while.

Finding Applications and Developers

Once you’ve establish what constitutes an application, now you have to find them and more importantly, the people that made them. It’s a typical problem and luckily one that has been solved before. You need to start as high as you can and start working your way down until you discover the technical people. You probably already know a good portion of these folks, but there are undoubtedly people you don’t know about that are developing and maintaining applications somewhere on campus. If you’re going to be thorough, you’ll need to find them.

Tracking

If you’ve tried to keep track of anything on campus you’ve most likely discovered that unless it’s fully automated, you have a problem. Scratch that. You have problems. Plural. You can ask people for updated information over e-mail, which will get you a few well-meaning responses and a lot of crickets. You can send out a spreadsheet for people to updated which will leave you in ‘multiple file revision’ Hell. You might even be so bold as to develop your own application that will allow people to update their own information online. You might even have asked at some point, “How hard can it be?” The problem is that no matter how easy you make this, you are essentially asking other people to do something for you, and therein lies the rub. How can you ask people to do this for you? This is more a people problem than a technology problem, but it’s a problem nonetheless.

Permissions

For the sake of argument, lets say that we’ve solved the people problem of getting updated information with the application we developed. Now, who gets to see what once they’ve gotten inside. If it is locked down so that people can only see their own information, you’ve created a system that requires them to do work with no real value to them. There is no real benefit in a person only seeing their own information. They’ll most likely want to have access to all the information so they can see what others are doing as well. That was the whole point of the application in the first place, right? So, you open the system and have no restrictions on who can see what. That idea is scary to a lot of people and more than likely they have valid reasons for being wary of this venture. Again, we’ve run into a people problem.

Summary

We have a blind spot on campus and we want to use technology to help illuminate ourselves to what is happening. The technology solution requires that campus agree on a definition, dedicating time to keep the information current, and who has access. These are things that must be dealt with by people. These are issues which no matter how much technology you throw at them, they will not go away.

Solutions?

Have you tackled this dragon? Did you win? If so, we would love to hear your story. Actually, we would love to hear your story even if you lost.

Previously I talked about improving the SSL performance in Tomcat simply by upgrading the JVM. Here we have a somewhat not-to-scale chart showing how we did in a “real world” test. Last night at 6pm an application opened up and sent a flood of users to our authentication service (CAS). Last year we could not handle the flood. CAS stalled, which caused a flood of calls to the help desk. In the business, we call that less than optimal.

We’re rolling CAS on Java 6 now and SSL performance is no longer an issue.

This, will just not do.

Scott crafted a plan wherein his software would expose a RESTful web service that would give us the current state of things in XML. A glue script would be written that would query the web service, find the static HTML report location, scrape the information we need from each report, and then finally update the information in our custom reporting tool.

Now, I’m not a huge fan of scraping HTML for content, especially semantically poor HTML. Design changes cause breakage. Luckily, there is Hpricot. It does quite an amazing job of taking crud HTML and letting you parse it as if it were XML. Less chance of breakage is always good.

The script is completed and runs from cron every night. Manual data entry just isn’t our thing.

• Accessible
• Manageable
• Usable
• Findable
• Flexible

If implemented properly, Web Content Management would be a great tool for making inroads toward achieving the first three: accessibility, web document management, and usability.

By placing the onus for accessible templates in the hands of developers who understand accessibility and how to create standards based solutions, the campus can ensure that all new sites created in the WCMS are accessible.

A WCMS solution will also play a significant role in how manageable documents will be on the web. Centralizing and standardizing the workflow should make it easier for departments across campus to publish content to the web.

How usable the web site is will depend on many factors. One way to ensure good usability is through centralizing the creation of template sets with those who practice design with usability in mind.

Stay tuned for Part 2 of “Able-ity: Chico State’s Web Presence”

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.