Forem: Nitish

GitHub Suspended Me. Turns Out, That Was Fine

Nitish — Mon, 27 Apr 2026 16:51:17 +0000

Okay so I've been putting off writing this post for weeks because honestly I wasn't sure how much I wanted to share. But enough people have asked what happened with Ultimate Media Downloader that I figure I owe everyone an explanation. Fair warning: this is long. Make a coffee.

Late March 2026. Everything was normal. I was pushing updates, answering issues, doing the usual open-source maintainer thing. Nothing felt off. I had notifications from GitHub, I was working on a fix for a bug that had been annoying me for days, and life was... fine, you know? Boring good. The kind of good you don't appreciate until it's gone.

Then GitHub suspended my account.

Day One: The Screen That Broke My Brain

I'm not going to pretend I handled it gracefully. I did not.

I opened GitHub to push a commit and got the suspension screen. My brain kind of just... stopped for a second. I reread it three times thinking I was somehow misreading it. I wasn't.

The reason they gave was vague. Something about policy violations and suspicious activity. I genuinely had no idea what I'd done. I mean — I host a media downloader. I've always known that sits in a gray area. But I wasn't the first person to do this, and there are way bigger projects doing the exact same thing still sitting on GitHub right now, so I figured I'd just... appeal it and it'd get sorted.

Reader, it did not get sorted quickly.

Shouting Into the GitHub Support Void

Have you ever submitted an appeal to a large tech platform? It's a specific kind of miserable. You write this really thoughtful, detailed explanation. You cite examples. You reference other projects. You basically build a legal case for why your account should be reinstated. And then you get back an email that reads like it was written by someone who definitely did not read your email.

That was my week two.

I sent multiple follow-ups. I explained that the software is a tool and that tools don't have intent. I pointed out YouTube-DL, which does functionally the same thing and had its own GitHub drama a few years back. Nothing landed. Or if it did, nobody told me.

What made it worse — and this is the part that kept me up at night — is that I had users. Real people relying on auto-updates that pulled from GitHub releases. My version checker hit the GitHub API. Everything was tangled up with my account. And I was locked out.

By about day ten I stopped waiting and started planning.

The Backwards Move That Actually Worked

I'm skipping over some of the specifics here because honestly they're boring and a bit embarrassing. But the short version is: I managed to get temporary access to the repo through some recovery options I'd forgotten I'd set up years ago.

My first instinct when I got in was to back everything up. And then I made what felt like a weird call at the time: I made the repository private.

I know that sounds backwards. "Your project is already invisible because your account is suspended, why would you make it more invisible?" But my thinking was — if GitHub sees a popular public repo suddenly go private, maybe they interpret that as me taking security concerns seriously rather than being a bad actor. It was a gamble.

Turns out it kind of worked? I started getting slightly less robotic responses from their support team. Something shifted. I don't know exactly what, and I'm not going to pretend I do.

Back In, But Not Really Welcome

They reinstated the account. With conditions attached. Basically: the main repo for Ultimate Media Downloader couldn't stay as-is. Too "potentially problematic." That was their phrase, not mine.

So I was back. But it didn't feel like a win. It felt like being let back into a party where the host is clearly not happy you're there. You're standing by the snack table and every few minutes someone glances at you and you're like — yeah I know, I know.

That was the moment I actually started taking Codeberg seriously.

Fine. Let's Try This Codeberg Thing.

I'd known Codeberg existed for a while. I'd seen it mentioned in open-source forums and had vaguely filed it away as "GitHub but smaller and European." Never felt urgent enough to actually explore.

Now it felt urgent.

I spent a day on the platform just clicking around. And the first thing I noticed was how — I don't know how to say this without sounding cheesy — how genuine it felt? There's no AI assistant trying to summarize your commits. No featured marketplace pushing you to buy things. No weird enterprise upsell banners. It's just a git hosting platform run by a non-profit that actually believes in what it's doing.

That shouldn't be a revelation. But after the GitHub experience it kind of was.

The other thing I noticed: nobody there was going to suspend my account for hosting a media tool. Because they actually care about software freedom. Not performatively — actually.

By end of week four I'd made up my mind.

The Actual Migration

This part is less dramatic than the rest of the story. Migrations are mostly just tedious, not traumatic.

I updated the README. Changed the clone URLs. Updated the version checker endpoint from GitHub's API to Codeberg's. Went through the contributing docs, the code of conduct, the issue templates — every file that had a github.com link in it. Found more than I expected. One of them was buried in a comment inside a Python file that I'd written like two years ago and completely forgot about. That took a minute.

Total time: maybe a day and a half, spread over two days because I kept getting distracted.

The harder part was more psychological. I'd been on GitHub for years. All my institutional memory of "where things live" pointed there. Switching platforms meant rewriting some mental muscle memory, which sounds small but isn't.

But once it was done? I felt weirdly relieved.

Where We're At Now

It's late April. The project lives on Codeberg now. Everything works. Updates go out, the version checker works, people are downloading things just fine.

The Codeberg community is smaller. That's real. Fewer people stumble across your project because there's no algorithm surfacing it. But the people who do find it seem more... intentional? Like they were looking for something specific rather than just scrolling. I've had better issue reports in the last few weeks than I used to get in a month.

I still have my GitHub account. I'm using it mostly to mirror things over there, just so people who bookmarked old URLs don't hit dead ends. But I'm not building anything like that there anymore.

But still using the githb to showcase my previous successful project and more. because i don't want to sart over all of it again.

The Actual Takeaway

I don't want to wrap this up with some neat lesson because the experience wasn't neat.

It was stressful. I was anxious for basically a month straight. I sent emails to GitHub support that I now find slightly embarrassing in retrospect. I lost sleep. My project went dark for a stretch of time and I couldn't even tell users why because I didn't fully understand why myself.

But — and I mean this — I wouldn't have moved to Codeberg if it hadn't happened. I was too comfortable. Sometimes that's what it takes.

If you're one of the users who noticed things were broken and didn't get an explanation at the time: I'm sorry. That sucked and you deserved better communication from me. I was in reactive mode and honestly just trying to keep the thing alive.

It's alive. It's on Codeberg. Come find it there.

One more thing

I still have like four documentation files somewhere that probably have a github.com URL hiding in them. I'll find them eventually. If you spot one before I do, open an issue. On Codeberg, obviously.

— NK2552003

Writing from my home office which is definitely a real office and not just my bed with a laptop

Codeberg > UMD
Github

PasteShield - an Extension that can save you from deploying the secrets

Nitish — Sat, 25 Apr 2026 06:04:05 +0000

You've done this. Don't lie. 😅

# "just for testing, I'll remove it later"
const API_KEY = "sk-prod-abc123supersecretdonotcommit"

git add .
git commit -m "fix stuff"
git push

3 minutes later:

