March 2005 Archives

It has been a crazy long time for me not to rant. But Mr. Rant is back and on a repeat of a previous one, no less. September of last year, I posted a not on my old blog---which has apparently stopped functioning...oh well. I'll dump its content into Andrew.Sterling.Hanenkamp.com Blog 3.0. Anyway, I mentioned a few work Pet Peeves. Well, the last few months have given way to a few new ones and I also wanted ot make a three other comments.

One: My job is completely bipolar. It is either way cool or way crap.

Two: My job is way cool because my boss is cool. Dr. Virg Wallentine is da bomb. The toys are nifty-awesome. My employees are easy to manage and are quite capable. I have flexibility in how the systems are managed, so long as I do my job well. My job is cool.

Three: My job is crap because flexibility disappears when things go wrong. Things go wrong about 50% of the time and when that 50% starts (and even ends) is completely unpredictable. I can be having a great day and someone pops in and says, "Is there something wrong with mail?" The great day becomes completely eclipsed by the ensuing hellish one. Which brings me to the second part of this, I just about only hear from folks when stuff breaks. That's the nature of the work; if you fix broken stuff for a living, nobody talks to you when it ain't broke.

Anyway, if you ever pop into my office and get the LookOfDeath(tm), it's probably because you just interrupted Two and I am trying to steel myself for a potential Three. Okay, on to my pet peeves...

But first, the disclaimer: I love my job despite its inherent frustrations. I really like helping folks out and this job is all about helping people. I also want to say that if you've made yourself a nuisance through any of these peeves, this is nothing personal—just don't do it again! Finally, these are mostly directed at students. Faculty and staff are allowed a bit more leeway in a lot of things because we just don't expect as much from you...er...umm...moving along. ;)

Here go...weeee...

1. Asking questions that are answered already. Search our site for docs before asking questions. I don't know how many times someone has sent me the message saying, "How do I connect to the Oracle server?" To quote Ren, "You eediot!" Check the FAQ on the support site. The User Guide and FAQ are quite helpful. Read them.
2. Replying to a resolved ticket to say, "Thanks." ARG! Thanks for more work. Now I have to resolve the ticket again. We work a thankless job, we'd rather keep it that way.
3. Subject lines that say nothing useful like, "HELP!" Help with....what? Or, perhaps worse, "Can't access mail." Subject lines should be helpful so we can get a quick idea on who should take care of it and it's urgency. I suggest never using the word "help" in your subject. Rather, say something meaningful. "Cannot download email via IMAP" "Mail error: Cannot contact imap.cis.ksu.edu" "Progress bar for sending email never goes away in Thunderbird" Each of these would probably be handled by a different student. Descriptions like this help my students know, "Ah, that's my problem." Otherwise, tickets tend to wait for me to assign them and that can take hours longer.
4. Subject lines that use lots of exclamation points, "I need access to X!!!!!!!!!!!!!!!" These messages tend to turn the systems staff into boiling cauldrons of rage. Angry geeks are frightening to other geeks, but probably a little comical to the rest of the world. Please, don't fuel the worlds fire to laugh at us more.
5. Over explanation. If you need something, tell us what the class or project is named and the faculty member involved. We don't need anything else, or we can ask for it. Giving us a 10 page dissertation on the exact nature of your needs usually just makes it harder for us to find what's being asked for.
6. Whining. I've gotten a fair share of nasty letters (probably 5 to 10 in the last year or so). Such hate-mail is whiney. We have policies, we have them for a reason. If you don't like them, you can either try and talk to us and figure out why we have the policies and use that information to make a suggestion, or you can deal. Screaming doesn't help the problem. Assuming that we're unreasonable power mongers is insulting rather than constructive (not that I would dispute that fact ;).
7. Asking for help without detail. My staff and I aren't prophets, psychic, or otherwise magical. Sending email stating, "Hi, I cannot connect to SSH" is meaningless. You've just guaranteed the maximum possible delay to getting any substantive help. What computer were you using? Where are you? Are you at home? Are you in Nichols? Are you in a campus lab? Are you on a corporate network? What program are you using to connect? Which host did you try to connect to? Did you get an error message? At what part of the process did it fail? Giving a complete explanation will give you the fastest response because we'll spend less time asking you these questions and can instead start fixing the problem.
8. Begging for help "ASAP" or giving us a ticket at noon saying, I need this by 2:30 pm today for an assignment. Sorry, dude. You should have planned ahead. We prioritize everything according to the same system, and your statement of urgency is not likely to be an important factor. The systems staff has a complicated list of tasks to do (usually between 100 and 150 at any given moment). These tasks are carefully prioritized by the significance and nature of the problem and based the role of the person who sent it. Unless your request is completely trivial, our turn over is probably going to be longer than 2 hours. My students are part time, and I have a class to teach. These factors interfere. Unless your task is critical or an emergency, we may not even get to in the same day. Large tasks, such as those that require changing policies or installing applications can take weeks. Unless you can convince the department to give me a much larger staff and we can somehow shunt aside the fact that this is a state University and we just take time because of flat beauracracy, you'll just have to be patient.
9. Sending us your username and password. Okay, this made it into my list this year because a student did this recently. I believe the joke immediately was something to the effect, "You start enrolling him in classes, I'm going to go take a look at his financial records." Don't ever send anyone your username and password. Your password is your personal secret. Giving that information away is simply not smart.
10. Stepping behind my desk without being asked. This is a personal pet peeve of mine. I like to have a certain amount of personal space and keeping you a few feet away at least makes me feel a bit more secure about typing various secret passwords into the machine while you are in the room. Please don't step behind my desk. My employees will make fun of me for this one I'm sure, but pride be damned, this annoys me.
11. Leaning over my shoulder or stepping within a couple feet of me to talk. This creeps me out. Again with the personal space. Step back, please. I'd really rather not know how recently you bathed.
12. Asking one of my staff for something and then asking me, or vice versa. This is the old trick every 4 year old tries: "Mom, can I do X?" "No." Go to the next room. "Dad, mom says that I can do X if you say it's okay." This is annoying. I have pretty good hearing when my door is open and my music is turned down. If one of my students says, do X to get your problem solved. Do that. Don't come to me and ask the same question again.

