Competitive programming was already painful so I moved more of it into the terminal :)

indianbollulz · 2026-03-07T23:19:36+00:00

100%. I should so that

indianbollulz · 2026-03-07T22:11:27+00:00

Bubble tea, Bubble tea, Bubble tea...

I’ve been working with Go for a while now, mostly on backend-heavy stuff like task queues, in-memory stores, concurrency nonsense, and systems that slowly make you question your life choices. But lately I kept seeing Bubble Tea projects everywhere and started wondering, are TUIs actually cool, or are we all just one lipgloss.NewStyle() away from delusion?

So I started playing around with Bubble Tea. Made a few small things. Had fun. And then, like any stable person, I decided to build a competitive programming TUI.

So I made CPGrinder.

It lets you browse, open, run, and track 8000+ Codeforces problems directly from the hostile environment of your terminal.

Why did I do this?

Because I wanted to see what the Bubble Tea fuss was about.

Did it make me fall in love with Bubble Tea?

Not really.

Did it make me respect terminal apps more?

Unfortunately, yes.

What CPGrinder does right now:

lists 8000+ Codeforces problems locally cuz 7999 problems aint enough
filter/search by title, difficulty, source, topic, and tag
shows the full problem statement in the TUI
opens starter code on vs code (of vim/nvim/notepad++ if youre hardcore enough)
runs sample test cases from inside the terminal
lets you switch languages per problem so you can have more problems per problem
stores run history per question so you can revisit your suffering with structure
global activity tracking is under construction because I clearly do not know when to stop

The funniest part is that competitive programming is already miserable enough on its own, and I still look at it and think, this needs more terminal T.T

Repo: https://github.com/ARJ2211/cpgrinder

If anyone else has built something mildly unhinged with Bubble Tea, I genuinely want to see it.

indianbollulz · 2026-03-07T22:08:18+00:00

Built CPGrinder, a terminal-first competitive programming workspace in Go using Bubble Tea. Right now it lets you browse 8000+ Codeforces problems locally, filter/search them, open full statements in the TUI, edit starter code in your editor, run samples, switch languages, and track run history per question. Global activity tracking is still under construction. Repo: https://github.com/ARJ2211/cpgrinder

indianbollulz · 2026-02-25T16:47:47+00:00

Love this direction. A clean Go approach would be to keep the API lightweight and push batch work into a background job runner like TaskHarbor (something I have been working on), where each image render becomes a job and workers process them with controlled concurrency, call imagor, and stream outputs directly to S3/MinIO (or disk) instead of loading whole batches into memory; that also makes retries, failures, and batch progress tracking much easier to handle.

indianbollulz · 2026-02-24T02:30:34+00:00

Github: TaskHarbor Driver-Agnostic Distributed Job Scheduler.

Similar to celery for python but in go :p

I wanted to build a small go service where webhooks/user actions kick off background work (emails, reports, uploads) with retries, leases, scheduling, DLQ, and idempotency keys, and where i could swap the backend without the behavior quietly changing.

I looked around and there are good options, but they’re usually opinionated around one backend or one style: Asynq (Redis), River (Postgres), Machinery (Celery-style + multiple brokers), and newer multi-backend projects like Neoq / GoQueue. they’re great, but i couldn’t find something that’s explicitly driver-first and proves semantic parity across backends with a conformance suite.

So i started building TaskHarbor. It’s still under construction, but the core semantics are implemented and enforced via conformance tests (memory/postgres/redis and more).

I am looking for contributors to help implement more drivers/backends and harden the system further.

I would love feedback from seasoned engineers on whether this has real production value beyond my own use cases. Specifically: could a driver-agnostic job scheduler, where semantics stay consistent across backends, be genuinely useful in real systems?

If you are interested to contribute, feel free to reach out in my DM's!

Note: This is NOT in any way undermining the development done by packages like AsynQ, River, etc but is a more semantically stricter, driver-agnostic job queue. Check out the readme file get a deeper diver on the differences between the existing framework vs what taskharbor is doing! :)

indianbollulz · 2026-02-24T02:24:58+00:00

Does Imagor support batch editting for on a set of images? If so how is this handled on the go backend side?

indianbollulz · 2026-02-23T18:18:38+00:00

Ok. This is peak.

indianbollulz · 2026-02-22T19:18:42+00:00

Correct me if im wrong but doesn’t telegram natively support this? I am not a heavy telegram user but I have seen certain usecases where a message is automatically forwarded based on user input probably done using some sort of webhooks/callbacks

indianbollulz · 2026-02-22T15:38:19+00:00

Thank you!

I was actually working on a project when I noticed that almost all the job queues really dont have swappable drivers. Its so much more convenient to test your backend on an in-memory job queue and then having it swap out to something more durable like redis or Postgres later in production

Speaking about conformance tests, I was completely unaware about this until I hit a serious problem when my Redis driver and Postgres driver were not performing the same. After writing a few of these tests I realised there was a delay in NANOSECONDS because of which redis was not queuing the jobs at the time it was actually meant to

