How did the “Rails can’t Scale” meme start

ActiveRecord provides the attributes method, which returns a hash of attribute names mapped to their values for the receiving object. So you can do something like (example console session):

> u = User.first
> u.attributes
=> {"first_name"=>"Joe", "last_name"=>"Bloggs","email"=>"joe@bloggs.com"}
> u.attributes.keys
=> ["first_name", "last_name", "email"]
> u.attributes.keys.include?("middle_name")
=> false

Documentation link

I think you make a mistake in assuming that the choice of technology is a purely technical decision.

The customer seems to be concerned about the business implications of picking a particular technology. Given that, you need to present a case that addresses his business concerns at least as heavily as your technology opinions.

• Employers have to recruit from a particular geographic area and certain areas have particularly active communities around particular technology stacks. If you're starting a business in the Pacific Northwest of the US, for example, there would be a strong bias towards a Microsoft stack simply because Microsoft is very influential in the area so most of the developers you'd be looking to hire would have experience with that stack. Other geographical regions have very different profiles.
  Talk with your customer and understand why and how he formed his opinion. Perhaps he read that the local PHP community is particularly active or that the local college teaches a lot of PHP and no Ruby. Perhaps he's got a trusted developer that he can call in for the occasional emergency that is a PHP pro and a Ruby neophyte. Of course, it's also possible that he's using poor metrics like the number of job ads or resumes that mention various keywords.
• Employers have to be concerned with the long-term sustainability of technology stacks. Years ago, for example, lots of companies invested a great deal of time and effort building PowerBuilder apps (and other languages of that genre). PowerBuilder often made it very easy to build line of business apps and developers at the time were often quite enamored with it. Unfortunately, the PowerBuilder community more or less collapsed leaving companies in a situation where they had a lot of existing code in a language no one really wanted to use where they had difficulty getting competent developers to maintain the existing code and expensive, time-consuming projects to migrate those apps to other technology stacks. The relative technical merits of PowerBuilder were vs. Java or C++ or C# or whatever they migrated to at that point; it was a death spiral since developers didn't want to get stuck working in a language that companies wanted to migrate away from and companies saw the lack of developers as a sign they should redouble their migration efforts to ensure they had the capacity to do the development the business needed.
  Relatively niche languages like Ruby absolutely have the potential to create these sorts of legacy problems for companies who can't predict whether the language is going to fizzle out in a few years when people move on to the next fad or if it has real staying power. You can certainly mitigate this by pointing out that Ruby isn't dependent on one company or organization so no one can decide it is no longer a strategic product for the company. If your customer has been burned in the past by having applications developed in languages that became business headaches, you'll need to make a case that Ruby is more like Linux and other open source technologies that flourished without a company backing them than languages that have died out over the years.
• Employers want consistency in the environment so choosing a language for one project forces a choice for many others. Even if Ruby is technically ideal for the project you're pitching, you have to explain why it's appropriate for every other application this customer is going to need developed or explain what mix of technologies you believe are appropriate (i.e. Ruby for X, something else for Y). Dealing with heterogeneous technologies, however, inevitably translates into extra cost for the business.