jasonk

I wanted to be able to put the Consul UI behind a reverse proxy, and be able to access it as https://example.com/consul, but it doesn't seem to support that out of the box.

According to hashicorp/consul#14342 it's supportd and you can set a variable to tell the UI what prefix to add to the front of API requests, but after a couple of days of trying I could not figure out how to set that variable (and comments on the PR suggest that nobody else has figured it out either, and Hashicorp hasn't responded to any of those).

I did manage to get it working, but it needed a little kludge. Since I couldn't figure out how to get Consul to set the right variable in the UI, I made Nginx do it instead.

This is the configuration I ended up with. As a bonus this config also includes a map that makes the UI default to read-only even if the UI is running on the consul servers.

References:

• https://github.com/hashicorp/consul/pulls/14342

jasonk

First off, let me say that 1password is a great tool that I use every single day.

That being said, however, as a web developer it has one very obnoxious problem that they are unwilling to fix: There is no way for a developer to indicate that a field that 1password thinks should be filled from it's vault should in fact not prompt the user to autofill it.

Some examples of completely valid use cases made absurdly painful by this refusal include:

• Admin tools that let you change passwords for other people getting accidentally filled with passwords from 1password
• Fields that aren't even asking for passwords that are using type=password to cause the input to be hidden

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

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

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

Reolink API Examples

I had some difficulty finding simple examples of how to use the Reolink API and ended up digging through some python implementations to figure out how it works.

The official documentation is available at https://bit.ly/3rWxG6e but it is a bit lacking, and the API is somewhat weird, which makes it difficult. You should still look at it though, as it lets you know what commands are available through the API.

The main weirdness is that even if you are sending one command at a time, the payload has to be an array of objects and the response is always an array of objects. Also, you have to pass the command both as a URL parameter and in the payload.

Included here are a small(ish) bash script (also requires jq) for running API commands against Reolink cameras or NVRs.

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

jasonk

Starting with MongoDB 4.2, you can use [aggregation pipelines to update documents][$pipelines]. Which leads to some really cool stuff.

For example, prior to this you could easily add sub-documents to an array using [$addtoSet][$addtoSet], and you could remove documents from an array using [$pull][$pull], but you couldn't do both in the same operation, you had to send two separate update commands if you needed to remove some and add some.

With 4.2, now you can, because you can format your update as a pipeline, with multiple $set and $unset stages, which makes those things possible. However, since this is so new I had a really hard time finding examples of many of the things I wanted to do, so I started to collect some here for my reference (and yours).

See also:

• https://docs.mongodb.com/manual/tutorial/update-documents-with-aggregation-pipeline/
• https://www.mongodb.com/blog/post/coming-in-mongodb-42-pipeline-powered-updates-and-more-expressive-queries

jasonk

I'm a big fan of hub, but I found myself wishing for the ability to use git hooks on pull-request messages the same way you can on commit messages with prepare-commit-msg and commit-msg hooks. People have been asking for hub to be able to do this for a while, but until that happens, here is a way you can do it yourself, right now.

To use this, just drop the script below into your $PATH somewhere, and make sure you have your $EDITOR environment variable set to whatever command runs your real editor, and then set your $GIT_EDITOR environment variable to run the hub-editor script.

The way this works is that when hub-editor is invoked with a file named PULLREQ_EDITMSG (which is the filename hub uses for editing pull requests) then it will run the prepare-pull-request-msg and pull-request-msg scripts from your .git/hooks directory (if they exist and are executable). If hub-editor is invoked with any other file

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