My 10yo (Pradyumn) got interested in coding last year. I wasn’t so sure about it in the beginning since I didn’t want to force my career choices or interests on to him. But I realized that he wanted to do it of his own accord, so I agreed to help him. But our deal was that I will introduce him a bit to the learning resources and help him out with his doubts here and there, while he will peruse all the learning material and build his things on his own without much interference/interaction with me.

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.