a checkpoint #

I received my BJJ brown belt last night.

aside #

I've nothing particularly caffeinated to add to the "discourse" on the subject of measuring the productive output of a software engineer, but I continue to be bemused by the various attempts maximizevalueextraction.biz like DORA, SPACE, DEVEX et al.

Imagine a framework for measuring the delusions of these biz-analysis freaks.

tmux #

I get weird about multiple tabs and splits in my workflow, and I really like to have the same layout across #tmux sessions.

In the distant-in-dog-years past, I spend too many hours building custom layout templates, etc, but have since given up tmux as a hobby. Now, I just hit prefix and then smash <SPACE> until the layout looks nice enough.

However... When I have a giant screen, e.g. 3840 x 2160, the layouts look weird to me. So, back to scripting:

#!/bin/bash
# $HOME/.config/tmux/big-split.sh

TERMINAL_WIDTH=$(tmux display-message -p "#{window_width}")
TERMINAL_HEIGHT=$(tmux display-message -p "#{window_height}")
PERCENTAGE=70
OFFSET=10
PANE_WIDTH=$((TERMINAL_WIDTH * PERCENTAGE / 100 + OFFSET))

tmux split-window -h -l "$PANE_WIDTH"

Then a small amendment to tmux.conf so that I can set the layout with :bigsplit:

# $HOME/.config/tmux/tmux.conf

set -g command-alias[0] bigsplit="run-shell '$HOME/.config/tmux/big-split.sh'"

These look good, but putting them up sucks.

Wading back into the JS framework pool. Though I've been building quite a few side-projects recently using a variety of approaches (Deno, Hono, Fresh, etc.), those projects are all to my own peculiar taste.

The calculations change when building an application that someone else is paying for, and particularly if that application needs to be supported long-term by a team of varied skill-sets and expertises. Peril avoided.

The framework du jour is inarguably #nextjs. It's an unavoidable #react-ism, and has to be considered.

But, context. gcp and cloudrun is where this application will be deployed, which is, evidently, hard with NextJS. While there will always be an "ahem, actually", anecdote, blog post, and conversation seem to converge on the point that NextJS just doesn't work as well unless you're deploying to Vercel. This seems doubly reinforced by the existence of shim-projects to leverage bespoke features of NextJS in non-Vercel clouds.

My hesitation also relates to #wordpress, and chaos currently visible in that developer community, due to commercial strong-arming by wordpress.com.

Then there's this.

So I'll be looking pretty hard at react-router v7 instead... Signs point to it working well from gcp.

Tomorrow is my last day with my current company. I just want to note that, here.

Late-winter, 2018, only so many people that you could count us with a single hand. Up to much larger headcount, acquisition, and sun-setting.

A job is a job is a job, but I've been in this one chair for long enough that it just has me feeling nostalgic.

If you're using macOS, just use postgres.app - homebrew installations of #postgres are too much heartache.

(or use a containerized postgres)

Be sure to add psql to $PATH in .zshrc or whichever flavor you're using:

PATH="/Applications/Postgres.app/Contents/Versions/latest/bin:$PATH"

A few notes on #hono

If you install hono from jsr, using hono extensions from npm will not work, e.g. @hono/zod-validator.

If you're curling and stuff is weird (validator("json", ...)), probably forgot to add -H "Content-Type: application/json".

...And it's this kind of November. America, an anxiety disorder. Violent backlash almost certain, varietals both comic and tragic.

Something entirely unrelated. eslint version 9.

Upgrading eslint, or "make-work" #

I love tooling. #eslint has been ubiquitous for so long, the standard and the standard. But OSS is evolve or die, and sometimes both.

The upgrade path between eslint 8 -> 9 is rocky enough that it simply doesn't look worth the squeeze, to me. For a new project, the choice is obvious (9), but I've had little success using the migration tools.

$ npx @eslint/migrate-config .eslintrc.json

Attempts #

Given the scope of linting configuration, I'm probably better off declaring linter bankruptcy and simply starting over. Yeah, that's it, this is make-work.

// @ts-check

import eslint from '@eslint/js'
import tseslint from 'typescript-eslint'

export default tseslint.config(
  eslint.configs.recommended,
  ...tseslint.configs.recommended,
  ...tseslint.configs.recommendedTypeChecked,
  {
    rules: {
      '@typescript-eslint/no-unsafe-assignment': 'warn',
      '@typescript-eslint/no-unused-vars': [
        'warn',
        { argsIgnorePattern: '^_' },
      ],
    },
  },
  {
    languageOptions: {
      parserOptions: {
        projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
  {
    files: ['**/*.js', '**/*.mjs'],
    ...tseslint.configs.disableTypeChecked,
  }
)

Text editing #

Given the advent of mjs and cjs, make sure your tooling recognizes those file extensions when looking for configuration files.

Links #

• @eslint/migrate-config
• typescript-eslint

Wanted cornbread, needed chili. A #recipe.

1. Convey thyself to the supermarket.
2. Grab 1 lbs meat, likely beef.
3. 2 cans beans, likely pinto.
4. 4 cans hatch chile. The little yellow cans.
5. You know what you like. Grab some other chili adjacent ingredients. Probably a white onion for dicing. Tomato paste. You have chili powder at home, yeah? Shredded cheese. Crushed tomatoes or diced, even sauce? No sauce, but get a can anyways. Garlic... A red pepper. So strange that they lock the laundry detergent up now. There's not many people here, this time of night. Get followed around by 3 security guards, conspicuous in their plate carriers.
6. Allons-y, and mise en place. This is quick chili.
7. Brown the meat. Freestyle a bit. Various powders and spices.
8. Tomato paste, into the stew.
9. Etc. This isn't a soup. Use the too-expensive salt to season.
10. Forget to prepare the cornbread. This is less-than-quick chili now.

I've been wondering why my fly machines weren't auto-suspending after I added #sentry to a project. From the logs, I could see / was being requested every second... Smells like a bot.

So I added more logging to catch the user-agent from request headers, and was surprised to see the following:

user-agent: SentryUptimeBot/1.0 (+http://docs.sentry.io/product/alerts/uptime-monitoring/)

I guess #sentry has a new feature (beta) that does a healthcheck on URLs that have thrown exceptions. I need to read the docs more closely, but a GET every second seems a bit excessive. To disable it, I just revised my robots.txt:

User-agent: SentryUptimeBot
Disallow: *

Links #

• https://docs.sentry.io/product/alerts/uptime-monitoring