With the competition less than a month away things are really starting to ramp up here. We’re pulling together the final members of our expanded expert panel (to be announced shortly), working on updating the voting workflow and dashboard code, and starting to put together the prize list.

I think we’re probably supposed to be doing some other stuff too, but I forgot what.

We’ll have more updates for you soon. In the meantime, if you’d like to show your support, feel free to toss this Rails Rumble badge up on your blog, company website, or placeholder page. Leave a comment if you post it somewhere so other competitors or fans can find you!

We have gotten a couple of "rule clarification" emails here at the dojo. Most of these are on what you are allowed to do before the competition begins. According to the rules:

You can, of course, work on the concept for your application before the competition starts, including paper mockups of the user interface and database entity diagrams. But no digital assets can be created until things officially get rolling. This includes digital mockups of any sort, graphic design assets, code, etc.

So where does cucumber fit in? Is it a mockup? Is it a digital asset? Can you do it before the competition? We discussed this all week and came to a ruling.

The official ruling is: no, you cannot write cucumber features before the competition begings.

While we strongly encourage you to plan out your application features beforehand, we felt that cucumber falls under "digital assets" being developed before the start date. Because cucumber is a set of executable specs that are specific to an application (unlike a public plugin or gem) we decided this violates the rule and should be avoided. Emailing back and forth describing features is of course expected and welcome, but formalizing that into .features goes against the spirit of the competition.

Some further clarifications:

• Paper mockups are good; Photoshop mockups beforehand are bad
• Shooting schedules are good, Video and photography beforehand are bad
• Planning what each object and database table will look like is good, pending specs beforehand are bad
• Setting up domain names, blogs, twitter accounts that you use to promote your application or track your team progress is good, writing your whole application beforehand is bad

Some more gray areas:

• Chef scripts - if these are public and not specific to your application they are permitted
• Bort scripts - if these are public and not specific to your application they are permitted
• Rails Templates, Base applications - if these are public and not specific to your application they are permitted

We should stress that your template, script, or plugin must be generic and open. If you are the only person in the world that is using it then it might be pretty hard to argue that it is not specific to your application. So be careful and make sure it is generic. For example, the twitter template mentioned in This Bird's Ready to Rumble is allowed, but my "Secret-Rails-Template-For-My-Rumble-Ninja-App-of-Doom" would probably not be.

We want you to plan as much as possible before the competition without starting early! We are eager to hear feedback on these rulings. This is one of those areas that may change next year based on your feedback.

Note: This is a guest post courtesy of our friends at Intridea

Last year, there were a quite a few of Rails Rumble applications built around Twitter. And that was before @Oprah. We’ve had some experience building applications with, like, for, and around Twitter at Intridea and we thought that we could share a few useful gems (in both the knowledge and Ruby sense) that we’ve come across along the way. We expect to see a huge number of creative Twitter apps coming from the Rumble teams this year.

Why Twitter?

Twitter’s a great platform for the Rumble. Why? You don’t have to worry about that pesky “empty app effect” when your users sign into the application for the first time. You get to leverage the billions of existing tweets, giving you a huge head start on the competition.

Also, Twitter’s a really easy platform on which to build an app, especially a Rails app. After all, 48 hours is at least two or three weeks in Twitter years. Don’t believe us? Back in May, one of our Intrideans built a complete Twitter on Rails application on stage at RailsConf in about 30 minutes. As Rumble participants, you’ve got up to 4 times as many people and nearly 100 times as long to build your apps. Almost seems too easy!

Your Twitter Toolchest

There are a great many Ruby libraries to interact with Twitter, but if you’re really looking to build a Twitter-centric application quickly, we recommend you take a look at TwitterAuth. TwitterAuth is a full authentication stack that connects using Twitter’s OAuth protocol. It does all the heavy lifting so you can stop worrying about getting users signed up and start worrying about what they’ll do once they are! There are already some interesting apps using TwitterAuth every day in production, like Pix.im, a TwitPic alternative, and TwitterMass.

