Installing Rails on a Mac Shouldn't Be As Hard As It Is | Hacker News Reader

Installing Rails on a Mac Shouldn't Be As Hard As It Is

cabforward.com

84 pointsbluedevil2k92 comments

Maybe I'm coming at this from a different perspective as I've spent a number of years doing that whole "NINJAS BUILD FROM SRC.TAR" thing, but installing Rails under Mac has always been pretty straight forward. Get RVM > Get Ruby Version X > RubyGems > Rails > then fork off for databases if I want something fancy.

You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe. Do you want to replace the default Ruby setup, which could potentially be used by something? Do you want to install new database servers? Do you want to modify Apache? Do you want to fiddle with SSH key gens? Do you want to have to delve in and change items of your .bash_profile? Do you trust an automated installer to be able to do it reliably on every single machine?

I'm not sure I'd have the confidence in something not going wrong and then sitting there with a half broken machine wondering what. At least this way at every step you can do the install > check & verify > confirm steps and make sure it's all business as normal.

>You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe.

I don't think it inherently require anything like that for _installing_.

There is essential complexity (e.g the complexity of developing a RoR app), and accidental, inessential, complexity.

Installation not being a one click / command process is inessential complexity. It's just that the people involved (and the people NOT involved) have failed to make it any better.

For example, one can install Apache/PHP/MySQL on a Mac in a single package in 1 minute (via MAMP).

The php interpreter isn't used by system processes. I'm not sure how essential the stock Ruby interpreter, but I know that on Linux the system Perl & Python interpreters are used by system processes and upgrading them could potentially break things.

OS X Server uses both PHP and Ruby. From my Lion Server:

    jtm@vertex ~ $ find /usr/share -iname *.php | wc -l
         165
    jtm@vertex ~ $ find /usr/share -iname *.rb | wc -l
        5855

Even if you don't use OS X Server, Ruby.framework has been part of the API since Leopard [1], so applications can (and do) depend on it.

[1] https://developer.apple.com/library/mac/#documentation/MacOS...

  > [...] accidental, inessential, complexity [...]

Sure, but when that complexity is so utterly minuscule, what's the point in shielding users from it? Especially when you could argue that it benefits the user who will, at the very least, roughly know what's powering his application?

> You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe.

