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.

Interesting Links

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

• Open social - https://overreacted.io/open-social
• How OpenAI delivers low-latency voice AI at scale - https://openai.com/index/delivering-low-latency-voice-ai-at-scale

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

Tradeoffs

Of course, there are tradeoffs. Otherwise ropes would have been the de facto standard for implementing strings in any programming language. The reason they're not quite as popular is because they solve a very niche problem involving large immutable strings, frequent concatenation, substring sharing, or editor-like updates. As a result, almost all of the popular engines use different underlying representations for strings, based on the length. One possible use case that I can think of is React's renderToString().

Ropes actually perform worse for short strings because of the pointer overhead and cache locality, and in a typical workload, most strings are usually small. As a result, engines use plain one-byte (ASCII) or two-byte (UTF-16) strings, until the length of the string exceeds a threshold, at which point a rope-like (extending the idea of ropes from the original paper) structure is used which uses flatten-on-demand. It means concat()s are O(1) since it modifies ~2 nodes, and when the tree is rebalanced (rope is flattened) is engine-specific. Mostly it's flattened when there's a request for linear char buffer, indexing, native interop, or certain substring paths. It gives the best of both worlds, concat()s are faster, and we don't have to spend time rebalancing until we actually need it. The amount of ad-hoc optimizations these engines do is fascinating.

Implementation

Alright, let's go through the original paper. The idea of storing data in the leaf nodes and information about the data in internal nodes of the tree isn't new, B+ trees existed since early 1970s. However, B trees self-balance on insertion, with at most O(log n) node updates, but in case of ropes, rebalancing could cost O(rope_len) in the worst-case, which means worst-case adversarial input can be generated that triggers rebalancing after every concat().

The paper mentions length of rope should be at least F(n+2) for a depth of n. But how do fibonacci numbers come in the picture while describing the definition of a balanced binary tree? The usual definition of a balanced binary tree is abs(h(left)-h(right)) <=1 (i.e. heights of left and right subtrees of every node in the tree differ by at most 1), which means for a tree to be balanced -

1. For depth=0, min_leaves_required=1
2. For depth=1, min_leaves_required=2
3. For depth=2, min_leaves_required=3
4. For depth=3, min_leaves_required=5
5. For depth=4, min_leaves_required=8 ... and so on

which forms a sequence 1,2,3,5,8... which is a standard fibonacci sequence shifted by 2, hence the bound ofF(n+2). You can verify these values by drawing a balanced binary tree on paper. So, given a rope's total length and current tree depth, we can efficiently get a rough estimate of whether the tree needs rebalancing after a concat() operation.

I also like how the paper just assumes you have a garbage collector at your disposal, and even hints at using reference counting if you're implementing in a language like C. Let's not implement a GC here, maybe some other day, in another post. Let's use Go and for simplicity we will only consider ASCII strings for now. We'll see how things might change for UTF-16 later.

The API contract looks something like this -

type Rope interface {
  Len() int
  String() string
  Concat(other Rope) Rope
  At(index int) byte
  root() *node
}
type rope struct {
  root *node
}

// expose root via root()
func (r *rope) root() *node {
  if r == nil {
    return r
  }
  return r.root;
}

The paper specifies, we require some notion of "sequence of characters" for leaf nodes. Let's use strings for that. It also mentions tree indexed by position, it means we need to store some information about the length of string represented by a node. Let's use totalLen for that. The node will look something like this -

type node struct {
  left *node
  right *node
  leaf string
  totalLen int // length of substring represented by this subtree
}

Let's start with implementing easier and straight-forward Len() and Concat() first. Since we're maintaining totalLen for each node, Len() is trivial. For Concat(), we just create a new parent root node, and attach roots of the two ropes as left and right children of this newly created node. Note that since we're not doing any rebalancing, this operation is O(1).

// length
func (r *rope) Len() int {
  if r == nil || r.root == nil {
    return 0
  }
  return r.root.totalLen
}

