zerosum dirt(nap)

At NH.rb last night I gave a talk about deploying web applications to the EC2 cloud with Rubber. Rubber is an extension to Capistrano written by Matt Conway that makes provisioning and managing multi-instance EC2 deployments magically delicious [GitHub].

Want to bring up an instant multi-role staging server fully loaded with Apache, Passenger, MySQL, and your Rails app? All gem’d up, migrated, and ready to use? Sure you do. First, sign up for an EC2 account, generate your keypair, and then…

gem install rubber

cd my-rails-project
script/generate vulcanize complete_passenger_mysql
edit config/rubber/rubber.yml

cap rubber:create_staging

It uses a Ubuntu AMI and provisions an EC2 small instance by default. If you added your account credentials and the apt packages and gems you needed to rubber.yml (and provided that there weren’t any unexpected problems), you should now have a fully functional staging server for your web app that you can visit at http://appname.your-domain.com.

Since it’s EC2 you only pay for what you use. What’s more is you can horizontally scale this out with relative ease — breaking out the individual roles to separate instances as needed — and/or add your own custom roles as needed (see the other templates available for examples).

Want to learn more? Peep my slide deck and then check out the Rubber Wiki.

The results are in for the 2009 Rails Rumble. Check em out and peep the winners. Some pretty impressive stuff for a single 48-hour sprint, right? Right!

I’d like to personally thank all the sponsors, expert panelists, and especially the contestants that made this years contest the best one yet. We’re looking forward to using the feedback we’ve received this year to make the next one even better, and starting to seriously discuss doing some more language/framework-agnostic events too.

But first, we need a little bit of a break :). Some downtime next weekend sure will be nice!

This weekend is Rails Rumble Build Weekend, which means that over 200 teams of 1-4 people are, at this very moment, working diligently (tirelessly!) to build the next awesome 48-hour micro-app.

This is the third year in a row we’ve run the contest and things seem to be going smoother than ever. Well, so far. Big thanks to Darcy Laycock, Erin Shine, and Jeff Rafter for being incredible co-conspirators, to all our competition sponsors, and especially to the participants who are really pouring their everything into this. I can’t wait to see how some of these ideas turn out.

In case you’re curious, we’re running the voting process a little bit differently this year, and have assembled a fine panel of expert judges to help qualify the best of the best before they go on to public voting. These people come from all corners of the web startup ecosystem and I’m really amazed that most of them were able to find the time in their busy schedules to help us out — we’re honored! So a big thanks to them, too.

The competition wraps tomorrow (Sunday) night at midnight UTC, and then the expert panelists have a couple days to work their magic. Public voting should probably open on Thursday if all goes to schedule. If you’re not competing you can still register for an account and help us judge! For more information, head on over to the competition site or check out the blog. Make sure to subscribe for updates. Thanks!

Need to unit test those pesky ActiveRecord observers you’re using? I don’t use em often, but there are times when they’re definitely useful. Fortunately, since AR::Observer leverages Ruby’s Observable module all you have to do is call MyModel.delete_observers in your test setup or before block.

ZombieSighting.delete_observers

Better yet, add the exclusions to your test or spec helper file. Then you can unit test your models comfortably in isolation, and write tests for your observers that look like this:

describe Observer
  before(:each) do
    @obs = ZombieSightingObserver.instance
    @thing = Factory.build(:zombie_sighting)
  end

  it 'should generate a new notification' do
    lambda { 
      @obs.after_create(@thing)
    }.should change(Notification, :count)
  end
end

We wouldn’t want to couple zombie sightings too tightly with notifications, after all, as that might anger them even further (zombies are known to be crazy about SRP).

Michael Bleigh’s TwitterAuth gem is truly full of awesome. It’s a complete OAuth authentication and API access solution for building Twitter apps with Rails. It uses familiar conventions borrowed from the Restful Authentication plugin, too. If you’re building a Rails-based app and you want to allow your users to Sign in with Twitter there’s just no better way to go.

For this particular app, I’m using the dynamic duo of Cucumber and Webrat to whip up integration tests. Since I initially stumbled a little bit when thinking about how to test integrated authentication against an external source like Twitter, I thought I’d doc the solution here in case other people were having the same issue.