Well the default installation shouldn't. The default installation should be for someone who just wants to try Ruby out, that will just set things up to work, and won't interfere with anything else on the system (except for integrating with the webserver you're using). Like PHP does. Then they can mess around with Ruby, and as they learn about it, go back and change the installation or re-install as necessary.

> Do you trust an automated installer to be able to do it reliably on every single machine?

Well, yeah. Isn't that what installers are for? They're written by the team that developed the software. I assume they have a much better idea of how to properly install it than I do!

But is RVM really that hard? If you are on a major distribution of Linux or OSX, all you have to do is install the dependencies and then copy and paste the bash command that setups up RVM.

The hangup is usually installing the dependencies. I remember on Ubuntu this involved hunting down one library that wasn't listed on the RVM wiki. Maybe that needs to be fixed with either more documentation on the RVM wiki or a Ubuntu RVM package (that package probably already exists).

On OS X it requires getting GCC to work, again maybe that needs to be clearer on the RVM wiki.

On windows - well on windows I just install a Ubuntu VM and go back to that installation.

But fixing those simple things (documentation, possibly RVM package) is far easier than creating a whole new installation process.

I agree that there must be a better way, but I need to point it out.

Ruby does come with Mac. Ruby is not Rails. The default installation allows anyone to try Ruby.

Sure, and if it's nicely sandboxed away and running in a bubble then it's perfect, if however it requires hooks into the system, which is the current paradigm, then they can't cover all cases. What if you have a custom bash profile and it kills it? Or some mix of packages throws a curve ball? At the end of the day you should know your system and requirements more than a faraway team, which reduces the risk.

As someone who has just begun to learn to program (I finished JS lessons on Codecademy two weeks ago), I could attest that the Rails installation was quite daunting. Had I read about the "straight-forward" path you mentioned back then, I'd have just seen "Get acronym > which version of Ruby > What is a gem > Rails > what the hell is fork ".The last thing I want when trying out a new language is to be presented a smorgasbord of options that showcases language's capabilities, but all of which I have little understanding of.

I see this process somewhat analogous to learning a new musical instrument, like a violin. A professional violinist may care to customize many aspects of the instrument to meet his or her needs, including the turning of the instrument (perhaps he cares to set A to 416 to emulate Baroque turning). A beginner, by contrast, would just like to be handed a well tuned instrument ready to learn and experiment. Now, would it kill that beginner to set and tune his own set of strings, or maybe given the options to set his violin to Baroque turning as well? Certainly not - though the necessity and benefits of such an exercise would surely be lost on many beginners.

There's many different ways to install Rails and those will always be available whether someone creates an installer or not as long as source code is available. However, there is a combination of Ruby, Rails, and the database choices that serve as its backend which are common for the "Make a new Rails app and ship to Heroku" workflow that should be easier for being so popular.

I'm really surprised Rails isn't just another component in the Heroku toolbelt. The default Ruby version in OS X is always outdated, the database preferred by Heroku (postgres) is also outdated in OS X, and getting the latest XCode or re-installing it to install brew to install postgres and changing the order of execution in the PATH to make sure it picks up the right version is a prescription for despair and angst. RVM only solves the Ruby and gem versioning problem.

Yehuda Katz is working on a Mac app that sets Rails up on a Mac: http://www.kickstarter.com/projects/1397300529/railsapp

Also see this relevant (and relatively recent) update on the project: http://yehudakatz.com/2012/06/05/tokaido-status-update-imple...

Far too high a proportion of the questions in #ruby are about installation.

Often people come in having (naturally) tried to install it from their distro's package manager. First we have to explain to them why this is a bad idea and persuade them to remove it. Then, often they have tried to install it from source, passing some fucked up value to --prefix, and they have to be helped to clean that mess up.

Then we tell them to use rvm, but someone pipes up about rbenv and friends and we have to explain the differences. Then it turns out that they didn't have openssl-dev or something installed so they have to recompile ruby again, or someone has to try and remember the magic spell to compile the openssl bit of ruby separately, which nobody ever can.

THEN it turns out that all they want to do with ruby is run redmine, which has some other specific requirements that nobody in the channel knows or cares about.

Basically, when yehuda katz finishes that project of his, freenode will be measurably happier, although the problems with OS packages will remain, I imagine forever.

The real root of the problem is that a lot of the things which make the ruby ecosystem highly dysfunctional are the same things that make it so great. Primarily the fast pace.

I use and love Ruby every day, but this package management business is ... irksome. First the Ruby guys crapped all over package management from Debian, who, despite their shortcomings, have been doing it a while and know a thing or two about it. That wasn't entirely unfounded, because there were some messy things there, and the intersection of two different package management systems is bound to be a bit confused.

Now we have rvm's and gemsets and bundles and additionally people trying to foist off alternatives to some of these, and the whole thing is beginning to look like an unholy mess.

Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does.

Until you have more than one app running on the same machine with different dependencies... like say on a development machine. This is the point when bundling shines, because it elevates you off of the os-level dependencies.

A properly done OS can handle more than one version of a library at the same time.

Also, it's a good idea to use a development environment that's not too far from what you're running in production.

> Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does.

But what it does moves at about 10% of the speed of the ruby community (at least post-Rails). I'm not saying that the ruby culture is better—it obviously has serious consequences for stability and leads to all manner of headaches. However it does mean that if a new and better idea of how to do something comes out, Ruby is probably one of the first places you can use it in production.

My feeling is that the benefits outweigh the costs if and only if you are a full-time developer in a paradigm that Ruby is good for (eg. traditional web development). If you are just dabbling in the language then Ruby will continuously pull the rug out from under you. And if you are just trying to install some software as an end-user, then Ruby is probably one of the worst possible platforms.

I didn't meant to say that Ruby should use Debian package management or anything like that: it needs its own stuff at its own speed. More that they should be a bit slower on the draw when it comes to pissing on other people's work.

Agreed that the subset of the community with no respect for the Debian process showed the worst sort of young hipster developer arrogance.

Surely bundler helps solve some of these problems; at least it makes managing gems easier on a per-app basis.

And then you try and deploy it:

http://serverfault.com/questions/405994/state-of-the-art-dep...

And you're either stuck with this Mongrel-derived nonsense that is incapable of utilizing the computing power of the server to dynamically (de)allocate resources, requiring you to pick numbers at setup time, or you've got Passenger, which gets that right, but basically nails your deployment to one and only one Ruby.

(Yes, I've not had the best of days...does it show?)

It does, yes. And, to be fair, bundler has caused me a number of headaches over the years.

I guess I'm lucky in that I only need one Ruby; I can't see an easy solution for using more than one at once.

    $ /usr/bin/ruby -e "$(/usr/bin/curl -fksSL http://bit.ly/HyK0NG)

That looks terrifying.

Too often you see advice like that. And this is supposed to be from technical users who know about security. And we wonder why mundanes click on spyware scams…

How is it any different from downloading any other code and running it?

Are you saying you audit every piece of unsigned code you run?

I admit that putting bit.ly into the chain of trust is quite a bold step, but is it really that different to, say, the rubygems server? Or your wireless router?

EDIT: also, LOL at "mundanes."

Imagine Bit.ly gets backdoored, and that shortlink is repointed at a script that just contains rm -rf /

Imagine your wifi box gets backdoored.

Imagine your ISP's router gets backdoored.

Imagine if the server you got your bash from gets backdoored.

Imagine if the rails repo gets backdoored.

Imagine if the plant where apple images the macbook HDDs gets backdoored.

Imagine all the people, living for today...

(But yeah, personally, I'd forgo the bit.ly part as its unnecessary.)

I could also imagine that someone wired up my car to explode, but there's a reasonable level of paranoia. Link shorteners are fairly frequently used to hide the true destination of a link.

Although, I wonder how hard it would be to set up some text with CSS that looks like one string, but is actually another. e.g. the user would see

    https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb

but when copied-and-pasted is revealed to actually be something like

    https://raw.github.com/mxel/homebrew/master/Library/Contributions/install_homebrew.rb

Or even better, the Lybian goverment siezes it.

Libya has traditionally been known as an incredibly corrupt regime, but since Ghaddafi is gone, who knows how things are run these days. My guess is, like it was before they gave him the boot, if you slip the right guy some cash, you can change that link all you want. Might be a different guy though, probably closer to the source, and the price is likely to be a lot lower now that there are less beaks to wet.

You can open it up in web browser and view the code. Goes right here: https://raw.github.com/mxcl/homebrew/master/Library/Contribu.... I'm not sure how it could be more transparent.

You can check checksums. You can use a package manager which has been gpg signed and reviewed by people smarter than you. You could download it over https.

You're downloading and running in one go. If someone puts a badfile up for 1 minute, then restore it to normal, and you get hosed, it's pretty hard to check that, because the download link looks fine now. You cannot try to figure out what happened or who did it to try to track down the culprit.

Checksums are only for transmission errors. If someone can change the code, they can change the checksum.

Indeed, using signed code is massively preferable, and it is increasingly common.

I was about to write that you can't operate running only signed code, but if you consider git hashes a form of signing then I suppose you largely can these days. However, running unsigned code is still so common that I don't think you can really single out people who pipe curl into sh.

I appreciate the feedback, but you posted that line out of context. I did not simply provide a shortened URL without any explanation. I linked to the official Homebrew installation instructions, and provided the full URL that my bit.ly link resolves to. I also included a screenshot of the command being run with the full original URL.

What else would you suggest I do to make it less terrifying?

I am not sure installing a full stack web framework, a version control system, and automated deployment to public hosting should be _that_ easy. Learning how to install it all is very informative as to what is going on.

e.g. Deploying to Heroku is in fact very easy. Ok you have to mess around with ssh keys, but you don't want that to be automagic - you want to have some understanding of why what you are doing is secure, and why anyone else can't access your code.

If you want it to replace php (or anything), it has to be as accessible as php for the same developer.

Until then, all the conversation about standards, best practices, and tutorials are far less accessible.

The purpose of Rails isn't to replace PHP.

It might not be, but our Rails heads sure do like talking about PHP a lot.

If a technology is truly supposed to be accessible it needs to actually, be accessible instead of carrying an air of superiority, otherwise software continues to suffer.

Rails isn't supposed to be accessible the way PHP is, i.e. built into every shared hosting account with unlimited flexibility as to what you can do with it. If that was the right way to go for web applications, there would have been no need for Rails in the first place, since PHP would have been sufficient.

I'm not sure where it was said PHP is only shared hosting. Besides, many places start on shared hosting, kind of like Heroku for rails code, no?

I'm also not sure where the idea is coming from that Rails shouldn't be accessible to developers. If you have some wider posts or links I'd love to read some more.

Rails is accessible to developers who have a baseline of competence. PHP is accessible to complete beginners.

Again, is that your opinion / preference, or can you share a source? Most interested to see where this is coming from beyond things I could google myself.

My tutorial (http://www.moncefbelyamani.com/how-to-install-xcode-homebrew...) is mentioned in the article, and at the time I wrote it (back in March), those were the steps necessary to install all of those tools.

I published it to help others avoid the pain I went through, and to share what I've learned so far. Given that it has had over 15,000 views so far (mostly search traffic), I'd say it's doing its job.

A few weeks ago, I used my own tutorial to set up a new MacBook Pro, and noticed that the latest version of the Xcode Command Line Tools and Homebrew seem to play well now. Originally, the separate CLT download from Apple and Kenneth Reitz's osx-gcc-installer resulted in errors when installing Homebrew, but I'm planning on trying them again soon and updating my tutorial with my findings.

I'm also planning on evaluating the new RailsInstaller for Mac, but when starting out, I recommend learning the hard way to understand what each tool does and to pick up some basic command line skills.

I'm coming from a Windows world, where installing Rails and all the tools is as easy as hitting up RailsInstaller.org, downloading an .exe file, and having my environment set up in a few minutes.

Uh, what? http://railsinstaller.org/ has a Mac version too!

It's right on their home page (if you're browsing from a Mac; it shows you the Windows version if you're browsing from Windows...)

https://github.com/downloads/railsinstaller/railsinstaller-n...

That's new. They just announced the Mac OS X version on June 1st: http://www.engineyard.com/blog/2012/railsinstaller-for-os-x/

Doing ruby dev in a VM is pretty nice for some things, and terrible for others. In general, I think VM's are great if you have a team and need to get environments setup that work on any machine (windows/mac/linux). Where it falls flat is in some weird places like if you want to use Guard for automatic file change actions. Otherwise, it's pretty awesome.

If I'm working on my own projects tho, running ruby local on OS X is the way to go. Much less overhead.

I think this is partly why so many of my Mac-using colleagues have a Linux VM for doing development; every programming-type task I tried to do on my Mac was an exercise in frustration. At least there's finally a set of command-line compilers you can get without having to download XCode (it's free, once you pay $99 to become a developer! I thought I already was a developer, which is why I want compilers...)

Personally, I just installed Arch Linux on my Air. With the SSD, it boots in seconds, even on an encrypted root. I can use whatever window manager I want, and all the tools I need for work are there or easily accessible. No hoops, no tricks, no outsmarting the operating system.

XCode is free without paying $99 for anything, and I don't remember a time when gcc and friends were not available for OS X.

There's a free 200MB download of the command line build utilities. Xcode proper (4+ GB) is also free ...

I was unable to find free versions of either of these, for Snow Leopard, when I looked a year ago. At that time, Lion was utterly unusable (not sure if it's any better), so I just gave up and got a Linux VM for that laptop.

https://developer.apple.com/downloads/

Requires sign in, but free otherwise.

> Installing Rails on a Mac Shouldn't Be As Hard As It Is (cabforward.com)

1. Editorialized headline

2. It's easier than this article-- you don't have to install XCode: https://github.com/kennethreitz/osx-gcc-installer/

3. There are some smart folks working hard to make it easier: http://www.kickstarter.com/projects/1397300529/railsapp

>1. Editorialized headline

And we should care because?

The article is fine, the headline is correct (even if editorialized), and it can potentially save new users some time.

I believe the author's headline is justified within the article:

"I'm coming from a Windows world, where installing Rails and all the tools is as easy as hitting up RailsInstaller.org, downloading an .exe file, and having my environment set up in a few minutes."

The author points to my article: http://railsapps.github.com/installing-rails.html

I titled my article "Read This Before Installing Rails" because Rails is not just a Ruby gem, it is a complex and rapidly evolving ecosystem. Sure, if you want to see Rails running on your Mac you can use the installed system Ruby 1.8.7 and "gem install rails". But if you want to do development, you'll need to update (and keep updated) all the related gems and packages that are an essential part of the Rails habitat. Judging from the comments and help requests I see, that's not easy.

Packages such as RailsInstaller, Cinderella or the BitNami RubyStack are great but they inevitably slip further and further behind the evolving state of the Rails ecosystem. I'm hoping the design of Yehuda Katz's Tokaido will avoid this issue. In the meantime, yes, it's difficult to install (and keep current) a useful and fully functioning Rails development environment on a Mac (or any other machine!). I say that from the experience of attempting to keep my "Installing Rails" article current.

For example, would you like to develop using Ruby 1.9.3 (the current recommended version) and deploy to Heroku (which now supports Ruby 1.9.3)? You'll need to update to the unreleased 1.2.0.pre.1 bundler (which requires a "gem uninstall" not a "gem update"). That's true today. Maybe it'll change tomorrow.

A rapidly evolving ecosystem is not a bad thing. Rails is a powerful, widely used, and well-supported development platform. The constant changes bring increased utility. If you can keep up and find the right advice. The author's article is sound and offers some of that good advice.

  user@brand-new-mac $ which rails
  /usr/bin/rails

What? OSX has shipped with (some version of) Rails since Leopard. You don't need to install a compiler or compile anything to use Rails on a Mac. It comes with sqlite3, too.

    $ /usr/bin/rails
    Rails is not currently installed on this system. To get the latest version, simply type:
    
        $ sudo gem install rails
    
    You can then rerun your "rails" command.

> The basic database program that Rails uses is SQLLite3, and you will need to install this to work with it.

yet Tiger had sqlite3 already.

What's more, Ruby is installed already. One can 'gem install rails' and have the latest version landing in /Library/Ruby/Gems

Added bonus: running sudo gem install rails spins for 20 minutes then dies with some cryptic error message.

At least that was what happened when I tried to install rails on my brand new macbook air.

To be fair though, open source software hates me. This has been pretty much the same experience I've had every single time I've tried to install anything with gem install, apt get or yum install. On every flavor of linux/unix on any box I've ever touched.

While this is technically true, it's important to note that it's not usually desired.

You should be running a fairly recent version to keep up with patches or match your server, you should be running RVM so you can keep a gemset and use bundler, and you should use homebrew to make installing other packages easier.

Not that any of that is difficult, and you're right to a degree: you can get started learning using one command and go from there.

It's really not that complicated.

Unless you're planning to deploy to a production server running OS X, I don't see why you'd care about Rails running natively on your Mac.

Why not develop against a VM running the same OS as your server?

What if you'd like to develop a gem not for any specific platform? What if you want to develop desktop apps, or make CLI apps to automate little things on your usual platform?

Well, yeah, that's almost a truism: if your app needs to run on OS X, then it needs to run on OS X.

I think very few Rails apps need to run on OS X, however.

I guess it just depends on the target. For starting out serious development I'd certainly agree with all you say, although I personally prefer the local development and tests on staging method, since it means I know it runs on at least two systems, at least with the code where it's possible. It might be nicer for beginners though to be able to quickly dive in.

Why on earth should you have to run a VM in order to run a programming language?

This hasn't solved the problem of Ruby being difficult to install, it's just added ANOTHER problem of having to learn to install a VM manager and a whole new OS, plus using up far more system resources. Seems to me like that's just making things worse.

Why on earth should you have to recreate your sever stack on a desktop OS? Seems like you're just begging to be bitten by some OS-specific bug or quirk.

It solves the problem of Rails being hard to install on OS X... because it obviates the need to install Rails on OS X. And there's no new OS to learn -- the VM runs the same thing as your server. If you don't know how to use the OS that's running on your production server, that's a bigger problem.

I've been developing this way for years. Additional benefits include: you can easily have multiple VMs with different configurations, you can snapshot/backup/restore a VM very easily, crashing a VM doesn't crash your computer, and it's relatively easy to share a fully configured VM with another developer (even if their primary OS is something totally different).

I see it as being a bit like moving to a service-oriented architecture. When you're just getting started it adds overhead, but by the time you get to your 5th developer or platform-dependent bug (hello HFS case-insensitivity bugs!), maintaining a VM image starts to make a ton of sense.

Similarly, when you start a new web app, of course a monolithic framework like Rails is great and is flexible enough to roll in all your business logic. Somewhere around 50k lines though, you start getting that ball of mud feeling and managing changes across the entire code base starts to become onerous. At that point you realize the sysadmin overhead, and cost of defining and maintaining slow-moving services interfaces allows you to turn your ten-person team into ten ten-person teams and get a reasonable productivity multiple out of the deal.

It's not about running a programming language. It's about assuring that the code you write will run properly on the target it's deployed to. Assumptions that are made on the basis of the development platform (that are external to the programming language itself) will not necessarily be true on the deployment environment and can (and often do) result in bugs that can't be replicated easily between the two environments and can often be difficult to track down.

As a non-developer who has tried several times to learn, I can say with 100% confidence that setting up a dev environment and workflow is fucking maddening.

It's a major barrier to learning and I hate that it's as complex as it is. Should be turn-key.

The thing is though, you need to be familiar the tools involved with installing the system in order to use the system. It might present a bit of a learning curve up front, but I think you'll be better off.

Now try installing rails on a windows machine; that's the real pain in the ass.

Have you tried RubyStack (http://bitnami.org/stack/rubystack) In addition to Ruby runtime + Rails we include many of those components mentioined above such as SQLite, RVM, MySQL. Free and self-contained (so if you don't like it you can simply remove the installation directory) It works the same across Windows, Linux, OS X

I got frustrated with this as well and decided to make it easier. Here is my solution:

http://up.jenius.me

i found this article very encouraging. first i started developing on a windows 7 machine, before "railsinstaller.exe" was around. It was a pain to setup. soon after i was able to get my hands on a mac. still being pretty new to rails it was a whole new world of learning; git, ssh, .bash_profile, unix commands, figuring out gemsets on rvm, why one rails app would install rmagick, but another would error out, what the hell is GCC?

working through these things was a huge help and eye opening experience for me. being new to OOP and web app development it seems like there is a never ending list of things to learn, and everyone out there with their computer science degree has the knowledge already that i am missing. so i guess it is encouraging to see a list of things that this "engineyard training provider" is struggling with, and i worked through it all and have a pretty good grasp on now.

Try this - https://github.com/kelsmj/macsetup

It shouldn't be, but try on Linux...it's even worst than on Mac. That's why I made this 35 page tutorial: http://www.mirceagoia.com/2011/11/ruby-on-rails-installation...

Wow, this is somewhat ridiculous. I just clean installed Lion on my MBP. Installed Xcode form MAS, installed the Xcode command line tools (in the prefs), and ran curl -L https://get.rvm.io | bash -s stable --rails. Done.

Installing Rails and most everything else was simple for me. Getting mysql hooked up proved to be much more troublesome. Especially with MAMP installed already. I wish it would install in a contained package and not mess with anything else.

Is nobody worried that this developer wonders out loud why he can't re-use his GitHub key with Heroku? Basic knowledge seems missing.

How about https://github.com/thoughtbot/laptop

I'm pretty happy with vagrant images.

Ultimately, putting your dev environment on a server image makes way more sense.

I thought the Rails install process couldn't be easier, and I don't even like Rails... ducks

I love cinderella:

http://www.atmos.org/cinderella/

For Postgres, I really recommend postgresapp.com.

Only works if you downgrade from SL to Lion though.

I've used Postgres.app recently on Lion. What problem did you have?

Lion is the problem I have.

This is very helpful

Your first mistake is installing Rails. You're second mistake is attempting to do so on your development machine and not in a jail or vm.

Not sure why you'd recommend installing Rails in a VM? It's a framework, not an environment.

You want development to match production as closely as possible, otherwise you're setting yourself up for nasty surprises down the line.

I found using a staging environment that is a clone of production to trump developing in a vm. All code goes through staging before production so there is no surprises

No, you want testing to match production as closely as possible.

Much of the time, development can be done in all sorts of ways that needs little connection to the final production environment.

DHH, the creator of Rails, and the team at 37 Signals (the company behind it), install Rails on their development machines, (with Pow: http://pow.cx/ ).

Reply on news.ycombinator.com