We did a massive rewrite last year (https://c9.io/blog/announcing-the-all-new-cloud9-development...). We adopted a new plugin system and started with a completely new, clean code base. We ported the old plugins one by one, optimizing them and fitting them into the new system, and actually throwing out quite a few of them entirely. So the code is actually rather clean. But note that this figure includes code for a lot of backend systems that are part of the Cloud9 service infrastructure, such as backup workers and container management code, as well as code for partners and plugins that are not exposed to the normal user base.
The URL is very similar but notice how the subdomain differs. The outer Cloud9 runs on (ide.)cloud9-lennartcl.c9.io. It responds on that URL and on *.cloud9-lennartcl.c9.io. That's where the inner Cloud9 runs: (ide.)cloud9-lennartcl.cloud9-lennartcl.c9.io. Visit that URL and you actually go through 3 proxies: the production proxy of c9.io and those of two inner instances. And note that the user names look the same in this case in this case, but that's really just for symmetry; ide.cloud9-2-lennartcl-2.cloud9-lennartcl.c9.io would have looked too awkward :) Each instance can have its own database with user names and workspaces. And each workspace runs in its own container.
In this case the tech team recently switched to Ghost for blogging and didn't realize that it doesn't automatically scale images when you upload them :)
You have good eyes :) The screenshot uses the "legacy" white theme that didn't have the flat look yet. It did have a few more dark colors at the edges, which is why it was used for this screenshot. We plan to work with our designer on darker versions of the flat light theme. Until we release those, I can recommend using something like f.lux (https://justgetflux.com/) to make it nicer to work with bright web sites and applications in low-light conditions.
Ahh Enterprise. Protip for anyone applying for an enterprise job: just copy-paste https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... when they do the mandatory fizzbuzz test in the job interview. And then complain in the github issue tracker if you didn't get the job.
As you can imagine we're getting a big load of traffic on release day. Which is fine; we have many servers hosting these containers. Some new ones are being spawned as the traffic increases. What we're finding now, though, is that we need to tune our load balancing logic, especially for the scenario where many new users show up. This requires the use of some other metrics than the "normal" scenario with many users leaving their workspace for several hours and then coming back. Right now there is one host in particular that has more users on it than it reasonably should. But, in short, we're working on making it better :)
Yeah, looking at the behavior of the machine I figured something like this was going on. It doesn't help either you ops team either having made front page on HN =)
That said, poking around I realized I can create and edit projects on my own server. I just spun up a 2G droplet on digital ocean and was playing around with the SSH connector and i am beyond impressed. Ideally I'd prefer to manage my own system resources, but being able to drop in and work on my project from any browser on hardware that I can control, upgrade and allocate is very nice and feels more sustainable at least for my case.
