Programming

One of the great new standards made possible by OAuth is PortableContacts. Joseph Smarr from Plaxo is the main force behind it together with Chris Messina and others.

Portable Contacts as the name suggests is a standard for allowing one application access to your contact data on another application. The standard is a nice example of a very clean API which supports both JSON and XML.

I was looking around and I couldn’t find a Ruby library for it, so I wrote this simple Portable Contacts Ruby Gem to allow me and others to use it.

It requires OAuth and the Ruby OAuth Gem. If you need to use it with a Rails application use the OAuth Plugin if using straight Ruby use the Ruby Gem. All you need is an AccessToken object and a Portable Contacts URL to get started.

@access_token = ... # instantiate access token
@client = PortableContacts::Client.new "http://www-opensocial.googleusercontent.com/api/people", @access_token

# Get users profile

@profile = @client.me

puts @profile.display_name
=> "Bob Sample"

# Get users contacts
@contacts = @client.all

If you are using the plugin it is very easy to get started accessing Google.

Just install it and configure it. Once you have a GoogleToken for your user:

@google_token=GoogleToken.find_by_user_id @user.id
@client = @google_token.portable_contacts

# Get users profile

@profile = @client.me

puts @profile.display_name
=> "Bob Sample"

# Get users contacts
@contacts = @client.all

As this is the very first version there are likely to be issues, please do submit patches. I would also love to include a PlaxoToken etc for the OAuth Plugin if someone wants to submit one.

Plans

Eventually there will be some sort of auto discovery so you don’t need to provide a Portable Contacts url.

I would also like to add a server component to the gem, making it easy for you to provide portable contacts for your own application.

It has been fairly easy to provide OAuth services in your web application (see How to turn your Rails Site into an OAuth Provider), but to actually consume Twitter, FireEagle, my own Agree2 and other OAuth services has been a fairly manual affair.

There are great gems out there that wrap up the process for the above mentioned services. So it hasn’t been too hard to support one of them. But what to do if you want to support 5 different services today and more in the future?

I knew there should be some generic approach to handle the OAuth authorization process, but had not spent too much time thinking about it until we actually needed to consume external web services for Agree2.

Well I think I’ve cracked it in a a nice Dont Repeat Yourself fashion.

I am really happy to announce a major update to the Rails OAuth Plugin it has been coming over the last week or two with help from Nobukazu Matake.

The plugin is now a gem. Just install it with:

sudo gem install oauth-plugin

For a quick tutorial in how to use it see How to turn your rails site into an OAuth Provider.

New OAuth Consumer generator

The biggest news is the OAuth Consumer generator which should remove any excuses you ever had to not use OAuth when talking to Twitter etc. I will cover this in more the next blog post. For now checkout the README for more.

OAuth 1.0a support

The biggest change on the Provider side is support for OAuth 1.0a. There is also optional backwards compatible support for the insecure OAuth 1.0.

Please read Seth’s Idiot’s Guide to OAuth 1.0a for detailed information on what changed and why.

Nothing has changed on the OAuth 1.0a for existing AccessTokens, but if you need to support clients that only support 1.0 add the following at the bottom of your environment.rb file:

OAUTH_10_SUPPORT = true

HAML support

Both consumer and provider will now create haml view templates. Just use the —haml flag.

Cleanup and easier updates

The original plugin was a really quick proof of concept, with lots of things that really needed cleaning up. I am trying to do that little by little now.

The first step of this is to have the main functionality of the OauthController in a module within the plugin. This allows you to update it easily. We will do the same for the various Token classes as well over the next few releases.

How to upgrade?

As long as you’re using git/svn or whatever the easiest way to upgrade is to run the generator and let it overwrite your existing files. Then use a diff tool to bring any changes you had done into the new code.

If you don’t like the idea of doing that check the README for what should be done. Worst comes to worst create a dummy rails project run the generator and compare files.

Do you need advise or help with implementing OAuth in your Rails application?

I am available as a consultant and would be glad to help your company out. Whether you need help in developing an OAuth strategy or in practical hands on implementation help. Send me an email at pelle@stakeventures.com to let me know what you need help with and I can give you an estimate and my rate.

The Debian world seems to be on a rant on why the RubyGem’s are bad and why we should all be using aptget instead.

