ActsAsFlinn

Merb brought much attention to the ActiveRecord alternative ORM DataMapper and I feel like it’s going to put a serious hurting on ActiveRecord. My reasoning is based on the fact that alternate data storage technologies are gaining serious traction. The latest and greatest (couchdb, dynomite, cassandra, thrudb) are offering distributed document / object databases that will make creating highly scalable websites even easier and faster, oh yeah and they’re all free. With that in mind, I’m expecting a paradigm shift in data stores (big variable huh?). At the very least I expect Maglev to come true and the free/open source clones to follow. The model storage shift then becomes, how to you write the validations, callbacks, plugins and relationships for first class Ruby objects… DataMapper basically has all the pieces there already. With that in mind here are 5 reasons DataMapper will rule Ruby object data storage.

#1 Rails 3

(this is the big one) Rails 3 (Merb) will open Rails up to ORM alternatives like DataMapper. This will fuel uptake of DataMapper and others.

#2 property

This is a core difference in how DataMapper and ActiveRecord work. DataMapper allows the developer to define the property (attribute/column) in the class. Defining your attributes is better than letting the data store define it. This will become more apparent with the adoption of document/object databases that don’t define a hard schema.

#3 It’s Ruby

Defining properties in terms of real Ruby classes is the hotness. Take any ruby class then, include DataMapper::Resource… done.

#4 Laziness + Strategic Eager Loading

Yeah, one of DataMapper’s core features is it’s ability to iterate over associations without causing the n + 1 query problem. Whether dealing with SQL or Memcache or something new this will always be an issue. It’s 1 vs. many selects, io, or network hits it will never not be an issue. DataMapper handles this gracefully.

#5 Mapping Data vs. Record Handling

ActiveRecord is based on the assumption your storage is a database record. The entire library is written with that in mind. DataMapper is extensible and modular. Don’t need SQL? OK great, but you still need validations, properties, callbacks, and relationships. DataMapper has this covered whether it’s SQL, REST, CouchDB, or anything else. It’s easy to create something new.

OpenID as a Single Sign-On

I’m working on implementing SAML relying party services for a large household brand. I recommended OpenID about a year ago but they chose SAML instead. SAML is Sun’s an industry standard for Single Sing-On.

I’ve come to realize why the powers that be chose SAML instead of OpenID. OpenID is essentially the same thing as SAML but SAML’s user experience is designed in such a way that the IDP is providing a federated sign-on process. The user experience is designed for sign-in not cover-your-ass disclaimers like you find with most OpenID providers.

For example, a user browsing a CNN partner site can expect a CNN login page and CNN’s login page doesn’t educate the user on the virtues of SAML. The OpenID user experience can be implemented the exact same way but they chose SAML because when they tried someone’s (Yahoo!) OpenID implementation they were confused (for good reason). In their mind OpenID was a bad user experience. They took it at face value and didn’t know that you could engineer the OpenID user experience.

Guess what. OpenID can be used for Single Sign-On.

OpenID can be used for federated login. Here’s how.

1. On your consumer sites take a username and figure out the identity url for the user (don’t ask for it)
2. Setup a regular login page on your OpenID provider
3. Setup the appropriate release policy for your consumer sites
4. By default turn on a remember me cookie at the IDP
5. Use cookies on your consumer sites to figure out the identity url for the user.

Single Sign-On with OpenID = Done.

The result is a user that has no idea they’ve just used OpenID (a great user experience), a provider that can service any partners and partners that can integrate faster with a well supported open stack available for many platforms right now.

OpenID User Experience is Piss Poor

With piss poor OpenID setups providers are missing the opportunity to leverage their #1 asset, their user base. Recent OpenID user experience research from Yahoo and Google show something obvious – they both suck at providing OpenID. OpenID in its most basic form allows the user to supply a URL. Even if that’s the best UX you can come up with, don’t give the user a hash they can’t remember (Yahoo!). But that’s not the best you can do. There is no standard that says the user has to supply their own URL, you can should build it for them. Also, I don’t care what anyone says about fracturing the standard, GOOG is right – email is the obvious choice.

Facebook Connect is getting crazy adoption because it’s easy and the user doesn’t have to make a choice about what IDP to use. FBC is going to continue to mop up because they have a huge user base that is arguably more savvy than other large IDP’s. Facebook is making it easy to just get to what you want without caring about login.

Implementing OpenID shouldn’t be completely promiscuous. Choose a partner and be happy with your choice. What I mean by that is, if you think Yahoo!, AOL, Google are going to provide you with the right registered user base just pick one. Present only one or two IDP options and maybe an advanced option for power users if you really want it.

If you’re consuming OpenID and not making it simple for users you’re missing the boat. If you’re providing OpenID and trying to educate the user or filling your page with warning triangles and disclaimers your putting holes in your ship.