Not sure if the author is reading these comments but if you like the Moonlander but don’t like how the thumb cluster is tied to the tenting angle, I strongly recommend their ZSA tenting solution. It makes the whole thing a lot sturdier but more importantly it lets you adjust the tenting angle independently from the thumb cluster angle. You can also probably find used ones online.

I know you mention it already in the article but it is really worth trying out. You even get more tenting angles that would previously be impossible without it. And it just makes the whole thing a lot sturdier.

For anyone curious about this, the tenting solution is available here[0].

I wrote about it in my review of the Moonlander[1]. In short, in addition to much more stable angle adjustment, you get an additional 46 degrees of adjustment (11 degrees with the tent legs vs 57 degrees with the platform kit.)

It does tend to slide around a bit on a smooth desk, but I solved that with some rubber matting glued to the bottom.

0 - https://www.zsa.io/moonlander/platform

1 - https://marcusb.org/posts/2025/08/two-years-with-the-zsa-moo...

Good to know, thanks! Now that I 3d print (apropos hobbies with infinite depth...) I would probably just CAD design and print my own instead, but I've come to accept the limitations, such as it is, of the moonlander's tenting design.

Even using the AWS Console on a 13in screen is painful

I used to do this with Reddit but lately more than half of my feed is their recommended posts which include a lot of negative or ragebait content. Maybe a plugin can help with this

With Reddit, I unsubscribed from all the defaults and only subscribe to small, specific subs, which I browse via the Home page and via /new. If I see anything undesirable, I unsubscribe right away. It is a pretty good experience as of today.

There’s a yazi nvim plugin too!

Been using yazi for the terminal but not as a plugin yet. Perhaps I should give it a try. I’ve been happy with oil.nvim too

I also like rebasing. Sometimes my squashing cannot be completed without manual intervention, so I'll do a squash merge into a temporary branch instead:

   git checkout main
   git checkout -b squash-branch 
   git merge --squash [branch-to-rebase]

At this point I usually git diff the two branches as a sanity check before merging back into main:

    git diff [branch-to-rebase]
    git checkout main
    git merge squash-branch

I am normally able to squash rebase 99% of the time using git rebase -i main, but doing a git merge --squash into a temp branch has saved me a lot of hassle over the years.

Reminds me of this xkcd:

https://xkcd.com/917/

Or this: https://xkcd.com/688/.

That one closed about a year back unfortunately.

I do something kind of like this, but all of my scripts break when the underlying env is suddenly broken when e.g. brew updates python without asking me and breaks all existing environments.

I'm sure I could come up with solutions that are very robust for my particular machine, but I would like something that allows me to share it as a gist and a teammate could just as easily use it, or I can use it myself on another machine without hassle. In other words, a solution contained within the script iteself and maybe one or two binaries outside that make it possible.

I see, it might be heavy handed but running them inside Docker containers might provide you with the isolation you're looking for. You could also build and share these images with your teammates.

I've actually started using a lot of different CLI tools with Docker, especially when the tool isn't available for my OS.

We run canaries in Prod, it isn’t as extensive as our integration tests that run in our test stages but it still tests happy paths for most of our APIs.

Very cool!