November, 2004:

Know any engineers in Portland? Jive is looking for two contract positions to fill immediately:

Java Web Application Consultant

Systems Engineer

Given the amount of comment spam I receive, I’ve been thinking about different techniques to stop it. One of the more powerful approaches is to require users to enter text that they see from a visual image, usually a grainy or distorted picture representing various numbers and letters.

Of course, this keeps blind users from being unable to register for anything that uses this type of authorization system. This got me thinking about ways we can protect from abuse but also ensure that the disabled aren’t shut out.

Searching on the web, I found Why blind users can’t register at Slashdot and the PayPal approach definitely sounds interesting. Another idea that would work for even deaf-blind users is to introduce a Disabled Computer Users Registry and come up with some key-based system that could be used to bypass these abuse gateways.

Of course, if a key is leaked, the abuse can still happen, but that should be much easier to track down. Or maybe another technical solution could help out (such as something as primitive as a hardware dongle).

Anyway, I’m surprised that nothing like this exists. If anyone knows of something similar, please let me know. If not, I might try to pull something together in the coming months. It’s unfortunate that technology is leaving more and more disabled people behind. I know we can all do better.

Last night I installed Half Life 2. The install was a bit of a pain in the ass. Not only because it was 5 CDs (hey Valve, ever hear of D-V-D?), but because you had to register online to play even the single player game. That wouldn’t be a problem except that their servers were having a really hard time and so it took 45 minutes before the game would even start. That’s OK though, I’ve been waiting over 3 years for this game anyway, so what’s another 45 minutes.

It was worth the wait.

I started up the game and quickly realized that my computer wasn’t really set up for gaming on my monitor. That is because my PC is actually in my living room and I run USB and VGA cables around the corner to my desk. Fortunately, my PC also outputs component output to my HDTV, and so all I needed to do was to try to play the game on that.

I was a bit worried because other games (ie: Doom3), don’t support widescreen and so playing on on my TV was not only sucky, but the burn-in effect worried me greatly.

Fortunately, Valve wasn’t as dumb as Id. They offered a widescreen (16:9 and 16:10) option, so all I needed to do was run the game at a beautiful 1920×1080 resolution. My video card was able to keep up fine (Radeon X800 Pro), and the game played flawlessly in an otherwise not-too-friendly PC environment (also known as my living room).

This is definitely the future of computers and home entertainment. “Convergence” may be a nice buzzword, but it really is the way of the future. After playing Half Life 2 in such high detail while on the comfort of my couch, it is clear where things need to keep moving. (Keep in mind I already use my Xbox’s HD output, but very few games support resolution as high as 1080i).

To make a long story short: last night I probably enjoyed one of the finest moments in PC gaming history. I was able to play one of the most anticipating games ever (and one that has delivered thus far) while playing with the hardware and environment that can’t be topped.

I feel special.

I’ve finally decided how I can make WebWork’s client side validation really work for you. Rather than relying on JavaScript code that is equivalent to the rules on the server side (such as regex, range matches, etc), let’s just avoid JavaScript all together.

Huh? Let me explain:

Right now WebWork’s client side validation library requires that code be written in two languages: Java and JavaScript. I propose that we stick with writing validators in only Java.

Rather, we use JavaScript and XmlHttpRequest to communicate with the server side and check for validation on any onChange event. This would allow for people to any validator they want, avoid worrying about JavaScript, and still give the effect of client side validation.

A sample scenario would be this:

1. User enters a negative dollar amount to withdraw from a bank account.
2. User presses tab, switching the focus to the next form element
3. The onChange event is fired off, sending a request to the server asking if the particular field for that form is valid
4. The response indicates it is invalid (along with the error message)
5. The onChange event parses that response and uses DHTML to insert the error message in to the form, just like server side validation looks like.
6. The user is unable to submit the form because there is a token called canSubmit that is now set to true.

This of course would only work for browsers that support XmlHttpRequest, but that’s OK. For the browsers that don’t, we’d just disable client side validation and let server side validation take place.

This would also be a great start for the future of WebWork: providing a richer set of server-side data binding entirely on the client. In essence, this begins to push it a bit more “even driven”. What do you think?