Forgot your password?
typodupeerror
Programming IT Technology

Balancing Performance and Convention 171

Posted by Soulskill
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?"
This discussion has been archived. No new comments can be posted.

Balancing Performance and Convention

Comments Filter:
  • 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.

    • by latentevent (1444209) on Saturday January 03, 2009 @12:35PM (#26312079)

      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.

      • by arth1 (260657) on Saturday January 03, 2009 @01:42PM (#26312503) Homepage Journal

        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.

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

      • Couple of points:

        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.

        True -- but Rails does make caching easy.

        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

        It's more than that -- Rails 3.0 is also Merb 2.0. So, Rails 3.0 should gain all of the advantages of Merb -- one of which is raw performance [slideshare.net].

        For offline processing in a Rails app, look at plugins like workling/starling and other message queues.

        For what it's worth, Merb has a simple threaded backgrounder built in.

      • Re: (Score:3, Interesting)

        by CodeBuster (516420)
        The parent was not so much saying, "avoid Rails, use Django", but rather was explaining that for about 5% of his necessary requirements, customization of Rails was too complex or expensive when compared to the alternatives. I am myself a web developer and our whole business is really about trade-offs and costs. I have not used Rails personally, but from what I understand, in Ruby on Rails those who go "off the reservation" are "punished" with "ugly code" and complex maintenance for not adhering to the core
    • by Forge (2456) <kevinforgeNO@SPAMgmail.com> on Saturday January 03, 2009 @12:42PM (#26312115) Homepage Journal
      After reading the linked commentary, I can say there really is a better 4th option. It was even hinted at by the author.

      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.
      • Re: (Score:3, Interesting)

        by truthsearch (249536)

        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

      • by shirai (42309) on Saturday January 03, 2009 @06:26PM (#26314681) Homepage

        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

        • by terjeber (856226)

          Some comments to your ideas... I like a lot of what you say and I strongly disagree with some of them.

          zero changes ... to go from single database to a cluster of databases

          Perhaps, or perhaps this isn't something that belongs in the application-server domain at all, but in the database driver domain. In other words, if you need a cluster of DBs, use a DB product that supports this seamlessly. I am not going to mention Oracle by name, but it would support what you are asking here I assume, depending on how the Rails/Oracle guys wrote the Ora driver for Rails. Never tried Rails

          • by shirai (42309)

            Before I respond, I just want to reiterate the I like Rails and that I really respect its creator; that said, a framework is just a tool and as such it can and should be improved and also that there are other ideas that are different (and sometimes even more radical) that work too.

            zero changes ... to go from single database to a cluster of databases

            Perhaps, or perhaps this isn't something that belongs in the application-server domain at all, but in the database driver domain. In other words, if you need a cluster of DBs, use a DB product that supports this seamlessly. I am not going to mention Oracle by name, but it would support what you are asking here I assume, depending on how the Rails/Oracle guys wrote the Ora driver for Rails. Never tried Rails with Oracle, but for all apps I have written lately, this is taken care of by the Ora driver.

            I agree that clustering would be better solved in the database but I also wish my apps would just write themselves. Neither is realistic or true. The fact is, clustering right now (at least in open source) must be in the applicati

            • by terjeber (856226)

              I agree that clustering would be better solved in the database ... The number of Rails apps using Oracle as a backend are approaching 0%

              That would imply that all Rails developers are idiots. If Oracle is the only DB where the DB supports clustering properly and someone needs clustering, he should use Oracle or he should find another business to work in since you are an idiot. You select the correct tool for the job.

              Also, given that Oracle is, by a significant margin, the chosen database for critical enterprise stuff, if your 0% assertion is true, then Rails isn't used anywhere for important stuff.

              It isn't easy to convert a large software project, constantly in flux, to support clustering

              If clustering is supported by the DB, yes it

              • by shirai (42309)

                That would imply that all Rails developers are idiots. If Oracle is the only DB where the DB supports clustering properly and someone needs clustering, he should use Oracle or he should find another business to work in since you are an idiot. You select the correct tool for the job.

                Also, given that Oracle is, by a significant margin, the chosen database for critical enterprise stuff, if your 0% assertion is true, then Rails isn't used anywhere for important stuff.

                That's a false dichotomy. Many Rails developers are really smart but they won't use Oracle for other reasons. The major roadblock with Oracle is not that it's the wrong tool, it's that it is not free (neither as in beer nor speech).

                It isn't easy to convert a large software project, constantly in flux, to support clustering

                If clustering is supported by the DB, yes it is. That is why it belongs in the DB realm.

                I don't think we're disagreeing on this point. Your hypothesis is that if you have clustering in a db, then it is easy. I'm simply stating the fact that nobody uses dbs that support clustering with Ruby (MySQL supports clustering but it is an in-memory database). If clustering wa

                • by terjeber (856226)

                  That's a false dichotomy. Many Rails developers are really smart but they won't use Oracle for other reasons. The major roadblock with Oracle is not that it's the wrong tool, it's that it is not free (neither as in beer nor speech).

                  How is it a false dichotomy? Oracle is, by a rather significant margin, the chosen database in the enterprise world. This is where the money is generated. If Rails is not used in conjunction with enterprise database solutions, Rails isn't used for important stuff. And no, Wikipedia is not "important".

                  I'm simply stating the fact that nobody uses dbs that support clustering with Ruby

                  Again, this is a rather odd statement. Where do you get this information from? Are you seriously saying that nobody is using Rails on Oracle?

                  What I'm really advocating is that all the same problems that people encounter simply be standardized. This is just like how ActiveRecord standardized database access.

                  And I am pointing out that you don't do that by adding rubbish and ir

    • by arth1 (260657) on Saturday January 03, 2009 @01:29PM (#26312423) Homepage Journal

      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.

      • Re: (Score:3, Informative)

        by quanticle (843097)

        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.

      • > will you disqualify fifty really smart guys
        > 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.
    • by Fweeky (41046)

      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

    • by Serious Callers Only (1022605) on Saturday January 03, 2009 @02:08PM (#26312675)

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

    • Everything your code does is something the framework doesn't do for you: the real problem is not customization, but how cleanly the framework allows you to extend it, how stable the interface (between the framework core and your extensions) is, and so on.

      That's why I'm surprised to hear people recommend switching from Rails to Django. My experience in going through that route is that Django is less flexible and harder to customize than Rails. For example, in both frameworks you can write custom SQL querie
  • You see, the other 95% (Convention as you put it.) you're talking about can be done by anyone: that's one of the reasons frameworks exist. In other words, it can be shipped to the lowest cost country in the World.

    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

    • So now we have one guy [slashdot.org] who says employees should use the obscure methods because it will keep the company more dependent on the employees while we have another guy [slashdot.org] who says managers should avoid the obscure parts because it makes them too dependent on the employees...
  • Expand the toolkit (Score:5, Insightful)

    by thethibs (882667) on Saturday January 03, 2009 @12:10PM (#26311917) Homepage

    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.

    • by Bearhouse (1034238) on Saturday January 03, 2009 @12:27PM (#26312031)

      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.

    • by truthsearch (249536) on Saturday January 03, 2009 @02:29PM (#26312851) Homepage Journal

      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.

  • Hard to say, but... (Score:5, Informative)

    by SlashDotDotDot (1356809) on Saturday January 03, 2009 @12:15PM (#26311957) Journal

    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

    // MYCOMPANY Begin custom changes
    // Optimized this block for queries where the
    // search string is only one word long, and
    // measured a 20% performance increase on the
    // production server under moderate load.
    // 3-Jan-2009
    ...
    // MYCOMPANY End custom changes

    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)

      by omb (759389) on Saturday January 03, 2009 @02:45PM (#26313003)
      I hate code full of company comment cruft.

      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,
      • by Bazzargh (39195)

        Agree 100% with the parent. You should be using version control. In fact, its such a common issue that there's even a term for what the original poster is asking about:

        VENDOR BRANCHES

        Go google that now. You can find more information for your system here...

        * In (a) CVS book [red-bean.com]
        * In the SVN book [red-bean.com]
        * One method of doing this in bzr [ubuntu.com]

        With git or mercurial, patch queue solutions are probably what you want - stgit or the newer TopGit for git, Mercurial Queues for mercurial. You want to use patch queues so that you have a

    • Re: (Score:2, Interesting)

      by chachacha (833677)
      Keeping commented out code around is not only distracting to developers but harmful. Code in comments isn't syntax checked, isn't compiled, and isn't tested and therefor quickly begins to suffer from bit rot. It would be better to refactor the surrounding code to work with different plugin-able implementations and to fully support both the "old" and the "new and improved" implementation if the intent is to be able to reliably revert that part of the system to a different implementation.
  • Extend sanely (Score:2, Informative)

    by Bantik (89939)

    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

  • by speedtux (1307149) on Saturday January 03, 2009 @12:37PM (#26312087)

    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.

    • by b4dc0d3r (1268512)

      I remember using MFC, and finding very common problems had no MFC equivalent. I had to either call Win32 directly (which is fine for uncommon problems), or futz about updating poorly documented auto-generated code that I didn't understand well enough to be in there making changes. This is because MFC project team just couldn't predict what would be common, and it's the reason OP is having issues, and the reason I avoided toolkits until I couldn't any longer.*

      It's very important to be able to tell a produc

  • Build vs. Buy (Score:5, Interesting)

    by michaelmalak (91262) <michael@michaelmalak.com> on Saturday January 03, 2009 @12:43PM (#26312123) Homepage
    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.
  • 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?

    • Financial
    • Manpower
    • Engineering

    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

  • by Jane Q. Public (1010737) on Saturday January 03, 2009 @12:48PM (#26312159)
    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.
  • 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

  • by level4 (1002199) on Saturday January 03, 2009 @12:52PM (#26312197)

    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.

    • One has to take the name "framework" literally... it provides a foundation, YOU provide the structure. Expecting your framework to be a complete solution in itself is like expecting a building foundation to be a complete home: you will be disappointed. And you will have nobody to blame.
  • [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)

    by BrainInAJar (584756) on Saturday January 03, 2009 @12:59PM (#26312237)
    Why not deploy your app on JRuby, and if there are still performance bottlenecks, write those parts in real Java ?
    • by dkf (304284)

      Why not deploy your app on JRuby, and if there are still performance bottlenecks, write those parts in real Java ?

      Apart from whether to use Java or not, this post exposes a really good point: if you've got performance problems, you're often best off rewriting part of your app in a lower-level language. Keep the rewritten part small though, since it's usually easier to work in a higher-level language. And always measure whether you're addressing a real bottleneck and making it better...

      (The identities of the higher/lower-level language aren't so important as the principle of splitting.)

  • Contribute (Score:3, Interesting)

    by RAMMS+EIN (578166) on Saturday January 03, 2009 @01:00PM (#26312239) Homepage Journal

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

  • by r (13067)

    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

    • You could have just forked the library, and kept your own code (and version) rather than updating to the latest of their version. Your "solution" puzzles me, as it seems to be shooting yourself in the foot.
    • by quanticle (843097)

      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?

      • by r (13067)

        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?

        Yes, that would help with testing, but also multiplies the work: now you have patches and the new test suite to maintain and shepherd through upgrades. :)

        Testing patches actually wasn't the main obstacle. The far bigger time sink was when some patched piece of functionality moved over to a different location in the codebase. Then the engineer had to go and become

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

      So write plugins, instead of monkeypatching.

      Better yet, use a framework like Merb, which has a well-specified Plugin API. Stick with that, and your plugin will work for at least the rest of Merb 1.x. If there's something you can't do with only the plugin API, that is considered a bug.

      Merb 2.0 will also be Rails 3.0, so alternatively, wait until then -- Rails will then have a plugin API also.

    • by terjeber (856226)

      Maintaining custom patches for a foreign codebase is going to be painful

      Well, the thing is, in Ruby it is not. Given the tools that Ruby gives, such as mixins, modifying the core of a framework in a maintainable manner is a lot easier. Now, if you go out and fix the framework in a non-Ruby manner, for example by altering the framework source in-place, you will have problems, but if you do, you need to re-take Ruby 101.

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

    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

    • by quanticle (843097)

      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.

    • I've tried doing similar things. Possible outcomes:
      1. Project accepts your code. (all is right with the world)
      2. Project rejects your code, because they have a different plan for solving the problem ( 2 major releases away!)
      3. Project denies that the problem exists

      I've experienced all three. The second two, are far more likely than the first.

  • by presidenteloco (659168) on Saturday January 03, 2009 @02:20PM (#26312761)

    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)

    by starrsoft (745524) * on Saturday January 03, 2009 @02:26PM (#26312819) Homepage
    FTFA:

    So we have two basic options: pay for bigger hardware, or spend more time writing/maintaining custom code that allows us to live on our existing hardware.

    Hardware is Cheap, Programmers are Expensive [slashdot.org]:

    Given the rapid advance of Moore's Law, when does it make sense to throw hardware at a programming problem? As a general rule, I'd say almost always. Consider the average programmer salary here in the US. You probably have several of these programmer guys or gals on staff. I can't speak to how much your servers may cost, or how many of them you may need. Or, maybe you don't need any--perhaps all your code executes on your users' hardware, which is an entirely different scenario. Obviously, situations vary. But even the most rudimentary math will tell you that it'd take a massive hardware outlay to equal the yearly costs of even a modest five person programming team.

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

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

  • Integrate the rails hacking into your release process.

    * import rails into your scm -- one that has good branching and merging

    * regularly update your scm rails trunk to recent upstream release

    * branch rails locally as part of your release process. that includes using the branched release in QA.

    * get as much of your local changes as possible merged upstream! it's a pita to start, but your effort will be rewarded.

    Use the right tool for the job.

    * use standard APIs so you can switch back and forth between your

  • by Anonymous Coward

    The true differences between frameworks are inevitably revealed as soon as you try to build a product of significant complexity. A truly flexible framework makes it easy to override, overload, or otherwise replace functionality WITHOUT having to modify the framework itself. This has long been my issue with a number of web frameworks implemented in a variety of frameworks. There are many frameworks that will make a fairly simple form based web application come together very quickly. If you've got 5-10 fo

  • Big Surprise (Score:3, Insightful)

    by holophrastic (221104) on Sunday January 04, 2009 @01:30AM (#26317607)

    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.

  • It sounds to me like the OP is complaining that his hammer won't work with every nail.

    No tool is perfect and each has limitations.

    Use each tool as appropriate and do not prescribe to purism over functionality.

A LISP programmer knows the value of everything, but the cost of nothing. -- Alan Perlis

Working...