GitHub Secret Scanning Alert: We found a secret in your repo...

Yeah. We've all been there.

Meet PasteShield

PasteShield is a VS Code extension that watches your clipboard like a hawk. Every time you hit Ctrl+V, it scans the content before it lands in your file.

Think of it as a bouncer at the door of your codebase.

No cloud. No subscription. No telemetry. 100% offline. Free forever.

See it in action

You paste an API key → PasteShield goes "hold on bestie" →

Three choices. Zero drama:

Cancel — yeah don't do that
Show Details — tell me more
Paste Anyway — I know what I'm doing (do you though)

Also catches stuff already in your file

It doesn't just guard the door — it also checks if anything sketchy already got in, via CodeLens annotations right above the suspicious line:

No hunting through files. The warning is right there, above the guilty line.

What does it catch? Everything, basicall

~200 patterns. 25+ categories. Scanned in under 50ms.

Vibe	Examples caught
AI keys	OpenAI, Anthropic, Gemini, Groq, DeepSeek, xAI...
Cloud creds	AWS, GCP, Azure — all the big ones
Payment secrets	Stripe, Razorpay, PayPal, Square
DB connections	MongoDB, Postgres, Supabase, Redis
Auth tokens	GitHub PAT, JWT, Slack, Discord
PII	SSNs, credit cards, Aadhaar, PAN, IBAN
Unsafe code	`eval()`, `innerHTML`, SQL injection patterns
...and 18 more	Mobile/IoT, Maps, CDN, Crypto, Web3

Too loud? Tune the noise level:

"pasteShield.minimumSeverity": "high"
// critical | high | medium (default) | low

Not ready to be blocked? Try silent mode 🤫

New in v1.7 — silent mode logs everything to the sidebar without interrupting your paste.

Perfect if you're the type who wants data before commitment (reasonable, honestly).

"pasteShield.silentMode": true

See the full history in the sidebar, export it as JSON, sleep better at night.

For teams

Drop a .pasteshield-policy.json in your repo (or host it at a URL) and your whole team gets the same rules automatically.

{
  "template": "strict",
  "rules": [
    { "type": "block_pattern", "pattern": "openai-api-key" },
    { "type": "audit_logging", "enabled": true }
  ]
}

One update → everyone's protected. No Slack message needed.

Where it stores your secrets

v1.7 upgraded this significantly. Credentials go into your OS keychain — Windows Credential Manager, macOS Keychain, Linux libsecret — via VS Code's native SecretStorage API.

Nothing in settings.json. Nothing in plaintext. Nothing in the cloud.

And if you actually want to store detected secrets properly, it integrates with:

HashiCorp Vault · AWS Secrets Manager · Azure Key Vault · Google Secret Manager

All from inside VS Code. No tab switching.

vs Gitleaks / git-secrets

Not a competition — they're complementary:

You type/paste  →  [PasteShield catches it here] ← THIS
      ↓
You commit      →  [Gitleaks / git-secrets catch it here]
      ↓
You push        →  [GitHub Secret Scanning catches it here]
      ↓
Production      →  [Too late]

PasteShield is your first line of defense. Use all of them.

Install in 10 seconds

Option 1: VS Code Marketplace → search PasteShield → Install

Option 2: Quick Open (Ctrl+P) and paste:

ext install NK2552003.pasteshield

That's it. It starts working immediately. No config needed.

What's coming

The roadmap is genuinely exciting:

ML-based false-positive reduction — smarter, fewer annoying alerts
CLI version — run it in CI/CD pipelines
SARIF output — plug into GitHub Advanced Security
Auto secret rotation via provider APIs
Community pattern marketplace — share and import rulesets

TL;DR

You paste something sketchy → PasteShield yells at you → you don't get fired → 🎉

Free. Offline. 200+ patterns. Works in under 50ms.

sidkr222003 / PasteShield

PasteShield intercepts every paste (`Ctrl+V` / `Cmd+V`) in the editor and scans the clipboard content for dangerous patterns — API keys, hardcoded passwords, unsafe JavaScript, prototype pollution, and more — before the text ever reaches your file.

PasteShield

Intercepts secrets before they land in your file — ~200 patterns, 100% offline.

Overview

PasteShield intercepts every paste (Ctrl+V / Cmd+V) in the editor and scans the clipboard content for dangerous patterns — API keys, hardcoded passwords, unsafe JavaScript, prototype pollution, and more — before the text ever reaches your file.

It works entirely offline, using a high-performance regex engine that evaluates ~200 pre-compiled patterns across 25+ categories in under 50 ms. Detected threats are surfaced through inline warnings, CodeLens annotations, a persistent history sidebar, and an ASCII statistics dashboard.

Why PasteShield vs Gitleaks?

Gitleaks catches what's in your repo. PasteShield catches what never should have been.

These tools are complementary, not competing:

Gitleaks: Scans existing git repositories for leaked secrets (post-commit detection)
PasteShield: Intercepts secrets at paste time, before they ever touch your filesystem (pre-commit prevention)

Use both for defense-in-depth: PasteShield as your first…

View on GitHub

Built by Sid Kr. (NK2552003). MIT licensed. No VC funding, no upsell, no BS.

GITHUB
MARKETPLACE VSCODE

Drop a ⭐ on GitHub if this saved your job once. Or twice.

The Quiet Files That Make a Website Trustworthy

Nitish — Mon, 20 Apr 2026 15:59:35 +0000

I used to think a website was only about visible things: pages, animations, speed, and "wow" UI.

Then one day, after deploying my portfolio, a scanner flagged something tiny:

"security.txt not configured."

At first, I ignored it.

But that one warning sent me down a rabbit hole, and I learned something important:

Some of the most important website files are the ones users never see.

They are quiet, but they build trust, improve security, and help search engines understand your site.

In this post, I will explain these files in a simple way:

.well-known
security.txt
pgp-key.txt (your GPG public key)
robots.txt
sitemap.xml

If you are a beginner, this is for you.

TL;DR

If your website is public, these files should exist:

/.well-known/security.txt: how to report vulnerabilities.
/.well-known/pgp-key.txt: your public encryption key for sensitive reports.
/robots.txt: crawler guidance.
/sitemap.xml: map of your public URLs.

Together, they make your site easier to trust, crawl, and maintain.

Imagine Your Website as a City

Your homepage is the city center.

Your projects page is the museum.

Your contact page is city hall.

Now imagine visitors are not only humans.

Some are bots, crawlers, and security researchers.

How do they know:

Where to report a vulnerability?
Whether encrypted contact is available?
What pages they should crawl?
Where your important pages are listed?

That is where these files help:

.well-known/ (a standard place for machine-readable files).
security.txt (how to report vulnerabilities).
pgp-key.txt (how to send encrypted security reports).
robots.txt (crawler guidance).
sitemap.xml (map of your public pages).

