DEV Community: Shuvo

My friend's Game Boy got stolen so I built him one

Shuvo — Sat, 03 Oct 2026 06:45:29 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

My friend's Game Boy Color got stolen. Rude. Then he went looking for a replacement and found out that decent used ones are now rare, overpriced, or "mint condition" in the way that means "mint-flavored lie."

So I built him a new one that can't be stolen: a Game Boy Color in the browser. It's teal, it has a D-pad that clicks, and it plays real Game Boy games.

The twist is that he never has to scroll through a ROM list. He just tells it what he's in the mood for:

"I want to play a game involving Pokémon."

A small AI reads the request, picks a game from the collection, and boots it. He can type the request or tap the mic and say it out loud. A bit like a game store clerk who lives inside the console.

Demo

Code

0shuvo0 / Game-boy-color-emulator

Browser-based Gameboy Color Emulator with AI game search capabilities using Google gemma 4b

Browser-based Gameboy Color Emulator

with AI game search capabilities using Google gemma 4b

Note: For the AI feature to work you need to have https://ollama.com/library/gemma3:4b installed and running on your machine.

in the package.json file there is a script called "start:ai" which will start the ollama server.

View on GitHub

How I Built It

Emulator: The mGBA core compiled to WebAssembly, wired up in a Vite + TypeScript project. It loads ROMs straight from public/gameroms, including ones packed inside ZIP files.
Controls: Keyboard (Z/X/Enter/Shift), touch buttons on the on-screen console, and gamepad support.
The AI picker: Gemma 3 (4B), running locally through Ollama. When he makes a request, the app sends it along with the list of available games. Gemma picks the best match and the emulator loads it.
Voice: The browser's built-in speech recognition fills in the prompt and submits it when he stops talking. It's not an AI model, but it makes the whole thing feel like magic.
Escape hatch: If he knows what he wants, "Choose a game instead" opens a normal list.

The prompt is simple: "here's what the player wants, here's the game list, pick one." The game list is just a file (src/games.ts), so adding a game means dropping a ROM in a folder and adding its name.

Why Does Open Innovation Matter?

This project needed an AI that could do one small job well: match a vibe to a filename. A giant cloud model would be overkill, and a cloud API would have made it worse in a few ways:

It costs nothing. No API key, no per-request bill, no "you've hit your limit" while someone is trying to play Pokémon. For a gift to a friend, that matters.
It runs locally. His requests never leave the machine. Nobody needs to know what he plays at 2 AM.
It's swappable. Gemma 3 4B was small and fast enough. If a different model picks better, it's one line to change.
It doesn't break on me. No deprecation emails, no pricing changes, no surprise outages. The model is on the disk, and it stays there.

A 4B open model on a normal machine turned out to be plenty for this. It does the job without anyone's permission or a credit card.

Prize Categories

Best Use of Gemma: Gemma 3 (4B) running locally through Ollama powers the natural-language game picker.

Hacktoberfest 2026, what changed?

Shuvo — Thu, 01 Oct 2026 04:06:27 +0000

