ActsAsFlinn :

5 Reasons DataMapper Will Deprecate ActiveRecord

Fri, 02 Jan 2009 05:24:00 +0000

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.

Federated Login with OpenID

Sun, 07 Dec 2008 15:16:00 +0000

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.

On your consumer sites take a username and figure out the identity url for the user (don’t ask for it)
Setup a regular login page on your OpenID provider
Setup the appropriate release policy for your consumer sites
By default turn on a remember me cookie at the IDP
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 is missing the boat

Sun, 07 Dec 2008 06:12:00 +0000

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.

Engine Yard As A Service

Tue, 18 Nov 2008 20:35:00 +0000

No Hands Rails Stack

Ezra just announced a new service coming in January. They’re extracting the Engine Yard stack into an easily configurable service for booting up new Engine Yard nodes. The service is promising, even supports building nodes based on JSON. I’d expect this type of setup to replace AWS as a rails stack based on all the work Engine Yard has done on the deployment process and operations of a rails stack. The screens shown looked highly configurable, check boxes with memcached, mysql, erlang, etc. also add users, ip addresses, etc. Just about everything you would need to build a complete rails stack, with no hands.

Ezra’s Slides

After talking to Ezra and Vivek Engine Yard As a Service is not necessarily a web service they provide but more of a stack as a service they provide. Say you’re locked into a contract with a hosting company or you love your hosting company but they don’t know anything about building a rails stack or you’re cheap and you want cheap VPS’s, you run EYAS on your choice platform. I asked a few questions about how Engine Yard intends to go about doing this, though partnership or through an install process for the end user and it sounded like some of those things are either secret or not defined yet. Even with the specifics still a bit unclear the prospect is very exciting.

#prorubyconf08

Tue, 18 Nov 2008 19:42:00 +0000

I’m at the Voices That Matter conf in Boston. Met some old friends, met some new people. Some talks are interesting as my team is mostly operating in a vacuum rails-wise. Most of the team has experience working at larger companies but not in rails at a larger company. So it’s nice to hear what other larger companies are doing and how their rails team fits in to the business. The yellowpages.com talk was interesting to hear that most of their hits are static and not using ActiveRecord at all. I’m thinking that FanNation with it’s large amount of dynamic requests is got to be one of the larger rails installations. Also surprised to hear that NYT uses a handful of EC2 instances to do mostly page cached/generated pages. Again not much (if any) dynamic content generation.

At the end of the conference I won a prize (I think for talking a lot of shit on the irc back channel). I picked Obie’s book The Rails Way. The book is hugegantic weighing in at around 800 pages. So far I’ve skimmed the book and it looks promising. Lots of code examples, etc. I’ll do a full review once I get to read it.

Hartford.rb on Merb

Fri, 31 Oct 2008 02:42:00 +0000

So after the last Hartford.rb meeting we started talking about the need for a web page. I volunteered and started working on it a few nights ago. I’ve been working with Merb and I’ve got to say that in the 2 months I’ve been away a lot has changed. I’m using haml and while it feels a bit different it does kind of make sense. So far the requirements are for pages, events and I think a way to upload documents and notes from meetings. I’m working on pages right now, slow going while I relearn Merb but happy to be working on something interesting and new.

What do other Ruby Brigades have on their websites?

Rails MemcachedStore for the Memcached Gem

Sun, 26 Oct 2008 01:55:00 +0000

I’ve been experimenting with the memcached gem (the c gem that runs up to 150x faster than memcache-client). Merb already has pretty good support for the Memcached gem and in typical merb style does it better with fewer lines of code but I digress. Here’s my test implementation, so far so good nothing really heavy on it yet. YMMV so be warned this is not tested in a production environment don’t say I didn’t warn you so and such.


# in your environment file
config.cache_store = :memcached_store, 'localhost:11211'


# lib/memcached_store.rb
require 'memcached'

