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
>
>