Hacktoberfest 2026 Is Not What You Remember (And That's Actually Good News)

Last updated: October 1, 2026

If you've done Hacktoberfest before, you probably remember the drill: open four pull requests, wait for the merge notifications, and wear your free T-shirt with quiet pride.

Forget all of that. Pull requests no longer count toward Hacktoberfest rewards. The whole event has been rebuilt from the ground up, and this year it's about learning and building with open-source AI.

Don't close the tab yet. The new version is free, open to beginners, and has more ways to earn swag than the old one did. This guide walks through what changed, why, and exactly how to take part, online or in person.

The 60-second version

Pull requests are out. Neither PRs nor merge requests count toward rewards anymore.
The theme is open-source AI. The tagline is "AI belongs to everyone," and the focus is open-weight models, agents, and the tools around them.
There are two ways to join: 300+ one-day in-person events called Fests, and an online program with livestreams, challenges, and a week-long event.
Rewards run on stickers. You earn virtual stickers for activities, and real stickers get mailed to you once you collect enough.
It's free, and you need to be 13 or older.
MLH and DEV run it now, with DigitalOcean (the original creator) as presenting partner.

Old vs. new: what actually changed

	The old Hacktoberfest (2014-2025)	Hacktoberfest 2026
Core task	Open 4 pull requests on participating repos	Learn and build with open-source AI
How progress is measured	PR count	Virtual stickers from activities
Main format	Online, solo, on GitHub	300+ in-person Fests plus an online program
Reward	T-shirt (or a tree planted, in some years)	Sticker pack by mail, with extra tiers up to a raffle
Who runs it	DigitalOcean	MLH and DEV, with DigitalOcean presenting
Open-source contributions	The entire point	Still welcome, just not rewarded
Community element	Mostly social media and Discord	Real events in real cities
T-shirt	The headline prize	Only at Fests, while supplies last, not guaranteed

A small correction to a common memory: older editions let you contribute to any public repo that opted in, not just a short curated list. The 2026 change is bigger than swapping the list. The counter itself is gone.

Why they changed it

Short answer: the spam got out of hand.

The organizers say it's now easier than ever to churn out low-effort pull requests, and maintainers kept paying the price in review time and burnout. Their own history page describes the 2015-2025 era as one where thousands of people made a first contribution, but the flood of low-quality PRs eventually became too much for the people on the receiving end.

So rather than patching the rules again, they dropped the incentive. The mission page puts it simply: open source was never defined by a PR counter, and this year they'd rather help people learn to build with open models and tools.

You can agree or disagree with the call. But the reasoning is easy to follow, and anyone who has ever maintained a popular repo in October will probably nod along.

Meet the new cast: MLH, DEV, and DigitalOcean

Major League Hacking (MLH) runs the Fests and the sign-in system (MyMLH).
DEV runs the online challenges and hands out badges.
DigitalOcean started Hacktoberfest in 2014 and is still on board as presenting partner.
A long sponsor list backs the swag and events, including GitHub, MongoDB, Snowflake, Google Cloud, IBM, Qualcomm, Arduino, and many others.

Two ways to take part

You can do either one, or both. They stack.

Path 1: Go to a Fest (in person)

A Fest is a free, one-day, locally organized event. Almost all of them are free, though a few pop-ups happen inside ticketed conferences. There are two flavors:

	Hack Day	Meetup
Vibe	Mini hackathon	Community hangout
What you do	Build a project with open-weight models or open-source AI tools, then demo it	Talks, workshops, panels, and meeting people
Team?	Solo or any team size (prizes cover up to four members)	No team needed
Prizes	Yes, usually a swag bag	No
Bring	Laptop and charger	Curiosity, plus a laptop only if the host asks

A few things worth knowing:

Beginners are welcome. You don't need to build an AI project to attend a Meetup.
Everyone on a team must register and check in. One person submits the project.
Projects must be finished and submitted on the day, before the host's deadline.
Every in-person attendee gets an official participation certificate, available in your My Hacktoberfest dashboard.
Swag varies by Fest. T-shirts and other goodies are limited and not guaranteed. The local host decides how to hand them out. Select Hack Days also have Arduino boards available while supplies last.

How to join a Fest:

Open Find a Fest and search by city, country, or name (or use your location).
Open the Fest's page and read the details: date, venue, food, accessibility, and what to install or bring.
Register on that Fest's own page with a free MyMLH account. Every Fest has a separate registration.
Show up, check in with the host, and say hi to a stranger.
Use the Contact Host button on the page for anything about logistics, accommodations, or late arrival.

Path 2: Join online (from anywhere)

The online program runs all month and has three main pieces:

Livestreams. Sessions on open-weight models, agents, and tools. You check in with a code shown on screen to collect a sticker.
DEV Challenges. A weekend kickoff challenge plus four weekly open-source AI rounds, all labeled as cash-prize challenges.
Global Hack Week: Hacktoberfest. A week-long virtual festival of livestreams and challenges, run by MLH.

Here are the dates as listed on DEV's challenge hub and in community guides. Always double-check the deadline printed on each official challenge page, because that's the one that counts.

Activity	Dates (UTC, as reported)
Weekend Challenge	Oct 2 (02:00) to Oct 5 (06:59)
Open-Source AI Challenge, Week 1	Oct 5 to Oct 11
Global Hack Week	Oct 9 to Oct 15
Open-Source AI Challenge, Week 2	Oct 12 to Oct 18
Open-Source AI Challenge, Week 3	Oct 19 to Oct 25
Open-Source AI Challenge, Week 4	Oct 26 to Oct 31

The full online calendar lives on the official schedule page and shows times in your own time zone.

Heads up: the exact prize amounts and the actual challenge prompts weren't public when I researched this. The prompts are revealed when each challenge launches, so don't start building a "winning entry" before you've read the real brief. Challenge announcements go out under DEV's #hf26challenge tag.

The sticker system, explained

This is the new reward engine, and it's friendlier than it sounds.

There are 24 virtual stickers in total: 22 you can earn online, plus 2 you earn in person (attend a Fest, or host one). Each one is tied to an activity.

The reward tiers

Stickers collected	What you get
3	A real, mailed Hacktoberfest 2026 sticker pack
10	A bonus holographic sticker added to your pack
17	Completionist status, plus automatic entry into a raffle for a Hacktoberfest 2026 T-shirt or an Arduino Uno Q board

Two stickers are required before anything ships: signing in to Hacktoberfest.com, and adding your mailing address to your MyMLH account. Do those first. They also count toward your total, so you're already two-thirds of the way to the first reward after five minutes.

Where the rest come from

Category	Examples of what earns a sticker
Livestreams	Check into 1, 3, or 5 livestreams, or the launch livestream
DEV Challenges	Connect your DEV account, then submit to the Launch Weekend and Weeks 1 to 4 challenges
Global Hack Week	Complete registration challenges, check into a session, and hit 15, 30, or 75 points
Tools	Install and log in to DevRelay, join the MLH Community Discord, connect your DigitalOcean account
Surveys	Fill out the pre-event and post-event surveys
In person	Attend a Fest, or host one

The full, up-to-date list is on the Activities page, and your personal progress lives in My Hacktoberfest.

Good to know about swag

Online participants don't get T-shirts. Those are a Fest thing, and even there they aren't guaranteed. Completionists can still win one in the raffle.
Mailing takes a while. The main site says stickers and prizes go out 8 to 12 weeks after Hacktoberfest ends, while the FAQ says packs should arrive at most destinations within 30 to 60 days of shipping starting. Plan for a wait either way.
Activity done early still counts. The FAQ says eligible activity completed before milestones were announced is credited.
Signing in alone won't earn you a pack. You need to do at least a few activities.

Your quick-start checklist

If you only do one section of this article, make it this one.

Today (5 to 10 minutes):

Sign in at My Hacktoberfest with a free MyMLH account.
Add your mailing address to MyMLH.
Connect your DEV account (optional, but it earns a sticker and a DEV badge, and it's needed for DEV Challenges credit).
Join the MLH Community Discord.

This week:

Register for Global Hack Week: Hacktoberfest, which is free.
Follow each DEV Hacktoberfest challenge so you get launch notifications.
Check the schedule and mark a few livestreams.
Look up Fests near you and register if one fits.

All month:

Check into livestreams and submit to challenges as they open.
Fill out the pre-event survey early and the post-event survey at the end.

What should you build? Ideas to get started

The official line is that instead of counting PRs, you'll write your first skills.md, build an open-source agent, fine-tune an open-weight model, or follow your curiosity. Here are some starter ideas by difficulty.

Beginner-friendly

A reusable agent skill: a folder with a SKILL.md, a README, a license, and a couple of examples.
A small local chatbot running an open-weight model through a local runtime such as Ollama or llama.cpp.
A tiny evaluation script that checks whether a model gives consistent answers to the same prompt.

Intermediate

A small open-source agent that combines a local model, a few tools (files, APIs, MCP servers), and simple memory.
A CPU-friendly fine-tuning experiment using Hugging Face's PEFT or TRL. Keep it small. A tiny project that works beats a giant one that doesn't.
A tool-call correctness test suite or prompt regression tests.

Ambitious

Improve an open-source agent harness or SDK: better error messages, safer permissions, clearer setup on Windows, macOS, or Linux.
Build an evaluation dashboard that compares open-weight models side by side.

A good project checklist before you submit anything: what real problem does it solve, which license applies, which model and under what terms, can someone else run it without hidden steps, is there a short demo or screenshot, and are the limitations written down.

But I still want to contribute to open source!

You absolutely can, and nobody is stopping you. The organizers say outright that open source runs 365 days a year and that you can contribute anytime. They just aren't giving swag for it anymore. They point newcomers to this beginner's guide to getting started.

If you're going to send a PR this October, here's how to be the kind of contributor maintainers love:

Read CONTRIBUTING.md first. Some projects require you to be assigned the issue, get design approval, sign a CLA, or follow an AI-disclosure policy.
Check that the issue is still open and unclaimed, with no competing PR.
Reproduce the problem yourself. A fix without a reproduction is a guess.
Keep the change small and focused, and add a test that fails before your fix and passes after it.
Be honest about AI help. Many repos now ask for disclosure. Never submit code you can't explain or test.
Say what you're about to do before writing a lot of code. A short comment like "I reproduced this, here's my plan, anyone already on it?" saves everyone time.

Where to look

Hacktoberfest has no official participating-repo list this year. These are active projects in the open-AI orbit that have accepted outside contributions. Treat them as places to browse, not guaranteed openings, since issues get claimed quickly.

MCP TypeScript SDK and MCP Python SDK
Hugging Face PEFT and TRL
Giskard (AI evaluation)
MDN content (documentation, with low setup cost)
Browser Use
FastMCP

A smaller, well-scoped issue in a project with a clear guide is almost always a better bet than a big feature nobody has approved.

Want to host a Fest?

Anyone can. If your city has no Fest yet, it could be you.

	Hack Day	Meetup
Attendees build projects	Yes	No
Workshops and speakers	Yes	Optional
Prizes	Yes	No
MLH funding	Yes	No

Applications are open and are confirmed on a rolling basis, within about a week of a completed application.
Hosts get stickers, swag, and prizes for participants, a listing in the searchable directory, programming help, and (for Hack Days) funding with reimbursement for certain event expenses.
Start here: Host a Fest, then read the host handbook.
Hosting also earns you a sticker and a DEV badge.

FAQ

Do pull requests count at all?
No. They don't count toward rewards, and the organizers say that's deliberate.

Can I still get a T-shirt?
Maybe, but only at a Fest while supplies last (the host decides), or through the Completionist raffle if you hit 17 stickers. Online participants aren't promised one.

Who can join?
People aged 13 and over, subject to country eligibility rules. Individual Fests can have their own age limits, and if you're under 18 you should ask the host about parental permission. DEV Challenges have separate contest eligibility rules.

Is it free?
Yes, including nearly all Fests and Global Hack Week.

Do I need to build an AI project to take part?
No. You can watch livestreams, attend a Meetup, join the Discord, and do surveys. Those all count toward stickers.

Do I need a GPU?
Not for everything. Plenty of beginner-friendly work (documentation, SDK bugs, evaluation tools, small fine-tuning experiments) runs fine on a laptop CPU.

Who do I contact with problems?
Use Contact Host on a Fest's page for event questions, the relevant challenge page for DEV Challenge questions, and the support emails listed on the official FAQ for swag, prizes, or safety concerns.

Final thoughts

It's okay to feel a little nostalgic. The four-PR challenge got a lot of people into open source, and it's strange to see it retired.

But the new format has a lot going for it. Maintainers get a break from the spam. Beginners get real events and a clear, low-stakes path to a reward. And if you've been meaning to try out open-weight models or build your first agent, October now comes with a built-in excuse, a community, and stickers.

So sign in, add your address, grab those first two stickers, and see where the month takes you.

Sources and further reading

You Can't Even Make an AI Wrapper Chat App 😆🫵

Shuvo — Fri, 05 Jun 2026 05:48:23 +0000

"It's just a fetch call, bro." — Every junior dev, moments before learning a hard lesson.

So you want to build a ChatGPT wrapper. Fair enough. It sounds embarrassingly simple — you've got an API key, a text box, and ambition. How hard can it be?

Turns out: pretty hard. Not rocket science hard, but "oh god why is my chat broken on refresh" hard.

Let's walk through the three stages of enlightenment.

🟢 Stage 1: The Junior Dev Move

"Ship it. It works on my machine."

The junior dev opens a blank React project, installs axios (or doesn't, and just uses fetch), and writes something like this:

Frontend:

const res = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify({ msg: input })
});
const { result } = await res.json();
setReply(result);

Backend:

app.post('/api/chat', async (req, res) => {
  const result = await ai.chat(req.body.msg);
  res.json({ result });
});

Done. Deployed. LinkedIn post drafted.

The problem? You're waiting for the entire AI response to generate before anything shows up on screen. For a short reply, fine. For a longer one? You're staring at a blank screen for 10–15 seconds while your users quietly close the tab.

It feels like dial-up internet. In 2025.

🟡 Stage 2: The Mid-Level Dev Move

"I've heard of this 'streaming' thing."

The mid-level dev has seen the ChatGPT UI. Tokens appear one by one, like the AI is thinking. That's streaming — and it's a vastly better experience.

Backend:

app.post('/api/chat', async (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  const stream = await ai.chat.stream(req.body.msg);

  for await (const chunk of stream) {
    res.write(`data: ${chunk.text}\n\n`);
  }
  res.end();
});

Frontend:

const response = await fetch('/api/chat', { method: 'POST', body: ... });
const reader = response.body.getReader();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  setReply(prev => prev + decode(value));
}

Now tokens stream in real-time. The app feels alive. Users are happy. You are happy.

The problem? Hit refresh.

Gone. All of it. Every conversation, vanished. The app has the memory of a goldfish. Each new page load is a blank slate — no history, no context, no continuity.

You've built a chat app that forgets you exist the moment you leave. That's not a chat app. That's a very expensive alert() box.

🔴 Stage 3: The Senior Dev Move

"Streaming is table stakes. Persistence is the real work."

The senior dev knows that a chat app without history isn't a product — it's a demo. Real users expect to close the tab, come back tomorrow, and pick up where they left off. They expect their conversation to exist.

This means the stream itself needs to be saved as it arrives — not after it's done, not on the next request, but token by token, persisted to a database in real time.

Backend — save while streaming:

app.post('/api/chat', async (req, res) => {
  const { conversationId, msg } = req.body;

  // Save user message immediately
  await db.messages.insert({ conversationId, role: 'user', content: msg });

  res.setHeader('Content-Type', 'text/event-stream');
  const stream = await ai.chat.stream(msg);
  let fullResponse = '';

  for await (const chunk of stream) {
    fullResponse += chunk.text;
    res.write(`data: ${chunk.text}\n\n`);
  }

  // Save complete assistant response after stream finishes
  await db.messages.insert({ conversationId, role: 'assistant', content: fullResponse });
  res.end();
});

Frontend — load history on mount:

useEffect(() => {
  const history = await fetch(`/api/conversations/${id}/messages`);
  setMessages(await history.json());
}, [id]);

Now when a user refreshes? Their chat is still there. When they come back on mobile? Still there. When they share a conversation link? You get the idea.

But wait, there's more. The senior dev also thinks about:

Sending the full conversation history back to the AI (so it has actual context)
Handling mid-stream disconnects gracefully (what if the user closes the tab at 50%?)
Debouncing saves so you're not hammering your DB on every single token
Auth, so users only see their conversations

None of this is glamorous. It's just... what production looks like.

The Takeaway

Level	What they build	What's missing
Junior	Request → Response	Speed, UX
Mid	Streaming response	Persistence
Senior	Streaming + saved history	(probably something else they'll discover next week)

The gap between a junior and senior implementation isn't really about the AI part at all — the API call is the easy bit. It's about treating the surrounding infrastructure with the same seriousness as the feature itself.

So next time someone says "I built an AI chat app over the weekend" — ask them what happens when they refresh the page.

The silence will tell you everything.

Now go add persistence to your side project. You know who you are.

Before AI we had ...

Shuvo — Fri, 22 May 2026 04:12:37 +0000

Nowadays you will hear a lot of people saying Why should I hire a software developer when I can vibecode it my self with about $100 worth of AI tools?

Well they aren't wrong about that!

But getting an app made and running was never the hard part. Before AI or vibe coding we had platforms like Fiverr/UpWork where people could just pay a third world country developer $50-$100 to build them their app.

So getting a working APP or at least MVP was never really very hard or expensive rather its the distribution part that kills 99% of the apps.

And for handling complex apps or codebases cheap developers were not reliable then, AI tools are not reliable now!

Frontend rate limiting can save you $10,000

Shuvo — Thu, 21 May 2026 04:04:07 +0000

Fastest Requests Are the Ones You Never Make

While backend rate limiting is absolutely crucial, it comes at a cost.

For backend rate limiting, we usually store a user's IP and request timestamps in memory or a Redis database. If your app has millions of users, you end up storing a lot of data in memory or a database — and that can get expensive fast.

But what if we block requests before they ever leave the browser/client? By handling rate limiting on the client side, we can save a significant number of unnecessary request and read/write operations on the backend. Depending on how many users your app has, this can translate to anywhere between hundreds to thousands of dollars saved per year.

1: Basic frontend rate limiter example:

// utils/rate-limiter.ts

const MAX_REQUESTS = 50;           // Maximum number of requests allowed
const TIME_WINDOW = 60 * 1000;    // Time window in milliseconds (1 minute)

// Store timestamps of recent requests
let requestTimestamps: number[] = [];

// Check if a new request is within the allowed limit
function canMakeRequest(): boolean {
    const currentTime = Date.now();

    // Remove timestamps that have fallen outside the time window
    requestTimestamps = requestTimestamps.filter(
        timestamp => currentTime - timestamp < TIME_WINDOW
    );

    return requestTimestamps.length < MAX_REQUESTS;
}

// Drop-in fetch wrapper with rate limiting
function $fetch(url: string, options?: RequestInit): Promise<Response> {
    if (!canMakeRequest()) {
        return Promise.reject(new Error('Rate limit exceeded. Please try again later.'));
    }

    requestTimestamps.push(Date.now());
    return fetch(url, options);
}

export default $fetch;

2. Better rate limiter with cooldown time and localstorage implementation so user can't just reset limit by refreshing the page

// Front end rate limiter
// Max number of requests allowed per time window
const MAX_REQUESTS = 50; // Maximum number of requests allowed
const TIME_WINDOW = 60 * 1000; // Time window in milliseconds (e.g., 1 minute)
const COOLDOWN_TIME = 30 * 1000; // Time to wait after hitting the rate limit before requests are allowed again

// localStorage keys for persisting state across page refreshes
const STORAGE_KEY_TIMESTAMPS = 'rate_limiter_timestamps';
const STORAGE_KEY_COOLDOWN = 'rate_limiter_cooldown_until';

// --- localStorage helpers ---

// Load request timestamps from localStorage, falling back to an empty array
function loadTimestamps(): number[] {
    try {
        const stored = localStorage.getItem(STORAGE_KEY_TIMESTAMPS);
        return stored ? JSON.parse(stored) : [];
    } catch {
        return [];
    }
}

// Persist the current timestamps array to localStorage
function saveTimestamps(timestamps: number[]): void {
    try {
        localStorage.setItem(STORAGE_KEY_TIMESTAMPS, JSON.stringify(timestamps));
    } catch {
        // Silently fail if localStorage is unavailable (e.g. private browsing restrictions)
    }
}

// Load the cooldown expiry timestamp (ms since epoch), or 0 if none is set
function loadCooldownUntil(): number {
    try {
        return Number(localStorage.getItem(STORAGE_KEY_COOLDOWN) ?? 0);
    } catch {
        return 0;
    }
}

// Persist the cooldown expiry timestamp to localStorage
function saveCooldownUntil(until: number): void {
    try {
        localStorage.setItem(STORAGE_KEY_COOLDOWN, String(until));
    } catch {
        // Silently fail if localStorage is unavailable
    }
}

// --- Core rate-limit logic ---

// Function to check if a request can be made
function canMakeRequest(): boolean {
    const currentTime = Date.now();

    // If an active cooldown exists, block all requests until it expires
    const cooldownUntil = loadCooldownUntil();
    if (cooldownUntil && currentTime < cooldownUntil) {
        return false;
    }

    // Load persisted timestamps so a page refresh doesn't reset the counter
    let requestTimestamps = loadTimestamps();

    // Remove timestamps that are outside the time window
    requestTimestamps = requestTimestamps.filter(
        timestamp => currentTime - timestamp < TIME_WINDOW
    );

    // Persist the cleaned-up timestamps
    saveTimestamps(requestTimestamps);

    // Check if the number of requests in the time window is less than the maximum allowed
    return requestTimestamps.length < MAX_REQUESTS;
}

// Function to make a request
function $fetch(url: string, options?: RequestInit): Promise<Response> {
    if (!canMakeRequest()) {
        // Inform the caller how long (in seconds) they need to wait
        const remaining = Math.ceil((loadCooldownUntil() - Date.now()) / 1000);
        return Promise.reject(
            new Error(`Rate limit exceeded. Please try again in ${remaining}s.`)
        );
    }

    const currentTime = Date.now();

    // Load, update, and persist timestamps before making the request
    const requestTimestamps = loadTimestamps();
    requestTimestamps.push(currentTime);
    saveTimestamps(requestTimestamps);

    // If this request tips us over the limit, start a cooldown period.
    // The cooldown begins NOW and lasts COOLDOWN_TIME ms, after which
    // canMakeRequest() will unblock and the sliding window will have cleared.
    if (requestTimestamps.length >= MAX_REQUESTS) {
        saveCooldownUntil(currentTime + COOLDOWN_TIME);
    }

    // Make the actual fetch request
    return fetch(url, options);
}

export { $fetch };

Whenever you need to make a request to the backend, just use $fetch instead of the native fetch:

// example usage
import $fetch from 'utils/rate-limiter';

try {
    const data = await $fetch('/api/get-data', {
        method: 'POST',
        body: JSON.stringify({ key: 'value' })
    });
} catch (error) {
    console.error(error.message);
}

⚠️ Warning: This will prevent the vast majority of users from flooding your backend, but a determined minority and AI bots may attempt to bypass client-side checks entirely. Backend rate limiting must still be in place as your true line of defense. Think of frontend rate limiting as an optimization layer, not a security layer.

When to Use Frontend Rate Limiting

Your app has a high volume of users and you want to reduce unnecessary backend load
The endpoint being called is expensive (e.g., hits a third-party API, runs a heavy DB query)
You want to improve UX by giving users instant feedback instead of waiting for a backend 429 response
You want to reduce cloud costs on services that charge per request or per DB operation

When Not to Use Frontend Rate Limiting

As a replacement for backend rate limiting — it is never a substitute
For protecting sensitive or security-critical endpoints (authentication, payments, etc.)
When your users are primarily API consumers or developers who interact directly with your backend
When the client environment is untrusted (e.g., mobile apps that can be reverse-engineered or patched)
When accurate rate limiting is a hard requirement — client-side state can be reset simply by refreshing the page

Your trycatch sucks - lets fix it

Shuvo — Thu, 21 May 2026 03:19:50 +0000

You're not handling errors. You're hiding them.

Every app crashes. Every API fails. Every database hiccups at 2am on a Friday.
The difference between a good dev and a great one? What happens next.

Let's roast your error handling — then make it legendary.

🤦 Level 0: The "Trust Me Bro" Dev

No try/catch at all. Just vibes.

const data = await fetchUserData(userId);
console.log(data.profile.name); // 💥 TypeError: Cannot read properties of undefined

The crime: One bad response nukes the entire app. Users see a white screen. You get a 3am Slack ping.

🐣 Level 1: The Junior — "I Googled try/catch"

try {
  const data = await fetchUserData(userId);
  setUser(data);
} catch (err) {
  console.log(err); // 👈 and... that's it. shipped.
}

What's wrong here?

console.log in production helps nobody — users still see a broken UI
No distinction between a 404 and a 500 — every error is treated the same
The error disappears into the void (or a DevTools tab nobody has open)
err might be null, a string, or an Error object — you're not checking

The mindset: "At least it won't crash." — Yeah, it just silently breaks instead. Cool.

📈 Level 2: The Mid-Level — "I've Been Burned Before"

Now we're thinking. You've seen production fires. You have trust issues with APIs. Good.

2a — Typed errors, real messages

try {
  const data = await fetchUserData(userId);
  setUser(data);
} catch (err) {
  if (err instanceof NetworkError) {
    showToast("Connection lost. Check your internet.", "warning");
  } else if (err.status === 404) {
    showToast("User not found.", "error");
  } else {
    showToast("Something went wrong. We're on it.", "error");
    logger.error("[fetchUserData]", { userId, err }); // 👈 goes to Sentry/Datadog
  }
}

✅ Users get useful feedback, not a frozen screen
✅ Engineers get structured logs, not a haystack of console.logs

2b — Undo previous operations (the "atomic mindset")

Imagine you're updating a user's profile and their avatar. Step 1 succeeds. Step 2 fails.
Congrats — your user now has a corrupted half-state.

let previousProfile = null;

try {
  previousProfile = await getProfile(userId); // snapshot
  await updateProfile(userId, newProfileData); // step 1
  await uploadAvatar(userId, newAvatar);        // step 2 💥 fails here
} catch (err) {
  logger.error("Profile update failed", { err });

  // ↩️ Roll back step 1 since step 2 failed
  if (previousProfile) {
    await updateProfile(userId, previousProfile);
  }

  showToast("Update failed. Your profile has been restored.", "warning");
}

✅ Users never see broken half-state
✅ Rollback is explicit, not accidental

2c — Wrap it in a clean utility (stop repeating yourself)

Tired of writing try/catch 50 times? Make a helper:

// utils/tryCatch.js
export async function tryCatch(fn, fallback = null) {
  try {
    const result = await fn();
    return [result, null];
  } catch (err) {
    return [fallback, err];
  }
}

// Usage — clean, flat, readable
const [user, err] = await tryCatch(() => fetchUserData(userId));

if (err) {
  showToast("Couldn't load user.", "error");
  return;
}

setUser(user);

✅ No more deeply nested try/catch pyramids
✅ Forces you to handle the error at call site — can't ignore it

🧠 Level 3: The Senior — "I've Seen Things"

You don't just catch errors. You anticipate them. You build systems that heal themselves.

3a — Retry queue with exponential backoff

Networks are flaky. Don't give up on the first failure.

async function fetchWithRetry(fn, { retries = 3, delay = 500 } = {}) {
  for (let attempt = 1; attempt <= retries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const isLast = attempt === retries;
      const isRetryable = err.status >= 500 || err instanceof NetworkError;

      if (isLast || !isRetryable) throw err; // don't retry 401s or 404s

      const backoff = delay * 2 ** (attempt - 1); // 500ms → 1s → 2s
      logger.warn(`Attempt ${attempt} failed. Retrying in ${backoff}ms...`);
      await sleep(backoff);
    }
  }
}

