couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: (perceived) barriers to entry
Date Wed, 11 Apr 2012 12:22:20 GMT
On Tue, Apr 10, 2012 at 8:46 PM, Tim McNamara
<paperless@timmcnamara.co.nz> wrote:
> After chatting with Noah S on Twitter, I offered to jot up some
> thoughts on things that my reduce or eliminate perceived barriers to
> entry to work on CouchDB.
>
> Here are a few things that I've been able to think of. In the course
> of researching this mail though, I've actually answered many of my own
> questions.
>
> "serious business"
> A database seems like the kind of project that only extremely talented
> people would touch. People depend on the code working. Getting started
> would require quite a bit of confidence. Am I good enough?
>

@antirez of Redis fame did a really great post on data durability a
couple weeks ago. If you read and understand that you're briefed
enough to start diving into the code. Beyond those basics the advanced
details are more about learning the details of how certain types of
hardware reacts to those POSIX API's. Ie, stuff that @antirez alludes
to but doesn't cover (non-volatile write caches being a fun one).

http://antirez.com/post/redis-persistence-demystified.html


>
> "Erlang, wtf"
> This is a barrier that I've been facing for a while. I'm actually in
> the process of learning Erlang, trying to expand my horizons from
> Python. Still, a new language makes it harder to have the required
> confidence.
>

Heh, I still say "Erlang, wtf?" after using it for a few years. But I
think that's true of any language I've used for any extended period of
time. As much as I love Python it's still got its warts (outer
variables not captured by closures?).

In the end I would wager that a big part of the Erlang stumbling block
is that it's also functional and that is a stumbling block for some.
When I started with it I was like "oh, its one of those academic
things the CS people dreamed up," and didn't get into it right away.
But once you get into it you realize its not as hard as you made it
out to be.

>
> "I still don't understand rereduce"
> I'm personally not 100% clear on how queries work. This is even after
> using the db for a while. I don't want to look like a stupid idiot in
> front of great developers. Therefore, there's a high risk of offering
> suggestions and getting told to "RTFM"
>

For this I would say come ask in IRC or on the dev@ list. There are
also some older resources that still do a decent job of describing the
internals. But I would say no one expects any new comer to jump in and
tackle some of the core modules without first learning how they're
used in other places in the code.

http://horicky.blogspot.com/2008/10/couchdb-implementation.html

>
> "Where are the easy bugs?"
> [solved]
>
>
> "wow, big code base"
> Is there any documentation on how to project is laid out? Stepping
> into a new project is always a little daunting.
>

You're joking, right? :D CouchDB is something like 15K lines (although
in a weird language and not as clean as it could be) but compared to
other similar databases that's absolutely tiny.

That said, there's not much excuse for us to not have documentation on
code layout and the internal and external APIs and so forth. Hopefully
we'll be doing some work in the next few months to try and address
this issue.

>
> "Apache project?"
> As someone outside of the ASF, I don't really know what contributing
> on an Apache project means.

Don't worry about this. As you start contributing its the same as any
other open source project since the beginning of open source. Look at
the code, make a change, submit it back.

Other than that, I would say if you're interested in contributing to
pick one section of the code base and start reading and trying to
understand. Do some hacking and see if you can break it or change its
behavior in fun ways. My personal quest into the internals started at
the HTTP layer, worked into the view engine, and then finally to the
actual core. For me that was just what I found interesting at the
time. I could see another approach to start at the level of couch_file
and work outwards if that seems more approchable.

HTH and always feel free to ask questions,
Paul Davis

Mime
View raw message