DEV Community: Shuvo

I'm Too Lazy to Write Alt Text, So Gemma Does It For Me

Shuvo — Sun, 25 Oct 2026 04:14:14 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Every codebase I've touched has the same line in it:

<img src="/imgs/cookie.png" alt="" />

It's rarely because we don't care about accessibility. Describing forty images is just the most boring job in front-end, so it gets pushed to "later."

So I built a VS Code extension that does it for me. Hover over any <img> with a missing or empty alt, click Generate alt text, and the description is written straight into your code.

Feeling really lazy? Press Cmd+Shift+A (Ctrl+Shift+A on Windows/Linux) and it fills in every empty alt in the file at once.

A few small rules keep it safe to trust:

It never overwrites alt text you already wrote.
Failures are reported per image, and the successful ones are still applied.
Output is escaped, so a stray quote can't break your markup.

Code

0shuvo0 / ai-img-alt-text-ext

Generate accessible image alt text in HTML, JSX, and TSX files using a locally running Ollama vision model. Image contents are sent only to the Ollama server you configure.

AI Image Alt Text

Generate accessible image alt text in HTML, JSX, and TSX files using a locally running Ollama vision model. Image contents are sent only to the Ollama server you configure.

Features

Hover over an <img> element with an empty or missing alt attribute and select Generate alt text.
Press Cmd+Shift+A (or Ctrl+Shift+A on Windows/Linux) to fill empty or missing alt attributes in the current file.
Supports multiline tags, other attributes, workspace-relative image files, and HTTP(S) image URLs.
Existing non-empty alt text is never overwritten. Bulk generation reports individual image failures and applies successful results together.

Requirements

Ollama running locally or at a server you can access.
A vision-capable model installed in Ollama, for example:
```
ollama pull gemma3:latest
```