// Usage
const data = await fetchWithRetry(() => fetchUserData(userId));

✅ Temporary blips are invisible to users
✅ Smart: retries server errors, not client errors (no point retrying a 401)

3b — Circuit breaker (stop hammering a dead service)

A retry queue is great — unless the whole service is down. Then you're just DDoS-ing a corpse.

class CircuitBreaker {
  constructor(threshold = 5, timeout = 30_000) {
    this.failures = 0;
    this.threshold = threshold;
    this.timeout = timeout;
    this.state = "CLOSED"; // CLOSED = healthy, OPEN = tripped, HALF_OPEN = testing
    this.nextAttempt = Date.now();
  }

  async call(fn) {
    if (this.state === "OPEN") {
      if (Date.now() < this.nextAttempt) {
        throw new Error("Circuit open — service unavailable");
      }
      this.state = "HALF_OPEN";
    }

    try {
      const result = await fn();
      this.reset();
      return result;
    } catch (err) {
      this.recordFailure();
      throw err;
    }
  }

  recordFailure() {
    this.failures++;
    if (this.failures >= this.threshold) {
      this.state = "OPEN";
      this.nextAttempt = Date.now() + this.timeout;
      logger.error("🔴 Circuit breaker TRIPPED");
    }
  }

  reset() {
    this.failures = 0;
    this.state = "CLOSED";
  }
}

// Usage
const userServiceBreaker = new CircuitBreaker();
const data = await userServiceBreaker.call(() => fetchUserData(userId));

✅ Failing fast is kind — users get an error immediately, not after 10s of retrying
✅ Gives the downstream service a breather to recover

3c — Structured error classes (errors that mean something)

Stop throwing raw strings or generic Errors. Give your errors context.

class AppError extends Error {
  constructor(message, { code, statusCode = 500, context = {}, retryable = false } = {}) {
    super(message);
    this.name = "AppError";
    this.code = code;
    this.statusCode = statusCode;
    this.context = context;
    this.retryable = retryable;
    this.timestamp = new Date().toISOString();
  }
}

// Subclass for specificity
class AuthError extends AppError {
  constructor(message, context) {
    super(message, { code: "AUTH_ERROR", statusCode: 401, context, retryable: false });
  }
}

class ServiceUnavailableError extends AppError {
  constructor(service, context) {
    super(`${service} is unavailable`, { code: "SERVICE_DOWN", statusCode: 503, context, retryable: true });
  }
}

// Throwing
throw new ServiceUnavailableError("UserService", { userId, attempt: 3 });

// Catching
catch (err) {
  if (err instanceof AuthError) {
    redirectToLogin();
  } else if (err instanceof AppError && err.retryable) {
    retryQueue.add(err);
  } else {
    logger.error(err.code, err.context);
    showToast("Unexpected error. Engineers notified.");
  }
}

✅ Catch blocks can make decisions, not just log and pray
✅ Every error carries its own context — no more guessing what happened

🗺️ The Full Picture

What you do	Junior	Mid	Senior
Catch errors	✅	✅	✅
Inform the user	❌	✅	✅
Send to a logger	❌	✅	✅
Typed/structured errors	❌	⚠️ partial	✅
Rollback on failure	❌	✅	✅
Retry transient errors	❌	❌	✅
Circuit breaker	❌	❌	✅
Errors are self-describing	❌	❌	✅

✅ The Golden Rules

Never swallow errors silently. A hidden bug is a time bomb.
Always tell the user something. Frozen UI is worse than an error message.
Log with context, not just a message — what failed, who triggered it, when.
Not all errors are equal — 404 ≠ 500 ≠ NetworkError. Handle them differently.
Retryable ≠ always retry — client errors (4xx) should fail fast.
Leave the system in a valid state. Roll back or compensate when operations are partial.
Your catch block is business logic — treat it that way.

"The mark of a great engineer isn't writing code that never fails.

It's writing code that fails gracefully."

Now go fix your try/catches. 🛠️

I Built a Fully Automated YouTube Channel That Uploads Every Day - Without Touching It

Shuvo — Wed, 20 May 2026 04:57:27 +0000

Every morning, a video goes live on my YouTube channel. I didn't film it. I didn't edit it. My computer did all of it while I slept.

Here's the story of how I built Progress Bar of the Year - a fully automated YouTube Shorts channel that posts a daily update on how much of the current year has passed - and the surprisingly elegant tech stack behind it.

The Idea: Simple, But Strangely Satisfying

The premise couldn't be simpler: every day, a short video goes up showing what percentage of the year has elapsed, paired with a fun historical fact about something that happened on this same day in a previous year.

That's it.

But there's something almost meditative about watching the year tick forward - and something genuinely cool about a channel that runs itself. No burnout, no filming schedule, no editor. Just code, running quietly on a small computer in the corner.

The Tech Stack at a Glance

Layer	Tool
Core logic	JavaScript / TypeScript
Historical facts	Google Gemini API
Video generation	Remotion
Upload	YouTube Data API v3
Automation	Bash + crontab

Let's break down each piece.

Step 1: The Math - How Much of the Year Has Passed?

What it does: Calculates today's date, the total days in the current year, and the percentage of the year that's gone by.

How it works: This is pure JavaScript - no libraries needed. The logic boils down to three things:

const now = new Date();
const startOfYear = new Date(now.getFullYear(), 0, 1);
const endOfYear = new Date(now.getFullYear() + 1, 0, 1);

const elapsed = now - startOfYear;
const total = endOfYear - startOfYear;
const percentage = ((elapsed / total) * 100).toFixed(2);

It also accounts for leap years automatically, since endOfYear - startOfYear will naturally be 366 days in a leap year.

Why this approach: JavaScript's Date object handles all the heavy lifting. There's no edge case to manually code - the language figures out whether it's February 28th or 29th, whether we're in a leap year, all of it. Simple and bulletproof.

Output: A number like 38.21 - meaning 38.21% of 2026 has already passed.

Step 2: The History Hook - Google Gemini API

What it does: Fetches a genuinely interesting historical event that happened on this exact calendar day in a previous year.

Why AI instead of a static database? A hardcoded database of historical facts would work - but it would be finite, brittle, and boring to maintain. The Gemini API gives us:

An effectively unlimited and varied set of historical facts
Natural language output ready to display on screen
The ability to request facts in a specific format or tone

How it works: A prompt is sent to the Gemini API each day with the current month and day, asking for a notable historical event:

const prompt = `
  Give me one interesting historical event that happened on ${month} ${day} 
  in any previous year. Keep it to 1-2 sentences. Be specific with the year.
`;

const response = await gemini.generateContent(prompt);
const fact = response.text();

The API returns something like: "49 years ago on this day, the first public screening of Star Wars generated enormous excitement among audiences who had never seen anything like it."

Why this matters for the channel: It transforms what could be a dry statistics update into something actually worth watching. Every video has a little historical surprise baked in. It gives viewers a reason to come back — not just for the percentage, but for the story of the day.

Step 3: Video Generation - Remotion

What it does: Takes the percentage and the historical fact and renders them into a polished, animated MP4 video - entirely in code.

What is Remotion? Remotion is a framework that lets you write videos using React. Instead of opening Premiere Pro or After Effects, you define your video as a React component. Animations, timing, transitions - all written in TypeScript. Then you render it to an actual video file using Node.js.

Why Remotion over other tools?

Full programmatic control - Every pixel, every animation, every timing decision is in code. No manual steps, no GUI.
Consistent output - The same code produces the same visual style every single day, automatically.
React-based - If you already know React, you're immediately productive.
High quality - Remotion renders frame-by-frame at whatever resolution and framerate you specify. The output is a proper video file, not a screen recording.

What the video looks like: A dark, minimal design with:

The year progress percentage in large type
A smooth animated progress bar filling to the correct point
Today's date
The historical fact rendered as clean text below
A short looping background animation for visual polish

The entire VideoTemplate.tsx component is just a React component with Remotion's <AbsoluteFill>, <spring>, and timing hooks to drive the animation.

export const VideoTemplate: React.FC<VideoProps> = ({ percentage, fact, date }) => {
  const frame = useCurrentFrame();
  const { fps } = useVideoConfig();

  const progress = spring({ frame, fps, config: { damping: 200 } });

  return (
    <AbsoluteFill style={{ background: '#0f0f1a' }}>
      <ProgressBar width={progress * percentage} />
      <PercentageText value={percentage} />
      <HistoricalFact text={fact} />
    </AbsoluteFill>
  );
};

Once the component is ready, rendering is a single CLI command (or programmatic call):

npx remotion render VideoTemplate out/video.mp4

Step 4: Uploading to YouTube - YouTube Data API v3

What it does: Takes the rendered MP4 and automatically uploads it to the YouTube channel with a title, description, and the correct Shorts formatting - no human involvement.

How the YouTube Data API works: Google provides an official API for interacting with YouTube programmatically. After a one-time OAuth2 authentication setup (where you grant your app permission to upload to your channel), you can upload videos, set metadata, manage playlists, and more - all from code.

The upload flow:

const youtube = google.youtube({ version: 'v3', auth: oauth2Client });

await youtube.videos.insert({
  part: ['snippet', 'status'],
  requestBody: {
    snippet: {
      title: `Year Progress Update - ${formattedDate}`,
      description: `${percentage}% of ${year} has passed.\n\n${historicalFact}`,
      tags: ['yearProgress', 'motivation', 'history'],
      categoryId: '22',
    },
    status: {
      privacyStatus: 'public',
    },
  },
  media: {
    body: fs.createReadStream('out/video.mp4'),
  },
});

Making it a YouTube Short: YouTube Shorts are simply vertical videos (9:16 aspect ratio) under 60 seconds. Remotion renders the video at 1080×1920, and that's all YouTube needs to classify it as a Short - no special API flag required.

The token refresh problem: OAuth2 tokens expire. To keep the automation running forever without manually re-authenticating, the app stores refresh tokens in tokens.json and automatically refreshes the access token before each upload. This is the kind of detail that separates a weekend project from something that actually keeps running for months.

Step 5: The Bash Script - Gluing It All Together

What it does: run-daily.sh is the conductor. It runs once a day and orchestrates the entire pipeline end-to-end.

Why a bash script? The core logic is in Node.js/TypeScript, but crontab (which triggers the daily run) works at the OS level. A bash script acts as the perfect bridge - it can set up the environment, invoke Node, handle errors, and maintain a log.

What the script does, step by step:

#!/bin/bash

PROJECT_DIR="/Users/mdshuvo/yearlyprogress"
STATE_FILE="$PROJECT_DIR/last-upload-date.txt"
LOG_FILE="$PROJECT_DIR/log.txt"

TODAY=$(date +%Y-%m-%d)

# Read the last run date
if [ -f "$STATE_FILE" ]; then
  LAST_RUN=$(cat "$STATE_FILE")
else
  LAST_RUN=""
fi

# Skip if already ran today
if [ "$LAST_RUN" = "$TODAY" ]; then
  exit 0
fi

cd "$PROJECT_DIR" || exit 1

# Run the main script, append output to log
/Users/mdshuvo/.nvm/versions/node/... >> "$LOG_FILE" 2>&1

# Trim the log to keep only the last 2000 lines
if [ -f "$LOG_FILE" ]; then
  tail -n 2000 "$LOG_FILE" > "$LOG_FILE.tmp" && mv "$LOG_FILE.tmp" "$LOG_FILE"
fi

Key design decisions:

