Mar 27, 2017Building Towards a Holistic Development Service
Software development is one of the first -- if not the first -- examples of what J. C. Licklider called the Man-Computer Symbiosis. A "cooperative interaction" between people and computers where the person is concerned in what may be classified as the creative aspect of the work such as setting the goals, formulating the hypothesis and evaluating the results while the computer does all the "routinizable work". This symbiotic partnership is especially effective for work that puts to the test our intellectual capacity like keeping all the moving parts of a large software system in our head. Or as Dijkstra warns us "the competent programmer is fully aware of the strictly limited size of his own skull". This begins to explain why software engineers are so passionate about their tools. From the good old editor wars to JavaScript fatigue, we're continuously adding and improving on our arsenal because this is the best way we know how to become better engineers. From a business point-of-view, it might also explain the seemingly sudden rise and growth of the developer tools market: hosted version control, infrastructure, devops and automation etc. Despite all this success I think we've fallen victim to the onetime useful Unix dictum Do One Thing and Do it Well. Roughly speaking, we separate our tools by development life-cycle stages: authoring, executing, testing, building, and deployment. Which limits how much information each tool has at its disposal and therefore how much utility it can provide. Sharing the work isn't easy. The text stream as the "universal interface" means that, for example, tools need to re-parse code at every stage of the life-cycle to extract whatever meaningful information it needs. In practice it means I can't upgrade to the latest release of my favorite programming language because I need to wait on all my tools to upgrade their parsers. And this is not a theoretic problem, consider the fact that the website that you're probably reading this on was authored in ES2016 JavaScript, parsed and compiled to ES5 and then parsed again and minified and then parsed yet again to finally run in your browser which most likely runs ES2016 (back full-circle). However, we'd like to take a stab at the problem from an angle that we, at Replit, are uniquely situated to do. Our mission is to make programming more accessible, so when we design we focus on the hobbyist and the learner (although a lot of engineers also get a lot of value from our service). This relieves us from the pressure of having to build tools that needs to compete and achieve parity with existing development tools. Our users are open to things that makes it easier for them to learn, play, and share.
- Nov 14, 2016
Learning Devops & AWS on the Job: Building and Scaling a Service
Or, what I wish you I knew before building Repl.it's code execution service new drinking game "name that AWS service logo" — TJ Holowaychuk (@tjholowaychuk) March 23, 2016 I, by no means, identify as a devops or even a backend engineer. Most of my professional experience has been equally split between frontend/product and developer tooling. I also primarily learn by doing and bias towards simplicity and MVPs -- almost to a fault. So when I approached building a service on AWS I took a very simple path and increased complexity as the service scaled up. Here are all the steps that I went through before getting to something that I'm not totally ashamed of. eval.repl.it
- Jun 24, 2016
API Docs
[Update Oct 2022: We have retired our API, we are excited by our previous work but we do not have the resources to support this at the moment.] Repl.it's code execution API is an HTTP and WebSocket endpoint that you connect to and send code to execute. You can connect from any device or browser and start executing code. This guide will describe the concepts behind the service, how it can be used, and provide a step-by-step guide for signing up and trying out the service! Code Execution You're probably here because you want to run some user code in an app or website somewhere. Our customers use the Repl.it API for many different things including: In-browser coding environments In-browser coding exercises