The first generation prompts for the Ollama server URL (for example http://localhost:11434) and model name. These values are saved in the VS Code user settings. To change them…

View on GitHub

How I Built It

The whole thing runs on Gemma 3 through Ollama, entirely on my own machine.

When you click the button, the extension:

Finds the image. It checks the workspace root first, then common static folders like public/, so /imgs/cookie.png just works. Remote URLs work too.
Sends it to the local Gemma model with a short prompt asking for a concise, useful description.
Writes the result back into the alt attribute.

Setup is two steps: ollama pull gemma3:latest, then point the extension at your Ollama URL. The model name is a setting, so you can swap in any other vision model without touching the code.

Why Does Open Innovation Matter?

Alt text feels like a perfect job for a hosted API, until you think about what you'd be sending it.

Your images stay yours. Client mockups, unreleased products and internal dashboards often sit in a repo long before anyone should see them. With a local model, nothing leaves the laptop.

It costs nothing per image. A big project can have hundreds of images. Running them through Gemma costs electricity, not a bill that grows with your codebase.

It's swappable. If a better open vision model shows up next month, it's a one-line settings change. I'm not tied to one provider's pricing or availability.

The honest trade-off: a local model is slower than a hosted API. But this is a job you start and walk away from, so for this use case slow and steady is a fine deal.

The Lazy Payoff

I ran it on 20 images from one of my projects.

Time: just 3 minutes, versus roughly 10 minutes writing them by hand.
Usable as-is: 18 out of 20 descriptions needed no editing.
Where it struggled: Animated or vector images eg gif files

Prize Categories

Best Use of Gemma: every description is generated by Gemma 3, running locally through Ollama.

Chat with client In -> Invoice Out

Shuvo — Thu, 15 Oct 2026 06:30:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every freelancer knows this moment.

The client says "Great work, can you send the invoice?" and suddenly you're digging through 200 WhatsApp messages to find the rate, the hours, the email address, and that one message where the price changed from $250 to $300.

Then you open a template, retype everything, export a PDF, and email it. Ten minutes gone, for something that's already written down in the chat.

Chat2Invoice fixes that. You paste the conversation, and a local AI turns it into a ready-to-send invoice PDF.

Paste your WhatsApp, Slack, iMessage, or email conversation (optionally attach a contract, a receipt, or a mockup).
Review what the AI found. Anything missing gets flagged, and everything is editable.
Send a clean A4 PDF. Download it or email it straight to the client.

Who would pay for this? Anyone who gets paid directly, outside platforms that auto-generate invoices: freelance designers, developers, writers, consultants, and small agencies who negotiate in DMs and then have to turn those DMs into paperwork.

The best part is that the chat never has to leave your machine.

Demo

Step 1: Paste the chat

Step 2: Review what the AI found

The AI shows what it extracted and highlights anything it couldn't find. Here it caught one field was not found in chat.

Step 3: Preview, download, send

Struggling to learn Git?

Learn Git by solving problems on GitMission.com

Code

0shuvo0 / chat2invoice

Chat2Invoice

Paste a client chat → local AI (Ollama) extracts invoice details → review/edit → generate an A4 PDF → download or email it.

Stack: Next.js 14 (App Router) + TypeScript + Tailwind CSS, jsPDF (PDF generation), pdfjs-dist (PDF text extraction), Inter font bundled locally (@fontsource).
Offline: everything runs locally. Text/PDF reading and PDF generation happen in the browser; the AI runs in your local Ollama. Only "Send via Email" needs internet (Resend).

Requirements

Node.js 18.18+ (20 LTS recommended)
Ollama

Setup

# 1. Install Ollama, then pull the model (one time, ~3 GB)
ollama pull gemma3:latest

# 2. Install dependencies
cd chat2invoice
npm install

# 3. Environment
cp .env.example .env.local     # edit if needed

.env.local:

OLLAMA_AI_MODEL=gemma3:latest
OLLAMA_HOST=http://127.0.0.1:11434
# Optional – the "Send Invoice via Email" section only appears when BOTH are set:
RESEND_API_KEY=re_xxx
RESEND_SENDER_EMAIL=invoices@your-verified-domain.com

(Shell environment variables work too.) RESEND_SENDER_EMAIL must…

View on GitHub

How I Built It

The open-source AI part: Gemma 3 running locally through Ollama. No API key, no per-request bill, no server in the middle. The app talks to Ollama on 127.0.0.1:11434, and that's where the "understanding" happens.

The stack:

Next.js 14 (App Router) + TypeScript + Tailwind CSS
jsPDF to generate the invoice PDF in the browser
pdfjs-dist to read text out of attached PDF contracts, also in the browser
Inter font bundled locally, so nothing is fetched from a CDN
Resend for the optional "Send via Email" feature

The flow:

Input. Paste the chat or hit "Paste Clipboard". An optional "Advanced & Attachments" section lets you add notes that override the chat (like "Net 15, apply 10% holiday discount"), plus PDF/TXT files and images. Text is extracted in the browser, and images go to Gemma 3's vision capability.
Review. Missing required fields appear under Action Needed, and found ones are shown as editable fields. Optional extras include discount, amount due now, tax note, currency, company names, and payment instructions. The invoice ID (like INV-2026-OCT-13-JD2N) and issue date are auto-generated, and "Due Now" defaults to amount minus discount.
Ready. Preview the invoice, download the PDF, or send it to the client with an editable message.

I intentionally put a human checkpoint in the middle. The AI proposes, and you approve. A small local model will occasionally misread a message, and an invoice is a document with money on it, so the review step is a feature rather than a limitation. Missing details get flagged and asked for instead of invented.

Running it yourself takes a minute. Pull a model with Ollama, then create .env.local:

OLLAMA_AI_MODEL=gemma3:latest
OLLAMA_HOST=http://127.0.0.1:11434

# Optional: the "Send Invoice via Email" section only appears when BOTH are set
RESEND_API_KEY=re_xxx
RESEND_SENDER_EMAIL=invoices@your-verified-domain.com

RESEND_SENDER_EMAIL must be on a domain verified in your Resend account. Skip these two lines and the app simply hides the email section, so everything else works fully offline.

Why Does Open Innovation Matter?

Client chats are some of the most sensitive text a freelancer owns. They contain real names, email addresses, rates, project details, and sometimes things covered by an NDA. Pasting that into a closed cloud API just to get a PDF is a bad trade.

Open-weight models changed the deal:

Privacy by architecture. The chat is processed by Gemma on your own machine. There's no "we promise not to store it" because there's no server to store it on.
Costs nothing to run. No tokens, no subscription, no usage cap. A tool for a side hustle shouldn't eat into the side hustle's income.
Works offline. Text extraction, AI, and PDF generation all happen locally. Only the optional email step needs internet.
No lock-in. The model is one environment variable (OLLAMA_AI_MODEL). If a better open model shows up next month, swapping it in is a one-line change, with no pricing changes or deprecations to worry about.

A closed API could do the extraction, but it couldn't make the promise that matters most to the person using this tool: your client's conversation never left your laptop.

My First User

My friend who is in final year in college and he is super busy trying to manage study and freelance work at the same time. So this will save him a few hours monthly.

Prize Categories

Best Use of Gemma: Gemma 3 runs locally via Ollama and handles both text extraction and image understanding for receipts and mockups.

I Built a Group Chat Where Only AIs Can Talk (and They Roast Each Other)

Shuvo — Wed, 14 Oct 2026 05:10:34 +0000

Imagine a group chat like WhatsApp or Discord, but no human can send messages. Only AI models can. They talk to each other, bully each other, roast each other, and react to each other's messages.

That was my idea, and it turned out to be a lot of fun.

Here's how I built it, including the one trick that made it far more entertaining: giving every model its own voice.

📦 Source code: github.com/0shuvo0/AI-Group-Chat

The idea

It's a custom app where I can add a bunch of AI models to a shared chat. Once they're in, they read what the others wrote and respond on their own. I just sit back and watch.

The first question is how to get the models into the app.

Problem 1: Too many APIs

I don't want to open chatgpt.com and paste messages by hand. I want my app to send a question to a model and get the answer back programmatically. That's what an API is for. Gemini, Claude, Grok, and ChatGPT all have their own.

The catch: I wanted lots of models, and API access is paid. Five models would mean:

five separate accounts,
five separate billing setups,
five API keys to manage,
a minimum top-up on each, even though I'd barely use any tokens.

That's complicated and not cost effective.

The fix: OpenRouter

OpenRouter gives you access to a huge catalog of models through a single API. You add credit to one account, use whichever models you like, and it bills you per model usage.

The result is one service, one API key, one balance. Swapping or adding a model is just a change to the model name.

Problem 2: Getting them to actually chat

Left alone, models will happily ramble about whatever they want, and that's rarely entertaining. So I added a theme. When I open the app, I can give the chat a topic, and the models riff around it.

Each model gets a prompt like this:

const prompt = `
You are ${ai} ai, chatting in a group chat with these AIs ${others.join(', ')}.
Talk the way people do in a casual group chat.

${theme ? `\nTheme of this chat: ${theme}\n` : ''}

Rules:
- Write only your own messages, never lines for the others.
- Send 1 to 3 short messages. Put each message on its own line.
- Keep each message to a sentence or two. Do not write paragraphs.
- No markdown, no quotes, and do not start with your name or a label.
- An emoji-only message is fine now and then.
- Respond to what others said, by name if it helps. Add something new instead of just agreeing or repeating.
- Do not say goodbye or try to wrap up the conversation.
- Talk like carefree young generation: relaxed, fun, expressive, emojis

${
  history?.length
    ? `Chat so far:
<chat>
${history}
</chat>

If you have nothing to add right now, reply with exactly: <SKIP>
Otherwise, send your next message(s).`
    : 'Nobody has said anything yet, so you are sending the first message.'
}
`.trim()

A few details make this work well:

Role clarity. Each model is told it's in a group chat and who else is there.
Strict format rules. Short messages, no markdown, no name labels. Without these, models write essays or script lines for the other participants.
Shared history. Previous messages are passed in a <chat> block so replies actually respond to what was said.
An escape hatch. Models can answer <SKIP> if they have nothing to add, which keeps the conversation from feeling forced.
Personality. The casual, emoji-friendly tone instruction is what gives the chat its vibe.

The app itself was simple to build. I described what I wanted to Claude, and a few prompts later I had a working version.

Problem 3: It's too fast to read

The app worked and looked good, but it wasn't as fun as I'd hoped. Messages arrive so quickly that reading them all becomes a chore.

So I gave the models a voice.

The fix: Kokoro.js

For text-to-speech I used Kokoro, an open model with just 82 million parameters, around 300 MB in size. That's small enough to run directly in the browser, so there are no extra server calls or per-character fees, and it's fast.

I used its JavaScript library, kokoro-js, and plugged it into the web app. Each incoming AI message is converted to audio locally and played back. Now the models don't just type, they talk.

The final result

Watching a handful of AIs bicker, joke, and roast each other out loud is oddly entertaining.

Tech stack recap

Piece	Tool
Multiple AI models, one API	OpenRouter
Text-to-speech in the browser	Kokoro via kokoro-js
Scaffolding the app	Claude

Try it yourself

The full code is on GitHub: 0shuvo0/AI-Group-Chat. Clone it, add your OpenRouter key, pick a theme, and let the models loose.

Struggling with git?

Learn git by playing games and solving missions with GitMission.com

People Won't Go Outside so I made this

Shuvo — Wed, 07 Oct 2026 01:38:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

GoSeek is a mobile scavenger hunt that gets you outside by giving you a riddle instead of an instruction.

The problem I started with: if an app says "go outside!", nobody goes. People don't like being told what to do, but they love solving puzzles. So GoSeek hands you this instead:

"Small furry apex predator that domesticated itself, loves afternoon sunbeams, and leaves silent pawprints in the garden."

You can't solve that from the couch. You have to go find the thing, and the app only accepts a photo taken live in the app. No gallery uploads.

The loop:

Tap Touch Grass and get a riddle for a random everyday object (a bench, a pigeon, a manhole cover).
Go outside and work out what it is.
Open the camera and take a photo.
A vision model running on your phone checks whether it matches.
Match confirmed: confetti, points, and the photo joins your Trophy Gallery.

Harder objects are worth more points, and points level you up from Wanderer to Explorer to Seeker to Trailblazer.

Who is it for? Anyone, especially city dwellers. The object list leans urban (street signs, power lines, shop signs), with nature finds like butterflies and pine cones as harder, higher-reward targets. The screen is the shortest part: read, walk, snap, done.

Demo

🌿 Live app: goseek.ai.studio (best on your phone)

Code

0shuvo0 / goseek

GoSeek is a mobile-first outdoor scavenger hunt game. Each round gives you a riddle clue, and you must find the matching object in the real world by taking a photo with your camera or uploading an image.

GoSeek

GoSeek is a mobile-first outdoor scavenger hunt game. Each round gives you a riddle clue, and you must find the matching object in the real world by taking a photo with your camera or uploading an image.

Try it: goseek.ai.studio

How it works

The app picks a random object from src/data/objects.json and shows a clue/riddle.
You open the mission screen, then use the live camera or a file upload to capture a photo.
src/services/aiModel.ts validates the image against the target object using a local Hugging Face vision pipeline and a fallback visual heuristic.
If the object matches, the app awards points, stores the discovery, and updates your run stats.
Progress is saved in the browser using IndexedDB (src/services/db.ts), so your streak, score, and discovery history persist locally.

Main flow

src/App.tsx manages the dashboard, active mission, score updates, and success/reset modals.
src/components/ActiveMission.tsx handles the camera, verification loop, save…

View on GitHub

How I Built It

1. Design: Google Stitch → Figma

I described the app to Google Stitch, imported the generated design into Figma, simplified it, and edited the copy.

Stitch prompt

APP: GoSeek
1.
when user opens the app and clicks a button first we choose an everyday common object that can be easily found outside(We will have an array of those things with difficulty level, more common = less difficult and more difficult = more points)
2.
app uses ai to describe the object as a mystery/riddle eg. instead of saying 'cat' it says 'small furry apex predator that domesticated itself'
3.
the use has to go out find the object and take a photo(use can only take photo on the app, website not upload old or downloaded photos)
4.
then the app uses AI to analyze the image and tells use if the photo is of correct thing or not
if correct so a nice animation and add points to user

design a mvp for it

Google stitch output:

After simplifying on figma:

2. The architecture problem

My first plan: keep a list of objects and have an on-device model write riddles on the fly. That fails. A model good enough for clever riddles is too big for most phones, and this is an outdoor game that has to run on the device you actually carry.

So I split the job and put each task where it fits:

Job	Model	Runs on	When
Write creative riddles	Gemma 3 4B (open-weight)	My computer, via Ollama	Once, ahead of time
Judge the photo	SmolVLM-500M (open-weight)	The user's phone, in the browser	Every play

The heavy creative model runs once and produces a static objects.json. The tiny vision model handles the one thing that must happen live.

3. Generating riddles with Gemma

I pulled gemma3:4b with Ollama and wrote a small script that asks for five riddles per object. The key is the prompt:

You write riddles for an outdoor scavenger hunt game for all ages.
Write 5 different riddles, each describing "${obj.name}" WITHOUT ever saying the word "${obj.name}" (or its plural, or any word in it).
Rules:
- Each riddle is 1-2 sentences, maximum 30 words.
- Each riddle uses a different angle (looks, purpose, location, sound, behavior, feel).
- Family-friendly, no mention of people or danger.
- Do not start with "I am" every time.

Output ONLY a JSON array of 5 strings. No explanation, no markdown.

Asking for a different angle per riddle keeps replays fresh, and the "never say the word" rule stops riddles from giving the answer away.

Full generation script (ai.ts + index.ts)

// ai.ts
async function askGemma(userPrompt: string): Promise<string> {
  const response = await fetch('http://localhost:11434/api/chat', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      model: 'gemma3:4b',
      messages: [{ role: 'user', content: userPrompt }],
      stream: false,
    }),
  });
  if (!response.ok) throw new Error(`Local AI request failed (${response.status}). Make sure Ollama is running.`);

  const data: { message?: { content?: string } } = await response.json();
  const answer = data.message?.content?.trim();
  if (!answer) throw new Error('Local AI returned an empty recommendation. Please try again.');
  return answer;
}

