Ripple Hackathon - Day 1
by Sean Cribbs
So you may have heard about this event going on around Ripple this week. Basically, we have committers and interested parties gathering in the offices of Basho’s SF office to hack on Ripple and move it toward 1.0. Today was the first day of the hackathon/sprint/thing. Here’s a quick rundown on what happened:
Planning & Priorities
Because our committers are volunteers and are taking time out of their regular work to be here and to contribute, I wanted to make it worth their while – to let them work on what would make the most impact for them. So we started with a discussion that consumed most of the morning, dropping our personal priorities into either the “Gripes” (actual problems encountered) or “Wants” (desired features that would make things easier) columns. Mark took a picture of this discussion in-progress:
Some of these were things that can be directly addressed by the library, some will need to be done in Riak itself. The list, roughly as it went up on the board, is below:
- Count things (e.g. keys in bucket)
- Indexes (Risky does this)
- Separate Repos for subprojects
- Migrations framework
- Rake tasks - db:*
- Riak as a gem (node generation, install)
- “Many” should be “few” (too many links)
- Principle of Least Surprise
- double-storage (backlinks)
- Assigning inverses
- list-keys (list a small bucket should not be expensive)
- key-filters suck too
- Connection resiliency
- PBC problems
- multiple hosts
- embedded docs by key
- module scope for class names
- SBI is problematic
- JSON problems
- Test Server
We all then took some things that we wanted to work on and sat down to work on them. I also fielded a lot of questions about certain aspects of the things others were working on.
Wrap-up & Demos
One thing I wanted to do with each day was to prevent it from fizzling out, so we all discussed one thing we had accomplished (or decided on) and talked about it or showed off code.
- Nathaniel and Duff worked on a new kind of association for documents where the key of the other document(s) is stored in the body rather than with links (in a header). This starts to address the first bullet point under the “Gripes” above (aka issue #136) has a neat related feature - the “many” side can look up related objects using Riak Search. Their work-in-progress is on the “stored_key” branch.
- Myron worked tirelessly with the guys from travis-ci to get a continuous integration server running. This involved getting Riak 0.14.2 installed on their worker boxes and then figuring out the idiosyncracies of why our tests fail! All in all, an awesome effort that is already bearing fruit.
Kyle discussed lots of strategies for both teasing out HTTP response validation logic from the individual client library adapters, as well has how to do request retries efficiently. The syntax we’re going to go with will be a simple block that wraps the lower-level request invocation so we implement the retry logic separately. This should land early tomorrown now that we have a solid plan.
Kyle also created an interesting conflict resolution DSL for Risky which encapsulates various resolution strategies at a fine granularity (at the property level, actually). We discussed borrowing that syntax to build on Myron’s existing conflict-resolution code.
It was a very exhilirating day (if a bit distracted at times), and I trust tomorrow will be really productive as well.
Come on by
As the original announcement mentions, if you’re in the San Francisco Bay area and want to talk about Ripple, Riak, or contribute to the library, feel free to drop by the Basho office (929 Market, Suite 500) anytime during business hours tomorrow or Wednesday. We also have formal “Riak Office Hours” on Wednesday too, if your questions are more general.