DEV Community: Suryadipta Ghosh

Here's why you need a chess stats card

Suryadipta Ghosh — Fri, 12 Jun 2026 10:34:03 +0000

How I spent a day automating something that takes 10 seconds to do manually, and why you should absolutely use it.

Let me paint you a picture.

You're a developer. You open a developer's GitHub profile. There's a nice README: some skills, a few projects, maybe a visitor counter they definitely copied from Stack Overflow.

Then you see it.

"Won as Black against a 1542-rated opponent. Sicilian Defense. 38 moves. Currently on a 5-game win streak."

You don't even play chess. You have no idea what any of that means. But you understand one thing. This person has a personality besides coding. This person ships things. This person spent their weekend building an automated README updater instead of touching grass.

Here's why you need a chess stats card on your GitHub profile

You don't.

Let's be honest; you absolutely do not need this. Your README was fine. Your projects speak for themselves. Nobody hiring you as a backend engineer cares that you blundered a rook on move 23.

But here's the thing about developer profiles in 2026: everyone has the same README. Skills section. Projects section. GitHub stats card showing 847 contributions in green squares. A wavy SVG banner someone generated at readme.so.

Chess stats? Nobody has that. And the ones who do are immediately more interesting than the ones who don't.

That's the whole pitch. That's the blog post.

Lemme tell you more about it since you seem interested.