export { askGemma };

// index.ts
import { askGemma } from "./ai";
import * as fs from "fs/promises";
import * as path from "path";

export type Difficulty = 'easy' | 'medium' | 'hard';

export interface GameObject {
  name: string;
  difficulty: Difficulty;
}

const objects: GameObject[] = [
  { name: "Cat", difficulty: "easy" },
  { name: "Tree", difficulty: "medium" },
  // ...
];

const OUTPUT_FILE = path.join(process.cwd(), "objects.json");

async function run() {
  const results: any[] = [];

  for (const obj of objects) {
    console.log(`Generating "${obj.name}"...`);

    const prompt = `...the prompt above...`;

    const raw = await askGemma(prompt);
    const cleaned = raw.replace(/```
{% endraw %}
json|
{% raw %}
```/gi, "").trim();
    const riddles = JSON.parse(cleaned);

    results.push({ name: obj.name, difficulty: obj.difficulty, riddles });
  }

  await fs.writeFile(OUTPUT_FILE, JSON.stringify(results, null, 2), "utf8");
  console.log(`✅ Done. Saved ${results.length} objects to ${OUTPUT_FILE}`);
}

run().catch(console.error);

The output is a plain objects.json:

[
  {
    "name": "road",
    "difficulty": "easy",
    "riddles": [
      "A long ribbon of black stone that carries wheels from where you are to where you're going, never moving itself",
      "Painted with dashed lines and arrows, it tells travelers where to go, yet it has no voice"
    ]
  }
]

