07/24/2009

There's a bit of buzz going around about the "real-time web" lately. The real-time web is about information delivered to the user as soon as it is available. Real-time notifications are exciting because it allows web pages to be more dynamic and seem more alive. These techniques also allow developers to mimic desktop applications, with their immediate user feedback, on the web.

With all the talk about "real-time" it's important to take a step back and evaluate the techniques we use to accomplish these browser feats.

1) Ajax (Wikipedia article)
Ajax is the technique where a user action (via a web browser) is able to update information or retrieve additional information from the web server. I won't get into too much detail because Ajax really is everywhere these days. Favorite a tweet, digg a story, move around in Google maps, post a comment on Facebook... these actions are all performed via Ajax. You, the web user, take an action in the browser and the server is notified of what you did - no web page refresh required.

2) Comet (Wikipedia article)
Comet is the lesser known of the real-time techniques and can be thought of as the reverse of Ajax (well, actually Comet often uses Ajax, which I'll explain later, but bear with me for now). An event happens that is known to the server and the server notifies the browser, updating the web page that the user is viewing. Again, no page refresh required.

The important difference between Ajax and Comet is where the action originates. With Ajax, the action is taken by the user and with Comet, it's an action from the server. Currently Comet is a popular technique for browser-based chat applications since it allows the server to receive a message from one user and display that message to another user. Some web applications that currently use Comet are Google's GTalk, Meebo's chat, and Facebook chat.

From a technical perspective, Ajax and Comet differ in the expected length of the request. Ajax uses a quick request-response to update or get new information from a server, while Comet typically opens a longer connection to get information as it is available from the server.

So how does Comet actually work?

There are several ways to implement Comet but the most common is called "long-polling". Long-polling means that the browser opens an XMLHttpRequest to the server but instead of expecting a quick response (like Ajax does) the connection just waits. If the connection gets a response from the server, it returns that to the browser right away. Otherwise after a bit of time the connection dies and the browser sends another request and waits again.

How is long-polling different from just periodically checking with Ajax?

Some web applications, such as 37signal's Campfire chat application, use periodic Ajax (quick) requests to check if there's a new action from the server. The problem with this kind of short-polling is that it's difficult to tune to get the best results. For example, if you check for new stuff on the server every 5 seconds, what happens if a new action appears right after the response returns? Well, your user waits another 5 seconds to see that action. That's okay, but not ideal. Also, a lot of Ajax requests will be hitting your server when there is no data available and may waste more requests than having fewer, longer connections.

What's the future of Comet?

The heart of the internet is communication. The next generation of web applications will not only need to be responsive to one user, but also facilitate speedy communication between many users. The quicker we can chat, message, poke, tweet as well as see and respond to these actions, the better!

07/22/2009

It seems like a silly thing to write about but I love having my own server.

In the past year I got my own Media Temple Dedicated Virtual server to use for side projects (mainly Baconfile). Since I'm an application developer (and not much of a sysadmin) I never really thought about managing my own web server. Surprisingly, I'd now say that my server is my most fun toy.

It's incredibly fun because I can have an idea for a web site, build it, and get it out on the web... all by myself.

Okay, so I'm sure some of you old-timey web programmers have been doing this forever, but not me. I've always relied on someone else to host my stuff (employers, cloud services, umm...ex-boyfriends) thinking that it was something that I could never manage to do (or really want to do).

Ha! Everything I've needed to know about website management is on the web and available via a quick search. In fact, it appears to be the most documented thing on the web! I like to imagine in the 90s people said "here's my document and here is how you're seeing it on the internet!"

Why bother mentioning this on my blog? I only say this because I know quite a few web developers who don't do their own hosting. I say to you developer friends - do it! It's the best thing I've done all year.

07/14/2009

I've been keeping a gist of web product guidelines for myself. It's pretty much a list of stuff I tell entrepreneurs when they asked me what I've learned from Pownce (from a product point of view) and also what I try to remind myself when working on new projects. I thought I'd re-post them here for fun. If I'm missing anything, be sure to comment.

07/13/2009

One of the side projects I work on is Baconfile, a web interface for Amazon S3. This weekend I fixed up the (previously semi-functioning) Baconfile API. The API now allows you to not only get data for files and folders, but to post new content to Baconfile. Find out more about the Baconfile API here.

The first real project to be built on the API is Bacondrop, a Mac uploader for Baconfile. Bacondrop is nice and simple - just drag any file over to the Bacondrop app (or dock icon) and the file is instantly uploaded to your Baconfile account. You can download the latest Bacondrop here.

06/23/2009

I'll be heading over to Amsterdam for the Kings of Code conference next week. The conference takes place on Tuesday, but I'll be there for a whole week hanging out and working. No, "working from Amsterdam" isn't a euphemism, I'll actually be working on some stuff for my job at Six Apart.

The speaker lineup for Kings of Code looks really good and I'm excited to get to meet some awesome developers. If you're in Amsterdam for the conference, be sure to say "hi."

05/19/2009

The Django Dash is coming up in a couple weekends (May 30-31) and I'm excited to be participating this year. The Django Dash is a contest for creating a new Django-based project in under 48 hours.

Defunkt and I are working on a web IRC client which will certainly be awesome. I didn't get to be part of the dash last year since Pownce was a sponsor and I haven't done any timed hacking for awhile so I'm pretty excited.

Issues is unique in that there aren't any Owners, Priorities, or Milestones - only labels, like GMail. This allows project owners and users make up their own system to suit the project. You can also sort the issues by drag and drop, so you can move the important ones to the top.

I've filed some pretty good issues during alpha testing.
The original plan was for Issues to launch on April Fool's Day, so this issue was meant as a joke. Sorry Rails!

Try out GitHub Issues, and let me know what you think. Disclaimer (yesss, I finally get to make a disclaimer): I'm an advisor to GitHub.

04/10/2009

I thought about writing how I made Baconfile's tiny URL service, tinyb.cn. However, I thought it would be more fun to write a generic URL shortener... and make it short. I've been wanting to play around with Sinatra (a Ruby web framework that isn't Rails) for a while now, so that's what I did.

The basic idea is to have the user enter a URL, then store that URL in the database. The only columns in the database are the auto-incrementing primary key and the URL. To create fancy short URLs, the id is base36 encoded/decoded. That's all people.

I pretty much agree with Gruber about the importance of URLs: they should tell a user where they are and be simple, informative, and easy to share. I also don't agree with Digg branding my (personal) project site and serving ads against it either (just click on the "Related" link on the Digg bar to get an ad).

Baconfile is my pet side project and I've had a lot of fun developing it in my free time over the past couple months. It's a web interface for files on Amazon S3 and I actually love that it's not very popular.

All the fun of running a website without any hassle ;)

I actually implemented my own URL shortener for Baconfile, called tinyb.cn (Tiny Bacon). Instead of shortening any URL on the web though, it's only used for URLs that redirect for Baconfile. The idea being that when a user sees a tinyb.cn URL, they might guess that it redirects to baconfile.com.

There's even a Twitter button on the bottom of each Baconfile permalink page that redirects to Twitter and pre-populates your tweet with the tinyb.cn URL. It doesn't require a username/password, nor does it post the tweet for you automatically, it's just a link - like this.

I created tinyb.cn to make tiny URLs more transparent and informative instead of misleading and self-serving. I'm sure I'll write more about how to make a URL shortener, but for now let's just consider how we can use tiny URLs for good.