// concat
func (r *rope) Concat(other Rope) Rope {
  return &rope{root:concat(r.root, other.root())}
}

// helper
func concat(a *node, b *node) *node {
  if a == nil {
    return b
  }
  if b == nil {
    return a
  }
  return &node{
    left:a,
    right:b,
    totalLen: a.totalLen + b.totalLen,
  }
}

Let's implement String() now, which is a standard in-order tree traversal.

func (r *rope) String() string {
  if r == nil {
    return ""
  }
  return r.root.String()
}

func (n *node) String() string {
  if n == nil {
    return ""
  }
  if n.left == nil && n.right == nil {
    return n.leaf
  }
  return n.left.String() + n.right.String()
}

The idea for implementing At(x) is to do a DFS from root node, since we store total length represented by subtree under the node, it tells us if we need to explore left or right subtree. Once we are at the leaf node, we just return the character in the leaf string chunk. For simplicity, let's ignore out-of-bounds errors.

func (r *rope) At(index int) byte {
  return r.root.at(index)
}

func (n *node) at(index int) byte {
  if n.left == nil && n.right == nil {
    return n.leaf[index]
  }
  leftLen := 0
  if n.left != nil {
    leftLen = n.left.totalLen
  }
  if index < leftLen {
    return n.left.at(index)
  }
  return n.right.at(index-leftLen)
}

Now the only challenging part remaining is rebalancing the tree. The idea is to rebuild a balanced tree. Since the left-to-right order of leaves gives the canonical representation of the text we are storing, we first collect leaves by traversing similar to how we did it in String() implementation. After collecting the leaves, we build the new tree by recursively splitting the collected leaves in half and combine the two halves with concat().

            root                            root
           /    \                          /    \
        node     "gh"       ---->       node     node
       /   \                           /   \    /   \
    node    "ef"                    "ab"  "cd" "ef" "gh"
   /   \
"ab"  "cd"

collected:["ab","cd", "ef", "gh"]

Let's implement rebalance() now. We can call this rebalance() whenever it's optimal to do so.

func (r *rope) rebalance() *rope {
  if r == nil || r.root() == nil {
    return r
  }
  return &rope{root:rebalance(r.root())}
}

// helper
func rebalance(n *node) *node {
  if n == nil {
    return n
  }
  if n.left == nil && n.right  == nil {
    return n
  }
  leaves := make([]*node, 0)
  collectLeaves(n, &leaves)
  return buildBalanced(leaves, 0, len(leaves))
}

// collect leaves in order
func collectLeaves(n *node, leaves *[]*node){
  if n == nil {
    return
  }
  if n.left == nil && n.right == nil {
    *leaves = append(*leaves, &node{leaf:n.leaf, totalLen:n.totalLen})
    return
  }
  collectLeaves(n.left, leaves)
  collectLeaves(n.right, leaves) }

// build a new balanced tree
func buildBalanced(leaves []*node, L, R int) *node {
  if L >= R {
    return nil
  }
  if R-L == 1 {
    return leaves[L]
  }
  M := L + (R-L)/2
  left := buildBalanced(leaves, L, M)
  right := buildBalanced(leaves, M, R)
  return concat(left, right)
}

This wraps-up our basic implementation of ropes. Of course we could re-use leaf nodes and do a ton of other optimizations, but hopefully the basic idea is clear now.

References

For further reading:

1. Ropes: an Alternative to Strings
2. Fast string concatenation in JavaScript
3. Rope (Data Struture) - Wikipedia

I applied to a few positions on Amazon's career portal a few months back because even though Amazon looked very busy breaking their own records in laying off employees, their careers page also had a few recent openings. Anyway, after 3-ish days, I received an OA, which had 2 problems to be solved in 90 minutes, a "work-style simulation" based on their "leadership" principles and a somewhat basic system design quiz.

Online Assessment