1. `.well-known`: The Official Notice Board

Think of .well-known as your website's official notice board for machines.

It is a standards-based location where tools expect to find important metadata.

Example paths:

https://yourdomain.com/.well-known/security.txt
https://yourdomain.com/.well-known/pgp-key.txt

Why It Matters

Security scanners check this location first.
Automation tools trust standard paths.
It reduces confusion and makes your site look professional.

Quick Tip

Keep these files simple text.
Keep the URL stable.
Avoid moving them around once published.

2. `security.txt`: "If You Find a Bug, Contact Me Here"

security.txt is like a public help desk for security researchers.

If someone finds a vulnerability, they should not have to guess where to report it.

A practical security.txt can look like this:

Contact: mailto:security@yourdomain.com
Contact: https://yourdomain.com/contact
Encryption: https://yourdomain.com/.well-known/pgp-key.txt
Acknowledgments: https://yourdomain.com/security/thanks
Policy: https://yourdomain.com/contact
Canonical: https://yourdomain.com/.well-known/security.txt
Expires: 2027-04-20T00:00:00.000Z
Preferred-Languages: en

What Each Line Means

Contact: where someone can report a vulnerability
Encryption: where your public key is published
Acknowledgments: page where you thank valid reporters
Policy: your disclosure policy or contact workflow
Canonical: the official URL of this file
Expires: validity date (update this before expiry)
Preferred-Languages: language preference for reports

Why It Matters

Encourages responsible disclosure.
Helps researchers report safely and quickly.
Improves trust signals for audits and security checks.

Common Mistakes

Expired Expires date
Broken Encryption URL
Contact pointing to a dead inbox
Publishing this file but never checking reports

3. `pgp-key.txt` (Many People Call It a GPG Key): Your Locked Mailbox

When a vulnerability is sensitive, researchers may want encrypted communication.

That is where your public PGP key comes in.

You publish your public key (usually ASCII-armored) at:

https://yourdomain.com/.well-known/pgp-key.txt

It looks like this:

-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----

How to Generate and Publish Quickly

gpg --full-generate-key
gpg --armor --export you@yourdomain.com > public/.well-known/pgp-key.txt

Important Notes

This file should contain only your public key block.
Keep your private key secret.
Reference this file from security.txt using the Encryption: field.
If you rotate keys, update this file and security.txt immediately.

Why It Matters

Enables safe disclosure for high-impact findings.
Shows your project takes security seriously.

4. `robots.txt`: Traffic Signs for Crawlers

robots.txt is the rule board for bots.

It does not secure private data, but it tells compliant crawlers what they should and should not crawl.

Simple example:

User-agent: *
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

You can also block internal routes if needed:

User-agent: *
Disallow: /admin/
Disallow: /private/

Why It Matters

Helps crawl efficiency.
Prevents unnecessary crawling of irrelevant areas.
Connects crawlers to your sitemap.

Important Reminder

robots.txt is not access control.
Do not rely on it to protect private data.
Use real auth and server-side protection for sensitive routes.

5. `sitemap.xml`: Your SEO Map

If robots.txt is traffic signs, sitemap.xml is the city map.

It tells search engines what pages exist and how often they may change.

Example entry:

<url>
  <loc>https://yourdomain.com/projects</loc>
  <changefreq>monthly</changefreq>
  <priority>0.8</priority>
</url>

Why It Matters

Faster discovery of pages.
Better indexing consistency.
Cleaner SEO foundation.

What to Keep in Mind

Include only canonical, public URLs.
Keep it updated after route changes.
Add new pages like /security/thanks when relevant.

How these files work together

.well-known gives a standard location.
security.txt gives a reporting workflow.
pgp-key.txt gives confidential communication.
robots.txt gives crawler guidance.
sitemap.xml gives URL discovery.

Together, they quietly improve trust, security, and discoverability.

A short real-world flow

Imagine someone finds an XSS issue on your site.

Here is what happens when your setup is good:

They check /.well-known/security.txt.
They see your contact and encryption info.
They fetch your /.well-known/pgp-key.txt.
They send an encrypted report.
You reproduce, fix, and thank them on /security/thanks.

No confusion. No random DMs. No lost report.

That is why these files matter.

Story from my own setup

When I first added these files, I thought:

"No normal visitor will ever read this."

But scanners stopped complaining.

My deployment checks became cleaner.

And most importantly, I knew that if someone found a serious issue, they had a safe and clear way to reach me.

That feeling is worth a lot.

Quick Next.js Structure (Copy-Friendly)

public/
  .well-known/
    security.txt
    pgp-key.txt
  robots.txt
  sitemap.xml

app/
  security/
    thanks/
      page.tsx

Verify in 30 seconds

curl -fsSL https://yourdomain.com/.well-known/security.txt
curl -fsSL https://yourdomain.com/.well-known/pgp-key.txt | head -n 5
curl -fsSL https://yourdomain.com/robots.txt
curl -fsSL https://yourdomain.com/sitemap.xml | head -n 20

If all four commands return valid content, your baseline is strong.

Beginner Checklist You Can Copy

[ ] Add /.well-known/security.txt
[ ] Add /.well-known/pgp-key.txt
[ ] Add Encryption: and Acknowledgments: in security.txt
[ ] Add a /security/thanks page
[ ] Keep robots.txt and sitemap.xml updated
[ ] Set a reminder to update Expires before it lapses

Final Thought

Beautiful UI gets attention.

These tiny files earn trust.

If your site is public, these are not "extra" files anymore. They are part of good web citizenship.

If you are building in public, these files are one of the easiest professional upgrades you can make in a single afternoon.

Building a VS Code Extension — Here's What It Does & Need Your Help

Nitish — Sun, 19 Apr 2026 17:15:47 +0000

TL;DR — Building Dev Toolkit, an open-source VS Code extension full of developer utilities. There are 11 open issues, all beginner-friendly. Come pick one and ship something real.

The Problem

Every developer has a list of tiny friction points they tolerate every day:

Manually hunting down leftover console.log statements before a commit
Forgetting which imports are actually used
Having no clue how large a folder is until it's too late
Wondering "where is this function even called?"

None of these are hard problems individually. But nobody had packed them all into one extension. So I built one.

What is Dev Toolkit?

Dev Toolkit is a VS Code extension that bundles essential developer utilities into a single, clean package. It's written in TypeScript and lives right inside your editor.

Here's what it can do right now:

File Size Viewer

Displays the size of any file in the VS Code status bar — formatted in human-readable units (KB, MB, etc.). Also decorates the Explorer panel with per-folder and per-file sizes, with tooltips showing file count.

Console Log Remover

One command. Removes every console.* statement from your JS/TS file — or just from a selected block of code. Perfect pre-commit cleanup.

Unused Import Remover

Scans your JavaScript/TypeScript file and strips out every import that isn't actually referenced. Clean files, no clutter.

