My posts will always be written by me, a human, sharing tips, personal news, and more. And though I started writing web sites before HTML 1.0 was formally standardized, I’ve never been good at design. My blog used Jekyll Minima with a few overrides and I only recently updated it to 2.5, but was envious of the theming that 3.0 has in development. Though I really haven’t touched much CSS since shortly after 2.0 was released, I knew the mechanics but wanted a little help prototyping some ideas quickly.

Trying out themes

It probably wasn’t obvious, but my previous color palette used Seahawks colors. I wanted to see what mixing those colors or other colors might look like for light and dark themes. With some links to the color palettes I was considering - but haven’t necessarily settled on for the foreseeable future - asked Copilot with Sonnet 4.6 to render a few. It didn’t take long - certainly faster than I’d have done it - and I was able to select a theme as a start quickly. I made a few tweaks and had it apply the changes with some color mapping instructions from the old palette.

Having been to several of their games with my son - who loves hockey - and my wife - who merely tolerated it but got a selfie with Buoy - I choose a Kraken color palette. They put on one heck of a show at Climate Pledge Arena.

It took a few iterations to iron out the kinks. I would verify the responsive site in Safari’s dev tools and batch several changes with explicit instructions. As with any time I use an LLM to generate code, I review and recommend changes as needed.

Theme switcher and responsive fixes

With separate light and dark themes, I next had it lay the ground work to switch themes and fix some responsive issues, like certain buttons being too long on mobile viewports so I’d change the text to “Subscribe” instead of “Subscribe on Sequoia” in the sequoia-subscribe component. Again, with a carefully crafted prompt, it didn’t take long to generate the necessary changes that’d probably have taken me a couple hours.

With all changes reviewed and tested, I finally had a properly responsive and themed web site I’ve been wanting but just haven’t found the time.

I was also working on an idea for unified test resource provisioning across SDKs and languages and was working with a couple different vaults in the Azure Portal: our test secrets used by all the languages, and one I had just created for some tests. Certain I had the right one selected, I was prompted Are you sure you want to delete this vault? with just Yes and No buttons, and clicked Yes.

I was wrong.

I deleted the shared test secrets used by Azure Pipelines and more.

Within seconds I realized my mistake, hurried down the hall to our engineering systems team room, and echoed Gob Bluth’s famous line, “I’ve made a huge mistake.”

Not the best start on a new team, but what happened next is what I like to share with mentees both junior and senior.

Driving change

In the short term, we needed to restore functionality. Soft delete wasn’t enabled on the vault, so the vault was truly gone. But across all the developers, we all had enough secrets in process or machine environment variables¹ that we could restore most of the secrets. Others we just had to regenerate and deal with as problems arose.

In the long term, I wanted to make sure something so vital - think about a company losing production secrets on which their business depends - didn’t happen again, or at least wasn’t so easy.

I had already developed a pretty good rapport with the Key Vault service team, and worked with them on some changes:

1. The name of the vault wasn’t part of the original prompt. They added the name of the vault and changed the buttons to more descriptive Delete and Cancel.

2. They moved up plans to enable soft delete by default. After that change, you had to explicitly disable soft delete. Seems many customers weren’t aware of soft delete, which allows you to recover a deleted vault or vault resource for a configured number of days - the default being 90 days.

   Eventually, a change was made such that soft delete couldn’t be disabled, and purge protection could be enabled that prevented a deleted vault or vault resource from being purged for the configured number of days.

Final thoughts

We all make mistakes. I was a senior at the time and not long after that was promoted to a principal engineer. I still make mistakes - perhaps not as bad and hopefully won’t - but how we deal with them and learn from them is what matters.

Own up to the mistake and try to prevent them from happening again or to anyone else, if relevant. Seek out partners to brainstorm ideas and show a growth mindset among your peers and management. They’ve all made mistakes too.

Since the Key Vault service allowed an empty string for the key version for all endpoints, the KV SDKs across all languages back then - .NET, Java, JavaScript/TypeScript, and Python - we made the key version parameters in all those languages optional even though they didn’t all technically follow language guidelines for optional parameters: optional parameters go into “options bags” - an optional parameter that had a bunch of optional properties on it or, for pythonistas, kwargs.

For key data operations that generally fine: an empty version means you act on the latest key version; however, for cryptography operations - encrypt, decrypt, sign, verify, wrap, and unwrap - that can inadvertently lock you out of your data. For example, if you encrypt with key version 1 and that key is rotated to version 2, you won’t be able to decrypt with version 2. You can work around this by cycling through key versions, but knowing when you found the right one isn’t always easy if you don’t know the plaintext. This is compounded when unwrapping a symmetric key because the key length is the same and, in some block ciphers, will decrypt into plaintext you can’t always validate.

