The Changelog: Software Development, Open Source - Cloud 9 IDE (Interview)

Episode Date: July 17, 2012

Wynn caught up with Ruben and Matt from Cloud 9 to talk about what's new with their IDE in the cloud.

This episode of The Change Log is brought to you by Pusher.com. Pusher is a hosted API for quickly adding scalable real-time functionality to web and mobile apps. If you're building anything that needs to get data from the server back to the client asynchronously, you need to check out Pusher. They've got a number of tutorials to help you get started, everything from a quick start guide to building a real-time chat client, push notifications, activity streams, and more. We'll see you next time. www.changelog.com Welcome to the Changelog episode 0.8.3. I'm Adam Stachowiak. And I'm Winn Netherland. This is the Changelog. We cover what's fresh and new in open source. If you found us on iTunes, we're also up on the web at changelog.com.

We're also up on GitHub. You can head to github.com slash explore. You'll find some trending reposts, some feature reposts from our blog, as well as the audio podcast. And if you're on Twitter, follow the Change Log and me, Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N. Speaking of Explorer, you'll notice that there's no more player on Explorer. So the folks at GitHub, we decided to remove the player from there to save a few kilobytes across the site.

So I'm sure you'll appreciate that. So you have to link back to the website to listen to the episodes now. But no biggie. We're still there. Yeah, we're still there. Fun episode this week. We talked to Ruben Daniels from Cloud9. We got the scoop on some, what's the latest ACE developer tools in their Cloud9 suite? Man, you know, I'm so excited about what this is going to do.

I think this is just, you know, an editor in the cloud. I mean, you as a Vim person, you must just love what this is going to do for just taking your environment anywhere. Be cool. It's going to take a while to get me off of text mode. I've got to tell you, I'm loving it more and more. But for those folks that want to just open up a browser and have their editor anywhere, it's amazing just the sheer feat of what they've done in the browser with Cloud9. I'm just amazed.

It behaves like a native application in many ways. It kind of reminds me of whenever everybody was in the enterprise trying to go to thin clients, right? It's kind of the same thing. Your dev environment isn't your local machine anymore. It's on the server. It's like pants, legs, wits. We just, in the industry, keep oscillating back and forth

between fat and thin clients. It's like bootcut and skinny jeans, you know? That's true. It's a fun episode this week. Should we get to it? Let's do it. We're chatting today with Ruben Daniels and Matt Pardee from Cloud9. So why don't you guys introduce yourselves?

Ruben, why don't you go first? So I'm Ruben. I'm the CEO and co-founder of Cloud9 IDE. And a developer myself, but today also doing all the stuff that CEOs do. And I'm Matt Pardee. I am the developer evangelist for Cloud9 and also a developer on the platform and wear of many hats at Cloud9. We should mention you guys are co-workers with Tim Caswell, friend of the show that was on a couple of episodes back

talking about Lua and Lovit. So for folks that don't know, I guess Cloud9, that probably used it might not even know it. It's the editor that powers the Readme editor on GitHub. Is that right? Definitely. It's a very, very powerful editor, and we worked together with Chris from

GitHub to integrate it. And yeah, it's a multifunctional editor having all sorts of themes and everything from multi-selections to all sorts of strange language support. Let's talk a bit about your business and business model behind it. So Cloud9 is an open source editor, the IDE, but it also has a platform behind it. Is that right? That's correct. We decided that we wanted to make as much as we possibly could open source. So not only the editor is open source, but also actually the IDE application. And then the software that we use to manage and scale the platform itself, we kept close to provide the service.

What sort of server architecture are you employing? So it's a multi-tiered architecture where we have a proxy in the front that's dynamically scaled based on the need. We have a second layer, which is what we call IDE servers that do multi-user, multi-workspace servers that get the request from the proxy. And then behind that, we have another layer where people's code is run, actually,

and all the things that they do on the console as well. So I didn't hear Node in that, but I'm assuming it's a Node server based on Tim's employment there everything's node all these different layers, each is node are you guys employing node in the build process for the IDE as well?

yeah, all the build scripts are in node the connectors are in node one of the cool things that we've been working on is this virtual file system layer that sits between the IDE server and the servers behind it. And this virtual file system allows the IDE server to connect over SSH to a Node process that runs there and perform all sorts of tasks like reading files, starting processes, doing file watching and things like that. And VFS is actually open source on GitHub.

