Perfection enthusiast and byte craftsman in San Francisco, CA.
Interested in systems, developer productivity, and design.

[Github][] &bull; [Twitter][] &bull; [LinkedIn][]

[github]: https://github.com/justjake
[twitter]: https://twitter.com/jitl
[linkedin]: https://www.linkedin.com/in/jaketl



NextJS offers a great developer experience and impressive performance, but has
a number of frustrating limitations that make it difficult to deploy in
production: There's no way to plug in performance monitoring like Datadog APM,
or customize error handling to use a reporting system like Sentry, and logs and
errors are printed to STDOUT/STDERR unstructured with no way to customize them.

The strategies for hosting NextJS apps in production basically boil down to:

0. Make your site totally static, so that there's nothing to worry about. Use
   the static host of your choice. Give up all API features, previewing,
   regeneration, etc.
1. Deploy with Vercel, but give up all control over builds and hosting. No
   option to use Datadog APM or other dependencies that require an "agent".
2. Deploy manually with `next start`, but be blind to state of the system in
   production.
3. Deploy manually and use a custom server entrypoint to add error handling and
   performance monitoring, but give up performance and features.

## What we want

1. A way to load Datadog APM `dd-trace` NodeJS package before importing NextJS,
   so that dd-trace can inject performance monitoring into lower level packages
   like `http`.
2. A way to customizing logging so that logs can be parsed by our logging pipeline.
   Ideally, all logs would be JSON written to STDOUT or a UDP port.

## Why not use a custom entrypoint?

