rckenned

There's a lot of things about this I'd enjoy talking with folks about:

* Fear's role in software development

* Emoji's role in presentation development

Interesting, I'd never seen this. For what it's worth, early Dropwizard versions used Guice heavily. We yanked it out because we found the indirection of dependency injection wasn't buying us much. Subsequently, others have put it back in through the use of modules (i.e. https://github.com/HubSpot/dropwizard-guice).

Metrics was created before Servo. Some folks at Netflix wanted to use Metrics but ran into fundamental differences of opinion with us (Yammer) that we weren't willing to yield on. So Netflix built Servo and Dropwizard kept going with Metrics.

The Bump guys did a "Scala on Android" talk at the last Scala Days. They didn't explicitly say it, but reading between the lines it sounded like, "Scala on Android…don't".

http://www.slideshare.net/michael.galpin/scala-on-android-ex...

At Yammer we use Riak to power our notifications backend. More details available here…

http://blog.basho.com/2011/03/28/Riak-and-Scala-at-Yammer/

We had a similar problem at Yahoo! with BBAuth and OAuth. Developers started out initially building an application that needed access to (for instance) Yahoo! Mail. Unfortunately, there's no way in the Yahoo! Developer Network to "upsize" an application ID or consumer key after it has been created. You can't go back and say, "You know what? My application could be 2x as awesome if I added Yahoo! Address Book support." As a result, developers requested the kitchen sink: Yahoo! Mail, Address Book, Calendar, Flickr, Profile, MyBlogLog, Delicious, Fantasy Sports, Messenger, Updates and so on. In addition, each of those services has different permissions ranging from Read-Only to Read/Write (see https://developer.apps.yahoo.com/dashboard/createKey.html).

Google did a better job of this with their OAuth flow, allowing a "scope" to be passed in the authorization request so applications can dynamically select what they want access to (http://code.google.com/apis/gdata/docs/auth/oauth.html#Scope). This means applications don't have to ask for the world up front when registering. Unfortunately it doesn't fix the "OAuth will murder your children" problem.

Ultimately it's a user experience problem. As the article points out, add too many checkboxes and it becomes too complex. The average user doesn't pay attention (like reading a EULA) and in several cases they're not going to understand the scopes presented to them anyway. Read/Write is pretty clear to most of us, not so clear to my mother.

As an amusing aside, I went to log into Hacker News using their Clickpass integration to sign in using my Yahoo! account. Clickpass does the OAuth song and dance and requests read/write access to my Address Book. "http://www.clickpass.com is asking you and Yahoo! for the ability to automatically sign-in as you to your Yahoo! account through a service or application that is provided by http://www.clickpass.com, and to read and store to your data in Yahoo! Address Book." Evidently OAuth will not only murder your children, it will wipe them from your Address Book, too.