Ready? Let’s do it.

Setup

First, install the TwitterAuth gem and use the provided generator to whip up the appropriate facilities. You’ll need to register your Twitter application accounts too. Or you know what? Screw it. If you want to make this super easy on yourself, Mike wrote a really great Twitter app Rails template that does all the setup for you, including walking you through getting the dev accounts. It’s nice, try it out. You’ll be up and writing Twitter apps in no time.

For the rest of this I’m going to assume that you have all of that working, and have installed Cucumber too. Don’t have Cucumber? Install it using RubyGems and then just run script/generate cucumber inside your Rails app.

Authentication Feature

So let’s write a Cucumber feature to test authentication in our boilerplate Twitter template application. Put the following in features/authentication.feature:

Feature: Authentication
In order to create and edit games
As a user
I want to sign in with Twitter

  Scenario: Login via Twitter
    When I go to "the homepage"
    And I follow "Login via Twitter"
    And Twitter authorizes me
    Then I should see "Logged in as"

  Scenario: Checking login status
    Given I am signed in
    When I go to "the homepage"
    Then I should see "Logged in as"

  Scenario: Log out
    Given I am signed in
    When I go to "the homepage"
    And I follow "Log out"
    Then I should see "Login via Twitter"

Step Definitions

Next, you’ll need to write step definitions to satisfy the missing steps. Do that by creating a file called features/step_definitions/auth_steps.rb. The content of the file should define the following two steps:

Given /^I am signed in$/ do  
  visit login_path
  visit oauth_callback_path
end  

When /^Twitter authorizes me$/ do
  visit oauth_callback_path
end

Fake Style

The secret sauce here is FakeWeb. We’ll use it to fake out responses from the Twitter auth service so that your integration tests stay local (and reliable). Make sure to gem install fakeweb, and add the following to tests/environments/cucumber.rb:

config.gem "fakeweb", :version => ">= 1.2.5"

Now edit Cucumber’s features/support/env.rb file:

FakeWeb.allow_net_connect = false
FakeWeb.register_uri(:post, 'http://twitter.com/oauth/request_token', :body => 'oauth_token=fake&oauth_token_secret=fake')
FakeWeb.register_uri(:post, 'http://twitter.com/oauth/access_token', :body => 'oauth_token=fake&oauth_token_secret=fake')
FakeWeb.register_uri(:get, 'http://twitter.com/account/verify_credentials.json', :response => File.join(RAILS_ROOT, 'features', 'fixtures', 'verify_credentials.json'))

Here we’re stubbing out the interaction with Twitter auth, and responding to all outbound authorization attempts with canned data. Note that this references a fixture file, containing a sample verify_credentials API response from Twitter. You can obtain a copy using curl from the comfort of your terminal prompt (substitute your own username and password):

curl -i -u user:pass "http://twitter.com/account/verify_credentials.json" > verify_credentials.json

And We’re Done

Alright that should do it. Go ahead and run rake features. Everything should be green. And green is good. If you need to write other features that are dependent on a login requirement, you can reuse the same “Given I am signed in” step that we created earlier.

Thanks to b.kocik, whose original post on using FakeWeb to stub Twitter auth was 80% of the solution I needed here.

We opened registration for the 2009 Rails Rumble yesterday. This is the third year in a row that we’re running the contest and it’s sure to be the best one yet. The build weekend is August 22nd-23rd but you need to register this week if you want a seat. If I were you, I’d go register now before it fills up ;-).

In other news, I’ll be presenting at the second Portsmouth Pecha-Kucha Night tomorrow, July 8th. I’ll actually be talking about the creative power of constraints, and describing our experiences organizing the Rumble will be a big part of that. If you’re in town, make sure to check it out. I’ve never done a p-k talk before but it sounds like it’s going to be a lot of fun.

I’m writing this from a cramped airline seat as we jet back from Las Vegas to balmy Manchester, NH (wifi on planes is awesome — thanks Southwest). Amanda and I spent a week in Vegas during which I attended Railsconf 2009 and caught a couple of pretty incredible shows. Then we road tripped it out to the Grand Canyon in Arizona and hiked in below the rim. Which was absolutely breathtaking. I wish we could have spent more time there and less in the city, to be honest.

