Google Checkout will not kill Amazon

The blogosphere is going nuts about Google Checkout today. The most controversial opinion comes from Rafe Needleman over at CNET, which calls Checkout an "Amazon Killer"

He couldn't be more wrong: People don't shop at Amazon just because you have your credit card information saved there-- almost all major e-commerce sites let you save your credit card info. People shop at Amazon because of low prices, huge selection, cheap/free shipping and great reliability. Google checkout provides none of this-- it is not a store, just a system to store credit card info. It is merely the Google version of Yahoo Wallet. Amazon and eBay have nothing to worry about. In fact, there's nothing stopping them from supporting Checkout themselves (aside from potential not-invented-here reasons).

Checkout is certainly significant, but not for the reasons Needleman mentions: The best part about Checkout comes by integrating it with Google advertisements. Forget cost-per-click, it's now cost-per-sale! This change makes click fraud is no longer something to worry about, which was one of the thorns in Google's side, at least in terms of Wall St perceptions of their business model.

I think Needleman's post is just another example of people gaming the blogosphere, as Richard MacManus ranted about the other day-- just write any "XYZ vs Google" post with an sensationalist headline and watch the hits roll in (this is the #3 post on techmeme right now). For this, Needleman gets a "nofollow" on my link-- this type of stuff shouldn't be encouraged.

google checkout amazon

RailsConf '06 Wrapup

RailsConf 06 just finished a few hours ago, and overall it was a great conference. Here are the day by day highlights:

- Intro to Capistrano: This session had people sitting out the door trying to listen. I hadn't seen cap in action at all til the conference, and I was really really impressed. We're seriously considering switching to cap instead of our current NUnit-based deployment and build cycle for Openomy.

- Rails Optimization: This talk started out a little slow, but then was amazingly impressive. Stefan Kaes demonstrated how to optimize your Rails app- what types of things to avoid, etc. He developed a view compiler which does some automatic optimizations on you views (such as pre-computing url_for calls, inlining some helpers, etc) which cause almost a 5x performance increase on complex pages!

- Demos & Lightning talks: Lots of really cool stuff was shown off. I was really impressed with Tunecore, a service that allows artists to submit albums to a variety of music services. Rightcart was also a really cool way to embed a shopping cart to arbitrary webpages.

- Keynotes: All of them were fantastic. Martin Fowler was an excellent speaker, and Paul Graham presented a great essay as usual. I already blogged about DHH's great talk last night. Dave Thomas' opening keynote a Hilbert-style "3 big problems for Rails adoption," which was a good call to action to kick everything off. Interestingly enough, by the time the conference was over, a few people had announced solutions to a few of these.

- Metaprogramming: There were 4 pretty good talks on the use of DSLs, metaprogramming, and other advanced Ruby. The best was Scott Halloway's "MetaRails" talk, which explored how a few of the more interesting features of Rails are implemented (ex, class reloading).

Overall, the conference was phenomenal-- you can never beat the excitement and energy of a "first conference." RailsConf '07 will be co-sponsored by O'Reilly, so it promises to be a much bigger show. I'll definitely try to make it out to that.

Instant REST on Rails: ActiveResource

DHH gave his keynote at RailsConf tonight, and it was totally awesome. It focused on the new CRUD features that will show up in Rails 1.2, and all of the niceness that comes out of them.

Taking a page from REST protocols such as Atompub and the related GData, Rails will support "resources." These resources are designed to support basic CRUD operations, which are driven by the full set of HTTP verbs: GET, POST, PUT, and DELETE. This, combined with the #respond_to and #to_xml methods already in Rails, as well as some enchancements to the Routes package, allow programmers to build very DRY RESTful websites and webservices.

The coolest part of the keynote was the Steve Jobs-esque announcement of the ActiveResource library, which DHH just started building a few days ago. This new library would abstract a REST webservice built following certain conventions, similar to how ActiveRecord currently abstracts a relational database. For example, you would write:

Person = ActiveResource::Struct.new do |p|
  p.uri "http://www.myhost.com/people"
  p.credentials :username => "maurice", :password => "pass"
end
person = Person.find(1)
person.name = "Maurice"
person.save!

Which would connect to the REST resource located at the give URI, and then use GET/POST/PUT/DELETE to interact with it-- essentially giving your REST webservice a free library that enables you to consume it. In this example, it would call "GET /people/1", turn the resulting XML into a struct. Then it would POST an updated copy of the struct to the service.

ActiveResource will make it almost trivial for Ruby programs to consume RESTful services and make it really easy to integrate multiple Rails applications, all while keeping a very simple API. Overall it looks great, and I'm really looking forward to be able to play with it.

Tags: railsconf activeresource REST

Windows Live integration is going to be HUGE

An article on CNET the other day described Microsoft's announcement of an SDK that would allow deskop applications with Windows Live ID. Richard MacManus commented shortly afterwards about how big this for Microsoft:

This strategy will define Microsoft's future, because in many ways it's the bridge between the old world (desktop software and the Windows OS) and the new world in which Google is a pioneer (web apps)

I totally agree-- Microsoft is one of the few companies with the reach to be able to take the web application mainstream. Just the Live ID API has potential to be the ultimate single sign-on solution: imagine being signed on to all of the windows live services just by starting a user session in Windows. Users may never have to sign in more than once again, and Microsoft would have an instant audience for its Live services.