Required for Rust

Since I’m the architect for the Azure SDK for Rust, have much more experience with Azure Key Vault now, and have been working on the Key Vault SDKs for Rust, after having talked with the Key Vault service team about it, we made the key version parameter required for cryptography operations. Not only does this mean the version parameters actually follow language guidelines, but that they steer customers into the pit of success. You can still pass an empty string "" to use the latest version but it’s not recommended.

I’ve updated the akv CLI accordingly to require the key version for the encrypt command, whether passed to --version or (new) passed as a key URI with version.

Hopefully by requiring a key version for crypto functions, customers will be less likely to accidentally lock themselves out of their encrypted data.

Using cargo-cache as I described previously can help clean up old dependencies, and you can delete all targets/ from repos under some directory like so:

find -maxdepth 2 -name targets -execdir rm -rf {} \;

After that and cleaning up any other files you don’t need, log out of all your WSL sessions, close down Visual Studio Code if you have it running and connected to WSL e.g., if you started code from within WSL, and shut down WSL:

wsl --shutdown

Now for the easier part: find the VHDX for your distro and shrink it all from within PowerShell:

# Replace "Ubuntu-24.04" with your distro name
$path = (Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss `
  | Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu-24.04' } `
  ).GetValue("BasePath") + "\ext4.vhdx"
Optimize-VHDX -Path $path

It may take a while, but after it completes you can log back into your distro. Seems WSL changed it so you don’t have to run resize2fs anymore - Ubuntu 24.04, at least, automatically picked up that more space was available.

It’s a CLI that works with various static-site generators to publish records into your PDS - something I was just starting to think how I wanted to tackle it. This CLI is a good start, so I’m happy to try it out, file bugs, and even submit pull requests!

This post, if all is set up correctly, should be the first post published to the ATmosphere.

rustup target add x86_64-unknown-linux-gnu
cargo build --target x86_64-unknown-linux-gnu

Of course, the targets’ compiler, headers, and libraries need to be available, but a typical install of Visual Studio or gcc will support common targets. But on my new work Surface Laptop 7 arm64 I needed to compile openssl-sys for my a project and that’s when the fun began:

error: failed to run custom build command for `openssl-sys v0.9.102`

----- SNIP ---8<
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR unset

While there are lots of ways of getting the bits I need - like compiling source myself or downloading and extracting files to the right locations - I like the convenience of a package manager especially when it comes to installing updates. But I’m running Ubuntu 24.04 aarch64, so how do I install packages for amd64 e.g., libssl-dev:amd64?

Configuring sources

While I’ve had some experience managing debian package repositories e.g., in /etc/apt/ I’ve never before had need to try to install packages for other architectures. I wasn’t even entirely sure it was supported, but a quick search got me started:

sudo dpkg --add-architecture amd64
sudo apt update

But updating the package index failed: I was getting several 404s because packages weren’t available on http://ports.ubuntu.com/ubuntu-ports/. I was also only familiar with the one-line format and not this new format I was seeing, which `man 5 sources.list tells me is DEP822-style.

After reading sources.list(5) and a bit of trial and error, I ended up with the following /etc/apt/sources.list.d/ubuntu.sources

Types: deb
URIs: http://ports.ubuntu.com/ubuntu-ports/
Suites: noble noble-updates noble-backports
Components: main universe restricted multiverse
Architectures: arm64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main universe restricted multiverse
Architectures: amd64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://ports.ubuntu.com/ubuntu-ports/
Suites: noble-security
Components: main universe restricted multiverse
Architectures: arm64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble-security
Components: main universe restricted multiverse
Architectures: amd64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Installing packages

After a quick and finally successful sudo apt update, I was able to install packages:

sudo apt install --yes libssl-dev:amd64

I was able to get further with my original goal of compiling openssl-sys, but then got an error about no linker available. I installed gcc:amd64 and almost able to compile my crate, but the linker failed so I needed to specify the linker explicitly in .cargo/config.toml:

