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.