On 9/5/06, Chad Perrin <perrin / apotheon.com> wrote:
> > or write your own equivalents (which will wipe
> > out your rails productivity boost).
>
> . . . once.
>
> Imagine you have choice A and choice B.  With choice B, you have all the
> libraries already.  With choice A, you're missing some.  On the other
> hand, with choice A you have a productivity boost that provides extra
> time roughly equivalent to the time it takes to write the libraries that
> are missing.

Time saved is not the only thing that libraries provide. For instance, you
may simply not have the expertise or business mentality for library
development. e.g. Marketing, management and other project stakeholders
cannot determine if a library is 'good' or 'done' or whatever - a library is
a software product whose customers are developers. Libraries generally
require higher quality than the products that use them too.

I know for instance that I would smack anyone at work who suggested
we write a(nother) security library. I have been in companies where
our library choice was something that was discussed in sales pitches.
If you use something sensitive like a credit card payment processing
engine, customers might be sensitive to what libraries you use to access
it (the vendors, an established third party etc.).

There are also many companies where library authoring may be a complete
anathema. They don't know how to fit it in with their business processes
(like testing) or how the life expectancy and support of a library outlasts its
first application, and how it gets support. There may also be significant
developer fear about having to author and effectively support something
like that.

Also consider this: the Ruby/Rails environment has probably more active
library development per capita (of developers) than established languages.

I know in Java,
the quality of the basic libraries is excellent, and it is worth checking out
virtually anything that the jakarta crew work on, as they are especially
good. But ironically, this means that library development skills for your
average java programmer have severely atrophied through lack of use, and
if they then have to write equivalents in Ruby.... that ramps up your risk
completely. I know for a fact that when I am presented with an in-house
java library my first reaction is 'aw crap'. I have been pleasantly surprised
on occasion, and I work with good people now, but there is something
about Java that attracts the worst kind of well-intentioned designer - the
kind that starts developing meta-solutions instead of addressing the
given problem.

> It strikes me as a bad idea in general to pursue edge cases in
> frameworks.

Well I wasn't distinguishing between Ruby or Rails here. I wasn't
requesting that Rails accomodate edge
conditions - the correct approach to edge conditions in Rails, is
to down shift to Plain Old Ruby. This is pretty obvious with its
'helper' hook, and is well stated in the good literature, and 'Recipes'
in general are implemented this way.

However, my point was that using Ruby *IN* Rails in this manner
could kill your scaling. Its another one of those rock-and-hard-place
situations - the implication is that only 'sweet spot' Rails apps
can truly scale. Whether Rails scales up to MySpace levels is
another thing, and whether you need twice or ten times as many
machines is another. But *I* don't particularly care about those cases.

I do care about single machine performance though.

> SNMP, I realize, is not an uncommon case, but it's uncommon enough for
> web app development that expecting a web development framework to do the
> heavy lifting for you is a somewhat odd demand, I think.

I try to avoid the thing as much as I can, doctor's instructions. Its a fine
protocol for what it was intended for, but the only uses of it I ever see
are when people build insane application protocols over it.

I doubt if I am the first person to think about using Rails easy machine
parallelism to split up the workload involved when a couple of thousand
SNMP agents start screaming at you all at once.

This problem alone is what will dictate the shape of our new app. It is
not a solution we have ever solved properly before.

I would get a perverse satisfaction from using 'risky/slow rails' to solve
our most persistent scaling problem. An ActionSNMP plugin would be
quite cool indeed.

> I'm entirely with you on this: web application framework advocates, for
> any framework in any language, seem to believe that the developer will
> always be the one deploying and that deployment will be accomplished at
> a server where the developer has complete access and control.  There
> isn't nearly enough attention on the problem of removing control
> characteristics and direct access capabilities, or even passing on
> deployment to someone else entirely who wasn't part of the original
> picture at all.

Well Rails is new, and a moving target. The audience for Rails solutions
is web developers, and its original core audience was probably the
Perl, PHP, ASP community (I am guessing) who had direct access to
production servers.

The success attracts other kinds of web developers with indirect server
access. I don't expect the Rails binary distribution problem to stay
unsolved for long. Instant Rails is an early step in that direction, and
I don't think the problem is particularly hard anyway - you just bundle
your gems and binary dependencies together. Once you are dealing
with say, using existing MySQL databases you are automatically
dealing with a knowledgeable customer, and you can invisibly install
something like sqlite for the technofearful.

Rails is also attracting attention from weirdos like me who are seeing
what else we can do with it, and who see the lack of convenient
source deployment methods a problem. Also the lack of an established
build process is a bit step backward. As we have gotten very used to
100% non-manual build processes that do lots of non-build activities
too (like source analysis, unit tests, product watermarking). Not all
steps are applicable to Rails, but Rails does add some (deploy to
test server & test) but the principle remains the same.