This is a new "series" I'm starting. I haven't decided the frequency yet, but probably like weekly or biweekly or just whenever. Let's see how it goes. The goal of this series is to share what I've been spending my time on, some thoughts and some cool or interesting things I've learned or come across since the last Devlog.

Dev

For the past few weeks, I've spent time building chronobsky and adding support for LG's WebOS to my own fork of jiotv_go. Finally, my legacy frontend engineering skills are coming in handy. Kinda sad to see that after almost 3 years of offering free premium TV channels, Jio is now introducing subscriptions, but it was fun while it lasted.

Having worked extensively with React from the pre-LLM era, I automatically used to underestimate how performant the browser's HTML rendering is by default for static content, and used to add things like pagination and virtualization. With LLMs, dynamically stitching HTML components at build time has become really easy.

One thing I've realized is that with AI, it's very addictive to introduce slop in your projects. For example, adding a TUI dashboard in glesha turned out to be pretty much a useless feature, but at the time of introducing it, I just couldn't resist "vibe-coding" one specific independent-ish module in the project, and I've spent the past week de-sloppifying the codebase. Nowadays, I kinda sit on any idea that comes to my mind a little bit longer to see if I really want it in.

Tailscale

If you use more than one device and need to ssh to and from each other quite frequently and haven't heard of Tailscale yet, you should drop everything you're doing and take 5 minutes to set all devices up, and it's definitely worth it. I have been hearing about Tailscale every now and then for the past few years, but never bothered to actually check it out because I didn't even know what it does. I wish I had looked into it way earlier.

I have two laptops and a Raspberry Pi (Zero 2W), and I also have two different ISPs for my internet, one is stable but slow, another is unstable (frequent disconnects) but fast. pi is always connected to the stable but slow network, but this is not the case for my laptops. I also have a tiny VPS for tinkering, and I ssh into these devices very frequently.

Before this, I used to switch networks just to be able to connect to my Pi. I had also looked into both routers' settings if I could connect them so that I could access devices connected to two different routers, but there was no easy way to do this so I just didn't bother. I knew one way to do this by editing /etc/hosts and similar files on each device and using static local IPs for each device, and maybe setting up port-forwarding to access over the internet, but it just felt like too much work, and then there's the obvious exposure-to-internet aspect. As a last resort, I googled "how people usually do this" and found out that Tailscale does exactly this, automatically, and only devices in the tailnet can communicate with each other, and external actors cannot because Tailscale uses a reserved IP range that isn't publicly routable.

Moving back to Alacritty

I was using alacritty terminal for the longest time, and I've been trying out alternatives like st and foot. Mainly because each window of alacritty terminal took ~200MB (wasn't aware of create-window yet), which seemed very unfair, and also I never really noticed why GPU-acceleration was needed to just render text on screen.

I tried st at first. It felt way too barebones but on the bright side, it also took very minimal ~10MB memory for each instance. For st, the font-rendering somehow felt worse for me. Also to configure st, it required patching source code and recompiling. As a result, I decided to move on to the next candidate, the builtin default of sway, the foot terminal. It took ~24MB for each instance, had saner configuration support. I had been using foot ever since, until last week when the opencode CLI just kept crashing foot. I never thought a CLI program would be capable of crashing a terminal. After spending around 5 to 6 months with foot and reconsidering other options yet again, this time the candidates were ghostty and alacritty, and ghostty just felt too early-stage for me.

By the way, after using a terminal that uses CPU rendering for a while, the difference of GPU accelerated rendering is very noticeable to me, and ~200MB feels worth it. One good thing I didn't know earlier is the use of alacritty msg create-window which is a life-saver and makes all the difference to me. Now it's just a single ~200MB, with ~8MB of /bin/bash for each newly spawned terminal window. So, for the foreseeable future, I think I'll stick with alacritty until something better comes along.

DSA

  1. One micro-optimization in Java is computeIfAbsent. Not only is it shorter to type, it also avoids creating throwaway ArrayList<>() instances.

    // bad
List<Integer> existing = map.getOrDefault(x, new ArrayList<>());
existing.add(y);
map.put(x, existing);

// good
map.computeIfAbsent(x, k -> new ArrayList<>()).add(y);

  2. BFS can be done without explicitly creating the entire graph upfront, especially when finding neighbors of a vertex isn't expensive.

  3. Sometimes, you can introduce auxiliary/dummy vertices in a graph problem; this can simplify the problem by representing repeated transitions as one step, and you can avoid doing extra repetitive work.

  4. When creating a prime sieve, it's more efficient to start marking composite numbers from i*i instead of 2*i if i is prime, because all composite numbers from i...i*i already have a prime factor that's less than i so they would have already been marked composite by a smaller prime number.

Some of the things I've read or been reading over the past few weeks -

By the way, if you're interested, you can check out all devlogs here.