Chish

A Game of Thrones

Unknown — Mon, 28 Sep 2026 00:00:00 +0000

Two Pointers

Unknown — Mon, 28 Sep 2026 00:00:00 +0000

##Approach

##Solution

##Learning

Escaping AI Tutorial Hell and Learning to Actually Think in Code

Unknown — Wed, 09 Sep 2026 00:00:00 +0000

Me and two friends are building a regex parser and interactive TUI in Go for Hack Club -- basically regex101, but running directly inside the terminal using Bubble Tea.

One friend took the engine (lexer, parser, NFA matcher), the third guy was building the bridge between the two, and I took the TUI.

Early in the project, I caught myself falling into a dangerous habit that almost every junior dev is struggling with right now. I stopped it before it ruined my learning, broke the crutch, and forced myself to build the core architecture from first principles.

Here is what that trap actually looked like, how I broke out of it, and the mental models that finally made things click.

##The New "Tutorial Hell"

We all know traditional tutorial hell: watching someone build an app on YouTube, coding along, and learning nothing.

The new version is subtler: personalized, infinitely flexible AI tutorial hell.

When I started sketching out the TUI, I wasn't blindly copy-pasting code blocks. I was asking questions, reading the suggestions, and manually typing the code out line by line. On paper, it looked like productive engineering—my commits were atomic, the editor was moving, and my WakaTime hours were ticking up.

But a couple of hours in, I paused and tested myself on a blank buffer. My brain went completely blank. I couldn't design a struct on my own, I couldn't figure out where a test file should live, and I couldn't sketch a layout from scratch.

I realized I was just copying someone else's homework. When you retype generated code, you're only exercising recognition memory ("I understand this line as I type it"), not generative recall ("I can architect this from nothing"). The moment you hit an edge case, you're helpless without the prompt box.

I immediately killed that approach. If I was going to build this TUI, every struct, layout calculation, and test needed to originate in my own head.

Here are the concepts that actually unfroze my brain.

##1. What Actually Goes in a Struct?

Whenever I tried to create a component, I'd freeze wondering what fields belong in a struct. Turns out I was overthinking it like some abstract OOP hierarchy.

A struct is literally just a block of memory holding variables that change together. The easiest way to think about it is three buckets:

Config stuff that never changes (max widths, fixed borders, keybindings).
State that changes on keystrokes (cursor index, is this pane focused, raw input text).
Cached outputs so you don't recompute heavy stuff every frame (match offsets, syntax error messages).

And if you don't know what to put in a struct yet? Just don't make one. Write raw variables inside a dirty test function first. The moment you find yourself passing three loose variables into multiple functions together, that's your struct telling you it exists.

##2. Terminal UIs are Just Bounding Box Math

Designing the TUI layout was another thing that paralyzed me. 2D space feels endless until you realize terminal windows are just a finite grid of cells (Width $W$ by Height $H$).

Every layout is just two splits: vertical (stacking) and horizontal (side-by-side). You classify every box as either Fixed or Stretchy:

Fixed: The header is 1 row. The regex input box is 3 rows. The status bar at the bottom is 1 row.
Stretchy: The test string editor and match results take whatever height is left.

Remaining Height = Total Height - (Header + Pattern Box + Footer)
Left Column Width = Total Width / 2
Right Column Width = Total Width - Left Column Width

Once I wrote that arithmetic out, the blank canvas vanished. It's just boxes inside boxes.

##3. The Git Conflict Panic

Then came our first real team workflow collision.

I finished the base TUI, merged it to main, and started working on macro navigation on a new branch. At the exact same time, my friend branched off to build widgets. Both of our features legitimately needed new fields inside our root AppState struct in app.go.

He finished first and merged his PR into main.

When I went to open my PR, GitHub slapped me with the red conflict warning. My initial reaction was "wait, did we mess up the repo? How do I even update this without blowing away my branch?"

Turns out the workflow is way simpler than I thought:

Stash dirty work: If you're halfway through writing something and it doesn't compile yet, don't make a messy "wip" commit. Just git stash. It cleans your working directory immediately.
Pull main directly into your branch: You don't need a crazy rebase dance. Just run:
```
git pull origin main
```