So let's talk about that for a moment. The virtual file system, what sorts of file systems is it virtualizing, I guess is the question. So it virtualizes a local file system, and SSH is one of the things that we've been adding, and we'll add some more in the future. It's basically the start of a complete set of support for these things. I think we'll come out with some integrations with commercial services that have REST APIs for all their file access soon.

Matt, is that your role to onboard, I guess, integration partners to figure out how they could latch onto the platform and extend it? Yeah, so we'll be ramping up that process later. But yeah, I'll be working with making sure that our platform is ready for all developers to get on board with and that it makes sense. And it's kind of a new frontier for development workflow and how they can kind of latch into their existing services or technologies and really take advantage of this freedom and power of developing in the cloud.

So Ruben, some folks may be taking a double take. You've been on the show before in a previous incarnation of the brand, Ajax.org. Why don't you talk a bit about the transition between that brand and the new brand and if it involved a pivot at all? Well, yes. I mean, definitely. So Ajax.org, we used when we were creating an Ajax framework, actually. So the name made sense.

It was a little bit generic, but we created an open source framework to build UIs in the browser. And we thought it was a great framework, just not a great business. So at a certain point, we created the IDE with this framework, and we noticed that you can actually create a business building an IDE and support all the open source work that you're doing. And we raised a little bit of money from Excel, Excel Partners, a famous VC here in the Valley. So we had the funds as well to start going and doing this work on the IDE. So we pivoted the company basically going

from building this UI framework to building an IDE and selling it as well online. So you guys had ajax.org as the domain name for that previous incarnation. Hard to improve upon that, but you have with c9.io. Just noticed that. That's a great short domain. Looking at the screenshots for Cloud9 IDE, it looks a lot like Sublime or Google Chrome. This runs in the browser?

Yeah, I mean, we definitely looked at Chrome for the tabs. And how Chrome deals with tabs is very, very cool. So we copied that. And there are also some aspects of Sublime that are very new and very interesting. And, you know, if somebody innovates on a certain type of interaction, it makes only sense to look at that and use this inspiration for your own. So we've done that with a new version of Cloud9. You'll notice that there's a lot of things that were inspired by other things

that are already pre-existing. So some of the things that are given in a text editor, keyboard shortcuts, syntax highlighting. Talk a bit about those features. Right. So, yeah, we spend a lot of time on those. People seem to be really, really passionate about it. And we get a lot of people supporting us with creating new syntax highlighters.

And they're all issuing pull requests to do that. I think we have about 50 syntax highlighters now, somewhere there. And a lot of themes as well. They're really passionate about

that too. And so are we, actually. So what was the other part of your question again? Sorry. So the keyboard shortcuts, I noticed that you support both Vim and Emacs key bindings. How configurable is that? And do the browsers tend to get in the way and different platforms on some of those?

Right. Yeah, that's been a challenge. The browsers do get in the way and you have to work around some of the shortcuts that you would otherwise choose. But overall, it's been doable. We've been able to be creative with key combinations

to have the shortcuts that we want. There's a default set and then indeed there's an Emacs and Vim set. Generally, we build a system so that it's really, really easy to create these type of sets, and you can do that in a plug-in. In the future, we'll also have a UI to set these type of key bindings, but right now that's something that you can easily do in a plug-in. I noticed the browser is telling me to unlock extra features by installing a Chrome extension.

Is that how you get around some of those limitations? That's mostly for cut, copy, and paste via context menus, which is you could say an edge case, but still something that a lot of people do. And currently, if you don't have that plugin installed and you right-click and you do copy, it will only be available within that browser frame. If you go to another place outside that, you won't be able to paste that content. If you use Command-C or Command-V, you can, but with the context menu, you can't. So that unlocks that.

I think everyone in the company had an aneurysm when they found out that you couldn't, so that unlocks that. I think everyone in the company had an aneurysm when they found out that you couldn't actually do that, that it wasn't available. But, yeah, it's true, and I think there's probably some more features that will come out as browsers move along that we can integrate better by installing a Cloud9 plug-in, so to speak, on a Chrome Web Store

or other browser environments that are doing the same thing like Mozilla. Yeah, what you really notice is that browser vendors are noticing that to build real applications with HTML5 CSS as the way to be the presentation of those applications, you need to integrate better with the operating system. And we noticed that ourselves,

being able to access the file system or start processes locally is essential for, in our case, the offline use case. So with this next release, which... Will be out by the time this airs? Exactly. So with the new version of Cloud9, you're able to go offline when you want to.

