DEV Community: Biki Kc

RepoTrace — Make failing commands repeatable, inspectable, and testable

Biki Kc — Mon, 19 Oct 2026 03:47:07 +0000

Why it matters
When a command fails in your project or CI, “it failed” is rarely enough to act on. RepoTrace saves the exact argv, exit code, stdout/stderr, working directory, and interpreter metadata so a failure becomes a replayable artifact — a single-file, JSON bug report that you can rerun, render as Markdown, or convert into a standalone pytest regression test. That preserves the signal of the original failure and turns debugging into a repeatable, auditable process.

What RepoTrace is
RepoTrace is a small Python CLI and library (Python 3.12+) that captures command runs and produces:

Structured bug reports persisted as JSON files under a report store (.repotrace/reports by default).
Replay functionality to re-run recorded commands and compare results to the original trace.
Markdown rendering for human-friendly reports.
Generation of self-contained pytest regression tests that embed the command and expected output.

Core benefits

Reproducibility: replay a failure later (or on another machine) to confirm whether it still reproduces.
Traceability: keep a single-file record suitable for committing alongside a codebase or attaching to an issue.
CI friendliness: use capture/replay in pipelines to collect failing commands automatically and assert regressions as tests.
Fast triage: readable Markdown and tests remove context-switching and guesswork from debugging.

Quick highlights

Language: Python 3.12+
CLI: repotrace (Typer-based)
Notable libraries: Pydantic v2 (structured models), Rich (console output), Typer (CLI)
License: MIT

Why teams should try RepoTrace

Speed up debugging: capturing everything about a failing command means no more “works on my machine” guessing.
Create durable artifacts: JSON reports are easy to inspect, diff, and commit; generated tests are ready to land in CI.
Reduce friction between triage and fix: a report plus a generated test gives a precise spec of the problem that a reviewer or teammate can reproduce **locally.

Installation & Resources

ReproTrace is distributed under the MIT license and can be installed using standard Python package managers:

PyPI: https://pypi.org/project/repotrace/

GitHub Repository: https://github.com/BiTech5/repotrace

Join the Journey
Join RepoTrace — short invite RepoTrace turns failing commands into replayable bug reports and ready-to-commit regression tests — help make debugging reproducible.

Quick start

Fork & clone https://github.com/BiTech5/repotrace
uv sync && source .venv/bin/activate
Run a focused test: .venv/bin/python -m pytest tests/test_replay.py -q

Good first contributions

Fix small bugs, improve README examples, add edge-case tests, or generate CI/usage walkthroughs.

Conclusion / Call to action

RepoTrace reduces the time and friction of turning an observed failure into a replayable, testable artifact. If your team spends time reproducing flaky or intermittent failures, trying RepoTrace on a representative failing command (or a CI job) can immediately pay dividends: you get a concrete, versionable report and the option to convert it into a regression test that prevents regressions from returning.

Would you like a short blog-ready version of this article (250–400 words), or a ready-made example demonstrating capture → generate → commit for a small sample project?

🎨 DiagramAi: AI-Powered System Diagrams Made Simple

Biki Kc — Wed, 15 Jul 2026 00:56:18 +0000

Creating diagrams is a crucial part of software design and documentation. Whether it’s explaining workflows, modeling systems, or teaching concepts, visuals make ideas easier to grasp. But drawing them manually can be tedious.

That’s why I built DiagramAi — a web app that generates system diagrams using AI.

✨ What DiagramAi Offers
Right now, DiagramAi focuses on core system diagram types that developers and architects use most often:

🔄 Sequence Diagram – Show interactions step by step

🎭 Use Case Diagram – Capture user-system relationships

🧩 Component Architecture Diagram – Visualize modular system design

📚 Class Diagram – Model object-oriented structures

🏃 Activity Diagram – Represent workflows and processes

🔀 State Machine Diagram – Map out states and transitions