One-Click Project Cleanup

Runs three hygiene fixes in a single action:

Remove all console.* calls
Remove unused imports
Trim trailing whitespace

Function Reference Tracker

Locate every reference to a function across your entire workspace. Great for understanding impact before refactoring.

Code Explainer

Select any code block and get an AI-assisted explanation in a dedicated panel. Context-aware and fast.

Read Time Estimator

Shows an estimated read time for JavaScript, TypeScript, and Markdown files in the status bar. Surprisingly useful for docs and long config files.

Code Style Mood

Real-time code quality badges right in your status bar

Hover the badge for a detailed breakdown of line length, naming conventions, comment density, and function complexity.

The Stack

TypeScript    → 81.9%
CSS           → 7.3%
JavaScript    → 6.5%
HTML          → 4.3%

Built using the VS Code Extension API. Scaffolded with yo code, bundled with webpack. No heavy dependencies — just clean VS Code APIs and a bit of TypeScript magic.

What's Coming Next — And Where You Come In

This is where I need your help. There are 11 open feature issues, all tagged good first issue:

#	Feature	Why it's cool
#14	Auto README Generator	Generate a project README from your folder structure
#13	Focus Mode (Distraction Killer)	Collapse everything non-essential while you code
#12	"Did You Mean?" Fix Suggestions	Typo-catching hints for common mistakes
#11	Coding Session Tracker	Track time spent per file/project
#10	UI Component Preview (React)	Inline previews of React components
#9	Smart Snippet Predictor	Context-aware snippet suggestions
#8	Dead Code Highlighter	Visually flag unreachable code
#7	"Where is this used?" Heatmap	Usage frequency heatmap per function
#6	File Complexity Meter	Cyclomatic complexity score per file
#5	Smart Rename Preview	Preview all rename impacts before applying
#3	Bug Risk Detector	Static heuristics to flag risky code patterns

Every one of these is scoped, interesting, and genuinely useful. No filler issues.

Why Contribute?

Whether you're a student building your portfolio or an experienced dev looking to give back to open source, this project is a good fit if you want to:

Work with TypeScript on a real, active codebase
Learn the VS Code Extension API (very marketable skill)
Ship a feature used by real developers
Get your name in the contributors list
Add a meaningful open-source contribution to your GitHub profile

No prior experience with VS Code extensions is needed. I'll help you get set up.

How to Get Started

# 1. Fork & clone the repo
git clone https://github.com/YOUR_USERNAME/DEV-TOOLKIT.git
cd DEV-TOOLKIT

# 2. Install dependencies
npm install

# 3. Compile it
npm run compile

# 4. Press F5 to launch the Extension Development Host

Full details are in CONTRIBUTING.md.

Then just:

Pick an issue you like
Comment on it — "I'd like to work on this!"
Fork, build, and open a PR

Forest Ash Theme: 21 Eye-Friendly VS Code Themes Inspired by Anime & Nature

Nitish — Sun, 22 Mar 2026 06:40:17 +0000

Hey there, fellow developers!

Ever find yourself squinting at your screen after a long coding marathon? Yeah, me too. That's why I created Forest Ash Theme — a collection of 21 carefully crafted color themes for VS Code that feel like a warm embrace for your eyes.

The Origin Story

Inspired by the soothing textures of forest ash and the moody aesthetic of anime mood boards, these themes aren't just pretty — they're optimized for readability. Think of them as a visual sanctuary during those 8-hour coding sessions.

What's Inside the Box?

You get 21 unique themes split into two beautiful palettes:

Dark Themes (11 total)

The perfect choice for night owls and those who love low-glare environments:

Forest Ash — The classic, timeless original
Yoru Paper — Inspired by Japanese night paper textures
Sumi Moon — Dark ink inspired, lunar vibes
Kitsune Ink — Mystical fox-inspired palette
Shoji Night — Traditional Japanese door aesthetic
Aizome Dusk — Indigo and dusk combinations
Ronin Lantern — Warm, wanderer-like ambiance
Bamboo Midnight — Calm green and midnight tones
Nebula Manga — Cosmic manga vibes
Sakura Charcoal — Cherry blossom & charcoal blend
Kage Washi — Shadow and traditional Japanese paper

Light Themes (10 total)

Perfect for daytime coding and sunlit environments:

All the above themes have beautiful Light variants that maintain the same aesthetic identity while being optimized for brighter environments.

Why You'll Love It

Design Philosophy

Clarity         → Distinct tokens for different syntax elements
Calming Colors   → Desaturated, nature-inspired palettes  
Reduced Fatigue  → Carefully chosen contrast ratios
Consistency      → Each theme has its own unique identity

Features That Matter

Dark AND Light variants — Choose what works for your time of day
Syntax highlighting — Every language pops perfectly
UI elements — Buttons, menus, and panels all themed cohesively
Custom token colors — Comments, variables, functions — all distinct
Terminal colors — Your command line looks good too!

How to Get Started

Step 1: Install from VS Code Marketplace

Open VS Code
Go to Extensions (Cmd+Shift+X on Mac / Ctrl+Shift+X on Windows/Linux)
Search for "Forest Ash Theme"
Click Install

Step 2: Pick Your Vibe

Open Command Palette (Cmd+Shift+P / Ctrl+Shift+P)
Type "Color Theme"
Browse through the 21 options
Press Enter to apply

Step 3: Enjoy!

Sit back and let your eyes thank you.

Perfect For...

Night coders — Developers who work late into the evening
Day workers — Those who need light themes for bright offices
Design-conscious devs — People who care about aesthetics
Anyone with eye sensitivity — Low contrast, high comfort
Anime fans — Who wants their IDE to look cooler? Everyone!

Under the Hood

Built with meticulous attention to:

Color harmony — Every palette follows color theory principles
Contrast ratios — WCAG compliance for accessibility
Token coverage — Support for 50+ languages and frameworks
Custom UI theming — Not just syntax, but your entire VS Code experience

Get Involved

Found a color combination that doesn't quite work for you? Have a theme idea?

GitHub: Forest-Ash-Theme
Issues & Suggestions: We're always improving
Star us: If you love it, show some love on GitHub! ⭐

Final Thoughts

Your code editor is where you spend hours every single day. It deserves to be:

Beautiful
Eye-friendly
Uniquely you

Forest Ash Theme checks all three boxes. Whether you're a seasoned dev or just starting your coding journey, there's a theme calling your name.

Ready to transform your VS Code experience?

Install Forest Ash Theme today and join the community of developers who've already ditched the eye strain. Your future self (especially the one coding at 2 AM) will thank you!

Got a favorite theme? Drop it in the comments — I'd love to hear which one resonates with you!

Quick Links

Happy coding, and may your eyes remain stress-free!

How I Built a Big Data Survival Guide - Because My Semester Was Not Surviving Me

