Honestly, there are plenty of solutions to this. You could:
* Push more often;
* Backup your hard drive at least once every 12 nanoseconds;
* Put your laptop in a [hermetically sealed plastic bag][laptop ziploc].

While ~~all~~ most of those are valid solutions, I've got something slightly different. Instead of trying to protect your computer, why not stop relying on it all together? That's right, my digital nomads. This *one amazing trick* will allow you to eliminate your reliance on a single device, opening up the possibilities for you the next time your computer *literally catches on fire*.

:::figure
![My real computer catching on fire.][my computer on fire]
::figcaption[My very real computer catching on very real fire.]
:::

## Enter `code-server`
[`code-server`][code-server] is a magical piece of software from [Coder][Coder]. It allows us to run [VS Code][VS Code] on a cloud server, meaning that we no longer have to worry about maintaining our physical machine! Let's take a look at some of the massive benefits of using `code-server`.

### 1. It runs in the browser!
Because `code-server` runs in the browser, you can use it from *any device with a modern browser.*

**Chromebook?** No problem.

**iPad?** Doneskis.

**Raspberry Pi?** You know it.

**Palm Pilot?** Yea- uh, well… I did say *modern* browser. 😬

The added benefit here is that even if your device has limited resources — low RAM, tiny CPU, no *NIX environment — you'll still be able to work on your projects!

### 2. It has all of your favorite extensions!
Not only can you use VS Code in the browser, but you can also still use most of your favorite extensions! As a JavaScript developer, this is one of the most important parts for me.

NOTE: The `code-server` marketplace is more limited than the marketplace for VS Code because of Microsoft's Terms of Service, but if there's a missing extension, you can always request to have it added!

### 3. The built-in terminal works!
The `code-server` terminal works just like you'd expect! If you need to run your app, install new packages, or `cat` your SSH key, the built-in terminal has you covered. It works exactly like the terminal in a local installation of VS Code, and from it you can perform any task that your user is allowed to do!

## Conclusion
I've been using [`code-server`][code-server] for a little over a week now, and it's just a joy to use. My laptop finally has enough storage space to install that update I've been clicking away for months *and* my personal development pipeline is faster than ever! While those plastic laptop baggies might be a pretty solid back up plan, the best solution is to just get your code off of your laptop!





[my computer on fire]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F92456147-f514-4ec3-8b63-6aec6ab7032b%2Fmy-computer-on-fire.gif?alt=media&token=69cc0d49-0c4c-4c10-870c-87ff9017b2ba "Enjoy this real clip of my real computer catching on real fire. 🔥"
[code-server]: https://github.com/cdr/code-server "code-server repository on Github"
[Coder]: https://coder.com "Coder website"
[laptop ziploc]:  https://www.ohgizmo.com/laptop-ziplocs-let-you-surf-the-web-in-the-shower/ "Laptop Ziplocs Let You Surf The Web In The Shower"
[VS Code]: https://code.visualstudio.com/ "VS Code website"

What would you do if your computer caught on fire?