Fix the conflict markers: Open the file, find the <<<<<<< HEAD markers, and just keep both additions:

type AppState struct {
    // my fields
    NavIndex    int
    KeyMap      map[string]string
    // my friend's field from main
    ActiveWidget WidgetType
}

Compile and test locally: Run go build ./... and go test ./... before touching Git. If it compiles clean, git add, git commit, and push. The GitHub warning disappears.
Pop your unfinished work back if you stashed: git stash pop.

##The New Rule: The Closed-Tab Method

To actually get better (especially since I eventually want to write low-level systems code in Rust, Zig, and C++), I made a rule for myself on this project:

If I get stuck on how an API works or why an algorithm is failing, I can look it up or ask an LLM to explain the concept. Then I have to close the tab.

No copy-typing with the answer sitting on the second monitor. I close it, turn back to the editor, write the test case, break it, fix the off-by-one errors myself, and let my brain do the actual heavy lifting.

Currently writing the match span highlighter and unit tests by hand. It's slower, but the code is actually mine now.

VIA Not Detecting Your Keyboard on Linux? It Might Be a Stale udev Rule

Unknown — Fri, 04 Sep 2026 00:00:00 +0000

So I got a Rainy75 Pro keyboard. Great board, VIA support, the works. Plugged it into my Fedora 44 machine, opened VIA in Brave, and... nothing. VIA showed the device but immediately threw errors:

NotAllowedError: Failed to write the report.
Received invalid protocol version from device

Keyboard worked perfectly fine for typing. VIA worked perfectly fine on Windows. Just... not on Linux.

###The Red Herring: SELinux

First instinct on Fedora is always SELinux. The chrome://device-log output was showing Access denied opening device read-write, trying read-only, which screams permission issue. So I went down the SELinux rabbit hole:

sudo setsebool -P usbhid_access 1
# Boolean usbhid_access is not defined

Cool. Created a new udev rule with MODE="0666" and TAG+="uaccess". Reloaded rules, replugged keyboard... still broken. Set SELinux to permissive with setenforce 0... still broken. At this point I was convinced it was something weird with the VIA web protocol on Linux.

###The Actual Problem

Turns out I had a 92-via.rules file sitting in /etc/udev/rules.d/ from when I first tried to get VIA working (via some online guide). Here's what it had:

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", TAG+="uaccess"

Looks fine right? Except... 0664. That's not writable by the user. And because it matches KERNEL=="hidraw*" as a catch-all, it was hitting ALL hidraw devices — including the ones my new 99-rainy75.rules was trying to fix with MODE="0666".

The catch-all with the wrong permissions was silently overriding my fix.

###The Fix

Literally one line:

echo 'KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0666", TAG+="uaccess"' | sudo tee /etc/udev/rules.d/92-via.rules

Changed 0664 to 0666, removed the redundant 99-rainy75.rules, reloaded udev, replugged the keyboard, and VIA connected immediately. No SELinux tweaks needed. No browser flags. No desktop app install.

###How I Figured It Out

The real breakthrough was checking chrome://device-log in Brave (which is Chromium-based, so same internals as Chrome). It showed the full chain:

Chrome detects the HID device (vendor 0x320F, product 0x5055)
Tries to open /dev/hidraw3 read-write
Gets FILE_ERROR_ACCESS_DENIED
Falls back to read-only
Tries to write the VIA config report
Gets Bad file descriptor (9) because it opened read-only

Then I ran ls -la /dev/hidraw* and noticed the Rainy75 devices had crw-rw-r--. (664, no ACLs) while other devices had crw-rw-r--+ (666 with ACLs). The + means ACLs from TAG+="uaccess" were applied, but the underlying mode was still 664 from that old rule.

###Takeaway

If you're fighting VIA (or any WebHID/WebUSB tool) on Linux:

Check ALL udev rules, not just the one you created. A stale rule from a previous attempt might be overriding your fix. Look at every .rules file in /etc/udev/rules.d/ and lib/udev/rules.d/.
chrome://device-log is your best friend for debugging WebHID issues. It shows exactly which device, which operation, and which error.
Don't trust SELinux as the first suspect. In my case it was a perfectly innocent bystander. Always verify file permissions first with ls -la and getfacl.