And the way that we've implemented that is that you download a small little node app that you run persistently on your computer, and it will automatically sync all your files from the cloud to local and from local to the cloud. So as soon as you're offline, the changes are saved locally and the moment that you go online again, they move to the cloud.

Now, this type of solution we feel should in the future just be very simple to code within the browser. I know that many of the browser vendors are already working on these type of APIs to make that possible. So in the online scenario, do you have any multi-user features baked in where it would support a pairing scenario? Good question.

Yes, and that's been our vision and I think the promise of an ID in the cloud to very, very easily work together in teams. And we are ourselves a company where I think in 10 countries or something like that, we have developers. And working together sometimes can be a little bit of a pain as you're stuck with something that someone else built and you're trying to get their help,

but you have to do some screen sharing solution and then you can't type. So we tried to build a solution where you can do real-time collaborative editing on documents, multiple documents, and even your entire workspace in the cloud. So you'll just be able to go to Cloud9, copy the URL of the workspace that you're in, and then share it with someone else, and you can start typing, give that person read-write access. And they'll be able to not only type the code, but also run the program within your workspace.

And what we even added is the ability to debug code together. So you can set a breakpoint, hit it, and both participants or multiple participants will see what's going on. They can both step through, inspect variables, and these type of things. So we feel that that's a very, very new way of developing code for people that are remote. You've got a lot of codepository options baked in GitHub, Bitbucket, Mercurial, even FTP. Hopefully nobody's still using that sort of live to save to live workflow. You'd be surprised.

I know, I say that facetiously. Also a lot of deployment options, Joyent, Heroku, some of the usual cloud suspects. What about CI? Is that still something that you would integrate in with your code repository or do you have any plans for continuous integration in with your editor? So let me answer that question first by talking about our test panel, which is something new. And the test panel allows people to

very easily run all the tests within their project. And it's a very pluggable architecture. We're launching with just a way to run a node unit test, but we already have a plug-in for Selenium as well. So you can add all sorts of tests there that you can run automatically, even at every save or with some pattern that you specify. So what about support for pre-processing languages,

Compass, SAS, even CoffeeScript? It looks like a lot of times in the front end, it seems heavy to have to install a lot of tools and, I guess, dial tone to get those projects in place. That could just be baked into my editor. Yeah, so I'll talk about that. We worked on upgrading our console interface, which is built into Cloud9 at the bottom of the IDE. And we enabled the ability to run NPM packages right from the terminal in the console. And we already actually allowed users to use NPM

to install packages from npm.js.org right into their Cloud9 project, either locally or as a global NPM package. And now we've built in the ability so that when you type in an NPM package, such as coffee for instance that it will go and search and find that package that you have installed if it finds it then it'll run it and if it has a standard input prompt then you can actually interact with that so this is great news

for developers who work with express and they want to scaffold a lot of applications or they work with Coffee and they want to either build their entire Coffee script project or just even interact with the REPL directly from the console. And so we give them a little prompt that indicates what process is running and they can type in whatever Coffee script they want and get the feedback right away. And this is really great.

Developers can kind of reconsider how they use NPM packages in general because it is now a part of their cloud development process. And so you can almost think of some of these packages as general software packages. You know, you can code your own NPM package to compile CoffeeScript or build different things and put it on npmjs.org and then install it in your Cloud9 application. And they have now over 10,000 packages out there that you can try on Cloud9. Many of them have the ability to be run from the command line, and that's what we look for. So it's really exciting for people who do LESS

and CoffeeScript development and so on and so forth because now the console can accommodate for those kinds of those for that kind of so it sounds like coffee script and stylus and less would be supported pretty trivially but some of the ruby based languages like compass and sass would be a bigger stretch yeah exactly so we do have to make some limitations about what you can install in a shared environment but but yeah for the other other things that come with NPM, then those usually can be run in a shared environment like we provide. So the nice thing with this new release is that we're giving everyone that's a premium user a full environment.

So anybody that gets a premium account gets one environment in their workspace where they can just run any type of executable. And they get an individual environment per project that they create. So if they want to run Ruby or Python or PHP or anything really, they can just do that. And it runs completely isolated from any other project. So those security restrictions that we need to have on the shared environment are lifted. And we run Python in interactive mode, and that just all works fine right from within the console of Cloud9. Any integration with services like GIST or Pastebin? Not yet, but we definitely want to do that.

