Use codedamn playgrounds to build an amazing project

Playgrounds by codedamn are extremely powerful for a number of reasons. By choice, we have kept them very close to how your local development setup works. That means no unnecessary magic on your code layer, no code injections, nothing. What you write in the editor and what you run in the terminal is what gets executed.

However, this does not mean that playgrounds are not powerful. They are beasts. This is because these cloud development environments are:

Available at a URL – from any device, anywhere in the world
Syncs to AWS cloud securely.
Uses dedicated compute for your code only (no CPU sharing with a heavy chrome browser running on your laptop)
Can be easily scaled on CPU/RAM on the cloud
Works on mobile phones
Full Linux environments at your fingertips

In this article, let us explore how to use codedamn playgrounds efficiently to build an amazing project.

The Editor

The Editor in the playground is Monaco – a lightweight version of VS Code – the most popular text editor among developers. Monaco is both – lighter and most feature-lacker when compared to VS Code. This is because VS Code uses a few native Node.js packages that cannot run on browsers.

That’s okay – because we anyway do not want to compute and run too much JS on the client (we lose a lot of cloud computing benefits that way)

We use Monaco and restore important VS Code features with our light code layer. For example – multi-file support, basic IntelliSense in code, linking various Monaco models together on import and require calls in .js, .ts files, etc.

Most files in codedamn playground can be edited as regular text files using Monaco as the editor. The syntax highlighting and IntelliSense would work automatically. However, there are a few special files:

README.md
.cdmrc
Images
Binary files

Let’s start with the first type.

File: README.md

Note: Moving forward, we’ll have proper editing/viewing functionality for all markdown files

README.md file currently is hardcoded to be displayed as a markdown preview of the file. Currently, it is not possible to edit the source of this file from the Monaco view (you can, however, edit it from the terminal – more on that later).

This file is displayed as a formatted markdown preview. This is used mostly by the codedamn official team in starter templates, labs, etc.

File: .cdmrc

The file .cdmrc is a very important file for your playgrounds. This is the configuration file for codedamn playgrounds that control how your playground behaves. This is written in YAML. You can learn YAML syntax here.

There are only a few key-value pairs you can specify in this file. They are documented here. Let’s learn how you can work with .cdmrc with example configs.

Creating Terminals

terminal-one: echo "hello"
terminal-two: echo "world"
terminal-three: echo "user"Code language: YAML (yaml)

The config above will start three terminals as soon as your playground boots. Note that these commands run only once the playground is booted. This means that if you invite collaborators to your playground, and you’re already on that same playground (that already has executed these commands), they will not run again.

Currently, you can only specify commands for up to three terminals (with keys terminal-one, terminal-two and terminal-three)

Default Files

tabs: ['src/index.html', 'src/folder/script1.js', 'README.md']Code language: YAML (yaml)

The tabs field in the .cdmrc is an array of strings. Once specified, whenever your playground boots for the first time – it would open the mentioned files by default in the Monaco editor.

This is for a good UX when users don’t know what should be a good entry point for the project.

We at codedamn do this on our codelabs and some default playground repos. You can customize this behavior or disable it completely by passing an empty array [] or just removing the key altogether.

Live browser reloading

live-reload-browser: falseCode language: YAML (yaml)

Remember how I mentioned that we try to keep codedamn playgrounds as close as possible to your local development environments? That is great as it keeps you in sync with how things should work locally. However sometimes it is easier to have a little magic at hand – for example – reloading your browser anytime there is a change in your HTML file.

On codedamn playgrounds, when you choose a playground that uses html-css docker image as the base image, we automagically reload your browser window to reflect new changes.

This is great, however, there are some playgrounds like Next.js and React.js that also uses the same underlying html-css docker image. However, unlike plain vanilla HTML, CSS, JavaScript – those playgrounds do not need live reloading from us as those frameworks ship with Hot Module Replacement (HMR) or live reloading within their own source codes.

Therefore, you can disable platform-level live reloading using the syntax shown above.

The TL;DR of this block is – if you feel the embedded webview on your playground is refreshing on every change, you can disable it setting live-reload-browser as false

Run button

run-button: node $$fileCode language: YAML (yaml)

The run-button command in a playground does two things:

It makes a new button saying “Run Code” visible on your playground.
When you click on that “Run Code” button – it executes that command in the first terminal. However, we automatically run a CTRL + C sequence as well to terminate any previously running program. Therefore, anything running in the foreground on your first terminal would get terminated.

