Skip to content

Instantly share code, notes, and snippets.

@clr
Created October 17, 2012 22:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save clr/3908781 to your computer and use it in GitHub Desktop.
Save clr/3908781 to your computer and use it in GitHub Desktop.
Dmitri's blog post

Rails Rumble with Riak and Ripple - Three Developers and a Lot of Rs

This past weekend, Bryce Kerley, David Andersen, and I had the pleasure and honor of participating in Rails Rumble 2012. This event is a 48-hour competition to design, build and deploy a web application in Ruby and Rails (or one of the other Rack-based web framework). Developing at this pace is grueling, to say the least (especially since it took place immediately after we all flew home from Ricon 2012), but also really exciting. You get the whole product cycle experience, from design to feature releases to testing and QA, all in one intense weekend.

Our application is Brainload. It's a social flashcard/memorization aid tool, which lets users create, share and review flash cards on various topics (useful for memorizing programming language syntax, new APIs, school exam preparations, and building foreign language vocabulary). You can launch the site, try it out, and vote for it if you are so inclined.

One of the design constraints that we undertook this weekend, was to build this web app using only Riak as a back end -- no traditional relational database involved. Specifically, we chose the Ripple object modeling library, which provides a Riak persistence layer for Rails models, as well as familiar ActiveModel type querying capabilities. This provided several advantages and challenges, in terms of agile web development in the accelerated timeframe of the Rumble challenge. On the plus side, since Ripple essentially treats Riak as a document store, there was no database schema management and no migrations -- very helpful for rapid exploratory development. Ripple model relationships (powered by LevelDB-backed secondary index queries) provided the usual one to one and one to many capabilities required for web apps like this (users, decks, cards, categories and so on). On the challenge side, we couldn't use some of the minor Rails features that are closely tied to ActiveRecord -- for example, fixtures were not automatically loaded during rake testing tasks (the solution in that particular case was to explicitly load the needed YAML files, or to use a standalone test data generation package like Factory Girl). Fortunately, we had Bryce on our side, who was old hand at coding Rails with Ripple, to advise us and walk us through the finer points of Ripple-specific syntax.

Despite our best efforts, a last-hour commit did manage to introduce a bug (I think we were a bit ambitious with the social features we wanted to add right up to the last minute). If you try to add a card -- ouch! -- you get an error message. While it is frustrating that we can't fix this bug while the judging continues, this is part of what makes the competition so exciting. Of course, now that the contest is over, we started talking about future plans for our web app, bugfixes and features and all.

I cannot emphasize enough what a fantastic learning experience this was. Both in terms of working with really talented developers on my team (who also turned out to have pretty amazing sysadmin and design chops), and also for getting unique hands-on insight into the benefits and rough spots of working with our own database client and object modeling libraries.

If you get the chance to next year, I highly recommend participating in the Rails Rumble (and meanwhile, looking through and voting for the other entries in the competition). It was exhilarating and educational, and I am especially proud of Basho for being a sponsor of this competition.

@tylerhannan
Copy link

My thoughts are as follows:

Paragraph 1

  • We should link names to twitter accounts (or github based on preference)
  • Let's link Ricon2012 to the site

Paragraph 3

  • We should link Riak to somewhere (docs portal perhaps?)
  • I tend to prefer the terms "one-to-one and one-to-many" vs. spelling them out individually

Paragraph 4

  • Change the bugfixes line at end of paragraph to something like "future plans for our web app -- bugfixes, features, and all" It is awkward as is

Paragraph 5

  • I didn't realize Basho was a sponsor until the last paragraph. I don't want to be super promotional but we could maybe throw that in the top paragraph...ala - Rails Rumble (proudly sponsored by Basho).

@dmitrizagidulin
Copy link

Thanks, Tyler!
I made the suggested edits on my fork: https://gist.github.com/3909785/1dee0539fdb164d403bdc5f9180d47ec8d0dcd19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment