DEV Community: Nitish

Built a Repository for Student Offers

Nitish — Mon, 14 Sep 2026 04:45:44 +0000

As a student, I kept finding useful student offers randomly — sometimes through GitHub, sometimes from a friend, and sometimes from a post I happened to come across.

Free developer tools, AI tools, cloud credits, design software, premium plans, learning platforms… there are actually a lot of benefits available to students.

The problem is that they're scattered everywhere.

So I decided to put them together.

Student Offer Repository

I created an open-source GitHub repository where students can find useful offers, tools, credits, trials, and education plans in one place.

The repository currently contains 200+ listings, including:

Free student and education plans
Developer tools
AI tools and services
Cloud credits
Design and productivity tools
Learning platforms
GitHub Student Developer Pack benefits
Free trials and credits
Region-specific offers
Expired/replaced offers for reference

Not Just a List of Links

One thing I didn't want was another README containing hundreds of links with no context.

For the offers, I've tried to include the details that actually matter before signing up:

Eligibility — Who can claim it?

Region — Is it available globally or only in certain countries?

Verification — Student email, university ID, SheerID, GitHub Education, etc.

Duration — A few months, one year, or while you're a student?

Renewal — Can you renew it after it expires?

Billing — Does it require a card or automatically convert to a paid plan?

And wherever possible, I've included the official source so the information can be verified.

Why I Made It

There are some seriously useful tools available to students that many of us simply don't know about.

You might already be eligible for software or services that would normally cost money.

Instead of searching:

"Does X have a student plan?"

every time I discover a new tool, I wanted a place where I could just search one repository.

And if I'm already collecting this information for myself, I thought it might be useful to other students too.

So I made it public and open source.

It's Community Driven

I definitely won't be able to discover every student offer myself.

That's why contributions are welcome.

If you find:

a new student offer
an expired offer
incorrect eligibility information
a better official source
a country-specific student benefit

you can open an issue or submit a pull request.

The goal is to gradually build a reliable, community-maintained collection that students can actually use.

Check It Out

If you're a student, spend a few minutes browsing through it.

You might discover something you didn't even know you could get for free.

GitHub:

https://github.com/NK2552003/Student-Offer-Repository

If it helps you, consider giving the repository a ⭐.

And if you know an offer that's missing, feel free to contribute.

Still building it. Still adding more.

LLM Fundamentals Every Developer Should Actually Understand

Nitish — Tue, 08 Sep 2026 17:16:33 +0000

If you're building anything with AI right now, you're probably treating the LLM like a magic box: you send text in, text comes out, and when it doesn't work you just... poke it differently and hope. That works up to a point. But there are a handful of underlying mechanics that, once you understand them, completely change how you debug prompts, design agents, and reason about cost and reliability.

I recently went through Matt Pocock's free "LLM Fundamentals" video series on AI Hero, and it's a genuinely great five-lesson crash course on exactly this. Below is my own write-up of the core ideas, partly as notes for myself and partly because I think every dev working with AI APIs should know this stuff cold.

1. Conversations are just a list of messages

Under the hood, a "chat" with an LLM isn't a chat at all — it's an array of messages that gets replayed to the model every single time. Two roles matter most:

User messages — what you send
Assistant messages — what the model sends back

Sitting above all of that is the system prompt: an instruction block at the very start of the history that's usually invisible to the end user but highly visible — and highly obeyed — by the model. If there's a conflict between what the system prompt says and what the user asks for, the model will generally side with the system prompt. This is the whole mechanism behind "custom GPTs," AI coding assistants with personalities, and most jailbreak-resistance efforts (imperfect as they are).

Two more things live inside assistant messages that are easy to overlook:

Reasoning tokens — the "thinking" text some models produce before their final answer. It's not a separate channel; it's just another part of the same message.
File parts — messages can carry more than text. You can attach a PDF for the model to summarize, or get an image back as part of a response.

The upshot: once you think of "the conversation" as a plain array of typed message parts instead of a chat bubble UI, a lot of AI SDK code stops feeling mysterious.

2. Text becomes numbers — and that's all a model actually sees

LLMs don't read words. They read tokens — numbers derived from your text via a process called encoding, and turned back into text via decoding.

The vocabulary of tokens is built by analyzing a huge corpus of text: start with individual characters, find common groupings of characters, then find common groupings of those groupings, until you've built up a vocabulary of a few tens of thousands of "chunks." A bigger vocabulary means common words get compressed into fewer tokens, which is more efficient — a word like "understanding" might take 5 tokens in a small vocabulary but only 2 in a large one.

This is also why unusual or made-up words get chopped up strangely — a nonsense word like "Frabjous" doesn't appear often (or at all) in the training corpus, so the tokenizer has to break it into a surprising number of small fragments instead of recognizing it as a clean chunk.

Why does this matter practically? Because:

You're billed per token, input and output, usually at different rates.
Input tokens include your entire conversation history, your system prompt, and your tool definitions — not just the message you just typed.
Trimming unnecessary output (by asking for concise responses, structured formats, etc.) is a legitimate way to cut cost.

If you want to actually see this happen, the Tiktokenizer playground is a great way to watch text get chopped into tokens live.

3. The context window has a ceiling — and a soft spot

The context window is input tokens + output tokens, combined, and every model has a hard limit on it. Push a conversation past that limit and you'll get an error — sometimes mid-generation, where the model starts a response and simply runs out of room to finish it. The model has no built-in awareness of this limit; it can't gracefully plan around it.

But the harder problem isn't the hard limit — it's what happens well before you hit it: the "lost in the middle" effect. Information near the start and end of a long context gets attended to reasonably well; information buried in the middle gets less attention from the model, and retrieval quality drops accordingly. This gets worse, not better, as context windows get larger.

The practical implication is important: a huge context window is not a green light to dump everything you have into the prompt. A model that supports 1M tokens of context will usually still perform better with a focused 20K-token prompt than a sprawling 500K-token one. Bigger context is a safety net, not an invitation.

4. Tools are just a structured way for the LLM to ask you for things

"Tool calling" (or "function calling") sounds fancier than it is. Here's the whole mechanism:

You describe available tools in the system prompt — a name, a description, and a set of parameters defined via JSON Schema.
The user sends a message, e.g. "write a new file called .gitignore." You don't have to explicitly say "use the writeFile tool" — the model decides for itself which tool fits, if any.
The model responds not with plain text, but with a tool call: a structured message containing an id, the tool name, and the arguments it wants to call it with.
Crucially, nothing has actually happened yet. The model has only produced a message describing what it wants to do. Your application code is responsible for actually executing that action — writing the file, hitting the API, querying the database, whatever the tool represents.
You send a tool result back to the model, referencing the same id, describing what happened (success or failure — error messages need to go back to the model too, so it can adapt).
The model sees the full updated history and responds with a natural-language summary — something like "Done. What should go in there?"

That's it. Tool calling is a request/response loop layered on top of the same plain message array from section 1. This simple loop — describe tools, let the model choose, execute on your machine, report back — is the entire mechanism behind how tools like Claude Code and Cursor read files, run commands, and modify your codebase.

5. Agents vs. workflows: who's driving?

Once you're chaining multiple LLM calls together, you're building either a workflow or an agent — and the difference comes down to one question: who decides when to stop?

Workflow: the developer writes the steps in code. Call the LLM, do something with the result, maybe call it again, then stop — all according to predetermined logic. The control flow lives in your code, not in the model's head.
Agent: you hand the LLM a set of tools and let it decide, turn by turn, what to call next and when it's actually finished. There's no predetermined path — the model improvises its way through the problem.

Neither is strictly better. Agents shine when the steps required to solve a problem aren't knowable in advance and the system needs room to improvise. Workflows shine when the task is well-understood and needs to be done the same reliable way every time — and they're honestly underrated, since "agent" gets all the hype while "workflow" sounds boring by comparison.

A good example of a workflow pattern: splitting a long document into chunks, summarizing each chunk independently and in parallel, then summarizing the summaries. No improvisation needed — just orchestration. That's a workflow doing a job an agent would do less predictably and at higher cost.

Why this actually matters

None of these five ideas are complicated on their own. But together they explain almost every weird failure mode you'll hit building with LLMs:

Model "ignoring" your instructions later in a long chat? Lost in the middle.
API call failing on an otherwise-fine prompt? You blew the context window.
Costs creeping up unexpectedly? Check your tool definitions and conversation history — they're input tokens too.
Model doing something bizarre with an unusual identifier or made-up term? Tokenization artifacts.
Agent looping forever or doing something unpredictable? You probably wanted a workflow.

Full credit to Matt Pocock for putting this together — the original five-part series has diagrams for every concept above and is worth watching directly if you want the visual walkthrough rather than my recap.

What's the LLM quirk that's bitten you the hardest in production? Curious to hear war stories in the comments.

The Twenty-Minute Problem

Nitish — Mon, 27 Jul 2026 13:59:50 +0000

It was a Sunday, and Shreyansh had exactly one job: get a new laptop ready for work by lunch.

He opened a terminal, typed git clone, and watched the repo drop onto his machine. Simple enough. Then came the real work.

npm install — fine, that one runs itself. But then the README asked for a specific Node version, so he opened a version manager and switched. Then it wanted three environment variables, so he dug through an old Slack thread to find them. Then a database needed to exist locally, so he installed it, started the service, and typed out a handful of CREATE TABLE statements from memory because the schema file was buried two folders deep. Then a .env.example file needed copying and renaming — a step so small it was almost insulting, and yet he forgot it twice.

By the time everything ran, it was well past noon. Nothing about the process was hard. It was just long, repetitive, and full of little steps that lived only in his memory or in someone else's head.

That evening, Shreyansh decided the next new laptop would not cost him a morning.

The First Script

He opened a blank file and named it setup.sh. Not because it was clever, but because it was the most boring, obvious name he could pick — anyone opening the project folder would know exactly what it did.

He started small:

#!/bin/bash
npm install

One line. It didn't solve much on its own, but it proved the idea: a script is just a list of commands that a human would normally type one at a time, written down so the computer can type them instead.

Then he added the next annoying step — copying the environment file:

if [ ! -f .env ]; then
  cp .env.example .env
  echo "Created .env — remember to fill in your values"
fi

That if check mattered. He'd learned the hard way, on an older project, that a script which blindly overwrites files is worse than no script at all — it can wipe out someone's real configuration in half a second. A good setup script is polite. It checks before it acts.

Teaching It to Notice Things

The database was the part he dreaded most, so he tackled it next.

if ! command -v postgres &> /dev/null; then
  echo "Postgres not found — installing..."
  brew install postgresql
fi

brew services start postgresql
createdb myapp_dev 2>/dev/null || echo "Database already exists, skipping"

Each line was small, but together they did something bigger: the script could now look at a machine, notice what was missing, and fix only that. It didn't matter if Postgres was already installed — the script would check first and skip the step, the same way a careful person would.

He added the schema next, so a fresh database wasn't just empty but actually usable:

psql myapp_dev -f schema.sql

By the end of the evening, setup.sh was maybe thirty lines long. Not clever, not fancy — just a record of every small decision he used to make by hand, written down once so he'd never have to make them again.

The Second Laptop

Three weeks later, a new teammate joined. Shreyansh sent over the repo and one instruction:

chmod +x setup.sh && ./setup.sh

Eleven minutes later, she messaged back: "It's running. Weirdly satisfying to watch."

No Slack thread. No hunting for a schema file. No forgotten .env copy. The script didn't know anything Shreyansh didn't know — it just remembered it more reliably than he did, and it never got tired of typing the same commands.

That was the real shift. The script wasn't saving time so much as it was saving attention. Every manual step is a place where someone can get distracted, mistype, or skip something without noticing. A script either runs the step or it doesn't — there's no in-between where it "forgot," the way a tired person at 11 AM might.

What the Script Actually Bought Him

Looking back, the thirty lines in setup.sh were doing four separate jobs at once, even though it didn't feel like it while he was writing them:

A record. The script was the real documentation. Not a README that could drift out of date, but something that either worked or loudly didn't.
A safety net. The if checks meant it was safe to run twice, on a clean machine or a messy one, without asking first "wait, will this break anything?"
A shared starting line. Everyone who ran it ended up in the exact same place — same dependencies, same database state, same environment file — instead of five slightly different setups that "mostly" matched.
A found half-day. Multiply eleven minutes by every new machine, every fresh clone, every time someone wiped their laptop and started over. The minutes were small. The total wasn't.

The Part People Skip

Shreyansh almost stopped there, but one more habit made the difference between a script people trusted and one they quietly avoided: he made it talk.

echo "→ Installing dependencies..."
npm install
echo "✓ Dependencies installed"

echo "→ Setting up database..."
createdb myapp_dev 2>/dev/null || echo "  (already exists)"
echo "✓ Database ready"

echo ""
echo "All set. Run 'npm start' to begin."

A script that runs silently for two minutes feels like it might have frozen. A script that narrates itself — even in short, plain lines — feels like it's under control, and so does the person running it. That small bit of feedback was the difference between a teammate watching calmly and a teammate opening a second terminal to check if anything was actually happening.

Build Something I Desperately Needed as a CS Student

Nitish — Thu, 07 May 2026 18:03:04 +0000

Let me be real with you.

Last semester, I was convinced I was putting in solid hours every day. I'd sit down at 10am, open VS Code, and look up at the clock — it'd be 4pm. Six hours. That felt productive.

But when exam season hit and I needed to actually measure what I'd been doing, I had nothing. No data. No proof to myself. Just vibes and a half-finished project.

I tried timer apps. I tried Toggl. I tried writing it down in Obsidian. None of it stuck because the context switch killed me — having to go outside my editor to log a session meant I just... didn't.

And VS Code? VS Code, which I live in for 8+ hours a day, had absolutely nothing built in for this.

No session timer. No focus score. No "hey, you've been idle for 20 minutes, are you still actually working?" No Pomodoro. No history of which projects ate your week. Nothing.

That gap felt absurd to me. So I built something.

Meet FocusForge

FocusForge: Coding Session Tracker — a VS Code extension that turns your editor into a local-first productivity cockpit.

It tracks what actually matters:

Real active time — not just "window open" time. It detects when you're idle and separates it from genuine work time.
Focus Score — a live gauge built from your active ratio, flow minutes, break hygiene, and idle interruptions.
Pomodoro Mode — 25/5/15 defaults, auto-advance, sound, status badges, all native inside VS Code.
Flow State detection — once you've been heads-down for 25 minutes straight, it recognizes that and tracks it separately.
Project analytics — auto-detected from your Git workspace so you know exactly where your hours are going.
Session journal — add a mood, a one-liner about what you worked on, blockers. Perfect for standups.
100+ achievements — because learning to code is hard, and small wins matter.
GitHub Issue integration — log, comment, close issues right from your sidebar.
Weekly reports — Markdown or HTML, saved locally in .vscode/session-reports/.

All of it lives in your VS Code global state. No cloud. No account. No extension-owned backend. Your data is yours.

The Problem VS Code Doesn't Solve (Yet)

Here's what surprised me when I started building this: VS Code is incredibly powerful but treats your time as completely invisible.

You can see which file you're editing. You can see Git blame. You can see lint errors in real time. But it has no concept of:

How long you've been coding today vs. how long you've had the editor open
Whether you're in a flow state or just context-switching every 3 minutes
Which project is actually consuming your week (hint: never the one you think)
How many Pomodoros you completed before you hit burnout
What you were working on last Tuesday when your team asks in standup

For students especially — where there's no manager tracking your hours, no ticket system forcing structure — this invisibility is brutal. You lose entire weeks without realizing it.

FocusForge makes all of that visible.

How It Actually Works

When you open VS Code with FocusForge installed, it starts a session automatically. From there:

The Today tab gives you a live dashboard — active time, idle time, efficiency percentage, current state (active / idle / paused / flow / deep work), a Focus Score gauge with color zones, and a 12-week contribution-style heatmap.

