Like I said I’m not experienced with this stuff, so this is just a collection of notes, not a recommendation.

• Lots of people pointed me to Faye. From the home page:
  

  Faye is a publish-subscribe messaging system based on the Bayeux
  protocol. It provides message servers for Node.js and Ruby, and
  clients for use in Node and Ruby programs and in all major web
  browsers.

• Pusher is a service I had already heard of, and it comes highly recommended from many sources. I know Larry Marburger uses it on CloudApp and has nothing but good things to say about it.
• Lots of mentions of Juggernaut. From the website:
  

  Juggernaut gives you a realtime connection between your servers and
  client browsers. You can literally push data to clients using your
  web application, which lets you do awesome things like multiplayer
  gaming, chat, group collaboration and more.

• Several people mentioned PubNub, which appears at first glance to be a similar service to Pusher.
• In addition, lots of people replied with various combinations of lower-level tools and technologies, including: Socket.io, Goliath, WebSockets, and EventMachine.
• EDIT: A couple people have also pointed out that TorqueBox provides built-in WebSockets support.

For those who don’t know, 99Designs is a “design crowdsourcing” service. You post a contest in one of several design categories, with a specified monetary prize for the winner. Designers submit designs, which you rate and comment on, and based on the feedback they may submit updated designs. At the end of the contest period (a week, by default) you pick a winner. They get the money, and you get the rights to their design.

Getting my contest started was straightforward enough, although they could have provided some more examples of how to write a good spec.

For the first couple of days I saw zero entries. This was a nerve-wracking period – I was wondering if I had committed some 99Designs faux pas, or if it normally took a while for designs to appear. They would do well to add some kind of notice for contest holders saying “Don’t panic! Designers are working on their submissions“. Or maybe even provide a way for designers to indicate that they are interested and working on an initial submission.

Eventually designs started trickling in. Around the 4th day I saw a design that was good enough that I felt confident switching to “guaranteed payment”—in which it is guaranteed that someone will get the prize. After that submissions came at a steady clip. At the end I had a remarkable 93 submissions, all for a $145 “Bronze” level prize.

The design of the feedback system is simply awful. As a contest holder, you have (at least) three avenues of communication. There’s an “Inbox” – which never has anything in it. There’s  contest-level message board (which doesn’t feed into your Inbox). And then every designer to submit to your contest gets their own contest/designer-specific message boards, which have no connection to the main contest message board or your “Inbox”. If you leave feedback on a design, you leave it on the designer-specific message board. If they reply, you are not notified in any way. That means that if 20 designers submit designs, in order to keep up with responses to your feedback you must remember to check 20 different message boards manually. In addition, it is apparently impossible for designers to private-message the contest-holder. For an otherwise well laid-out site, the communication UX is a disaster.

Apart from that my experience was good. There were a lot of just plain low-quality designs, yes; but there were enough good ones to choose from at the end of the contest that I felt like my $145 (actually $100, I had a coupon) was well-spent.

The really nice part, for me, was that it enabled me to not think too hard about the design. This particular design was something that I wanted to look good, but apart from that I wasn’t very particular. 99Designs let me get a lot of different design perspectives on it without having to spend a ton of time working with a designer to hash out ideas.

Bottom line, I would use them again.

EDIT: Something I forgot to write about. One thing I noticed about the designs was that a lot of the designers seemed to be cuing off of previous designs more than the actual design spec. For instance, a designer would add a subtitle which was not part of the spec, and then subsequent designers would copy the subtitle word-for-word. This was a little annoying.

Standards:

• RFC2616 Hypertext Transfer Protocol: If you haven’t read this RFC, you might be surprised at what you don’t know about HTTP. I keep a printed copy nearby at all times.
• RFC5988: Web Linking. You might not have heard of this one, but I think it’s one of the more important recent developments in HTTP from a RESTful standpoint. REST is all about hyperlinks, but how do you link a non-HTML resource – like an image, for instance – to other resources? This RFC tells you how.
• URI Templates. This one’s still a draft. In general forcing clients to build their own URIs is bad form; contrary to a zillion “How to use our RESTful API” articles you may have read, URIs are supposed to be opaque. However, sometimes URI construction is inevitable; when that’s the case, we can at least specify it in a machine-understandable format with URI templates.

Books:

• HTTP: The Definitive Guide. A good HTTP reference is essential, and this book offers a lot more exposition and examples than plain RFC2616. It also draws in related material so you don’t have to go hunting down all the referenced RFCs yourself.
• Restful Web Services. Probably the best guide available for building REST services.
• RESTful Web Services Cookbook: Solutions for Improving Scalability and Simplicity. The companion volume to RESTful Web Services.
• REST in Practice: Hypermedia and Systems Architecture – I haven’t delved deeply into this one yet, but it seems to deal with higher-level patterns built on the principles laid out in the other books.

Articles:

• Roy Fielding’s thesis. Duh.
• The Richardson Maturity Model. Characterizing different levels of RESTfullness.
• Versioning REST Web Services, by Peter Williams. In which we learn a much better alternative to API endpoints with /v1/ and /v2/ in the URL.
• Versioning REST Services, by Scott Seely. An interesting variation on the scheme above that uses mimetype version arguments instead of a version built-in to the mimetype.
• Your Web Service Might Not be RESTful if… by Paul Sadauskas. Think you know REST? Think again.
• Haters gonna HATEOAS, by Magnus Holm and Steve Klabnik. One of the better explanations of just what the hell Hypertext As The Engine Of Application State (HATEOAS) means.
• Why HATEOAS, by Craig McLanahan. OK, so now you know your API isn’t really RESTful. Why should you care? This article provides a few reasons.

What about you? What are your favorite resources on RESTful architecture?

Note: Any comments to the tune of “blah blah REST orthodoxy blah blah zealots blah blah real world blah blah who cares” will be summarily deleted. The books and articles listed above are by real developers who have solved real deficiencies in HTTP APIs using RESTful principles. If you and/or your users don’t have the problems these techniques address, that’s fine. This article isn’t for you. Move along.

I started working through Web Design for Developers recently, but I haven’t been very happy with it and I don’t think I’m going to finish it. I asked around for some recommendations for books on web design, and got quite a few responses; I’ll list them below.

What I realized, though, is that the book I’m looking for right at this moment probably doesn’t exist. Most of the design/CSS books out there are coming at it from one of two angles: either they are telling you how to come up with an attractive and functional design from scratch, or they are telling you all about how the individual CSS selectors work. That’s all stuff I want to understand better, but as a working web developer I often find myself with a much more tightly constrained problem. More often than not, all I need is to be able to take a comp in PSD format and produce a functional web page that looks exactly like the comp.

The book I’m looking for would be a slim volume, and it would be called something like “The Mechanics of Web Design“. It would be a step-by-step guide for slicing a comp and turning it into HTML, CSS, and images. It would answer questions such as:

• Just what the hell is “comp” short for, anyway? “Composition”?
• How do I use guidelines in Photoshop or the GIMP to make slicing easier?
• When slicing up images, where should I make the cuts to end up with something I can best use in the final HTML?
• What points on the mockup text should I measure to determine the correct CSS pixel size?
• When should I use pixels, when ems, when exes?
• What are some guidelines for organizing my CSS or SASS files? (Both within the file and how to divide up the files)
• When should I use PNG? When JPEG? When GIF? What image compression settings should I use?
• What are some good naming conventions for image assets that go into making up the design?
• When do I use margins vs. padding for spacing?
• When do I use floats?
• How do I do those “sliding window” button styles with a minimum of effort?
• Where do I use absolute positioning? Where do I use relative?
• Etc.

Basically the problem I have is that while I long ago moved past doing messy trial-and-error when going from a failing unit test to working code, I’m still just poking things around to see what works when it comes to translating a visual design to HTML/CSS. And what I end up with always feels like a big messy unmaintainable ball of mud without consistent techniques or idioms.

Actually, the more I think about it, the more this sounds like it would make a better screencast than book.

Anyway, here are the books that were recommended to me:

• Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition
• Principles of Two-Dimensional Design
• Bulletproof Web Design: Improving flexibility and protecting against worst-case scenarios with XHTML and CSS (2nd Edition)
• Handcrafted CSS: More Bulletproof Web Design
• Web Standards Solutions: The Markup and Style Handbook, Special Edition (Volume 0)
• The Principles of Beautiful Web Design
• Sexy Web Design: Creating Interfaces That Work
• Designing the Obvious: A Common Sense Approach to Web Application Design

Thanks to @RobotDeathSquad, @batasrki, @jptoto, @laktek, @kenrichard, @djbrowning, @gavinlaking, and @JoshuaChilds for pointers to books and other resources.