Of course, Rails Templates are really the way to go if you’re looking to get an app up and running in the shortest time possible, and luckily there’s a TwitterAuth-based Rails template that will get you up and running in no time. Here’s a blog post about it, or if you’re feeling adventurous you can just get started immediately:

rails -m http://bit.ly/twitter-rails yourappname

You will be walked through the setup process and at the end of the process you will be ready to start adding functionality to your app!

Of course, even applications that aren’t quite so Twitter-centric can benefit from some Twitter integration. Here’s a list of some resources that may inspire you to include them in your Rumble application in some way.

• Twitter is one of the most popular gems for consuming the Twitter API, but we also like the simplicity and power of Grackle.
• Floxee is an interesting project that lets you easily create a Rails Engines driven tweet-tracking directory. It’s sparse on documentation, but might be worth a look-through.
• If you’re feeling adventurous, you might consider trying to work with the Twitter Streaming API using a library such as YAJL to parse tweets off of the stream in real-time.
• Maybe you just want a simple way to show off what people are saying about your app. A simple and customizable Javascript-driven Twitter search widget is available through TweetGrid.
• If you run into some Twitter issues along the way, the Twitter Development Talk Google Group is pretty actively watched even by employees of Twitter (though perhaps not so much on the weekends). Use it as a resource of last resort!

There’s a whole universe of existing OSS out there to connect with, post to, and otherwise fool around with Twitter. This is a small sampling we hope will give you some inspiration to get started on your Rumble app!

Keep in Touch

Of course, another reason that we’re so interested in Twitter, its API, and its applications is because of our flagship product, Present.ly. Present.ly is a private micro-blogging platform for teams with groups, file-sharing, and a fully Twitter-compatible API. If your Rumble team is distributed across the country, Present.ly might be a great way to keep in touch during the competition. In fact, you can even hook it up to GitHub to get every commit your team posts during the competition live in your feed.

As we sign off, we’ll leave you with a list of Twittering Intrideans who will be competing in the Rumble this year:

• Adam Bair (@adambair)
• Michael Bleigh (@mbleigh)
• Brent Collier (@brentmc79)
• Pradeep Elankumaran (@pradeep24)
• Joe Grossberg (@grossberg)
• Brendan Lim (@brendanlim)
• David Naffis (@naffis)
• David Potsiadlo (@davidpots)
• Chris Selmer (@cselmer)
• Ping Yu (@pyu10055)

We’re looking forward to seeing the awesome stuff the community comes up with for the Rumble, and best of luck to all the teams. We’ll see you on the Rumble-field!

