On the request of many people here is a quick guide to developing OAuth Consumer Application (Consumer==Client in OAuth Speak) in Ruby.

I will be using Agree2 as the sample application here, so feel free to go Register and load up a irb session to follow along. You could also do the same with Twitter’s OAuth or any other OAuth server.

The general process is:

1. Register your consumer application with the OAuth compliant service to receive your Consumer Credentials (This is only done once)
2. You initiate the OAuth Token exchange process for a user by requesting a RequestToken from the Service
3. You store the RequestToken in your database or in the users session object
4. You redirect your user to the service providers authorize_url with the RequestToken’s key appended
5. Your user is asked by the service provider to authorize your RequestToken
6. Your user clicks yes and is redirected to your CallBack URL
7. Your callback action exchanges the RequestToken for an AccessToken
8. Now you can access your users data by performing http requests signed by your consumer credentials and the AccessToken.
9. ????
10. PROFIT!!!

Get your Consumer Credentials

Once you are logged in to Agree2 click the Manage OAuth Applications link in the footer:

All OAuth capable applications require you to register your own application first to get your consumer credentials:

Click Register your application

Enter the name of your application, the url of your application, the callback url and an optional support url.

The callback url is the url that Agree2 redirects to after a user has authorized a token for you. For now just enter a url like http://myapp.com/oauth_client/callback. Click register and hey presto:

These are your applications Consumer Credentials.

Hooking up your code

As we are nice guys here at Agree2 also provides actual sample Ruby code on the credentials screen. I will go through this step by step.

First of all you need to install the oauth gem (make sure you have at least 0.2.2):

sudo gem install oauth

Your code needs to require the gem and the consumer part of the library:

gem 'oauth'
require 'oauth/consumer'

Instantiate your Consumer object with your credentials:

@consumer=OAuth::Consumer.new "AVff2raXvhMUxFnif06g", 
                              "u0zg77R1bQqbzutAusJYmTxqeUpWVt7U2TjWlzbVZkA", 
                              {:site=>"https://agree2.com"}

Now request a token from Agree2. This method actually performs a signed http request to https://agree2.com/oauth/request_token :

@[email protected]_request_token

Now you need to redirect the user to the authorize_url

If you’re in irb just output the url:

@request_token.authorize_url

In a real rails application you would perform a redirect:

redirect_to @request_token.authorize_url

The user will be taken to this screen to authorize the token:

I think we need to work a bit on the user interface for this. But it does work. The user authorizes the token. and the user is redirected to the callback url you specified earlier.

In your callback action you now need to exchange the request token for an AccessToken:

@access_token=@request_token.get_access_token

Now you are ready to do whatever you wanted to do:

# Request all your users agreements
@response=@access_token.get "/agreements.xml"

The access token object has all the normal http request methods and returns a standard ruby http response.

Our next step is to integrate this with ActiveResource. This is being worked on now. Once this is done I will update this tutorial.

If your company needs help getting your OAuth Strategy right or implementing OAuth in your application I’m available for consulting work [email protected].

I see Google is creating a Alumni Relations Program to help create a informal network of ex Google employees.

I think this is a great idea. I’ve always thought that current employees should be (but rarely are) thought of as potential future ambassadors, business partners and clients.

Alumni such as the PayPal alumni, often go do great things together based on their informal network. Rarely does the originating startup benefit at all from these often very strong networks.

I think the following 2 problems are what causes this.

Tight knit startup cultures and traitors

Good startups have a very strong team culture. We’re all in this together, we’re taking the same risks, working the same hours, living the same dream.

This culture is great and important but it also has the very natural side effect of turning people who leave to pursue other dreams into traitors.

There are these awkward moments before the traitor leaves, where no one really wants to talk about it. After the person leaves, he is a natural scape goat when the server crashes as an after affect of that 3am hacking session a few weeks ago.

All in all it’s about as uncomfortable as a divorce, with many of the same symptoms.

I’m not quite sure how to avoid this. But one way would be to actually discuss these things when the employee starts. Lets realize that it’s a real possibility that employee nr 4 in a hot San Francisco Startup might get a more interesting offer or start his own shop in 6 months time. It has been known to happen.

Rather than all the uncomfortable silences you should rather look at this as an opportunity. Talk openly about where they employee is going and what he’s going to be doing. Encourage him to stop by for lunch in the future, who knows there may very well be something that the 2 startups involved can do together in the future. Even informally.

He should be your ambassador and a potential future partner. You might even want to pay a small monthly retainer for him to help out an hour or two a month in case a problem comes up only he knows how to do.

How stock option vesting affect alumnis

Traditionally startups have been desperate to retain employees for as long as possible. One of the ways this is done is by offering stock options with long vesting periods. This means you would have to stay in the company for say 2 years before you could exercise (sell) your stock options.

