Cloud9 Acquired by Amazon
c9.io
c9.io
In previous classes we had the students setup a Ruby and Rails environment on their own systems and not only did that take multiple sessions to get setup, but then we were dealing with environment differences that took the focus away from the basics of learning Ruby nearly every session.
However, Cloud9 is much more convenient since it runs entirely on browser but VM solution could work in case C9 discontinues its free tier.
Here's how it works: the professor prepares an Ubuntu VM with the entire development environment set up inside it, and then just provides the image link for the VM. The students can easily install VirtualBox, and then all they have to do is download the image and run off that.
I have VMs on an external hard drive that are accessible to me via Windows and Ubuntu (fairly sure I've accessed them on my MBP as well, not sure). I'm using VirtualBox, so I set up the initial connectivity stuff, point at the existing vhd, and then I'm running right along by launching the VM.
We've written about our setup in https://www.andysayler.com/output/pdf/csvm-sigcse14-paper.pd....
The website for our current VM is at http://foundation.cs.colorado.edu/vm/.
Where feasible, I think the "code locally, run remotely" concept works quite well, especially as most IDE's support at worst FTP upload.
With students that had less than performant laptops, C9 filled the gap.
it even works fine over ssh, over vpn, over the internet, over 3g, in an airplane!
it's turtles all the way down.
Evidently there are a number of restrictions placed on the source code that prevent this from being the case. There was a Reddit discussion about it at the time:
https://www.reddit.com/r/programming/comments/2vvs7i/cloud9_...
BTW congrats to the Cloud9 team. They made a great product and selling to Amazon will ensure it lives on.
My department tries this occasionally. It fails because students either have
a) cheap pieces of shit with unreasonably poor performance under virtualization (I'm talking multiple seconds to bring a different window to foreground under Ubuntu)
b) Retina MBPs, on which Linux has absolute garbage text rendering due to quarter-assed (half-assed is giving it too much credit) per-application support for high-DPI displays. Staring at code for hours is hard enough when the code isn't blurry.
The department runs a Linux lab in one of the libraries with professionally maintained Ubuntu installs that already have everything professors request for their courses, and provides SSH access to those machines.
An interesting side effect is that you either get good at configuring your environment for yourself (to use your own Mac or Linux machine) or you learn to work with just a terminal (use Emacs/Vim and Bash over SSH).
Developers with tech jobs should also be able to afford high end machines.
It's totally worth it, if your employer will allow you to work on your personal machine at all.
Interesting that for me it was the startups that provided good machines while the enterprises provided 4 years old lenovo laptops with not so good batteries not the specs needed to use a VM effectively
Yeah, well, I'll just add that to my (very long) list of reasons never to work for enterprise companies.
With Cloud9 they can develop on any computer they have access to, whether their's, a friend's, or even one at the public library. It is just one less barrier to being able to engage people.
I've run into the use case while traveling abroad where I don't have a computer (out of paranoia / lack of security).
Internet cafés are everywhere but setting up the perfect dev environment takes so long... so far it's made development fairly impractical, especially because they're often very old Windows machines. I've had good experiences with C9 so far, though I'd like to see how it pans out under that use case.
It is a Not Unreasonable (TM) time investment to automate setting up your dev environment in the way you would a prod environment. emacs.d and other dotfiles in source control, masterless Puppet or Chef on your laptop, etc. If you're willing to go as far as installing Vagrant manually, the rest can be made pretty easy.
Of course, this works too.
In that line, https://janitor.technology/, which relies on Cloud9, is a promising offering.
(Disclaimer, I consider the author a friend.)
They claim to have workarounds which never worked for me.
There's no telling what this acquisition will bring, of course, but it's a good fit for AWS, so I'm optimistic that the service will continue uninterrupted. (Both the 3rd and 4th edition Rails Tutorial screencasts use Cloud9, so I sure hope so!)
Congratulations to Ruben and the rest of the Cloud9 team!
EC2's t2.nano, at 0.6 cents per hour, is incredibly close to free. (And that's not even counting the 12 month 'free tier'.)
IF you run it continuously. hyperdeficit was talking about using VMs for teaching, where VMs would presumably be spun up and down as needed.
While it might be pennies (or less!) - I'm still wary of how Amazon bills everything separately - your data at rest, your CPU, your bandwidth. I don't know if Digital Ocean would be any cheaper - but it sure strikes me as being a lot easier to predict. Maybe I'm just unreasonably afraid of what I perceive as "billing complexity" at Amazon.
Now I'm actually tempted to set up a small classroom using skolelinux/DebianEdu[1] on Digital Ocean built around a central droplet running the servers - and seeing how easy it is to suspend every thing to a dormant state and revive it... mostly just to play with the ldap-stuff.
[1] https://wiki.debian.org/DebianEdu/Documentation/Jessie/Insta...
I want to write code on a 2 lb MacBook, with continuous build-as-you-type in the cloud on a fleet of Xeons that have larger CPU caches than my entire project.
Have 5, 50, 500 tests that need to run? Run them all in parallel continuously and get immediate red/green feedback in your IDE. Behind the scenes Lambda takes horizontal scaling from minutes/seconds down to milliseconds, so go radically horizontal.
I want my editor, exactly as I left it, down to the open tabs and cursor position, on any machine. And pair-programming Google docs simultaneous-edit style, without either party giving up the ability to run/debug the software on their own.
What if the FaaS/Lambda lifecycle management was tightly integrated in the IDE? Working on, testing, versioning and publishing a function could be re-imagined in a non-file centric way.
Any time I see a network-always-on browser-based service, I'm only interested in it if I can run offline and synchronize my state in the background.
Which is exactly what I do. I use a local editor on different machines. I sync my projects (git). I get builds and tests farmed out for me automatically (CI).
I'm just not dead in the water if I'm on a train, or a plane, or in a car, or my network dies, etc.
Your editor doesn't need to run remotely in order to do this; it just needs to be able to run things remotely in order to do it.
> I want my editor, exactly as I left it, down to the open tabs and cursor position, on any machine.
You could build this from syncthing and emacs, if you wanted.
> And pair-programming Google docs simultaneous-edit style, without either party giving up the ability to run/debug the software on their own.
You can do this, too, with emacs. It's just a simple matter of programming.
Why spend time reinventing the wheel when there's already a network-aware, extensible editor with man-centuries (man-millennia?) of extensions already built?
c9 has a very low entry bar. It's not reinventing the wheel, it's improving it. You can't really compare a terminal based editor, with an extremely high learning curve, to a preconfigured web based IDE.
From rms's ruminations on Lisp & emacs (https://www.gnu.org/gnu/rms-lisp.en.html):
>> Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
It's really not hard to use a decent text editor like emacs.
> You can't really compare a terminal based editor
emacs has supported X11 since at least November 1994 — your information is at least two decades out of date.
I've got a nice GUI emacs frame open right now.
> with an extremely high learning curve
Learning emacs is not really hard at all. There's a lot to learn, but that's because it does a lot. If something is quick to learn, by definition there can't be much substance to it.
> to a preconfigured web based IDE
Check out emacs prelude (https://github.com/bbatsov/prelude): it's a great some of mostly-sane emacs defaults in one easy-to-use package.
Heck, emacs out of the box is pretty great, too. It evens displays a nice little message about how to use its built-in tutorial.
That's as wrong as 2+2=5.
> That's as wrong as 2+2=5.
If something can be quickly learnt, then it can't have been too different from what one already knows: i.e., the diff between HEAD & HEAD~1 is relatively small. But small diffs don't do much.
Emacs has a gentle but very long learning curve: it's quick to pick up (quicker than vi!) because it does have some similarities to tools one may already be familiar with, but there's real depth and complexity to emacs as a whole, which means that one never stops learning it. Kinda like life in general: being born was easy, and we never stop learning after.
I think that may be because all the mode changes are single keys, rather than Emacs, where I constantly have to ask things like "Okay, was it control, alt, meta, or some combination + S to save my file?"
Vim does the : command line thing, but it's an actual command line, with editing, rather than a series of hotkeys.
This annoys me because I'd really like to learn Emacs. It seems you can live in it - but the learning curve is hardly gentle.
I found Emacs to be relatively pleasant as an environment for hacking source code but I was nowhere near the same level of proficiency at editing with it after several months of usage compared to where I was within a few weeks of forcing myself to learn vi(m).
Emacs has a lot going for it as far as out of the box functionality and the ease of installing packages but it seems that unless you want to take the time to dive deep and learn the minutiae of elisp and configuration you are never really going to become super proficient with it.
The one thing I did come away with after using Emacs was that swapping ctrl/capslocks is the best thing ever and helps even with vi(m) and I now do that for all my environments even though I never touch Emacs anymore.
emacs already has interfaces to build and testing tools. It has Magit, the best git interface I've used.
> Remember software has always been about raising productivity, not just of an industry but of the developer himself.
That's why I'm advocating a user-extensible editing environment! That's why I use emacs.
> Eventually we'll look back on programmers using text editors and rsync for development and deployment the same way we look at people developing software in Pascal and BASIC.
We emacs users already look at folks using editors and rsync for development that way: we have TRAMP (https://www.gnu.org/software/tramp/), which enables one to run an editor locally on remote files. One can even run commands on the server a remote file is located on.
There's no reason that elisp can't be written to spin up DigitalOcean droplets, AWS EC2 instances, fire off Lambda code, deploy pods to kubernetes, control a Mesos cluster, &c. &c. &c. And if one does that, one gets all that plus a world-class, best-of-breed text editing environment with millions of lines of code to do just about anything else one might want to do already written.
Or one could spend time trying to extend a proprietary product, running elsewhere, ignoring forty years of experience and improvements. One could try to reinvent the wooden wheel while others are running transcontinental airline service.
That's really how I feel: every day I'm taking a teleporter to the office, and meanwhile I'm watching others talk about how they've noticed that if they rub a pair of sticks together they get pretty warm. I'm not saying that the folks busily reinventing fire are dumb — most definitely not: they're brilliant — but rather that no-one has bothered teaching them all the innovations which have occurred since fire was first invented.
Setting the metaphor aside, our industry seems to do an amazing job of utterly refusing to learn from and develop on the past. Every half-decade or so someone comes along and reinvents things which were truly groundbreaking ideas before I was born. We seem to be stuck repeating 1970s computer science, over and over and over, rather than trying to live in the 2010s.
If most new programmers prefer to edit code in browsers than in editors, then they are just wrong. I don't know why the preferences of new programmers should matter to professionals any more than the preferences of peewee football players matter to the NFL. The whole point of education is to improve people, not leave them satisfied where they are.
> Maybe they just prefer building tools on top of javascript/css (where they can create actual GUIs) rather than lisp.
Anyone who prefers JavaScript to Lisp or SmallTalk is just wrong. And, of course, one can create 'actual GUIs' in Lisp or SmallTalk just as in JavaScript. In fact, SmallTalk kinda invented the GUI IIRC.
> On a side note: Your TRAMP teleporter appears to use rsync most of the time anyway ;)
At least in my experience it's mostly SSH, not rsync.
I also happen to share that opinion, but the trick is to avoid falling into the Smug Lisp Weenie trap.
It is amazing how primitive most editors are in comparison to Emacs. However, what is also amazing is how fast they are progressing. I've been trying (of all things!) Atom, and it is already adequate for most folks.
Just the other day I've overhead colleagues talking about how some editor (MS Code?) finally added tabs. I kept to myself, but couldn't help rolling my eyes. Not only buffers are more practical (specially if paired with something like Helm), one could hack their own tab bar in a reasonable amount of time (or just download something to do so).
Recent editors are just not customizable enough (not yet, at least). Doesn't matter if they are written in Lisp or BrainF*ck.
Yeah, I know — that's why I included a shoutout to SmallTalk, another great language. There are any number of truly great languages out there (ML, Erlang also leap to mind), although not all of them are great for writing a great editor.
It's hard to avoid being a Smug Lisp Weenie when one sees so much effort wasted on haphazardly reinventing stuff which has been working well for decades elsewhere. Why not spend a few hours or weeks improving what is already great rather than spending years building something new which will probably never be great?
It's probably the thing which makes me most bitter about our profession: the amount of sloppy and wishful thinking, which includes ignoring the numerous lessons of the past. Can you imagine where automotive technology would be if every new engineer spent the first decade of his career playing with rubber trees and ore trying to develop tyres and engine-suitable alloys rather than building on over a century of experience of others?
What's really weird is that there's so much new territory to explore in our field. We're spending entire careers re-exploring our own backyards when there's an entire continent out there to discover.
For new programmers learning elisp adds possibility to create best possible editor on base of emacs (a problem they still don't want to solve), learning javascript allows to find a job (a problem many want to solve). When they learn javascript for their day job, they like the language that gives them power to create things, and they don't see emacs as great, because what they can do for js based editor in hours, will take them months in emacs.
But all that aside, the most important advantage building editor in the browser instead of in emacs, is the huge amount of work that large groups of very good engineers put into making browsers fast, stable and well documented. Small emacs team never can make the part of emacs written in c on par with browser, even for handling the small number of features needed for the ide.
This is what Steve Yegge predicted in 2008 http://steve-yegge.blogspot.am/2008/04/xemacs-is-dead-long-l... http://steve-yegge.blogspot.am/2008/11/ejacs-javascript-inte...
So on one hand we had to redo some of the things lisp had acomplished earlier, on the other hand there is a high chance we won't have to redo in the future what web is doing now.
Alternatively, you're trying to say that a McDonald's Happy Meal™ is great food, when I'm serving salt-crusted ribeye, served with fresh English peas, roasted sweet corn and garlic mashed potatoes with cream.
I recently started using Spacemacs[1], and I'm basically sold on Emacs as an IDE-building toolkit. And I say that as a decades-long Vim user (I still use Vim, just as key bindings within Spacemacs).
> You're right, but all you'd have to do is build cloud9 yourself.
> I recently..
There, I fixed it for you. Now why would anyone want to reinvent the wheel again?
Cloud 9 is one of many. In 3 years you won't remember the name.
So reinventing the wheel? If you refer to some magical emacs setup living somewhere on a fictional users local machine which is being cloned and made very real and available to the world. Yes they are reinventing the wheel. If it's easy, please make the fictional emacs become real and share it with us in a shown HN. I think there is a difference between a hacky approach that works and a product.
Furthermore, their IDE is extremely slow and vim mode is broken. Other than that, I share your ambition and hope that one day some other company will solve this. Perhaps Microsoft will be the first. Visual Studio Code has as a nice web-based editor.
We're considering building this in GitLab I want a local client that pushes my working copy to GitLab and runs tests on it. GitLab can receive the code, commit it to a 'hidden' repo, and run the tests. Sending feedback about failing test or successful tests back to the client. The client could be part of an official command line client, currently we have community ones under CLI clients on https://about.gitlab.com/applications/
See https://gitlab.com/gitlab-org/gitlab-ce/issues/19267 for more detail.
And it will need a client integrations and a way to make this 'hidden' repository and/or commit.
In Django for instance, it would be straightforward to automate generating the list of apps to test:
{
"name": "my django project",
"tasks": [
"python manage.py test myapp1",
"python manage.py test myapp2",
"python manage.py test myapp3",
],
"labels":"..."
}
It would be cool if the architecture allows for plugins like this.
When you rent a Google Compute Engine machine, it doesn't matter how much you use the CPU, the monthly cost is the same (roughly $30/vCPU/month). So you incur no additional cost by restarting tests after each input character. And if we can spread multiple users' tests out over multiple machine instances, the cost would remain constant per user, but their tests would execute in parallel on multiple instances.
Nothing to install, no environment to configure, just log in and start editing.
Lambda would be cool, but really any way to spin up several machines near instantly and for just a few minutes without paying for full hours would suffice. GitLab CI has helped lots.
If you're seriously pursuing it at all, we should talk more.
Sublime doesn't handle this too well today.
Sure I can setup all of this manually a second time, but it takes too long to be practical.
(Maybe there's even a play for getting this stuff into the hands of non-engineering employees. Build the "Excel" of APIs, if you will?)
There are exceptions to every rule, that doesn't mean you should make shitting all over the rule your own new rule.
You're still supposed to migrate the code to staging and then production.
It's highly interesting how very young developers are using C9, naturally, to code.
Something great is happening behind this behavior, it's much more than an online IDE. It feels friction less to develop a website totally online for this kind of developers.
Also, for example, I can think many people using PC's on cybercafes prefering C9 to develop.
I really recommend to watch it live to understand it.
Consider the fact that it's super easy to buy a bunch of cheaper Chromebooks or tablets, fire up Nitrous or Cloud9, and now the focus can be on solving problems - rather than set-up/deployment.
Well, I just tried to sign up to c9 to give it a try, and it asked for credit card information (it is mandatory, even for trying it out). I'm not sure if all the youth has access to a credit card. Also, I don't think it is very user-friendly, but that is beside the point.
I just tried it myself and you're right, they just added it.
Or worse, they'll do deep packet inspection to make sure you are not using SSH. My high school did this, and I ended up stuck with Cloud9 instead of using my real server at home. Glad to be out of there.
I get it that we need a better user interface than the plain text, but I fail to see any advantage of browsers either. Perhaps we really just need a better terminal emulator? I see the enlightenment guys has some new ideas[0]. Does anybody here know of anything else?
This is opposed to a straight up judgement, like what you have just done.
† https://en.wikipedia.org/wiki/VT100#/media/File:Vt100-advent...
For a concrete use case: my dev laptop broke down in the midst of a project, and I could just use a generalpurpose computer at location, use c9 to spin up a server, clone the git repo and I had an IDE to go with. Did not need to wait for the sysadmin to let me access a terminal or to unblock certain ports. No loss of productivity whatsoever, I was up and running in minutes.
Also, I can give others access to said c9 workspace, and they don't need to know anything besides the programming language used, to make little tweaks.
I think I just realized how much lasting trauma the browser wars caused me. You're completely right, but my gut still reflexively respond: I know you have a shiny thing that works great in Internet Explorer, but those ActiveX controls won't run in Opera on Linux...
Rebuilding trust in the web as an application platform is going to take some force on will on my part...
(That said, I have grumpy reservations on the security of our current and future web - but I guess it's not really worse than what it was like when people were running Windows 3.11 and running random code in spreadsheets on a samba-share...)
Also in esports a lot of the event hype feels manufactured and forced.
I do like watching esports though, I just think there's so much room for improvement in the whole way the thing is presented.
Remember that most teams are named after their sponsor. A sponsor is not related to any city/esport. It's just a sponsor.
It's a bit more complicated than that, actually. Most of the large esports organizations (examples: Evil Geniuses, Cloud 9, Fnatic, Team Liquid) have an identity that's separate from both their sponsors and their teams. Teams that represent a single sponsor are pretty rare -- I've seen a few, but they're not common.
I don't understand traditional sports teams. They claim to represent a geographic region, yet the typical player on such teams have as much history or loyalty to that region as I do to Jupiter.
As far as rooting for teams within a region, it usually boils down to finding your favorite personalities like that other guy said. Most of them stream on twitch for hours every day.
Also, all of the local regular sports teams I grew up rooting for never win anything so having no ties and getting to be a bandwagon fan in eSports cathartic for me haha
That isn't an e-sports specific phenomenon though. Maybe it's the case more with US sports teams, but in something like football/soccer you have teams like Manchester United that have a massive global brand that is attractive to people in multiple countries and may have zero connection to Manchester or England as a whole. People in other countries will choose a team at some point based on specific players they like, a certain style of play, or even who their friends/family are already rooting for. Formula 1 likewise is also just a pure battle of the brands. Pick a team, follow it closely, and cheer for them.
Not uncommon at all in my country. In fact, most major clubs have teams in many different sports.
I liked Google's web based IDE when I was a contractor there and for about a year I experimented with using nitrous.io. Right now I am experimenting with using codeanywhere pointed at my own large server instance.
It is tremendously convenient having one development environment set up that can be accessed from all of my devices. Hopefully Amazon will raise the bar.
They have one of those?
- https://cloud.google.com/source-repositories/docs/using-sour...
- https://cloud.google.com/shell/docs/features
Personally I think it's really nice.
In all seriousness though, I agree with the general sentiments here. I really hope C9 doesn't get shutdown, it's incredibly nifty and I've found it saving my butt a few times (quick set up for teaching new devs, working on a borrowed machine, working on university* , etc)
* ports aside from 80/433 are blocked, so I couldn't push/pull reliably. I ended up uploading everything to c9, then just using it to push/pull.
No SSL? Boo! ;)
After a few years of headaches trying to help students get their local dev environments setup, we started recommending Cloud9 to all Students. Definitely the way of the future.
though part of my team spent most of the time in the food lines, which was a bit of a setback:P
Amazon may have some cheap prices and their customer service has the margins available to offer refunds/replacements quickly. But that all is easy guise. Amazon is rotten inside. Each product team does whatever it wants. So how long can the exterior hold a toxic spill?
Those AWS dashboard icons look really nice. Makes everything look so organized and contiguous. But each of those services is done in different languages, different frameworks, by different teams, with whatever crap will hold the leaks and terrible patchwork programming by their average employee who will on average, stay less than a year. The churn is real.
It's one of the core paradoxes of economics. I want a cushy job with great pay, but when I go shopping I implicitly want everyone else to have a shitty job with low pay. There's a name for this paradox but I'm forgetting it right now.
It's very similar to the paradox of thrift: it's in my interest to save, but for me to save someone else must be spending. If everyone saves nobody can save.
Almost everything in economics is a paradox since there are two columns in accounting-- every transaction has a counter-party. It's bizarre for something not to be a paradox in economics.
If everyone has the same capabilities and preferences, then the economy is a zero-sum game like you've described. In some fields, that's close to true, and those fields tend to be low-margin commodities.
Why do 27k engineers (in Seattle alone) need to write in the same language to make a service successful? How many SAAS startups have you worked at? How does Amazon/AWS compare to this? I think you're out of touch and/or lacking context.
The editor is really nice and I absolutely love the ease of window snapping and tailing log files using the command line panel.
Before Cloud9 I used PHP Storm. Still a very good editor, but I love editing files on cloud hosted machines as I can move from desktop to desktop and continue right where I left off.
Here's a script reference that I use to set it up: https://github.com/medatech/ubuntu-setup-scripts/blob/master...
"Terms of the acquisition were not disclosed but we’re trying to find out. And we’ve also reached out to Amazon for a direct confirmation of the deal."
and
"Cloud9 had raised just over $5 million from investors that included Accel and Balderton..."
https://techcrunch.com/2016/07/14/amazons-aws-buys-cloud9-to...
If this service doesn't keep running I will chain myself naked to the front doors of amazon's offices and won't let anyone in until they agree to bring back cloud9. It would seem to have big potential with the rest of amazon's services.
My stack (if you're curious): JRuby / Sinatra, d3.js. Keeps it lean.
Oh, my one gripe! I keep the IDE window full size, so whenever I switch applications and tab back to Chrome... my full sized window is gone. I have to select window -> my tab, and this SUCKS. IT SUCKS. I wish this were wrapped in a little 'chrome as an app' application.
My only concern is that this could possibly mean getting rid of SSH Workspaces. Please don't let that happen. SSH Workspaces are required for us, and if that goes away we will have to find another solution.
I suppose it might be more clear if I install and run the "core" - but there was no mention of docker or vm support, nor root access?
https://github.com/benlowry/chromeos-dev-setup/blob/master/s...
For any services/products outside Google, Cloud9 is truly the only service I have been really excited about. So much so that I've replied to their various automated emails thanking them for their services, and they've replied back. Love, love, love it so much. It is _so_ simple. I'm glad for the founders and the team, but I really hope Amazon keeps up the amazing support and the product they have.
What are some great use cases for this type of tool? Is it mainly for quick testing or temporary stuff? Or would you use it for something longer term? Indie developer or team?
Nice to see these products taking off from a pure cost perspective, I can buy a chromebook and do development as long as I have an internet connection.
One can make guesses:
- expanding into new verticals
- potentially "enabling" Cloud9 users to become users of other AWS services
- world domination!
Having a high quality editor built into Lambda would make it so much easier to work with.
They can implement it without buying the company.
Even if the license doesn't allow it, the license for ACE surely does and ACE is the meat of the editor.
https://github.com/ajaxorg/ace
Maybe they want the team because they want to move the product in a certain direction? I don't know.
Congratulations to the cloud9 team.
That was remote VM, some of the younger ones think are invented 20 years later ;)
Cloud 9 and Eclipse Che are different beasts. The primary difference is around the definition of a workspace. Eclipse Che workspaces have an encapsulation that include their runtimes and a self-hosted IDE. This, then, allows you to run Eclipse Che as a workspace server on any server or desktop. And since the workspaces are defined with configuration files you can move workspaces from one server to another.
The SDK is entirely open source - with no restrictoins, so there is a development model for how to customize both the IDE and the workspace.
Since workspaces embed their own runtimes, you can use Dockerfiles to create completely customized stacks. And we'll be supporting composefiles shortly.
We built Che this way to encourage ISVs to adopt for ucsotmization while also providing a simple IDE for developers. Codenvy uses Che to build out a distributed system that they host at beta.codenvy.com and also is installable by customers behind their firewall.
Cloud 9 is primarily a fully hosted SaaS with their IDE. The IDE features are similar but different, with C9 having more work around collaboration of users within the shared environment.
There is more details beyond this - but this is the essence.
I think CAR is how development will be done in the future. (Literally tomorrow)
Oh ok... I'll check back in an hour :)
I spent a whole week trying Cloud9, Nitrous and Eclipse-che.
Pros: good for teaching, colaboration, toy projects. Cons: still a few years behind any decent IDE.
I am the Che project lead.
http://ipfs.io/ipfs/QmSCrZUPkqH4gsncsD7tGXPiFpymsbwmywsHXLDh...
> Cloud9 combines a powerful online code editor with a full Ubuntu workspace in the cloud
This is the first thing I see on loading their website. Is this their main selling point? Why does my editor need to be "in the cloud"? It works perfectly fine on my local machine, and I could even automate syncing if I wanted. Also, I could just ssh into my server and start an editor there.
> Build WordPress, Django and Rails websites and test in 300+ browser/OS combinations.
Is this automated? Because who would want to test 300+ browser/OS combinations manually?
I have a handful of devices which I like programming from - I use Eclipse Che (the tech behind Codenvy Beta, similar to Cloud9) for some of my projects and I have exactly the same environment on all of them.
There's other ways to accomplish this - sharing dotfiles between machines and using Docker for environments - but a cloud IDE makes it a bit easier and less hassle to set up.
It does not HAVE to be. But it is another option and great one at certain situations. Such as showing someone how to start programming, working on small project without having to deal with setup time etc.
I really like it actually. It's not meant to be replacement of local machine IDEs.
I've been on Cloud9 for all my work (day job and freelance) for several years now and honestly can't imagine not using a web-based IDE.
It also means I can have a nice IDE running on our development server instead of on my local machine, which is handy because I have two different computers I use for work (a desktop and a laptop.) My workspace is not just similar but literally the same workspace on both machines.
Ok. Do they allow two people to edit the same file simultaneously?
Hey, you just answered your own question. Beginners no longer have to setup their own machine/server, they can simply create an account on c9.io, they don't even have to pay for it and bam you have a full ubuntu workspace ready instantly without any effort which is very useful for teaching them their first programming language.
cloud9 on the other hand took me about 3 minutes to create an account, django workspace and to start developing with it.
that is a massive difference.
But I see no justification for creating a complete development platform in the cloud.
I already have a full Linux workspace ready instantly. I'm typing this in it right now. It's my laptop.
Linux is so simple to use now that my liberal-arts relatives are using it. Why use expensive, legacy, less-powerful OSes like Windows or macOS when Linux is available? Why run something over a net link when Linux can run locally?
For a rails app it's not a stretch to have to install postgres, rvm, ruby, some compiled gems, and redis. Then you need to make sure postgres and your rails server are running.
These aren't insurmountable and we can write documentation around it but compare that to 'Log into c9.io, copy this workspace and work on a ticket'.
I work with people that want to learn how to program and I hear feedback that getting an environment setup is overwhelming somewhat regularly. These online IDEs look like they can really combat that.
Well, how else will they be able to steal your IP and passwords? How else will you be able to go get coffee every time the net's down? How else will you be able to spend years reimplementing elisp in JavaScript, poorly? How else will you get to experience the instability of a web browser while editing code?
Truly, a cloud editor is an advancement on the bad old days when we had editors which ran quickly, locally, with decades of extensions and kept our information safe.