Having spent a great deal of time with reCAPTCHA over the last few weeks, I've come to appreciate both the clever idea and spot-on execution. Aside from being an excellent product, reCAPTCHA also offers clues to building Web services that people will not just use, but also tell their friends about. Here, in no particular order, are six things about reCAPTCHA that I hope all of my future Web services achieve:

1. It solves a nasty, boring, and widespread problem elegantly. The nastier and more boring a problem is, the more likely that a solution that actually works will be praised by all who use it. Boring and difficult problems create a natural scarcity of good solutions and people willing to work on them. Seek these kinds of problems out; they are a high-probability path to success.

2. It never goes down. Having used reCAPTCHA pretty much continuously over the last three weeks on my current project as well as on this blog, it's never been unavailable. As much as anything on the Web can be trusted to be there tomorrow, reCAPTCHA seems like a safe bet.

3. The business model is obvious. reCAPTCHA "pays" for itself by helping to digitize old books. This is a valuable service in itself that could be monetized in some very interesting ways. Because reCAPTCHA does something valuable beyond just fighting spam, it's very likely that I can rely on the service being around for a long time.

4. It solves problems from two different groups of users at the same time. Consider the giants of the Web: Yahoo, Google, YouTube, Facebook, eBay. What every one of them has in common is that along the way they have discovered how to solve problems from two different groups of users simultaneously. The same is true for reCAPTCHA. Come to think of it, every unsuccessful Web venture I can think of failed to solve two problems simultaneously (most didn't even really solve one). This shouldn't be surprising, but for some reason it is. Could this dual-problem thing be the golden rule of Web development?

5. The Ruby Library Rocks. Although short on examples, the Ruby Library for reCAPTCHA does what it needs to do and gets out of my way. Of course, the actual language is unimportant. What matters is that solid libraries in popular programming languages exist. The number of people willing to experiment with a new Web service is low to begin with - forcing them to develop their library beforehand is pointless.

6. No Limit on Usage. This is where a lot of Web services simply don't get it. I won't name names, but they know who they are. reCAPTCHA allows essentially unlimited use of their service - it's just part of the design. reCAPTCHA does make the reasonable request to "be contacted beforehand if you expect your site to constantly need more than 100,000 reCAPTCHAs solved per day." No access limit means developers can build scalable Web applications based on reCAPTCHA with confidence.

In the end, building a successful Web service that people will gladly tell their friends isn't complicated. It's just a matter of building value and trust.

One more thing. I'm currently using reCAPTCHA on this site in the comments section. There are probably still some browser-specific kinks to work out. If you're so inclined, I would be grateful for a short comment describing your experience, along with your browser and OS.

If you run a blog or website that allows public input, you've almost certainly been subjected to a spam attack. This is a problem because even one successful attack can eat up hours of time. After a recent spam attack on this blog, comments were disabled altogether. They've now been restored with the help of a more robust kind of protection, which is the subject of this article.

One of the best forms of spam protection is the Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA). CAPTCHA comes in many guises but usually consists of a noisy image of some text that a user must enter, like this one from Digg:

There are many CAPTCHA systems. The disadvantage most of them share is that they must be deployed on a server. Depending on your hosting situation and your platform, this may or may not be feasible. D-F is run by the Ruby on Rails blogging software Typo. Most CAPTCHA systems for Ruby require the installation of the C extension RMagick and its dependencies, which is either difficult or impossible on many hosts.

I recently found two solutions to this problem, and have implemented one of them:

• captchas.net This free service generates CAPTCHAs on a remote server, which your own server uses. By writing a small Ruby library and some glue code, I was able to integrate this solution, which is currently running on D-F. Here's an example in action:

• reCAPTCHA Not only does this service generate CAPTCHAs for you, but your users actually help solve OCR problems in the process. Talk about a win-win situation. If this sounds impossible, check out the description here. As an added bonus, reCAPTHCA APIs are available in a number of languages, including Ruby. reCAPTCHA is currently used on popular sites such as Twitter and looks like this:

The struggle against spam is an arms race. Currently, the best weapon for legitimate content producers is CAPTCHA, but even it can be foiled by a determined spammer. If past history is any guide, even more sophisticated forms of spam attacks and countermeasures are just around the corner.

image credit: freezelight