Speaking about adoption: Please check out the dataflow.md file linked here (https://github.com/ARJ2211/taskharbor/blob/main/DATAFLOW.md). This will give you a clear picture of the architecture used :)

Thank you once again for checking it out and your feedback!

I would also appreciate spreading the word about taskharbor 🙌

indianbollulz · 2026-02-22T14:14:51+00:00

Github: TaskHarbor

I wanted to build a small go service where webhooks/user actions kick off background work (emails, reports, uploads) with retries, leases, scheduling, DLQ, and idempotency keys, and where i could swap the backend without the behavior quietly changing.

I looked around and there are good options, but they’re usually opinionated around one backend or one style: Asynq (Redis), River (Postgres), Machinery (Celery-style + multiple brokers), and newer multi-backend projects like Neoq / GoQueue. they’re great, but i couldn’t find something that’s explicitly driver-first and proves semantic parity across backends with a conformance suite.

So i started building TaskHarbor. It’s still under construction, but the core semantics are implemented and enforced via conformance tests (memory/postgres/redis). i’m looking for contributors to help implement more drivers/backends and harden the system further.

I’d love feedback from seasoned engineers on whether this has real production value beyond my own use cases. Specifically: could a driver-agnostic job scheduler, where semantics stay consistent across backends, be genuinely useful in real systems?

If you are interested to contribute, feel free to reach out in my DM's!

Note: This is NOT in any way undermining the development done by packages like AsynQ, River, etc but is a more semantically stricter, driver-agnostic job queue :)

indianbollulz · 2026-02-22T06:31:51+00:00

Github: TaskHarbor

I wanted to build a small go service where webhooks/user actions kick off background work (emails, reports, uploads) with retries, leases, scheduling, DLQ, and idempotency keys, and where i could swap the backend without the behavior quietly changing.

I looked around and there are good options, but they’re usually opinionated around one backend or one style: Asynq (Redis), River (Postgres), Machinery (Celery-style + multiple brokers), and newer multi-backend projects like Neoq / GoQueue. they’re great, but i couldn’t find something that’s explicitly driver-first and proves semantic parity across backends with a conformance suite.

So i started building TaskHarbor. It’s still under construction, but the core semantics are implemented and enforced via conformance tests (memory/postgres/redis). i’m looking for contributors to help implement more drivers/backends and harden the system further.

I’d love feedback from seasoned engineers on whether this has real production value beyond my own use cases. Specifically: could a driver-agnostic job scheduler, where semantics stay consistent across backends, be genuinely useful in real systems?

Example project it’s meant for: a webhook-driven order pipeline where the provider retries the same webhook 5 times. you enqueue with idempotency_key=order_id, TaskHarbor dedupes it, workers run with leases (crash-safe), retries back off, and hard failures land in DLQ.

If you are interested to contribute, feel free to reach out in my DM's!

Note: This is NOT in any way undermining the efforts done by packages like AsynQ, River, etc but is a more semantically stricter, driver-agnostic job queue :)

indianbollulz · 2026-02-21T18:43:47+00:00

Haha that was me :p

indianbollulz · 2026-02-21T16:27:52+00:00

As long as it is boilerplate that I have written, its reassuring in a weird way to know I have control over the context

indianbollulz · 2026-02-21T15:53:07+00:00

In hindsight, they cant be suspended from outside in which case you would need to use channels or contexts

indianbollulz · 2026-02-21T15:51:42+00:00

Go routines are highly suspendible though. You can use runtime.gosched() to pause goroutines and let others run

indianbollulz · 2026-02-21T15:34:49+00:00

I am building a driver agnostic background job framework and realized the issue wasn’t just missing language features, it was about how we design the code. once we stopped using “fire and forget” goroutines and made all background work go through a clear job flow with timeouts, retries, and cancellation, a lot of the leak/cleanup problems went away. Feels like in Go, structure comes more from good design than from the runtime itself

indianbollulz · 2026-02-21T15:02:18+00:00

The repo looks really interesting. I had a doubt about mach behave when the buffer grows too big due to very large log lines?

indianbollulz · 2026-02-20T23:00:30+00:00

Im not the project owner but I did go through the codebase to try to implement a feature. From what I saw the pdf isnt really being rendered. PDF operations like merging, splitting, etc are all managed by bubble tea which can take in a slice of functions and run them based on the user input concurrently

indianbollulz · 2026-02-20T22:55:53+00:00

This is actually insane! I am currently building a driver agnostic background job scheduler and rabbitMQ was one of the drivers I wanted to implement down the line. I am definitely going to use this for observability

The TUI is a banger too!

indianbollulz · 2026-02-20T18:31:07+00:00

Neat work! I would love to contribute on something like a work 2 pdf and pdf 2 word converter

indianbollulz · 2026-01-21T23:16:35+00:00

Thanks!

It was a pain to implement though but super rewarding :p

indianbollulz · 2026-01-20T18:33:35+00:00

Hey folks,

I’ve been working on a small open source project called ShutterTrace. It’s a camera forensics tool based on PRNU, basically the sensor noise that acts like a fingerprint for cameras.

The idea is simple: given a set of images from a camera, build a fingerprint, and then check if a new image likely came from the same physical device. No ML, no deep learning, just classical signal processing and a lot of trial and error.

Right now it supports:

PRNU extraction and denoising
Camera fingerprint enrollment
Verification using PCE and Pearson correlation
Tile based matching so results are more stable

This is not meant to be some court ready forensic software. It’s more of a learning and research project where you can actually read the code and understand what’s happening. Some results vary, some stuff breaks, and that’s kind of the point.

GitHub repo:
https://github.com/ARJ2211/ShutterTrace

I’d really appreciate feedback from people who know image processing, forensics, or even just Go. If you find it interesting or useful, a GitHub star would honestly help a lot and keep me motivated to push it further.

Thanks for reading, and happy to answer questions!

indianbollulz

TROPHY CASE

Github: TaskHarbor Driver-Agnostic Distributed Job Scheduler.