Any sufficiently advanced technology is indistinguishable from magic.

• Arthur C. Clarke

In many ways, programming is very much like a kind of Magic. We even call people that are good at computers, a Computer Wiz(ard). When I volunteered at an English school I would often have a bit of fun and jokingly call myself パソコンの魔法使い or Computer magician when describing my job. Writing code can even look like writing in an ancient arcane grimoire.

While I already use VSCode for most things, like many developers I am often curious to see what else is out there. Even though I like some of the ideas behind the Zed editor, and will follow its progress, advertising built in AI is a fairly immediate turn off. The idea of a high performance editor though is still very appealing, and it seems like there are many rust based contenders (not that my rust abilities are anywhere near the level to contribute anything).

As I have tried to reduce my dependence on social media, I have picked up more and more blogs into my feed reader. With as much as I read, I have often felt like I should be writing more as well but I am very skilled at distractions and excuses to avoid writing.

I am often reminded about the seinfield calendar which introduced a strategy for improving at something with continuous practice. Even if the story itself is apocryphal, that idea of continuous practice shows up in many places. In fact, one of my favorite Japanese words is 改善(kaizen) or the idea of continuous improvement.

When one thinks of radiation, what kinds of thoughts first come to mind? For many, radiation gives the image of something scary. Often places like Fukushima and Chernobyl come to mind. For me, I’ll often immediately wonder “how much are we talking about”. There are two examples that often come to mind.

User Information / Data

Like radiation being useful for X-Rays and microwaving food, there are times where you need to handle user information and data. Though also like radiation, if you create too much of it for poor reasons, it becomes a much larger problem.

I’ve been using alfred on my macs for quite a number of years. I don’t remember how I first found out about it, but it’s nearly always the first thing I install on new machines. Should I move to Linux, I am certainly going to need to find an equivalent and onagre looks like it might be one potential replacement. Inspired by a random comment on mastodon, I thought it would be interesting to write about my most commonly used workflows.

I recently learned a new word, シンデレラフィット (Cinderella Fit) which amused me. It seems to be a term applied a lot when talking about various storage items from places like muji and ikea and refers to items that fit perfectly. I’m often reminded of it when I see videos on things like gridfinity where one tries to make a container that fits perfectly for each individual item. There’s a part of me that loves seeing things like BaseLynx , a customizable charging system that has a dock for each one of your devices. I think part of the appeal of having a 3D printer, is the idea that you can make a container to hold just about everything perfectly. There’s also a number of times I’ve wanted a cable of a very specific length. With more things using USB C, maybe that’s something obtainable, but there are still plenty of household objects that all have their own transformer block with weird sizes and such that I then want to hide away.

I was surprised when reading the changelog for Salt 3007.0 , regarding several deprecated modules to be removed in 3009.0. I also later read some of the policy changes on their blog. Going forward, they are planning on having a much smaller core module, and will be moving a lot of larger modules to external repositories.

I started using Salt while I was at Kotagent, and quite liked the way it worked. Even though a lot of teams at my current company use Ansible, I never enjoyed using it, and somewhat forced my team to switch to Salt (this was easy because my team was mostly just me). I think Salt tried to include too much into its core, and over time it feels like the increase maintenance burden resulted in a product that moves slow and was hard to improve. I hope having a cleaner core, and moving a lot of modules out will result in being able to have a more reliable core, while keeping it easy to extend via the various types of modules.

Loosely inspired by xinetd , I wrote a simple dev proxy launcher.

I have now been in Japan for 9 years. Japan is far from a perfect country and there are plenty of bits that cause irritation at times, but overall I feel like my normal day to day is pretty good. This past year definitely had some ups and downs and I have quite a lot to consider moving into 2024.

Rust has been on my list of things to learn for quite a while, and recently I have started to actually start learning it. I started with the Rust Book online, working through a chapter at a time, mostly during my weekly MokuMokuKai . After finishing the first I/O project I also went through the rust cli book to further check some of my understanding before moving on.

Right now I’m taking a short break from the book to experiment with a few small CLI applications in Rust to check my understanding. I use mqtt for many of my other projects, so one of my first small project is a set of mqtt tools to tail a server or send simple payloads. I am also reworking my worklog script and rewriting it from Swift into Rust to continue practicing. While I like Swift as a language, and there are libraries to help write a CLI, it feels like Rust might be better for the specific wrapper tools I want to write. Perhaps this will also lead towards me replacing Hugo with something else that is a bit easier to work with. Something like Zola could work if I want to keep it a static site, but I’m also thinking about going with a Django site this time.