WonderProxy - Server Status

nospam@example.com (Paul Reinheimer) — Mon, 04 Jan 2010 13:59:00 -0500
A few weeks ago I launched the WonderProxy website, one of the first decisions I made when working on it was the network status bar shown on the left side. That's a nearly live showing of the state of all the servers in the network (as of when the page loads).

What I Did
The box with Nagios running on it runs real tests against all the proxies in the network on a regular basis. I do mean real tests: it uses curl to make a request against a script on a different web server, which checks the headers to ensure that the correct headers are being used. This checks: the proxy is running, the proxy is listening on the correct port, the proxy is able to authenticate users, the proxy is able to retrieve remote documents and return them. Every minute the Nagios box collates the data for all the servers and creates a .json document. That document is then pushed to the web serving machine, ready for consumption by obliging clients.

Note, I've said "what I did", in reality the JavaScript ninjary was done by Christine, and the curl ninjary was done by my obliging sys-admin Will

Why I Did It
Presently, I deal with upwards of twenty hosts between professional and personal projects, that's a lot. I've probably dealt with another ten that I’ve terminated relationships over my professional career. All in all, I’m sick of the hoops that they make me jump through to find out what's going wrong.
Here's a typical outage for me:
0 minutes - Nagios notifies me that something is wrong
+2 - I've logged into nagios, and attempted to log into the affected system for more information, confirming the outage
+9 - I'm on the website for the host of the affected system, finding absolutely no helpful information.
+10 - I've started trying to figure out what my login credentials are for the affected system's hosting provider.
+11 - I've logged in, found no more information
+12 - File a ticket with the host
...
+35 - Nagios informs me that the service is back up
+90 - Host replies with some generic "something went wrong on our end, we fixed it, we may credit your account with $0.12 later" message.

I argue this is patently absurd. Some companies put on a front about being better about this sort of thing, but then an outage occurs and the one girl/guy with access to the twitter account is on vacation, or asleep, or at the movies so nothing happens.

When my box goes down its either my fault, in which case I need to start working my rear end off to bring it back up, or the host is experiencing a real outage, in which case I should just sit on my hands and wait. In that typical listing I've indicated above I don’t know which situation I’m in until 90 minutes on, though I can start poking at logs 35 minutes in.

What I Hope This Means

If you're a WonderProxy customer running tests and something breaks, you can log onto the WonderProxy website and know immediately if the proxy is broken, or if you should be looking harder at your own infrastructure.

Thoughts? Does your host do better?

Functional URLs - More than Developer Vanity

nospam@example.com (Paul Reinheimer) — Fri, 04 Dec 2009 09:36:04 -0500
I read David Sklar's post to the PHP Advent calendar this morning, and as the title rather clearly points out, I disagree with his conclusion.

Before I go any further I'd like to clarify something in the title, namely the word "functional". I'm using this meaning from dictionary.reference.com:

having or serving a utilitarian purpose; capable of serving the purpose for which it was designed: functional architecture; a chair that is functional as well as decorative.

If you define a URL's purpose as simply being an instruction to a browser or other application, then sure a URL such as this one qualifies:

http://www.realtor.ca/map.aspx?&vs=VEResidential&beds=0-0&baths=0-0&minp=0&maxp=0&area=Montreal%2c+Quebec&trt=2#acr:false;ac:false;baths:0-0;beds:0-0;fp:false;gar:false;pmin:175000;pmax:200000;rmin:0;rmax:0;openh:false;
pool:false;stories:0-0;buildingstyle:;buildingtypeid:;viewtypeid:;waterfront:false;forsale:true;forrent:false;orderBy:A;sortBy:1;
LisStartDate:;mapZ:12;page:1;mapC:45.49792488715173, -73.56531143188478;curView:0;

That said, the only purpose of a URL isn't to give an instruction to a browser or other application. It's an indicator to the user, telling them what the page is about, and one they use quite a bit[1]. It's an address that does still need to be typed on occasion, or at the very least copy/pasted into a variety of mediums. It should be a destructible resource that users can use to navigate the site and obtain what they're looking for.

Compare:

store.example.com/plv2/product.php?refid=4AF82BC932

and

store.example.com/toys/dolls/barbie

In the first case you're stuck, there's no options to you for navigating the site beyond the on screen options. In the latter case you can move from looking at Barbie, to looking at all dolls, to looking at all toys, to looking at the entire product line of the store rather easily. I will concede that not all users will think to navigate in that manner, but some will, and they have the option.

In conclusion: URLs are more than some text an end user clicks on, and having good ones has more worth than letting the developer look cool in front of their peers: It's an actively used resource. Having clear, functional URLs is a worthwhile goal for any web property.

[1] Jakob Nielsen's Alertbox, March 21, 1999: 2007 update at the bottom.

p.s. I may receive a beating shortly for the rather ugly URL this blog post possess while standing on a soap box shouting for better URLs. Software I build myself does include more functional addressing, compare wonderproxy.com/servers/Miami/ and wonderproxy.com/servers/ (I'm working on the case sensitivity thing).

noreply@ Needs to Die

nospam@example.com (Paul Reinheimer) — Thu, 19 Nov 2009 21:02:47 -0500
It's 2009, there's absolutely no reason to make it hard for your customers to talk to you. The technology exists now, and has for a while, to import whatever mail you receive into whatever ticketing system you're using. Sure, internally use whatever system you're happy with, there's lots of inefficiencies in trying to handle any volume of support through traditional mail clients. Your clients on the other hand, aren't wizards at whatever system you're using, but they do know how to use their email client.

When you send a client an email, monitor the address and import replies.

Yes, there's challenges, watching vacation auto-responders ("Hi, I'm on vacation! I'll come back on the 20th") and ticketing systems (“Thank’s for emailing Widget-Co, Your email will be answered soonish!”) get into a reply fight isn't pretty. Handling character sets, HTML formatted mail, etc. all present challenges. But these are manageable problems.

The only reason not to import email into your ticketing system is if you don't actually want to talk to your customers.