DEV Community: Naman Vashistha

Gardening and the Pace of Things as an Engineer

Naman Vashistha — Tue, 17 Feb 2026 08:00:40 +0000

I am a software engineer, so most of my day is in front of a screen. Things respond quickly there. Code compiles or it doesn’t, a message gets a reply, something either works or it breaks. I got used to that without really noticing I had.

I had always liked the idea of gardening, just never done it. At some point the time and situation felt right and I started. Also wanted to do something that had nothing to do with screens or electronics. Soil, water, sunlight. That was the appeal.

I water a plant and walk away not knowing if it did anything. The soil looks the same the next morning, the leaves don’t visibly change, and if something is happening it’s somewhere I can’t see. Weeks went by where I couldn’t really tell if I was helping or just showing up.

Then one morning a leaf had an odd color, slightly yellow at the edges and curling inward. I took a photo and sent it to ChatGPT out of curiosity. It gave me a confident answer. I read it, tried to understand what the plant might need, and moved on. Somewhere along the way I realized I had started paying more attention to the plant itself rather than looking for someone to tell me what was wrong with it.

The basics turned out to be most of it. Good soil, mostly. Something to hold moisture, something to let it drain, something to feed the roots. Soil, cocopeat & compost. The balance matters more than the ingredients. And water only when the soil asks for it, not before.

One plant died and I still don’t know why. By the time something was clearly wrong it was already too late. There was no obvious moment I could point to.

The others came up slowly. Quietly, in their own order, at their own pace. It was nice to watch.

Some plants have looked exactly the same for weeks now. Same height, same leaves, no visible change. I notice it, but it doesn’t pull at me the way it used to. I water, I check the soil, I watch. Most mornings that’s enough.

Automating LimeDB LXC Container Deployment on Proxmox

Naman Vashistha — Fri, 21 Nov 2025 17:08:29 +0000

Github: namanvashistha/limedb

This commit introduces a new bash script, proxmox/limedb_lxc.sh, designed to automate the provisioning and setup of a LimeDB instance within an LXC container on a Proxmox VE host.

What Changed

A new executable bash script (limedb_lxc.sh) has been added to the repository's proxmox/ directory. This script provides a single-command solution for deploying a fully functional LimeDB server in a containerized environment on Proxmox.

Why the Change Was Needed

Deploying a distributed key-value store like LimeDB often involves repetitive setup steps, especially when provisioning multiple instances for a cluster or for development/testing environments. Manually creating LXC containers, configuring their resources, installing dependencies, downloading and setting up LimeDB, and configuring its systemd service can be time-consuming and prone to human error. This script aims to reduce operational overhead, ensure consistency across deployments, and lower the barrier for users to quickly get LimeDB running on Proxmox.

Design Choices Made

Proxmox pct Utility: The script heavily relies on the pct command-line interface provided by Proxmox for all container management operations, including creation, starting, and executing commands within the container.
Unprivileged LXC: It creates an unprivileged container by default (--unprivileged 1), which is a security best practice as it isolates the container processes more effectively from the host kernel.
Debian 12 Base: A Debian 12 standard template (debian-12-standard_12.2-1_amd64.tar.zst) is chosen as the default operating system for the container, offering a stable and widely-used base.
Resource Configuration: Default parameters for CPU cores (1), RAM (512MB), swap (512MB), and disk size (2GB) are set, providing a lightweight yet functional setup suitable for initial deployments or development.
DHCP Networking: The container's network is configured to use DHCP on vmbr0, simplifying network setup in most standard Proxmox environments.
Nesting Support: The --features nesting=1 flag is included, which can be beneficial for running certain nested virtualization or containerization technologies within the LXC, though not strictly required for LimeDB itself.
Binary Installation: LimeDB is installed by directly downloading a pre-compiled binary from its GitHub releases (v0.0.2) into /usr/local/bin inside the container. This avoids the need for a full build environment within the LXC.
Systemd Service Management: A systemd unit file (limedb.service) is dynamically created and enabled within the container. This ensures LimeDB starts automatically on boot and is managed robustly by the system's init system.
Basic Error Handling and Feedback: The script includes functions for informative messages, success indicators, and error reporting, with checks for root execution and successful container creation.

Trade-offs and Constraints

Proxmox-Specific: The script is tightly coupled to the Proxmox VE environment and cannot be used for deploying LimeDB on other virtualization platforms without significant modifications.
Default Parameters: It uses hardcoded default values for container ID (105), password, storage pool (local-lvm), and OS template. Users need to ensure these defaults are appropriate for their specific Proxmox setup or modify the script variables directly.
Root Privileges: The script itself must be run as root on the Proxmox host. Commands executed within the container (e.g., apt-get, wget, systemctl) are also run as the root user.
Network Assumptions: It assumes the presence of a network bridge named vmbr0 and a DHCP server on that network. Static IP configuration is not an option within the current script implementation.
External Dependency: The LimeDB binary is fetched directly from GitHub releases. This implies a dependency on GitHub's availability and the persistence of the specific release version.
Limited Customization: While essential parameters are configured, more advanced LXC settings (e.g., CPU limits, IOPS limits, specific static IP addresses, custom bind mounts) are not exposed for easy modification.
Security Post-Setup: The use of a default container password and root installation inside the container means that for production deployments, additional security hardening (e.g., changing passwords, creating dedicated unprivileged users for LimeDB) would be necessary.

Future Implications

This script serves as a foundational automation tool for LimeDB on Proxmox. It significantly simplifies the initial deployment phase, making it easier for users to experiment with, test, and potentially scale LimeDB instances. Future enhancements could include making more parameters configurable via command-line arguments, supporting different OS templates, enabling static IP configuration, or integrating with configuration management systems for more advanced fleet management.

