April 2005 Archives

It's a good thing Terri's coming home tomorrow. I don't think my body can take many more of these late nights. (I.e., my wife is out of town for a conference, so I pulled late nights this week, since I don't when she's home. :)

Background: The latest idea for Contentment, which is the real working idea originally came by basically adding some customizations built with HTML::Mason. Mason is a nifty mini-CMS/embedded-Perl templating system. It's hard to classify because it has a really wide mix of features. It serves files, it provides a layered virtual file system, it provides a templating engine, it provides some fancy features for wrapping content with other content via "autohandlers" and filtering, etc. To paraphrase Strong Bad, "It beats the pants off that ol' washed up the PHP I used to use."

So, I extended it. Initially, I added an indexer and a template system. Well, I had to use some odd tricks to get that to work, but I think Mason still did it pretty well. I added a system for handling contextual and session information. I brought SPOPS into the picture to help out with the database end of things (and then I hacked that because the so-called last S=Security is S=Stupid Security, at least for my needs.) I've added a fancy transformation system, which I've revamped to make it even better. I've added a fancy filtering system to be applied after transformations (which should go through the same refactoring that transformations did). The latest addition is the VFS system. I've written a new project, File::System to handle the new needs I have for URL mapping and the soon to come URL to database record mapping I have in mind.

What does this all add up to? I'm seriously abusing Mason at this point. I've taken my good ol' friend Mason and ripped his guts out, strung them around the room, and replaced parts with my own PVC. Okay, that's disgusting. Man, I go weird at 4am...I should sleep.

Basically, I'm going to have to evaluate things more, but I think that I've already spotted the next set of updates. Mason is going to say, "Sayonara." Or at least, partially. It's still going to be a valuable part of the system, but it won't be the front end anymore, I think.

Anyway, I'm never satisfied. I don't know who said it, but in the "Camel Book" by Larry Wall, Tom Christiansen, and (originally) Randall Schwatz (though, he's since been gypped, I understand), the three virtues of programming are Laziness, Impatience, and Hubris. I think a fourth one to add to the list is Discontent.

Yes, very punny. Good night.

Grrr! I do not like spam. I've added CAPTCHA to my site (via this Drupal module) to prevent it. I got nailed by "online pharmacy" yesterday and I don't intend to have a repeat, again, ever. So, it may be annoying, but all comments on this site will, from now on, require you to pass the Turing test (i.e., Are you human?) by identifying a Captcha image.

Cheers,
Andrew Sterling Hanenkamp

Update: COLE EDITTED MY BLOG!? ---- wow, I can edit your blog!!! YAY

Okay CAPTCHA dies. Stupid Drupal module...yeah. Apparently there are session bugs.

I've been a bit irrate about the mail server lately. This weekend has proven to be a further illustration of why mail services must go. The major reason for handling our own email in CIS is "flexibility." The CIS department likes to have flexibility in the management of its services. This is quite appropriate. However, there are certain services where the need for stability outweighs the need for flexibility. We have a few major services that must always work (in this order):

1. Authentication
2. File services
3. Printing
4. Email
5. DHCP
6. Backups
7. DNS
8. Web

There are probably others. The last four are difficult to order. File services, printing, and web provide three of the services that make CIS separate from CNS. These are core services that we offer and I know that we can maintain any flexibility without offering these. Authentication supports those core features. Everything else could be offered by CNS, in my opinion, without undermining our independence and flexibility.

Email and backups are probably the two services that can be best handled by CNS rather than CIS, in my opinion. Email, in particular, is important at this point because it is the most difficult to support. Email doesn't function correctly if any of the above (except printing and backups) aren't working. Email bounces if authentication stops. Email isn't delivered if file services stop. Certain services can't be found if DHCP fails for very long. Email stops if DNS breaks. Webmail isn't accessible if web breaks.

Of course, this is stil an over-simplification. There are a lot of interdependencies and the "file services" heading contains multiple layers of complexity within itself. Our two most common failures are authentication and parts of file services. These would often go unnoticed, except for the email loss. Most workstations can still function if file services and authentication are a little flaky or slow. Email stops. And when email stops, I get phone calls at home on the weekend.

However, I don't work on the weekends unless there's an emergency. It's one of the boundaries I've set to keep my sanity. I put out fires all week long, I need some time to unwind and catch up on my honey-do, please. Saturday and especially Sunday are generally off time, unless someone calls me. I'm always open to faculty and staff giving me a phone call to ask for help and I will fix things needed.

Of course, the last few times of downtime have had nothing to do with other services failing, but with processes on the mail server maxing out the CPU. Sendmail stops working when the CPU maxes out as a safety precaution (mail processes can get very memory/CPU intensive and can lock up a machine if not careful). Anyway, I caught the machine with an load average of 296! If you don't believe me, here's a screenshot.

I believe my sister said it best, "'Nuf sed."

Phew. If possible, in the future, I'm going to avoid making a major web launch on the first weekend of Daylight Savings Time—quite easily Benjamin Franklin's worst idea.

Essentially, the latest and greatest update for NewHopeKS.org is online. I cut over to the new software last night at 10:00. Anyway, I thought I'd mention a few details of this endeavor.

The new site is Drupal-based. Drupal is the same software that runs this blog, as of this writing. We picked it for a number of reasons. Drupal is popular, easy to understand, easy to extend, has lots of existing extensions, and is probably going to be around for awhile. Thus, if the three of us who are responsible for the web site suddenly moved away, it shouldn't be hard to find someone else to take over. (One must always be careful of volunteer commitments, because volunteers often fail to keep commitments. While Tim, Eric, and I are actually committed, we've gone through this process on the assumption the next person in charge might not be.)