This has implications for the online storage space as well: MSFT could automatically give all its users a small Live Drive account, sign-on to it on start up, and integrate it with Windows Explorer. Depending on how well this is executed, it could totally change the game for the many online storage services out there (including Openomy).

It will also be interesting to see is how tight the integration will be: Microsoft has gotten into a lot of trouble before by integrating IE and Windows Media Player into the OS. Successfully integrating the desktop with Windows Live would make life a little more difficult for many web startups and reignite antitrust concerns. With all the changes going on at MSFT recently, I'm really looking forward to seeing how this one plays out.

Econ 201: Oligopolies suck

Basic economic theory explains that oligopolies are inefficient, and should be avoided in favor of a free market with many many competitors. In college, we even mathematically "proved" it (with a few simplifying assumptions, of course)! Even if it is a fact, it's still great to see real-world examples that prove my old Econ 201 prof right.. there have been a few in the news recently: DRM and Net neutrality

What's missing in both cases is a good dose of competition. Unfortunately it's the innovator's dilemma again: their significant market power makes these companies lazy and gives them the ability to do as they please. Telcos can provide over-priced, slow service to users, and then can threaten to charge web companies for being able to interact with their customers. The entertainment industry can impose DRM'ed content on all of us, essentially taking full control over how content is used and distributed. Both of these issues would go away immediately if consumers had viable alternatives.

Where the heck are all the companies that are trying to disrupt the current state of these industries? I can think of many that have tried, but none that have made a lasting impact.

H1-Bs and startups

This post on the Meebo blog the other day about their experience with H1-B visas caused quite a stir in the comments. This year the H1-B quota was all used up about 2 months, leaving a lot of companies and a lot of people in a pretty bad situation: now two of meebo's new team members cant work in the US for another year and a half! Thats *aaages* in internet time. When this happens for a large corporation its already bad enough, but for a company the size of meebo, those two new employees represent like 20% of their workforce!

When the topic of immigration policy comes up, there's always a pretty fiery debate. The comments were full of stories about abuse of H1-B workers and the standard protectionist economics arguments in favor of the quota. While the protectionist argument does make a lot of political sense-- the people that benefit directly from it are the ones with the larger voting power-- economically it's probably the wrong solution.

If you want to make sure that Americans get the best jobs, then focus on making Americans the most qualified for that job and optionally provide businesses with an incentive to hire them. Depending solely on articifial barriers, such as an immigration quota, only avoids solving the true problem and creates the wrong incentives. For example: the most common suggestion given in the comments was to open a meebo office in another country. The current quota program encourages companies to send jobs offshore, where the workers wont be paying US taxes or contributing to the US GDP.

The truth is that the kind of people Meebo is looking for really are in short supply: not any schlub that knows some javascript is going to cut it. They want the smartest and the most innovative people they can get-- if the first ones they find happen to be born outside of the US, then so be it. It is more costly for the economy for companies like meebo to either have to lower their hiring standards or to wait for a local hire to appear, than it is to bring someone in from another country. (While it may only take an extra month to find a local hire, by that time meebo could've pushed out two new releases of features to their servers!) These startups and technology companies are keeping the US on the cutting edge of technology, and it is in the country's best interest to make sure they have the workforce they need to keep it that way.

I'm not advocating totally removing the quota either... there were many examples in that thread of comments that describe why this is undesireable. A better system must exist between these two extremes. Hopefully, now that immigration reform has become a mainstream political issue, there will be some dialog that results in a better system for both businesses and Americans.

Disclaimer: I'm on an H1-B visa in the USA, and I'm really grateful for the opportunity to be here. However, this may cause me to be a bit biased on this issue ;)

The State Pattern, Ruby-style

One of the cool things about using a language that allows for metaprogramming is that you can reduce the amount of boilerplate code you have to write. Common patterns can be put into libraries, and give you a small DSL that you can use to replicate this pattern all over your code. A good example of a common pattern with lots of boilerplate is the state pattern: where the behavior of an object changes depending on the internal state of the object. This can be accomplished by using a simple 'if' statement, or by modeling a finite state machine.

Check out a sample implementation on the RubyGarden wiki. We have a class for each state, a common parent class for the states, and a context class that delegates to the current active state class. That's a lot of code that doesnt really do much. Enter the StatePattern module, which puts all of this boilerplate in a small mix-in module, and ties everything together with some metaprogramming glue. Now we can write:

class Connection
  include StatePattern
  state :initial do
    def connect
      puts "connected"
      transition_to :connected, "hello from initial state"
    end
    def disconnect
      puts "not connected yet"
    end
  end
  state :connected do
    def initialize(msg)
      puts "initialize got msg: #{msg}"
    end
    def connect
      puts "already connected"
    end
    def disconnect
      puts "disconnecting"
      transition_to :initial
    end
  end
  def reset
    puts "reseting outside a state"
    transition_to :initial
  end
end

c = Connection.new
c.disconnect # not connected yet
c.connect    # connected
             # initialize got msg: hello from initial state
c.connect    # already connected
c.disconnect # disconnecting
c.connect    # connected
             # initialize got msg: hello from initial state
c.reset      # reseting outside a state
c.disconnect # not connected yet

.. and the boilerplate is all gone. How's it all work? Each call to state defines a new subclass of Connection that is stored in a hash. Then, a call to transition_to instantiates one of these subclasses and sets it to the be the active state. Method calls to Connection are delegated to the active state object via method_missing. This was a tricky one to get right! Download the source from here.