Google Reader's Lesson on Privacy in Software Design

There's been a big kerfuffle over the last week (or two) about Google Reader's revised sharing feature. In the past, your Google Reader shared items were only available to people to whom you'd given a relatively obscure URL. While I quickly published that shared URL to a few places, other people were clearly taking advantage of its obscurity.

Recently, Google Reader added a 'friends' section such that the shared items for all of your GMail contacts (as well as anyone you add explicitly) will be easily accessible in the menu. Unfortunately for Google, not everyone is happy with this.

Some people have shared items that they've chosen to expose to a particular subset of friends / contacts, but don't want to expose to others. Imagine, for instance, that you share your love of bare-chested firemen with a few close contacts but you may not want your colleagues to know.

It's an interesting case, because on the surface, to anyone who was already treating the Shared Items as relatively public, it seems like a useful feature. I was happy to see the feature arrive, because I'm looking forward to using it and I was already treating my shared items as public. On the other hand, I can understand that this raises a privacy concern for some people, and I can respect that and see that it could be quite damaging.

It just goes to show that privacy can be a tricky thing in software design, and that sharing of information of any kind should be thought through in detail to avoid the kind of negative backlsh that the Google Reader team is facing.

It seems to me like there are some relatively simple solutions to the Google Reader Privacy Crisis (TM). I'm inclined to believe they should roll back the change until they're able to put some access controls in place. The simplest solution is to add a preference that allows people to make their shared items visible to their GMail contacts. Even if that preference defaults to 'on', it gives people the simplest control over the publication of their shared items. After that, it might be nice if there were options to share certain tags with certain groups of people, for instance -- so if I wanted to tag some feeds as private, or "for special friends" and share those as distinct from my publically shared feeds, that seems like a useful, if more complex, form of sharing that could add value.

Anyway -- I'm not sure if Google Reader is going to cave in to customer demand or stick to their guns, but I'm pretty sure there's an interesting lesson on software design and privacy here for those who care to learn it.

Ruby 1.9.0 - Released

Ruby 1.9 has been released, a little later than estimated. There are a lot of changes for Rubyists to absorb, and if you're using Ruby on Rails, Ruby 1.9 with Rails 2.0 is a pretty novel, but powerful, combination. We'll be seeing the impact of those changes in 2008.

Will YARV give Ruby the performance it needs, or will JRuby storm the enterprise? Time will tell. Maybe 2008 will be the rise of Erlang, JavaScript/EcmaScript 4.X, or some other new and powerful language.

In the meantime, if you haven't given Ruby or Rails a chance, maybe this is your chance.

The Windows download is slightly harder to find than most, so I'll link to it here.

Aren't Packaging Systems Supposed to Make Life Easier?

So, I'd like to conduct a little experiment with CXF. Specifically, the version of CXF that the current version of ServiceMix uses.

ServiceMix uses a complex multiproject Maven build, which is pretty normal these days. Due to the parenting structure, it took me a little while just to figure out which version of CXF ServiceMix uses. I eventually found it simpler to download the source and run a grep. It uses 2.0.2-incubator.

Equipped with this knowledge, I added the version to my own Maven POM for the project, only to discover that CXF 2.0.2-incubator uses jaxb-impl 2.0.5, which isn't in the central Maven repo. A little digging with Nabble shows me that it's in the java.net repo, but that the java.net repo uses the Maven 1 repository structure.

I did a quick dig on the java.net repo to ensure that there isn't a Maven 2 structure as well. It seems like there is, but that jaxb-impl doesn't publish new versions there (although there seems to be an old version there, for whatever reason).

Because it's not always possible to find a Maven repository that holds the dependency you need, and because they're not always reliable, we're using Artifactory as a mirror/proxy for Maven repositories. This means that in order to take on the java.net repo, we need to add the repo to Artifactory rather than to the project POM.

Unfortunately, it turns out that Artifactory, unlike the Maven POM, doesn't support a configuration option for legacy maven repositories. So now I have to download the dependency and upload it to artifactory.

So, due to lots of leaking abstractions, i've now spent about two hours setting up something that, five years ago, would ahve taken ten minutes - download ServiceMix, grab its CXF jar, drop it in a lib directory, and reference it from Ant.

Three cheers for packaging systems. maven/artifactory and leaking abstractions.

New Google Analytics API

The new capabilities in the Google Analytics API look impressive; could replace the way a lot of people do internal tracking of custom events. However, despite the fact that their front end is quite impressive in and of itself, I'd still like the option of retrieving the data so I could present it in my own interface.

Mocking Methods that Don't Exist with RSpec

I've done some tests/specs using RSpec in Ruby with Mock Objects, but until I read this message on the RSpec List it hadn't occurred to me that you could mock methods (messages) that aren't present in the class itself.

I guess you could see that as a natural consequence of the kind of duck-typing system that dynamic languages offer, but it's a little awkward. You can end up, as the poster suggests, with a view that's out of sync with your model, and tests that don't pick it up.

As a result, not only do dynamic languages make testing more important, they make integration testing more important. Interesting.

I'd be interested to see a large codebase written entirely in Ruby and get a sense for the comprehensiveness and duration of a test run -- within three months of writing tests and specs on a Ruby/Rest project, we'd already racked up a five-minute test run (but, hey, we were Ruby newbies, so I'd be surprised to discover that people who've been at it longer have good strategies for maximizing test comprehensiveness and minimizing test-run time.