I posted a gif of some new game dev work, and the amazing [@TimBeaudet][Tim Beaudet's Website] asked me a few questions about what I'm working on.

:::figure
![Screenshot of the MOAR game, specifically the quick stats UI which displays the character's name, current health and mana, and avatar.](https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F15263bd8-049b-495f-bd2c-f182101f329b%2Fcharacter-preview.gif?alt=media&token=f5667cd4-9d2f-40b6-bd7c-8b637a6fd93d)
::figcaption[Screenshot of the MOAR game, specifically the quick stats UI which displays the character's name, current health and mana, and avatar.]
:::

## Is it a big idea?
Holy crap yes and simultaneously not even a little bit. 🤣

*The story goes something like this...* Early last year, I woke up from a weird dream at 4am and had the code in my head to build an inventory management system in JavaScript. I snuck down to the office and wrote it all out. I was pretty happy with my creation, so I figured... why not build the rest of a game? And so began my first *real* foray into game dev.

## What was learned from Attempt #1?
My first idea was to build a simple game, then expand from there. I was heavily inspired by CrossCode and Moonlighter, so I intended to dig in with a game that combined some elements of both of those. I reached out to an artist friend of mine to see if he was interested. We started working together on some worldbuilding, some art, and developing the main story arc of the game. The idea was to build this region that was cut off from the rest of its continent. If the game turned out well, we could build the rest of the world on top of the engine and the world (heh) would be our oyster.

There were two roadblocks that prevented me from moving forward on that attempt. The first was that I wanted to go in a pixel art direction, and my artist buddy wasn't into it. He produced a couple gorgeous pieces of concept art for me, but when he tried converting it to art we could use (I had decided I wasn't married to pixel art, he could kind of do whatever) he lost motivation.

The second roadblock was game physics. I had built my own game engine, and I ran into a thousand issues when I tried to reconcile the renderer with the physics engine. That killed my motivation and I shelved the project for a few months.

## What was learned from Attempt #2?
Several months later, I dug into my second attempt because I was itching to get back to doing some game dev. I had decided I wanted to fiddle with an MMO and net code (because why would I **decrease** the scope? I mean c'mon...). I grabbed some free art from OpenGameArt.org (artist CalciumTrice, who I absolutely adore) and threw stuff together. The net code was surprisingly easy. I knocked all of that out, but then I ran into new physics engine issues (HOW ON EARTH DOES A RIGID BOX SQUEEZE THROUGH AN IMPERCEPTIBLY SMALL HOLE‽). After smashing my head against that issue for a couple of months, rewriting both the renderer and the physics code multiple times, my motivation was shot.

## Attempt #3?
Alright, here’s the setup:

> You’re on a farm. Somebody has asked you to go collect some logs and bring them back to the farm. Go do that.

The story isn’t exactly robust, and that’s okay. The plan is to finally get a tiny functional prototype done and get the gameplay to just *feel good*. From there I can turn the game into whatever I want. I’d like to revisit the larger stories I wrote for the previous two attempts and merge them into something that can drive development for this latest attempt, but *everything* is up-in-the-air atm.

## Takeaways:
* Don't allow people to engage in things if they seem hesitant. They don't want to do it!
* Physics are hard.
* Scoping down is *holy bananacows important.* Large scopes make it really difficult to focus on the basics.





[Tim Beaudet's Website]: https://timbeaudet.com/

Making a Video Game in Zero Easy Steps!

[Ana Tudor][Ana Tudor Twitter] asked this morning about using the Chrome DevTools for testing CSS performance:

::tweet{id=1237009588664352771}

Chrome's performance tools have come a loooong way in terms of measuring performance on all sorts of scales, so I figured I'd take this opportunity to dig in and better educate myself on how to use them. What follows is the result of my endeavor to figure out what these graphs and charts mean. 😬

## TL;DR

Honestly, I'm not sure the Performance tab has that much to offer in terms of debugging CSS. It may be able to help define the *when*, but from my cursory dive I don't see it helping me identify the *why*. If others have more insight, I'd love to have somebody prove me wrong. 🥰

## Okay, what are we looking at?

This is a screenshot of the Chrome DevTools on the [about][about] page. This page has a decently meaty animation when it loads up, so I figured it'd be a good place to test this stuff out.

:::figure
![][devtools performance screenshot]
:::

## The Timeline
The first thing I did was try to understand what each section of the Performance tab is for. I started with the timeline at the top of the pane.

:::figure
![][devtools performance timeline screenshot]
:::

The timeline looks *super* interesting. At first glance, it seems like it's able to enlighten me with all sorts of valuable data. At second glance, I realize I find it *completely unintelligible. After clicking at random and hovering around a bit, I think I was able to glean some details on how to use it to track performance.

First off, you can grab the handles at either end of the timeline and drag them in to minimize the amount of data that's currently under analysis. This alters what you see in the rest of the tab, too.

Second, Chrome seems to have recorded what the site looks like as it renders. Hovering over any point on the timeline will show you a thumbnail of the site at that precise moment. This feature is what we in the industry often refer to as *hella cool*.

:::figure
![][devtools performance timeline gif]
:::

I've now minimized the data under analysis by using the thumbnails and pulling the handlebars to the beginning and end of the animation I'm wanting to analyze. 😎

### The... Other Timeline?

Okay, so below the complete timeline is another timeline with much more in-depth information. Again, this looks *super* useful, but I'm not entirely sure what to make of it. One thing I will say is *do not scroll while hovering this timeline*. It turns out that scrolling adjusts the selection in the full timeline up top. FML.

Okay, I'm going to try to reduce scope so I only have to understand a part of this, rather than the whole thing. First thing, I'm going to disregard the `Network`, `Timings`, `Chrome_ChildIOThread`, and `ThreadPoolForegroundWorker`. I'm sure they're all useful, but they don't seem immediately related to what I'm interested in.

Clicking the arrow to open the `Main` section is... holy cow it's noisy. When I hover over it I see a lot of things like `Schedule Style Recalculation` and `Recalculating Styles` (I really want it to say `Reticulating Splines` in here somewhere...), so I'm sure this something I'm going to dig into, but I'm going to put it off until last. The other pieces look *way* less noisy.

Opening the `Raster` section, I feel like I'm getting somewhere. I see two things underneath it — `Rasterizer Thread 1` and `Rasterizer Thread 2`. With all this talk of threads, I suspect this whole graph is about the browser's processor utilization. Most of these categories are probably related to the CPU, though there's a separate section specifically for the GPU that I'm excited to get to. Anywho, the `Raster` section. By definition, rasterization means:

> "to convert into pixels for screen output; convert into a raster image"
> *via [The Free Dictionary][rasterize definition]*

So this is very probably referring to the browser taking already generated images and preparing them, pixel-by-pixel, for rendering.

Next, I'm going to skip down to the `Compositor` section. There's only a single timeline underneath it. Compositing generally refers to taking two or more things and combining them to make a single thing. I'm guessing this is the browser taking the different pieces chunks of DOM, positioning them appropriately, then sending them as a single hunk to the `Rasterizer` to turn it into an image that can be rendered.

The `GPU` section is actually kind of disappointing. Similar to the `Compositor`, it's a bunch of blips on the timeline with no description. I was hoping it would give me some detail on what operations it was passing off the GPU, but nah. 😞

## The Overview
Finally, we have the donut chart at the bottom labeled "Summary".

:::figure
![][devtools performance summary screenshot]
:::

Looks like this is a breakdown of how long each of the performance heuristics that we're tracking took *in total*. Let's break down the legend here:

1. **Scripting** - It seems safe to assume that this is tracking the page's execution of JavaScript.
1. **Rendering** - I'm guessing this is a combination of both DOM rendering *and* CSS rendering.
1. **Painting** - I'd wager that this is related to CSS repaints, but honestly I'm not sure what the difference between rendering and painting is. We'll have to look this up next.
1. **System** - Probably OS-level things like garbage collection.
1. **Idle** - Time that the browser isn't doing anything or is waiting for something else to finish.

## Conclusion

So, I think all of the pieces of the timeline could be really valuable, but you still have to do a lot of work by hand. If you're working on some clunky CSS animations, the timelines could be super helpful to identify *when* your animation is getting wonky, though it doesn't seem to have any insight into *why* it would be happening. The overview seems really valuable for getting a quick look at the resources your app is using within a certain window, but I'm not sure that I'm going to be using it anytime soon.

One other resource that may be useful when you're digging into CS performance is the [CSS Triggers][csstriggers.com] website. It details which types of CSS rendering operations (`Layout`, `Paint`, `Composite`) will be triggered when changing each CSS property. You could use this — in conjunction with the `Performance` tab and looking at the styles on your elements — to try and narrow down what exactly is causing your animations to be clunky.





[about]: /about
[Ana Tudor Twitter]: https://twitter.com/anatudor "Ana Tudor on Twitter"
[csstriggers.com]: https://csstriggers.com/ "CSS Triggers"
[devtools performance screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-1.png?alt=media "Screenshot of the Chrome DevTools' Performance tab on https://trezy.com/about"
[devtools performance timeline screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-3.png?alt=media&token=3525e3ec-a631-4a0f-b263-69470a7d859f "Close up of the Chrome DevTools' Performance Timeline"
[devtools performance timeline gif]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-4.gif?alt=media
[devtools performance summary screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-2.png?alt=media "Close up of the Chrome DevTools' Performance Summary"
[rasterize definition]: https://www.thefreedictionary.com/rasterize "Rasterize definition in The Free Dictionary"

<trezy-who/>

<trezy-who/>

Latest articles