Nitish — Fri, 27 Feb 2026 04:35:13 +0000

When I first opened my Big Data Analytics syllabus, I thought:

“Okay… this looks manageable.”

Ten minutes later I saw Hadoop, Spark, distributed storage, stream mining, sampling algorithms, and architecture diagrams that looked like airport control systems.

That’s when I realized something important:

Big Data isn’t hard because of concepts.
It’s hard because everything is disconnected.

You learn one tool in class, another in labs, something else on YouTube, and by the end of the semester you understand pieces — but not the system.

So instead of searching for the “perfect notes”,
I decided to build something I wish existed from day one:

A Big Data Survival Guide

-> https://github.com/NK2552003/Big-Data-Survival-Guide

A structured repository that connects syllabus concepts, real-world understanding, and student-friendly explanations in one place.

Why I Created This

Most university resources fall into one of two categories:

Too theoretical – full of definitions, zero intuition
Too practical – tutorials without explaining why things exist

As students, we don’t just need notes.
We need a mental map of the ecosystem.

I wanted something that helps answer questions like:

Why do we even need distributed storage?
What problem does Hadoop actually solve?
Why did Spark replace MapReduce in many workflows?
How does streaming data differ from batch processing in practice?
What part of this syllabus actually matters for industry?

That’s how the Big Data Survival Guide started.

Not as a project.
But as a personal attempt to survive the semester 😅

What’s Inside the Repository

Instead of dumping raw notes, I organized the material to feel like a guided path.

Foundations First (So Tools Make Sense Later)

Before touching any framework, the guide explains:

What makes data “big”
Why conventional systems fail at scale
Difference between analytics vs reporting
How modern data pipelines think about processing

This part is important because once the problem is clear, the tools suddenly stop feeling random.

Understanding the Ecosystem, Not Just Definitions

When students learn Hadoop or Spark, we often memorize components:

HDFS
NameNode
MapReduce
Executors

…but we don’t understand how they fit together.

So in the guide, each technology is explained from a problem-solution perspective:

What issue existed before it
How this system solves it
Where it fits in the bigger pipeline

This makes it easier to remember during exams and understand during projects.

Stream Processing Made Less Scary

Stream mining topics are usually where most students mentally exit the classroom.

Counting distinct elements, sampling, moment estimation…
sounds like math-heavy theory.

So I rewrote these sections with:

Simple explanations
Real examples
Step-by-step logic
Why companies actually need these algorithms

Because once you connect theory to scale problems, it stops feeling abstract.

Why I Made It Open Source

I realized something while studying:

Every student is rebuilding the same notes separately.

Different colleges.
Same confusion.
Same syllabus.
Same panic before exams.

So instead of keeping this private, I pushed it to GitHub so:

Anyone can use it
Anyone can improve it
Anyone can add diagrams or explanations
Anyone can learn from it

Because knowledge shouldn’t be locked in one notebook.

What I Learned While Building This

Ironically, creating the guide taught me more than studying ever did.

I learned that:

Writing concepts forces real understanding
Simplifying ideas exposes what you don’t actually know
Organizing topics reveals the hidden structure of systems
Teaching something is the fastest way to master it

This project started as survival.
It ended up becoming clarity.

Who This Is For

If you’re:

A student studying Big Data Analytics
Someone confused by distributed systems
Preparing for exams and interviews
Trying to understand how tools connect
Or just starting your data engineering journey

This guide is for you.

Not as a replacement for textbooks —
but as a bridge between theory and understanding.

Where This Is Going Next

I don’t want this to stay just a notes repository.

The vision is to evolve it into:

A visual learning map for Big Data
A beginner-friendly data engineering handbook
A project companion for students
A resource educators can actually use in class

Basically…

From “notes to survive the semester”
to “a system to understand the field.”

If You Want to Check It Out

Here’s the repository:

-> https://github.com/NK2552003/Big-Data-Survival-Guide

If it helps you:

Star it
Suggest improvements
Add explanations
Share it with classmates

Because if Big Data is already huge,
learning it shouldn’t feel chaotic too.

From Beautiful Soup to Building the "Ultimate Media Downloader"

Nitish — Sun, 04 Jan 2026 15:34:54 +0000

Libraries in Python that I Used

1. Beautiful Soup (The OG)

It’s literally what it sounds like. You feed it messy HTML code, and it cleans it up so you can find things. Perfect for static sites like Wikipedia or your uni's old-school portal.

2. Selenium / Playwright (The "Heavy Lifters")

Some sites are annoying and use a ton of JavaScript (looking at you, infinite scrollers). These tools basically open a "ghost" browser and click things for you. It's like having a tiny robot living in your RAM.

3. yt-dlp (The MVP)

If you’re trying to download videos or audio, don't reinvent the wheel. This library is a beast. It supports basically every site on the planet.

The Real Deal: ULTIMATE-MEDIA-DOWNLOADER

To prove I wasn't just procrastinating on my finals, I put all this together into a project called ULTIMATE-MEDIA-DOWNLOADER (UMD). (Yeah, it's still under development, but it's already a tank).

Check it out here: NK2552003/ULTIMATE-MEDIA-DOWNLOADER

Why is it cool?

It’s Fast: It uses yt-dlp under the hood, so it doesn't break every time YouTube changes its UI.
It Looks Sick: I used the Rich library, so instead of boring white text, you get actual progress bars and colors in your terminal. (Makes you look like a hacker in the library, 10/10 would recommend).
No Setup Pain: I made a script that handles all the annoying installs for you.

Try it out

If you want to play around with it:

Install in just 2 commands - no virtual environment needed!

git clone https://github.com/NK2552003/ULTIMATE-MEDIA-DOWNLOADER.git
cd ULTIMATE-MEDIA-DOWNLOADER
./scripts/install.sh

Windows users:

git clone https://github.com/NK2552003/ULTIMATE-MEDIA-DOWNLOADER.git
cd ULTIMATE-MEDIA-DOWNLOADER
scripts\install.bat

That's it! Once it's ready, just throw a link at it, now user it form anywhere

umd <URL>

️ Disclaimer (The "Don't Sue Me" Part)

Look, I built this for educational purposes only.

Be Ethical: Only download content you have permission to access. This tool is meant for personal backups or studying, not for pirating or re-distributing copyrighted stuff.
Terms of Service: Every website has its own rules. By using this tool, you're responsible for making sure you aren't breaking any laws or ToS.
No Liability: I (the developer) am not responsible for how you use this tool or any consequences that come from it. Use your brain!

Pro-Tips for My Fellow Colleagues

Don't be a jerk: If you scrape a site 10,000 times in a second, their servers will hate you and they might block your IP. Use time.sleep().
Robots.txt is a thing: Check website.com/robots.txt to see if they actually allow scraping. (Most of the time they're cool with it if it's for "educational purposes" lol).
Metadata is king: Don't just download the file; grab the title, the thumbnail, and the tags. It makes your folders look way cleaner.