Anyway, the conference itself had both its high and low points, but it was neither a total stinker nor an overwhelmingly fantastical experience this year. Peter Cooper, whom I had the pleasure of meeting there, has done a much better job than I of summarizing over at RubyInside. Friends Ben Scofield and Nick Quaranto also have some great notes at their respective sites. In fact, I’m going to steal Ben’s format for this post.

People

The best part of a conference is the people and the conversations, and the afterhours activities. Or at least, that’s been my experience thus far. This time around was no different. Greets to bcardadella, bphogan, brupm, bryanl, bscofield, cdwarren, croaky, cwsaylor, danabrit, davidcjames, defunkt, dpickett, erebor, fowlduck, greggpollack, graysky, jamesgolick, jeffrafter, jharuska, jimweirich, joefiorini, jnunemaker, jremsikjr, keavy, knowtheory, lazyatom, linoj, mbleigh, mojombo, patmaddox, peterc, qrush, rbates, reinh, robertdempsey, seanhussey, skizzles, solaredge, techpickles, wifelette, wycats, zachinglis and anyone else whom I might have forgotten to add to the list (sorry!). Thanks guys.

Sessions

The sessions this year were spotty, but generally I think the content was better than the previous Railsconf. I mistakingly sat through too many introductory talks and many others reported the same; everyone could benefit from session experience level labels. It’s weird that the organizers don’t do this, since they ask speakers about the experience level of their talks as part of the proposal process.

In any case, a number of the talks I saw this year stood out as being particularly great:

• Jason Rudolph and Larry Karnowski on JavaScript integration testing (using the BlueRidge project)
• Bryan Helmkamp’s Webrat talk
• Michael Bleigh’s Twitter app development session
• Blythe Dunham on her experiences integrating SMS support into Rails apps

There were a lot of talks this year about testing, cache control / optimization, and Rack / Rails Metal. As well as some useful Rails 3 speculation and discussion. All good stuff.

Interestingly, I really didn’t care for many of the (very rough) ideas expressed in Yehuda’s mountable Rails apps (Rails 3) session — in particular I really had no clue why they kept comparing Rails (a framework) to Drupal (a CMS). But, that said, the talk did do a great job stimulating discussion about alternative approaches in “CabooseConf” — apparently just a small room with, uh, tables and stuff — between myself, Bryan, Josh, Ted and others. For this reason it definitely belongs in my favorite sessions list.

[mountable app slices] are a challenging problem, and there are a lot of issues in terms of sharing application state, resolving cross-app dependencies, and so on. I hope that we’ll have an elegant solution to this soon; but I suspect that the real answer may be in making component-sized micro-apps easier to mount and integrate rather than taking an “app slices” or engines approach (if the latter case prevails, the Radiant extensions system has some stuff we can learn from).

The keynotes were mixed also

• The opening DHH keynote teased us with some interesting Rails 3 info but also repeated a lot of mantras we’d heard before with the usual rallying cries
• The “fireside chat” with Tim Ferriss was a bit of a disaster; although I think there were at least a few interesting nuggets in there somewhere
• Chris Wanstrath’s “how to be a famous Rails developer” essay was a definite highlight; well written and thought-provoking, it should be a wakeup call to those people in the community who put personal ego before productivity and creativity
• Uncle Bob was full of energy and was no doubt entertaining, but to be honest, the content was blah to say the least. More repetition of the same rah-rah we’ve had drilled into our heads for eons, without anything new. A little disappointed but almost everyone else seemed to love it
• The closing Rails core panel… to be honest, I skipped it. I hear it went well, though

The Rails Rumble Panel

Speaking of panels, I think our own Rails Rumble / productivity panel went fairly well, although it was missing much of the energy present in our pre-panel planning conversations, which was really a shame. It’s doing decent in the ratings but not stellar, hovering around a 3/5. As Ben (one of our panelists) notes on his own blog, the panel format can be a difficult one to get a lot out of, and I definitely felt this myself sitting through other panels last week. However, I think the Rumble panelists did a damn good job discussing the merits of innovation competitions and relaying advice about finding teammates / cofounders, translating their entries into marketable web properties, and noting the tips, tools, and techniques that helped them excel in a severely constrained timeframe.