Simply describe what you want, and DiagramAi generates a clean diagram for you.

🚀 Why I Built It
I wanted a tool that could bridge natural language and visual representation. Instead of dragging shapes around, you just type:

“Create a sequence diagram for user login with authentication service and database.”

And you’ll instantly get a diagram you can tweak, export, and share.

🔒 About the Source Code
For now, DiagramAii is not open source. I’m keeping the code private while I refine the features and explore future directions. But the app is live and free to use.

🌍 Use Cases
System Design: Quickly sketch architectures during team discussions.

Documentation: Add visuals to README files or wikis.

Education: Help students understand workflows and system behavior.

Brainstorming: Turn rough ideas into structured diagrams instantly.

🎯 Try It Yourself
👉 https://diagramaii.vercel.app/

It’s lightweight, intuitive, and designed to make diagramming effortless for developers.

💡 I’d love to hear from the Dev.to community: Which diagram types should I add next? Should I expand into ER diagrams, network diagrams, or even mind maps?

Windows for Students, Linux for Developers — My Unexpected Dilemma

Biki Kc — Fri, 26 Jun 2026 15:12:42 +0000

I recently bought a new laptop, and for the first time in years, I decided to stick with the pre-installed Windows 11 instead of immediately installing Arch Linux.

As someone who has spent years daily driving Arch, that felt strange.

But there was a good reason.

Why I Stayed on Windows

I'm a college student, and Windows comes with something that Linux still struggles to replace perfectly for my workflow: Microsoft Office.

PowerPoint, Word, and Excel just work.

Yes, LibreOffice is good, and Google Docs exists, but when professors expect .pptx files with perfect formatting or group projects revolve around Office, having the native applications is genuinely convenient.

For my academic life, Windows has been surprisingly comfortable.

I honestly have no complaints there.

Then I Started Developing Again...

That's when reality hit.

I joined an open-source project that required services like Redis and Supabase.

On Arch Linux, I probably would have installed everything in a few minutes.

sudo pacman -S redis

Done.

Need Docker?

sudo pacman -S docker

Need PostgreSQL?

sudo pacman -S postgresql

Everything lives in one package manager. Life is simple.

On Windows, it became a completely different story.

Some tools require installers.

Some recommend Docker.

Others simply tell you:

"Use WSL."

At first I thought, "Okay, maybe that's fine."

But after setting it up, I couldn't stop asking myself...

If I'm using Linux inside Windows just to develop... why am I using Windows in the first place?

WSL Isn't Bad

Before anyone gets offended, I don't think WSL is a bad technology.

It's actually impressive.

Running a real Linux environment inside Windows is a huge achievement.

The problem isn't WSL itself.

The problem is that many modern development tools assume Linux as the default environment.

Instead of Windows becoming a better Unix-like development platform, the recommendation is often:

"Just install Linux inside Windows."

As someone who already knows Linux, that feels a little ironic.

The Things I Miss from Arch

After spending years on Arch Linux, you start appreciating the little things.

One package manager for almost everything.
Consistent CLI-first workflows.
Native Docker experience.
Easier setup for databases and backend tools.
Development environments that closely match production Linux servers.

More importantly...

The terminal feels like home.

But Windows Isn't All Bad

To be fair, Windows has improved a lot.

Better hardware support.
Great battery life on many laptops.
Excellent Office applications.
Better compatibility with university software.
WSL for developers who need Linux tools.

For many people, it's probably the best balance.

I just haven't fully adapted after years of Linux.

So... Should I Switch Back?

That's the question I've been asking myself.

Should I:

Keep Windows and use WSL for development?
Dual boot Windows and Arch Linux?
Install Arch as the primary OS and run Windows only when I need Office?
Or just accept that WSL is now part of modern Windows development?

I'm genuinely curious what other developers think.

Especially those who have switched between Linux and Windows multiple times.

How do you balance productivity for work or college with a development environment that feels natural?

I'd love to hear your experience.