[tageet.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

[target.x86_64-unknown-linux-gnu]
linker = "x86_64-linux-gnu-gcc"

Success! …well, almost.

When I tried a normal build e.g., cargo build I got pages full of compiler errors. Turns out, when I installed gcc:amd64 it replace a few components, since apt list --installed *gcc showed gcc-13-aarch64-linux-gnu was now removable.

After a quick search - there’s plenty of information of people wanting to cross-compile for aarch64 on amd64 - I realized I need to install a few packages at once, to effectively make sure all the right symlinks are created. I could’ve done this manually, but figured there were a number of executables I’d need to fix and would rather just let apt handle it:

sudo apt install --yes gcc-13 gcc-13-aarch64-linux-gnu gcc-13-x86-64-linux-gnu
sudo ln -s /usr/bin/x86_64-linux-gnu-gcc /usr/bin/x86_64-linux-gnu-gcc-13

The last line was just for convenience, which apt did for aarch64-linux-gnu-gcc and, originally, when I installed gcc-13-x86-64-linux-gnu standalone.

Cross-compiling for openssl-sys

I was finally able to cross-compile openssl-sys:

cargo build
PKG_CONFIG_SYSROOT_DIR=/usr/lib/x86_64-linux-gnu cargo build --target x86_64-unknown-linux-gnu

Fortunately, cleaning up all that Rust doesn’t require WD-40 and a little elbow grease. Here are a few tips:

1. Use cargo-cache to view information about and clean up the cargo cache:

   cargo install cargo-cache
   cargo cache --info
   cargo cache --help
   

   It hasn’t been updated in a while, but seems to work quite well.

2. Delete your target/ directory. Generally, most of the time building is spent acquiring crates anyway, but this can typically save you a lot of space, especially if you’ve been working in a repo for a while and dependencies have changed frequently.

WSL

This can be even more problematic when working in Windows Subsystem for Linux (WSL), since the virtual hard disk (VHDX) used to default to 256GB then later 512GB, and currently 1TB. Note, however, this is only the maximum size the VHDX sees as the maximum space. Depending on your physical drive space availability, it may be less.

In my case, recently, my old WSL Ubuntu-22.04 image thought it ran out because it only saw 256GB. Most of that was consumed by Rust and Go. You can view space using du from within WSL like so:

du -hd1 -t1gb .

If deleting repos’ target/ directories didn’t free enough space, you can resize your VHDX from an elevated shell:

# Replace 'Ubuntu-22.04' below with the name of your distro.

# Shut down your distro.
wsl --shutdown 'Ubuntu-22.04'

# Find the path to the VHDX file for your distro.
(Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss `
  | Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu-22.04' } `
  ).GetValue("BasePath") + "\ext4.vhdx"

# Launch diskpart and resize the disk returned above as {path}.
diskpart
select vdisk file="{path}"
expand vdisk maximum="{size in MB}"
exit

Now log into your distro’s shell again and tell it that it has more disk space available:

# Find the correct device.
sudo mount -t devtmpfs none /dev 2> /dev/null
mount | grep ext4

# Copy the name e.g., /dev/sdc and resize it using the same size in MB as above.
sudo resize2fs /dev/sdb '{size in MB}M'

When roads started getting icy, I decided to get a Zwift indoor trainer which I (mostly) enjoy. That gave me ample time to work on more Strava badges - the harder ones, especially.

Around these parts, it’s hard to avoid climbing on your bike so, with already strong legs, I leaned into it: I started signing up each month for Strava’s 7,000m (22,966ft) challenge. I lost a bunch of weight and my legs got stronger to the point that training with friends and cycling teammates meant frequently having to wait for them at the top of hills. I don’t mind. Fun to get out with people and (usually) to take a break after longer climbs.

I even finally road my first Bike MS: Deception Pass Classic and set a new course record on Strava; though, I plan to socialize more next year. It’s not a race, but I wanted to push myself on my first century ride and see what I could do over 100mi and over 5,000ft.

All this lead up to a lot of climbing over the past year to earn some badges, but more so to prove I could:

I’m on track to complete over 100km elevation and 5,000mi distance by EOY; however, after that I plan to back off a little. Cycling indoor is great exercise, but it does get a little boring. I discovered audiobooks help, but it’s also mentally exhausting and I’m burning out after an average of 4-5 rides week - most often pushing myself.

I’ll keep going, but I plan to tank any possibility of getting the 7,000m badge in January 2025. I’ll likely go for those badges in spring and summer months as I start training for the next charity ride(s).

Update

🎉 My pull request was merged: TypeSpec is now supported out of the box in Helix! You still need to install the LSP as with any other supported language, but that’s a single, simple command. See below, or in their wiki.

Background

I’ve been using vim and before it vi for close to 30 years. I started my programming career in a terminal and, while I often enjoy GUI apps like Visual Studio Code and am more productive when touching lots of files, I still like the efficiency of a good terminal editor.

But vim is feeling rather dated. There’s clearly a lot of cruft they have to support, and much of this seems to have carried over into neovim. While neovim does support tree-sitter for LSP support and has a rich ecosystem, I thought I’d give another, fairly new editor a try: Helix.

Helix is a vim-like editor written in Rust and seems to be fairly popular with some other Rust developers. Given it doesn’t have a long legacy to support, it seems worth a try at first. So far, I’ve been loving it. Language support is fairly easy to add and it supports a large number of languages out of the box, though you have to install the LSPs and perhaps other tools for some languages.

One language it’s missing is TypeSpec, which my team, the Azure SDK team, develops. It’s also getting used by some third-parties, and since we’re planning to generate source generation only from TypeSpec for the Azure SDKs for Rust, I’ll be using it a lot more. It’s also being reviewed more frequently by the Azure REST API Review Board, of which I’m a member.

Installing the LSP

The TypeSpec LSP is contained in the @typespec/compiler, so all you need to do is install that globally (or otherwise discoverable in your $PATH):

npm install -g @typespec/compiler

Configuring the grammar

You’ll need to add some configuration to your languages.toml configuration file e.g., ~/.config/helix/languages.toml:

use-grammars = { only = ["typespec"] }

[[grammar]]
name = "typespec"
source = { git = "https://github.com/happenslol/tree-sitter-typespec", rev = "af7a97eea5d4c62473b29655a238d4f4e055798b" }

[[language]]
name = "typespec"
language-id = "typespec"
scope = "source.typespec"
injection-regex = "(tsp|typespec)"
file-types = ["tsp"]
roots = ["tspconfig.yaml"]
auto-format = true
comment-token = "//"
block-comment-tokens = { start = "/*", end = "*/" }
indent = { tab-width = 2, unit = "  " }
language-servers = ["typespec"]

[language-server.typespec]
command = "tsp-server"
args = ["--stdio"]

Compilation

Once that configuration is in place, you need to actually compile the parser. Helix has made that easy:

hg -g fetch
hg -g build

Rich language support

Now that helix is configured to start and use the TypeSpec LSP for any files with a .tsp file extension with an ancestor tspconfig.yaml configuration file, you need to tell it what to do with that information.

To support syntax highlighting; selection of functions, arguments, models, etc.; and proper indentation, copy files from https://github.com/heaths/helix/tree/main/runtime/queries/typespec into the runtime/queries/typespec subdirectory of your helix configuration directory.

Demo

What do you get after all that?

While there are many different ways to configure this, many have you set up a service or autorun program but I want neither of those affecting Windows boot and login performance for something I don’t use often throughout the course of every day. Fortunately, I found one one such article that accomplished exactly what I wanted using socat and npiperelay.

I made a few modifications including how to acquire npiperelay given changes to the Go toolset.

1. Acquire npiperelay

You need to acquire npiperelay in Windows. You can download it from https://github.com/jstarks/npiperelay/releases/latest into a directory in your PATH environment variable or, if you have Go installed, run:

go install github.com/jstarks/npiperelay@latest

2. Install socat

Next you need to install socat in your WSL distribution. I’m assuming you are using some Debian-based distro e.g., Ubuntu. If you are using another distro, please use appropriate commands.

apt update
apt install -y socat

3. Create startup script

You’ll need to create a bash script that will start when you log into your distro. I’m assuming bash below.

mkdir ~/.1password
touch ~/.1password/agent && chmod +x ~/.1password/agent

Open ~/.1password/agent and paste the following content:

#!/usr/bin/bash

export SSH_AUTH_SOCK=$HOME/.1password/agent.sock

ALREADY_RUNNING=$(ps -auxww | grep -q '[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent'; echo $?)
if [[ $ALREADY_RUNNING != '0' ]]; then
    if [[ -S $SSH_AUTH_SOCK ]]; then
        rm $SSH_AUTH_SOCK
    fi

    (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:'npiperelay.exe -ei -s //./pipe/openssh-ssh-agent',nofork &) > /dev/null 2>&1
fi

4. Run script on login

To run the script when you log in interactively, edit your appropriate profile e.g., .bashrc for bash:

. ~/.1password/agent

You can restart your login session or just source ~/.1password/agent yourself.

5. Test

Assuming you have already configured 1Password’s SSH agent using the instructions at the beginning of this post, you can test and reset any git repository you have handy e.g.,

cd ~/src/some-project
echo test > test.txt
git add -A
git commit -am'test' -S
git show --show-signature

Unknown signer

If the git show --show-signature command about shows an unknown or invalid signer, be sure you have your allowed_signers set up for git. Unlike GPG that can use counter signatures to validate identities, SSH signatures need explicit approval:

mkdir -p ~/.config/git/
cat ~/.ssh/identity_rsa.pub > ~/.config/git/allowed_signers
git config --global gpg.ssh.allowedsignersfile $HOME/.config/git/allowed_signers

Blocks tunneling into other hosts

If you are also using SSH to tunnel into other hosts, you should configure SSH separately for github.com:

Host *
    IdentityFile ~/.ssh/id_rsa.pub

Host github.com
    IdentityAgent ~/.1password/agent.sock
    IdentitiesOnly yes