Ever since the initial release of Movable Type, Six Apart has been invested in the idea of writing content management systems that consist of an authoring tool that publishes static files. In the more recent Movable Type releases, support for dynamic publishing templates has been added, but Six Apart has still been wed to the author and publish model rather than a model that merges authoring and publishing into one big piece of software. That is, until Vox. (I’m assuming TypePad works like a Movable Type installation internally. It seems that way from the user’s perspective.)

Vox only has one interface, and the controls that are available to you depend on your privileges. When you read my blog there, you see only the items that I have granted you the rights to see. When I read it, I see everything and can click on the elements to change them if I like. The editing and publishing environments are combined.

Is Vox the result of Livejournal’s influence on Six Apart? Or are they seeing some things they like about WordPress? Are we going to see these kinds of features make their way into Movable Type? I’d love to read an article about how Six Apart decided to go this direction. In any case, it was the right decision. Vox works really well.

One question I’m wrangling with right now is how to add authenticated feeds to an application. I have an application that you have to log into in order to use. The application will publish some feeds. I have to decide whether or not to require authentication to view the feeds, and if so, how that authentication will work.

There are a number of problems associated with feed authentication. The first is that I have no idea what sorts of authentication are widely supported by feed readers. The second is that most people subscribe to many, many feeds, and I wouldn’t want them to have to enter their username and password every time they attempt to refresh the feed. The third is that if you create an authentication system that doesn’t require the user to enter their password, the link to that feed is almost certainly not secure. The user will be able to copy the feed URL and email it to anyone they like. This is especially problematic if the user’s username and password are included in the URL. And the fourth is that regardless which system I use, it needs to be understandable by users who don’t know what RSS, Atom, SSL, and Basic Authentication are.

The good news is that none of the data in this application really demands security. The only reason it’s walled off at all is that it’s going to be published elsewhere later and I don’t want people to start browsing it within the content management system. I could leave out all of the security for the feeds without much worry. If I can bring my support for authentication to the feeds, though, I may as well do so.

I’m looking at how other applications do feed authentication. FogBugz produces RSS feeds and provides two means of authentication. You can consume the feed in an application that maintains your FogBugz cookie (like Firefox), or you can include your username and password as query parameters.

LiveJournal supports authentication for feeds using HTTP Digest for authentication (if you add the right parameter to your URL) or using the LiveJournal authentication cookie if your application has it stored.

37signals’ Basecamp application also uses authenticated feeds. Basecamp’s documentation doesn’t say what form of authentication they use, but a little test reveals that their feeds are authenticated using Basic Authentication.

Daring Fireball also uses Basic Authentication for private feeds.

Needless to say, it doesn’t seem like there’s much standardization in this area, but I think that the best answer is to use Basic Authentication and rely on the user to have a tool that saves their username and password for them if they don’t want to enter it every time. That seems like a preferable approach to creating URLs that have a username and password or even a token included in them. The only problem with that approach is that I have to add support for basic authentication to an application that uses cookies for authentication normally, but at least that’s a problem for the developer rather than a problem for the user.

Feed authentication seems like yet another area where some kind of certificate-based authentication system would be a huge win, but obviously that remains a pipe dream.

After some recent contemplation, I’ve completely rethought my approach to photography. I decided to write about this after reading Khoi Vinh’s post about a digital photography class that he’s taking and the kinds of pictures he aspires to take.

For many years, I’d say that my taste in photography has been pretentious and that my aspirations matched. I wanted to take the kinds of photos that people look at and think, “How artful and interesting.”

Flickr has ruined all of that. Go to Flickr any day of the week and you can see hundreds of beautiful, artistic, interesting photos. Search Flickr for tags relating to the last place you went on vacation. Somebody has already taken great photos of the things that you saw and did.

My new focus is on taking pictures of stuff I want to remember. I still want to take well composed photos, but I’m going to focus less on artistic value and more on sentimental value. It’s easy enough to find the art better done elsewhere. If I go on a trip or go to an event and come away with a collection of photos that captures well what I experienced, then I’ll consider it a success.

For what it’s worth, I think the thing that screwed up my perspective on photography was working on the high school yearbook. Our teacher had lots of opinions on what makes for a good and bad photo and I think that’s where the pretentiousness crept in.

A few months ago I signed up for an emusic.com subscription. For about $10 a month, you get the right to download 40 MP3s a month that are yours to keep. At 25 cents a track, it’s a great deal as long as the site has enough music that interests you to keep your queue full. So far, so good.