Deep Work Mode is my personal favourite. It's a focused coding block that hides the activity bar, mutes notifications, and gives you a full-screen distraction-free environment with a countdown. When you're studying for a test or pushing to finish a feature before deadline, this mode is the difference.

The History tab shows a 14-session bar chart with clickable detail panels — active time, efficiency, focus score, peak streak, flow time, break counts, commits made during the session, and language breakdown.

The Journal is lightweight on purpose. Just a mood, a one-liner, optional blockers. The weekly view is perfect for async standups and self-reflection.

GitHub Issue Log connects to your local repo automatically. No setup beyond a GitHub token if you want remote repos. You can create, comment, close, and log issue completions — and they'll show up in your weekly report.

Install It

Search FocusForge in the VS Code Extensions tab, or:

ext install NK2552003.focusforge

Or grab it directly from the VS Code Marketplace →

The Soundtrack to Your Flow State 🎧

Here's a feature I didn't plan but ended up loving more than almost anything else in FocusForge.

I was three hours into a debugging session once, headphones in, streaming musicforprogramming.net in a separate tab. The kind of slow, atmospheric, textural music specifically curated for deep coding work — no lyrics, no sudden drops, just long drifting soundscapes that keep your brain in a calm, engaged state.

And then my tab crashed. Lost the music. Lost the flow. Closed my laptop out of frustration.

That's when I discovered isdampe's music-for-programming — a Node.js CLI that streams musicforprogramming.net (and toggleable rain from rainymood.com) directly into your terminal. Beautiful little tool. But it still meant context-switching out of my editor.

So I brought it inside.

FocusForge's Ambient Audio panel streams directly from musicforprogramming.net — 70+ episodes of handpicked coding soundscapes, from drone textures to modular synthesis to field recordings — all playable right from your VS Code sidebar. No browser tab. No Spotify. No notifications from a separate app.

You can:

Browse and play any episode from the musicforprogramming.net catalogue
Toggle rain overlay on/off (yes, rain + ambient music is genuinely incredible for focus)
Set volume independently
Auto-start audio when a session begins
Audio pauses automatically when you go idle — resumes when you're back

The pausing-on-idle part is what makes it feel intentional. The music isn't just background noise — it's tied to your actual work state. When you're in flow, it plays. When you drift away, it quietly stops. When you return, it picks back up. It mirrors your focus in a way that nothing else does.

Huge credit to isdampe for the original music-for-programming repo that inspired this, and to the team at musicforprogramming.net for building one of the most genuinely useful resources for developers that almost nobody talks about.

Why I'm Sharing This

I've seen a lot of "I built a thing" posts where the tool is clearly built for a portfolio and never used by anyone including the author. That's not this.

I use FocusForge starting today as i published it now. I think it will change on how I think about my sessions. The journal alone has saved me in standup conversations more times than I can count.

If you're a student grinding through projects, a developer freelancing without a time-tracking system, or just someone who wants to know where their coding hours actually go — this was built for you.

Go forge something.

Built with TypeScript, VS Code Extension API, and a lot of late-night sessions that FocusForge dutifully tracked.

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!

DEV Community: Nitish

Built a Repository for Student Offers

Student Offer Repository

Not Just a List of Links

Why I Made It

It's Community Driven

Check It Out

LLM Fundamentals Every Developer Should Actually Understand

1. Conversations are just a list of messages

2. Text becomes numbers — and that's all a model actually sees

3. The context window has a ceiling — and a soft spot

4. Tools are just a structured way for the LLM to ask you for things

5. Agents vs. workflows: who's driving?

Why this actually matters

The Twenty-Minute Problem

The First Script

Teaching It to Notice Things

The Second Laptop

What the Script Actually Bought Him

The Part People Skip

Build Something I Desperately Needed as a CS Student

Meet FocusForge

The Problem VS Code Doesn't Solve (Yet)

How It Actually Works

Install It

The Soundtrack to Your Flow State 🎧

Why I'm Sharing This

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

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