Follow-up on: What's up dev?

[st...@shimaore.net]

Hi,

I'm writing as an contributor on the wiki, CouchDB advocate, and
user.

I wanted to follow-up on the initial question about project energy,
and Noah's response, first to say that I'd be glad to help with things
such as documentation, use examples, etc.

Noah asked about "areas [people] give a shit about", so here's what I care
about (if there are any trolls just have mercy and ignore them, thanks):

- As a user (that is, a developer who uses CouchDB as a back-end
  database and front-end in some cases), CouchDB is:
    1. an API;
    2. the API is what Futon tests;
    3. as long as things are "fast-enough" I'm happy.

  Most other things I can work around by writing code.
  (For example: the replicator is muchly useful but not core --
  replicate[1] might be a viable option --; and even though it is a very
  good idea, I never used the _replicator database because I had coded
  for that before it was there.)

  I really don't care whether I use Apache CouchDB, or something
  written in Erlang, or anything else -- as long as it conforms to the API.
  ... I use Apache CouchDB because I want the reference API.

  For couchapps I rely on a modified node.couchapps.js & Sammy.js but
  that's my playground, not the server's.

  The API must be clearly documented, backward-compatible.
  I'd like to see more index types (GeoCouch, longest-match) integrated.

  I depend enough on the technology that I'd start my own version of the
  server if things went really bad.

- As a system administrator I want to be able to deploy private,
  distributed CouchDB simply and reliably. I want to distribute it over
  multiple physical locations, multiple clouds if I can.

  As a sysadmin I understand there are a lot of moving pieces, and the
  most visible ones (view server) aren't necessarily in Erlang.

  I care enough about the stability of my CouchDB installations to
  package my own builds.

  OTP has little practical impact because package managers just do "stop"
  and "start" on upgrades.

  ... I use Apache CouchDB because there's little momentum behind
  BigCouch, and I believed it was going to be integrated anyway.

- As an advocate I had to learn to answer "isn't it dead?" questions.
  On the other hand I have fun when people mention binary protocols.
  But overall I'm advocating for a technology, not a given
  implementation. (And I'd love to have fellow developers prove me wrong,
  obviously.)

S.

[1] https://github.com/mikeal/replicate

Re: Follow-up on: What's up dev?

[Noah Slater <ns...@tumbolia.org>]

Thanks for the feedback! Useful stuff. I'll let other people reply to
specific points if they want to.

On Mon, Sep 24, 2012 at 2:46 PM, <st...@shimaore.net> wrote:

> Hi,
>
> I'm writing as an contributor on the wiki, CouchDB advocate, and
> user.
>
> I wanted to follow-up on the initial question about project energy,
> and Noah's response, first to say that I'd be glad to help with things
> such as documentation, use examples, etc.
>
> Noah asked about "areas [people] give a shit about", so here's what I care
> about (if there are any trolls just have mercy and ignore them, thanks):
>
> - As a user (that is, a developer who uses CouchDB as a back-end
>   database and front-end in some cases), CouchDB is:
>     1. an API;
>     2. the API is what Futon tests;
>     3. as long as things are "fast-enough" I'm happy.
>
>   Most other things I can work around by writing code.
>   (For example: the replicator is muchly useful but not core --
>   replicate[1] might be a viable option --; and even though it is a very
>   good idea, I never used the _replicator database because I had coded
>   for that before it was there.)
>
>   I really don't care whether I use Apache CouchDB, or something
>   written in Erlang, or anything else -- as long as it conforms to the API.
>   ... I use Apache CouchDB because I want the reference API.
>
>   For couchapps I rely on a modified node.couchapps.js & Sammy.js but
>   that's my playground, not the server's.
>
>   The API must be clearly documented, backward-compatible.
>   I'd like to see more index types (GeoCouch, longest-match) integrated.
>
>   I depend enough on the technology that I'd start my own version of the
>   server if things went really bad.
>
> - As a system administrator I want to be able to deploy private,
>   distributed CouchDB simply and reliably. I want to distribute it over
>   multiple physical locations, multiple clouds if I can.
>
>   As a sysadmin I understand there are a lot of moving pieces, and the
>   most visible ones (view server) aren't necessarily in Erlang.
>
>   I care enough about the stability of my CouchDB installations to
>   package my own builds.
>
>   OTP has little practical impact because package managers just do "stop"
>   and "start" on upgrades.
>
>   ... I use Apache CouchDB because there's little momentum behind
>   BigCouch, and I believed it was going to be integrated anyway.
>
> - As an advocate I had to learn to answer "isn't it dead?" questions.
>   On the other hand I have fun when people mention binary protocols.
>   But overall I'm advocating for a technology, not a given
>   implementation. (And I'd love to have fellow developers prove me wrong,
>   obviously.)
>
> S.
>
> [1] https://github.com/mikeal/replicate
>



-- 
NS