4. Building the app in Google AI Studio

I opened Google AI Studio's app builder, attached the design screenshots and objects.json, and gave it a single detailed prompt: game loop, data models, tech stack (React, TypeScript, Tailwind, Transformers.js, IndexedDB), and camera rules. A few follow-up prompts later the app worked, and one click on Publish made it live.

AI Studio prompt

Role & Goal: Act as an expert frontend developer. Build a mobile-first, PWA-ready web application called "GoSeek," an outdoor scavenger hunt game where users find real-world objects based on riddles.

UI/UX Design
Match the layout, dark theme, and typography strictly to the provided design mockups in attached photos. The app must be highly responsive on mobile devices.

Core Game Loop
Model Initialization: On first load, download and initialize the SmolVLM-500M AI model locally on the device (show a progress bar during this step).
Mission Generation: Select a random everyday outdoor object from objects.json. Display one of its associated riddles to the user (e.g., "small furry apex predator that domesticated itself" instead of "cat").
Capture: The user clicks "Open camera" to access the device's live camera. Constraint: Users must capture a live photo; file uploads from the gallery are strictly disabled.
Verification: Pass the captured frame to the local SmolVLM-500M model to verify if the object matches the riddle.
Success State: If matched, trigger a celebratory animation (e.g., confetti or a success modal) and award points based on the object's difficulty.
Gallery & State: Downscale the verified image and save it locally along with the object name, timestamp, and points earned. Display these in a scrollable "Trophy Gallery & Log" history section.

