Wherein we write down some stuff that we know.

Archive for the ‘Web Development’ Category

Goin’ Mobile

Thursday, November 20th, 2008

“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.

System Statusstatus_update

Tracking the Applications You Develop

Tuesday, July 29th, 2008

Problem

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.

Tomcat SSL Performance Followup

Wednesday, April 2nd, 2008

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.

Routing Around Damage with Ruby

Friday, October 26th, 2007

We have an installation of some monitoring software. It monitors the accessibility of web pages. It creates static HTML reports. A different report is generated for each “site” we monitor. Separate HTML reports are fine, even preferred at times, except that they are totally useless for getting a bigger picture of what we are monitoring, as there is no way to query the monitoring software for the information we need. “How many sites are 100% compliant?” “How many aren’t?” “How many are over 80%?” Each report stands alone with it’s data encased in semantically poor HTML. Scott had already built a system where we could store the results of the monitoring to give us the big picture we were looking for. But, and you knew this was coming, the data for each report has to be entered in manually.

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.

Able-ity: Chico State’s Web Presence (Part 1)

Wednesday, October 10th, 2007

When the university gets around to redesigning the campus web presence, it will need to meet the following goals:

  • 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”