While checking the logs on a Caddy server I asked "Why can't I see a simple, easy to get to access log like FastAPI has?" So I made a tool to turn Caddy's JSON access logs into something easier to read.

It's a very simple design: Read JSON from stdin, write pretty-printed logs to stdout. No command line arguments or options, just a binary and pipes/redirects. For anyone interested the development process, I posted a Bluesky thread while working on it.

This is the first time I've published a project as a binary (outside of work) so no packages yet...just Linux binaries on GitHub releases. Cross-compiling looks harder than I thought so I don't think I'll set that up unless I find a need for it.

Code + downloads are available on GitHub. Due to recent events in the US I am feeling less friendly towards corporate types and have opted for GPL licensing on this project, rather than the MIT license I normally use on small projects. I am also wondering exactly how much of a headache it would be to move away from GitHub...

In a fit of insanity, you decide to get a tech job. After some searching you find a company desperate enough to hire someone with no experience.

---

"I'm thinking we'll start you out taking care of the zebra," the manager said. "That'll be a good way for you to get up to speed and learn how we do things."

"The zebra?" you ask.

"Yeah, the zebra. I'll show you," the manager turns and starts leading you down a hallway.

"What's that?" you ask again.

"What? The zebra. You know, a zebra."

"Of course! A zebra," you answer, understanding this must be a technical term everyone is expected to know already.

The manager leads you past the accounting desks, the customer service desks, a prestigious cubicle for a director, the IT desks, and finally into the datacenter. There's rows of tall black cabinets full of equipment, but the manager continues past them, leading you to a room near the back.

He opens the door and you follow, finding yourself facing a zebra, black and white stripes and all. Straw covers the floor, feed and water troughs are visible along one wall, and another features a double door open to a yard.

"Meet Zarzoni, our zebra," the manager introduces you, before launching into an explanation of feeding schedules.

Continue...

If you've ever used SSH keys to log into a remote shell and thought "This is so simple and easy, and private keys never have to be transmitted thanks to public key cryptography! Why don't we use this for logging into everything?" you're in luck: you can now set up your web site to accept logins based on public key cryptography and never have to store passwords. Unfortunately, the "simple and easy" part is a work in progress. Hence, the minefield.

What's a "Passkey"?

Passkeys are public-private keypairs designed for logging in to web sites.

Passkeys are created when a user registers one on a web site. They're tied to the domain specified at registration, and aren't reused on different sites. When created, the public key is saved by the server for recognizing the user on future visits.

The private key is saved by the client software. It may be saved in an OS cloud service and tied to the user's Microsoft/Apple/Google account, or it may be saved in a password manager (1Password advertises support, though I haven't tested it), or in a hardware key such as a Yubikey.

On return visits, the client and server communicate to verify the authenticity of the private key. Depending on how a key was set up, the client may require the user to select from available keys or enter a PIN.

Overall, when set up well, this can create a streamlined and secure login - visit page, tap on prompt / enter PIN, and you are logged in! No SMS codes, no begging users to install a password manager, and you don't have to store passwords! Sounds good, but the bad news starts when you try to implement it...

Continue...

I have published the first semi-functional versions of Paraforge to npm! (0.1.0 was published on 2 Sep 2024.) This is the very first test model that I used for most of the early development.

I have an old 3D model based on a Lego castle that I made as a kid, which I frequently use as a test model. Lately I've used it a lot to test the 3D viewer I'm making for Paraforge, and I hope to translate it to a Paraforge script soon. I even uploaded it to VRChat a while back!

Based on the commit logs for my old personal site it looks like I first posted it online on 4 Mar 2016. Since then I've used it for a lot of debugging - the multitude of breakages that happen when updating Three.js, the intricacies of iOS compatibility with accelerometer events, the numerous breaking changes with new Three.js versions, new security requirements and breaking changes in the gamepad API, Three.js rearranging everything down to the meaning of color values, learning web components, and whatever Three.js decided to break lately.

Now I'm making a web site (mainly so I have somehwere to demo Paraforge), so naturally the first post I make is for the old castle.