Balancing Performance and Convention 171
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?"
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.
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.
Re: (Score:2)
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)
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.
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
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.
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).
Django is not really an improvement (Score:2)
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
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
Re: (Score:2)
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.
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.
Re: (Score:2)
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,
Re: (Score:2)
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)
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.
Re: (Score:2)
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)
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".
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
Re: (Score:2)
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.
Amen. Like the poster above who wants rails to include, in its core functionality, the ability to store images, automatically retrieve the image and a thumbnail of said image depending on the situation. This isn't stuff that belongs in an application server framework, but it does belong in an image manipulation framework and a DB driver (re-sizing images in one, storing stuff in the other).
I find that a lot of people who ask for special functions like this are just simply bad developers. Often self-taught t
Re: (Score:2)
However, we use filesystem storage for media, finding direct DB storage to be somewhat problematic.
Being Sunday, I do not have that information. (Score:2)
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)
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.)
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)
Re: (Score:2)
Right, but the suggestion was of using JRuby for the Ruby implementation (including Rails), and using "real Java" for the performance bottlenecks. I responded to a comment making fun of that idea.
Now, ensure that you also score memory performance.
"Memory performance" is not a goal in itself - it only matters to the extent that it affects speed (though GC, cache misses, and so on). (And of course if you don't have enough memory to run your application at all or without paging, but t
Re: (Score:2)
The only reason it is even acceptable in a lot of situations today is because the hardware has gotten so much faster.
Re: (Score:2)
It's generally the fastest garbage collected language there is that allows easy refactoring and creating highly maintainable code. If you consider Java slow, than you must be programming in C/C++ which is not very well suited for the tasks the OP requires. A great many people seem to conclude that just because they've seen a few poorly performing Java applications (usually old apps with a user interface) that the language itself is slow, however the only conclusion you can draw from that is that those spe
Re: (Score:2)
True, but that is not saying much. As I stated before, it may be the fastest in its class, but it still ain't fast.
"If you consider Java slow, than you must be programming in C/C++"
No, my language of choice is Ruby, which is generally slower than Java. But again... that doesn't make Java fast.
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
Re: (Score:2)
Re: (Score:2)
We're trying to figure out what your point *is*, and if it makes any sense at all.
You started with:
Haha. This is the first time in a long time I have seen anyone seriously suggest using Java for better performance...
But then you agree that:
Obviously it is faster than the more dynamic languages like Python or Ruby. I never claimed otherwise.
Er... if it's faster than Python or Ruby, why is it so funny to use it for better performance?
There's also a lot of evidence that Java's performance in general is quite close to that of C/C++, but many tens of times faster than Python/Ruby/etc.. ...so, it seems pretty reasonable to use Java for a performance improvement. I've done it before a number of times -- my last large project in
Re: (Score:2)
Why has everybody been trying to read more into that than there is?
I happen to program almost daily in Ruby, which tends to be slower than Java... and if I heard someone say that about Ruby I would laugh even harder.
Where is the contradiction in this?
Re: That's rich! (Score:2)
Ah, now that's rich! You say you "program" in Ruby, but I can't think of the last time I heard anyone seriously suggest that you were even a competent programmer.
Oh, wait -- the "factual" nature of that statement doesn't mean it's not misleading, full of crap and worth calling out. I simply don't know anything about you.
Maybe you're just trolling, at this point; whatever.
Re: (Score:2)
Re: (Score:2)
Okay, last shot, then I give up.
Read the first statement I made in the GP post. It's factually true (I haven't HEARD that you're competent), but very misleading, because there's no reason I *would* hear anything positive or negative about your programming.
I was making a point, which I explained in the second paragraph.
Your original "That's rich!" comment was mocking someone for suggesting Java to speed up a RoR app, but apparently you have no basis to mock them; you simply haven't heard that suggested befo
Re: (Score:2)
There was no actual mockery intended, just a simple comment.
Re: (Score:2)
No, my language of choice is Ruby, which is generally slower than Java. But again... that doesn't make Java fast.
Speed is a relative thing in the computer world. Java today can in many cases compete with C++ in speed, and it immensely more maintainable with fewer resulting problems. So, yes, I would in fact say that Java is fast. Not compared to hand-written assembly that solves a limited problem, but in the league it plays, one that partly includes C++, Java is fast.
Have you written any Java code that wasn't fast? Perhaps it was you :-)
Re: (Score:2)
"Have you written any Java code that wasn't fast? Perhaps it was you
I am not aware of having stated anything that warranted insults.
Re: (Score:2)
am aware that Java 5 (aka 1.5.x) made some major speed improvements, but this is the first I have heard anybody claim that it "competes" with C++.
Well, I am glad that you say "first I have heard" since that explains it. You simply haven't been around that much to hear. Perhaps you do not work in the right industry. Perhaps you haven't been keeping up with Java at all. For one, Java is at 6, and it has been competitive for quite some time. As the benchmark here shows [debian.org], java is very competitive with C++. This is for CPU intensive benchmarks. Once you add disk and database access into the mix, as you do in most applications, the speed difference between
Re: (Score:2)
Not at all. I think your own opinion is colored with simple exaggeration.
My "prolonged lack of information" has been al
Re: (Score:2)
Sure, until you add the memory used back in ... and then it falls to mid way between C and Python. Of course you then add in "size of code" (read: programmer time) and it's about par with Python ... and it's much easier to hook C code into python for the bits that need to be fast.
And the new "shootout" specifically asks for the "simplest" versions in each language, so I'd say it significantly underreports C/C++ code's speed compared to other
Re: (Score:2)
Nonsene. (Score:2)
Of course, you have no way of knowing exactly what I have heard; but neither do you have any real reason to doubt my statement.
Re: (Score:2)
If you go back and read it again, you may see that my comment was perfectly honest and accurate.
How was it accurate? Java is the second highest performing programming language of the modern OO and equivalent languages. It's performance is some times slightly slower, some times slightly faster than C++. In reality, Java is very close to C++ in performance for all the most common programing tasks today. Your statement implied that Java was very far from high performance, which was 100% wrong.
So, being 100% wrong, what was it that was accurate about your statement?
Of course, you have no way of knowing exactly what I have heard;
I couldn't care less about what you have
Re: (Score:2)
It was accurate because what I stated, way back in the very beginning, and what you were supposed to be replying to, was that this was the first time in a long time I "had heard" somebody recommend Java for performance reasons. That was a completely truthful -- and accurate -- statement! I challenge you to demonstrate otherwise! (Hint: you would have to be my Siamese twin in order to convincingly do so.)
"I couldn't care less about what you have heard, and what you have heard
Re: (Score:2)
Sure, until you add the memory used back in
Not quite sure what you mean by this. GC or the fact that C++ uses less memory than Java.
I see a lot of "in the wild" C code that does really weird stuff so it can, supposedly, get a tiny speed/mem imporovement
Yes, one does. I have even written some since I was doing embedded work once and every byte counted and every cycle counted. This is called optimization and we do it using various types of tools. For Java there is not as much reason to create "weird" code to make it go a little faster since the VM can perform that kind of optimizations. In Java you can, given the ease of development over C/C++, spend time making algorit
Re: (Score:2)
this was the first time in a long time I "had heard"
Which just means that you are ignorant and have a desperate need to flaunt it.
since it was about THAT STATEMENT, and NOT about Java's actual performance!
Sorry, I misunderstood your comment. I took the "that's rich" part to actually mean that you commented on Java performance. I was not aware that you only had some masochistic need to announce that you were ignorant. I am absolutely sure that Julia Roberts also has never heard that Java has a certain level of performance, but I doubt she has a need to advertise this particular ignorance in various public fora. I would assume that J
Re: (Score:2)
I have read the article in question, and it takes a specific "performance test" to task over bad methodology. I have not endorsed said methodology but referred to an article on the topic of performance that is more in depth.
If you have any information about the methodology applied in this article [idiom.com], please let me (and the author) know.
I also referred to this one [debian.org], again not the one with the flawed methodology. If you feel there is anything wrong with either of these, please feel free to enlighten me.
Re: (Score:2)
In the link you gave to the new shootout, it has three "comparison type" boxes: 1) CPU. 2) MEM. 3) LOC. Java does well if you just turn on the first box, I explained what happened as you turned the other two boxes on.
And, unlike the other poster, I'm not implying that Java isn't "fast enough" just that "faster than C or C++" is misleading at best.
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?
Re: (Score:2)
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
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. 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.
Re: (Score:2)
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.
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.
Re: (Score:2)
I've experienced all three. The second two, are far more likely than the first.
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.
integrate into your process (Score:2)
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
Good frameworks provide flexibility (Score:2, Interesting)
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)
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)
Agreed.
Although, I'm detecting a hint of sarcasm. Which makes sense only because you're missing a key piece of information -- I own the two businesses involved. The job market in which I'm interested is in not having to hire other programmers.
So yes, considering the employees market, allowing other companies to control mine by defining the tools I use for me is simply not beneficial when compared to my doing it myself. As usual, doing it myself is teh better way to go -- long term.
Hammer and Nails (Score:2)
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.
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.
Re: (Score:2)
Re: (Score:2)
Stay away from Drupal.
I think there is a huge conspiracy going on between Drupal "press" and Drupal "consultants".
Re: (Score:2)
And "Rails" isn't a framework? And by "as3" I assume you mean ActionScript3, presumably for Flex, which one might reasonably assume is a framework, no?