It looks very nice indeed but I wonder why there is .net and not just c#. It might actually be better because this way you can have all the web functions too but might take a bit more for simple things.
It would be awesome to just open a project on github & run it without downloading / installing. Great tool to tinker & learn. Add some profiling tools to the mix while you are at it. Imagine you are trying to decide between 2 different libraries or frameworks. You could just fire them up in Github & try out for a bit before making up your mind. Would be nice to generate compile & generate binaries on the fly too instead of downloading them from 3rd party sources.
Runnable is a great example of a product that really understands their core use case and does it very well. They use Docker as the recipe-structure on the runner image.
For your use case, we have been rewriting Codenvy for the past three years, both the IDE and the underlying infrastructure. The new system now also uses Docker as a tool for recipe construction of builder images and runner images. We then layer on an endpoint structure that we call Factories, which allows for automatic environment provisioning inclusive of code (from git or svn), the builder type (mvn, gcc, etc) and the runner environment which can be a pre-packaged solution (managed by Codenvy) or a custom environment as defined by a specialized docker recipe in your project space. The factories are just URL formats to make embedding or sharing entire environments (for cloning) easier.
If you'd like early access to the next gen system, people can write me tyler at codenvy, and we'll get you hooked up. We've been in alpha since early Jan and will go public beta in another month or so. We are just cleaning up some remaining items.
It seems to be a mix of languages and frameworks. For example, it doesn't list Python, but it does list Django. No Javascript, but jQuery and Node.js (Angular programmers are out of luck).
Yeah, but node.js is a framework, not pure js, and I suspect it doesn't do DOM-related stuff. jQuery is probably better suited for general in-browser javascript.
This reasoning seems fundamentally confused, so I feel like clarifying some concepts:
On Runnable you can create basic client-side JavaScript files to be run in the browser (without jQuery) and do window and DOM manipulations.
Node.js isn't a framework for the browser (like jQuery), but a server application platform (with a bunch of objects and functions).
"Pure js" doesn't exist as an environment. It runs within a parent environment (e.g. a browser or a server) and manipulates the global objects in that environment.
JavaScript is just a language specification, and can be implemented in any environment. (For instance, it's implemented in Adobe Illustrator.)
Ok, got you. If you use the "Create New" button in the top right corner, you get the option to create a "JS" project.
The project template comes with jQuery pre-installed. However, it can easily be removed.
I guess the people behind Runnable assumes that it's more convenient to have to remove jQuery than having to add it for each new JS project, and personally I agree with that assumption.
I may be wrong here but to address a comment above, my hunch is this is spawning a light, short-lived VM for this, which doesn't eliminate security concerns but would be sandboxed enough to make it tougher.
I was trying to get some info on environment in C++ but unfortunately,
Yep, there's playpen[0] that's ultimately used as a security sandboxing. This is what's used on the new Rust playpen area: http://playtest.rust-lang.org/ (Not fully ready, still needs some beautifying -- that's why it's on playtest and not the play subdomain).
Even if the code is sandboxed, it's possible to run outgoing attacks from something like this. The same is of course true of traditional server rentals, EC2, and any other service that gives you an OS instance of your own. The difference, though, is those are (ostensibly) less anonymous.
Why crash the machine when you can use it? Let's say someone wanted to run a ton of background processes to make a ton of requests to some server for whatever reason.
You can actually create your own example with Erlang or Lua :) We provide a person VM for you to use and share. Simply start with a base example like (runnable.com/new/bash) install the compilers you need and click publish!
Best not to advertise compatibility with everything unless you are sure that it really is compatible with everything. Otherwise it is too easy to mislead people (who will load the site, check for their favorite language, not see it and never come back)
It's pretty strange to get root access to a server, even though it's just a Docker VM. We can install anything we want, compile any C code we want, DDoS and spam anyone we want... The machine is also crazy loaded right now, with 100% load on all cores (according to htop that I installed from the package repo), almost run out of RAM and disk space decreasing fast.
Yes, I'm from Runnable. People have tried fork bombs. We are pretty good and cleaning them up. Please do not try this and let other users enjoy the platform
Nice, but some users are not "honorable". And you make it super easy and quick to make accounts, no confirmation, just enter some email address. (not that i'm complaining about that part, i like easy signups... but it may open you to abuse).
104 comments
[ 2.9 ms ] story [ 99.8 ms ] threadLooks pretty cool!
Enjoy!
For your use case, we have been rewriting Codenvy for the past three years, both the IDE and the underlying infrastructure. The new system now also uses Docker as a tool for recipe construction of builder images and runner images. We then layer on an endpoint structure that we call Factories, which allows for automatic environment provisioning inclusive of code (from git or svn), the builder type (mvn, gcc, etc) and the runner environment which can be a pre-packaged solution (managed by Codenvy) or a custom environment as defined by a specialized docker recipe in your project space. The factories are just URL formats to make embedding or sharing entire environments (for cloning) easier.
If you'd like early access to the next gen system, people can write me tyler at codenvy, and we'll get you hooked up. We've been in alpha since early Jan and will go public beta in another month or so. We are just cleaning up some remaining items.
Edit: If you expand the list of supported languages, it shows Python too.
On Runnable you can create basic client-side JavaScript files to be run in the browser (without jQuery) and do window and DOM manipulations.
Node.js isn't a framework for the browser (like jQuery), but a server application platform (with a bunch of objects and functions).
"Pure js" doesn't exist as an environment. It runs within a parent environment (e.g. a browser or a server) and manipulates the global objects in that environment.
JavaScript is just a language specification, and can be implemented in any environment. (For instance, it's implemented in Adobe Illustrator.)
The project template comes with jQuery pre-installed. However, it can easily be removed.
I guess the people behind Runnable assumes that it's more convenient to have to remove jQuery than having to add it for each new JS project, and personally I agree with that assumption.
Hope this helps!
The target use case is interviews, but it works well for a wide variety of use cases as well.
They provide company accounts. Seems kind of nice to have a full working piece of code working within a few seconds.
I can think of stripe, facbeook or any other company that provides an api.
The only problem with a full working application is that it's easier to miss what steps should be taken.
I was trying to get some info on environment in C++ but unfortunately,
> Oh no, there's a problem with Runnable!
[0]: https://github.com/thestinger/playpen
* Got root in the countainer.
* You "know" where that is mapped to on the host, because it is based on the UID of the container which is set as the hostname.
* You configure a trigger to run a script, using that knowledge.
* Code happens on the host, outside the container.
But, that said, the attack works as specified against docker 0.11.0. Largely because guests do have sysfs mounted at /sys.
See https://www.destroyallsoftware.com/talks/the-birth-and-death... on taking this to an "extreme" -- linux, Gimp on X windows, even Chrome -- transpiled and running in a firefox tab.
What I'm actually interested in is how they suddenly got on nr 2 in google :-)
You guys have a very nice looking product.