Slashdot Mirror
Balancing Performance and Convention
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?"
What you call "convention vs. customization" is really just a special case of "build vs. buy". You can research the standard factors that go into such a decision, but the most important one is whether the part you intend to build is both a) essential to the business and b) something that would give you a competitive advantage over buying.
I work on a major website, all done in Ruby/Rails. We, in contrast, have found that the tremendous ability to customize the framework is liberating, rather than constrictive.
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.
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.
Where are we going and why are we in a handbasket?
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
Sunny
Be my Friend