Web Development

I recently had a request from one of the librarian's at work to come up with a way to display a librarian's current AOL status (online, offline, away) via a Web page. I spent some time digging around online, but didn't find anything particularly useful. Then I mentioned it to a co-worker, who said he had a snippet of code on his site that did exactly that.

A little digging turned up AOL's AIM Presence, a quick-and-easy utility that allows you to display an icon on your web site indicating your current status. This did the trick nicely, and worked even when logged in via iChat or Trillian (though in both cases, we were using AOL available accounts).

While surfing for information about styling tables using CSS, I came across "css vs. tables", on which one very anti-CSS layout web designer argues in favor of using tables to control page layout.

I'm sympathetic to his argument ... up to a point. When I re-designed Nuketown last year, I went to a CSS-only layout and I regret it; while the design works for the most part, there's really no way to make sure all three columns are automatically the same length (as is the case with tables). I have to resort to hacks, which is pretty damn annoying for a standard that's supposed to be the cure-all for developer blues. Next time around, I'll be going back to tables.

I'm in the process of redesigning my work Web site (and probably the sites for Nuketown and the GriffCrier as well). This time around my goal is to avoid cheating with my code, which basically means I want to avoid using any of the hacks or tricks that Web designers typically use to create a decent looking page.

Examples of such tricks include using tables to control page layout or invisible gifs to force tables, text and images to align properly. Both of these things are sins among Web designers, but we all do them because it's the only way to get pages to display properly.

It's a battle between Man and Machine ... and while the Man's not winning, I'm not doing all that badly.

My first encounter with trying to get my Perl scripts to execute on any Unix box was a brutal massacre that left bits of my geeky ego scattered across my desktop. Like any good general though, I knew when to fall back and regroup. I did exactly that, and decided to try and eliminate as many potential problems as possible.

I expected learning Perl to be challenging, but I never expected to have to work so hard to get a simple "Hello World" script running.

Perl's a server-side programming language, normally found on Unix servers, which is extremely useful for writing all sorts of programs, especially those involving text manipulation. I know some Perl, just enough to read a program, understand its logic and to modify it to do what I want.

I've wanted to delve into it more deeply for years, but have never had the time. Now, thanks to the convergence of a several happy facts I'm making the time.