And I think that that's something that we can do once we have sort of the basic workflows that we envision ready. So you guys are pretty excited about the release that just came out prior to this airing. What's on the roadmap of what you can talk about for the next six months? I think that one of the most important things is API stability. We've seen with, you know, Eclipse and Visual Basic

and many of these other tools that the ecosystem, a lot of people just being able to change and create plugins for these type of IDEs is really, really important. And we have several hundred plugins right now for Cloud9, but to really be able to create durable plugins, you need to have a stable API and a well-documented API as well. So our goal for the next three months or so is to actually do that and build that. We already started with a lot of things that we've done with this release are to cater for that.

One of those things is Architect, which is another open-source library. And it's sort of, I think that Rick, our CTO, called it COM for JavaScript. But it's really a plug-in system that's very generic and very nice and creates a loose coupling between different modules, having sort of a service-like architecture

within, in this case, a node process. Having started my development career in the late 90s, com for JavaScript might not be the best marketing slogan. Well, it might not be the best marketing slogan, but it's at least a way to understand what it is. Sure. Let's talk about the anatomy of a plug-in. Is it purely

client-side code that plugs into the open-source IDE or do you have anything like the equivalent of a Heroku add-on that would be a server-side addition

as well? So, currently, actually, Architect only runs on the server and our work for the next month

or so is to get it on the client as well. So, we have the same architecture on the client and the server and that's for the next month or so is to get it on the client as well. So we have the same architecture on the client and the server. And that's something that we can do because we run JavaScript on both ends. And a plugin is a very simple module with only a couple of calls to initialize it. And it can ask for or request other services and the those services will implement a certain API, which it can then use. Matt, maybe you can elaborate a little bit more on this.

Yeah, so I got my feet wet with Architect recently, and it's a wonderfully elegant, simple solution for any level node application that you want to build. And it happened to suit our needs for Cloud9 because we wanted this idea of isolation and reusability. And when I started working with Architect after it had kind of been created, I was really blown away. You can start from a really simple foundation. And, for instance, if you wanted to create the kind of, you know, proverbial to-do application, you might have a database module and a, you know, an HTTP module to actually serve the web page. And then you may even have an authentication module because you only want certain people to access the application

or access the database rather. And what Architect allows you to do is allows you to put those three separate modules into each one of their components and then add to a pool of resources by registering themselves and saying, this is what I'm providing to the rest of the world. And then every other module can say, this is what I want to consume. And so the HTTP module might only need to interact with the authentication module to allow people to access the web page.

And then there might be a separate controller that will access the database. The great thing about it is that it simplifies the process, but it also makes it so that you don't have to really consider your application as starting from a web-based interface and then going back to the authentication interface and then going back to the database interface. You can consider all of these things as part of one big pool. And so it may be a little bit of a tweak on people's mental models of how an application works,

but once you actually start working with it, you realize that it frees your mind to think of other possibilities so that if you have another part of your application that wants to use the database, it's already available for you if you just ask for it. And it might seem trivial or just like a basic idea, but when you just say, I want to have this database that already exists over here, then you can use that. And even better, you can then use that database module as part of another application really effortlessly.

You don't have to cut and paste different parts of your scripts or application code. You can just take it out and put it back into something else. And we even facilitate that process by making it so you can separate these different components into either a plug-in that exists as part of your application, or you can even install it via NPM. And so we even have different components, like we've created an HTTP module called Architect HTTP that I believe is available on NPM. And so when you download this application, you know, Architect from GitHub, and we have some examples that go along with it, you can just do NPM install on one of the demos, and it will install the needed plugins from NPM directly.

So it makes your entire, not even your application scale really easily, but it also makes the process of developing your application scale really well as well so that everyone else can work on different components and update those components as needed. I think that one of the limitations that we found just using the basic require system is that we couldn't easily use and test only parts of the system. And so that's one thing that this system provides. Another thing is that it also allows for out-of-process parts. So I could take a plug and run it out of process

and still use the same way of communicating between them. And I think that that can be very powerful. You, of course, have to be very careful with that and make sure that the plugins that you do that with are architected for this type of behavior. So yeah, we're really excited about Architect and using that both on the server and the client. And what we are looking to sort of evolve Cloud9 into in the next couple of months is