It had two problems, surprisingly both problems were based on bitwise operations. First problem was of medium difficulty, I cannot share the exact problem, but it was based on range XOR sum queries (via prefix XORs), and was trivial if you knew the ball knowledge:

XOR_SUM(a[i]..a[j]) = pref[j]^pref[i-1];

Second problem was this one, it was hard but I was able to come up with a greedy approach where we start with 0 as our candidate answer for final AND, and try to get 1 at each position of our candidate answer starting from MSB to LSB, where we check the feasibility of including m least expensive elements using at most k total increments.

I was able to solve first problem within ~15 minutes, and spent the rest of the time on the second problem.

I also skimmed through the Amazon LPs before the OA, so I don't mess up the workstyle assessment questions.

Round - 1

Interviewer was SDE-2, he was younger than me, he joined 5 minutes late, I was already nervous pro max and panicking because this was my first time interviewing for FAANG, he joined and said don't worry we'll extend by 5 minutes. We introduced ourselves, and he jumped to problem solving right away.

First problem was this one, which I knew how to do, so I told the optimal solution, stated complexity, asked if I should start writing code, coded it up, we were past 20 minutes by now.

Then he asked the second problem this one, for which I was able to come up with a brute force BFS solution, but I ran out of time. I regret picking java as my language of choice for the interview. Also, my solution wasn't really optimal, the interviewer tried to give me hints, but I crumbled under pressure of time running out since he had mentioned in the beginning he is expecting optimal solutions to BOTH problems. As soon as the interview was over, the hint he gave clicked, but it was already too late. I was not able to complete the bfs(...) function because it's standard and I have run out of time. He said now he has to ask me some questions based on LPs, which he asked and I answered.

Round - 2

Two weeks went by, and my second round was scheduled, this guy looked really tensed for some reason. After introduction, he asked me to write API for music library app, expectation was to tell class design for entities and only requirement was that he wanted low latency for getTopKPlayedSongs(k) and getTopKPlayedSongs(artistId, k), addSong(artist, song). I started with listing out entities like Player, Artist, User, Song, Library etc, and then I went blank, I knew how to do getTopKSongs(k) in O(log n) with a HashMap<Count, Set<SongId>> and a TreeSet<SongId,Count> combo, which I told when I ran out of time, but again, the expectation was to get a "production-level" code in 30 minutes.

It requires at least one soft yes to get to round 3 and round 4, and knew immediately after second interview was over that I didn't get it.

Key takeaway is, time is way more limited in these interviews, you get ~20 minutes to explain and code the optimal solution. Good thing is, I was able to solve every problem so far, so we're past "wtf do i even do here man" stage, so that's some progress, but need to work on time and not panicking.

We're just not there yet gang, the grind must go on, maybe in next 6 months :)

Migrating to a new domain

So, on one fine day, I was chitchatting with gemini about why my old domain txds.me was not ranking properly in the Google's search results, even after I specifically told claude to "make sure my site is SEO optimized". It kind of did the job since I currently rank 5th if I search for txds on Google and that's nice for me being a nobody, and to be fair, txds isn't even really related to me in any way. It was just toxdes without vowels to get a shorter domain for my personal space on the internet.

Now why toxdes? well, I started using internet really late, so all the cool usernames that made sense were already taken everywhere, so I had to work with whatever was available at the time, and I have stuck with it ever since. Gemini also convinced me to use toxdes.com because nothing significant exists for this word. I also tried my firstname+lastname combo, but turns out my name is way too unfairly common than it should be, so here we are.

By the way, I also checked historical `whois` data, and found out that txds.me was registered at least 8 times in the past, and toxdes.com wasn't registered even once. It's a really nice tool.

