Show HN: Action.io - 0 to Rails in 60 seconds in your browser

HN is not about technical purity...it's about hackers getting shit done.

You may think that getting a 'vanilla' Rails App deployed to the cloud and being able to do editing in your browser is trivial - because you have invested a ton of work in your own setup and you are entitled to that.

But when did HN become a place where on the thread announcing a major achievement - the shipping of what seems like a damn good product, that may solve a pain point for many people - people are shitting all over it because of some language/community war? Really?

I am a Rails developer, sure...I may not have as much experience as you do building web apps or even programming, but anything that removes the friction of me getting a product out the door is perfect.

While I can't say I would necessarily pay for this immediately, but I can see it having immense value.

As someone that has wrestled with getting Rails setup on various operating systems for people that aren't Rails developers but need access to the source, like a front-end dev that only uses Windows for instance, having something like this is pretty awesome.

I can just push my app here and the front-end dev can edit the code in the browser....without having to worry about installing Rails (or even having the app installed) locally.

I am sure many other people think that this looks like an awesome product - hence the many upvotes.

I just don't understand how this comment got so much attention and how, after scrolling through many replies, I haven't seen someone address this issue.

This is HN. Hacker News. For Hackers. By Hackers.

Not Ruby land. Not Python land. Not Computer Science land. Sure, we all talk about those stuff.

But our #1 focus is on people that get shit done.

These guys have done so.

Congrats. The product looks kick-ass.

I await my trial.

2) Minimizes dependencies. Adding chef cookbook servers, apt-get, etc. into the mix is another point of failure.

3) Is scalable/reusable. Most people/companies have multiple projects they work on and much of the vagrant/(chef|puppet) architecture doesn't easily support diverse workloads (this project needs recipes x,y,z, this one needs a,b,x,y; this server runs ubuntu 10.10, the other 10.04)

4) Is all integrated. Sure, I can use some combination of chef, chef-knife, and chef-librarian but they don't work together in my project. Someone can check in a new project setting and unless I run vagrant up, it'll continue to run happily. I want something like bundler that will fail to run unless I'm all up to date, and is unified into a single package.

Given those restrictions, here's what bothers me about the vagrant ecosystem (they're not really complaints about Vagrant per-se but the state of dev virtualization):

1) Every project I get needs a VM (unless I want to start installing stuff locally). This increases the amount of time it takes to get a project up and running. Yes, in the long run it pays off, but can be a barrier to entry for "I just want to fork a project for a quick bug fix".

2) VirtualBox building is slow, takes forever, and requires gobs of disk space. If I have 4 projects, it seems I need a separate vbox for each one. Now I've got GBs of files littering my filesystem. I'd kill for dedupe.

3) Chef / Puppet recipes are one-size-fits-all, and to change them requires adding a whole lot of infrastructure. Sure, you can embed them in your project (chef-solo), but then that's not very reusable.

So you can set up your own chef cookbook server, but then it's another moving part that can fail and then no one can provision new VMs. Bleh. We've gone with symlinking our own cookbook repo into our projects. That's suboptimal but avoids a whole lot of yak shaving.

What I'd like are more extensible cookbooks that have per-project configuration. Yes, they often have some configurable values, but occasionally I want to use a cookbook but it's got some strange version of a lib in there that is incredibly out of date that I can't change.