The origin story (it's embarrassing)

I was procrastinating.

I had actual work to do real features, real projects. Instead I was playing Blitz on Chess.com at 1am, losing to some 500 rated, and thinking: "I wish my GitHub profile knew about this loss so it could share in my suffering."

That thought, which a normal person would have dismissed immediately, lodged itself in my brain.

By 2am I had an API route. By 3am I had a GitHub Action. By 4am I had deployed it to Vercel, watched it fail, fixed the UTF-8 encoding issue that was turning chess pieces into hieroglyphics, and gone to sleep feeling like I had accomplished something meaningful.

I had not accomplished something meaningful. But I had built something cool.

What I actually built

chess-readme-stats does two things:

Story mode — a narrative text block that lives in your README and auto-updates every 6 hours via GitHub Actions. It reads your Chess.com games, figures out what happened, and writes a little story about it.

It looks like this:

2026-06-10 · Blitz (3 min) · Playing as White

Opponent resigned after 38 moves

Opening: Sicilian Defense · ECO B20
Accuracy: 91.2%

Opponent: johndoe · 1542 rated (55 points above you)

Rating: 1487 → 1495 (+8)
Streak: 5-game win streak
This month: 21W 9L 3D (Blitz)

Peak hours: evenings
Personal best: 1623

Not a table. Not a JSON dump. A story. Because your games are stories and they deserve to be told.
(I know it svcks in visual appeal, we gon fix that).

Card mode — a single SVG image you embed in one line. No GitHub Actions. No workflow. No setup. Just:

![Chess Stats](https://chess-readme-stats.vercel.app/api/card/yourusername.svg)

Done. It shows your rating, peak rating, win rate, total games, country, and most played opening. Updates on every page load.

The technical bit (for the nerds)

The whole thing runs on Next.js deployed to Vercel. Here's why those two choices specifically:

Next.js gives you API routes and a frontend in one project. My /api/story/[username] and /api/card/[username].svg endpoints live right next to the website that generates the setup instructions. One codebase, One deploy. One git push and everything is live.

Vercel gives you edge deployment for free. This matters specifically for the SVG card — when GitHub renders someone's README, it hits your card endpoint from wherever their CDN node is closest to. Vercel's global network means that request is fast regardless of where the viewer is. A basic Express server on a single DigitalOcean droplet would be slower and more expensive.

The Chess.com API is entirely public and requires zero authentication. You can hit it right now in your browser:

https://api.chess.com/pub/player/hikaru/stats
https://api.chess.com/pub/player/hikaru/games/2026/06

Everything I needed was sitting there. Ratings, game history, PGN strings with opening data baked in, accuracy scores when available, timestamps, country. No API key. No rate limit I hit in practice. Chess.com just... gives you this data. Genuinely one of the nicest public APIs I've worked with.

The trickiest part was the opening name. Chess.com's PGN has an [ECOUrl] header that looks like:

https://www.chess.com/openings/Sicilian-Defense-Dragon-Variation

You slug-parse that URL, replace hyphens with spaces, handle the ... notation for Black's variations, and you have a clean opening name. Much more reliable than the [Opening] header which only appears sometimes.

The second trickiest part was the streak calculation. A chess player plays Blitz, Rapid, and Bullet all mixed together in one games array. If I walked backwards counting consecutive wins, a Rapid loss would break a Blitz win streak incorrectly. The fix is filtering by time_class before counting — only count streaks within the same format as the last game played.

How to set it up in 2 minutes

Go to chess-readme-stats.vercel.app, enter your Chess.com username, and the site generates everything for you — a live preview of your card, the one-line embed, and the complete workflow YAML with your username already filled in.

For card mode: copy one line, paste into README, done.

For story mode: paste the token comments into your README, create one workflow file, run it once manually. After that it runs itself. Don't worry, as of writing this, I need the project is too pre-stage, but I'll maintain it

The whole setup takes less time than the average chess game.

Contribute

This is open source and I genuinely want contributors. There are real features missing that I haven't built yet:

Light mode card theme
More custom card themes
Blitz and Bullet rating variants (currently only Rapid)
Rating history sparkline inside the card
Lichess support for the non-Chess.com crowd
Country code to full country name (right now it shows IN not India)
Response caching so we're not hammering Chess.com on every request

If any of those sound interesting, the codebase is small — under 400 lines total across two route files and one page. You can read the whole thing in 20 minutes and ship something real.

github.com/sxryadipta/chess-readme-stats

The real reason I built this

I'm a fresher. I'm building my portfolio. I needed projects that weren't todo apps or weather apps or Netflix clones.

This is a real product with a real API, a real deployment, real users, and a real open source presence. I learned Next.js by building it. I learned API design by building it. I learned why cache headers matter by being burned by them at midnight.

That's worth more than any tutorial. More importantly, that was something I cared about; and wished it existed

Also my Chess.com stats are now on my GitHub profile and I feel 15% more legitimate as a person.

Built with Next.js, deployed on Vercel, powered by the Chess.com public API.

If this was useful, a star on the repo means a lot — github.com/sxryadipta/chess-readme-stats

I made a WhatsApp reminder for important FIFA World Cup matches.

Suryadipta Ghosh — Fri, 05 Jun 2026 16:16:37 +0000

I have been a busy these vacation days with my personal projects. But being a football fan, I can’t afford to miss World Cup matches. Especially of the big names. It is the last World Cup of the players of my generation; who I grew up watching. It is the last dance of the stars who got me hooked: Ronaldo, Messi, Neymar, Modric, Neuer, and more. And for this reason, I don’t want to miss the major matches in group stages and knockout rounds.

I decided to make a simple WhatsApp reminder for me so that I have notifications of matches I want to watch without manually searching it up or missing out later. The teams I added are Brazil, Germany, Spain, France, Argentina, England and my favourite, Portugal.

For this, I needed 4 things. Firstly, a data of the matches and their dates and timings. Secondly, an execution engine, which checks for the timings and triggers the alerts. Then, a delivery channel is needed. Lastly, an automation which acts as a scheduler and runs periodically.
So for this, The first step was to create a matches.json to store the match timings in Indian Standard Time (IST).

I didn’t want to complicate it by fetching data, so I hardcoded it. Next, I needed to figure out a way to actually go through this JSON and add a WhatsApp reminder for me. I got to know about the Twilio WhatsApp sandbox, which is a pre-configured environment for sending business initiated messages. I can use that to send my scheduled reminders.
I signed up for a Twilio account. After verification and filling preferences, I setup the Twilio WhatsApp sandbox. To begin testing, I connected to Twilio sandbox by sending a WhatsApp message from my device to the Twilio number (which was my own number). Twilio on a trial account lets you send messages to verified mobile numbers only. You need to get your Account SID and Auth token in order to run an automated script.
Now, we need a script to parse the JSON file and send reminders at predetermined intervals. I needed reminders at 12, 3 and 1 hour before the match. Since the script runs every hour, it won’t land exactly at the 12h/3h/1h mark. So I give it a ±30 min buffer. Which means: If a match is between 690–750 mins away, it counts as the 12h reminder. The time is calculated by a parseIST function which converts the "2026-06-17 22:30" string into a proper JS Date object. It appends +05:30 so JS knows it's IST and converts it to UTC internally. A minsToGo is set which calculates how many minutes from right now until kickoff. If it's negative, the match has already started. Now, we can loop over using this constant. For each match, it checks if the kickoff is within ±30 mins of the 12h, 3h, or 1h reminder window; and if so, builds and sends a WhatsApp message with the match details.
I tested it locally by running it on node. And it worked! (had to alter the times of some matches temporarily to trigger the scheduled times)

To automate the running of this file, I added GitHub workflows. Firstly, setting up the Account SID, Auth Token and WhatsApp number in your repository secrets is required.

Then we create a remind.yml file in the Github Workflow directory of the repository. It sets up a scheduler which runs every hour (you can manually run it too in repository actions). And all set! This now gives me periodic reminders of the upcoming important messages on WhatsApp.

You can check the repository here: https://github.com/sxryadipta/worldcup-match-reminder

JS HTML DOM

Suryadipta Ghosh — Sun, 13 Apr 2025 17:42:34 +0000

Introduction

The basic HTML and CSS teaches you to build static web pages. What I mean by static is, any change requires reloading the whole page. Developers would have to sit and wait all day to handle user interactions and update content on the fly- which is manually impossible. To create these dynamic experiences smoothly, the DOM was introduced.

What is DOM?

DOM stands for document object model. It was introduced as a structured representation of the HTML document. HTML elements are constructed as a tree of Objects in HTML DOM. In the DOM, all HTML elements are defined as objects. Using JavaScript we can create, delete or update these DOM elements in real-time, basically adding interactivity.

DOM Document

Think of HTML DOM document as the big object- the owner of all other objects in your web page. As he’s the owner, you need to go through him to get to his other owned objects. In other words, before accessing any other object, you access the document object first. Now, how do you access or manipulate objects/elements of your HTML web page?

document.getElementById(id)  //find an element by element id.
element.innerHTML =  new html content  //change the inner HTML.
document.createElement(element)  //create new element.
document.removeChild(element)  //delete an element.
document.appendChild(element)  //add an element.

DOM Methods and Properties

DOM methods are actions, and DOM properties are values. Think of the DOM as a human body:

Elements are like body parts. (e.g., hands)
Properties describe them. (hand.color = brown)
Methods signify actions. (hand.move)

element.innerText //is a property.
element.setAttribute() //is a method.

Properties describe, methods do.

Events and EventListeners

HTML events are occurrences that a web page can respond to. Events are like your web page saying "Hey, I got touched!" and event listeners are JavaScript's way of saying "I got this." It's liking teaching your web page stimuli and the responses to it.
The addEventListener() method attaches an event handler to the specified element.
Syntax:
element.addEventListener(event, function, useCapture);

Well, I guess that's enough as my introductory blog sharing about my learnings, I'll be back soon!

Follow me on X: sxryastacks

Basic Git and GitHub commands

Suryadipta Ghosh — Tue, 09 Jul 2024 09:57:13 +0000

Learning about version control system is an important part of your developer journey. As I started to code, one of the first things that I learnt was about Git and GitHub. Straight from the horse’s mouth, “Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.” It was created by Linus Torvalds in 2005 and has become the standard for version control in software development due to its efficiency and flexibility.
On the other hand, GitHub is a web-based hosting service for Git repositories. It provides a platform where developers can store their Git repositories in the cloud, making it easier to collaborate with others. GitHub adds features on top of Git, such as issue tracking, pull requests, code review, and project management tools. Open-source projects and teams widely use it for managing and sharing code.

Here are some of the basic commands of git that would help you get started using it:

git init
- Initializes a new Git repository in the current directory.
git clone [repository_url]
- Clones a remote repository from GitHub or another Git hosting service to your local machine.
git add [file(s)]
- Adds file(s) to the staging area to prepare them for a commit.
git commit -m "commit message"
- Commits the staged changes to the repository with a descriptive message.
git status
- Shows the current state of the working directory and staging area.
git pull
- Fetches changes from the remote repository and merges them into the current branch.
git push
- Pushes your commits to the remote repository.
git branch
- Lists all local branches in the repository.
git checkout [branch_name]
- Switches to the specified branch.
git merge [branch_name]
- Merges the specified branch into the current branch.
git remote -v
- Lists the remote repositories associated with the local repository.

Now let’s learn about some of the GitHub Commands:

git remote add origin [repository_url]
- Sets up a remote repository on GitHub as the origin for your local repository.
git push -u origin [branch_name]
- Pushes the specified branch to GitHub and sets it as the upstream branch.
git pull origin [branch_name]
- Fetches changes from GitHub and merges them into the current branch.
git clone [repository_url]
- Clones a repository from GitHub to your local machine.
git fork
- Creates a copy of a repository on GitHub under your GitHub account.
git pull-request
- Opens a pull request on GitHub for merging changes from a branch.
git fetch --all
- Fetches all branches from the remote repository to your local machine.

These commands cover the basic operations you'll perform when using Git and GitHub for version control and collaboration in software development.