Final Thoughts

Web scraping is probably the most useful skill I've picked up outside of class. It saves so much time and honestly, it’s just fun to see code doing work for you.

If you like the project, give it a star on GitHub! It helps with my "hired-after-graduation" ego. ⭐️

If you want to contribute then visit my github that is given above

Peace out! ✌️

The Anthology of a Creative Developer: A 2026 Portfolio

Nitish — Fri, 02 Jan 2026 04:35:43 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI (just check my github, not for prizes 😅)

The Prologue: Beyond the "Sectioned Resume"

Most portfolios feel like a list of ingredients. For 2026, I wanted mine to be the complete meal.

I’m Nitish Kumar, an undergraduate engineering student and creative developer. I’ve always felt that code is just another way of storytelling—so I ditched the typical "Hero-About-Projects" grid. Instead, I built a narrative experience that reflects how I think, build, and observe the world.

The Gallery

I built this to be "authored"—a stroll through a digital gallery rather than a scroll through a resume.

🔗 Explore the Story: https://nitishkr.fun

The Craft (How I Built It)

If this portfolio were a book, here is how I bound the pages:

The Technical Spine

Next.js (App Router): The foundation that holds the chapters together.
TypeScript: My editor, ensuring every "sentence" (and variable) makes sense.
GSAP: The cinematography—adding subtle, intentional motion that guides the eye.
Tailwind CSS: For the editorial aesthetic and spacing.
Cloud Run: My printing press, keeping everything fast and accessible.

The Editorial Vision

I treated the design like a high-end magazine. Each section is a chapter:

Identity: The "Who" and the mindset.
The Workshop: Skills and tools as a craftsman’s kit.
The Lab: Projects as experiments, not just finished products.
The Lens: Using photography as a reflection of how I observe UI/UX in the real world.

Google AI: The Creative Director

Google AI wasn't a "generator" for me; it was a thinking partner. I used it to:

Refine the Copy: Helping me transition from dry technical descriptions to narrative-driven prose.
Accessibility Review: Ensuring the "story" remains readable for everyone.
Logic Soundboarding: Using AI to brainstorm the best way to structure a chapter-based layout.

The "Director's Cut" (What I'm Proud Of)

Story-Driven Flow: The site feels like a single, continuous conversation.
Intentional Dark Mode: Designed from the ground up to feel like a premium "night-time" reading experience.
The Power of Restraint: Knowing when to stop adding features and start refining the white space.
Photography Integration: My photos aren't just "assets"—they are windows into my perspective as a designer.

Closing Thoughts

This portfolio is my way of proving that engineering is an art form. It’s about more than just shipping code; it’s about crafting experiences that linger.

Thanks for checking it out, and Happy New Year!

Let's connect!

I Rewrote My Media Downloader from Scratch - Here's What I Learned

Nitish — Fri, 31 Oct 2025 07:29:56 +0000

The Problem

It started simple enough - I wanted to download YouTube videos for offline studying. Couldn't stream during power cuts, and mobile data was expensive. So I hacked together a Python script using youtube-dl.

Fast forward a few months, and that "simple script" had become a 2000-line monster with zero documentation, no error handling, and more bugs than features. Friends kept asking me to add Instagram support, then Spotify, then TikTok... and each time I'd just copy-paste code and pray it worked.

It was time for a complete rewrite.

What I Built

Ultimate Media Downloader v2.0.0 - a CLI tool that downloads media from 1000+ platforms with proper architecture, comprehensive docs, and features I actually wish I had from day one.

Key Features

🌐 Universal platform support (YouTube, Spotify, Instagram, TikTok, SoundCloud, Twitter, Facebook, Twitch, Apple Music, and more via yt-dlp)
⚡ Concurrent downloads with resume capability
🎨 Beautiful CLI with progress bars and real-time stats
🔐 Proxy support, SSL/TLS bypass, Cloudflare protection
📦 One-command installation scripts for all platforms
📚 Actually useful documentation (8+ guides with flowcharts)

The Technical Deep Dive

What I Learned

1. Documentation is Not Optional

Writing docs made me realize how confusing my own code was. If I couldn't explain it simply, it was probably too complex. Created:

Architecture overview with Mermaid diagrams
Usage guides with real examples
Contributing guidelines
Troubleshooting FAQ
Command reference

2. Setup Scripts Matter

"Just install these 10 dependencies" doesn't work. Created automated scripts:

# Linux/macOS
./scripts/install.sh

# Windows
scripts\install.bat

One command, everything works. Made onboarding 10x easier.

3. Error Messages Should Be Helpful

Changed from:

Error: Download failed

To:

❌ Download failed for https://example.com/video
   Reason: 403 Forbidden - Video may be private or region-locked

   Suggestions:
   • Check if the video is publicly accessible
   • Try using --cookies for authenticated content
   • Use --proxy if content is region-restricted

   Need help? Open an issue: https://github.com/...

4. Testing Saves Time

Spent 2 weeks writing tests. Saved myself months of debugging later. Every platform has unit tests, integration tests, and edge case coverage.

5. Git Commits Tell a Story

Used conventional commits:

feat: add Instagram story support
fix: handle rate limiting on Spotify
docs: add Mermaid flowcharts for download process
refactor: extract common validation logic

Made it easier to track what changed and why.

Installation & Usage

Quick Start

# Clone and install
git clone https://codeberg.org/nk2552003/umd.git
cd umd
./scripts/install.sh

# Download a video
umd "https://www.youtube.com/watch?v=dQw4w9WgXcQ"

# Download with quality selection
umd --quality 1080p "URL_HERE"

# Download entire playlist
umd --batch "PLAYLIST_URL"

Example Commands

# YouTube video
umd "https://youtube.com/watch?v=VIDEO_ID"

# Spotify playlist (downloads from YouTube)
umd "https://open.spotify.com/playlist/PLAYLIST_ID"

# Instagram reel
umd "https://instagram.com/reel/REEL_ID/"

# TikTok video
umd "https://tiktok.com/@user/video/VIDEO_ID"

# Twitter video
umd "https://twitter.com/user/status/TWEET_ID"

What's Next

Working on:

GUI Interface - Electron or PyQt desktop app
Browser Extension - One-click downloads from any page
Cloud Storage Integration - Direct upload to Drive/Dropbox
Mobile App - React Native companion
REST API - For third-party integrations

Challenges I'm Still Solving

Rate Limiting - Some platforms are aggressive. Need smarter throttling
DRM Content - Can't download DRM-protected media (and shouldn't)
Private Content - Cookie/auth handling is tricky
Live Streams - Quality varies, need better handling

Contributing

The project is open source and I'd love contributions! Whether it's:

Adding new platform support
Improving documentation
Fixing bugs
Adding tests
Suggesting features