Overall

I had a good time, and visiting Vegas for the first time was certainly an interesting experience. I’m glad I went, and happy that we had a chance to participate. It was awesome to see (almost) everyone from the community in the flesh again, especially folks like Jeff and Ben, whom I’ve been working on side projects with on and off. It’s amazing how much easier it is to hash out ideas in person that it is over chat or phone conversations sometimes.

Will I go again next year? I don’t know. If it’s in Vegas, probably not. As much as I enjoyed seeing the sites, frankly I felt that it was a bit distracting. If the conference is in Vegas again next year, I certainly hope the organizers hold it somewhere other than the Hilton. Although it was easily accessible by monorail it’s relatively removed from the rest of the strip, and the in-venue food and entertainment options there are limited to say the least. If I’m going to be distracted, I at least want those distractions to be convenient! At least a drunk Billy Mays was there (at the Hilton, attending another convention). Maybe next year we can get him to show us how to pitch our apps to consumers during a keynote? Maybe?

Railsconf is less than two weeks away. I’m pretty excited because this year we’re doing a Rails Rumble panel with a bunch of swell people who developed some pretty amazing things within the compressed event timeframe (48 hours). Winners and other innovators from both the 2007 and 2008 events will be present. The session is called “Starting Up Fast: Lessons from the Rails Rumble” and the point of it is that these guys will be sharing the tips and tricks that let them build great stuff quick with Rails. Hopefully their advice will be applicable to your own startups and hobby projects, in “real life” as well as within the innovation competition atmosphere.

So this is where we need your help. What do you want to ask them about? Project scoping for early and frequent iterations? Essential dev tools and techniques? Finding dependable partners / cofounders? General work habit questions? Inspirational mantras? Anything goes. Please submit your questions via Google Moderator. The event will be recorded and made available afterwards, so you won’t have to be in attendance to get your answers.

I’m happy to report that our panel, Starting Up Fast: Lessons from the Rails Rumble, has been accepted for the 4th annual Railsconf event in Las Vegas.

I’ll be moderating a panel of competition winners and participants, and we’ll be discussing how they were able to achieve some impressive feats in the compressed contest timeframe. It should be packed full of useful real-world advice on how to organize and launch Rails applications quickly. We’ll also talk about the event itself, and the nature of innovation competitions in general (and why you should get involved!) I guarantee that it will be fun, but I can make no guarantee about whether or not there will be choreographed mock-fighting. That’s up to you.

Panelists include our friends Joe Fiorini (grand prize winner 2008), Josh Owens (grand prizer winner 2007, design award 2008), Ben Scofield (winner, solo division for both 2007 and 2008), James Golick (winner, most useful 2008), and Darcy Laycock, who participated in the 2007 contest and joined the organizational team for the 2008 event.

So if you’re making the voyage to the City of Sin in May, make sure to check us out. I’m excited, and it’ll be great to meet many of you there! Also, you can teach me how to gamble. I hear that I have a pretty bad tell. Whatever that is.

UPDATE 3/16: The panel is scheduled for May 6th from 4:25pm to 5:15pm PDT in Pavilion 9 – 10

We launched a new Radiant-based site for a client last month. It was a small project but involved the creation of a couple new extensions, so I thought I’d take the opportunity to OSS them. In case anyone is interested…

• Flash Gallery Extension—An extension that works with Todd Dominey’s excellent SlideShowPro (SSP) Flash component to easily create elegant Flash-based media galleries within Radiant (Note that SSP is a commercial product; however a trial version is available suitable for testing this extension).
• Upcoming Events Extension—An uber-simple extension that allows creation and management of important dates within a Radiant CMS instance.

That is all.

Wow. Well, this is… somewhat unexpected. And very, very cool.

