Show HN: Action.io - 0 to Rails in 60 seconds in your browser
action.io
action.io
One question though, is there delay when typing in the browser as there normally is when you ssh into a box? That kinda drives me up the walls, and I am an emacs person.
in case you are travelling...
It doesn't matter for chat, but for serious coding it would be absolutely infuriating.
With the glossy IDE finish: not my thing :/.
I'm very excited about the possibilities that action.io provides. Additionally, I think integration between the two would be the best of both worlds, providing a CLI based interface and possibly non-web based development through my virtualization providers (VirtualBox for now, many more coming soon), as well as web-based development should you want it using the fantastic tools that action.io is building.
We'll talk and see if we can come to a mutual agreement/vision. :)
P.S. Here's what Mitch (creator of Vagrant) has to say about action.io: https://twitter.com/mitchellh/status/215491864080547840
Thanks for the info!
"Winamp… It really whips the llama's ass!"
However I'm almost sure I don't want my Vim and terminals in the browser, there surely will be all sorts of quirks with copy/paste etc.
Can the remote filesystem be mounted so that we can just hack with our local terminals and editors?
PS. Why not: on console focus-loss -> file browser auto refresh
What exactly do you have to show besides the marketing?
Also, it worries me to depend on a third party service and my Internet connection to get work done.
We're working on some great collaboration features and sandboxing that will definitely make it useful for power users. We've also got a solution that we're working on that will allow offline development so you can use native editors and can work offline. Stay tuned.
It's an honest question. How does the IDE perform using the iPad Safari? I thought about doing web-based IDE but found the performance very slow in my testing. Ultimately, it boils down to native vs web apps.
Nevertheless, kudos to you. I know that doing front-end web UI, dealing with AWS, and provisioning the boxes, are not trivial problems.
Edit: Just to preempt, yes, I know my app restricts developers to use iPad :)
Ups... reading the comments below... you will be providing SSH access to the VMs
If we were starting again from scratch, we'd pretty much all agree to outsource most stuff: use Heroku, GitHub, etc. And there are several people intersted in Action.io now too.
That little tidbit made my day!
yes please.
Why are Rails people so obsessed with accelerating the trivial?
I mean, the other end of the spectrum is to be focused purely on the obscure and utterly advanced, like category theorists trying to harness Haskell.
I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Python stand for themselves while they advance of the state of the art for the work-a-day programmer. (The middle of the proverbial road)
Meanwhile, we've got Rails (and I mean this separately of Ruby. The non-Rails Ruby community is much more like the rest of us) at one end of the spectrum, and Haskell/Clean/etc. at the other.
What the hell?
The point is that managing 5 Rails apps, one on Mysql, two on Postgres, two on CouchDB, one with Redis, one with Memcached... (and so on so forth) gets non-trivial soon if you don't grow beyond managing it all on your development machine.[1] Suddenly, all that trivial development stuff becomes a question of configuration management.
What the Ruby community understands is that trivial things can pile up into something non-trivial. This is why Heroku solves a trivial problem (deploying a process on some defined environment using git) and takes it to a big scale. Github does the same for repositories (arguably one of the "trivial" tasks for sysadmins) and provides it for a good amount of money. All those services started in the Ruby community for a reason. We love the mundane, as everything else is based on that.
[1] Alternatively, if you are not consulting, multiply the trivial problem by 20 developers and a growing code-base.
I just got done proselytizing the benefits of automation.
I'm not arguing against myself. I'm concerned with why everything Rails people promote and celebrate seems to be along the lines of what originally popularized the framework.
"Make a blog in 15 minutes!" --- you remember this one? Were you programming back then? It's exemplary of what I'm talking about.
Why are they accelerating the trivial? How many times do you really need to deploy a vanilla Rails app over and over in 1,000 different ways? There's much more to deployment than that, and if that's all your needs are, then there isn't much to say.
We should be learning new and advanced ways to manage complexity with Capistrano or Vlad the Deployer or some non-Ruby deployment tool like Puppet, CFEngine, or Chef.
Partly because they can help deal with things other than just the Rails app itself, which is the easy part generally speaking.
Actually: Yes. I was even programming Ruby before that, after it won in a flip-coin-contest against Python. :)
We might be on the same page here, but with different mindsets: http://news.ycombinator.com/item?id=4138088
I am a happy Puppet/Vagrant-user and would give away a substantial amount of money for a build/management/hosting-service for all that. Still, you need a hook, and the (in)famous 15-minute-blog was a tremendous hook, as is a "setup a clean dev env in 2 minutes". Immediate usage is the greatest hook you can get. I remember using frameworks where the setup took hours and was closely bound to the machine you were using unless you built your own tooling on top of the whole thing.
Also: there is a lot of stuff around in the Ruby world that can advances the state of the community as you say, even by salvaging Rails. I have not written a Rails App in around 2 years, yet I constantly use parts of it. Rails became a much better community citizen over the last few years.
If the 15-minute-hookiness is all you complain about: well, let them have it, if its fun :). I don't care about it a lot, but it is fun to get started.
That much I've noticed. A lot of Sinatra/Generic-rack-blah users have been successfully pirating various chunks of functionality from the Rails community. I'm thankful for that.
If you're talking about what they deploy, rather than what they're written in, neither Capistrano nor Vlad are in any way limited to deploying Ruby. Capistrano has a few minor built-in niceties for deploying Rails (basically a few pre-written tasks so you don't have to write them yourself) but it's no less applicable to deploying other projects.
Capistrano used to be a lot more Rails-centric than it is now.
I was referring to the predominant cultures/environments they handle. Chef/Puppet/CFEngine are more ecumenical even if Chef/Vagrant/rails is popular.
Vagrant provides that for me today but it's still difficult and annoying to deal with.
I want something that: 1) Runs completely locally. I want to be able to work offline, on a plane, whatever without needing remote resources.
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.
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.
I believe Mitchell is going to talk to the action.io folks about possible collaboration.
That's easy. That's a false dichotomy. This isn't a deeply held cultural value.
>I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Python stand for themselves while they advance of the state of the art for the work-a-day programmer.
It is a Ruby cultural value that There's More Than One Way To Do It, and that shiny things are worth chasing.
That said, I laugh in the face of your "Python cleanliness".
I think action.io is going to help a lot in the case of trying out the latest versions of a framework before migration. Want to try out Rails 3.2 + Ruby 1.9 when you are on Rails 2 + Ruby 1.8? I do not have to mess around my local config. I see action.io allowing me to just create a dev environment instantly for me to try out.
I see huge benefits in the open-source community tool. There are so many different open-source projects out there, but the last thing I want to do is to spend 30min (or more) messing with my local development environment just to try out and play around with a open source project.
Cool stuff man.
rvm 1.9.3
gem install rails
Though this project is interesting, it's not really going to make much of a dent in my daily workflow. There is a metric shit-ton of work being put into things that do. Over the past few years:
* The Rails queuing API (so you all queuing methods e.g. via Resque or DelayedJob have a common client interface).
* The asset pipeline (css/js concatenation + dependency management, plus precompilation for prod).
* Profoundly, bundler. I dread doing anything without having bundler there to declare, manage and allow me to browse the code of all my dependencies.
So yeah, the stuff that makes the news on HN isn't where the goodies are at in Rails.
> I've always felt the strength of the Python community is that it was able to let the idioms and cleanliness of Python stand for themselves while they advance of the state of the art for the work-a-day programmer.
:%s /Python/Rails/g<CR>
I'd seen the Resque/DelayedJob stuff. The equivalent in Python-land are Celery and Carrot. They're probably not much different.
>* The asset pipeline (css/js concatenation + dependency management, plus precompilation for prod).
Creating defaults for this stuff is definitely cool, but OTOH, it's something we solved at my company with a single bash script ;)
>:%s /Python/Rails/g<CR>
Vim user. Pffffft. ;) All hail the hypno-Emacs!
>it's [action.io] not really going to make much of a dent in my daily workflow
I would hope not. I would think most serious programmers have a pretty smooth/fine-tuned pipeline for "save file, run script, see changes in $SERVER(s)"
I'd expect as much.
> Creating defaults for this stuff is definitely cool, but OTOH, it's something we solved at my company with a single bash script ;
Good for you guys! That's going to be one hell of a bash script though, enjoy maintaining that.
> Vim user. Pffffft. ;) All hail the hypno-Emacs!
Err, OK.
No sense of humor? Oh right, HN.
>Good for you guys! That's going to be one hell of a bash script though, enjoy maintaining that.
Nope. Catenating files has been the privilege of Unix users since the 70s, that we would believe this to be difficult or complicated is embarrassing. The trickier part was sedding the query string that invalidates the old versions.
Rails' asset pipeline doesn't delete old assets. That way you don't get inconsistencies when not all of your servers symlink to the new assets at the same moment.
I'll start laughing when you start being funny.
> Nope. Catenating files has been the privilege of Unix users since the 70s, that we would believe this to be difficult or complicated is embarrassing. The trickier part was sedding the query string that invalidates the old versions.
Ooooh! Colour me embarrassed, you got me there champ!
What about rolling up assets seems so irreducibly complex that you want to rely on a shake-n-bake to get 'er done?
From a Rails beginner perspective...
Having spent days trying to get Rails up and running on a Windows box, this product looks absolutely awesome.
Even the so called out of the box solutions still needs hours of customization. Every new release of Rails means starting from scratch with limited documentation.
Anyone who has struggled with installing Rails on Windows, then finding a decent IDE, installing all the other packages etc etc will appreciate being able to get to that point in 60 seconds via their browser.
I am sure some Rails experts and Mac Users may disagree but getting started in Rails takes a lot of effort.