The "escape hatch" is to use a ["custom
server"](https://nextjs.org/docs/advanced-features/custom-server) entrypoint
instead of the recommended `next start` command, but this has significant
drawbacks, as the docs warn:

> Before deciding to use a custom server please keep in mind that it should
> only be used when the integrated router of Next.js can't meet your app
> requirements. A custom server will remove important performance
> optimizations, like serverless functions and Automatic Static Optimization.

Yikes; the whole reason we're using NextJS is for [Automatic Static
Optimization](https://nextjs.org/docs/advanced-features/automatic-static-optimization),
so this is unacceptable.

## Using preloading

The NodeJS CLI has an option to require a node module _before_ importing and
executing the entrypoint script: [`-r module / --require module`][rdocs]. If we put
our customization in a module that we preload _before_ `next start`, we can
work around many of NextJS's issues. We'll be able to use vanilla `next start`
self-hosting, but get to have Datadog APM, error reporting, and customized logging.

[rdocs]: https://nodejs.org/api/cli.html#cli_r_require_module

### 1. Create your preload

Create a `server-preload.js` file in your NextJS project root. Here's a
lightly-edited version of Notion's server-preload.js. Below you'll see how we
set up Datadog tracing and fix the logging situation.

<script src="https://gist.github.com/justjake/6fa39b07421a58ad58ff013b141b7172.js"></script>

(Not seeing a big code block? Try refreshing, or [click here to view the gist directly](https://gist.github.com/justjake/6fa39b07421a58ad58ff013b141b7172).)

### 2. Require your preload when you `next start`

Now you'll need to load your preload file when you start NextJS on the server.
Everywhere you have `next start`, replace with:

```bash
node --require ./server-preload.js ./node_modules/.bin/next start
#    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#    Load our preload before running `next start`
```

You may beed to adjust paths to fit your app depending on your working
directory where your app runs in production.

That's all there is to it!

Direct your questions/comments/concerns to [@jitl on twitter](https://twitter.com/jitl).


I just finished putting together a new home server. It's tiny. It's quiet.
It's simple. It's got a super-fast SSD, six cores, and a bunch
of RAM.

My goal is to never be frustrated by this system -- that's what makes it cozy.

##### Table of Contents

[TOC]

## Why build now?

Winter 2019 is a great season to build a new cozy home server. AMD, the x86 CPU
underdog, released a new generation of processors in July: the [Zen 2
architecture](https://en.wikichip.org/wiki/amd/microarchitectures/zen_2). AMD
has been the "value" choice for home system builders for a while, but with Zen
2, AMD has a considerable multi-thread performance lead while having lower
prices than Intel.

## Hardware



This is a 7-liter mini-ITX build that will comfortably fit in your TV media
center. Overall, my part choices are spendy. There's a few places one could cut
down that price tag.

| Type             | Item                                                                                                                                                                                                 | Price |
| :--------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---- |
| **CPU**          | [AMD Ryzen 5 3600 3.6 GHz 6-Core Processor](https://pcpartpicker.com/product/9nm323/amd-ryzen-5-3600-36-thz-6-core-processor-100-100000031box)                                                       | \$194 |
| **Motherboard**  | [Gigabyte X570 I AORUS PRO WIFI Mini ITX AM4 Motherboard](https://pcpartpicker.com/product/NQ7p99/gigabyte-x570-i-aorus-pro-wifi-mini-itx-am4-motherboard-x570-i-aorus-pro-wifi)                     | \$219 |
| **Memory**       | [Corsair Vengeance LPX 32 GB (2 x 16 GB) DDR4-3200 Memory](https://pcpartpicker.com/product/6rrcCJ/corsair-memory-cmk32gx4m2b3200c16)                                                                | \$140 |
| **Storage**      | [Samsung 970 EVO Plus 2 TB M.2-2280 NVME Solid State Drive](https://pcpartpicker.com/product/Fv8j4D/samsung-970-evo-plus-2-tb-m2-2280-solid-state-drive-mz-v7s2t0bam)                                | \$443 |
| **Video Card**   | [VisionTek Radeon HD 6350 1 GB Video Card](https://www.amazon.com/gp/product/B006V2IZ30/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)                                                            | \$68  |
| **Case**         | [Silverstone ML05B HTPC Case](https://pcpartpicker.com/product/J7mLrH/silverstone-case-ml05b)                                                                                                        | \$64  |
| **Power Supply** | [Corsair SF 450 W 80+ Platinum Certified Fully Modular SFX Power Supply](https://pcpartpicker.com/product/TxNv6h/corsair-sf-450w-80-platinum-certified-fully-modular-sfx-power-supply-cp-9020181-na) | \$100 |
| **Total**        | **\$1228**                                                                                                                                                                                           |

<small>
My [PCPartPicker Part List](https://pcpartpicker.com/list/7bnjp8) has every component except for the video card - the one I bought from Amazon isn't listed on PCPartPicker.
</small>

### CPU: AMD Ryzen 5 3600

This was the lowest-power 6-core Zen 2 part available. I wanted six cores
because my application load sometimes includes multi-threaded game servers and
media transcoders.

None of the Zen 2 parts have onboard video support, so choosing this CPU means we have
to supply a PCI video card.

### Motherboard: X570 AORUS PRO WIFI Mini ITX

Mini ITX is the smallest size of consumer motherboard, and it's our choice for
this small server build.

At around \$200, this motherboard is on the expensive side. There are [B450 ITX
motherboards](https://pcpartpicker.com/product/ZGDJ7P/gigabyte-b450-i-aorus-pro-wifi-mini-itx-am4-motherboard-b450-i-aorus-pro-wifi) half the price with nominal compatibility with our CPU choice, but older boards might need a BIOS upgrade
with similar features for our purposes, but I heard rumors that Linux on Ryzen
3000 doesn't play well with the older motherboards. Plus, some older motherboards
need a BIOS upgrade before they can be used with the newer AMD CPUs. Annoying.

### Storage: Samsung 970 EVO Plus 2 TB M.2 NVME

NVME is an amazing technology - it's crazy that a chip the size of a pack of gum
can hold 2TB of the fastest storage around.

At $450, this is the single most expensive part on our list, and it's also the
hardest to justify. The [Sabrent Rocket 2TB NVME][storage-perf] has
similar performance at half the price ($250), and a [2TB spinning
disk][storage-cheap] is a fifth the price at \$83. I picked Samsung for
peace-of-mind. Back in the day, cheap SSDs would fail randomly so it was worth
buying a premium part. Supposedly things work better across the board these days.

[storage-perf]: https://pcpartpicker.com/product/LxXnTW
[storage-cheap]: https://pcpartpicker.com/product/zk7CmG/seagate-firecuda-2tb-25-5400rpm-internal-hard-drive-st2000lx001

### Video Card: VisionTek Radeon HD 6350 1 GB Video Card

This was the smallest-looking AMD video card I could find on Amazon when
scrounging around. It needs to be a "low profile" half-height card to fit in
our small case. AMD works much better with Linux than Nvidia - [Nvidia is an
enemy of your
freedom](https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html).
Plus, AMD drivers are in the kernel so there's less mucking about required.

Unfortunately, it turns out this video card is so old, it can't be put into a low-power
state when it's not in use! That means it both draws power all the time, which is bad for
the environment, and it produces heat, which leads to a noisy spinning CPU fan!
**I do not recommend this card!** It's bad. I haven't found a good solution
other than removing the card.

### Case: Silverstone ML05B HTPC Case

My original intended case was the [Inwin Chopin](https://www.in-win.com/en/gaming-chassis/Chopin/),
an even-smaller case with no space for a graphics card. However, my motherboard didn't fit into
the Chopin because the Chopin uses some strange bulbous stand-offs.

So, I rage-bought this HTPC case from Amazon! It looks nice in person, but if I
did it again, I'd get a case with space for a two-slot PCI card, so I could
upgrade to a larger graphics card... one with a more modern GPU that could
enter a low power state.

### Power Supply: Corsair SF 450W 80+ Platinum SFX

Like "ITX" is a small type of motherboard, "SFX" is small size of power supply.
Corsair is a well-respected manufacturer. This is their lowest-wattage SFX
(small-size) power supply that has fully-modular cables.

The [Platinum
efficiency rating](https://www.velocitymicro.com/blog/what-is-psu-efficiency-and-why-is-it-important/)
means that this power supply will save me about \$32 a year - not too much. But since this computer
will be on 24 hours a day for years, I wanted to get a well-rated power supply that would last.

## Software

<figure>
  <img title="cozy.systems on the local network" src="@root/images/cozy-systems.png" />
  <figcaption>cozy.systems home page Heimdall dashboard</figcaption>
</figure>

The cozy server runs Ubuntu 18.04.3. I manage configuration and set-up using
Chef. The only aspects of the software stack that aren't managed by Chef are a
fallback, local-login-only user account, and the initial system installation.

I didn't do anything fancy with partitioning like use LUKS or LVM or ZFS - I'm
just using ex4 with a single partition. Plus an EFI boot partition.

### Chef

I use [Chef](https://learn.chef.io/#/) to manage system configuration.
[Max Burkhardt](https://twitter.com/maxb) and I managed our shared home server
with [knife-solo](https://matschaffer.github.io/knife-solo/) for years.
Although we've moved apart, we continue to use the same recipes for our personal
servers. Our current repo is private, but you can find a much earlier iteration
at [justjake/chopped](https://github.com/justjake/chopped).

I find Chef delightful _for hobby systems_ - I can write my system
descriptions in Ruby, the most fun language, but I don't need to worry about
the whole thing turning into a dynamically-typed Chef spaghetti disaster
because the scope is so small - just one or two servers.

Our general philosophy:

- Every recipe can run as `up` (install and configure) or `down` (stop,
  uninstall, and clean up).
- Install and run services with Docker. This simplifies many management tasks
  and keeps the base system clean. Many of our Docker images come from the
  [Linuxserver.io](https://www.linuxserver.io/) community.
- Avoid making new cookbooks. What's the point?
- Avoid Chef features like roles and attributes unless strictly necessary for
  variation between systems. Perform attribute lookups through a helper class
  for typo-safety.

Without further ado, here's the Chef role for the cozy server:

```ruby
name "cozy_systems_app_server"
description "App server for the cozy.systems network"

default_attributes(
    'base' => {
        'sysadmin_users_data_bag' => 'cozy_users',
    },
    'armada' => {
        'enabled_recipes' => {
            'certbot' => 'up',
            'unifi' => 'up',
            'netdata' => 'up',
            'qbittorrent' => 'up',
            'sonarr' => 'up',
            'radarr' => 'up',
            'emby' => 'up',
            'dashboard' => 'up',
            'dyn_dns' => 'up',
        },
        'directories' => {
            'downloads' => '/home/media/downloads'
        },
        'domain_suffix' => 'cozy.systems',
        'local_network' => '192.168.1.0/24',
        'route53_zone_id' => 'Z...' # removed for privacy
    }
)

run_list 'recipe[armada]'
```

See those `'enabled_recipes'`? That's what I'm running on the server!
Let's break it down.

### Certbot (letsencrypt)

Certbot is a package for automating Let's Encrypt certificate renewal.
We use a single wildcard certificate for the whole `*.cozy.systems` domain
to encrypt all the things. Yay HTTPS!

Our recipe creates a wrapper script on the root system that wraps the
[certbot/dns-route53 Docker image](https://hub.docker.com/r/certbot/dns-route53) , which lets us renew by fiddling AWS Route53 DNS.

### Unifi

I run my home network on Ubiquiti networks
[Unifi](https://unifi-network.ui.com/) wifi gear. The wireless access points
are powerful and very reliable for home use, but managing them does require
running a Unifi "controller" server.

We install the Unifi server from the [linuxserver/unifi docker image](https://hub.docker.com/r/linuxserver/unifi/). Unifi uses a bunch of ports, we do a bunch of host-port mapping in Docker, plus some Nginx magic to make everything work:

```ruby
# in site_cookbooks/armada/recipes/unifi.rb
# ...
docker_container 'unifi' do
  action enabled ? [:run] : [:stop, :delete]
  restart_policy 'unless-stopped'
  repo 'linuxserver/unifi'
  tag docker_tag
  log_driver 'syslog'
  memory 1024 * 1024 * 500
  # Tons of ports for Unifi access point management.
  # Access points need to connect it to register & download
  # configuration. No idea why it needs so many, though...
  port %W(
    #{armada.claim_port(3478, 'unifi')}:3478/udp
    #{armada.claim_port(10001, 'unifi')}:10001/udp
    #{armada.claim_port(8080, 'unifi')}:8080
    #{armada.claim_port(8081, 'unifi')}:8081
    #{armada.claim_port(8443, 'unifi')}:8443
    #{armada.claim_port(8843, 'unifi')}:8843
    #{armada.claim_port(8880, 'unifi')}:8880
    #{armada.claim_port(6789, 'unifi')}:6789
  )
  env [
    "PUID=#{unifi_uid}",
    "GUID=#{unifi_uid}"
  ]
  volumes [
    '/home/unifi:/config'
  ]
end

# chopped_nginx is our nginx-in-chef DSL. We prefer this over needing
# to make a zillion template Nginx configuration files.
# chopped_nginx is open source at
# https://github.com/justjake/chopped/tree/master/site-cookbooks/chopped_nginx
chopped_nginx_http 'unifi' do
  action enabled ? :create : :delete
  config do
    server do
      server_name armada.domain('wifi')
      server_name armada.remote_domain('wifi')
      listen 443, :ssl
      location '/' do |l|
        l.proxy_ssl_verify :off
        l.proxy_http_version '1.1'
        l.proxy_set_header :Upgrade, '$http_upgrade'
        l.proxy_set_header :Connection, :upgrade
        armada.proxy_pass(l, "https://127.0.0.1:#{web_interface_port}/")
      end
    end

    server do
      server_name armada.domain('wifi')
      server_name armada.remote_domain('wifi')
      listen 80
      location '/' do |l|
        armada.proxy_pass(l, "http://127.0.0.1:#{notify_port}/")
      end
    end
  end
end
```

### Netdata

[Netdata](https://github.com/netdata/netdata#readme) shows you graphs about the
system. I use it to figure out which Docker container is pegging the CPU, and
to check on motherboard temperature sensors.

![netdata screenshot](@root/images/netdata.png)

We install it via Docker from the [official netdata/netdata
repo](https://hub.docker.com/r/netdata/netdata). To allow netdata to query the
host system about containers securely, we also install [a docker socket
proxy](https://github.com/Tecnativa/docker-socket-proxy).

By default Netdata scans your system for about a million different things. It comes with a bunch of annoying health-check alarms too. Most of our customization of Netdata is disabling all this stuff.

**Beware!** By default `netdata` sends home usage statistics, and encourages you
to register your server in their public remote instance browser! This is creepy.
If you consider installing Netdata, be sure to:

- Disable telemetry by writing a file to `/etc/netdata/.opt-out-from-anonymous-statistics`. See
- Configure your Netdata instance to be a "registry" and register with itself.
  See https://docs.netdata.cloud/docs/configuration-guide/#make-security-related-customizations and https://docs.netdata.cloud/registry/#run-your-own-registry

### qBittorrent

[qBittorrent](https://github.com/qbittorrent/qBittorrent) is low-resource and
has an HTTP API with good integrations for our other software. It's not flashy,
but it works great. We install this from the [linuxserver/qbittorrent docker repo](https://hub.docker.com/r/linuxserver/qbittorrent/).

![qBittorrent screenshot](@root/images/qbittorrent.png)

qBittorrent detects a naïve Nginx reverse-proxy as a CSRF attack for some reason. Here's how we work around that:

```ruby
chopped_nginx_http 'qbittorrent' do
  action enabled ? :create : :delete
  config do
    server do
      server_name armada.domain('torrents')
      server_name armada.remote_domain('torrents')
      listen 443, :ssl
      location '/' do |l|
        # proxy mechanics
        l.proxy_pass        "http://#{backend_port}/"
        l.proxy_set_header  :Upgrade,           '$http_upgrade'
        l.proxy_set_header  :Connection,        :upgrade

        # shenanigans to pass qbt's CSRF protection (?)
        l.proxy_set_header  'X-Forwarded-Host',       backend_port
        l.proxy_set_header  'X-Forwarded-For',        '127.0.0.1'
        l.proxy_hide_header :Referer
        l.proxy_hide_header :Origin
        l.proxy_set_header  :Referer,                 "''";
        l.proxy_set_header  :Origin,                  "''";
        l.proxy_set_header  :Host,                    backend_port
        l.add_header        'X-Frame-Options',        "SAMEORIGIN"

        armada.protect(l)
      end
    end
  end
end
```

### Sonarr & Radarr

Sonarr automates torrenting TV. Radarr automates torrenting movies. Put in the
name of the thing you want, tell it the quality, and it'll go out to the
torrent sites, find the right torrent for you, download it, and then move the
finished files into a nicely organized directory structure. This is especially
nice for episodic TV - once you subscribe to a show, new episodes show up on
the filesystem soon after the show airs, ready to be watched!

![Radarr screenshot](@root/images/radarr.png)

Sonarr and Radarr connect to qBittorrent over its HTTP API to manage downloads,
and they also talk to the Emby API to index completed downloads in the media
library.

Docker containers come from [linuxserver/sonarr](https://hub.docker.com/r/linuxserver/sonarr/) and [linuxserver/radarr](https://hub.docker.com/r/linuxserver/radarr/).

### Emby

Emby is a media server and home streaming app. I mostly use it via the
excellent Apple TV app, but playback works great in a browser, too.

![Emby screenshot](@root/images/emby.png)

We install Emby from the [offical emby/embyserver
repo](https://hub.docker.com/r/emby/embyserver). Be sure to follow the
instructions to allow Emby to offload encoding work to your graphics hardware.

### Dashboard (Heimdall)

[Heimdall](https://github.com/linuxserver/Heimdall) provides us with a nice
homepage that links out to our other services.


At first, you're content with `cd`. It's fun and novel to navigate your
computer with paths in a terminal, and it feels faster than the double-clicking
you used to do in the Finder. Plus, you get to feel like you're on the way to
being a hacker.

But as the years go by, even with tab completion, you begin to tire of writing
the same locations over and over again. Even browsing the nice zsh completion
list barely eases your pain. How many times this semester will you type `cd ~/src/cs61a`? How many times will you type `vim ~/.zshrc` then `. ~/.zshrc`?
Fifty times? A hundred times? Thousands of times? It's time to do something
about this.

```zsh
alias webtree="clear; cd $webtree; ls"
alias oldtree="clear; cd ~/src/webtree-legacy; ls"
alias prefix="cd $PREFIX"
alias templates="clear; cd ~/src/templates; ls"
alias lib="clear; cd ~/src/lib/; ls"
```

<small>From the author's .zshrc, circa 2011</small>

This works for a while, but as you acrete aliases over the years, you begin to
notice some patterns. You've written the same characters many times. Didn't
your favorite teachers tell you, "Don't repeat yourself"? Instead of feeling
the pain when you `cd`, now you feel the pain when you're in your `.zshrc`
adding another alias. "You know how I'd solve this in Ruby?" you say. "I'd use
`Hash#map`". So you break out your Google (who could know that the syntax for a
map in `zsh` is `typeset -A var_name`?) and come up with a nice little loop.

```zsh
typeset -A jump_dirs
jump_dirs=(
  zshall          "~/.zsh
  webtree         "~/src/webtree"
  prefix          "$PREFIX"
  lib             "~/src/lib"
  stats           "~/src/jarkstats.js"
  gsd             "~/src/GroovesharkDesktop"
)
for short in ${(k)jump_dirs}; do
  alias $short="cd $jump_dirs[$short]"
done
```

<small>Inspired by the author's .zshrc, circa 2014</small>

Very cool. This is certianly a nice way to arrange things. It's not the next
[vim-tmux-navigator][], but it has a certain utilitarian asthetic in your
dotfiles. It breaks up the monotony. And, when you need to add another
edit-this-thing-real-quick alais, you feel _no_ pain.

[vim-tmux-navigator]: https://github.com/christoomey/vim-tmux-navigator

A few years pass. You've been working at a "real company" for a while; working
on code at a scale far larger than a few CS projects here, and a few student
job repos there. There's 50 repos checked out in ~/src, and you find yourself
in a dozen of them today, and a different dozen tomorrow. It feels pointless
adding another mapping to `quick_dirs` to generate an alias -- a new repo will
appear tomorrow, and you'll need another mapping.

```zsh
# considered harmful
goto () {
  cd ~/src/"$1"
}
```

The function does the trick for new files in ~/src, but now that you're writing
Golang, you can't keep your projects in ~/src. Daddy knows best, and he says to
put your files in `$GOPATH`. You're used to typing `goto monorail`. It seems
rude, somehow, when you type `goto encabulator`, but instead of happily
agreeing, `zsh` tells you "cd: no such file or directory: ~/src/encabulator".
Weren't you just there in ~/.../encabulator a moment ago? You stomp off to add
yet another Go project to `jump_dirs` when you realize you just can't take it
anymore.

```zsh
# paths in which to find projects or directories
# top path wins
goto_search_paths=(
  $GOPATH/src/*/*
  ~/airlab-stable/repos
  ~/src
)

goto () {
  for p in $goto_search_paths; do
    local it="$p/$1"
    if [ -e "$it" ] ; then
      echo "cd $it"
      cd "$it"
      return 0
    fi
  done
  echo "goto: not found: $1"
  return 1
}
```

You've done it. You've solved the `cd` problem forever. You can `cd` to any go
project, be it yours or a dependency. You can `cd` to any work project. And you
can `cd` to the rest of the stuff in ~/src. All is right in the world. Until
you have to copy a file from one project to another. You type this in your shell:

```
$ goto slipnslide
$ cp slipnslide.gemspec ~/src/dep-checker/spec/fixtures/slipnslide
cp: ~/src/dep-checker/spec/fixtures/slipnslide: No suck file or directory
```

You've forgotten where any project is checked out. You rely entirely on `goto`. So...

```
$ goto dep-checker
$ dep_checker="$PWD"
$ goto slipnslide
$ cp slipnslide.gemspec $dep_checker/spec/fixtures/slipnslide
(Successful silence...)
```

Just how many times are you gonna perform that
goto-then-set-a-var-then-goto-again operation? You're a shell pro. You're not
gonna do it more than 16 or 17 times before you've had enough. You've been
reading "The Art of Unix Programming" because someone extremely opinionated
told you to. And what you've learned, is that you should remind yourself to
practice The Unix Arts. Because you've been using too much Ruby lately.

It's time to compose.

```zsh
# paths in which to find projects or directories
# top path wins
goto-refresh-search-paths () {
	# assign this variable in a function, so that we freshly expand any globs
  # every time we run a goto- command.
  goto_search_paths=(
    $GOPATH/src/*/*
    ~/airlab-stable/repos
    ~/src
    ~/src/disabled-repos
  )
}

goto-which () {
  goto-refresh-search-paths
  for p in $goto_search_paths; do
    local it="$p/$1"
    if [ -e "$it" ] ; then
      echo "$it"
      return 0
    fi
  done

  echo "goto-which: not found: $1" > /dev/stderr
  return 1
}

goto () {
  goto-refresh-search-paths
  local dir=$(goto-which "$1")
  if [ -n "$dir" ]; then
    echo "cd $dir"
    cd "$dir"
  fi
}
```

There we go. Even has some good touches like writing its error messages to
STDERR, so that when you use `$(goto-which does-not-exist)`, you get "" back
instead of interpreting the error as a directory name. You're unstoppable.
Nothing can stop you. It's time to go all the way, and add tab completion as
long as you've got 19_goto.sh open in nvim.

```zsh
_goto () {
  goto-refresh-search-paths
  echo "_goto: $COMP_CWORD" >&2
  COMPREPLY=()

  # Only complete one word
  if [[ $COMP_CWORD -gt 1 ]]; then
    return 0
  fi

  # Complete with matching paths inside our search paths
  local cur
  cur="${COMP_WORDS[COMP_CWORD]}"
  echo "_goto: cur = ${cur}" >&2

  for p in $goto_search_paths; do
    COMPREPLY+=("$p/$cur"*)
  done
}

if [[ "$SHELL" == *"zsh" ]]; then
  autoload bashcompinit
  bashcompinit
fi

complete -F _goto goto
complete -F _goto goto-which
```

It doesn't work. Even though you loaded the bash completion support for zsh.
Well, at least you tried. _You're_ a hacker.

---

Update (2019-01-23): The current version of the `goto` shell function and friends has working
tab completion. You can find it online
[in my dotfiles repo](https://github.com/justjake/Dotfiles/blob/new/zsh/rc.d/19_goto.sh).


Notes


[Docs][docs] • [Github Project Home][gh] • [NPM][npm]

[docs]: https://github.com/justjake/quickjs-emscripten/tree/master/doc
[gh]: https://github.com/justjake/quickjs-emscripten
[npm]: https://www.npmjs.com/package/quickjs-emscripten

quickjs-emscripten is a Typescript/Javascript library around a WebAssembly
build of [QuickJS][], an javascript engine written by Fabrice Bellard and
Charlie Gordon.

> QuickJS is a small and embeddable Javascript engine. It supports the ES2020
> specification including modules, asynchronous generators, proxies and BigInt.

The quickjs-emscripten library allows you to use QuickJS to:

- Safely evaluate untrusted Javascript (up to ES2020).
- Create and manipulate values inside the QuickJS runtime.
- Expose host (native Javascript) functions to the QuickJS runtime.

[quickjs]: https://bellard.org/quickjs/

I was inspired to write the library by Figma's [blog post][figma] on
their plugin system. And, I wanted to build some familiarity with the
Emscripten ecosystem.

[Learn more about the project from the README][docs].

# Demo

The form below will evaluate ES2020 inside a QuickJS virtual machine.
Go ahead and kick the tires. You won't be able to access browser APIs
or affect this page's contents because the VM is totally isolated.

If you want to build with quickjs-emscripten, [head over to Github][gh]
or [NPM][npm] to get started.



Teeveed is a natural language interface for the media center. I built it as my
winter break project in 2013.

![teeveed icon](https://justjake.github.io/teeveed/images/teeveed-256.png)

You talk to it with your smartphone's web browser. You say "Okay TV, play Game
of Thrones episode 3," and `teeveed` will open that media in VLC on your media
center computer.

Teeveed is made up of three components:

- A coordinator daemon, which runs on your server. It indexes your files for
  quick search and fuzzy name matching. This process also hosts a webserver with
  an API, and a remote control client UI.

- The remote control client UI. This is a webpage that uses the Chrome Speech
  APIs to receive user input and pass it on to the coordinator.

- The HUD, which displays user intents and matched entities on the big screen.
  It also opens VLC to play movies. This process controlled by the coordinator.

<img
  style="box-shadow: 0px 5px 10px rgba(0, 0, 0, .5);"
  src="https://justjake.github.io/teeveed/images/hud.png"
/>

The intents you see here are parsed from the user's plain-text input by
[**Wit.ai**](http://wit.ai), then handled by the coordinator daemon.

## Project Status

Development has ceased. I quit working on this early in the Spring 2014
semester as my classes became more demanding.

### What went well

I'm very happy with the progress I made on teeveed in the limited time I gave
it. I learned a ton.

- Leveraging my newly-aquired Java skills from my Winter 2013 classes to build
  a JavaFX GUI was was fun! I don't really get the Java hate.

- Postgres is really flexible, and has some great extensions for things like
  full text search.

- Chrome has a ton of very cool proprietary APIs, like the speech-to-text API I
  used for voice.

- Wit.ai. I built my app in the early days of the service when the Wit team
  was making daily improvements. It was fun discovering how powerful the
  service could be. They also gave great support on Twitter. I'd definitely
  recommend Wit.ai to a friend.

### What went poorly

- JRuby. The biggest productivity drain on this project was waiting for JRuby
  to compile my Ruby code into Java bytecode during app boot. There's some kind
  of AOT compilation step you can do to speed this up, but I couldn't find good
  documentation for this in 2013. At the time, all the JRuby expertise was locked
  away inside enterprise users.

- As an extension, Maven, the Java build and packaging thingy. Maven is
  inscrutable to a new user (eg, me), and the slew of plugins I used to build my
  artifact didn't help any. Where JRuby was a producitivity drain because it
  increased my iteration times, Maven setup was just a single massive time-suck.

- Complicated architecture. I designed the system to be complex to test my
  ability to coordinate different components, but I ended up trying to build too
  much flexibility and configurability. I should have hard-coded more.

### The Code

You can find the code at
[github.com/justjake/teeveed](https://github.com/justjake/teeveed).
I still find the development notes interesting.



Grooveshark Desktop was my take on a desktop client for the now-defunct music
service [Grooveshark][] - a kind-of proto-Spotify based on a dubious legal
plaftform. My app featured:

- A mini-controller view, with fully customizable themes
- Media key support
- Growl desktop notifications
- reduced pixel waste
- native Last.fm support
- Minified and full-screen modes

Grooveshark Desktop recieved over 50,000 downloads, and was even featured on [Lifehacker][].

<figure style="position: relative">
  <img
    style="width: 97%; margin-right: 0"
    src="@root/images/gsDesktopPreview-searchSmall.png"
    alt="search ui screenshot"
  />
  <img
    style="position: absolute; bottom: -15px; left: 0px; max-width: 50%"
    src="@root/images/gsDesktopPreview-mini.png"
    alt="minicontroller screenshot"
  />
</figure>

Grooveshark updated their online app regularly, and the work required to
maintain my desktop cleint became overwhelming. I dropped it in 2010 in favor
of spending more time on my studies.

## Implementation

My client was implemented as a userscript for the Mac-only site-specific
browser application [Fluid][]. To create the seamless double-high menubar, I
relied on a specific Fluid feature to totally disable window chrome. I then
implemented window-movement as a javascript event handler. The "traffic lights"
were also entirely Javascript.

I'd like to think that I pioneered the technique of poorly-recreated native UI
elements in a thin Webkit wrapper, but really it was all Site-Specific browser
programmers. Now thin webapp wrappers are common-place: Facebook Mobile, Rdio,
and Spotify are all poorly-disguised webviews masquerading as honest desktop
clients.

Because Grooveshark Desktop was just a Javascript file and a collection of settings for the
Fluid SSB runtime, installation could be a real hassle. A SSB in Fluid consists of several parts:

- SSB App with its bundle-settings tweaked so that it looks for specially-named files
- one or more userscripts in ~/Library/Application Support/Fuild/SSBs
- A regular OS X .plist file in ~/Library/Preferences

I thought an OS X package would be the easiest (and most correct) way for my
users to get these pieces into place. Unfortunately, the tools to directly
create an OS X package that targets the user's home directory faded away into
obscurity, even in 2009. All the information on the package format I could find
was years out of date. I could create packages that targeted /Applications and
/Library just fine, but these required administrator passwords and were
perceived as intrusive.

I eventually cobbled together [a script][buildpkgs] using the remaining package
utils from Xcode 3 from references for Xcode 2 tools and Panther. Took plenty
of trial-and-error. The package tools happily build a complaint package to
install all the Grooveshark Desktop components into the filesystem root. Then
the script unpacks that package, manipulates the auto-generated manifest,
flattens the package directories, and the re-compresses everything back into a
.pkg file.

The [source][] is still availible online at Github.

[grooveshark]: http://listen.grooveshark.com
[fluid]: http://fluidapp.com/
[lifehacker]: http://lifehacker.com/5843955/grooveshark-desktop-is-a-mac-os-x-grooveshark-client-with-bonus-features
[source]: https://github.com/justjake/GroovesharkDesktop
[buildpkgs]: https://github.com/justjake/GroovesharkDesktop/blob/master/buildpkgs.sh


projects


Freshman year, I scored a job at Residential Computing, UC Berkeley's
student-run internet service provider, as a web designer.

- Redesigned and implemented new a new, data-driven website
- Worked with Rescomp's Marketing Team to redesign branding and image
  across web and print publications.
- Migrated legacy internal tools to the new design.

## Home Page

![Home page](@root/images/work-rescomp-home.png)

## Support Page

![Support page](@root/images/work-rescomp-support.png)

## About Rescomp

From Rescomp's [About page](https://rescomp.berkeley.edu/about):

> Residential Computing supports broadband, reliable network connections throughout the residence halls and campus
> apartments, including wireless connectivity in dining facilities and many other common spaces. Our staff, primarily
> made up of Berkeley students, provide knowledgeable, friendly, and responsive technical support to our residential
> clients for their network connections, computing needs, and cable TV service.
>
> Our customers include undergraduate and graduate students, family housing residents, live-in faculty, and conference
> guests. Our primary goal is to ensure that our clients can fully utilize network resources for their academic and
> personal needs through our provision of in-room Internet and wireless access, as well as technology resources in each
> unit's Academic Services Center (ASC). We are continually available to residents through timely phone, email, and
> in-person support to help resolve any technical issues that may arise.
>
> We ensure that all computers connected to the network meet campus minimum security standards, and we continually work
> to educate all residents about bandwidth policy, the importance of using legal services to obtain digital media, and
> about smart and safe use of technical resources.



I designed the branding and website for AtOnce Sales Software, a Santa Barbara-based startup. I also prototyped a
backend inventory management tool.

## Teaser Website

![AtOnce teaser website screenshot](@root/images/work-atonce-website.png)

## Prototype - viewing a line item

![Backend prototype - viewing line item](@root/images/work-atonce-backend.png)

## Prototype - editing a line item

![Backend prototype - editing line item](@root/images/work-atonce-backend-edit.png)



You can always find the latest PDF of my resume at [https://jake.tl/resume.pdf](/resume.pdf).

Also check out my [LinkedIn profile][linkedin].
[LinkedIn]: https://www.linkedin.com/in/jaketl

<object alt="PDF resume embedded in the page" data="/resume.pdf" type="application/pdf" width="100%" height="800">
</object>