an environment where it's really easy to develop these types of plugins, try them out, start and stop them without having to restart the server. And then also being able to provide a way to easily get them running in a secure way on the online platform. Let's talk about the average workflow for a moment. So signing into Cloud9, if I authenticate with GitHub, then I see all of my public repos, I guess private repos as well. And then if I click on one of those, to get started, I have to clone that to the Cloud9 servers.

Is that right? Yeah, that's correct. And then as I make changes or invite other people to collaborate on that project, how do changes get upstream back to GitHub? So there's the command line that we touched upon a little while ago. And you can type git commit or git push, and that will commit back to your origin, which will be your Git repository somewhere else.

So essentially when you clone, it sets it up as a remote here on Cloud9? Yes. Your origin is still back at GitHub? Yeah, definitely. It's a really nice command line console at the bottom of the screen. This is one of those things that normally web-based editors make massive tradeoffs, but this seems to, I guess, combine the best of both worlds. That's what we're trying to do, and we've had people being really enthusiastic

about not having to change windows but just having that all in one UI and there are all sorts of shortcuts to switch easily, shift escape will go to the console control escape will open up the output so it's

a very nice way to work generally So one of the common features in editors is what Microsoft calls IntelliSense and code completion and Xcode. You guys have anything like that? I think that this feature is the most requested feature by our users. I mean, we have 120,000 users now, and we often ask them, what would you like?

And this type of solution offers a way to very quickly type things without having to know what the APIs are exactly. So we spent a lot of time on building that. In the past few months, we hired some very intelligent guys that got their PhD in this area. And they built a solution for JavaScript that I think can match the solution that exists out there for Java and other strongly typed languages. But they managed to do it for the weakly typed JavaScript using another open source project of ours called TreeHugger. And TreeHugger allows you to query code with a query language very similar to you have query languages for databases or XML. But in this case, you query code and you can match code based on its structure, its so-called AST, rather than just the characters that are there.

So we use that and that will be available for many other languages later on, but right now it's there for JavaScript and we have Node.js documentation support in there as well. So that means that when you want to try out some Node.js calls and you don't remember what they're like, you just type in the first letters or just type alt space or control space and you get help and auto-completion immediately. Just from a consumer perspective, it seems like a lot of IDEs are tied to the platform for which they're developing, Visual Studio for Microsoft, Nextcode for Cocoa and the Apple platforms. It appears that if you had somewhere where you could pick off customers at the fringe, it would be in the Eclipse market, a market that you're going after. So Eclipse, I think, is mostly catered towards Java.

And it's indeed a very big group of developers. But outside of Vim, just my own observations, it appears that Eclipse has the most try-to-be-all-things-to-all-people approach. Right, right. I think that there's value in being specific and providing tools for certain environments. And I don't think that a lot of script languages or dynamic languages have good IDEs. So there are a lot of people now that are using text editors

with these basic, basic forms of autocomplete or other tools, and they don't know any better. So what we're trying to do with Cloud9 is provide the richness that people in the Java and.NET community know they can have from their IDE and provide that for the people that are writing in these script languages. And it is possible. So that's our focus right now. But on the longer term, we'll definitely also support those bigger languages.

Regular listeners know that we normally end with a few questions. One of those is, what's your text editor? I think I know the answer to that one. So let me ask you, Matt, first, who's your programming hero? Oh, man, that's a good question. You know, I'm going to say Linus Torvalds, and the reason is because I think that he's often misunderstood in the way that he responds to developers

and what we see a lot of times online. But I have to say the deeper that I go into Git, because I'm a Mac guy and I don't use Linux, so the more I go into Git, the more profound respect I have for what he did there. And I'm not the type of guy who adds up what a programmer did over his lifetime, and it's kind of just still relevant to me that I use Git every day. So my answer might be a little bit more short-sighted

than some of the giants in the programming history books, but I really have a lot of respect for, for the thinking that he did on get and, um, how one person's idea like that can impact millions of developers. And, um, I think it is great.

And obviously what Linux has done for, for everyone else in the world, um, is also pretty incredible. So yeah, I'll go with Linus. What about you, Ruben? Good question.

I crowdsourced this question right now. People don't have an answer. Are you doing a phone-a-friend on Twitter? I'm using Skype. Can I have a different question? You can email to me and I can put it in the show notes. Okay. Alright, I'll do that.

Cool. Well, nice work guys. It's a great editor and it's a great platform that you guys are building and I look forward to where you guys take it in the next few months. Thank you very much, Wyn. It's great being on your show, and I'd love to have everyone try it out on C9.io. Yeah, thanks, Wyn.