The migration is pretty much complete, and moving forward I'll be exclusively using toxdes.com. I currently use Cloudflare to manage DNS records, and this website is also statically hosted on Cloudflare pages. I also host some of my historic personal projects on github pages and vercel under subdomains. Vercel's dashboard has a functionality to add *.toxdes.com domain, and setup redirects for*.txds.me to redirect to the newly added domain, so those were easy. I migrated from netlify to vercel for one old project, it was just easier to manage that way. And for the github pages site and the main txds.me domain, I am using Cloudflare's redirect rules.

Adding likes to blog posts

I've been learning about system design since forever, and I thought this might be a good idea to burn some tokens add a little bit of "server-side" state to this website.

We live in exciting times nowadays where realizing an idea is just few prompts away, I quickly ended up vibe-coding `counter as a service`. The goal was simple, adding "likes" to my posts. Within 2-4 prompts, I was able to get a multi-tenant counter backend server as a single binary which exposed some HTTP endpoints and synced state to the postgres database.

I also added a small in-memory LRU cache to do async updates to the postgres database, mainly because redis felt like an overkill. Perfect little solution for a perfectly little problem. I know it can be abused easily, and cannot really scale well, I'll hopefully improve it and make it a little bit more reliable as the time goes by, but for what it's worth, it's good enough for now.

Why write more

I always felt like I had nothing to share, and I'm not a good enough engineer to share non-trivial computer science things and with the recent advancements of LLMs, writing blogs felt actually pointless.

Recently, I also had a good chat with someone who smuggles decent engineers to startups and he told me "you're mid bruh". I mean it's true, to some extent, but man did it feel brutal. Anyway, I was weirded out when he asked why do you have only 2 blogs in three years, and I was like what's the point in writing trivial stuff. Anyway, the good takeaway from the chat was writing a tech blog was never about storming the frontier of advancement in computer science research, which feels strange now as I type it out, but it was exactly what I used to think - everything I ever knew about programming and computers always felt like explaining how to do add two numbers 6+7.

After the chat, and some pondering, I have had a change of heart, and I have decided to write more. I think I'll start writing whatever trivial things I know, or will learn next.

I think I'll start by writing about failing my Amazon's SDE-2 interviews.

But there was one thing I missed from the React world: motion.

Static sites often feel "dead." You click a link, the screen goes blank, and the new content appears. I wanted it to feel alive, preserving context as the user navigates, but without bringing megabytes of javascript to hydrate a virtual DOM just to animate a div.

Enter the View Transitions API

Specifically, Cross-Document View Transitions. This API allows the browser to snapshot the old state and the new state, then morph between them. It’s native, hardware-accelerated, and requires zero client-side routing, truly magical.

The Chrome team's intro covers the mechanics well, but here is how I'm using it to make this static site feel a little bit alive.

The setup is deceptively simple. You just tell the browser to look out for navigations by adding the css:

@view-transition {
  navigation: auto;
}

When user navigates from the "Home" page to the "All Posts" page, I didn't want a hard cut. I wanted the recent posts to physically travel to their new positions in the full list.

This is made possible with Shared Element Transitions. The concept is simple: if you give two elements on different pages the same view-transition-name, the browser matches them up and handles the geometry.

<!-- On both the Home page and the Blog List page --> 
<li style="view-transition-name: post-item-${slug}">
  <!-- The entire item morphs -->
</li>

Things are a bit more interesting when you click into a specific article. I wanted the title and date to translate from the item and settle into the header of the post.

To make this work, we need to be more granular. Instead of transitioning the whole item, let's assign specific names to the text nodes inside the card.

<!-- In the List Item -->
<li>
  <span style="view-transition-name: post-date-${slug}">2026-01</span>
  <span style="view-transition-name: post-title-${slug}">Introduction to View Transitions</span>
</li>

<!-- In the Blog Post Header -->
<article>
  <h1 style="view-transition-name: post-title-${slug}">Introduction to View Transitions</h1>
  <div class="post-meta">
    <i style="view-transition-name: post-date-${slug}">Published Jan. 2026</i>
  </div>
  <!-- rest of the content -->
