I’m a sucker for screen real estate, and thus I use 2 32" 4k monitors so I can see most of my apps’ windows simultaneously, instead of switching back and forth between them.

#myworkplace is pretty lean (on cables) and mean (on screen real estate). And a lot of tileception goes on (window tiling, then local tmux tiling, then 1-2 levels of remote tmux tiling) pic.twitter.com/wCqsusBfRb

— Shantanu Goel (@shantanugoel) August 10, 2020

I use the awesome Rectangle app that provides shortcuts to move/resize an app window to my liking. However, this goes for a toss whenever I disconnect my laptop, or reboot it. macOS can’t seem to reliably remember where to put the windows at such events and I’ve to keep playing this game of doing a lot of alt-tabs and rectangle keyboard shortcuts to get my app windows back where I like them. So, I spent some time recently to whip up a short hammerspoon script that allows me to do this easily.

Auto generated files in a project are pretty common. There are generally 3 scenarios for this in a project that needs auto-generated files:

• An external pre-built tool generates files pre-compilation and then the generated files get checked in to the tree
• The tool is compiled in-tree but is again used to generate files pre-compilation and then check them into tree
• The tool is built during the main build step and then it also generates the needed files just in time.

Arguably, the last method is usually the better one since it keeps friction to a minimum during development by always generating latest files according to any changes done locally and also prevents against the human error of someone foregetting to commit the separately generated files, or having a time period where the tree is out of sync because the generated files and hand written files were committed separately. There is a con as well that such files are not available for someone going through the code statically for understanding or debugging. But one could always couple both methods if so desired.

I’m going through this brilliant book, Crafting Interpreters, these days to learn more about how interpreters are built. My attempts so far have been ameturish, as I’ve never had a formal CS course, and this looked useful to upskill my toolkit. However, the book implements the interpreter in Java (at least the first part, which I am going through now) and I’m trying to follow along in C++ instead since I don’t have much experience in Java, neither an inclination to learn it. In one of the chapters, the author uses a Java “Object” class to hold the literal values that may appear in the script being parsed by the interpreter. Java docs say that:

I’m a backup nerd and like to back-up everything I do. Not just that, I like to version them too so I can go back in time to any point. git serves as a good tool for me for versioning wherever small data/text files etc are concerned and then I back this up with remote git servers like my own git server on a raspberry pi at home, a gitlab server and a github server. Prime targets for this are my dotfiles that I edit in spacemacs and my notes that I take in Joplin. The only issue though is that every time I change something, which is pretty often (since I’m a tinkering nerd too) I’ve to manually commit the changes and push them upstream. Apart from being all kinds of nerds, I’m an automation nerd too, which is a fancy way of saying that I am lazy, but I digress.

I added a Raspberry Pi 4B recently in my ever expanding homelab. To get the best network with the new gigabit ethernet port on the raspi, and still save power, I added a PoE hat to it so I could power the raspi as well as provide it data through the ethernet port. Everything worked fine except that I ocassionaly got into situations where the raspi stopped responding suddenly. Initially I thought that it’s crashing due to some issues and used to just restart it manually. I tried switching from manjaro-arm to raspbian as well but that showed same symptoms, despite updating to the latest bootloader and firmware as well. Then I noticed that I could hear the fans on the PoE hat whirring up and settling down even when the raspi was inaccessible. This put me in a doubt that the raspi hasn’t actually crashed, because the fans whir up and go down according to the CPU temperature. So this pattern meant that the CPU was still doing something to heat it up. A trip to the kernel logs via journalctl -xe confirmed the doubt and also showed a few weird messages about the ethernet.