jasonk

#!/bin/bash
cd "$(dirname "$0")"

# CraftBukkit download URL
CBURL="http://repo.bukkit.org/content/groups/public/org/bukkit/craftbukkit/1.7.2-R0.3/craftbukkit-1.7.2-R0.3.jar"
# ScriptCraft download URL
SCURL="http://scriptcraftjs.org/download/2014-02/v2.0.4/scriptcraft.jar"

# Install CraftBukkit
if [ ! -f craftbukkit.jar ]; then

jasonk

#!/bin/bash
set -e
# This script monkey-patches MeteorJS to allow it to work from behind a MITM
# proxy that forges SSL keys.  You may need this to get through a corporate
# content-inspection proxy, for example, since Meteor doesn't allow you to
# specify the CA certs to use.

cd "$HOME/.meteor"
cd "$(dirname "$(readlink meteor)")"
cd tools

jasonk

Keybase proof

I hereby claim:

• I am jasonk on github.
• I am jasonkohles (https://keybase.io/jasonkohles) on keybase.
• I have a public key ASDct1967s50TUfSbObjpQyCXi0IYMbrRd0ZRzh2DDpaYwo

To claim this, I am signing this object:

jasonk

On my team we like to put ticket numbers in commit messages, so that Jira finds them and puts links to the commits in the ticket. The problem is that I have a really hard time remembering my ticket numbers. What I've been doing is creating a branch for each ticket, but while that helps me remember the numbers, it still doesn't help me remember which ticket is which. I had tried posting comments to myself in Slack to keep track of them, but then it occurred to me that I didn't need to be using just the ticket number as the branch name, so now I'm trying something new.

Instead of creating branches with just the ticket number, I'm using ticket/short-description. The length of the branch name doesn't affect much, thanks to tab completion, and having that information available at a glance right in the repo is huge, especially since I have the branch name as part of my prompt.

[me@my-machine:dir PROJ-1234/fix-ci ]$ git branch
  PROJ-1234/fix-ci
  PROJ-1233/remove-stupid-widgets
  PROJ-1232/fix-brok

jasonk

TamperMonkey Utility Scripts

To use, include them in your TamperMonkey script, like so:

// @require https://gist.githubusercontent.com/jasonk/24bd00ff72b686f0b8a098290ef754bf/raw/tampermonkey-utils.js
// @require https://gist.githubusercontent.com/jasonk/24bd00ff72b686f0b8a098290ef754bf/raw/tampermonkey-cleanup.js

Note that tampermonkey-utils.js must be loaded before any of the others are loaded.

jasonk

Reserved Test Domain Names

Making up fake email addresses that use real domain names is a bad idea and in my experience also extremely common. To help people avoid that situation, here is a list of all the domain names that I know of that are reserved explicitly for purposes like testing and documentation.

Reserved Top-Level Domains

.test

Reserved by RFC2606/RFC6761.

jasonk

This works around an issue where using Istanbul with the noop instrumenter means it will try to parse your code with a hard-coded Babel config that may not work (especially if the code it's trying to parse is TypeScript).

This kludges the problem away by using patch-package in a post-install script to patch istanbul-lib-instrument to look for an environment variable pointing to your Babel config file, and a one-line patch to nyc to make it pass the filename when calling the patched functions in istanbul-lib-instrment (otherwise it will fail if your babel config includes overrides).

To use this, setup patch-package as shown in their README, then make a patches directory in your repo and drop these two patch files into it. Then just running yarn (or npm install) should be enough to do the patching. Then you just have to make sure that $ISTANBUL_BABEL_CONFIG is set to the path to your babel confi

jasonk

The [2022.9][release] release of [Home Assistant][hass] add a much-anticipated integration for doing firmware updates on z-wave devices. I immediately rushed to update the 36 devices it said there were updates available for. Then I woke up the next morning to find it telling me about updates for 35 of those devices...

It's a brand new feature, so I'm not too worried about it being a little rough around the edges at the moment, for now here is what I've found:

• It does work, you just have to be careful about it
• When you start the update from the UI it will show as being updated immediately. Don't be fooled! It's started, but it's nowhere near done.
• Z-wave has it's benefits, but bandwidth is not one of them. It takes quite some time to send a firmware update over the z-wave network to a device (around 20 minutes or the ones where I've timed it).
• If you start multiple updates they will all try to send update packets at the same time and flood your z-wave network, and very likely all fail,

jasonk

pipeline {
  environment {
    DOCKER_REGISTRY = 'https://my-docker-registry.example.com'
    DOCKER_CREDS = credentials( 'my-docker-credentials' )
  }
}

jasonk

Sentry is awesome, but their NodeJS Platform is slightly less great. It's basically entirely synchronous, so if you have a lot of async operations going on things like breadcrumbs and other context information will all get mixed up together.

I put this gist together to share with other people how I worked around this problem in our code base. It's not a perfect solution, but it works pretty well.

How it works

The way this works is that Sentry has a global store (global.__SENTRY__) that includes a hub property that stores the current hub. The hub has a stack of scopes that are the things you interact with when using things like Sentry.withScope and Sentry.configureScope. What I'm doing here is replacing that hub property with a getter that return an async context local hub instead of a global one. It does this by using the Node native AsyncLocalStorage mo