Check out the repo: ULTIMATE-MEDIA-DOWNLOADER

Final Thoughts

This rewrite taught me that good software is 20% code and 80% everything else - architecture, documentation, testing, user experience, and maintainability.

If you're thinking about rewriting your project from scratch, my advice:

Don't rush - Take time to plan the architecture
Write docs as you code - Future you will thank present you
Test early - Don't wait until everything breaks
Listen to users - They'll find bugs you never imagined
Iterate - v2.0 won't be perfect, and that's okay

Would love to hear your thoughts, especially if you've gone through similar rewrites. What worked? What didn't?

GitHub: https://codeberg.org/nk2552003/umd.git
Star if you find it useful!
Open to feedback and contributions

The Brew, The Choco, and The Scoop: A Developer’s Tale of Package Managers Across OSs

Nitish — Mon, 18 Aug 2025 03:16:21 +0000

Imagine you’ve just set up a brand-new laptop.

You’re excited, coffee in hand ☕️, ready to code. But before you can write even a single line, you need your toolkit — Git, Node.js, Python, Docker, VS Code.

Now comes the ancient developer’s question:

👉 “Should I download them one by one… or is there a magical tool that installs everything for me?”

That magical tool is called a package manager. And in this article, we’ll walk through the developer-friendly package managers across Windows, macOS, and Linux distros, with a story-like journey and step-by-step guides.

The Origins: Linux, the Old Wise One

Linux has had package managers since forever. That’s why it’s often called the “wise old grandparent” of developer tooling.

Depending on your Linux distro:

Debian/Ubuntu → apt

sudo apt update
sudo apt install git
sudo apt install python3

Fedora/RHEL →dnf

sudo dnf install git
sudo dnf install nodejs

Arch Linux → pacman

sudo pacman -S git
sudo pacman -S docker

With Linux, you’ve always had the comfort of typing a command and watching the system do the rest. But what about Windows and macOS?

Enter Homebrew: The Rebel on macOS

Back in the day, macOS users struggled — you had to click, drag, and install everything manually. Then came Homebrew (or just “brew”), calling itself “the missing package manager for macOS.”

🔧 Installing Homebrew

Open Terminal and paste:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

After installation, you might need to add it to your PATH:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Using Homebrew

Install Git:

brew install git

Install Node.js:

brew install node

Install apps (like Chrome, VS Code):

brew install --cask google-chrome
brew install --cask visual-studio-code

And suddenly, macOS wasn’t behind Linux anymore.

Windows Joins the Party: Chocolatey, Scoop, and WinGet

Windows devs had it the hardest. Download → Next → Next → Finish → Reboot. Repeat × 10.

Then came the heroes:

🍫** Chocolatey (the Classic)**

Chocolatey is like the old guard of Windows package managers — huge library, lots of community support.

Install Chocolatey
Run PowerShell as Administrator:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

Use Chocolatey

choco install git
choco install nodejs
choco install vscode

Scoop (the Minimalist)

Scoop is for devs who don’t like “admin permissions” or clutter. Everything installs in your home folder.

Install Scoop
Run PowerShell (non-admin):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

Use Scoop

scoop install python
scoop install ffmpeg
scoop install docker

WinGet (Microsoft’s Official Knight)

Finally, Microsoft gave Windows an official package manager: WinGet.
It’s already built into Windows 10 (latest) and Windows 11.

Use WinGet

winget install git.git
winget install Microsoft.VisualStudioCode
winget install Google.Chrome

WinGet is slowly catching up with Chocolatey and Scoop, but it’s great because it’s native.

Cross-Platform Heroes

If you’re the kind of dev who works on multiple OSs (like coding on mac, testing on Linux server, gaming on Windows), these tools feel like part of the same story:

Linux: apt, dnf, pacman → the originals
macOS: brew → the rebel
Windows: choco, scoop, winget → the trio of saviors
Package managers save time, clicks, and headaches.
They turn a 2-hour setup into a 10-minute script.
The next time you get a fresh laptop or set up a dev environment, don’t go the “download → next → finish” route. Instead, pick your tool:
Linux → apt, dnf, pacman
macOS → brew
Windows → choco, scoop, winget

And you’ll feel like a magician, installing an entire dev environment with just a few commands.

Why .env and .env.local Files Are Crucial in Modern Development Projects

Nitish — Sun, 03 Aug 2025 03:09:14 +0000

Ever wondered how applications know your API keys, secret tokens, or database credentials without hardcoding them into your code?

That magic comes from environment variables. And in many modern web development projects (especially in Node.js, React, Next.js, etc.), we use .env and .env.local files to store these values.

Let’s break down what these files are, why they’re important, how they’re different, and some best practices to follow!

What is a .env file?

A .env file is a simple text file that stores environment variables in a key-value format.

Example:

DATABASE_URL="postgres://user:password@localhost:5432/mydb"
API_KEY="12345-abcdef"
PORT=3000

These variables can then be accessed inside your app using tools like dotenv in Node.js or automatically in frameworks like Next.js, React, or Vite.

Why is it important?

Here’s why .env files are essential:

Separation of Secrets from Code

You should never hardcode API keys, database URLs, or other secrets into your codebase. .env files let you keep those values separate.

Flexibility across Environments

Whether you're working on development, staging, or production—each environment may need different values.

With .env, you can easily switch between these.

Cleaner Code

Instead of littering your codebase with config values, you reference environment variables like:

const apiKey = process.env.API_KEY;

Version Control Safety

You can (and should!) add .env to your .gitignore file so sensitive data doesn’t get pushed to GitHub.

What about .env.local?

This is where things get a bit more contextual and powerful.

.env.local is commonly used in frameworks like Next.js or Create React App, and is specifically meant for local development only.

It lets you override values in .env or add machine-specific variables that shouldn't be committed to version control.

Example:

.env (committed to git)

API_URL=https://api.production.com

.env.local (not committed to git)

API_URL=http://localhost:4000

In this case, your local machine uses a development server, while production uses the live API.

`.env` vs `.env.local` — What’s the Difference?

Feature	`.env`	`.env.local`
Purpose	Shared base config	Local developer overrides
Should be committed?	Yes	No
Used in production?	Can be	Never
Use case	Default settings	Developer-specific changes

Best Practices

Add .env.local to .gitignore

Your secrets should never be in Git.
Use .env for non-sensitive defaults

E.g., logging level, app name, etc.
Prefix with NEXT_PUBLIC_ in Next.js

Only env vars that begin with NEXT_PUBLIC_ are exposed to the browser:

NEXT_PUBLIC_API_URL=https://my-api.com

Use dotenv or built-in support

Node apps can use the dotenv package:

require('dotenv').config();
console.log(process.env.API_KEY);

Avoid committing secrets

Even in .env, don’t add real passwords or tokens if it will be versioned.

