

Dawn of kitchen sink libraries in Ruby - gnufied
http://codemancers.com/blogs/2012/05/dawn-of-the-kitchen-sink.html

======
websymphony
_Now at its core, handling file uploads is very simple and straightforward
affair_

I understand the concerns the author is raising and having a single
responsibility for a library is definitely ideal. But as far as I have
experienced, file uploads are never as trivial as author is pointing them out
to be.

Most of the times you need some kind of post processing for the files,
sometimes you need multiple file uploads, sometimes you want to do it
asynchronously. It just never ends up trivial.

~~~
gnufied
Thats true, but often times a complicated library that makes these choices for
you gets in your way, rather than helping the case.

~~~
telent
Which is exactly why I'd rather use a library that _doesn't_ make the choice
of Rails and ActiveRecord for me.

~~~
gnufied
Well, I tend to take a pragmatic approach about this. The question is, how
much you want to deviate from convention of underlying framework when
developing? 90% of Web applications out there, can reliably stick to rails
conventions and they will be well served by it. But from my personal
experience - handling file uploads, processing them is often very different
from app to app. What we need is composaple modules not a single monolithic
library that does everything and there lies my gripe.

------
parley
While I haven't been doing much Ruby for a while, I agree somewhat with the
article. Personally, I think it boils down to composability. Building simple,
modular functionality with clearly defined borders _should_ enable both a
larger library composing these modules together and offering a unified
interface towards them _as well as_ a developer hand-picking and using these
modules by hand as he/she needs them. The Prismatic blog published a good post
recently where the problem with libraries vs frameworks was highlighted, and I
agree with that post. I'm not saying it's easy, and it's certainly easier in
some languages than others, but most of us could probably agree that it's the
way we would like it to be done, no?

~~~
iffyuva
Talking about 'libraries vs frameworks', tenderlove spoke about frameworks
providing bare-metal interfaces for libraries and let libraries implement
those interfaces in whichever way they want. but its still not sure to what
extent that would solve the problem. Recently, bare-metal queue implementation
in Rails
[https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053...](https://github.com/rails/rails/commit/adff4a706a5d7ad18ef05303461e1a0d848bd662)
has been discussed 'for and against' extensively.

~~~
parley
I'm not quite sure I understand. Speaking of the generic case, the (quite
broad, I admit) statement that modular and composable functionality should
enable both the unified-libraries-approach (or frameworks) and pick-and-
choose-approach should (when applied) solve the OPs problem of not wanting to
use what he/she doesn't need, shouldn't it?

I support the idea of a framework essentially being a light-weight layer on
top of libraries, but if the framework just uses a single monolithic library
then little (but something!) is gained. If it uses one or more libraries that
are all properly composed of smaller modules, etc, etc, then a lot of
flexibility is gained.

I'm not very familiar with Rails - especially its internals - so it's hard to
comment on this particular case. However, making job queueing modular seems to
have found the approval of most people in the commit comment thread you
linked.

But I agree that the distinction is never clear cut, and everything needs a
discussion on a case-by-case basis...

------
govi
I personally liked the days where the libs did one thing best. Probably that
was why even the gem management was supported from a very long time in the
past.

------
netpenthe
in relation to rails, i feel like it's tending towards perl.

gems are becoming cpan...

