You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Karel Minařík <ka...@gmail.com> on 2010/08/01 21:51:33 UTC

What's wrong with Ruby libraries for CouchDB?

Hi all,

during the last year, I have been working on and off on couple of Ruby  
contracts/projects using CouchDB as the primary database.

Encountering Couch was probably the _most_ joyful experience in the  
"developer" part of my life, during that year, *period*.

_Working_ with Couch in Ruby/Rails apps was _highly frustrating_  
experience during that time.

I have summarized some of the issues I had/have in the following gist:

--> http://gist.github.com/503660

The points include "too many gems", "too many layers", "lack of  
modularization" and "talking to the rest of Ruby world". I've put them  
in the gist and not on this list mainly because I don't know if all  
people interested are subscribed to this list. I welcome any feedback  
here, but _rather_ in comments to the gist.

One thing I'd propose is some virtual (or real) get together of  
authors of various Ruby gems for Couch to consider if there's not some  
common ground, and if the features of different libraries could not be  
catered in a radically smaller number of gems.

Regarding the (natural) "one size does not fit all" argument: the  
situation reminds of the state of i18n in Ruby on Rails two years ago.  
There were number of options for providing the functionality, because  
"everybody has different needs". This has put a really _big_ strain on  
developers, forcing them to research and evaluate all the options and  
make the choices. In the end, thanks to coordinated effort, common  
ground was found and a modular, but "out of the box" usable solution  
was created: http://github.com/svenfuchs/i18n.

I think adoption rate, and more importantly _joy_, of using Couch in  
Ruby would benefit from something similar.

Best,

Karel

--
www.karmi.cz


Re: What's wrong with Ruby libraries for CouchDB?

Posted by Mikeal Rogers <mi...@gmail.com>.
Here is the blog post I did.

http://www.mikealrogers.com/2010/08/abstracting-couchdb/

On Sun, Aug 1, 2010 at 2:32 PM, Mikeal Rogers <mi...@gmail.com>wrote:

> I'll try to respond to each of these in a new blog post because a lot of
> what you say isn't specific to Ruby.
>
> Some of the underlying reasons for your complaints, which I think are
> valid, are actually due to some of the better parts of CouchDB being too
> easy :)
>
> -Mikeal
>
>
> On Sun, Aug 1, 2010 at 12:51 PM, Karel Minařík <ka...@gmail.com>wrote:
>
>> Hi all,
>>
>> during the last year, I have been working on and off on couple of Ruby
>> contracts/projects using CouchDB as the primary database.
>>
>> Encountering Couch was probably the _most_ joyful experience in the
>> "developer" part of my life, during that year, *period*.
>>
>> _Working_ with Couch in Ruby/Rails apps was _highly frustrating_
>> experience during that time.
>>
>> I have summarized some of the issues I had/have in the following gist:
>>
>> --> http://gist.github.com/503660
>>
>> The points include "too many gems", "too many layers", "lack of
>> modularization" and "talking to the rest of Ruby world". I've put them in
>> the gist and not on this list mainly because I don't know if all people
>> interested are subscribed to this list. I welcome any feedback here, but
>> _rather_ in comments to the gist.
>>
>> One thing I'd propose is some virtual (or real) get together of authors of
>> various Ruby gems for Couch to consider if there's not some common ground,
>> and if the features of different libraries could not be catered in a
>> radically smaller number of gems.
>>
>> Regarding the (natural) "one size does not fit all" argument: the
>> situation reminds of the state of i18n in Ruby on Rails two years ago. There
>> were number of options for providing the functionality, because "everybody
>> has different needs". This has put a really _big_ strain on developers,
>> forcing them to research and evaluate all the options and make the choices.
>> In the end, thanks to coordinated effort, common ground was found and a
>> modular, but "out of the box" usable solution was created:
>> http://github.com/svenfuchs/i18n.
>>
>> I think adoption rate, and more importantly _joy_, of using Couch in Ruby
>> would benefit from something similar.
>>
>> Best,
>>
>> Karel
>>
>> --
>> www.karmi.cz
>>
>>
>

Re: What's wrong with Ruby libraries for CouchDB?

Posted by Mikeal Rogers <mi...@gmail.com>.
I'll try to respond to each of these in a new blog post because a lot of
what you say isn't specific to Ruby.

Some of the underlying reasons for your complaints, which I think are valid,
are actually due to some of the better parts of CouchDB being too easy :)

-Mikeal

On Sun, Aug 1, 2010 at 12:51 PM, Karel Minařík <ka...@gmail.com>wrote:

> Hi all,
>
> during the last year, I have been working on and off on couple of Ruby
> contracts/projects using CouchDB as the primary database.
>
> Encountering Couch was probably the _most_ joyful experience in the
> "developer" part of my life, during that year, *period*.
>
> _Working_ with Couch in Ruby/Rails apps was _highly frustrating_ experience
> during that time.
>
> I have summarized some of the issues I had/have in the following gist:
>
> --> http://gist.github.com/503660
>
> The points include "too many gems", "too many layers", "lack of
> modularization" and "talking to the rest of Ruby world". I've put them in
> the gist and not on this list mainly because I don't know if all people
> interested are subscribed to this list. I welcome any feedback here, but
> _rather_ in comments to the gist.
>
> One thing I'd propose is some virtual (or real) get together of authors of
> various Ruby gems for Couch to consider if there's not some common ground,
> and if the features of different libraries could not be catered in a
> radically smaller number of gems.
>
> Regarding the (natural) "one size does not fit all" argument: the situation
> reminds of the state of i18n in Ruby on Rails two years ago. There were
> number of options for providing the functionality, because "everybody has
> different needs". This has put a really _big_ strain on developers, forcing
> them to research and evaluate all the options and make the choices. In the
> end, thanks to coordinated effort, common ground was found and a modular,
> but "out of the box" usable solution was created:
> http://github.com/svenfuchs/i18n.
>
> I think adoption rate, and more importantly _joy_, of using Couch in Ruby
> would benefit from something similar.
>
> Best,
>
> Karel
>
> --
> www.karmi.cz
>
>