Rated Syndication for RSS/Atom

I've often wished that content syndication via Atom and RSS came with ratings. Basically, there are feeds that contain good content, but have entirely too much of it. Consider the prolific output of some person or site like Robert Scoble or Engadget, and imagine that instead of having to choose between ignoring them entirely or drinking from the firehose, you could subscribe to the top X% of their syndicated content.

So when Engadget delivers the news about iPhone 2.0 and rates it 95%, you'll read it, but when they unbox a Samsung Blackjack 2.2 Silver and rate it 30%, you might not even have to skip past it with 'j' in Google Reader.

Heck, Google Reader could even offer to tweak your settings based on usage. "I've noticed you only read about 15% of Robert Scoble's postings. Would you like to subscribe to his top 20% syndicated content instead?" "I see you've read everything that Clay Shirky wrote this week. Would you like to expand your subscription?" "I see you're writing a memo ... "

The ratings could be delivered entirely by the content author/syndicator or through tools they supply for readers to modify the ratings, a la Digg / Reddit.

So, if you're out there working on the next syndication format, please take some kind of content rating into account, save me from the never-ending river of content.

Viewing Logs as Trees using NDC/Viewer

One of the problems that one tends to find when attempting to diagnose a problem using logs is the sheer volume of information that one has to digest. I've been thinking about that a little over the last couple of days, and it seems to me that with a little work you could display logs in tree form, like a call stack, which would give you the ability to do many of the kinds of things you can only do with a profiler right now, such as:

• Track down the hibernate logging that relates to a particular HTTP request so that you can diagnose a tricky persistence problem.
• Analyze the number of SQL calls made by a single HTTP request.
• Get a rough outline of the time involved at each layer of a request.

In order to make that happen, it seems like you'd want:

• Judicious application of the nested diagnostic context in Log4J or Logback to store a sense of the layer. This is probably done easiest with an aspect that could be applied at various tiers (services, daos, etc.)
• Some kind of request-tracking key, whether this is the thread, or some kind of context-free identifier stored in the mapped diagnostic context. Again, this could be applied via an aspect.
  
• Better log-parsing/viewing tooling. Using the above pieces of information, you could display logs as a tree, allow for querying, etc.
  

It's an interesting idea. Like most interesting ideas, it would take someone to actually follow through on it, and i'm not convinced that's going to be me. ;)

Project Wiki or Project Blog?

I've seen a lot of technology development projects adopt wikis as a way of sharing information. Often, unless you appoint someone the job of keeping the information both up-to-date and organized, these often get out of hand pretty quickly. Without a common kind of organization to keep things in check, it gets difficult to find information, and without someone constantly reviewing the documentation for relevance, some information gets out of date quickly while others remain relevant.

I'm starting to wonder if projects should probably seek a platform that emphasizes a blog style rather than a wiki style. The blog entry metaphor is more suited to "writing information about a point in time." When you do a search for something in your project blog and find information from May 2006, you're much more likely to think to yourself, "Hey, I wonder if this is still relevant."

That's not to say that a Wiki isn't a good idea, just that wiki content should be saved for information that is both long-term relevant and worth keeping up-to-date, and then someone should, in fact, regularly review it for relevance and make any necessary updates.

In keeping with my agile mindset, this kind of regularly updated documentation should be kept to that information that is very valuable, so that you don't distract a team whose job is creating value through software and end up spending a lot of their time reviewing and updating documentation that isn't necessary.

Scala Lift-Off

Interesting to see Scala and Lift gain a little momentum, with Scala Lift-Off, an unconference.