I first encountered Cloud9 (the IDE, not the professional gamers) a couple years ago, when I was looking for a nice HTML/CSS editor for the students in my Exploring Computer Science course to use on their own laptops. I settled on it because it had good highlighting, didn’t require them to understand anything on the command line, but still focused on raw code as opposed to WYSIWYG stuff.
Since I stopped teaching high school, I hadn’t thought much about it. As a boot camp instructor, it was important to me that I teach my students how to use “real” tools, and so we focused on local tools.
At the moment though, I find myself temporarily without a dev machine, and my mind turned back to Cloud9. I’m mainly working in libraries (hurrah for free access to computers!), and while I can thankfully count on them to have Google Chrome, I can’t count on much else.
So, how can I do some real development without a real dev machine? I started up a new (free) account to find out.
I don’t remember if they had this before, but one of the coolest things about Cloud9 is that my code is running on a machine to which I have actual shell access. It is a necessity when doing any sort of development to be able to work around in the shell.
They support a number of different languages with prebuilt images, including some of my favorites: Django, Node.js, or plain old HTML5. They also have templates for a LAMP stack, WordPress, and even C++!
I decided to try out building an Angular app, so I went with the Node.js image. It starts prepopulated with SimpleServer, “A simple chat server using Socket.IO, Express, and Async”. Groovy. Opening server.js and clicking the Run button at the top of the IDE causes it to start the server (behind the scenes, it just invokes node, though apparently it supports more complex run configurations). I loaded up the address where it said I could find my app (the concatenation of the app name, -, and my username .c9users.io), and lo and behold there was a chat app.
Just for kicks, I decided to try setting a breakpoint while the code was running.
Debugging works too, right out of the box! There’s an Immediate window, which automatically grabs context from the breakpoint. You can see the local variables, set watch expressions… basically, the typical things you’d want to do with a debugger.
For debugging the client side, there’s Chrome, and that’s probably what I’ll stick to.
All in all, this is pretty awesome with very little effort on my part.
As far as the editor goes, I haven’t gotten a chance to play around with it much. I appreciate that there are global settings to be used across all projects and per-project settings, and that everything has a simple GUI or can be updated by editing the .settings JSON files directly. It doesn’t feel like it’s been dumbed down in any way – it feels like a serious tool for users who want to get things done.
The shell isn’t dumbed down either. Behind the scenes it looks like it’s using tmux to communicate with a process running in some virtual machine somewhere. The shell is immediate and has full screen support – I was able to use top to inspect the running processes without any issues.
Next step: actually develop an app in this environment. I’m especially interested in seeing how it handles tools like gulp/grunt.