With registration now closed, we're slowly working on the process of preparing for the next stages of this RailsRumble. In an effort to help clear up everything, we're requiring pending teams (you'll know if you've either have received a pending email but not an approved email or if you've got a big pending warning on your team page) complete the signup process by paying your donation via paypal or contact us.

Teams who haven't paid / contacted us by 23:59 GMT, July 22nd will then have their team removed from the contest in order to give spots to others who wish to compete. If you're on one of the pending teams and have any questions / problems or simply want to be removed from the competition before then, feel free to contact us (either via the support link in the footer, organizers@railsrumble.com or via #railsrumble on Freenode).

Whoah, registration numbers and your donations have definitely exceeded our expectations this year. In under 5 days we’ve received more than 150 registrations for the competition and they just keep coming. Nice work!

So instead of waitlisting a bunch of teams like we did last year, we went ahead and asked our infrastructure partners at Linode and GitHub if maybe — just maybe — they wouldn’t mind us going to 200 teams this year. And they said yes! Because they’re full of awesome. (thanks guys!)

There are still a couple days left, and about 40 of the 50 expanded team spots are still available, so keep spreading the word and let’s fill em up. Registration will still be closing end of day Sunday.

Note: This is a guest post courtesy of our friends at Thoughtbot

What if we told you that you can build a killer web application in 48 hours? Impossible? No!

Dream the impossible dream. Reach for the unreachable star.

Rails Rumble

Registration for the third annual Rails Rumble opened earlier this week. That means it’s time to start picking through your backlog of web app ideas, pick one, and recruit your team to make it happen.

Rumblestiltskin can help with that process.

For a love of meta, Rumblestiltskin was developed quickly (less than hour from concept to production prototype, another couple of hours of polish) using the same techniques we’ll be using during the Rumble.

Trends in gems & plugins usage

Last year, the Ruby Railsways blog released trend data on gems & plugins usage based on the Rumble.

We were most surprised by the lack of diversity in Rails templates (what the blog post calls “Skeleton applications”).

Rails templates

We have been using a “Rails template” for a few years (back in the ’ol Subversion days!) but on September 30, 2008, we converted it to a git repo and named it Suspenders.

We use Suspenders for all of our clients’ applications and our own products. Three teams competed last year from our office and all used a Rails template.

We highly recommend using Suspenders or another template such as Bort or Blank for your Rumble app. With only 48 hours in the competition, you want to spend as much time as possible on the actual application.

Fork away

Suspenders’ opinions include, but are not limited to:

• Test::Unit, Shoulda, Factory Girl, & Mocha for testing
• Capistrano for deployment
• Mongrel for web serving
• Hoptoad for exception notifications
• Prototype/Scriptaculuous for Javascript
• The flash, session key, & other “basic” items should be pre-configured

The full documentation is in the README_FOR_TEMPLATE.

If you like some, but not all of these opinions, fork away. For example, maybe
some of these items will come in handy for the Rumble:

• Cucumber for acceptance testing
• Faker for fake data
• Fakeweb for fake responses
• Paperclip for file uploads
• Clearance for authentication
• Gmail SMTP for email
• Google Analytics for usage analytics
• jQuery for Javascript
• Delayed Job for background processing

Remember that to stay within the rules this kind of preparation should be open source. The reward awaits…

The Championship Belt

For the third year running, we’re proud to sponsor the Rumble’s championship belt.

Registration for the 2009 Rails Rumble is now open. Go sign up to reserve a spot for your team now! As we mentioned previously, registering to compete will require a minimum donation of $5.00 per team to one of the eligible community projects we’ve selected. This year, those projects include our friends at RailsBridge, the Ruby 1.9 or Bust! project, and the Rails Rumble organizers team (hey, that’s us!)

We have 150 guaranteed spots available for competing teams and registration for those spots will remain open for contestants until the 12th of July or until they run out, whichever comes first. We may be able to open some additional spots if we need to but there are no guarantees. So yeah, don’t miss out! If you just want to participate in judging, you can register as a judge at any time from now through the end of the voting period.

There are going to be some great prizes this year, thanks to our sponsors, and we expect the quality of the applications to be higher than ever before. We’re really looking forward to it, and hope you are too.

So in case you haven’t heard, registration for the 2009 event opens next week. That means that it’s time to start talking ideas and finding teammates.

Don’t have an idea yet? How about this one: you could build a web app to organize Rumble web app ideas and help people find teammates!

Oh wait, someone already did that.

Say hello to rumblestiltskin, a small Rumble idea organizer created by Dan Croak of Thoughtbot. At the site, you can browse a list of ideas, submit your own, and find potential teammates, too. Check it out; there are already some pretty quality microapp ideas listed there.

We’re actively seeking sponsors for the 2009 competition. Sponsor money is used to purchase prizes for winners, and to offset the other costs of running the competition. This year we’ve created a tiered sponsorship system, with a limited number of sponsored spots available at each level. Supporting the Rumble is a great way to help promote entrepreneurship in the Ruby community. It also allows you to get your company brand, products, and services in front of not just the developer community but also the far larger startup enthusiast and web consumer demographics.

Make sure to check out our current roster of sponsors, including our infrastructure partners Linode and GitHub, as well as our friends at Thoughtbot (3-time sponsor of the much-loved Rumble championship belt!), Hashrocket, Intridea, RailsKits, TechStars, Spreedly, and Rails Forum.

We’ve been overwhelmed by all the support thus far and only have two spots remaining at the “heavyweight” level (but many opportunities at the middleweight and lightweight levels). Please contact Erin Shine if you’re interested in learning more about sponsorship options.