LimeDB: Architectural Shift to a Go-based Distributed Key-Value Store with Consistent Hashing

Naman Vashistha — Fri, 21 Nov 2025 15:18:21 +0000

Github: namanvashistha/limedb

This commit marks a pivotal architectural change for LimeDB, transitioning its core distributed key-value store implementation from a Java/Spring Boot foundation managed by Docker Compose to a new Go-based system. This complete rewrite focuses on performance, efficiency, and a streamlined deployment model.

What Changed

TheThe primary change is the introduction of a complete Go implementation of LimeDB's distributed key-value store. This necessitated the removal of all previous Java-related Docker infrastructure, including .dockerignore, DOCKER.md, docker-compose.yml, and docker-compose.prod.yml. A .gitignore update also reflects a new development environment preference.

The new Go codebase introduces several key components:

cmd/server/main.go: The application's entry point, responsible for loading configuration, initializing services, starting the HTTP server, and managing graceful shutdown.
internal/config: A package for parsing command-line arguments to configure node-specific parameters such as NodeID, ServerPort, a list of Peers, and the number of VirtualNodes.
internal/server: Implements the HTTP server using github.com/valyala/fasthttp. It defines API endpoints for GET, SET, DELETE operations, as well as cluster and ring state monitoring (/api/v1/cluster/state, /api/v1/cluster/ring).
internal/node: Contains the NodeService which orchestrates key-value operations. It manages an in-memory Store (based on sync.Map) for local data and routes requests to the appropriate node using consistent hashing, forwarding them via an fasthttp.Client if the key belongs to a remote peer.
internal/ring: This package provides the ConsistentHashRing implementation, which uses MD5 hashing to map keys to int64 values on the ring. It supports adding and removing physical nodes, each represented by a configurable number of virtual nodes, and efficiently determines the responsible node for a given key.
go.mod and go.sum: These files define the Go module limedb-go and its dependencies, primarily fasthttp.
run_go_cluster.sh: A shell script facilitating the local setup and execution of a multi-node Go LimeDB cluster, automatically generating the peer list.
scripts/bulk_set.py: The Python testing script was updated to support a higher number of nodes (up to 50) and increased concurrent key operations, reflecting the expected scalability improvements of the Go implementation.

Why the Change was Needed

The transition from Java/Spring Boot to Go was driven by the pursuit of higher performance, reduced resource consumption, and improved concurrency characteristics. Go's design, with its lightweight goroutines and efficient memory management, offers significant advantages for building high-throughput distributed systems like LimeDB. The aim is to achieve lower latency and higher request per second (RPS) metrics compared to the previous Java-based setup, while also simplifying the deployment footprint by moving to a single-binary model.

Design Choices Made

Go Language Adoption: The primary decision was to rewrite the system in Go. This choice aligns with the project's goal of being a lightweight, fast, open-source distributed key-value store for high-performance systems. Go's built-in concurrency model and performance profile are well-suited for this.
fasthttp for HTTP Communication: github.com/valyala/fasthttp was selected over Go's standard net/http package for its optimized performance. In a key-value store where network I/O and request handling throughput are critical, fasthttp provides a more performant foundation for inter-node communication and client APIs.
Consistent Hashing with Virtual Nodes: The ConsistentHashRing implementation is central to the distributed nature of LimeDB. By employing consistent hashing and distributing virtual nodes across physical nodes, the system achieves even data distribution, minimizes data movement during node additions/removals, and enhances fault tolerance. MD5 hashing to int64 provides a consistent mapping to the hash space.
In-Memory sync.Map Storage: For the initial phase of this rewrite, an in-memory sync.Map was chosen for local key-value storage. This provides a simple, thread-safe, and highly performant local store, allowing the development focus to remain on the distributed routing and consistent hashing logic.
Command-Line Configuration: Node configuration is managed via command-line flags. This provides a transparent and explicit way to bootstrap and configure individual nodes, particularly useful in development and for static cluster deployments.
Direct Request Forwarding: When a request targets a key not owned by the current node, the NodeService directly forwards the HTTP request to the responsible peer. This keeps the routing logic within the application layer, leveraging the consistent hash ring.

Trade-offs and Constraints

Persistence (Current Constraint): The current internal/node/store is an in-memory implementation, meaning data is not durable across restarts. This is a deliberate simplification for the initial Go rewrite phase, prioritizing the core distributed logic. For production readiness, a persistent storage layer will be required (the previous Java version used PostgreSQL, highlighting this need).
Static Peer Configuration: The node.peers list is currently static and defined at startup. This approach lacks dynamic cluster membership capabilities, meaning manual intervention is required to update peer lists when nodes join or leave the cluster. This could be a scalability bottleneck in highly elastic environments.
fasthttp Ecosystem: While fast, fasthttp has a smaller ecosystem of middleware and integrations compared to the standard net/http package. This is an accepted trade-off for the performance gains it provides in a specialized service.
Basic API Routing: The server's router uses a basic switch statement for URL matching. While functional, it could evolve into a more robust routing framework as the API surface grows.

Future Implications

This Go-based rewrite provides a strong, high-performance foundation for LimeDB. Future development efforts will likely focus on enhancing its capabilities:

Durable Storage: Implementing a persistent storage layer (e.g., integrating with a local embedded key-value store like BadgerDB or RocksDB, or a custom log-structured approach) to ensure data durability.
Replication and Consistency: Introducing robust data replication strategies (e.g., N-way replication, quorum reads/writes) to ensure high availability and strong consistency guarantees.
Dynamic Cluster Membership and Discovery: Developing mechanisms for nodes to dynamically discover each other, join/leave the cluster, and handle failures gracefully (e.g., using a gossip protocol or integrating with a service discovery system like Consul or etcd).
Load Balancing and Client-Side Hashing: Exploring options for smarter client-side load balancing or direct client integration with the consistent hashing ring to minimize request forwarding overhead.
Advanced Observability: Expanding metrics, logging, and tracing capabilities for better monitoring and debugging in production environments.