Fixing Sphinx's Hyphen-Eating Search

Unknown — Tue, 01 Sep 2026 00:00:00 +0000

So Sphinx's search was doing this annoying thing where searching for -v or --force just... returned nothing. Even in docs that literally have those exact flags written out.

###The Mystery: Python Indexer vs JavaScript Search

My first instinct was to go poke the JS search code since, well, that's what actually runs the query right. But that's only treating the symptom lol, by the time a query even reaches the JS side, the index has ALREADY lost the hyphens. Turns out the Python indexer was stripping leading hyphens before terms even got stored. So -v was being indexed as just v, and no amount of JS fixing was ever gonna find that.

###Flags vs Compound Words

Real fix had to happen on the Python side, regex change. The annoying part was telling apart something like -v (a flag, keep the hyphen) from the hyphen inside extra-curricular (a compound word, don't treat it special). Those two cases look kinda similar but need totally different handling...

This is what led me to negative lookbehind, which I'd genuinely never used before. (?<!pattern) basically checks "hey is this pattern NOT sitting right before me" without actually consuming any characters. Zero width check, so it doesn't eat part of what you're trying to match.

###The Regex Fix

Ended up with this:

(?<!\w)-{1,2}\w[\w-]*|\w+

Reading it out... match one or two hyphens followed by a word character (and then whatever word/hyphen stuff after), BUT only if there's not already a word character sitting right before those hyphens. That's what kicks out the extra-curricular case while still letting -v and --force through clean. The |\w+ at the end is just... normal word matching for everything that isn't hyphen-flag-shaped.

PR's up against Sphinx now. Fingers crossed for review lol.

Devlog 01: Shared Types First

Unknown — Tue, 01 Sep 2026 00:00:00 +0000

Okay so, first real day on the Hackatime TUI. 3 person team, Bubbletea for the TUI part, one guy on backend wiring, one guy on widgets, and me doing dashboard/nav stuff.

###Unblocking the Team First

First thing I did was just... define the shared types. Dashboard, Filters, the whole shape of the panel data. Didn't touch any actual logic before this, cuz both backend guy and widget guy are kinda stuck until they know what the data even looks like. Felt like the responsible thing to do lmao, be the guy who unblocks everyone instead of just diving into my own corner.

After that I built out the fixed header, renders username, streak, the whole filter row (Date Range / Project / Language / OS / Editor / Category)... I basically just referenced the real Hackatime dashboard for this. It looks right now, which is nice, but it doesn't DO anything yet lol. Next up is making it actually usable, dropdowns opening/closing, moving the cursor around, filters actually triggering a refetch.

Also threw together the card and panel grid, just wireframes with empty slots for now (Project Durations, Languages, Timeline, etc) so widget guy has something concrete to build into whenever he starts.

Getting started is always the hardest part for me, every single time. But once the first commit was up everything just kinda... flowed after that.

###The Planned Layout

This is our planned layout for the dashboard:

┌──────────────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ [●] Chish 🇮🇳     │ Keep Track of Your Coding Time                                                   │
│ [🔥 3 day streak]│ Today: 43m 27s logged (Python, JS, Rust, etc.) using Neovim & VSCode             │
│                  ├──────────────────────────────────────────────────────────────────────────────────┤
│ > [Home]         │ [Date: All Time ▾] [Project: All ▾] [Lang: All ▾] [OS: All ▾] [Editor: All ▾]    │
│   Projects       ├──────────────┬──────────────┬──────────────┬──────────────┬──────────────────────┤
│   Settings       │ TOTAL TIME   │ TOP PROJECT  │ TOP LANGUAGE │ TOP OS       │ TOP EDITOR           │
│                  │ 520h 34m     │ kasumi       │ Rust         │ Linux        │ VSCode               │
│                  └──────────────┴──────────────┴──────────────┴──────────────┴──────────────────────┤
│                                                                                                     │
│ ┌─ Project Durations ────────────────────────────┐ ┌─ Languages ──────────────────────────────────┐ │
│ │ kasumi            ██████████████████ 31h 28m   │ │ Rust       ████████████░░░░░░░░░  38%        │ │
│ │ skora-backend     ██████████████████ 31h 27m   │ │ Python     ████████░░░░░░░░░░░░░  22%        │ │
│ │ stacksense        █████████████░░░░░ 22h 25m   │ │ Svelte     ████░░░░░░░░░░░░░░░░░  12%        │ │
│ │ the-verse-...     ██████████░░░░░░░░ 19h 54m   │ │ C / Go     ███░░░░░░░░░░░░░░░░░░   8%        │ │
│ │ desktop-editor    ████████░░░░░░░░░░ 16h 44m   │ │ Other      ██████░░░░░░░░░░░░░░░  20%        │ │
│ └────────────────────────────────────────────────┘ └──────────────────────────────────────────────┘ │
│                                                                                                     │
│ ┌─ Editors ──────────────────────────────────────┐ ┌─ Operating Systems ──────────────────────────┐ │
│ │ VSCode            ██████████████████  48%      │ │ Linux      ████████████████████  100%        │ │
│ │ Neovim            ██████████░░░░░░░░  28%      │ │                                              │ │
│ │ Zed / CLion       ████░░░░░░░░░░░░░░  14%      │ │                                              │ │
│ │ Godot / Other     ███░░░░░░░░░░░░░░░  10%      │ │                                              │ │
│ └────────────────────────────────────────────────┘ └──────────────────────────────────────────────┘ │
│                                                                                                     │
│ ┌─ Project Timeline (Stacked Weekly Activity) ────────────────────────────────────────────────────┐ │
│ │ 22h ┤  █                                                                                        │ │
│ │ 16h ┤  █                                                                                        │ │
│ │ 11h ┤  █    █         █                                                                         │ │
│ │  5h ┤  █    █    █    █    █    █    █                                      █                   │ │
│ │  0h ┴──┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴───────────  │ │
│ │       Jun15 Jun22 Jun29 Jul6 Jul13 Jul20 Jul27 Aug3 Aug10 Aug17 Aug24 Aug31                     │ │
│ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ │
│                                                                                                     │
│ ┌─ Coding Rhythm (Activity Heatmap) ──────────────────────────────────────────────────────────────┐ │
│ │      12AM    3AM    6AM    9AM   12PM    3PM    6PM    9PM                                      │ │
│ │ Mon  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■][■]                               │ │
│ │ Tue  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■]                               │ │
│ │ Wed  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■][■][■][■][■][■]                               │ │
│ │ Thu  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■]                               │ │
│ │ Fri  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■][■][■][■][■][■]                               │ │
│ │ Sat  [ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■][■][■][■][■][■][■][■]                               │ │
│ │ Sun  [■][■][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][■][■][■][■][■][■]                               │ │
│ └─────────────────────────────────────────────────────────────────────────────────────────────────┘ │
│                                                                                                     │
│ ┌─ Today's Goal ─────────────────────────────────┐ ┌─ AI vs Human Coding ─────────────────────────┐ │
│ │               ╭─────────╮                      │ │ [AI 7%]                [Human Coding 93%]    │ │
│ │               │   73%   │                      │ │ ███░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    │ │
│ │               ╰─────────╯                      │ │                                              │ │
│ │ 27% below usual  |  Today: 43m / Usual: 59m    │ │ AI: 32h 15m (7%)   |   Human: 450h 58m (93%) │ │
│ └────────────────────────────────────────────────┘ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────────────────────────┘

###Current Progress

Here is how the wireframe looks right now in the terminal:

Diving into C++ as a Rust Developer

Unknown — Fri, 26 Jun 2026 00:00:00 +0000

I recently decided to learn C++ alongside my Rust knowledge. My initial impression is that modern C++ (C++20/C++23) is much cleaner than the old legacy tutorials make it out to be.

###What is interesting so far:

References and Pointers: In Rust, the compiler forces me to think about lifetimes constantly. In C++, I have to enforce those exact same rules in my head.
RAII: Resource Acquisition Is Initialization is basically how C++ handles cleaning up memory when variables go out of scope, which maps directly to Rust's Drop trait.

I will be posting my progress here as I read Bjarne Stroustrup's A Tour of C++ and work on my custom heap allocator.

let code: i32 = 64;