The code bellow is a mashup of the available options that seems to work just fine.

require 'xmlrpc/client'

# build a post

post = {
  'title'       => 'Post Title',
  'description' => 'The content of the post',
  'mt_keywords' => ['a', 'list', 'of', 'tags'],
  'categories'  => ['a', 'list', 'of', 'categories']
}

# initialize the connection

connection = XMLRPC::Client.new('yourdomain.com', '/xmlrpc.php')

# make the call to publish a new post

connection.call(
  'metaWeblog.newPost',
  1,
  'wp_username',
  'wp_password',
  post,
  true
)

I was a little surprised by how not straight forward this was, but, like I said, this end result works.

set :git_enable_submodules, true

Found that by searching through the Capistrano change log. There’s probably some better documentation somewhere, but that worked.

The hangup, if you aren’t running a web application, is that the process involves several redirects with form data to exchange your application’s identifying information, prompt the Twitter user to allow access, and receive and store the resulting token. With no web application to handle such requests, a CLI bot needs an alternative (though one-time) method of obtaining a valid token.

After looking around for a while, I found this Ruby script (cleaned up below) which uses the twitter_oauth gem to walk you through the process.

require 'twitter_oauth'

client = TwitterOAuth::Client.new(
  :consumer_key     => 'TWITTER_CONSUMER_KEY',
  :consumer_secret  => 'TWITTER_CONSUMER_SECRET'
)
request_token = client.request_token

puts "#{request_token.authorize_url}\n"
puts "Hit enter when you have completed authorization."
pin = STDIN.readline.chomp

access_token = client.authorize(
  request_token.token,
  request_token.secret,
  :oauth_verifier => pin
)

puts access_token.inspect

When running the script, navigate to the URL it prints out and follow the on-screen instructions to obtain a PIN. Then return to the script, paste in the PIN, and press enter. The resulting variable dump will contain both a valid token and token secret that can be used in conjuction with your consumer information to connect to Twitter.

For example, you could now use grackle to make Twitter API calls:

require 'grackle'

TWITTER_AUTH = {
  :type             => :oauth,
  :consumer_key     => 'TWITTER_CONSUMER_KEY',
  :consumer_secret  => 'TWITTER_CONSUMER_SECRET',
  :token            => 'TOKEN',
  :token_secret     => 'TOKEN_SECRET'
}

client = Grackle::Client.new(:auth=>TWITTER_AUTH)

… and you’re set.

The basic thrust of the talk was the inner-platform effect and why it matters for WordPress developers. Really, I think it’s one of the biggest problems for anyone involved in making and/or using web applications these days. This was a way to get the point out there quickly, but hopefully I can follow up with some writing on the topic sometime soon. (Famous last words, I know.)

This WordCamp seemed to be a lot more focused on the small business aspects of the WordPress community than the one we attended in New York, but we did get to see some great (if brief) dev talks on the WordPress API, HTML5, etc. and one very reassuring panel on using WordPress in academics. I also had a great time listening to Doc Searls and David Weinberger talk about The Cluetrain Manifesto among many other topics. They’re the kind of people I could listen to for hours.

At some point they were asked about net neutrality and gave an answer I hadn’t really heard before: no one really knows how to define net neutrality, but the problem could be solved by forcing content and application providers to stay out of the broadband business. I suppose that’s an internet-as-utility argument, but it’s not something that seems very present in the political debate.

Anyway, thanks to all the organizers and especially Mitcho for putting together the Ignite event.