Ripple Hackathon - Day 1

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:

Wants

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)

Instrumentation

Gripes

“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

retries

PBC problems

multiple hosts

Associations

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.