The one catch is that the 40 downloads are “use them or lose them”. When your account rolls over, you lose any downloads that you didn’t consume. I’ve been good about using all of my downloads every month, so that hasn’t been a problem, but if you’re the kind of person who loses track of this sort of thing, emusic is a good way to spend money without getting any value in return.

The one thing I can’t comment on is the quality of the MP3s, beyond saying that they’re good enough for me. I suspect that audiophiles may differ.

If your music interests center on major label releases, emusic is probably not for you. If you like old stuff, obscure stuff, and indie releases, you’ll probably be pretty happy. I’m still working through the backlog of stuff that I know I want, so I haven’t done much exploring, but emusic has a lot of ways to find music that interests you if you don’t know what you want already. That said, I downloaded an album from Jon Langford’s list of 12 recommendations, and this month Ed Ward has a really good looking list of old country albums that interests me.

My mode of use for the site is to wait most of the month to see if there are any “instant gratification” tracks that appeal to me. If so, I download them. Toward the end of the month I go download some tracks that I have in my queue to use up my quota, then I start again the next month.

The problem I’m running into now is in assimilating new music into my collection. I generally buy Paste magazine, which adds 20 songs or so to my collection every other month, and now I’m downloading 40 tracks a month from emusic. Listening to the songs enough to decide how to rate them is work, and I worry about getting behind.

I was trying to add my name to the list of attendees on the BarCampRDU Web site yesterday, and I found that regardless of the time of day, I couldn’t get in, because the wiki software that is used to manage the site grants an exclusive lock to the person editing the page for 15 minutes. After 15 minutes, the lock remains but someone else can steal it.

Using exclusive locks to avoid the lost update problem is painful, especially in Web applications, because users can easily navigate away from a page without providing any kind of signal to the Web application that the lock should be released. For example, if I go to the BarCampRDU page, click on edit, and close my browser window, I’ll keep my exclusive lock on the page for 15 minutes even though I’m not really editing it any more. This may seem like irresponsible behavior, but most people don’t expect clicking on a link to give them an exclusive lock on a resource. That’s not the Web way.

Optimistic concurrency control is the way to go in Web applications. It’s used in Mediawiki (as well as many other applications), and support for it is built into lots of persistence frameworks, including ActiveRecord and Hibernate. With optimistic concurrency control, things work like this:

• Person one attempts to edit a resource
• Person two attempts to edit the same resource
• Person one saves their changes
• Person two attempts to save their changes to a now stale version of the resource
• Person two is notified that a change slipped in behind them and that they need to reconcile their changes with person one’s changes

The nice thing about optimistic concurrency control is that the only time anyone is affected is if two people edit the resource and one actually slips in a change before the other. In all other cases, everything just works. The amount of trouble conflicts cause depends greatly on the type of resource in question. Even in cases where the content is complex (think of long wiki articles, for example), the user interface can make conflict resolution less painful through the use of diffs.

A quick Google search seems to reveal that somebody needs to write a tutorial that explains how to implement optimistic concurrency control in PHP, but I’m not the one to do it.

I just got my blog set up at Vox. The posting tools are pretty nice. Nicer than my Movable 3.2 installation anyway, although not as nice as MarsEdit. Don’t expect the name of the new weblog to last.

The emergence of Vox has led me to lots of thoughts about the evolution of online communities, but I’ll get to them some other time.

I should also note that the two levels of membership at Vox are “standard” and “starter”. A standard member can invite as many starter members as they like, starter members don’t get any invitations at all. I’m not sure who gets “standard” invitations. Obviously Mena Trott has them, but she’s the boss. I’m not sure who else does.

I was able to obtain an invitation to Vox yesterday, and after using the invitation I got my first surprise — when you sign up for Vox, you don’t start out with all of the toys that everybody else has. You are initially inducted at Starter level. What’s that mean?

You don’t get your own weblog. Or really any opportunity to publish anything except for comments on other people’s weblogs. In the meantime you’re supposed to build your neighborhood (add existing users as contacts) and post comments. I guess at some point you get promoted to being a Standard user, and at that point you can start adding your own content to Vox, and invite other people to become Starters themselves.

On one hand, it’s a bit frustrating to be given the keys to a new car but then told that you can only start it in the driveway and listen to the radio, but on the other hand, I think this model could be very effective going forward in terms of building a more robust community. When I join a new community, I usually lurk for awhile to get a sense of how things operate before jumping in and annoying people. The Vox approach sort of enforces that kind of custom on new members. Before you get to leave the driveway you have to see how things work. At least that’s how things work now — it will be interesting to see if Six Apart sticks with it.

