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