Data Structures & Logic
export type Difficulty = 'easy' | 'medium' | 'hard';
export interface GameObject {
  name: string;
  difficulty: Difficulty;
  riddles: string[];
}
export const points: Record<Difficulty, number> = { easy: 10, medium: 20, hard: 30 }
export const level: Record<string, number> = {
  wanderer: 0,      // 0-49 points
  explorer: 50,     // 50-99 points
  seeker: 100,      // 100-149 points
  trailblazer: 150  // 150+ points
}

Technical Requirements
Tech Stack: Use React with TypeScript and Tailwind CSS for styling.
AI Integration: Use Hugging Face transformers.js to load and run SmolVLM-500M entirely on-device via WebGPU/WebAssembly.
Storage: Use IndexedDB (via a wrapper like idb or localforage) rather than localStorage to save the downscaled user photos and history state without hitting quota limits.
Camera API: Use the HTML5 navigator.mediaDevices.getUserMedia API facing the environment (rear camera). Fall back to typical file upload if it fails.
Handle edge cases and figure stuff out if missing in description.

The stack

Layer	Tool
Design	Google Stitch → Figma
Riddle generation	Gemma 3 4B via Ollama
On-device vision	SmolVLM-500M via Transformers.js (WebGPU/WASM)
UI	React + TypeScript + Tailwind CSS
Storage	IndexedDB (photos + history)
Camera	`getUserMedia`, rear camera, live capture
Build + hosting	Google AI Studio

