I really hope that the Cloud9 service keeps running, and maintains the free version that it currently provides. I have been using Cloud9 with the Michael Hartl Rails Tutorial to teach new programmers the basics of programming with Ruby and Rails and it has greatly reduced the friction for them to start learning.
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.
Cloud9 has been a great partner to the Rails Tutorial, with their custom Rails Tutorial workspace allowing readers to spin up quickly at the beginning, while also maintaining state if they need to take a break. It's also enormously less overhead that downloading and installing a virtual machine.
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!
Wouldn't virtual machine basically do the same thing? I've taken some classes where teacher gave us an image where everything was already installed and configured. Everything went smoothly.
However, Cloud9 is much more convenient since it runs entirely on browser but VM solution could work in case C9 discontinues its free tier.
>I've taken some classes where teacher gave us an image where everything was already installed and configured.
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).
People forget the bit about poor performing machines. Developers with tech jobs often have high end machines provided to them. Many students do not, especially at public open-enrollment places. They come with whatever they have, despite recommendations from the program they enter.
This is also a reason that Cloud9 makes sense for us. The group I work with is focused on teaching programming to people who aren't traditionally represented in software development and sometimes they don't even have their own computers and have had to borrow a computer from a friend to do the work.
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.
>setting up the perfect dev environment takes so long
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.
Those tech companies should also provide high end machines to developers. I'm glad the last two places I've worked provided high end MacBook pros but also allow devs to use their own machines so inevitably there are a couple of Linux and Windows folks.
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
Just got back from paternaty leave and got new MacBook pro. Not sure if got lucky or this will be common practice. I'm from the IBM corporation. So one should not generalize ;) P.S. I guess only people who get crappy HW complain and this creates the ilussion that all corporations give crappy HW.
I think that the future is having not one but many workspaces. If you review a MR? Start that workspace. Help someone with a question? Login to their workspace. In GitLab we want every issue and every commit to have an IDE button https://gitlab.com/gitlab-org/gitlab-ce/issues/12759
BTW congrats to the Cloud9 team. They made a great product and selling to Amazon will ensure it lives on.
Yes, we think this will be great with a container scheduler. The IDE, Review Apps, and Autoscaling CI runners are a great for a container scheduler. We're currently working on making GitLab run great on Mesosphere and RedHat OpenShift, and plan to add others after than.
Creating a C9 environment takes just a few seconds and once that's done I can work anywhere. It takes all of that setup away. I can create one at work to screw around with a Node module, go home and play with it more on my desktop, move to the couch and use my Macbook, go on the porch to smoke a cigarette and use my Chromebook... the only overhead is a browser tab.
Agreed. In a lot of my college courses, the professors provide a VM which is completely set up for development. That means that anyone who just wants to start programming can use the VM while everyone else who wants to setup their local environment can do that. I think it's a great solution.
I'm a lecturer myself and am curious: How do your lecturers deal with the situation that students have at least three different operating systems (LINUX, Mac, Windows)? Setting up a VM will make 2/3rds cringe in my experience - setting up three VMs is a lot of work.
We use VirtualBox in our courses since it's a single platform that runs on all 3 major operating systems. Chromebooks are still an issue, but few enough people have those that we can basically just classify them as unsupported. There's still some setup effort, especially on Windows machines that ship with hardware virtualization disabled at the BIOS level, but it's a much simpler way to get 1000+ students up and running quickly than trying to have everyone setup local dev environments.
I'd say that most students running Linux opt to install their own development environment so installing the VM for them really isn't an issue. Either way, it's much easier for the professor to spend a class showing people how to install VirtualBox, and then the class VM than showing them how to install an entire development environment locally.
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.
unless I'm misunderstanding the question, I don't think this is going to be an issue.
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.
I like the vagrant-ish approach (just, not using Vagrant, shared folders are way finnicky in many different circumstances and it just really defeats the purpose of the tool if you aren't paying extra $$$ for the VMWare provider), personally. May not have been a classroom setting, but when I was training one of our new developers who had 0 Python or Linux experience (we're mostly a .Net shop, wasn't a hiring criteria) I had him install Fedora Server (CLI-only) in a VirtualBox VM. We then used the built-in deployment and remote execution / debug facilities in PyCharm Professional to test code inside a sane environment (because installing psycopg2 on Windows is not sane) while he was able to use his familiar desktop to actually do everything else, after setting deployment up it was pretty much transparent.
Where feasible, I think the "code locally, run remotely" concept works quite well, especially as most IDE's support at worst FTP upload.
Unless something has changed since last year, it is not truly "open source" if you're going by the Open Source Initiative's definition of "open source".
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:
In my university we have been using remote VMs with a GUI (e.g. Windows) for more than 10 years. We need to this with several softwares due to license restrictions.
Also worth a look depending on your needs:
https://codenvy.com/ (based on open source eclipse che IDE)
http://www.koding.com/ (easy hybrid local IDE and/or cloud IDE integration)
Sure it's "FREE" - becasue every time you use it, you will be consuming compute from your AWS account. That is my thought. AWS would not do this if it did not make them money. It is not just to be cool.
Just a hair under $5 a month, but unless you have a reason to deal with AWS complexity, you're probably better off with something like Digitalocean or Vultr for the same price and less surprises.
Which you can also do at Digital Ocean (note: you have to take a snapshot, and destroy the droplet in order to suspend billing).
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.
It's also only 512MB of RAM. For a dev box, m4.large spot instances work really well price-wise too, especially if you stop them when you're not working.
I think you should learn how to install a program and even compile a program before you make one yourself.
If you learn these basic skills it will be easy to take up any programming language.
Developers are quite conservative of their environment, but a cloud IDE could be awesome.
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.
This is a great idea. It makes much more sense to run your tests in the cloud than on your local machine. I don't think it can be done 'as-you-type' due to resource constraints. But I do think it can be done pre-commit. As a programmer I'm waiting for my tests to finish for hours per day, leading to a lot of inefficient multitasking and distractions. Obligatory adapted XKCD http://www.codeproject.com/Articles/381622/Unit-test-and-the... If we can improve this it would be an amazing thing.
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/
> I don't think it can be done 'as-you-type' due to resource constraints. But I do think it can be done pre-commit.
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.
If you restart the tests it indeed doesn't matters less. Currently GitLab doesn't allow for an easy cancel and rerun I think. Also keep in mind that that testing can keep over 30 CPU's busy for 5 minutes. I think it makes more sense to start that when a human indicates it. But we can also consider 'restart as you type' and 'restart when you save'. Thanks for your suggestion.
That would be nice! For now we're offering static .gitlab-ci.yml templates for many languages in the interface itself so you can easily start. Making plugins is a larger undertaking.
Does a cloud IDE work well with a flaky network connection?
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.
I haven't tried running C9 in a connection that intermittent or totally offline, but it does work well for hopping on/off across networks without losing local state in the browser.
Just tried C9 again -- You can change text in open files, but you can't open new files (doesn't seem to cache everything) and I couldn't refresh the browser view of my web app. To be fair, my app pulls some assets from CDNs, but if C9 gave me cached versions or just failed to load them I could have kept working. I'd say at this point, fully offline is too limited... at least if your use case involves many files and building web apps.
> 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.
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?
> You're telling me rsync already does everything that I want to do, when I'm trying to describe Dropbox.
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.
Good quality ingredients is the most important part, some chefs would say. You're right, but all you'd have to do is build an opinionated "skin" over Emacs, bringing together and properly configuring existing plugins, writing some new ones, and packaging it nicely.
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).
Eh.. what? Cloud9 is the reinvention of the wheel. That's the point you missed. With far fewer features, it just happens to be packaged together nicely to suit a particular purpose.
Cloud 9 is one of many. In 3 years you won't remember the name.
It might be, but so was google. In addition, some of the greatest software is nothing more than bundling the right components together that existed before. Microsoft Office is not exactly unique, emacs can do that and was available well before it (emacs can do everything!). Wordpress is not really innovative, it's just a collection of things others already had, yet it is huge now. Point is, Emacs is missing to much to equal cloud9 right now. It might all be somewhere, but it isn't readily available in a form users of cloud9 would like.
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.
What if he doesn't want to spend the next 6yrs learning Emacs?
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.
>> 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.
> > If something is quick to learn, by definition there can't be much substance to it.
> 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.
As someone that's tried many times to learn Emacs, I found Vim's basic features a lot easier to pick up.
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 have more or less the same problem coming from vi(m). I forced myself to use Emacs for about 2-3 months to get past the "this is hard because it is unfamiliar" stage.
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.
At the risk of sounding precocious but I doubt a novel programmer today has as much time for a project as the folks had back in the 70s and 80s. Development cycles have gotten much, much shorter. And there are already numerous tools which you have to learn for an efficient workflow, like build and testing tools, code repositories, etc. Every bit of time saved in dealing with your environment rather than the actual programming problem at hand is very valuable nowadays. Remember software has always been about raising productivity, not just of an industry but of the developer himself. 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.
> And there are already numerous tools which you have to learn for an efficient workflow, like build and testing tools, code repositories, etc.
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.
I think it's clear to everybody here that you can integrate any type of functionality into emacs. But if most new programmers prefer browsers, then that's what they are going to use... Maybe they just prefer building tools on top of javascript/css (where they can create actual GUIs) rather than lisp. For most programmers this is kind of a moot discussion because usually you don't get to choose the tools yourself and have to make do with what's supported. On a side note: Your TRAMP teleporter appears to use rsync most of the time anyway ;)
> But if most new programmers prefer browsers, then that's what they are going to use...
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.
> Anyone who prefers JavaScript to Lisp or SmallTalk is just wrong.
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.
> the trick is to avoid falling into the Smug Lisp Weenie trap.
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.
One of the most important metrics for a language is the number of people using it.
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.
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.
It's funny that you use the 2 lb Macbook as an example. Mine has a terrible problem with its wifi, requiring me to restart it every minute or so. It's unusable with Cloud9's IDE.
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.
Hyperdev does the cloud IDE thing pretty well; I spun up a half-serious prototype of a web app in a weekend, and sitting down at any nearby computer to hack / run / test really was a joy. I even logged in from my iPad to fix some css (not painless, do not recommend, but it worked.)
Nothing to install, no environment to configure, just log in and start editing.
I remember trying it, and Fog Creek is a company I really like and trust, but it's hard to tell if they're interested in turning HyperDev into more. I want it to be a fully professional development environment, and today it's "JSFiddle for backend".
Side note: I have really wanted to get this _exact_ testing setup with aggressive parallelism running on a large Django app.
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.
Another thing I've always wanted is when working on two feature branches, or a feature branch and separately a hotfix branch -- to leave my open files in the IDE, virtual environment, git untouched and have both co-exist.
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.
Once fully integrated with AWS, this could offer a rather exciting, low friction way to work on the platform. Using Cloud9 to build, test, and deploy Lambda functions from a single interface with all the auth stuff dealt with automatically.. you could have some powerful APIs running in the cloud very quickly.
(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?)
The last thing this world needs is mission-critical software edited willy-nilly through a "convenient" web browser interface. We as an industry can barely put our pants on in the morning on the best of days, and now this.
I'll counter with the suggestion that nothing about how you access an editor should impact your SCM process. Cloud9 has a terminal to run SCM tools and a light-featured Git UI if that's your thing.
You're right - in an ideal world. Somehow the drive for adoption and market share seems to counter such common sense, resulting in the "get started quick" camp running production systems.
Agreed. IMO it's always during an emergency where it's a decision between fixing the server in 20 seconds, or 5 minutes via the normal deployment pipeline.
I'm including a continuous integration step as "normal deployment pipeline". Probably code review and other steps as well. The point is emergency is always --forced.
That Lambda use case makes a lot of sense. The editor they have in place for Lambda right now barely exists. You can't even use it if you go the upload the build artifact as a zip route.
I've discovered C9 while viewing coders working via Livecoding.tv.
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.
I fail to see how it's advantageous over just having a shell account somewhere free like SDF though. Do young developers just want to interact with everything through the browser?
Failing to understand that different people have different preferences isn't a terribly interesting stance to take in public. These sort of sentiments are better worded as a search for knowledge, instead of this sneer.
You are the one sneering. "Failing to understand" is a completely respectful stance. It places the lack of understanding on the person saying it. It leaves open the possibility that the person saying it is wrong. It's skeptical but not without a degree of humility.
This is opposed to a straight up judgement, like what you have just done.
A browser is much easier to use. Every computer has a browser and no place blocks said browser. This means that when you're not near your dev machine, you can easily use another machine to log on, regardless of what software it has and which ports are open. As a bonus, you get a fullblown IDE with all your serverside dev tools (Node or Rails etc) ready to go, without any configuration or installation of packages.
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.
> A browser is much easier to use. Every computer has a browser and no place blocks said browser.
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...)
I used to volunteer teaching coding to youths (teens in highschool, mostly) and I tend to believe this is the case. Though I think it's driven by the fact that it's user-friendly to set-up & use vs. alternatives.
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.
> I used to volunteer teaching coding to youths (teens in highschool, mostly)
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.
That's new and perhaps a bit orthogonal to the argument here. Perhaps it rules out C9 as an option now, but the point remains that development on C9 was much simpler than all that setup stuff you have to do for a VM.
Somehow we are evolving beyond the PC era by going all the way back before the PC era. The only difference: tty replaced by browsers.
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?
Everywhere that provides internet access will give you a browser, where they may not give you a proper SSH program (or worse, they'll block everything but 80/443 outbound). This happens with a lot of cyber cafes, free wifi hotspots, and so on.
> (or worse, they'll block everything but 80/443 outbound)
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 think younger developers have zero tolerance for lengthy configuration steps. Whether it's a build system that uses XML and is hard to grok or provisioning cloud services with the terminal, it's seen as a waste of time and ripe for optimization.
I don't understand e-sports teams. They're not representative of a geographical region and a "team" can actually have players on multiple games. It's like if the New York Yankees were just the Yankees and also played football, soccer and basketball. I don't understand the convention for how spectators are intended to root for a team. I get that this thing in regular sports for rooting for the team closes to you is arbitrary, but at least it's clear fun way to be a part of it.
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.
> I don't understand e-sports teams. They're not representative of a geographical region ... I don't understand the convention for how spectators are intended to root for a team.
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.
>I don't understand e-sports teams. They're not representative of a geographical region [snip]
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.
There are geographical regions in League kinda, they're just country/continent size. I enjoy watching the American teams try to compete with other regions (Europe, Korea, China etc.) People generally just root for their region to do well.
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
In esports it seems to me like there is more focus on the personalities than the teams. I liked C9 because of Hai and Balls. I liked TSM because of Dyrus. A lot of people like SKT because of Faker, the unkillable demon king[1].
> 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.
This holds true for traditional sports as well. A number of people will follow "their star/their player" wherever they go. Their favorite quarterback was transferred to a new team? That's their favorite team now. The loyalty isn't to the specific team - it's to a specific player or specific players.
Seems like a smart move by Amazon if they integrate cloud9 as a standard service.
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.
Acqui-hiring at its finest. Amazon just wants to get Surefour.
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.
I assume they will also be changing their hosting over to AWS soon, so they can remove this bit from their features page.
> VMs hosted on Google Cloud
> We know that latency is important and Google knows how to deal with global availability. This is why you will get all the benefits of Googles infrastructure for free.
For running a developer event like BattleSnake.io, C9 is amazing.
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.
Even the best job? Because working for them was the worst work environment I ever experienced in 15 years of employment as a software development engineer.
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.
Cheap prices for the customer equal low pay and bad working conditions for the producer. Same is true of Wal-Mart... look into all those Chinese mega-factories where all that stuff is produced.
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.
Not sure what team you were on, but in my time at Amazon I never saw a company whose teams were more in-sync in terms of process, tools, frameworks, languages, etc. Say what you will about the work environment, but it's saying something that with the churn you mention (which is real), they are still able to deliver consistently. It's a well-oiled machine.
I worked for AWS. I wont say much more. The average employee churn stats speak for themselves. Amazon burns folks out. Uses them up. Not like the valley at all. Leadership principles [1] door desks, bezos cult.
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.
Nice hashtag. This isn't twitter though. Ive worked at exactly 17 startups. AWS was a steaming pile of sh!t with robotic middle managers, most on visas from the curry capitals of the world. Theres no necessity for the same exact language to be used. But when each team is just mavericking their own thing hoping it gets picked to be added to "the panel" you get a grab bag of absolute shit. If only you saw the code behind these services....
I absolutely love the Cloud9 IDE. I've been using the source download to host it directly on my development VM as well as in the cloud (using Digital Ocean and CloudAtCost).
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.
"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..."
I started using Cloud9 a few weeks ago, and my productivity running an interactive visualization app has gone way up. Cloud9 has the best autocomplete ever, and it 'just works' after you do a little environment setup in your included ubuntu instance. Any concerns I had were not a problem, like every day or two the cloud9 window crashes, but when it reopens the cursor is in the exact same place and all state is maintained. I don't even get that locally across reboots!
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.
Congratulations C9. My team uses C9 literally all day every day, and I hope this only means you'll have more resources at your disposal for faster iteration.
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.
Ever since they released Salesforce.com support C9 has been my savior from the awful "Developer Console" and the oft buggy and janky Eclipse-based "Force.com IDE". I will be very disappointed if this is nothing more than an acqui-hire :(
Remember Twitch, IMDB, Zappos... Amazon doesn't have a history of aqui-hires. Sure, they are getting some talent but since there's no obvious AWS competitor to C9 they would be crazy to shut it down.
That was your original point, but the person replying to you made a counterargument to your assertion that you don't see any reason for them to discontinue the service - that maybe they are after the team and their knowledge, rather than the product. Maybe Amazon want them working on something else.
C9 is my favorite web IDE. Being open source made it so much better than their competitors because you could install it locally to take advantage of your own hardware. It's really cool that they got acquired vs the fleet of mostly proprietary alternatives.
I tried looking at the github project - can you self-host it in the sense that you could set it up on a server in your home, and use it without needing access to the Internet?
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?
HA! Just yesterday a friend wanted to bet that they'd be soon acquired by GOOG/MSFT!
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.
I've always been intrigued by Cloud9 and its ilk but can't figure out what is the best thing to do on it.
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?
I've used Nitrous and Cloud9 both quite a bit... I tend to prefer C9 for Web Dev and Nitrous for full stack Ruby dev.
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.
The current editor for AWS Lambda functions is nothing to write home about and has some really severe limitations; for example you're unable to edit any code that uses more than 1 file (that has to be uploaded in a zip every time).
Having a high quality editor built into Lambda would make it so much easier to work with.
Congrats to the team! My first node.js experience was with Cloud9 IDE and the experience was great. I built a real-time multiplayer Bomberman clone extremely fast and it definitely helped me get hired in my past two jobs.
I like this. When testing my cloud9 account I thought it was a still rough edged proto-type of the future. I wasn't ready to change my workflow, but thought very interesting.
Does anybody else think that Microsoft might build a similar web based Visual Studio soon? They already have their Visual Studio Code that's built with web tech, and a bunch of web based Office apps. Combine that with Azure and they basically have the best position in the market if they so choose. I'd probably still prefer the native VS though.
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.
It definitely does a lot more than when I first looked into it. Someone tuesday night was trying to get a bootstrap repo using webpack dev server on cloud9. She had a local node install, so i had her use that instead, simply because I wasn't familiar with c9. She showed me her node+react app fully running on it though, which I thought was pretty damn cool.
Started with Cloud9, moved to Nitrous and ended with a server with vim + tmux on DigitalOcean as my instant-on IDE from everywhere. I find this superior than former ones: cheaper, more powerful, more flexible and somehow faster/more adjustable for my needs. Still Cloud9 and Nitrous were my gateway drugs for cloud coding.
I have not used c9 yet so I can't attest to how good it is, but I've seen a lot of beginner webdevs use c9 and lots of them only have good things to say about it. So let's hope amazon doesn't ruin things here.
This will be a great way to connect to individual EC2 instances. You'll be able to automatically get a shell, a tree file browser, and a text editor all in one webpage without have to fiddle with anything.
Its cool but since i live in emacs having a tiny aws reserved instance for development is a cheap way to get a dedicated linux machine connected to the web 24/7
Why do you say that Eclipse Che doesn't support docker-based projects? You can run Che in privileged mode, which lets your Docker workspace build and run other Docker projects.
> 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?
The reason my team uses C9 is it facilitates remote pair programming in a really nice way. That's the main purpose of it for us.
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.
This is nice. But then again, how do you know when the other person is finished editing so you can run your program? On second thought, ssh and git seem more practical.
It shows you when the file is being edited, when it has unsaved changes, and when it's been saved. It also has a linter that shows you if there are typos. It's a full fledged IDE. It works great.
>Also, I could just ssh into my server and start an editor there.
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.
> 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
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?
Using Firefox/Chrome on a linux box doesn't really compare to getting a dev environment setup.
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.
You could also just start an AWS server, upload an image containing useful tools such as an editor and a webserver, and teach them to use ssh. All could be done within an hour or so. I don't see the big advantage of Cloud9.
well, i just tried it. amazon aws is a hassle to setup. especially figuring out how to qualify for the free tier. its not just a "gimme free access already".
cloud9 on the other hand took me about 3 minutes to create an account, django workspace and to start developing with it.
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.
You are right. I was thinking about my previous statement later on and realized, that it is meant and is able to fully replace standard IDEs. What I meant was more like "you can keep your IDE if you like it" type of think.
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.
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.