Why I'm Building My Own Distributed Database

Naman Vashistha — Sat, 11 Oct 2025 21:09:44 +0000

As a backend developer, I've worked with Redis, PostgreSQL, MongoDB, and countless other databases. But I always felt like there was something missing – a deeper understanding of how these systems actually work under the hood. So I decided to embark on a journey to build my own distributed key-value database from scratch.

Meet LimeDB – a distributed key-value store I'm currently building with Java 21 and Spring Boot. My goal is to create a truly custom database system that starts with PostgreSQL as a foundation but evolves into something much more ambitious, all wrapped in a horizontally scalable coordinator-shard architecture.

GitHub: namanvashistha/limedb

🤔 Why Build Another Database?

You might be thinking: "Why reinvent the wheel? Redis and PostgreSQL already exist!" And you're absolutely right. But here's the thing – as backend developers, we often treat databases as black boxes. We know how to use them, but not how they work.

Building LimeDB is already teaching me more about distributed systems, consistency, partitioning, and database internals than years of just using existing solutions. It's like the difference between driving a car and understanding how the engine works.

🎯 The Learning Goals

When I started this project, I had several learning objectives:

Understand Distributed System Patterns - How do you route requests across multiple nodes?
Grasp Database Internals - What happens when you store and retrieve data?
Learn About Horizontal Scaling - How do systems like Redis Cluster actually work?
Master Modern Java - Put Java 21 features and Spring Boot to real use
Build Something Production-Adjacent - Not just a toy, but something that could theoretically scale

🏗️ Architecture Decisions

The Coordinator-Shard Pattern

Instead of a peer-to-peer system (like Cassandra) or a single-node system (like Redis), I chose a coordinator-shard architecture:

Client → Coordinator → Shard 1, 2, 3...

Why this pattern?

