On Thu, Sep 07, 2006 at 01:54:44AM +0900, Richard Conroy wrote:
> 
> 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.

Mostly, they require higher quality APIs.  Everything else can be
changed.


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

Good point(s).


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

I'm not terribly sympathetic to unreasonable fears, I'm afraid.  I am,
however, sympathetic to people who have to labor under conditions of
unreasonable fear engendered by the ignorance of supervisors, which is
almost the same thing.


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

I'll take your word for it.  I'm not active in the Java community, and
would probably be stoned as a heretic if I was (nouns bore me, and an
entire language devoted to writing in passive voice never struck me as a
very good idea).


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

MySpace doesn't even scale to MySpace levels.  It's written in CFML, for
crying out loud.


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

Maybe that's the problem.  All I know for sure is that I've never run
across a situation where my first thought was "Y'know, I could solve
this by writing an app that leverages SNMP."


> 
> 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 curious about how that goes, whether you end up using Rails or not.


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

There is a startlingly high number of web developers out there who do
the sort of consulting work that does not guarantee direct access to
production servers, unfortunately.


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

When a Rails app deployment process consists of unceremoniously dumping
a bunch of files into a directory across an SFTP connection, then it
will be ready for prime time in the indirect-access market.  Until then,
it's still pretty much all Perl and PHP.  That's how it looks to me, at
any rate.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."