For rants see: Wouter – Rails? Stay the f* away from my system, Gunnar Wolf – Ruby has a distribution problem as well as the official Debian take on RubyGems.

However, the Debian/Ruby Extras team fear that Rubygems will make it much more difficult to package and distribute Ruby software in Debian (similar concerns have been raised by other individuals and GNU/Linux distributions)

Updated: Just discovered that Gunnar actually wrote this really good post It’s just a different mindset. Not necessarily a sane one, though, which I think is a way better explanation of his concerns. I still don’t see why Gems is “the most obnoxious of them all”. Gem’s can and should improve. But at its current state I actually do like it.

I always wondered why their rubygem package was intentionally broken. But never took the time to worry too much about it, when it’s easy to uninstall it and install it from source.

RubyGems like CPAN are about being OS agnostic when writing and deploying our apps. At the application level, I really do not care nor want to care about what server os I’m running.

I develop on Mac and deploy to Ubuntu, Gentoo, Redhat and OpenBSD. Using aptget, rpm, portage and pkgadd is fine for initial server setup and on going maintenance, but for day to day deployment of applications nothing but a PITA.

Different worlds, different points of view

The fact is that we are talking about 2 completely different worlds here. The whole thing is something very much akin to the old Men are are from Mars, Women are from Venus meme from a few years back.

For me my focus is the application. Most Ruby developers write applications for a living. For sysadmins their focus is on keeping servers running. Most Debian maintainers probably come from that world. Regardless if my assumption is right or wrong on that, their focus is definitely on Debian and not on Ruby.

So you now have the situation where an American is laughing at the stupid Limies calling a cigarette a “fag” and an Brit laughing at the stupid yanks calling a bum a fanny.

Get over it. We come from different worlds and have to live together. If your job is maintaining a bunch of sysadmin type services such as mail, dns etc you know what you need to do your job. Application developers also know what we need to do our job. It might even be that these things are different.

However if your job as a sysadmin is to support several web applications server, then I’m afraid when it comes to the applications you are no longer king. You need to support the developers and not hinder them.

But as Gunnar says:

By using Ruby Gems, you dramatically increase entropy and harm your systems’ security.

This is what we politely call FUD in the tech industry.

On the server it is the sysadmin’s job to understand the benefits of postfix vs. sendmail. tinydns vs bind etc. It’s the DBA’s job to decide on when MySQL 5.1 feels stable enough to use in production.

It is our job as application developers to understand the finer points between RedCloth 3 and 4.1. RubyGems allows us to test our applications with specific dependencies and make sure that this is exactly how they are deployed.

This enables us to have the confidence to deploy without having to do full regression testing when moving from a Gentoo to a Ubuntu server. Or to deploy minor updates from our Mac’s onto a server.

After having spent years of managing servers manually, the simplicity and beauty of deploying with capistrano is amazing. Besides initial server setup (which I can soon wave goodbye to thanks to PoolParty) I want to focus on the application.

RubyGem’s give me the freedom to develop on a Mac/PC and deploy onto just about anything. I deploy onto Ubuntu, OpenBSD, Redhat and Gentoo.

aptget is fantastic at what it does, installing base software on my server. Maintaining my application dependencies is just not its job. The Debian community is right to be conservative. However the ruby world works at tremendous speed, change is part of our core DNA.

I don’t want to necessarily be installing a new MySQL or GCC version on a daily basis, but I am willing to use the often daily updates of ruby gems. As I have the tests that prove they work and fantastic transparency about what was changed via GitHub

The Debian maintainers should stop breaking software out of some misguided principal. For gods sake Debian is an Open Source OS not North Korea. You broke your RubyGem package, now fix it.

There must be some way of creating virtual packages that just install the gem. This method could be reusable for Perl’s CPAN packages and any other application level packaging system.

Update: Violent platform wars going on over this post on Hacker News

RSpactor is one of the greatest tools out there for developing Rails apps on the Mac (Yes it’s Mac only) using RSpec. It works just like autotest, just with out any configuration and without using more resources than absolutely necessary.

Andreas is working on a next generation Cocoa based tool, which looks great. I know many of us are using the original command line version of it still, which unfortunately broke, when the RSpec team introduced some API changes. No worries though, I’ve forked the older command line version on Git which you can also install as a gem:

sudo gem install pelle-rspactor --source http://gems.github.com