Idempotency - The state file check ensures the script never accidentally uploads twice on the same day, even if crontab triggers it multiple times.
Logging - All output is appended to log.txt for easy debugging if something goes wrong.
Log trimming - The log is kept to 2,000 lines so it doesn't grow forever and fill up the disk.
nvm path - The full path to the Node binary is specified, because crontab runs in a minimal environment that doesn't load your shell's .bashrc or .zshrc. This is a classic gotcha that trips up many automation projects.

Step 6: The Crontab - Set It and Forget It

What it does: Tells my computer(Mac mini) to run run-daily.sh automatically at a set time every day.

What is crontab? It's a Unix job scheduler built into macOS and Linux. You define a schedule using a simple syntax, point it at a script, and the OS handles the rest - forever, or until you delete the entry.

The crontab entry:

0 9 * * * /Users/mdshuvo/yearlyprogress/run-daily.sh

This runs the script at 9:00 AM every day. The five fields represent: minute, hour, day of month, month, day of week. Five stars with the first two set means "every day at 9:00."

The result: Every morning at 9 AM, without any human action, computer runs the script, generates the video, and uploads it to YouTube. By the time most people are having their morning coffee, the day's video is live.

What Makes This Project Special

Beyond the individual pieces, what's interesting here is how each layer is chosen for a specific reason:

JavaScript for logic - Universal, fast to write, perfect for date manipulation and API calls.
Gemini for content - Turns a static metric into a story worth watching.
Remotion for video - Treats video like software, making it reproducible and automatable.
YouTube Data API for distribution - The last mile, handled entirely in code.
Bash for orchestration - Lightweight, reliable, and plays perfectly with crontab.
crontab for scheduling - The simplest possible scheduler, built into the OS.

No overengineering. No cloud infrastructure to manage. No monthly bills for a complex pipeline. Just a small computer, some clever code, and a crontab entry.

What's Next?

A few directions this project could grow:

Multiple languages - Generate the same video in Bengali, Spanish, French, etc. to reach broader audiences.
Milestone alerts - Special videos at 25%, 50%, 75%, and 99% with more elaborate animations.
Thumbnail generation - Use a canvas library or Puppeteer to auto-generate custom thumbnails.
Analytics tracking - Pull view counts back from the YouTube API and log the growth over time.
Multi-channel - Clone the pipeline for a "Day of the Year" or "Days Until New Year" variant.

Try It Yourself

All the core tools used are free or have generous free tiers:

Remotion - Free for open-source and personal projects
Google Gemini API - Free tier available
YouTube Data API v3 - Free with a Google account

If you want to watch the year tick away one percentage point at a time, the channel is live at youtube.com/@ProgressOfYear. A new video drops every morning.

Built with JavaScript, Remotion, Gemini

Why Traditional Tutorials Don't Work for Learning Git

Shuvo — Wed, 13 May 2026 04:57:00 +0000

If you've tried learning Git through videos or articles and still feel confused, you're not alone. The problem isn't you - it's the way Git is usually taught.

The Problem with Traditional Git Tutorials

Most tutorials focus on explaining commands instead of helping you understand how Git actually works in real situations.

They are passive (watching instead of doing)
They focus on syntax, not workflows
No real problem-solving scenarios
No feedback when you make mistakes

Why This Approach Fails

1. Git is Conceptual, Not Just Commands

Git involves understanding history, branches, and changes - not just memorizing commands.

2. No Muscle Memory

Watching tutorials doesn't build the habit of actually using Git commands.

3. No Real Context

Real development involves conflicts, mistakes, and workflows - tutorials rarely simulate this.

Traditional Learning vs Effective Learning

Method	Result
Watching tutorials	Temporary understanding
Reading docs	Good reference, low retention
Interactive practice	Real understanding

A Better Way to Learn Git

The most effective way to learn Git is through hands-on, interactive practice.

Learn a concept
Apply it immediately
Make mistakes and fix them
Repeat with real workflows

Stop Watching, Start Practicing

If you want to truly understand Git, you need to use it - not just watch someone else use it.

Frequently Asked Questions

Are tutorials useless for learning Git?
Not useless, but incomplete. They should be combined with hands-on practice.

Why does Git feel confusing?
Because it involves abstract concepts that require practice to fully understand.

What is the best way to learn Git?
The best way is practicing real workflows instead of relying only on passive learning.

Learn Git Basics in 5 Minutes (Quick Guide)

Shuvo — Wed, 13 May 2026 04:53:45 +0000

Want to learn Git fast? This 5-minute guide covers the essential Git concepts and commands you need to get started. No fluff - just the basics that actually matter.

What is Git?

Git is a version control system that helps you track changes in your code, collaborate with others, and manage different versions of your project.

3 Core Git Concepts

Repository (Repo)

A project folder tracked by Git.

Commit

A snapshot of your changes.

Branch

A separate line of development.

Essential Git Commands

Command	Description
`git init`	Initialize a new repository
`git add .`	Stage changes
`git commit -m "message"`	Save changes
`git status`	Check current state
`git branch`	View branches
`git checkout -b feature`	Create and switch branch
`git merge`	Merge branches

Basic Git Workflow

Make changes to your files
Run git add .
Run git commit -m "message"
Repeat as you build your project

Important: Reading Isn't Enough

You can't learn Git just by reading. You need to actually use the commands in real scenarios.

The fastest way to learn Git:

Learn a concept
Practice it immediately
Repeat with real workflows

Practice Git in Minutes

Instead of just reading, start practicing Git commands interactively and build real confidence.

Frequently Asked Questions

Can I learn Git in 5 minutes?
You can understand the basics in 5 minutes, but mastering Git requires practice.

What should I learn first in Git?
Start with repositories, commits, and basic commands like add and commit.

Is Git hard for beginners?
It can feel confusing at first, but becomes easy with hands-on practice.

Git Commands Senior Developers Actually Use

Shuvo — Wed, 13 May 2026 04:48:34 +0000

Want to use Git like a senior developer? It’s not about knowing hundreds of commands - it’s about mastering a small set of powerful ones and using them confidently in real workflows.

What Makes These Commands “Senior-Level”?

Senior developers don’t just run commands - they understand how Git history works, how to fix mistakes, and how to manage clean workflows. These commands reflect that mindset.

1. `git status`

Always Know What’s Happening

Check your current state before doing anything. Senior devs constantly use this.

2. `git log --oneline --graph --decorate`

Visualize History

See your commit history in a clean, readable format.

3. `git checkout -b feature-name`

Work in Branches

Create isolated environments for features and fixes.

4. `git merge`

Combine Work Safely

Merge branches when features are complete.

5. `git rebase`

Clean Up History

Rewrite commit history to keep it linear and clean.

6. `git stash`

Save Work Temporarily

Quickly store changes without committing.

7. `git reset`

Undo Changes

Move back to a previous state when needed.

8. `git restore`

Fix Mistakes Safely

Restore files without affecting commits.

9. `git pull --rebase`

Avoid Messy Merges

Keep history clean when pulling updates.

10. `git diff`

See What Changed

Understand exactly what modifications were made.

Practice These Commands Like a Pro

Reading commands isn’t enough - you need to actually use them in real workflows.

10 Git Mistakes Beginners Make (And How to Avoid Them)

Shuvo — Wed, 13 May 2026 04:40:12 +0000

Why Beginners Struggle with Git

Git isn’t just about commands - it’s about understanding how changes, history, and branches work together. Without hands-on practice, these concepts feel confusing.

