What's the secret recipe for code execution? I don't really think this is a secret thing... lots of websites probably have done something similar. Any idea?
I work at codecademy and in particular one of the two programmers working on code execution. It's going to be hard to give this question the answer it deserves without spending sometime going over many of the decisions we've made designing the system. Here is a very short list and in no given order:
1) Lightweight sandboxes: unlike many services we don't start full-blown VMs for each user to sandbox they're code and execution environment.
2) Persistent interpreter sessions and environments: Not having to suffer interpreter startup time each time you want to run a piece of code.
3) Websockets: Use of websockets on the browser to open a bi-directional communication channel with the server, which is much faster than ajax. Falling back to xhr-polling, jsonp etc. for older browsers or clients behind firewalls.
4) Output buffering: Stdout from interpreters are buffered and debounced.
5) Responsive server: This is basically like saying we did a good job programming our servers. We thought an event-driven server would be best for our use case (many child processes, idling connections etc.), but then you still have to do a very good job making sure you never block or do anything time intensive.
6) Easily scalable: Investing time in deployment and build process, setting up load balancers etc. allows us to bring new nodes fairly easily when we need them.
I haven't used the site before, are you asking about the content of the website and the training material... or are you asking about the actual website compile and display times?
If you go to Python and type in import os; print os.getcwd(); you can tell that they are not fooling users. The Python code is executed and returned. I am just surprised how fast they are able to run and return.
1) Lightweight sandboxes: unlike many services we don't start full-blown VMs for each user to sandbox they're code and execution environment.
2) Persistent interpreter sessions and environments: Not having to suffer interpreter startup time each time you want to run a piece of code.
3) Websockets: Use of websockets on the browser to open a bi-directional communication channel with the server, which is much faster than ajax. Falling back to xhr-polling, jsonp etc. for older browsers or clients behind firewalls.
4) Output buffering: Stdout from interpreters are buffered and debounced.
5) Responsive server: This is basically like saying we did a good job programming our servers. We thought an event-driven server would be best for our use case (many child processes, idling connections etc.), but then you still have to do a very good job making sure you never block or do anything time intensive.
6) Easily scalable: Investing time in deployment and build process, setting up load balancers etc. allows us to bring new nodes fairly easily when we need them.