So I've been programming in PHP for the past 7 yrs. What I should be doing is learning OOP but all the talks about RoR and Django interest me even more. With that said, I started to follow RoR when it first came out. I knew of it through 37signals when I was first introduced to their products. At the time, I continued to use PHP, it was what I knew and I was able to produce code much faster than trying to learn a new language.
Fast forward to 2009 ... it was a few yrs ago when Twitter made headlines, when they implemented Scala due to RoR's inconsistency. My question, have things gotten better for RoR? I know I shouldn't go by one company's issue but of course the fanboys will probably jump all over this and bash or pump one language over another.
I would assume by now lots of bug fixes and enhancements have been made, but I would still like to hear what annoyances there are with RoR that still needs to be addressed.
TIA!
Twitter's problems were not with Ruby or with Rails, and they have explained this at length.
This is becoming one of those various urban legends that everyone "knows" to be true, but isn't. It's quite hard to google for the story here, probably because of all the "follow me on twitter" buttons. Fortunately, a Stack Overflow answer referenced a detailed discussion on this that included Twitter developers.
I will give one other urban legend example that is (via RSI) somewhat programming-related: the Dvorak keyboard. Everyone knows that QWERTY is designed to be inefficient, to slow down the operator, and that it is an example of market failure, right?
Another urban legend: Dvorak vs QWERTY
Turns out this legend is not just completely false, but it has been deliberately, deceitfully falsified. Yes, the US Navy did test the patented Dvorak keyboard in 1944. But according to this report on the Dvorak keyboard:
How can we take seriously a study
which so blatantly seems to be
stacking the deck in favor of Dvorak?
And, indeed, there appears to have
been good reason for that deck
stacking.
We discovered that the Navy's top
expert in the analysis of time and
motion studies during World War II was
none other than...drum roll
please...Lieut. Com. August Dvorak.
Earle Strong, a professor at
Pennsylvania State University and a
one-time chairman of the Office
Machine Section of the American
Standards Association, reports that
the 1944 Navy experiment was conducted
by Dvorak himself.
Later tests by other organizations showed no advantage for Dvorak. It is also worth noting that slowing down typists was not a goal even in the early days of the typewriter. Actually, typing speed contests were conducted regularly with great publicity and the fact that typists were fast on QWERTY was a factor in the adoption of QWERTY.
Dvorak and Twitter and RoR
The false version of this story has been repeated for literally 65 years now, partly because almost no one cares about original sources, they just repeat the version they heard. Another parallel with RoR and Twitter is the religious/political angle. People have language and framework loyalties, and they have economic system loyalties, and the enduring legends play into existing bias. The Twitter story connects with some people's emotional perspective on the expertise they do and do not yet have; the QWERTY story connects with some people's personal dislike of free market economics.
Twitter switched some parts of their architecture from Ruby to Scala because when they started they used the wrong tool for the job. They were using Ruby on Rails—which is highly optimised for building green field CRUD Web applications—to try to build a messaging system. AFAIK, they're still using Rails for the CRUD parts of Twitter e.g. creating a new user account, but have moved the messaging components to more suitable technologies.
Your best bet is going to be working through a little prototype app. Rails is pretty nice once you get the hang of it. Though that is a similar truth to many frameworks.
Take a little piece of your app that's either easy or hard in php, and try to write it in rails. It shouldn't take too long and should give you a good real world example.
Personally these prototypes are my favorite. Systems with no users are the easiest to write.
Well, it's not only twitter that is based on Ruby on Rails. There is a long list with successful new projects - http://storecrowd.com/blog/top-50-ruby-on-rails-websites/ .
May be the only annoyance referenced by lots of users is the performance. However Ruby 1.9 addresses that problem and is compatible with most of the libraries already. Furthermore performance problems are function of Developers' programming knowledge in most cases and rarely a function of programming language speed.
My advice is just to give it a try for a week or two :)
Are you planning on having a site as heavily trafficked as Twitter?
If not, why are you worrying about issues that only came up under massive load?
Related
I am looking to start developing a relatively simple web application that will pull data from various sources and normalizing it. A user can also enter the data directly into the site. I anticipate hitting scale, if successful. Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack? Framework or not? Any thoughts, suggestions, or comments would help.
Disregard my vague description of the idea, I'd love to share once I get further along.
Later. I can't remember who said it (might have been SO's Jeff Atwood) but it rings true: your first problem is getting other people to care about your work. Worry about scale when they do.
Definitely go with a well structured framework for your own sanity though. Even if it doesn't end up with thousands of users, you'll want to add features as time goes on. Maintaining an expanding codebase without good structure quickly becomes fairly horrible (been there, done that, lost the client).
btw, if you're tempted to write your own framework, be aware that it is a lot of work. My company has an in-house one we're quite proud of, but it's taken 3-4 years to mature.
Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack?
A LAMP stack is scalable. Apache provides many, many alternatives.
Framework or not?
Always use the highest-powered framework you can find. Write as little code as possible. Get something in front of people as soon as you can.
Focus on what's important: Get something to work.
If you don't have something that works, scalability doesn't matter, does it?
Then read up on optimization. http://c2.com/cgi/wiki?RulesOfOptimization is very helpful.
Rule 1. Don't.
Rule 2. Don't yet.
Rule 3. Profile before Optimizing.
Until you have a working application, you don't know what -- specific -- thing limits your scalability.
Don't assume. Measure.
That means build something that people actually use. Scale comes later.
Absolutely do it later. Scaling pains is a good problem to have, it means people like your project enough to stress the hardware it's running on.
The last company I worked at started fairly small with PHP and the very very first versions of CakePHP that came out (when it was still in beta). Some of the code was dirty, the admin tool was a mess (code-wise), and sure it could have been done better from the start. But do you know what? They got it out the door before their competitors did, and became extremely successful.
When I came on board they were starting to hit the limits of their current potential scalability, and that is when they decided to start looking at CDN's, lighttpd caching techniques, and other ways to clean up the code and make things run smoother when under heavy load. I don't work for them anymore but it was a good experience in growing an architecture beyond what it was originally scoped at.
I can tell you right now if they had tried to do the scalability and optimizations before selling content and getting a website live - they would never have grown to the size they are now. The company is www.beatport.com if you're interested in who I'm talking about (To re-iterate, I'm not trying to advertise them as I am no longer affiliated with them, but it stands as a good case study and it's easier for people to understand what I'm talking about when they see their website).
Personally, after working with Ruby and Rails (and understanding the separation!) for a couple of years, and having experience with PHP at Beatport - I can confidently say that I never want to work with PHP code again =p
Funny to ask "scale now or later?" and label it "ruby on rails".
Actually, Ruby on Rails was created by David Heinemeier Hansson, who has a whole chapter in his book labeled "Scale later" :))
http://gettingreal.37signals.com/ch04_Scale_Later.php
I agree with the earlier respondents -- make it useful, make it work and get people motivated to use it first. I also agree that you should pick off-the shelf components (of which there are many) rather than roll your own, as much as possible. At the same time, make sure that you choose components for your infrastructure that you know to be scalable so that you can go there when you need to, without having to re-write major chunks of your application.
As the Product Manager for Berkeley DB, I've seen countess cases of developers who decided "Oh, we'll just write that to a flat file" or "I can write my own simple B-tree function" or "Database XYZ is 'good enough', I don't have to worry about concurrency or scalability until later". The problem with that approach is that a) you're re-inventing the wheel (and forgoing what others have learned the hard way already) and b) you're ignoring the fact that you'll have to deal with scalability at some point and going with a 'good enough' solution.
Good luck in your implementation.
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm considering Prestashop for a new project. It seems to be younger than Zen-Cart and osCommerce. Since I just found it by Google, I'd like to gather comments and experience and comparison of Prestashop to established "brands" like Zen-Cart and osCommerce
I work daily with PrestaShop. I think that it's the perfect solution for an average project. If you need something extremely fancy (but also extremely difficult to configure/use) you should go for Magento. I'm a programmer and I've had difficulties setting it up like I wanted. The learning curve is too steep. Of course it brings other advantages, but the project has to be big enough to make up for the time lost in learning to use the the platform.
The thing I like the most about PrestaShop it's the ease of use (for both the developer and the shop admin). Its modular system completely demolishes osCommerce. Everytime I have to work on an osCommerce shop, I cringe. It's outdated and it's not a good option, by any means. If you need to change the layout of the store, you just drag modules around in the Back Office. There's no cutting and pasting code in PHP files. The same for installing new modules.
In my opinion, PrestaShop is mature enough at this point. There are hundreds of modules you can use to customize it to your liking (just do a google search or try their forum). The template system is also top-notch and easy to use. Take a look at what you can do: http://www.templatemonster.com/prestashop-themes.php
I also messed around with VirtueMart. It's not a bad solution if you want to integrate your shop with a CMS (Joomla). There's also TomatoCart, a new-comer (they still don't have documentation for developers) that's based on osCommerce 3 alpha, but from what I've seen it's a major improvement. The Back Office is amazing.
Summing it up, I think PrestaShop is excellent if you need something that's easy to use, easy to configure and flexible. Magento is better for LARGE projects because there's a lot of overhead. If you are planning on configuring more stores in the future, the time lost learning Magento might be acceptable.
We install and review all open source eCommerce solutions as a matter of course. So we have looked in depth at all the one mentioned here. I prefer osCommerce to Prestashop. Prestashop is too immature and simply does not have the in-built functionality or breadth of Add Ons. It is not a "lite" version of Magento by any means.
As to the other poster's comment about osCommerce and Magento. Magento is an out of the box solution which is very difficult to customize. You need to be a programmer to work with it and even then the learning curve is steep. And if you do customize, you then are buying out of their upgrade path. Which is why the average site does not customize and why so many Magento stores look so much alike.
Unlike Magento, osCommerce has and always will be intended as a core eCommerce solution on which you build you own unique eCommerce solution.
Two different approaches to building an eCommerce site. One is cookie cutter then other is fast track to custom solution.
As one that love working with Magento i just wanted to show you this article.
If i were in the works of setting up an site for online commerce, i wouldn't choose ZenCart or OSC. They are both old and doesnt update at all. But thats just an personal opinion. And i work a lot with these things.
My Prestashop knowledge is limited though, but if its anything like Magento i would recommend it. Cuz Magento is by far the leading commerce platform atm. Also just my 2 cents.
Magento vs Prestashop
More reading OSC vs ZenCart
PrestaShop is an impressive new entry to the field, with a very attractive user interface and impressive product option/variant capabilities (like Zen Cart attributes). One downside is that it's much harder to modify; there is nothing like the Zen Cart "templating " capability so you're always changing core files. This gets hard to manage with the frequent release schedule PrestaShop is using. But you should definitely install it and spend some time testing it and evaluating its suitability for your shop.
prestashop is much easier than zen cart, oscommerce and magento. the easiest thing to do is try to install them as they are all free.
#Arta incorrectly stated, with regard to ZenCart,
They are both old and doesn't update at all.
ZenCart IS maintained, IS updated frequently and DOES have a decent roadmap into the future along with a robust community.
Here is a recent (March 2011) update from the ZenCart Team:
http://www.zen-cart.com/forum/showthread.php?t=175569
Personally, I have installed, configured and maintained no less than 3 ZenCart shops, having found ZenCart subsequent to using "Selena Sol's" and Gunther Birzniek's Perl-based eCommerce app creatively named, "WebStore" for several years.
I thought I'd died and gone to heaven when I found ZenCart because I am not a programmer - I'm just a plugger who pushes hard enough on something to make it work.
With ZenCart, the community help is excellent. The "Getting Started" documentation got me started and got my websites running.
I've looked at Magento (too da*n complicated) and just about every shopping cart that's out there.
Maybe I'm just getting old but things that are shiny and new still do not compare to my OLD ZenCart for the key features I need:
Secure.
Integrates with Authorize.net & Paypal, among others.
TRUE Quantity Pricing.
Price based on Options.
Categories.
Fine, granular control over Product page Title and Keywords.
Easy to update when updates are released because I don't muck with CORE files (and I've never had to).
Thriving, responsive community.
Open-source. TRULY open-source.
I do have one complaint, though. I WISH the folks at ZenCart would reorganize their add-ons page to make it easier for ppl to find an add-on and know when the add-on was last updated. But as you can see, this is not a complaint about the Shopping Cart software itself.
Hope this helps.
I agree with Val booth. Zen cart is the best and easiest. It has just about any option you can imagine, the templating is easy to install and adjust, and help comes very quick for questions posted in the forum.
My only beef with Zen cart is that the control panel the user logs into is a little complex for any changes if you are a computer newbie. This is only because setting are located in different places instead of one area only. There are many features in some cases located in multiple places. Say you want to add features to your homepage, you might have to go to one area to check a box to enable the features on the homepage, another area to defind the features, and another area to list the features. Meaning you have to bounce around. I have been using zen cart for several years and have it installed on many of my clients websites. The control panel always takes a little training for my clients. With that being said the reason for this is because this program has any feature imaginable. That means more complexity (Not it's not that difficult you just have to bounce around to make big changes).
As far as features this is the main reason why you should use Zen Cart. Let me give you a recent example. One of my clients charges tax for Ohio and California. Two different rates it wasn't a problem (just a little help from the forum and a couple of changes in the control panel). Next, they wanted free shipping to the USA only. Not a problem worldwide shipping for a charge (USPS) and free shipping within the USA. They also have lots of options for each product. No problem. I tell my customers: "With Zen Cart you can grow into your carts features years down the road." The structure is already there even if you don't think you need certain features now. Instead of having to install a different cart, we just enable a new module or feature. It's common for the needs of a business to change. As your website (business needs) change the zen cart features are already there waiting for you.
Don't overlook the fact that has been mentioned in these posts about zen cart updates. When you make changes to any core coding it goes in it's own folder named after your template. When you update the cart it does not mess up any of your past changes. This is very powerful because updates are common and easy and you don't need to re-modify your past changes! With other large programs this is not the case and puts a lot more work on you for each new update. Look in forums all over the web and you will see that Zen cart is the most flexible, the easiest to use, and has the most features.
No I have no affilaite with Zen cart at all, I am just a regular webmaster who installs shopping carts onto my clients websites and has been asking questions in their forums for years. I can tell you from my experience Zen Cart is the bomb!
I found prestashop more powerful but to customize it you must have knoeledge on CSS , smarty template and php. For me it is better than Zen and Os
Having used oscommerce, zen cart and more recently prestashop I would say prestashop is probably one of the easier solutions for building a relatively simple, attractive looking site. My main site is zen cart but I'm considering changing to prestashop. Unless you are an experienced designer / developer then I'd stay clear of oscommerce and go for zen cart or presta. Zen Cart is in a way a simpler version of oscommerce. Prestashop just looks more tidy and less like an "out of the box" solution to the untrained eye than os and zen. Some of the free templates are pretty tidy, and with the odd change to a few images it's relatively easy to customize the feel. Function is another story. As stated before there's limited documentation and community with presta - which i'm sure will grow steadily over the next year or so, which might make a beginer go with another solution.
Ive been using OSC these past few years and recently i started exploring Prestashop. I find presta harder to modify compared to OSC.
I think if you are more of a visual designer, it is easier to use OSC. But if u are more of a businessman, u should go for presta. The interface can be customizable but it'd take more time compared to OSC.
i have used Oscommerce and yesterday i have just installed prestashop....and i found presta a bit harder than osc because it is fully object oriented and uses smarty template.
i think it is harder to modify presta than osc.
Prestashop has been growing and improving extremely fast, both in number of users / forum members, and in development / features added.
A good resource to start with is the new book "[PrestaShop 1.3 Beginner's Guide]", it goes though all the important features in Prestashop and guide you towards getting your shop online and having your first sale in one week.
In addition to doing technical review for the book, I am also an English Moderator on the Prestashop forum, and I see people with no programming or website development background manage to install and customize their own shops, add themes, modules and modification with little or no help.
The [Prestashop forum] has been growing rapidly as well, it reached nearly 90,000 members, and is by far the best place to get help or questions answered, usually within a short period of time.
Make sure you search the forum first, because many questions have already been answered…
Speaking as a representative of the company:
For a small business or anyone without a massive dedicated server, PrestaShop is probably the best choice. Any of these options will have a steep learning curve, but I would have to say that PrestaShop is the easiest to get up and running compared to the rest.
Also, we've really made a commitment to customer service, and the forums have become a much better place to get answers since we opened an office in the United States.
The prestashop as good as it looks has still very little or no documentation and or ridicilously complex written smarty templ. stuff, driving us "open source" fanatics, like cattle into bottleneck traps forced to buy our way out.
Don't forget it's a company! they are even hiring at the moment. and we will be caught.
and imho, "open source" by a company?
reaping all the benefits of community development, organising predators and game refuge paths for a nice game hunting season.
I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.
We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.
After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:
So I thought it would be about time to
set the record straight on a number of
unfounded fears, uncertainties, and
doubts. I'll be going through these
myths one at the time and showing you
exactly why they're just not true.
This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn't
founded in the many myths floating
around.
Let's Clarify!
Myth: "Ruby on Rails doesn't scale"
Bust: That is not a specific, answerable question. Please clarify.
Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:
"What precisely do you mean by 'scale'? and how do you measure it at the moment?"
It could mean:
Maximum user sessions
Average response time given load
Throughput of given concurrent scenarios per server in a fixed time.
... difficulties organising the project so a large team of developers could work on it.
There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.
There are loads of ruby-based solutions, including
caching fragments of HTML
sharding the application across multiple databases
pre-computing work that's shared between users
pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
using a front-end web server more efficiently
just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
doing less interactively and having more batch work
doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend
If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.
However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.
Make the argument from the only perspective the client understands, money!
Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.
In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:
1) Why Rails?
Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)
http://www.theserverside.com/news/thread.tss?thread_id=33120
2) Rails doesn't scale
http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html
3) Rails is just a CMS?
If they are building a CMS then recommend Drupal, not Rails
I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job
Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.
Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.
Myth: it is hard to hire a good Ruby on Rails programmer.
(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)
Tomorrow, I will meet a client that is not working in technology but might ask if RubyOnRails is the right choice for his site. He might think that there's not enough RoR programmers and that he will be "hostage" of the language.
I have good reasons to use RoR and the client has good reasons to like it (it costs less!).
Do you have "official" sources I could show them?
Using a framework ensures that the "next guy" can pick it up quickly
Rails has reduced my workload by 80% over hand-coding.
Huge, active, friendly community to draw upon
Self documenting testing frameworks
It uses Ruby, which is super easy to learn in a pinch
Open source language, framework, and database that uses an open source OS. FREE sells.
This is, in some sense, a variant on the "bus hit factor" problem. Any app, once developed, is pretty much "hostage" to the language, the question is whether it is also "hostage" to the single developer who wrote the app. I think that RoR is a perfectly reasonable choice for development, but the issue is really how many developers in your local area are available to take this over if you happen to "get hit by a bus." If the customer is willing to work with someone remotely, this becomes much less of a problem. To reassure him, though, I'd first look to the local scene and find out about local Ruby developer groups. The presence of active, local developer groups is one measure that might convince him.
If, on the other hand, he's concerned that RoR will not continue to be viable in the future that is a slightly different issue. Again, I think you're ok -- you may want to point out other applications that are written using RoR as an indication of continuing pressure to improve both the language (Ruby) and the framework (Rails). You can find a lot of this information at http://rubyonrails.org/.
"might ask if RubyOnRails is the right choice for his site. He might think that there's not enough RoR programmers and that he will be "hostage" of the language."
Have you considered the possibility that these are valid concerns that should be taken seriously?
"I have good reasons to use RoR"
How does that help your client, though?
"it costs less!"
Does it? Do you have any specific evidence to support that assertion? Have you factored in hosting costs? Rails on MRI uses a lot of RAM. You're probably in Java territory or worse. Depends on the app and the load of course. Phusion Passenger (mod_rails) has improved the situation somewhat, but it's still an issue.
As mentioned by others documentation is a "HUGE" issue. Ruby and Rails official docs are sparse, to put it kindly. The community tends to rely on paper books which become outdated and misleading in a matter of weeks, thousands upon thousands of unreliable, contradictory blog posts, and screencasts which also suffer severely from the "quickly-outdated" problem. Don't think PeepCode is going to save you.
I would still consider advising a client to use Rails because the claims of programmer efficiency are more or less true, sort of, but I'd do so with extreme caution and I'd let him know the downsides.
Documentation is HUGE when it comes to open-source projects.
One thing you could do would be to explain to your client that it will cost them much more to have you and your developers spend hours and days searching for documentation on some other open-source framework that is less used and supported. Explain that there may not be as much ROR developers out there as there are PHP developers per say, but the fact that there's such a great amount of documentation and information about ruby and rails makes it exponentially easier to for any open-source developer to learn and use the framework.
There would be some things I would try to convince the client-
Ruby Community is huge
Ruby is mature enough
Ruby works with most database systems.
Rails is a product based on an Idea(MVC) most other platforms have embraced.
Improved readability and testability of code.
COSTS LESS!!
Migration methodology in RubyOnRails
If you want you can even target the Java Platform using JRuby and Java Platform is a pretty respectable platform.
Show some cool RoR applications.
Explain how you could be Agile!
I know so well clients not agreeing when you dont have a big company backing a technology.
The "cost less" feature of RoR is debatable, I agree with you. But in my case, I have a complete RoR-ready environment and I know that I can charge less for a RoR app than any PHP app that I could do.
The hardware/software environment for PHP and Rails are almost the same... so is the price of it. What will cost less for the client is the robust environment that we built.
That's the "cost less" feature. I'm not talking about about memory comsuption or anything else. It all can be bought for almost nothing.
This depends a lot on location. If RoR developers are plentiful and work for prices comparable to other programmers then you can use that to help sell Ruby.
For a client one of the main concerns is cost. Perhaps he is concerned about maintenance costs of finding and paying for a RoR developer, not the cost of the technology.
I know a web shop who was bitten by the relative 'newness' of RoR. They hired a developer to make a site and that developer use RoR. After the project the developer left. In our area RoR developers are not only scarce, they charge more than any other type of web developer. In this particular case the web shop ended up losing their client. The last I checked their client's web site is in PHP.
I'm not trying to say RoR is bad and I think that's an extreme case, but make sure to consider the client's concerns. The cost of maintenance is a very valid concern.