</article>

Because the names match, the browser performs a smooth "morph" transition, scaling the font size and translating the position automatically. BROWSER DOES ALLAT FOR YOU, isn't that cool?

// Current time
new Date()
// Milliseconds since epoch
new Date(1736533800000)
// String parsing
new Date('2023-11-24')
// Year, month, day
new Date(2023, 10, 24)
// Year, month, day, hour, minute
new Date(2023, 10, 24, 21, 30)
// Year, month, day, hour, minute, second, ms
new Date(2023, 10, 24, 21, 30, 45, 500)

If you give it an ISO date without a time (just YYYY-MM-DD), it assumes UTC midnight. But if you add a time without the Z, some browsers treat it as local, others as UTC. This isn't theoretical. Chrome and Firefox have behaved differently on this exact case.

The Z matters. Always add it if you want UTC.

// parsing date string
new Date('2023-11-24') // ISO date (no time)
new Date('2023-11-24T21:30') // ISO date with time (no timezone)
new Date('2023-11-24T21:30Z') // ISO date with time (UTC)
new Date('2023-11-24T21:30+05:30') // ISO date with timezone offset

When you pass numbers to the constructor, things get strange fast.

new Date(2023, 10, 24)  // November 24, 2023

Wait. November? We passed 10. Why November?

Because months are zero-indexed. January is 0, December is 11. This comes from C's tm struct from 1972. Java copied it. JavaScript copied Java. Now we're stuck with it. Does that mean 24 is also actually 25? Well...no, days are numbered from 1 to 31.

One more thing:

new Date(2023)      // Not year 2023!
new Date(2023, 0)   // This is year 2023

A single number isn't a year. It's milliseconds since January 1, 1970. So new Date(2023) is 2.023 seconds after the epoch, which is January 1, 1970, 00:00:02.023. So, If you want year 2023, you need at least two arguments: year and month.

But wait, there's more:

new Date(99, 0, 1)   // January 1, 1999
new Date(100, 0, 1)  // January 1, 100 AD
new Date(2023, 0, 1) // January 1, 2023

Years 0-99 get treated as 1900+n. This is Y2K panic code. Someone was worried about legacy code passing two-digit years, so they added this special case. Year 99 becomes 1999. Year 100 is literal.

Guess the Output: A Simple Algorithm

Here's how you would do to predict what the Date constructor will do:

Step 1: Count the arguments

1. 0 arguments? Current time.

2. 1 argument and it's a number? Milliseconds since epoch. Not a year.

3. 1 argument and it's a string? Parse as date string. ISO 8601 is safe. Anything else is a gamble.

4. 2+ arguments? year, month (0-indexed), day, hour, minute, second, millisecond in that order. Everything is in local time.

Step 2: For 2+ args, Check for two-digit years

1. If first argument is between 0-99, add 1900. Year 25 becomes 1925.

2. If first argument is 100+, it's the literal year.

Step 3: Month wrapping

1. Month argument is 0-indexed. 0 = January, 11 = December.

2. Month 12? Wraps to January of next year, same with larger values. So, new Date(2023, 20) is 01 Sep 2026.

3. Similarly, Month -1? Wraps to December of previous year.

Step 4: Day wrapping

1. Days range from 1 to <max_for_the_month>.

2. Any numbers outside of the range, are wrapped to next/previous month. So, new Date(2023, 2, 32) (allegedly 32nd march) becomes 01 April 2023. Same with negative numbers.

Step 5: Timezone

1. String with Z? UTC.

2. String with timezone offset like +05:30? Parses offset but doesn't store it.

3. String without timezone? Pray.

4. Number constructor (2+ args)? Always local time.

Step 6: Invalid input

1. String that doesn't parse? Invalid Date object. No error thrown.

2. NaN in any argument? Invalid Date.

3. undefined in any argument? Treated as NaN, so Invalid Date.