module ActiveSupport
  module Cache
    class MemcachedStore < Store
      attr_reader :addresses

      def initialize(*addresses)
        addresses = addresses.flatten
        options = addresses.extract_options!
        addresses = ["localhost"] if addresses.empty?
        @addresses = addresses
        @data = Memcached::Rails.new(addresses, options)
      end

      def read(key, options = nil)
        super
        @data.get(key, raw?(options))
      rescue Memcached::Error => e
        logger.error("Memcached::Error (#{e}): #{e.message}")
        nil
      end

      # Set key = value. Pass :unless_exist => true if you don't 
      # want to update the cache if the key is already set. 
      def write(key, value, options = nil)
        super
        method = options && options[:unless_exist] ? :add : :set
        response = @data.send(method, key, value, expires_in(options), raw?(options))
        response == nil
      rescue Memcached::Error => e
        logger.error("Memcached::Error (#{e}): #{e.message}")
        false
      end

      def delete(key, options = nil)
        super
        response = @data.delete(key, expires_in(options))
        response == nil
      rescue Memcached::Error => e
        logger.error("Memcached::Error (#{e}): #{e.message}")
        false
      end

      def exist?(key, options = nil)
        # Doesn't call super, cause exist? in memcache is in fact a read
        # But who cares? Reading is very fast anyway
        !read(key, options).nil?
      end

      def increment(key, amount = 1)       
        log("incrementing", key, amount)

        @data.incr(key, amount)  
      rescue Memcached::Error
        nil
      end

      def decrement(key, amount = 1)
        log("decrement", key, amount)

        @data.decr(key, amount) 
      rescue Memcached::Error
        nil
      end        

      def delete_matched(matcher, options = nil)
        super
        raise "Not supported by Memcache" 
      end        

      def clear
        @data.flush_all
      end        

      def stats
        @data.stats
      end

      private
        def expires_in(options)
          (options && options[:expires_in]) || 0
        end

        def raw?(options)
          options && options[:raw]
        end
    end
  end
end

Snippet

Thoughts on User.current and Thread Safety

Sun, 26 Oct 2008 01:38:00 +0000

Pratik Naik has an interesting post Thread safety for your Rails about what thread safety in Rails means (and what it doesn’t). One of the interesting points is that a common pattern of using class attributes is not thread safe and can lead to race conditions. I found it interesting because I’m a big proponent of User.current. I’ve always gotten great millage out of it and I’ve always felt like it’s a necessary evil for protecting user_id attributes from mass assignment and not totally driving yourself nuts with @foo.user_id = session[:user_id] all over your controller actions.

So the problem now is that if you ever intend to use User.current with a thread safe Rails app you’ve got to adjust fire. My thoughts are now turned toward investigating the following.


class ApplicationController < ActionController::Base
 before_filter :current_user_id

 # Set the value
 def current_user_id
   Thread.current[:current_user_id] = session[:user_id]
 end
end

class User < ActiveRecord::Base
 def self.current
   Thread.current[:current_user] ||= self.fetch_by_id(Thread.current[:current_user_id])
 end
end

Snippet

This seems like a thread safe method of accessing the current User without trading off the real functionality we want.

Slicehost Acquired by Rackspace

Sat, 25 Oct 2008 19:38:00 +0000

In case you’ve had your head in the sand the technology world is abuzz with hype about “the cloud”. Last week Rackspace had there own little cloud announcement and I was grimacing with the thought of yet another large host entering the fray. In case you don’t know I’m not a huge fan of “the cloud,” so I was imagining Rackspace might introduce yet another subpar on demand computing service. I couldn’t have been more wrong as it turns out. Rackspace wasn’t introducing a new unprove service, they were acquiring a proven leader already well respected in the industry, Slicehost.

Slicehost has been around for a few years now and has had such demand in the beginning I was on a waiting list. It was worth it because the service has been great. I’ve been hosting Snippy for a little while now on it and a few other things and I’m very happy. I’ve also had really great luck with Rackspace in the past so to hear that they were going to be adding their financial support and letting Slicehost run as a subsidiary is a awesome.

Slicehost will be able to keep it’s great level of support and is already lowering the pricing on some of their existing slices. Check them out if you’re looking for rails hosting, they’‘re well worth it.

Rumbling!!!

Sat, 18 Oct 2008 02:48:00 +0000

@actsasflinn and @rvr are doing Rails Rumble. We’re super psyched to do our project, Specify a collaborative spec’ing app. We’re just bootstrapping at this point but I’ll be updating this post all along and on twitter

Updates 2008-10-18 12:30:00 GMT-400 – Got the deployment environment all set and started some simple account management work…hmm saas railskit might have been handy. Hitting the hay.

2008-10-25 15:35:00 GMT-400 – Ugh, Rumble FAIL. We bit off more than we could chew and tried to build in too much real world functionality. In the end a line or so of code killed the project. Maybe not a bad thing since there was a considerable amount of unfinished functionality.