Simplicity: Clients only need to know about one endpoint
Routing Logic: Centralized decision-making about where data lives
Operational Ease: Easy to monitor and debug
Familiar: Similar to how many real systems work (think MongoDB's router)

Hash-Based Routing (For Now)

// Simple but effective
int shardIndex = Math.abs(key.hashCode()) % numberOfShards;

This is deliberately simple. I know consistent hashing is "better" for rebalancing, but I wanted to start with something I could fully understand and implement correctly. You can see this decision in the ShardRegistryService:

public String getShardByKey(String key) {
    int index = Math.abs(key.hashCode()) % shards.size();
    return shards.get(index);
}

Perfect? No. Educational? Absolutely.

PostgreSQL as a Starting Point

Each shard currently uses its own PostgreSQL database (limedb_shard_1, limedb_shard_2, etc.). But here's the key - PostgreSQL is just my Phase 1 storage engine, not the final destination.

Why start with PostgreSQL?

Quick Validation: Get the distributed architecture working first
ACID Guarantees: Data survives restarts while I focus on routing logic
Familiar Tooling: Easy to inspect and debug during development
Stepping Stone: Proven foundation before building custom storage

The plan is to eventually replace PostgreSQL with custom storage engines optimized for key-value workloads. Think LSM trees, custom file formats, and memory-mapped storage - but PostgreSQL lets me focus on the distributed systems challenges first.

💡 What I'm Learning Building This

1. Distributed Systems Are Hard

Even with this simple architecture, I'm already running into fascinating problems:

What happens when a shard goes down?
How do you handle network timeouts?
What about data consistency across shards?

These aren't academic questions anymore – they're real problems I need to solve as I build this system.

2. The Power of Good Abstractions

The Spring Boot framework is letting me focus on the distributed systems logic rather than HTTP parsing and dependency injection. My controllers are staying clean:

@GetMapping("/get/{key}")
public ResponseEntity<String> get(@PathVariable String key) {
    String value = routingService.get(key);
    return value != null ? ResponseEntity.ok(value) : ResponseEntity.notFound().build();
}

3. Testing Distributed Systems is Different

You can't just unit test individual methods. You need to:

Start multiple services
Test network failures
Verify data consistency
Check routing logic

def set_values():
    for i in range(1_000):
        payload = {"key": f"key_{i}", "value": f"value_{i}"}
        response = requests.post("http://localhost:8080/api/v1/set", json=payload)

4. Configuration Management is Crucial

With multiple nodes, configuration becomes complex. Each shard needs to know:

Which database to connect to
What port to run on
Its shard ID

./gradlew bootRun --args='--node.type=shard --server.port=7001 --shard.id=1'

🚀 Current Progress

LimeDB currently supports:

✅ GET/SET/DELETE operations (Redis-like API)
✅ Hash-based routing across 3 shards
✅ PostgreSQL persistence per shard
✅ REST API with proper error handling
✅ Health monitoring endpoints

Performance? It's not going to beat Redis. But it's already handling operations smoothly and teaching me why Redis is so fast.

🎯 What's Next?

The roadmap is ambitious and includes features I'm excited to tackle:

Phase 2: Better Distribution

Consistent Hashing: Replace modulo with a proper hash ring
Health Checks: Automatic failover when shards go down
Replication: Primary-replica setup for high availability
Metrics: Monitoring and observability

Phase 3: Custom Storage Engine

LSM Trees: Replace PostgreSQL with custom key-value storage
Memory-Mapped Files: Direct file system control
Custom Serialization: Optimized data formats
WAL Implementation: Write-ahead logging from scratch

Phase 4: Advanced Features

Custom Binary Protocol: Move beyond HTTP/REST
Compression: Custom compression algorithms
Cache Layers: Multi-level caching strategies
Transaction Support: ACID across multiple shards

Each phase represents deeper database internals knowledge - PostgreSQL is just the beginning!

💭 Why You Should Build One Too

Building your own database isn't about competing with PostgreSQL or Redis. It's about:

Deep Learning: Understanding systems from the ground up
Interview Prep: Nothing impresses like saying "I built a distributed database"
Problem-Solving Skills: Real distributed systems problems
Technology Mastery: Push your programming language skills
Portfolio Project: Something unique that stands out

🛠️ Getting Started

If this inspired you to build your own database, here's my advice:

Start Simple: Don't try to build Redis on day one
Pick Your Language: Use something you're comfortable with
Choose One Feature: GET/SET is enough to start
Add Gradually: Persistence, then distribution, then optimizations
Document Everything: Future you will thank you

🔗 Follow the Journey

Want to see the code as I build it? It's all open source:

GitHub: namanvashistha/limedb
Tech Stack: Java 21, Spring Boot, PostgreSQL
Current Status: Basic coordinator-shard architecture working

The README has setup instructions, and I'm trying to make the code as readable as possible for learning purposes. Feel free to star the repo and follow along as I tackle more distributed systems challenges!

🎉 Final Thoughts

Building LimeDB is turning out to be one of the most educational projects I've undertaken as a backend developer. It's not going to be the fastest database, or the most feature-complete, but it's mine. I understand every line of code, every architectural decision, and every trade-off I'm making along the way.

In a world of microservices and cloud abstractions, there's something deeply satisfying about building a system from first principles. I'm already looking at Redis, PostgreSQL, and MongoDB differently after just starting this journey.

So grab your favourite programming language, pick a simple data structure, and start building. The distributed systems knowledge you'll gain is worth its weight in gold.

What do you think? Have you ever built your own database or distributed system? What did you learn? Drop a comment below!

What No One Tells You About Being a Mid-Level Developer

Naman Vashistha — Tue, 22 Apr 2025 21:42:04 +0000

Let’s talk about what it actually feels like to be a mid-level dev—the quiet confusion, the shifting expectations, and the slow realization that growth isn’t always about writing better code.

1. You’re not a beginner anymore—but you still feel like one sometimes

You know how to ship features. You’ve debugged scary bugs. You’ve even explained things to newer devs and realized, “Wait, I do know this!”

But then, you’ll get thrown into something new—some legacy codebase, some architectural decision—and you’ll freeze. That little voice comes back: “Shouldn’t I already know this by now?”

You’re not alone. Mid-level is where imposter syndrome doesn’t vanish—it just mutates.

2. People start expecting more, but don’t always tell you what that is

You’re suddenly in charge of things like “code quality,” “project ownership,” and sometimes even “mentoring.” But no one tells you what those things actually look like day-to-day.

You find yourself in meetings, nodding along, Googling acronyms under the table. Half the skill lies in confidently navigating new challenges as you figure things out on the fly.

3. You have more influence than you think

You might not be leading teams, but your suggestions matter. Your pull requests shape patterns. Your way of solving problems gets copied.

And when a junior dev asks you for help, you suddenly see how much you've learned. That moment when you explain a concept and they go “Ohh!”—yeah, that’s a quiet promotion right there.

4. You start realizing that growth isn’t just about code

It’s about communication. It’s about trade-offs. It’s about choosing boring solutions when they’re the right ones.

It’s learning when to speak up in a design review—and when to just listen. It’s understanding the business impact of your work, not just its technical elegance.

The things that don’t go in your resume? They matter a lot more now.

5. It’s okay to not feel “ready” yet

Here’s the truth: no one fully knows what they’re doing. The difference at this level is that you’re getting better at handling uncertainty. Better at asking for clarity. Better at shipping anyway.

Being mid-level isn’t a stop on the way to senior. It’s a whole stage of its own—messy, confusing, but also really rewarding.

And if you’re here? You’re doing just fine.

Imposter Syndrome in Software Engineering – You're Not Alone

Naman Vashistha — Tue, 22 Apr 2025 21:10:32 +0000

I remember staring at my screen after deploying a bug fix, thinking, "Someone’s going to find out I have no idea what I’m doing." It didn’t matter that I’d been writing production code for years. That little voice—the one that says you’re not good enough—never really goes away.

Imposter syndrome is weird like that. It doesn’t care about your experience, your contributions, or your title. It creeps in when you're debugging a weird issue, sitting in a meeting with sharp teammates, or reading code that just seems way too elegant for you to have written.

What We'll Talk About:

What imposter syndrome feels like in our field
Why it's especially common among developers
Some mindset shifts and coping strategies that actually helped

Why This Matters

You’re not broken. You’re not alone. And most importantly, you don’t need to "fix" yourself to belong here.

Let’s start with the obvious: this job is hard. Not just technically, but emotionally.

You're expected to learn constantly, work with code that was written in a rush (also by you), and make decisions with incomplete information. And when things break—because they will break—you feel like the world is watching. Even if it’s just you.

And the weirdest part? Nobody talks about it enough.

What Imposter Syndrome Feels Like in Our Field

Imposter syndrome for developers often isn’t loud. It’s quiet. It whispers things like:

“You don’t actually understand this pattern, you just copied it from ChatGPT/StackOverflow.”
“They think you’re good because you got lucky with that last project.”
“You should know this by now. Why don’t you?”

It can hit during a code review, or while pairing with someone who types faster than you think. And worst of all—it often hits after success. After a promotion. After a session. As if your wins are just accidents.

Why It's So Common Among Developers

A few reasons, at least in my experience:

Software moves fast. There’s always a new framework, a new best practice, or some new tech everyone suddenly knows but you haven’t touched yet. It feels like running a race where the finish line keeps moving.
We normalize struggle... in private. Everyone’s debugging in silence, but we only see the wins. We don’t see how long it took someone to write that “clean” code.
We compare the worst of ourselves to the best of others. You see someone’s elegant GitHub project and think “I could never build that,” while ignoring the 40 tabs you have open just to write one function.
There’s a myth of the “10x engineer.” And if you're not pushing PRs, writing blog posts, building side projects, and contributing to open source, it’s easy to feel like you're falling behind. (Spoiler: you're not.)

Mindset Shifts That Helped Me

I’m someone who deals with this regularly. But I’ve found a few things that make those voices a little quieter:

Track what you’ve learned. Sometimes I just remind myself of small wins—like finally figuring out why a bug happened or learning a new Git command. It doesn’t have to be a big deal. Even remembering those little moments helps me see that I’m making progress.
Ask questions—even when it’s scary. I used to think asking made me look dumb. Now I realize it shows I'm invested and curious. And more often than not, the senior dev I was afraid to ask says, “Oh, good question.”
Surround yourself with honest devs. People who admit when they’re stuck. People who say “I don’t know” without shame. That’s the culture I want to be part of—and it makes a huge difference.
Stop aiming for perfect. Aim for progress. Perfectionism and imposter syndrome are best friends. So now, I try to focus on moving forward—even if it’s a little messy.

You’re Not Broken

If you’ve ever felt like you don’t fully belong, that doesn’t make you weak. It makes you human.

Confidence in tech isn’t a permanent state—it’s something you rebuild, over and over. And every time you push through, ask that question, commit that code, or help someone else, you're proving something to yourself:

You belong here.

Not because you're perfect. Not because you've mastered every language, every paradigm, or every tool.

You belong because you're learning. Because you care. And because you're showing up—even on the hard days.

If you’re reading this and nodding along, leave a comment or share your story. You’re not alone—and your experience might be exactly what someone else needs to hear.

Building a Fast and Smart Chess Engine Using Bitboards

Naman Vashistha — Tue, 22 Apr 2025 08:51:58 +0000

Repository: https://github.com/namanvashistha/chess

When you sit down to play chess online, there’s a brain on the server side that checks whether your moves are legal, prevents cheating, and enforces the rules of the game. That brain is the chess engine.

In this post, we’ll walk through how a chess engine is implemented under the hood—specifically one written in Go, backed by the blazing speed of bitboards. Whether you’re building your own chess app or just curious about how engines work, this post dives into the guts of what makes the game tick.

♟️ What Is the Engine Responsible For?

At its core, the engine is the rulebook of chess in code form. It needs to:

Understand how each piece moves
Enforce all special rules (castling, en passant, promotion)
Reject illegal moves
Detect checks, pins, checkmates, and stalemates

It’s not responsible for persistence (that’s the repository's job), nor for coordinating services (handled by the service layer). The engine lives in its own pure Go package—no external dependencies, just logic.

✅ What Happens When You Play a Move?

Let’s say it’s the first move of the game, and White tries e2 to e4. Here’s what the engine does to validate this move:

Check the source square (e2):
- Is there a White Pawn on it?
Check the target square (e4):
- Is it empty?
Pawn-specific rules:
- Is this the pawn’s first move? If so, can it move 2 squares?
King safety:
- After making this move hypothetically, does it leave the King in check?

The engine doesn’t just guess. It checks all these conditions explicitly and systematically.

⚡ Enter Bitboards: The Secret Weapon

We want our engine to be fast—like “respond in milliseconds” fast. That’s where bitboards come in.

A bitboard is a 64-bit unsigned integer (uint64). Each bit corresponds to one square on the chess board. A 1 means something is true about that square. For example:

Bitboard of White Pawns: 1s where pawns are
Bitboard of all occupied squares: 1s wherever any piece is present

Imagine the board as this:

8 | 0 0 0 0 0 0 0 0
7 | 0 0 0 0 0 0 0 0
6 | 0 0 0 0 0 0 0 0
5 | 0 0 0 0 0 0 0 0
4 | 0 0 0 0 0 0 0 0
3 | 0 0 0 0 0 0 0 0
2 | 1 1 1 1 1 1 1 1  ← White Pawns
1 | 0 0 0 0 0 0 0 0
    a b c d e f g h

This is represented in Go as:

var whitePawns uint64 = 0x000000000000FF00

With bitboards, you can:

Get all pawns with a single value
Find empty squares: ^occupiedSquares
Calculate legal pawn moves with shifts like whitePawns << 8

Bitwise operations (AND, OR, SHIFT) are insanely fast—no loops required.

👨‍💻 Example: Generating Pawn Moves

Here's how you'd generate single-step pawn moves using bitboards in Go:

singleMoves := (whitePawns << 8) & ^occupiedSquares

Want to allow double moves from the 2nd rank?

doubleMoves := ((whitePawns & rank2Mask) << 16) & ^occupiedSquares

Add attack logic (diagonal captures), en passant rules, and you're already halfway to a serious chess engine.

🔒 Validating King Safety

One of the trickiest parts is ensuring that a move doesn’t leave your king in check. Here's the approach:

Make the move virtually (don’t modify real board yet).
Recalculate all opponent attack bitboards.
If the king is under attack, reject the move.

This way, the engine enforces all safety rules without relying on the game state from external services.

📦 Engine Is a Pure Go Package

By keeping the engine as a pure Go package:

It’s portable and testable
There are no dependencies on HTTP, database, or external services
All the logic lives in memory and runs lightning-fast

You can plug this engine into your service layer or even into a CLI-based chess app or bot.

🧪 Testing the Engine

Unit tests are critical. Since the engine doesn’t rely on any infrastructure, it’s easy to write tests like:

assert.True(t, engine.IsMoveLegal("e2", "e4", whiteBoard))
assert.False(t, engine.IsMoveLegal("e2", "e5", whiteBoard))

You can simulate full games, generate perft (performance test) numbers, and validate against known legal positions.

🏁 What's Next?

Now that the engine can validate moves and generate legal positions, you can layer on:

Move scoring and search (for an AI opponent)
Threefold repetition detection
Draws by insufficient material

But even without AI, a robust engine ensures fair, rule-compliant play—which is essential for multiplayer games, tournaments, or bots.

✨ TL;DR

The Engine is the brain that validates chess rules.
It uses bitboards (64-bit integers) to represent the board and calculate legal moves ultra-fast.
All logic is implemented in a pure Go package—clean, testable, and fast.
Bitboards let you write elegant, blazing-fast chess logic without messy loops or nested conditionals.

If you're building a chess app or just love systems programming, bitboards are one of the most satisfying tricks in the book.

Repository: https://github.com/namanvashistha/chess

Create Stunning Images from Text with a Telegram Bot 🚀

Naman Vashistha — Wed, 22 Jan 2025 14:59:39 +0000

In today’s fast-paced digital world, creating engaging content is a top priority for individuals and businesses alike. Imagine being able to generate aesthetically pleasing images from text messages, complete with hashtags and custom watermarks, right from Telegram. Let me introduce you to a Telegram bot that makes this a breeze!

In this article, I’ll walk you through how this bot works, its use cases, and how you can set it up in just a few steps.

What Does This Bot Do? 🤔

This bot takes text input from Telegram users and generates visually appealing images with:

Rich text formatting
Custom hashtags
Watermarks (like your brand or username)

The generated images can be saved locally or shared instantly, perfect for:

Social media posts
Content creation workflows
Personal branding
Campaign visuals

How It Works 💡

Text Parsing:

The bot parses the input text and separates hashtags automatically.
Image Generation:

Using Python’s Pillow library, the bot creates a clean, responsive design with:
- A consistent color scheme
- Wrapped text for proper alignment
- Brand watermark
Telegram Integration:

The bot uses the python-telegram-bot library to handle messages and respond with images dynamically.
Custom Fonts and Styling:

With easily configurable fonts and colors, the output matches your brand aesthetics.

Setting It Up 🛠️

Follow these simple steps to set up the bot:

Clone the Repository

   git clone https://github.com/namanvashistha/text-to-image-bot.git
   cd text-to-image-bot

Install Dependencies Create a virtual environment and install the required Python libraries:

   pip install -r requirements.txt

Configure Environment Variables Create a .env file in the root directory with the following:

   TELEGRAM_BOT_TOKEN=your_telegram_bot_token
   IMAGE_WATERMARK=your_watermark_text

Start the Bot Run the script to launch your bot:

   python bot.py

Demo of the Bot 🎉

Here’s a quick example of what this bot can do:

Input: Simple is better than complex. #Python #ZenOfPython
Output:

Use Cases 🌟

Content Creators: Generate Instagram-worthy posts or tweets instantly.
Marketing Teams: Quickly create branded images for campaigns.
Developers: Extend the bot’s functionality to integrate with other platforms like Slack or WhatsApp.
Educators: Create visually engaging slides or educational content.

Repository 🧑‍💻

Check out the full source code and contribute to the project on GitHub:

GitHub Repository: Text-to-Image Bot

What’s Next? 🤔

How would you improve this bot for your own use cases? Share your thoughts in the comments or feel free to open an issue or pull request on GitHub.

Automated Job Search: LinkedIn Jobs to Notion Board

Naman Vashistha — Wed, 22 Jan 2025 14:13:24 +0000

A Python-based job scraping system that pulls LinkedIn listings into a structured Notion database. Repository: jobs-scrape-to-notion

Setup Steps

Clone the repository:

git clone https://github.com/namanvashistha/jobs-scrape-to-notion
cd jobs-scrape-to-notion

Install dependencies:

pip install -r requirements.txt

Configure Notion:
- Create a Notion integration at notion.so/my-integrations
- Create a new Notion database
- Share your database with the integration
- Copy the database ID from its URL
Set environment variables:

cp .env.example .env

Update .env with your credentials:

NOTION_API_KEY=your_integration_token
NOTION_DATABASE_ID=your_database_id

Key Features

Job Scraping

def fetch_jobs(search_terms, location, results_wanted=20):
    # Scrapes LinkedIn jobs based on multiple search terms
    # Returns a pandas DataFrame with job details

Notion Integration

Creates structured database entries
Handles rich text, URLs, dates, and company logos
Prevents duplicate entries
Manages API rate limits

Data Processing

Sanitizes input data
Formats salary ranges for Indian currency
Handles company metadata
Manages file attachments for logos

Running the Scraper

python main.py

Default configuration:

Search terms: ["Software Engineer", "Backend", "SDE"]
Location: India
Results per term: 20
Platform: LinkedIn

Customization

Modify main() in scraper.py:

search_terms = ["Your", "Preferred", "Terms"]
location = "Your Location"
results_wanted = 30  # Number of results per term

Error Handling

The system includes:

Comprehensive logging
Rate limit management
Duplicate prevention
Data validation

Visit the repository for source code and detailed documentation.

Automating Python Code Linting with GitHub Actions

Naman Vashistha — Tue, 21 Jan 2025 17:59:57 +0000

Linting your Python code is crucial to maintaining code quality and consistency across your projects. GitHub Actions provides a powerful way to automate linting processes, ensuring that all code changes meet coding standards before being merged into your repository.

In this article, we will explore how to set up a GitHub Action to lint Python code automatically whenever a pull request is created.

Prerequisites

To follow along, ensure you have the following:

A GitHub repository containing Python code.
Basic knowledge of GitHub Actions and workflows.

Setting Up the GitHub Action Workflow

Below is a GitHub Actions workflow configuration that automatically lints Python code in pull requests.

name: Lint Python Code

on:
  pull_request:
    paths:
      - '**/*.py'  # Trigger workflow only when Python files change

jobs:
  lint:
    name: Lint Code
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v2

      - name: Get changed Python files
        id: get_changed_files
        uses: tj-actions/changed-files@v35
        with:
          files: '**/*.py'

      - name: Run pylint
        if: steps.get_changed_files.outputs.any_changed == 'true'
        uses: dciborow/action-pylint@0.1.0
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          reporter: github-pr-review
          glob_pattern: ${{ steps.get_changed_files.outputs.all_changed_files }}
          level: warning
          filter_mode: added
          fail_on_error: true

Explanation of the Workflow

Triggering the workflow:
- The workflow runs on pull_request events.
- It is triggered only if changes include Python files ('**/*.py').
Steps in the job:
- Checkout code: Retrieves the repository code.
- Identify changed Python files: Uses tj-actions/changed-files to detect which Python files were modified.
- Run pylint:
  - The dciborow/action-pylint GitHub Action runs pylint on the changed files.
  - It reports warnings directly on the pull request.
  - The workflow fails if pylint finds any errors.

Customization Options

You can customize the workflow based on your needs:

Modify the pylint_args to include or exclude specific checks.
Change the fail_on_error value to false if you want warnings but don't want to block merges.
Use a different pylint reporter such as github-checks instead of github-pr-review.

Viewing Linting Results

Once the pull request is created, the pylint report will appear as a review comment on the PR, helping developers identify and fix issues efficiently.

Conclusion

By automating Python code linting with GitHub Actions, you ensure that your codebase remains clean and adheres to coding standards, reducing technical debt and improving maintainability. Try integrating this workflow into your projects today!

Building a Modern Chess Engine: A Deep Dive into Bitboard-Based Move Generation

Naman Vashistha — Tue, 21 Jan 2025 17:44:01 +0000

Repository: https://github.com/namanvashistha/chess

Chess engines have long fascinated programmers and chess enthusiasts alike. In this article, I'll walk you through the implementation of a chess engine focusing on efficient move generation using bitboards. We'll explore how bitboards work, why they're crucial for performance, and how to implement various piece movements.

What are Bitboards?

Bitboards are a fundamental data structure in modern chess programming. At its core, a bitboard is a 64-bit integer where each bit represents a square on the chess board. This representation allows us to use efficient bitwise operations to manipulate the board state and generate moves.

In our implementation, we use multiple bitboards to represent different aspects of the game:

type GameState struct {
    WhiteBitboard  uint64
    BlackBitboard  uint64
    PawnBitboard   uint64
    KnightBitboard uint64
    BishopBitboard uint64
    RookBitboard   uint64
    QueenBitboard  uint64
    KingBitboard   uint64
    // ... other state information
}

Move Generation Architecture

The move generation system follows a two-step process:

Generate pseudo-legal moves
Filter out illegal moves that would leave the king in check

Step 1: Pseudo-Legal Move Generation

Let's look at how we generate moves for different pieces:

Pawn Move Generation

Pawns have the most complex movement rules in chess. Here's how we handle them:

func generatePawnMoves(gs dao.GameState, pseudo_legal_moves map[uint64]uint64, legal_moves map[uint64]uint64) {
    // Single and double pushes
    singleMove := piece << 8
    doubleMove := piece << 16

    // Diagonal captures and en passant
    diagonalLeft := (piece &^ 0x0101010101010101) << 7
    diagonalRight := (piece &^ 0x8080808080808080) << 9
}

The implementation handles:

Single and double forward moves
Diagonal captures
En passant captures
Promotion (handled in move execution)

Sliding Piece Movement

For bishops, rooks, and queens, we use ray-tracing to find legal moves:

func removeBlockedMoves(piece uint64, moves uint64, allOccupied uint64, rayDirections []int) uint64 {
    blockedMoves := uint64(0)
    for _, direction := range rayDirections {
        blockedMoves |= traceRay(piece, direction, allOccupied)
    }
    return moves & blockedMoves
}

This approach:

Traces rays in all relevant directions
Stops at the first occupied square
Handles captures efficiently

Check Detection and Legal Move Filtering

One of the most critical aspects of move generation is ensuring moves are legal by verifying they don't leave the king in check:

func filterLegalMoves(gs dao.GameState, legalMoves map[uint64]uint64, pseudoLegalMoves map[uint64]uint64) map[uint64]uint64 {
    filteredMoves := make(map[uint64]uint64)
    for piece, moves := range pseudoLegalMoves {
        // Simulate each move and verify king safety
        simulatedGameState := simulateMove(gs, piece, movePosition)
        if !isKingInCheck(simulatedGameState, isWhite) {
            filteredMoves[piece] |= movePosition
        }
    }
    return filteredMoves
}

This process:

Simulates each potential move
Checks if the resulting position leaves the king in check
Only keeps moves that maintain king safety

Special Move Handling

Castling Rights

Castling requires checking several conditions:

King and rook haven't moved
No pieces between king and rook
King doesn't move through check
King isn't in check

if strings.Contains(gs.CastlingRights, "K") &&
    gs.WhiteBitboard&(1<<PositionToIndex("f1")) == 0 &&
    gs.WhiteBitboard&(1<<PositionToIndex("g1")) == 0 &&
    // ... additional checks
    {
    kingMoves |= (1 << PositionToIndex("g1"))
}

Performance Considerations

The use of bitboards provides several performance benefits:

Efficient move generation using bitwise operations
Quick position evaluation
Compact board representation
Fast legal move filtering

Technical Implementation Highlights

Let's dive deeper into some key technical aspects:

Bit Manipulation Techniques

The engine makes heavy use of bit manipulation:

piece & -piece: Isolates the least significant bit
board &= board - 1: Clears the least significant bit
board << n: Shifts bits left (used for white piece moves)
board >> n: Shifts bits right (used for black piece moves)

Move Generation Optimization

The code uses several optimization techniques:

Pre-calculated attack tables for knights and kings
Efficient ray tracing for sliding pieces
Smart use of bitwise operations to avoid loops

State Management

The engine maintains game state efficiently:

Bitboards for piece positions
Castling rights as string flags
En passant square tracking
Move history for game progression

Conclusion

Building a chess engine is a fascinating exercise in both chess knowledge and computer science. The bitboard-based approach provides an elegant solution to the complex problem of move generation, offering both performance and maintainability.

Some potential improvements for the future:

Implementation of a proper evaluation function
Addition of search algorithms (minimax with alpha-beta pruning)
Opening book integration
Endgame tablebases

The full source code demonstrates how modern programming techniques can be applied to create an efficient chess engine while maintaining readable and maintainable code.

Note: This implementation focuses on move generation. For a complete chess engine, you would need to add position evaluation, search algorithms, and other features.

If you're interested in diving deeper, check out the full codebase onGitHub.

Would you like me to expand on any particular section or provide more detailed technical explanations?

Why I Love: git reset --hard

Naman Vashistha — Tue, 21 Jan 2025 14:32:27 +0000

Managing version control is both an art and a science, and for many developers, Git is the tool of choice. While Git offers a plethora of commands to handle almost any situation, there is one command I hold dear to my heart: git reset --hard. It’s my go-to solution when things go haywire, and it’s the unsung hero that has saved me countless times. In this article, I’ll explain why I love it, how it makes my life easier, and how you can use it effectively.

What Does `git reset --hard` Do?

At its core, git reset --hard is about resetting your Git repository to a clean state. When you run this command, three things happen:

HEAD Moves: The HEAD pointer is moved to a specific commit.
Staging Area Reset: The staging area is updated to match the target commit.
Working Directory Reset: All uncommitted changes in your working directory are discarded to match the target commit.

In simpler terms, it’s like hitting a "factory reset" button for your Git repository. Here’s the syntax:

git reset --hard <commit-hash>

If you omit the commit hash, it defaults to the latest commit.

Why `git reset --hard` Is a Game-Changer

1. Undoing Mistakes Instantly

There have been countless times when I made experimental changes that didn’t pan out. Instead of manually reverting each file or trying to stash changes, I simply run:

git reset --hard

Within seconds, my repository is back to its last stable state. It’s quick, efficient, and hassle-free.

2. Getting a Clean Slate

When working on large projects, the working directory can get cluttered with temporary changes. Sometimes, you just want to start fresh.

Example scenario:

You’re debugging an issue and have tried multiple approaches.
None of them worked, and your directory is now a mess of temporary files and edits.

Instead of sifting through the debris, git reset --hard wipes the slate clean, letting you start anew.

3. Recovering from Merge Chaos

Merges don’t always go as planned, and conflicts can leave your repository in an inconsistent state. When I realize a merge has gone sideways, I use:

git reset --hard <commit-before-merge>

This resets my repository to a pre-merge state, allowing me to approach the merge more carefully.

4. Experimentation Without Fear

One of the joys of being a developer is experimenting with new ideas. But experiments often lead to dead ends. Knowing I can always reset my repository gives me the freedom to try new things without worrying about breaking anything permanently.

Use It, But Use It Wisely

As powerful as git reset --hard is, it comes with a caveat: it’s irreversible. Once you run this command, any uncommitted changes are gone for good. To avoid losing important work, here are some tips:

1. Check the Commit History:

Use git log to ensure you’re resetting to the right commit.

   git log --oneline

2. Use `git reflog` for Recovery:

If you accidentally reset to the wrong commit, git reflog can help you find your previous HEAD position.

   git reflog
   git reset --hard <old-commit-hash>

3. Commit or Stash First:

Before running git reset --hard, always commit or stash any changes you might need later.

   git stash save "WIP changes"

Caution: The Double-Edged Sword

git reset --hard is incredibly powerful, but with great power comes great responsibility. It permanently discards uncommitted changes, which means there’s no way to recover them unless you’ve stashed or committed first. Always double-check your changes and use commands like git log or git reflog to ensure you’re targeting the correct commit. This cautionary step can save you from accidental data loss.

Real-World Examples

1. Fixing a Botched Feature

Imagine you’re halfway through implementing a new feature, and it’s not working as expected. You realize it’d be faster to start over. Here’s what you do:

git reset --hard

In seconds, you’re back to where you started, ready to tackle the feature with a fresh perspective.

2. Cleaning Up After a Failed Rebase

Rebasing can sometimes lead to unexpected conflicts or an incomplete history. If a rebase goes wrong, here’s how you can recover:

First, abort the rebase to stop the process and revert any in-progress changes:

  git rebase --abort

If you still need to reset your branch to its state before the rebase, use:

  git reset --hard ORIG_HEAD

Additionally, if there are specific commits from the rebase you want to preserve, you can cherry-pick them individually after resetting:

  git cherry-pick <commit-hash>

This combination gives you the flexibility to recover from rebase errors without losing valuable work.

Why I Love It

git reset --hard is more than just a command; it’s a safety net. It gives me the confidence to experiment, the ability to recover quickly, and the freedom to focus on solving problems without worrying about making mistakes. It’s a tool that’s simple yet incredibly powerful.

If you haven’t already embraced git reset --hard, I encourage you to give it a try. Just remember to use it wisely, and it’ll become one of your favorite Git commands too.

Final Thoughts

Version control is an essential skill for developers, and mastering commands like git reset --hard can make your life significantly easier. While it may seem intimidating at first, understanding its nuances will empower you to handle even the messiest of repositories with confidence. For me, it’s an indispensable part of my workflow, and I hope it can be for you too.