So that concludes this year's edition of "Pet Peeves." Thank you and good night.

Nifty. After a harrowing week of work between putting out fires, keeping up on other projects, writing an exam, and dealing with some other class related issues, I finally managed to get the major changes need to the forms API complete. Because of these changes, I was able to move the CIS Knowledge Base over to Contentment this afternoon.

The major "coolness factor" for the CISKB is that the new form handling API will allow us (or principally, me) to add handy new features to the CISKB. Currently, there are only two forms on the site: change password and account application. The new account application is neat because it uses our newly acquired access to KEAS to verify that every account has a matching KSU eID and then attaches the user's unique identifier to the application, which will be used to create the account (once I make the minor changes needed in the account management software).

I plan to better integrate the Knowledge Base into RT to allow us to post a "Known Issues" page to help keep those pesky repeat tickets away. I also want to add some specialized forms for things like requesting file recovery, requesting help when email and account access aren't available, etc. I also want to setup a form for allowing students to automatically reinstate their account if it becomes disabled because of printer fees, password expiration, lost password, etc. There are a lot of mundane things that the systems staff deals with on a daily basis (especially around the start of each semester) that we can drop onto the web site.

As for Contentment proper, I want to port one more web site to it before a formal release, i.e. Andrew.Sterling.Hanenkamp.com. In the process, I also hope to improve the Contentment.org web site and drop some decent documentation in (er...create the documentation that is largely non-existent).

Once I start on a problem I have a difficult time letting go until I have a solution. I mentioned forms processing in my last entry and I have been crunching on it ever since.

I have found that the major problem with the original design had more to do with a poor OO methodology than a bad design. I just need to get the pieces separated into the correct objects. Therefore, I've build a new OO API for forms processing.

Okay, I've separated the system out into the following pieces:

• Context - a transient object that collects all the information pertinent to the current request
• Session - a persistent object that collects all the information connected with a particular user's session
• Setting - a persistent object containing application-wide settings
• User - a persistent object containing information about a user that exists across sessions
• Form - an object stored in Settings that describes the structure of a form
• Submission - a transient object that exists initially when a Form is written to a response and again if the user POSTs that form back in a request
• Action - a functor object that performs some action using data from a processed Form Submission
• Widget - an object that both renders some set of controls in a response used to form a POSTed request and a functor that performs some processing of Submission data on behalf of a Form before the form's Action is executed
• Map - an object used to determine how the response should be constructed when interacting with a Form
• Panel - a box in the response containing whatever object the Map says it should contain, the topmost Panel, __DEFAULT__, can be used to affect the entire response