Common Mistakes to Avoid

Hardcoding values:

const apiKey = "123456"; // DON'T DO THIS!

Forgetting to restart dev server after changes

Always restart your dev server when you change env files, or they may not reload.

Thinking .env.local works in production

It’s meant for local development only.

Conclusion

Using .env and .env.local files the right way is one of the simplest but most crucial best practices in modern app development.

They make your app more secure, configurable, and collaborative-friendly across teams and environments.

So next time you spin up a project, make sure your config is where it belongs—not buried inside your code, but safe and flexible inside a .env file!

How to Make Your First Open Source Contribution – The Easy Way!

Nitish — Thu, 31 Jul 2025 03:58:33 +0000

Contributing to open source can feel intimidating when you’re just getting started. But thanks to repositories like First Contributions, your journey into the world of open source can be smooth, guided, and beginner-friendly.

In this article, I’ll walk you through:

Setting up Git and SSH (Windows, macOS, Linux)
Forking and cloning a repository
Making your first pull request (PR)

Let’s dive in!

Step 1: Set Up Git

If you haven’t already, install Git on your machine:

For Windows:

Download and install Git from 👉 https://git-scm.com/downloads
During installation, choose default options unless you have specific preferences.
After install, open Git Bash (or your terminal of choice).

For macOS:

brew install git

For Linux:

sudo apt install git

Now configure Git (same email as your GitHub account):

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Step 2: Generate SSH Key (if not done yet)

SSH lets your computer securely connect to GitHub without typing your username and password each time.

Check if you already have one:

ls -al ~/.ssh

Look for files like id_rsa or id_ed25519.

If not, create one:

ssh-keygen -t ed25519 -C "your_email@example.com"

Press Enter to accept the default file location.
Optionally set a passphrase for more security.

Add the SSH key to your GitHub account:

Copy your SSH key:

cat ~/.ssh/id_ed25519.pub

Copy the entire output.

Go to 👉 GitHub SSH settings, click "New SSH key", give it a title, and paste the key.

Test the connection:

ssh -T git@github.com

If successful, you’ll see:

Hi your-username! You've successfully authenticated.

For Windows Users:

Make sure to use Git Bash or WSL terminal for the above commands.

Step 3: Fork the Repository

Head over to the First Contributions GitHub Repo and click the "Fork" button on the top-right to create a copy of the repo under your GitHub account click on SSH.

Step 4: Clone the Forked Repository

Use SSH to clone your fork locally:

git clone git@github.com:your-username/first-contributions.git
cd first-contributions

Step 5: Create a New Branch

It's good practice to create a separate branch for your changes:

git checkout -b add-your-name

Step 6: Add Your Name

Open the Contributors.md file in your editor and add your name at the end of the list. Example:

- [Your Name](https://github.com/your-username)

Step 7: Commit Your Changes

Stage and commit your changes:

git add Contributors.md
git commit -m "Add Your Name to Contributors list"

Step 8: Push Your Changes

git push origin add-your-name

Step 9: Submit a Pull Request (PR)

Go to your forked repository on GitHub.
Click "Compare & pull request".
Add a descriptive title and comment.
Click "Create pull request".

🎉 That’s it! You just made your first open source contribution! A maintainer will review your PR and merge it once approved.

Bonus: Use Their Interactive Tutorial

Want to try this in the browser without installing Git?

Check out 👉 https://firstcontributions.github.io – an interactive Git tutorial via Gitpod. No setup required!

Final Thoughts

The first-contributions repo is a great place to break the ice in open source. It’s designed to teach, encourage, and guide.

If you’ve made your first PR, congrats! 🥳
Now you’re ready to explore more projects and make meaningful contributions to the tech community.

Feel free to share your first PR or ask questions in the comments below! 👇

Helpful Links

Repo: github.com/firstcontributions/first-contributions
GitHub SSH Guide: docs.github.com/en/authentication/connecting-to-github-with-ssh
Git Handbook: https://guides.github.com/introduction/git-handbook/

Forem: Nitish

GitHub Suspended Me. Turns Out, That Was Fine

Day One: The Screen That Broke My Brain

Shouting Into the GitHub Support Void

The Backwards Move That Actually Worked

Back In, But Not Really Welcome

Fine. Let's Try This Codeberg Thing.

The Actual Migration

Where We're At Now

The Actual Takeaway

PasteShield - an Extension that can save you from deploying the secrets

You've done this. Don't lie. 😅

Meet PasteShield

See it in action

Also catches stuff already in your file

What does it catch? Everything, basicall

Not ready to be blocked? Try silent mode 🤫

For teams

Where it stores your secrets

vs Gitleaks / git-secrets

Install in 10 seconds

What's coming

TL;DR

sidkr222003 / PasteShield

PasteShield intercepts every paste (`Ctrl+V` / `Cmd+V`) in the editor and scans the clipboard content for dangerous patterns — API keys, hardcoded passwords, unsafe JavaScript, prototype pollution, and more — before the text ever reaches your file.

PasteShield

Overview

Why PasteShield vs Gitleaks?

The Quiet Files That Make a Website Trustworthy

TL;DR

Imagine Your Website as a City

1. .well-known: The Official Notice Board

Why It Matters

Quick Tip

2. security.txt: "If You Find a Bug, Contact Me Here"

What Each Line Means

Why It Matters

Common Mistakes

3. pgp-key.txt (Many People Call It a GPG Key): Your Locked Mailbox

How to Generate and Publish Quickly

Important Notes

Why It Matters

4. robots.txt: Traffic Signs for Crawlers

Why It Matters

Important Reminder

5. sitemap.xml: Your SEO Map

Why It Matters

What to Keep in Mind

How these files work together

A short real-world flow

Story from my own setup

Quick Next.js Structure (Copy-Friendly)

Verify in 30 seconds

Beginner Checklist You Can Copy

Final Thought

Building a VS Code Extension — Here's What It Does & Need Your Help

The Problem

What is Dev Toolkit?

File Size Viewer

Console Log Remover

Unused Import Remover

One-Click Project Cleanup

Function Reference Tracker

Code Explainer

Read Time Estimator

Code Style Mood

The Stack

What's Coming Next — And Where You Come In

Why Contribute?

How to Get Started

Links

Forest Ash Theme: 21 Eye-Friendly VS Code Themes Inspired by Anime & Nature

The Origin Story

What's Inside the Box?

Dark Themes (11 total)

Light Themes (10 total)

Why You'll Love It

Design Philosophy

Features That Matter

How to Get Started

1. `.well-known`: The Official Notice Board

2. `security.txt`: "If You Find a Bug, Contact Me Here"

3. `pgp-key.txt` (Many People Call It a GPG Key): Your Locked Mailbox

4. `robots.txt`: Traffic Signs for Crawlers

5. `sitemap.xml`: Your SEO Map