October 26, 2008 @ 03:57 PM by nap · 0 comments
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!
October 11, 2008 @ 05:42 PM by nap · 1 comment
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.
October 04, 2008 @ 03:24 PM by nap · 5 comments
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