The use-case is basically like this: The response has a Panel placed in it (possibly the __DEFAULT__). This Panel specifies a Map, which determines what sub-response to place within the Panel. Typically, this is some sort of Form, to being with. The Form is drawn to the response and stored in the Settings (keyed by a application-unique name). The Form determines the Action that is run on the receipt of an activated Submission. A Submission is initially created to associate a UUID with the submission and to remember the Map used so that an activated Submission received later will operate according to the original Map behavior. Finally, the user gets a copy of this form in her browser and fills in the details of the form. Once filled, the form is submitted back, which creates an activated Submission object. The Submission object then causes the Form to process all the incoming information via it's Widgets. Assuming successful processing by all Widgets, the Form then runs the Action. Based upon the Action result, the Map is then used to determine how to render the response. This generally involves an immediate 302 Redirect to the next page in the Map and then the Map is used within that page to determine how to render the content there.

Phew! The details of this whole process are almost entirely handled internally to Contentment (or will be when I release the next trunk revision). The only the thing the programmer will have to do is to create a Form with Widgets, create an Action to handle the Submission, and a Map to determine what to do next, based upon the output of the Action. This creates a nice HTTP-centric MVC architecture where the Action/Map form the controller, the Submission forms the model, and the Form/Widgets form the view.

Contentment is currently running two sites: Contentment.org and ~Sterling. I'm currently updating the CIS Support Site to also run under the new software. The process of conversion is pretty simple since a lot of what Contentment is came from the "knowledge base" used there.

I've discovered a few minor flaws in Contentment at this point that will need to be addressed soon. Primarily, to this point, the forms system that I've built is rather badly unfocused. I made some assumptions (which I stupidly did not document), which no longer hold. As such, I need to refocus the design of this subsystem as it is a major feature. This has come into play because two of the most important pages on the CIS Support Site are the password change and account application forms.

The forms system is actually very good at handling complex forms situations, but as for simple stand-alone forms, it sucks. Anyway, I just wanted to cover the basics of web forms and why they are a complex situation to be resolved.

Current HTML forms are dumb. Eventually XForms will replace them, but until then this system operates within the restrictions of HTML forms. HTML forms have a very small set of possible controls: text boxes, password boxes, checkboxes, radio buttons, buttons, popup boxes, list boxes, file uploads, and text area boxes. The HTML form also assumes that a given form only addresses a single action at a time, which is a very difficult limitation to live with if you want to do something even moderately complicated (like updating more than one record at a time).

This limitation can make having multiple nested forms very difficult or impossible (especially since a form tag cannot be embedded within another form tag). Even having multiple separate forms on a page can lead to complications. As such, I created the idea of "panes" where each form exists within a pane. Then, a pane may contain other panes and thus nested forms. Upon submit, the forms processor is run and processes all submitted panes that have had their "activate" field set. This actually works alright, but what if we don't want to use a pane? Well, that isn't handled so well.

Another problem with forms is what to do with the form when we're done with it. For example, what if we want to have a login form. We might want to have logins available on a stand-alone page or as a part of the side-bar. If a stand alone, where do we go after login? If a side-bar, do we return to the current page on success? Do we go to a special error page on error, or do we just report the error in the sidebar on the current page? Thus, I added a "map" system that allows pluggable module to determine how each action state is handled. This is a bit of overkill for very simple forms.

Beyond this, the system is a little esoteric. It requires a lot of extraneous API knowledge that could be simplified. There are also a lot of features that are a little out of place because of the time span that was involved from the start of the forms system and today (I started the forms system early last year). Anyway, this thing needs a bit of work and will probably be pretty well rewritten for the 0.9 release.

My next plans for the current revision are to reconstruct my blog aggregator and create a blogging plugin. I was thinking of rewriting the VFS to add it's first non-real-file-system plugin, but I think I'll create the plugins using the file system first and then try the VFS update afterward. I think it will make the VFS plugins a little more interesting if I start without them and then add them in later.

I need to also start posting documentation on the Contentment.org web site this week so all of this makes sense without having to read the code. So much work to do and so little time...