Slashdot Log In
Balancing Performance and Convention
Posted by
Soulskill
on Sat Jan 03, 2009 10:48 AM
from the delaying-the-problem dept.
from the delaying-the-problem dept.
markmcb writes "My development team was recently brainstorming over finding a practical solution to the problem that's haunted anyone who's ever used a framework: convention vs. customization. We specifically use Rails, and like most frameworks, it's great for 95% of our situations, but it's creating big bottlenecks for the other 5%. Our biggest worry isn't necessarily that we don't know how to customize, but rather that we won't have the resources to maintain customized code going forward; it's quite simple to update Rails as it matures versus the alternative. What have your experiences been with this problem? Have you found any best practices to avoid digging custom holes you can't climb out of?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Switch to django and python for starters (Score:2, Informative)
I worked in a small shop that used rails, we found that rails is... constricting, just for the reasons you posted to slashdot for. We looked at our options and switched to django+python. Maintenance wasn't a problem after that. I'd suggest investigating a switch now while you have an opportunity.
Re:Switch to django and python for starters (Score:5, Insightful)
Comments like this really don't address the core issues. Frameworks, and especially heavily-developed ones like Django/Rails, are rarely cause for insurmountable performance problems. Of course, caching and setting up distributed workload processing queues will be necessary in any framework, but that's up to the development team working on a specific app rather than the framework itself.
I've been working on a large Rails application for over a year, and we haven't found any scaling issues related to Rails. Instead, there are a number of things that we've done in our application in order to help it scale for our given workload.
That said, there are a number of things that Rails will do to help you scale your application. You may want to look at how Rails 3.0 (the next release of the Rails framework) is incorporating several ideas from Merb to make the framework lighter-weight and more extensible through Rack and the concept of Rails "metals." For offline processing in a Rails app, look at plugins like workling/starling and other message queues. I think you'll find that 1) Rails doesn't have scaling issues, programmers on Rails have several challenges that they have to face to make their applications scalable (just as in any other framework) and 2) As far as providing tools to facilitate developers in scaling their apps, Rails is quite a powerful framework and one that should be given a lot of consideration by development teams.
In conclusion, though, vague comments like "avoid Rails, use Django" are just unproductive spreading of FUD and don't really contribute to any significant discussion or understanding of how to get any of the viable web application development frameworks to scale in any specific case.
Parent
Re:Switch to django and python for starters (Score:4, Insightful)
>
No problem is insurmountable. But they are commonly cause for surmountable performance problems. And surmounting costs time and money, while not impressing those who noticed the problems or pay for fixing them.
If in doubt, KISS. Adding extra abstraction layers is generally not simplification. It's like adding another layer of management in a company, in that it is sometimes necessary, but it will rarely increase productivity or responsiveness, at least not in the long term. Especially not when a middle level manager gets replaced with someone who doesn't do things the same way.
Parent
Re: (Score:3, Interesting)
Re:Switch to django and python for starters (Score:5, Insightful)
Write your extension/hack as a modification of Rails and/or Ruby. Send them back to the maintainers of said products and see if you can get them inserted as a standard part.
If they do not exact a significant penalty elsewhere for the improved performance in your pretty mundane scenario. It is highly probeble, your changes will be accepted.
This isn't just true for Rails. It's true for any software (except stuff maintained by immature, anal retentive morons.
If it's L/GPL, BSD or other common free license, then this adoption of customer written code is a routine matter. If it's closed source and proprietary they may feel the need to get a lawyer involved and have you sign over all ownership rights to the code you wrote to improve their product (ask for money or stock when that happens).
Either way, in most scenarios good clean extensions tend to get adopted as part of the main program.
PS: Yes. Even "The Evil Empire" (Microsoft, Sun, Apple, IBM etc...) have been known to do this.
Parent
Re: (Score:3, Interesting)
The best option is to not use one single framework for all situations unless it's appropriate. Too many developers put blinders on, picking one framework and using it for every project.
My company has a flexible custom framework that we use for the majority of projects. But before we start on any project we discuss the options to see if another framework or open source app would be a better fit. Along with picking the best language for a task, the same should be applied to frameworks.
No need to use Rails
Re:Switch to django and python for starters (Score:4, Interesting)
Rails has a lot of problems mixed in with a lot of greatness. For a great many projects, its greatness overcomes its probems.
Its biggest problem, IMHO, is that it does not grow well with the needs of a developer over time. Some things:
* Doesn't scale well
* Not easy to do anything outside the Rails world
I had a conversation with Ezra back when he was starting Merb, and I remember the large resistance to the idea that there were problems with Rails at all. As Merb got released and then popular, it was clear that there are holes in Rails (yes I know they are merging).
At about the same time, I started my own framework (the Caffeine framework now the Go framework) which has not been made open yet (and is not complete yet), but there are several issues that it addresses which could help (a) improve Rails or (b) create other frameworks that can fill holes. I'll mention some of the ideas below.
Note that the original goal was to use Rails for our "very cool application" (tm). Unfortunately we have some pretty lofty goals and Rails turned out to be the wrong tool. I am the CEO of a successful Internet company CityMax (about 30 employees) so I do have experience with the problems that happen after launch and success. They are not the same problems as during the startup phase.
Here are some things that an ideal framework has that I believe are missing or lacking in Rails. Again, I do want to stress that Rails has greatness and that I really respect its creator. That said, I think frameworks can grow to another level.
# Built in scalability and clustering. Should require zero changes (except some configuration) to go from single database to a cluster of databases.
# Reusable code. If you build a feature (like a message board) for one application, that same code should be reusable in another app with zero code changes. It should also be reusable multiple times in the same application. For example, a blog app might use the message board in each blog but there might also be a support message board for the whole system.
# Built in scalable file system. The file should be storable in local, Amazon S3, MogileFS, network share or whatever. Directories can be mapped to any file store (e.g. temp directories might be local, permanent storage might be S3 and archives might be a network share). Should be easy to remap directories and migrate from one data store to the other.
# No magic. Hate it. Makes it hard to figure out and debug the code.
# Custom field types for database, particularly the ability to insert files and images into a database record. The actual files and images are stored in the scalable file system and automatically managed (basically automatic garbage collection for files).
# An image field type where you can change the image sizes (e.g. thumbnail, preview, full size) at will and images are automatically regenerated in those sizes the first time they are needed. This is one of those problems that comes out as you get bigger. Say your shopping cart app stores images in 3 sizes. Now you have 10 million products and you want to add another size. Without this, you are basically stuck with the decision you made at the start.
# Make easy things easy and make hard things easy. In Rails, the solution is usually to memorize the option that allows you to do what you want. With the right design, the problems should be solvable using just Ruby and the framework. This helps keep the framework light and easy to learn over time.
# Discoverable. The framework needs to be easy to figure out on ones own. Merb was more like this. Rails was less.
# Multi-threading. This was one of the primary reasons I didn't want to use Rails originally. I understand that threading is in Rails 2 now but I'm not sure how good it is.
# CouchDB. Okay, this feature is a little cutting edge but the biggest issue after launch is migrating the database. Add a new feature that requires a new column on a table with a bajillion records and you're doing many long midnight runs
Parent
Re:Switch to django and python for starters (Score:5, Insightful)
And when the guy knowing Django moves on, what's the chance of finding a replacements who knows it? How much will that reduce the number of eligible applicants for a position -- will you disqualify fifty really smart guys for five mediocre ones who happen to know Django?
In my experience, being a system administrator for over a generation, what is the most maintainable is to go for standards and well-defined APIs, and document it, document it, document it. Especially document what's obvious and "standard practice", because it may be "standard practice" to do a certain thing in a certain language or certain package, those who come around ten years down the road may not know that this was standard, or why. So document, not so much what you're doing as why. Any coder worth his pizza will figure out what but be clueless as to why.
Parent
Re: (Score:3, Informative)
And when the guy knowing Django moves on, what's the chance of finding a replacements who knows it? How much will that reduce the number of eligible applicants for a position -- will you disqualify fifty really smart guys for five mediocre ones who happen to know Django?
Probably not. In my (admittedly limited) experience, I find that Ruby on Rails and Python/Django are similarly supported, and have similar user/developer base sizes. Frankly, if I was choosing between Rails or Django, finding developers for either would be pretty far from the top of the list of my worries.
Re: (Score:2)
> for five mediocre ones who happen to know Django?
If your smart guys are really that smart, they shouldn't have trouble with picking up any language/framework. Speaking as someone who picked up PHP/Joomla last month and now is working with it in his daily job.
Re: (Score:2)
If he and his team are experienced with Ruby, why would they switch not just frameworks, but language? Python's not especially faster, it doesn't have a particularly better threading model (in fact, once you factor in JRuby, it's much worse), and the language itself isn't going to do anything to reduce "constriction", especially if they're unfamiliar with it.
If it's Rails you find "... constricting" (whatever that means), there are at least a dozen other Ruby frameworks out there, which would be rather eas
Re:Switch to django and python for starters (Score:4, Insightful)
I worked in a small shop that used rails, we found that rails is... constricting, just for the reasons you posted to slashdot for. We looked at our options and switched to django+python. Maintenance wasn't a problem after that. I'd suggest investigating a switch now while you have an opportunity.
Out of interest, what did you find constricting about Rails? Your comment here (and the article, such as it was) are not very illuminating on this score.
I've found it fairly easy to modify, very easy to add plug-ins to, and very easy to add custom SQL queries to if necessary for performance reasons (though most of the time that's not necessary). The only area I can see it being constricting would be when trying to interface with a legacy db structure which can't be changed, in which case Django would have similar problems.
Because the article is not specific enough on the problems they'd like to work around, it asks an unanswerable question - there is no magic formula for trading off convention and performance, no magic bullet; at a certain point you have to stop relying on a framework and add something yourself if it doesn't do what you want or perform to your satisfaction. The same holds true for any framework, and though the received wisdom on Slashdot is that Rails is difficult to work with, or doesn't scale, many companies don't find that to be the case (yellow pages, etc etc).
Parent
Re: (Score:2)
Can you explain the problems associated with using Python as a language for web development?
Concentrate on the 5% (Score:2, Insightful)
The customization is what is going to keep you employed. That's the specialization that keeps the customers from going overseas - even if you're Indian yourself. There's always someone willing to do it for less. No exceptions. So, develop those resources if you want to keep doing what you're doing
Expand the toolkit (Score:5, Insightful)
Would it be out of the question to assess the needs of the troublesome 5% (and perhaps the other 10% that were shoehorned into Rails) and add a framework that's more in line with those needs?
Data exchange is sufficiently mature that interaction between applications in different environments is not an issue, so all you are left with is the added overhead of supporting two frameworks; not a bad thing if you consider the added flexibility of using the framework best suited to each application. Having options is usually a good thing.
Re:Expand the toolkit (Score:5, Insightful)
Mod up! If the only tool you have is a hammer, you end up treating everything like a nail.
As the OP pointed point, all development environments sooner or later hit this wall. I've never found one, (and am pretty sure that one will never exist), that ticks all the boxes for a typical mixed environment (the GUIs, OLTP, distributed database management, web access, making the coffee...).
In the 80s, I worked for a company that - as was fashionable at the time - developed its own '4GL' and decreed that everyone use it. In a satellite office, we tried, but found that in certain circumstances it just plain would not do what we needed. Guess what? We went back to 'hard coding' those key functions...
Don't worry about it, (after all, same bits of windows, to name just one OS, are written in assembler to speed performance).
So as the man says, expand your toolbox and your competencies - it'll make you a better project manager (to handle the interfaces) and programmer.
Parent
Re:Expand the toolkit (Score:4, Insightful)
so all you are left with is the added overhead of supporting two frameworks
And that's often much better than supporting one framework plus your own customizations. Once you customize it's often extremely difficult to upgrade the framework and have your patches still work. So there can be a lot of extra development time involved. Plus just the learning curve to get intimately familiar with the internals of the framework when that's often not necessary.
Parent
Hard to say, but... (Score:5, Informative)
Making this sort of decision really requires more technical details than you provided in the summary or the linked article.
If you do choose to make custom modifications to Rails (or any other third party dependency in your system), make them very carefully. Keep notes about what you changed, and why. Comment the modified source code with a consistent, searchable tag, like
Also, check the third party source into your own version control system so that you can track the changes explicitly.
Since you are talking about making changes for performance reasons, be sure to follow good optimization practices. Measure first, optimize only the true bottlenecks. Measure under realistic scenarios. If optimizations are even slightly confusing or subtle, comment them thoroughly. Keep the original, unoptimized code, maybe just in comments next to the new code, or maybe in a separate "reference implementation" function so that you can fall back to a known reliable version.
Version Control (Score:4, Insightful)
Use a good VersionControl system, git, murcurial or Subversion if you must, __but__ keep the meta-data out of the code. If you use sensible tools you get all that, and its much easier to work with the upstream,
Parent
Extend sanely (Score:2, Informative)
First off, I totally agree with Samschnooks that as a development team, that 5% is your responsibility, and what you're really getting paid for. But given your concerns about maintainability, and what I'm reading as your concern that custom code that you create may end up being addressed by the framework, I do have some advice.
See what of your own code can be crafted into a plugin to extend the framework. Rails plugins are quite easy to create and insanely easy to use.
Be diligent about abstracting the funct
welcome to the real world (Score:3, Insightful)
Lots of tools have the property that they make the first 95% or so of the solution really easy and the remaining 5% nearly impossible. On balance, you're worse off than if you had done the whole project in another tool.
Build vs. Buy (Score:5, Interesting)
Depends on your perspective (Score:2)
What have your experiences been with this problem? Have you found any best practices to avoid digging custom holes you can't climb out of?
What's your perspective here?
If you're looking at this from the financial point of view, I'd say that you now have enough experience to plan carefully. Also, the customer should know about and pay for maintenance.
From the manpower point of view, you might need more junior developers who can start with maintenance issues.
If you're just looking for engineering elegance, I'd say that's solved in the maintenance (tail) of the project as well. Be sure to have a senior developer keep
I agree with the above poster. (Score:5, Interesting)
Without knowing much more detail about your problem, it is difficult to give advice. Having created large, complex websites, and maintained them for long periods of time, we have yet to run into intractible problems as a result of the language or framework themselves. The fact that there are many large, complex Ruby on Rails websites being created and maintained by Fortune 500 companies also contradicts the idea that Ruby and Rails have serious, show-stopping shortcomings.
I strongly suspect that part of the problem is that you do not know your platform (in particular, Ruby) as well as you perhaps could. Ruby is very extensible via Gems that are freely available or that you can write yourself, or even just code modules. Rails is similarly, wonderfully extensible via plugins. Plugins are also freely available for just about every situation you can imagine, or again you can write your own.
Ruby is one of the most flexible languages in existence. Rails is hardly perfect, but any shortcomings are easy to code around by adding your own extensions. But expecting any framework to be complete for your purposes, before you begin, is pretty much wishful thinking.
Once again, I do not know enough about your situation. But if you expect any framework to be "plug and play" for very complex tasks, like an erector set, you will be disappointed. There is no substitute for knowledge of your platform, and programming ability.
NO, (Score:2)
We DO use it under real load, and we have no problems that have been directly traceable to either our chosen language or web framework!
On the contrary: most of our serious problems have been traceable to problems with our commercial host, EngineYard.
I feel compelled to add (Score:4, Insightful)
Most people who speak of "limitations" to their framework are people who expect the framework to do all their work for them: this is simply unrealistic. If that were how it worked, it would not be called a "framework", but rather a "product".
Parent
Re: (Score:2, Insightful)
I like that.
Equally, most people who dismiss Linux because of its perceived lack of something or other, are people who expect the computer to do their thinking for them (or at least restrict them to safe choices). If that's what operating systems were about, then we wo
Manage change, three ways (Score:2)
The general answer is to manage the change you suffer, so as to keep it from getting ahead of you.
You can do this several ways, but the best requires you be the creator of the interfaces that are to change. If you are, you can make it easy for your customers (and your own team) to change asynchronously, basically by version-numbering your interfaces. Paul Stachour has a good talk on this at multicians.org [multicians.org].
A primitive form of this is freezing your interfaces: once they're in the Application Binary Inter
Just start replacing stuff (Score:3, Informative)
My company started writing a big app in Rails. We hit limitations (for us) fairly quickly so just started replacing the bits we wanted to work differently. The great thing about Ruby is you can just switch stuff in and out. The great thing about Rails is that it's well-designed enough that you can do that fairly easily.
Sessions, for example. We wanted to share sessions between sites, so just stopped using the Rails one and started using ours. We just put a new session class system in a gem, require it, and talk to that instead of the built-in. Works brilliantly and with a little finesse you can make it totally transparent.
I think the key is to think of Rails as a framework - as in, a literal scaffolding that you place things in. The basic structure is sound enough and very useful. It's filled with some useful default code, but if that doesn't meet your needs, feel free to start replacing it wih things that do.
Agreed (Score:2)
Write Tests, Open Source, & use Rack (Score:2, Interesting)
[test!]
A good test suite == "best practice to avoid digging custom holes you can't climb out of"
I work at a Rails shop too and, when I/we need to do something highly custom, we create it as a gem (or a Rails plugin) and post it somewhere incase someone else finds it useful. None of the plugins/gems I've released have required any maintenance to speak of, unless I've wanted to add additional features.
Be sure to write tests for your customizations (gem/plugin)! This will make it really easy to discover if y
JRuby (Score:4, Informative)
Re: (Score:2)
Memory hungry, but faster than any of the other web frameworks/languages by a long shot
Re:That's rich! (Score:4, Informative)
Parent
Re: (Score:3, Interesting)
As I stated before, it may be the fastest in its class, but it still ain't fast.
What do you use when you need something better performing than Ruby? You aren't going to say "hand-tuned assembly language", are you?
I've been using Java for a long time (this may be obvious from my userid & screen name), though it's not the only language I use nowadays.
Startup is slow (though finally they have addressed this for client apps in a recent release, and it's irrelevant for stable server apps); memory consumption is still not optimal (this hasn't seen massive improvements), but performance
Contribute (Score:3, Interesting)
``Our biggest worry isn't necessarily that we don't know how to customize, but rather that we won't have the resources to maintain customized code going forward; it's quite simple to update Rails as it matures versus the alternative.''
As Alan Kay said, the best way to predict the future is to invent it. If you are worried about your useful code being broken by a future version of Rails, contribute it to Rails so that that future version will include it. Or, if you can't get it into the framework, make it available as a separate plugin.
Assuming that it's ok to share the code and that the code is useful outside your project, this will allow open source to work for you and ease your maintenance burden. If it's not ok to share the code or it isn't useful outside your project, then it's part of the project and the project will have to carry the cost.
I wouldn't (Score:2)
Maintaining custom patches for a foreign codebase is going to be painful, proportionally to the number of patches, and how badly spread out they are through the codebase.
Consider this: every time the Rails team changes things, you'll have to go through your patches and make sure they still apply correctly. And if, heavens forbid, they do some major refactoring, you'll have to spend the time figuring out what functionality got moved where, and re-apply the patches as necessary.
My project was maintaining a cu
??? Why ??? (Score:2)
Re: (Score:2)
Consider this: every time the Rails team changes things, you'll have to go through your patches and make sure they still apply correctly.
If that's a major chore for you, may I suggest investing in a test suite, so that you don't have to go through manually and test all your patches?
The problem was, however, that they released new versions frequently, and we needed them as soon as they were released.
What sort of features were they adding that made it necessary for you to upgrade so frequently? Might it have been possible for your team to not upgrade to the latest version every time?
Open Source (Score:2)
Since you are benefiting from the open source nature of ruby on rails shouldn't you simply provide your customizations back to the ruby on rails project so they can be maintained as part of the the framework or start an open source project separate from ruby on rails where the com
Re: (Score:2)
It depends on the nature of the customization. If the customization is fairly domain specific, then neither of the above two scenarios work, since there may not be enough interested people within the community to take on the burden of supporting the project.
JEE tech is too complex and fragile (Score:4, Interesting)
We are well into a project that has JBoss SEAM as its basis, but required significant mods to give us multi-database capability and a FLEX front end. So instead of a community maintained opinionated meta-framework, we now have our own super complex, fragile framework cluster(****).
It is also effectively a dense, opaque yarnball. The stack traces of exceptions are so long, due to the interceptor architecture, that the Java stack trace displaying algorithm gives up and prints ...
So my advice would be, at the risk of trolling, but I intend it as a serious debate position, don't start with something as excessively complex as JEE technology.
Because JEE technology is barely manageable, maybe, if you stick EXACTLY to the most popular opinionated meta-framework for it, but if you deviate off the straight and narrow path, you are on your own in a dense jungle with a dull machete.
Ask Slashdot (Score:5, Insightful)
Hardware is Cheap, Programmers are Expensive [slashdot.org]:
Simple (Score:2)
Just deal with the other 5% in the 'old fashioned' way; using CGI or C - doing everything from the ground up. And if somehow you can't - because you can't just get the session state from the ruby framework, or you can't get the style sheets from it, then you have to wonder why not. And blame ruby for it, not yourself or CGI.
Extend (Score:2)
Ruby is a very dynamic language, that makes it easy to extends and to customize classes. Rails itself is designed to be extended using plugins. You can write a plugin that won't define any new class, but that will just add or replace methods from Ruby, Rails or other plugins. This is really a great feature of Ruby, that avoids a lot of hassle.
Big Surprise (Score:3, Insightful)
Those you know me, know me a lot. I had the same problem five years ago. And it started to turn working for clients and revenue-generating work into working for the framework and framework-customizing work.
So I built my own framework, from the ground up.
Now it's all my conventions, and no one else's. I customize in ways that I know will be compatible for future upgrades. Of course, I get to make those upgrades myself too.
But it means that I do everything "for the last time". If it's something that seems valuable, it gets thrown into a framework-compatible routine, and I never need worry about it ever again.
A lot more work early on. A lot more work for quite a while. And then, blissful no work for anything. Seven of the nine things in the "essentials" section of my invoices -- that every client project needs just to start -- amount to 90% of the essentials dollar amount, and amount to, no kidding, the twenty seconds to install hte framework for teh new client -- and by that I mean run the script that copies files, migrates databases, and changes passcodes. From then on, approximately 75% of the work is remembering the name of the existing function -- or looking at another client project to find it; writing documentation simply hasn't made it to the top of the list in five years.
I spend about 85% of my effort dealing with client content/sales/training/trust, and only 15% on the actual programming.
Re: (Score:2)
Well, perhaps a developer has time now to make the changes, but won't have time later to maintain them?
Re: (Score:2)
Re:Language is not the answer (Score:4, Informative)
I still remain skeptical about the benefits of model-driven-development. I recall that, at the latter end of the 1980s, developers were promised much the same thing with the push toward CASE tools. Of course, developers and managers quickly learned that such tools were only of use in a certain limited number of scenarios, and that attempting to use those tools outside of the scenarios for which they had been designed quickly led to the same problems.
Frankly, I'm not sure that "software entropy" is solvable by any sort of tool or language. Rather, it is solved by training developers to write tests, and enforcing certain minimum style standards on the code, so that any developer can look at any portion of the codebase without feeling too unfamiliar with it.
Parent
Re: (Score:2)