10 Common Git Mistakes

1. Trying to Memorize Commands

Many beginners try to memorize Git commands instead of understanding what they actually do.
How to fix: Focus on workflows, not commands. Practice using Git in real scenarios.

2. Not Practicing Enough

Watching tutorials without actually using Git leads to shallow understanding.
How to fix: Use interactive practice to apply what you learn immediately. GitMission is great for that.

3. Ignoring Branching

Branching is a core concept, but many beginners avoid it.
How to fix: Practice creating, switching, and merging branches regularly.

4. Fear of Breaking Things

Beginners often hesitate because they’re afraid of making mistakes.
How to fix: Git is designed to recover changes - experiment freely.

5. Not Understanding Commits

Treating commits like random saves instead of meaningful checkpoints.
How to fix: Make small, descriptive commits that reflect logical changes.

6. Skipping Git Fundamentals

Jumping into advanced topics without understanding basics.
How to fix: Master repositories, commits, and staging first.

7. Confusion Between Git and GitHub

Many beginners mix up Git (tool) and GitHub (platform).
How to fix: Understand Git as the system, GitHub as a hosting service.

8. Poor Commit Messages

Using vague messages like 'update' or 'fix'.
How to fix: Write clear messages describing what changed and why.

9. Not Learning How to Undo Changes

Beginners panic when something goes wrong.
How to fix: Learn commands for undoing commits, restoring files, and fixing mistakes.

10. Avoiding Real Workflows

Only learning isolated commands instead of real use cases.
How to fix: Practice full workflows like feature development and merging.

The Real Secret to Learning Git

The biggest mistake is relying only on passive learning.

Learn a concept
Practice it immediately
Repeat with real scenarios

Learn Git Without These Mistakes

Instead of struggling through trial and error, you can learn Git the right way through structured, hands-on practice.

Functional tabs with only CSS (No JavaScript)

Shuvo — Wed, 04 Jun 2025 01:34:42 +0000

This article demonstrates how to create functional tabs using only CSS, without any JavaScript. The tabs will allow users to switch between different content sections seamlessly, showcasing the power of CSS for interactive elements.
Original article: wtfcodes.com

Basic setup:

To get started, we will create a typical HTML structure for our tabs and apply some basic styles to make them visually appealing.

<div class="tabs-wrapper">  
  <nav class="tabs-nav">
    <div class="tab-item">
      <span>Tab A</span>
    </div>
    <div class="tab-item">
      <span>Tab B</span>
    </div>
    <div class="tab-item">
      <span>Tab C</span>
    </div>

  </nav>

  <div class="tab-content" id="tab-a-content">
    I am Tab A content
  </div>
  <div class="tab-content" id="tab-b-content">
    I am Tab B content
  </div>
  <div class="tab-content" id="tab-c-content">
    I am Tab C content
  </div>
</div>

body{
  font-family: Arial;
  padding: 1em;
}

.tabs-nav{
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
  user-select: none;
}

.tab-item{
  background: #bcbcbc;
  padding: 6px 12px;
  border-radius: 6px;
  color: #fff;
  cursor: pointer;
}
.tab-content{
  padding: 12px;
  border-radius: 16px;
  border: 1px solid grey;
}

Great! Now we need somekind of interactivity.
Lets think what cab we do so the active tab has something different than other tabs.
Well we can use <input type="radio" /> to indicate the active tab. Since radio inputs allow only one to be selected at a time, we can use them to control which tab is active.
And to make sure we can toggle the radio inputs by clicking on the tab, we can use the <label> element instead of <div> for the tab items.
So the updated HTML structure will look like this:

<div class="tabs-wrapper">  
  <nav class="tabs-nav">
    <label for="tab-a-toggle" class="tab-item">
      <span>Tab A</span>
      <input checked name="tabs-toggle" id="tab-a-toggle" type="radio">
    </label>
    <label for="tab-b-toggle" class="tab-item">
      <span>Tab B</span>
      <input name="tabs-toggle" id="tab-b-toggle" type="radio">
    </label>
    <label for="tab-c-toggle" class="tab-item">
      <span>Tab C</span>
      <input name="tabs-toggle" id="tab-c-toggle" type="radio">
    </label>
  </nav>

  <div class="tab-content" id="tab-a-content">
    I am Tab A content
  </div>
  <div class="tab-content" id="tab-b-content">
    I am Tab B content
  </div>
  <div class="tab-content" id="tab-c-content">
    I am Tab C content
  </div>
</div>

Nice progress!
Since we don't want the radio inputs to be visible, we can hide them using .tab-item input{display: none; } in the CSS.

Highlight the active tab:

We can use the tab-item:has(input:checked) selector in CSS to check if a tab has a checked input and apply styles to it.

.tab-item input{
  display: none;
}
.tab-item:has(input:checked){
  background: #6b54f0;
}

Amazing! Now we can see which tab is active.
Using the same logic, we can also show/hide the content of the active tab.

.tab-content{
  display: none;
}
.tabs-wrapper:has(#tab-a-toggle:checked) #tab-a-content{
  display: block;
}
.tabs-wrapper:has(#tab-b-toggle:checked) #tab-b-content{
  display: block;
}
.tabs-wrapper:has(#tab-c-toggle:checked) #tab-c-content{
  display: block;
}

Final code:

<div class="tabs-wrapper">  
  <nav class="tabs-nav">
    <label for="tab-a-toggle" class="tab-item">
      <span>Tab A</span>
      <input checked name="tabs-toggle" id="tab-a-toggle" type="radio">
    </label>
    <label for="tab-b-toggle" class="tab-item">
      <span>Tab B</span>
      <input name="tabs-toggle" id="tab-b-toggle" type="radio">
    </label>
    <label for="tab-c-toggle" class="tab-item">
      <span>Tab C</span>
      <input name="tabs-toggle" id="tab-c-toggle" type="radio">
    </label>
  </nav>

  <div class="tab-content" id="tab-a-content">
    I am Tab A content
  </div>
  <div class="tab-content" id="tab-b-content">
    I am Tab B content
  </div>
  <div class="tab-content" id="tab-c-content">
    I am Tab C content
  </div>
</div>

body{
  font-family: Arial;
  padding: 1em;
}

.tabs-nav{
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
  user-select: none;
}

.tab-item{
  background: #bcbcbc;
  padding: 6px 12px;
  border-radius: 6px;
  color: #fff;
  cursor: pointer;
}
.tab-content{
  padding: 12px;
  border-radius: 16px;
  border: 1px solid grey;
}

.tab-item input{
  display: none;
}
.tab-item:has(input:checked){
  background: #6b54f0;
}

.tab-content{
  display: none;
}

.tabs-wrapper:has(#tab-a-toggle:checked) #tab-a-content{
  display: block;
}
.tabs-wrapper:has(#tab-b-toggle:checked) #tab-b-content{
  display: block;
}
.tabs-wrapper:has(#tab-c-toggle:checked) #tab-c-content{
  display: block;
}

Thank you for reading!

If you enjoyed this article, please consider sharing it with others.
You can support me on Buy Me a Coffee.
If you have any feedback or suggestions, feel free to reach out to me on Twitter.
Don't forget to checkout wtfcodes.com