How It Went Outside

So I played with it outsider for 20-0 minutes and it was a blast
One of the riddle I got was: No back cushions, no screen, just a place to rest, feed the pigeons, or wait for someone and very interesting I must way
The SmolVLM-500M is small but so far it has been working decent]
It runs very smoothly on my iPhone 14

Why Does Open Innovation Matter?

Open models didn't just make GoSeek cheaper. They made the architecture possible.

Photos never leave your phone. GoSeek points a camera at your street and neighborhood. Because SmolVLM-500M is open-weight and runs in the browser, verification happens on the device: no upload, no server, no account. A closed vision API would receive every photo.
It works where the game happens. After the one-time model download, checking a photo doesn't need a network round-trip.
It costs nothing per play. Every verification is free, where a hosted vision API charges per image. Running Gemma locally made generating all the riddles free too.
Right model, right place. Open weights let me run a bigger model once for a creative task and a tiny one live on the phone. That split is the core design decision of the app.
Everything is swappable. A better small vision model next month? Swap it in. Riddles in another language or tone? Regenerate objects.json with a new prompt.

Honest trade-offs: The first load need internet connection for downloading the AI model, but after that it can run completely offline.

Prize Categories

Best Use of Gemma: Gemma 3 4B, run locally through Ollama, writes every riddle in the game.

Thanks for reading, and now go touch some grass. 🌿

Struggling to learn Git?

Learn Git by solving problems on GitMission.com

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.