No kidding, right? Personally, I’m excited. I think the Merb 2 / Rails 3 announcement makes a ton of sense (read the links above for details); Rails with a modular Merb-like architecture and a set of reasonable Rails-ish defaults is an epic win for both camps, if done right. It’s truly an exciting time to be a Ruby developer. Happy holidays everyone.

Back when I was a Java developer, I knew and really liked me some IntelliJ. Later, when I moved over to Ruby full time, NetBeans seemed like a damn good choice. After all, I was used to having a “proper” IDE, it had pretty nice Ruby support and also, much to my joy, it had a Vim plugin, which allowed me to use my favorite editor from my pre-IntelliJ days. Win.

Fast forward to about six months ago when I decided that I’d ceased to care about heavyweight IDEs. I just didn’t use enough of their features to make their overall (often cumbersome) weight and memory footprint worthwhile. So goodbye NetBeans with Vim plugin and hello Vim. MacVim, specifically.

Why Vim? Because Vim is universal. Because Vim is love.

Dave Thomas and Andy Hunt famously wrote “Choose an editor, know it thoroughly, and use it for all editing tasks” in their seminal masterpiece, The Pragmatic Programmer. I couldn’t agree more. There is no tool in a programmer’s toolbox more important than an editor, and the importance of knowing it inside and out cannot be understated. For me, ever since college, that editor has always been Vim. It was just everywhere that I needed it to be. It was ubiquitous. I could use Vim at home on my desktop, at school, at work in the campus NOC, at the CS lab, and in any number of remote shell sessions, on even the most obscure platforms. One ring to rule them all.

Vim is also small, and quick. Once you know what you’re doing, it’s quicker and easier to manipulate text in Vim than any other editor that I’m aware of. Of course, the learning curve is steep, relative to other editors. But it’s worth it. When I’m writing code, switching between files, replacing text, et al, I don’t want to have to use the mouse too frequently. Vim, in all of it’s keyboard-centric glory, delivers. MacVim also provides awesome mouse highlighting and menu option support, for the best of both worlds.

There’s also massive value in Vim’s powerful plugins system. Without some of these awesome third party extensions folks have developed for Vim, it wouldn’t be nearly as appealing as a desktop code editor. But by adding plugins like NERDTree, rails.vim, vcscommand.vim, and FuzzyFinder, it becomes a full-fledged programmers editor for me, something that easily outguns TextMate, NetBeans, Komodo, and all the other would-be competitors. Customize it to your hearts content.

Anyway, I just wanted to put that out there. Vim rules. And Tim Pope, author of rails.vim, rules too (even though he looks awful in drag). His plugin, along with NERDTree, vastly simplifies my day to day editing tasks, and reproduces all the functionality I would have actually used from a more fully-featured IDE. Thanks guys. You’re my heroes.

For more information on using Vim as a Ruby developer, see Jamis Buck’s post from a few months back about switching back to Vim from TextMate. It’s a well-written argument, but the really amazing thing about the article is the number of comments it generated. It’s great to see so much love for such a great editor and I’m glad to be in such good company.

So, what’s your favorite go-to editor? If it’s Vim, I’d be curious to know what plugins you’re using and how you’ve customized it.

PS If you’re also a MacVim user, make sure you install the :Bclose script too!

OK, I’m being a bit overly dramatic. But seriously, go sign up to judge and vote in the 2008 Rails Rumble. Help us decide which of the amazing web applications featured on our leaderboard deserves to take home the goods. Oh, and tell your friends. The more opinions the better.

If you need extra motivation, we’re giving away a number of Amazon gift certificates to random voters. There’s still time, but hurry up; voting ends November 1st.

While we’re on the subject, there’s also another important election coming up too ;-). I’m not going to pretend to tell you who to vote for, but (if you’re a US citizen) just make sure you understand the issues at stake and vote responsibly. Thanks!

The build portion of the Rails Rumble is next weekend. Wow, time really flies, eh? It seems like it’s only been a few weeks since we announced it. We filled all 200 seats this year and even had to open up a few more. I’m really amped, and am looking forward to seeing some truly amazing microapps come out of this weekend sprint. I think they’re going to be even better than last years’. I hope you’ll help prove me right.