Now, the web site isn't just Drupal—it's the CivicSpace-based distribution of Drupal. For those who know the history of this project, CivicSpace is the decendent of the DeanSpace, which is the software that was used by Howard Dean's presidential campaign web site. At first, it may seem a little odd for an evangelical church to be using this software, but evangelicals are advocates as much as any other CivicSpace site. We just happen to advocate for spiritual change rather than social change. Because of this and other factors (primarily Biblical guidance), we have quite a different M.O. for performing this advocacy, but there are still many similarities.

Anyway, at this time, we're barely scratching the surface of what we can do. As of this morning, the web site is a collection of events, announcements, and informational pages on New Hope. The web site will probably start being updated by church staff in another week or two. Parts of the web site will be modified by other volunteers starting today (especially, the SHAPE section). I am also going to start seeing what we can do about uploading our recorded messages. There's really a lot of work to be done still, but it's a great start.

I'd like to mention that the design of the web site is mostly due to the handiwork of Eric Benson. Unfortunately, he has no current personal web presence I can link to—many domains but no content. ;) I think it looks slick, though, as he tells me, most of the work isn't his, but he's got big-big plans. I can't wait.

Now, for the problems. The biggest and baddest problem of all is that the taxonomy system of Drupal is both awesome and a pile a poo. I'm probably going to patch Drupal according to the recommendations of GreenAsh in his three part series on taxonomy. It's either that or we see if Drupal figured some more stuff out when 4.6 becomes a stable release. The main issue is, that it seems obvious to arrange the New Hope web site into ministries: LIFE Groups (small group Bible studies), SHAPE Groups (small group studies of personal gifts), Construction Zone (children's church), Youth Group, etc. In fact, these things really could be mini web sites in their own rite. LIFE Groups could feature pages specific to each life group. Construction Zone could feature pages specific to each class.

However, Drupal is terrible at this. The problem is that the taxonomy system is too flexible. It can do a breadcrumb trail, but almost all documents show up in "Home". Gah! The reason this happens is because breadcrumb trails are single-inheritence heirarchies, just like a typical directory or file system. The taxonomy system of Drupal allows for mutliple-inheritance heirarchies and even more complicated structures, so a simple breadcrumb isn't possible without enforcing some sort of policy on this system. Honestly, this isn't a problem for me, but it might be for someone else. However, there's no reason I couldn't volunteer to be put under that policy and another site could decide not to be.

Anyway, GreenAsh has found some resolution to this by doing just that, he's established a policy that says that every page must be categorized into a top-level single-inheritance heirarchy. Then, he patched the Drupal source to make it work. I'm trying to decide if we want to do this or not. It would make a nice breadcrumb trail along with making new nodes a little simpler to organize based on the primary category. He also has some nifty stuff for cross-category breadcrumbing, which would be handy in our case too. I think I'll probably do this or some variation to make the New Hope web nicer to browse.

The biggest issue is, what happens at upgrade? Well, as far as I can tell, we're not actually doing anything bad to tables themselves. His patch just seems to nudge the behavior of Drupal in a slightly different direction, and then only in the places of taxonomies and breadcrumbs. The actual data stored in the system is unchanged. I imagine, we could lose some of the features for a time during upgrade, but still have all the raw materials to do it again. On the other hand, if Drupal actually implements this policy or something like it, but chooses to do so in a different way in a future version, this will be difficult to deal with.

However, I think it should be doable.