Saturday, October 21, 2006

My Psuedonym Ambigram



Yeah, so, I haven't posted many ambigrams yet. That's mostly because they're tucked away on a CD somewhere in Freehand 8 format. I need to get around to sorting through them and converting them to Illustrator (I never did buy Freehand for OS X, and now that Adobe's killed it, I've switched to Illustrator); hopefully that goes well.

In the mean time, here's one I did of my psuedonym so I could have an avatar in forums and stuff.

Logo, please!

So, I want to put a silly logo in the header of this page. It looks like this:



I couldn't find a way to upload images for use in the template. Let's hope they let me place this one where I want it...

Sunday, October 01, 2006

Wikipedia Watchlist RSS Feed

Over the summer, I became a Wikipedista to some extent, mostly because I found their pages on Nicaraguan subjects pretty lacking. Since I'm an RSS junkie, one of the deficiencies of the MediaWiki software that was immediately apparent to me was that there was no way to get your watchlist as an RSS feed.

Now that I'm back in school there are so many things vying for my attention that I've mostly kicked the habit. Fortunately, while I was still active, I wrote a script that fetches my watchlist and returns it as an RSS feed, which can be passed in to NetNewsWire through a script subscription.

It's based on a PHP script that I found here. The original was localized to the French Wikipedia, and, it turns out, didn't work at all for the English one without some serious modifications to the parsing code. It also needed to be placed on a web server, which is less than convenient for most people. PHP has the ability to run as a command-line SAPI, so that problem was easily solved.

It's been up on my user page for months, and I have no idea if anyone uses it. It's been great for me, though. I can keep up with developments on the articles I care about without having to remember to check my (infrequently updated) watchlist. Enjoy.

The Case of the Missing Trailing Slash and the Nefarious Port 16080

I recently had to deal with a very oddball problem at work. We are running a web server with Mac OS X Server, which we recently upgraded to version 10.4. After the upgrade, everything seemed to be working fine...mostly. Except for one thing.

If you were to type, in your browser, www.website.com/resource/, you would get to the desired resource just fine. Note that I have bolded the trailing slash, mostly because I can't bold it in the next example because it won't be there.

if, on the other hand, you typed www.website.com/resource (no trailing slash), which is actually the far more common behavior, the URL would be transformed into www.website.com:16080/resource, and the browser would stall waiting for a server that was never going to fill the request.

Thoroughly stumped, I turned to Google. It seems this is a problem that others have had as well, which is a relief to me because it means I'm sailing in charted waters. Everyone said that turing off the Web Performance Cache fixed the problem. So, I tried it; I went into server admin, edited my virtual host, and unchecked the "Web Performance Cache" checkbox. Lo and behold...the problem persisted.

More Googling revealed the nature of the cache. It is a feature specific to Mac OS X. When it is enabled, a caching daemon runs and sits between Aoache and the outside world. It is the cache process that serves all of your pages, fetching them as necessary from Aoache and serving them from its in-memory cache if they are available. Ok, that's kind of neat. I also learned that the cache process communicates with the server process over port 16080. Port 16080...the same port as shows up with every trailing slash...it's gotta be the performance cache...what gives?

I wanted to see if my turning off of the cache was actually taking in the OS. Googling to discover the process name (it's webperfcache), I came across this document that explains that the process would be running as long as the cache is enabled in at least one virtual host. I checked, and the process was indeed still running. We had multiple virtual hosts, so I checked the others, and sure enough, the cache was still on. I disabled those too, and *POOF*! Our server functioned properly again.

Case closed!