By the way, my Vox page is rafe.vox.com.

I’m anxious to see Google’s spreadsheet product, because I strongly suspect that it will do 99% of the things that I actually use Excel for, which represents about 2% of its overall capabilities.

Excel is an interesting product to me, in that it’s as close as you can get to being an application development platform without actually being one. I’ve known plenty of people whose job consisted mostly of writing Excel macros. I don’t think anybody’s Web application is going to take the place of that.

For me, though, Excel usage consists mostly of entering numbers and letting Excel add them up, or average them, or otherwise manipulate them. Even more unfortunately, I often see it used as a way to ship around tabular data, which I usually have to export as CSV so that I can get at it programmatically. There’s no reason why a Web-based product couldn’t take that over either of those functions almost completely. The main barrier is in presenting an interface that’s anywhere near as usable as Excel’s.

As a developer, I’m very curious to see how Google tackles that problem.

(Here’s a link to a tour of the spreadsheet application.)

One question I’m still puzzling through with Ruby on Rails is the logical unit of reuse for Web actions. This is a key question regardless of which Web application platform you use.

Since everybody has been exposed to PHP, let me use it to explain what I’m talking about. Let’s say you’re writing an application that enables a user to manage a weblog. Obviously, there’s going to be some shared code that you put in include files, but what I’m talking about is the top level interface to the Web site, the URLs. You could have one URL, index.php, and then put all of the verbs for your site in parameters, so you’d have URLs like:

• /index.php?action=post
• /index.php?action=view&id=50
• /index.php?action=configure&weblog=5
• /index.php?action=configureauthors&weblog=5

To be blunt, that’s an approach I hate. I prefer one page per verb. So if I were writing a weblog application, I’d have URLs more like this:

• /post.php
• /view.php?id=50
• /config/index.php?weblog=5
• /config/authors.php?weblog=5

One area where I generally do go for reuse of the same page is in processing form submissions, so rather than having two pages like post.php and save_post.php, I just write one page that displays a new form when it’s supposed to and processes the form submission when it’s supposed to.

This isn’t the sort of thing where there’s one right answer, it’s a matter of aesthetics and ease of maintenance. Right now I’m trying to figure out the right mix for Ruby on Rails. In Ruby on Rails, there are scripts called controllers that are basically packages of actions (or verbs, if you prefer). Public methods in the controller are the verbs, and correspond to the URLs, by default anyway.

So in Rails, you have mappings like this:

In the last example, Rails is smart enough to pass in 503 to the method as the parameter “id”. This behavior makes it easy to write shorter, cleaner URLs.

My general rule when it comes to Rails is to treat the controllers as nouns and the method names as verbs, so my examples there aren’t the best. For a weblog tool, I might have controllers like “blog” and “post”, and then the methods would be verbs that apply to those nouns. In one of my current Rails packages, though, one of my controllers is getting unwieldy, so I think I’m going to split it up into multiple controllers.

I follow the same rule as I do with PHP with Ruby on Rails. I don’t reuse methods in controllers for different tasks, even if they do basically the same thing. (That’s where I get the “units of reuse” I mention in the title of the item.) Say, for example, I have some search functionality in my application, at the URL /posts/search. Later on, I decide that I can use search to prevent users from entering a post with the same URL as an earlier post. I could just use a parameter to include my existing search method in the process, like this:

/post/search?step=checkforduplicates

Then in my search method I would check the step parameter to determine whether to show search results or show the “check for duplicates” page when finished. This is not how I would write an application. Instead I would create an entirely new check_for_duplicates method, and then extract the common code from the search method so that it could be used by both of my top level methods. To me, that’s a cleaner approach, and makes for nicer URLs in the application.

The reason I bring all of this up is that when you’re working on a team, this is the sort of thing you have to hash out and agree on among all team members for an application to be written in a sensible and consistent fashion. If one person is writing one method to display the “new post” form and another save new posts, and another person is wrapping them all into one method and keying off of the request method to determine which action to take when the method is called, you wind up with an application that’s difficult to maintain.

At work, I’m in the process of coming up with just these sorts of guidelines for our Ruby on Rails projects.

I didn’t think I needed a Vox invitation, but now I think I do. Anyone care to oblige?