This I think is a mistake. I have known many people who really want to move on and do something else often for them selves, but who have felt stuck and bitter due to this contract. You often hear the term indentured servant being thrown around.

What happens is one of 3 things:

1. The employee sticks out the vesting period, making money from the options. He’s a happy man. However he still might leave shortly after he is able to exercise his options.
2. The employee sticks it out for the vesting period. His stock options are fully vested but worthless. He is bitter that he wasted 2 years of his life on this, when he said no to other offers or he could have started his own shop.
3. The employee leaves early for a better opportunity feeling bitter that he left the stock options. Often this kind of employee starts bad mouthing the old startup. The founder was a fool, the VC’s destroyed it whatever. Typical drunk bar talk in the Bay Area.

Now the Alumni program Google has fits well with them as their alumni probably come under the first item above. Their alumni are happy, they made out well and now want to experience new things.

A better solution

I know nothing about stock option law etc. But I can’t help thinking that a more flexible approach to stock options for employees (and freelancers even) might hold part of the solution.

Is it possible to vest someone bit by bit on a quarterly basis? Maybe vest entirely within a year, but from the outset offer bonus stock options if you make it to year 2. That small change itself might make stock options feel more like carrots than shackles. Less bitterness.

Once an employee leaves, why not allow some kind of limited stock option plan as part of being part of the informal alumni network and/or being on retainer.

I know there are all kinds of solutions to this. However I feel that too often very innovative startups keep doing things the way they always have been done in the valley. Without questioning why.

This has been another piece in my blog series Think outside the Rounded Box.

Today I released the new version of the OAuth Rails plugin . This finally supports the new “all together now” release of the OAuth Ruby Gem, which Blaine Cook and me have worked hard to merge together from our previous incarnations.

I previously posted a guide to how to turn your rails site into an OAuth Provider, which should still be pretty much be correct as there haven’t been too many changes to the api that you would use within your rails application.

See the OAuth Plugin Documentation for more detailed installation instructions.

If you are using the plugin or gem please join the OAuth-Ruby Google Group

Updating

If you have previously installed the plugin you need to first update your OAuth gem to the latest version. I’m afraid you also do need to rerun the generator. There haven’t been any changes to the view code so you can leave them be if you’ve made your own changes.

Credits

The new OAuth gem was basically a merge of my previous gem which we merged with the Blaine’s original OAuth code, which is used on Twitter. Large chunks of this has been written by Larry Halff and Jesse Clark of Ma.gnolia. Further help and patches came from amongst other people Pat Cappelaere, Jon Crosby, Seth Fitzsimmons and Phillip Pearson.

Please, please, please get with the program. Checks are ancient pre industrial age relics that still hang around in a few places in the world. Unfortunately the worlds most dynamic economy the US is still addicted to checks. This makes this article extremely US centric, but it also affects non US readers who do business with US businesses.

I also want to say that I am not in anyway targeting any specific clients of mine here. This is a generic problem and based on conversations I have had with other US based freelancers. That said, with the exception of one client all my US clients have insisted on using checks.

I am targeting web 2.0 businesses here in particular. We are constantly asking other people to “think outside the box” and do things transparently and online. Paying people with checks is basically the least transparent and online thing we do as part of doing business. There are great alternatives that we can and should use.

What is so wrong with checks you might ask?

Everyone uses them? First the obvious:

• Snail mail is so 1980s
• I have better things to do than go stand in line at a bank (thats such an old fashioned activity)
• Relatively high risk for recipient
• Slow clearing. In particular for international payments.
• For international payments the recipient (and his bank) is likely to say “what is this thing you call a check?” (See Jarkko’s experience trying to deposit a US check in Finland)

Living in SOMA San Francisco like I do, you often feel (rightly or wrongly) that you are part of this massive revolution. Earlier it was labelled the “dot com/bomb” revolution, now it’s more likely to be the “social network” or “Web 2.0” revolution.

It can be argued that some of this is nothing more than just another reality distortion field, but with some critical thinking I think these are all part of a longer and very real revolution happening in both society and economics.

You do get some very smart people here (and elsewhere of course) thinking about real innovation in a number of fields. There is one thing though I have noticed and that is outside the world of their exact field of interest (data portability, video sharing, project management etc) the majority of the startups do very little innovation in the day to day aspects of their business.

My plan here is to create a new category in my blog like I originally did with Bootstrappers Anti-Patterns which I’m calling Think outside the Rounded Box, where I will try to talk about some of the silly old habits that even real innovators unfortunately still follow.

These are based on a combination of my own experiences and talking over the last year to lots of different people working with and in the “social network” or “Web 2.0” revolution.