The IDE is the first step. Our vision is to provide a set of tools so that your runtime is on the cloud (but can be sync'ed offline) and you can use whatever editor that you're most comfortable with.
I see it as they made an early exit and focused on the half of their system that seemed more promising income-wise. There is still a space for the all-in-one market, and frankly it's wide open. Environment + IDE + Deployment in one place definitely has a niche.
Wow, I'm very impressed. There is definitely a killer app for this, and that is Windows rails development. While it's better than it used to be, it's still far from ideal, and time consuming to set up. Love the idea of being able to use a consistent environment across multiple platforms. Great job; looking forward to playing with this!
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.
As long as you choose an availability zone that is closest to you when setting up the box, the latency will be minimal. In our experience with using Vim on our boxes, it was not a big problem. Emacs will run just as fine! (We aren't taking sides, I used Emacs a lot when I was doing Scheme.)
Hm. This is one of the rare times where a product actually does too much for me. If it gave me the ability to build and manage virtual envs for testing and development with ssh access (and maybe the ability to download them in say... vagrant box format) and nothing more, I would be sold immediately.
Creator of Vagrant here. Disclaimer that any of the comments I say following are my own opinion and do not reflect what the action.io team is thinking.
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. :)
Saw the initial tweet, but I did not see the discussion. Vagrant integration would be great, as I am traveling frequently and need my offline dev environment.
At the risk of being negative, I'm really sick of Show HN entries that go to a page where you can signup to a 'early access' mailing list but not actually get into the product and use it.
What exactly do you have to show besides the marketing?
The technology looks awesome but is this a pain point for people? I like developing on my local machine. Setting up an environment can be a pain but I only have to do it once. After that I forget about it.
Also, it worries me to depend on a third party service and my Internet connection to get work done.
The initial version of the platform will be really helpful to beginners, designers, and anyone who's a bit allergic to the command line.
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.
I really like what you have done. Having transitioned from a Windows/Visual Studio .NET application development environment to an OS X and Rails development environment within the last year, this would have been very useful.
This looks awesome. Congrats. Just wondering, why do you pick browser as the IDE? (as a background, I've been developing iPad IDE called Worqshop).
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
For those saying this isn't solving a serious problem: my colleagues and I have just spent weeks trying to get a reliable recipe for a Vagrant dev environment that encompasses our interesting (and in some cases a bit old) Rails-based tech. stack.
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.
It looks really interesting, but one of the things I like about standard Rails dev work is I can work offline fairly easily. Mostly this a weird 'I have a really long commute' thing, so I will be keeping an eye on this.
Yeah-- we're working on a solution for this, so stay tuned. We're thinking that dev ops drudge work is going to go the way of sys admin (thanks to heroku).
60 seconds?! It took me at least 10 seconds of looking for a 60-second thing to work out that the shortest one of the things you can see that has some meaning is almost five minutes long. Am I missing something??
I just filled out a survey they emailed me and the thing I indicated as being most important was an online development system to support remote pair programming using tech like Apache Wave or Etherpad.
I really like what you've done. Personally, not for me, I prefer programming locally using emacs, but I think it'll be great for lots of people, it also looks good, nice design :)
I'll be sold when they give me access :) Seriously though, I have an old Laptop that I still keep around mainly because rails is "set up right" for some of my older projects
Serious question from Python-land, that I think may illuminate the difference in mindset.
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.
This is their first iteration. For a simple Rails app, setting up Ubuntu an RDBMS and Redis is trivial, thats true.
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.
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.
>Rails became a much better community citizen over the last few years.
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.
Going slightly off point, but I'm not sure what makes Puppet and Chef (two projects written in Ruby - Chef in particular whose configuration language is pure Ruby code) "non-Ruby deployment tools", versus Capistrano and Vlad, which I presume are being referred to as the "Ruby" counterparts to the others' non-Ruby distinction.
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.
This is of course offtopic but I meet lot of people who think Chef/Puppet are not written in Ruby. There is something in wanting to talk about a tool without actually using it.
I'd be a lot happier if it was all client-side. I use Vagrant for all my projects. It's still a pain in the ass and I'd pay good money for a simple drop-in replacement for Vagrant that bundles everything up (DBMS, Ruby, Gems, etc.) in a single directory along with my code. Then when I'm done, I just destroy the ... "project"? and it's like it was never on my box.
Vagrant provides that for me today but it's still difficult and annoying to deal with.
Don't get me wrong. I <3 Vagrant. I use it all the time and for every project. My new MacBook Air is as pristine as the day I got it. But, Vagrant is not the ultimate solution for me. I don't think it exists, of course. My wish list is too long but...
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.
Wow...I can't believe this comment is the first in the thread.
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.
'...web framework that's optimized for programmer happiness...' says it all right there, doesn't it? You know what makes me a happy programmer? Building things, not mucking about with setting up a new dev environment (and filling my machine with crap) every time I hop on a new client project. Make the 'trivial' shit go away so I can focus on the fun/interesting/creative/productive stuff...sounds good to me. I'm very interested in a product like this where I can configure on the fly and keep my machine uncluttered. (seriously, it just feels gross to have 6 different versions of rails and 4 different rubies installed on my machine, even if RVM makes it kinda easy)
>Why are Rails people so obsessed with accelerating the trivial?
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 am from the Rails-land, but I think what action.io is solving is something that all developers face in general - setting up a local development environment is a pain. Think about it, you cannot easily have multiple Ruby versions in your own local box. Or even having multiple versions of databases in my own local machine is a pain. A lot of people ended up running virtual machines just to have different server configurations. I think action.io does it nicely to solve this problem.
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.
> 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.
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.
Rails volken: Do yourselves a favor, stop promoting stuff like this. It makes you look like Baby's First Web App.
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)"
>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.
Using the query string to bust cache and replacing your assets on deploy is the simple solution that Rails' asset pipeline replaces.
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.
> 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!
> Why are Rails people so obsessed with accelerating the trivial?
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.