This is especially useful when you’re working with, say, a program that requires you to run the same command over and over again. You can open a C++ playground on codedamn and configure the command as gcc script.c -o script && ./script and every time you click on Run Code button, it’ll execute this script.

Another important thing to note here is the $$file syntax. If you’d like to run a command dynamically on the focused tab/active tab, you can specify $$file and we would run your command after replacing $$file it with the path to the file you have currently opened inside your Monaco editor on codedamn.

For example, if you’re on src/index.js file and your run-button command is node $$file, then when you click on “Run Code” button, we would run node src/index.js. If you change file and click on the button again, we’ll update the path again before running.

Browser Link

browser-link: https://codedamn.comCode language: YAML (yaml)

By default, we open https://<whatever-host-is-assigned-to-you>.codedamn.app:1337 in the iframe browser preview on the right. However, you can override the webpage opened on the right using the command shown above.

Note that because we use iframe to embed the window, it is entirely possible that a variety of URLs might not work due to x-frame-options set to sameorigin or deny. Read more on MDN.

Conclusion

Here’s a dummy config file that uses all the options we have currently:

# terminals
terminal-one: |
  cd client
  yarn && yarn start
terminal-two: |
  cd server
  yarn && yarn dev
terminal-three: echo "we're ready"

# other config
browser-link: https://wikipedia.org
run-button: clear && node $$file
live-reload-browser: false
tabs: ['README.md']
Code language: YAML (yaml)

Port Mapping

Port mapping on codedamn playgrounds is very powerful. Ports are how you can run different applications accessible over a network together on a single computer.

We currently provide you with two ports (port 1337 and port 1338) where you can host your HTTP or WebSocket services.

Note: Currently, we do not support any arbitrary TCP traffic on these ports except for HTTP and WebSocket traffic.

Every time you boot a playground, you get a unique hostname assigned to you (example: hello-world.codedamn.app)

This hostname belongs to your app as long as your playground has at least one collaborator online.

For now, these hostnames are temporary so please do not use them/hardcode them in your programs because your program would stop working the next time your playground boots afresh.

This hostname has two special ports – 1337, 1338. Anything you run on port 1337 and 1338 inside the linux computer provided to you would be mapped over to hello-world.codedamn.app:1337 and hello-world.codedamn.app:1338 respectively.

In other words, whenever someone visits hello-world.codedamn.app:1337, we would forward all the traffic to your localhost:1337 port. There are two main things you have to remember here:

We give you TLS termination (https support) automatically. This is mandatory and not bypassable.
This traffic passing currently works only for HTTP and WebSocket traffic. We would not proxy any raw TCP traffic (like connecting to MongoDB listening on port 1338 on the container, from your local computer on that hostname would not work)

The details of port mapping are provided to you in Settings menu as well:

Environment Variables

There are a bunch of useful system environment variables available in the codedamn playground.

PUBLIC_HOSTNAME can be used to get the hostname assigned to you to access APIs, etc. in browser (example value = my-domain.codedamn.app)
PUBLIC_PORT is the port with which the hostname is embedded by default on right (i.e. 1337 – hardcoded value)
SECONDARY_PUBLIC_PORT is the second port available (hardcoded to 1338 right now)

Browser Logs

Browser logs are important for debugging and knowing what went wrong. There are two ways you can work with browser logs when you use codedamn playgrounds.

The first way is you open the iframe window in a new tab by clicking on “Open in new tab” icon on the top right of the screen – on the right side of the URL displayed on the right window.

The second way is you use codedamn Browser Logs tab.

Again, I hope you remember that we promised not to touch your code – no black magic from our side. Therefore, we somehow need to work with you to patch your code to bubble console.log calls to the playground interface.

Fortunately, it is as simple as loading a script tag before any other JS loads on your page. This script tag is:

<script src="https://bit.ly/codedamn-web-console"></script>Code language: HTML, XML (xml)

This is a shortened URL to https://codedamn.com/assets/js/web-console.js which essentially loads a chunk of JS that patches your console inside your preview browser, and bubbles up all the console statement info to the IDE to be displayed in the interface nicely.

A huge advantage of this is that you can completely skip opening Chrome/Firefox DevTools if all you want to check is console, while developing your app.

Wrapping up

Playgrounds are extremely powerful and we’re working on pushing the limits to the edge. Your feedback is really appreciated in building the next generation of the development layer. Feel free to connect with us over discord.