Anyway, I posted earlier today over on the Rumble blog about our decision to mandate OpenID usage in the registration (and voting) app and JanRain’s involvement in the Rumble as a sponsor. We’re using their new OPX ASP service to provide branded railsrumble.com OpenIDs to users who don’t have them. It’s pretty great. We really didn’t want to run our own provider and then be saddled with the upkeep of it. It makes much more sense to delegate that to a third party who is an expert in that realm.

Personally I think OpenID is, for the most part, pretty swank. Yes, it has its flaws. And maybe it isn’t a proper fit for every application. But for an event of this sort, a decentralized identity / login system is absolutely critical. It would be silly to force users to create dozens of different accounts (all with different login names, password criteria, etc) just to evaluate new applications.

I’m both excited and relieved that providing OpenID registration services is becoming easier and easier. It’s really about time and SaaS OpenID facilities makes a ton of sense for sites, like us, that want the benefits of providing OpenID without the hassle of operating and maintaining it long-term.

I expect a lot of competitors this year to use Jim Neath’s Bort or a similar blank slate Rails application to bootstrap their development. This is a good thing and it doesn’t void the rules in any shape or form as long as the kit is just bundling plugins and not providing major application functionality in and of itself (like Radiant or Spree does). One of the best things about Bort is that it supports OpenID right out of the box, in addition to stock Restful Authentication style user accounts. Epic win for you. And your users.

If you aren’t using Bort or something similar, you may want to check out our OpenID Simplified plugin, which was extracted from the Rumble voting app itself. It’s a combination of the classic OpenID Authentication plugin with some bits from Restful Auth, and a few extras to make adding OpenID-based user accounts to your application dead simple. What it doesn’t do, however, is provide non-OpenID-enabled account creation.

“Wait, what? You can’t create accounts with it?,” you ask, “What were you thinking?”

First of all, yes, you’re right. OpenID isn’t ubiquitous yet. And maybe it never will be. But it’s certainly better (at least imo) than creating yet another user account with yet another set of credentials (or worse yet, the same set). Options like the free MyOpenID affiliate program and JanRain’s branded OPX service make it just as easy to have users proxy-register with them as it is to create a one-off local user account. By signing up with one of these services you can provide your own logo and copy and have the logged-in user directed back to your site, once they complete the signup process.

Also, by integrating the ID Selector widget, many of your users even realize that they actually already have an OpenID account – via Flickr, Blogger, Wordpress, etc – and therefore bypass this unnecessary registration situation altogether.

My point is that, although it may not yet be perfect, we’re getting to the point with OpenID services where adding support for them is almost as straightforward as implementing our own local accounts system. Many of your users will already have an OpenID account. Sometimes they just need to be made aware of it. For those who don’t, it’s becoming easier and easier to allow them to create an account that they can use anywhere, without placing the burden for maintenance of that on yourself.

Workling is my current sauce of choice for interfacing with message queues and performing asynchronous background tasks in Rails apps. We’re using it in production in a couple of places (with Starling) and it works great. In fact, we liked it so much that we wrote about it in Practical Rails Plugins.

Anyway, one thing we didn’t discuss there was how to test your workers. I’m an RSpec junkie, and I want to make sure that my Workers are behaving the way that I expect at all times. The solution is pretty simple. I modified a code snippet written a while back by David Altenburg to spec his BackgroundRB workers…

Just add the following to your spec/spec_helper.rb:

module Workling
  class Base
    class RailsBase
      def self.register; end
    end
  end
end

worker_path = File.dirname(FILE) + "/../app/workers" 
spec_files = Dir.entries(worker_path).select {|x| /\.rb\z/ =~ x}
spec_files -= [ File.basename(FILE) ]
spec_files.each { |path| require(File.join(worker_path, path)) }

Now you can add specs for your workers to spec/workers/my_worker_spec.rb:

require File.dirname(FILE) + '/../spec_helper'

describe MyWorker do
  it "should manufacture a new widget at the happy castle widget foundry" do
    Widget.should_receive(:find).with(1).and_return(@widget = mock_model(Widget))
    @widget.should_receive(:manufacture)
    MyWorker.asynch_manufacture_widget(:widget_id => 1)
  end
end