DEV Community: ShatilKhan

Engineering of Small Things: Telegram Bots

ShatilKhan — Mon, 08 Jun 2026 05:59:19 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Yunus is a shared finance tracker for couples — built as a Telegram bot with a built-in web dashboard. My wife and I use it daily to track every expense across 14 categories (Bazar, Travel, Rent, Bills, and yes — a category literally called "Wife"). Everything is shared. Everything is real-time. Zero passwords.

The entire thing fits in under a thousand lines of TypeScript.

flowchart LR
    U[You &amp; Your Wife] -->|Send /start| TB[Telegram Bot API]
    U -->|Open Dashboard| TM[Telegram Mini App]

    TB -->|Webhook POST| VW[Vercel: Bot Handler<br>/api/webhook]
    TM -->|Load HTML+JS| VS[Vercel: Static Dashboard]

    VS -->|API calls| VA[Vercel: API Layer<br>/api/stats /api/entries /api/categories]
    VW -->|Read/Write Entries &amp; Budgets| DB[(Turso Edge SQLite)]
    VA -->|Query Data| DB

System overview: You interact with the bot through Telegram. The bot handler runs as a Vercel serverless function. The dashboard is a React SPA served as a Telegram Mini App. All data lives in Turso — a globally distributed SQLite database.

Why Telegram?

Most finance apps are designed for individuals. No one builds for couples. And the ones that exist (Splitwise, Honeydue) are over-engineered for what we needed: "hey, how much did we spend on bazar this week?"

Telegram was the perfect foundation because:

Mini Apps: Native WebView dashboards baked right into the chat app — no separate app to install.
Zero-login auth: Telegram injects cryptographically signed user data into every Mini App. No signup flow.
Cross-platform: Works identically on iOS and Android through Telegram.
Bot interface: Adding an expense is as fast as typing a message.

Demo

GitHub Repository: https://github.com/ShatilKhan/yunus

Screenshots

The Comeback Story

My original build was a 24-hour sprint. I sat down on May 1st, 2026, and cranked out 20 commits in a single day. The skeleton worked — you could add expenses, see summaries, and it had a budget feature. But it was rough.

May  1 — 20 commits: initial scaffold, bot, API, dashboard, everything
May  5 —  3 commits: budgets, summaries, backfill (unfinished)
         ╰──── 26 days of nothing ────╯
May 31 —  3 commits: the comeback — 195 lines changed, 6 files

The 26-day gap wasn't laziness. It was the realization that the product almost worked, but the friction points were killing the experience. Every day I thought "I'll fix it tomorrow" — and I didn't.

Then the GitHub Finish-Up-A-Thon challenge gave me the push I needed.

What was broken

1. The entry wizard took three steps when it should take two.

Original flow: Pick category → Type amount → "Add a note? (Skip)" → Confirm. That extra note step with a Skip button was a tiny thing that added up to major friction. When you're logging 5-6 transactions a day, an extra tap per entry is 150-180 extra taps a month for skipping a step you usually skip anyway.

2. Budget editing didn't exist.

You could set a budget, but you couldn't adjust it. If you wanted to bump the amount up, you had to close the entire budget and create a new one — which triggered an auto-savings of the remainder.

3. No "over since" date.

When the bot alerted that we were over budget, it just said "Over by 5000 Taka." It never told us when we went over. Was it day 3 of the month or day 25? That matters for next month's planning.

4. Bulk backfill was missing.

If I forgot to log a day's expenses, I had to add entries one at a time — going through the full wizard each time. The "Add Multiple" feature existed for today's date, but not for past dates.

5. The dashboard had no CSS.

This was the most embarrassing one. I had beautiful shadcn components (cards, charts, tables) and the build was compiling them... but no one ever imported the CSS file. The dashboard rendered as raw unstyled HTML. It worked. It looked terrible.

The incremental note hack — my favorite fix

This is the kind of fix that's obvious in hindsight but painful in practice.

flowchart LR
    subgraph BEFORE["BEFORE (3 steps)"]
        A1["1. Pick Category<br>Bazar, Travel..."] --> A2["2. Enter Amount<br>500"]
        A2 --> A3["3. Add Note?<br>Skip / Type note"]
    end

    subgraph AFTER["AFTER (2 steps)"]
        B1["1. Pick Category<br>Bazar, Travel..."] --> B2["2. Enter Amount + Note<br>350 lunch with team"]
        B2 --> B3["Confirm &amp; Save"]
    end

    BEFORE -->|REFACTOR| AFTER

The hack is parsing the amount and note from a single input:

// handlers.ts — the "amount" step now parses inline notes
const trimmed = text.trim();
const firstSpace = trimmed.search(/\s/);
const amountStr = firstSpace === -1 ? trimmed : trimmed.slice(0, firstSpace);
const noteRaw = firstSpace === -1 ? "" : trimmed.slice(firstSpace + 1).trim();
const amount = Number(amountStr);

await setSession(`wizard:${userId}`, {
  step: "confirm",
  amount,
  note: noteRaw || null, // null = no note, no extra step
});

Now you type 350 lunch with team — it parses 350 as the amount and lunch with team as the note. No extra step. Straight to confirmation. I also deleted the entire skip_note callback — 17 lines of dead code that existed only to handle a step that shouldn't have existed.

What the comeback changed

Fix	Lines changed	Impact
Inline note entry	+47 / -22	2-step wizard, removed Skip button entirely
Editable budgets	+14 / -0	Change budget amount in-place
Over-budget date	+19 / -3	See exact date budget was exceeded
Bulk backfill	+52 / -3	Bulk import for past dates
Dashboard CSS	+15 / -2	Tailwind styling + safe date parsing
Webhook migration	+28 / -1	Schema migration on cold starts

The Hack: Zero-Login Auth via Telegram initData

This is the most interesting architectural decision: how authentication works without a single login screen.

sequenceDiagram
    participant User as Telegram User
    participant MiniApp as Mini App (Browser)
    participant API as Vercel API
    participant DB as Turso DB

    User->>MiniApp: Open Dashboard
    Note over MiniApp: Telegram injects<br>window.Telegram.WebApp.initData<br>(HMAC-SHA256 signed)

    MiniApp->>API: GET /api/stats?days=30<br>Header: X-Telegram-Init-Data
    Note over API: verifyInitData()<br>HMAC-SHA256 with BOT_TOKEN

    API->>DB: SELECT 1 FROM allowed_users WHERE id = ?
    DB-->>API: exists?
    API-->>MiniApp: 200 { data } or 401
    MiniApp-->>User: Render dashboard

Every Telegram Mini App receives a window.Telegram.WebApp.initData string that's cryptographically signed with HMAC-SHA256 using your bot token. The frontend attaches this as an HTTP header:

// useAuth.ts — attaches initData to every fetch
const apiFetch = useCallback(async (endpoint, options = {}) => {
  const res = await fetch(endpoint, {
    ...options,
    headers: {
      "X-Telegram-Init-Data": initData, // Telegram-signed payload
      "Content-Type": "application/json",
    },
  });
  return res;
}, [initData]);

On the backend, every endpoint verifies:

// auth.ts — HMAC-SHA256 verification
export function verifyInitData(initData: string) {
  const params = new URLSearchParams(initData);
  const hash = params.get("hash");
  params.delete("hash");

  // Sort alphabetically, rebuild check string
  const dataCheckString = entries
    .sort((a, b) => a[0].localeCompare(b[0]))
    .map(([key, value]) => `${key}=${value}`)
    .join("\n");

  // Derive secret key from bot token
  const secretKey = crypto
    .createHmac("sha256", "WebAppData")
    .update(botToken)
    .digest();

  // Verify hash
  const checkHash = crypto
    .createHmac("sha256", secretKey)
    .update(dataCheckString)
    .digest("hex");

  if (checkHash !== hash) return null; // Tampered data
  return JSON.parse(decodeURIComponent(params.get("user")!));
}

Why this matters

This pattern — cryptographic identity via the chat platform — is incredibly powerful for internal tools:

No onboarding: First person to message the bot becomes admin. Add whitelisted users via /admin add <id>.
No password rotation: Telegram handles security.
No session management: Every request is self-verifying.
Shared by default: All whitelisted users see the same data — exactly what you want for a couple's finances.

The Why: A generalizable pattern

This isn't just a finance tracker. The shared Telegram bot + Mini App pattern applies to any two-person dataset:

Shared shopping lists — both partners add items, check them off in real-time.
Chore tracking — log who did what, when.
Pet care schedules — feeding, medication, walks.
Any "two people need to share one simple dataset" scenario.

The key insight: if your users already use Telegram, you don't need a separate app. You don't need login screens. You don't need onboarding flows. You just need a bot that responds to messages and a Mini App that displays data.

My Experience with GitHub Copilot

Every line of this project was written with GitHub Copilot. Not as a "generate the whole app" tool — more like a rubber duck that never gets tired.

Copilot was most useful in three scenarios:

1. Boilerplate generation. The initial scaffold — bot setup, database schema, API handlers — is the most tedious part. Copilot predicted the next 5-10 lines consistently, turning 30-minute tasks into 5-minute ones.

2. SQL query construction. I'm decent at TypeScript, but SQL is where I need the most help. Copilot's suggestions for aggregation queries were correct on the first try:

// Copilot wrote the CASE WHEN inside SUM and GROUP BY
const totalsResult = await db.execute(`
  SELECT
    SUM(CASE WHEN c.type = 'expense' THEN e.amount ELSE 0 END) as total_expense,
    SUM(CASE WHEN c.type = 'saving' THEN e.amount ELSE 0 END) as total_saving,
    COUNT(*) as transaction_count
  FROM entries e
  JOIN categories c ON e.category_id = c.id
  WHERE e.created_at >= datetime('now', '-' || ? || ' days')
`, [Number(days)]);

3. The comeback push. The May 31 commits were the most Copilot-heavy session. By then, Copilot understood the codebase well enough that suggesting updateBudgetAmount() or the date-parsing fallback felt like autocomplete.

The one thing Copilot couldn't help with was debugging production issues (CSS not loading, missing webhook migrations). Those required understanding the deployment flow — where code runs vs. where it doesn't — which no AI had enough context for.

The Stack

Layer	Tool	Why
Runtime	Bun 1.x	Fast Node.js alternative, built-in bundler
Bot Framework	Grammy.js	Telegram bot lib with TypeScript types
Frontend	React 19	SPA rendering
UI	shadcn/ui (New York)	Copy-paste components, full control
Charts	Recharts 3.8.0	Pie chart breakdown
Styling	Tailwind CSS v4	Utility-first CSS
Database	Turso (edge SQLite)	Globally distributed SQLite via HTTP
Hosting	Vercel	Serverless functions + static hosting
Auth	Telegram initData + HMAC	Zero-login, no passwords
Icons	Lucide React	Clean icon set

The unusual choice: Turso (edge SQLite) over PostgreSQL

Turso is SQLite turned into a distributed database. It speaks the same SQL you already know, accessible via HTTP from serverless functions. The tradeoff: single-writer (no concurrent global writes) — irrelevant for a couple's finance tracker. The gain: zero connection pooling, zero migration tooling, zero ops, and the same SQLite syntax you'd use locally.

Production Gotchas

These are the bugs that almost made me give up. This is the most bookmarked section — save it.

1. CSS never loaded on the dashboard

Symptom: Dashboard rendered as unstyled HTML. Cards had no backgrounds. Tables had no borders.
Cause: build.ts used bun-plugin-tailwind but no file imported the CSS. index.css existed. globals.css existed. Neither was referenced.
Fix: One import line:

  // frontend.tsx
  import "./index.css";

2. Webhook cold starts missed schema migrations

Symptom: Budget tracking returned "No active budget" even though budgets existed. No errors.
Cause: initSchema() only ran in the local dev server (src/index.ts). The production webhook handler (api/webhook.ts) never called it. New column = query failed = catch returned null.
Fix: Two changes — added migration to webhook handler AND made the query resilient:

  export async function getActiveBudget() {
    try {
      // Try with new column
      const result = await db.execute(
        "SELECT id, amount, start_date, alert_sent, over_budget_date FROM budgets WHERE end_date IS NULL"
      );
    } catch {
      // Fallback: column doesn't exist yet
      const result = await db.execute(
        "SELECT id, amount, start_date, alert_sent FROM budgets WHERE end_date IS NULL"
      );
    }
  }

3. `new Date()` is not your friend

Symptom: Dashboard showed "Invalid Date" for every entry — but only on some devices.
Cause: SQLite returns "2026-05-31 14:30:00" (space-separated). new Date() behavior with space-separated strings varies by browser. Telegram's Mini App WebView (Safari on iOS) returns Invalid Date.
Fix: Manual parsing:

  const formatDate = (dateStr: string) => {
    const parts = dateStr.split(/[\sT]/);
    const dateParts = parts[0]!.split("-").map(Number);
    const timeParts = (parts[1] || "00:00:00").split(":").map(Number);
    const date = new Date(
      dateParts[0]!, (dateParts[1] || 1) - 1, dateParts[2] || 1,
      timeParts[0] || 0, timeParts[1] || 0, timeParts[2] || 0
    );
    if (isNaN(date.getTime())) return dateStr; // fallback to raw string
    return date.toLocaleDateString("en-US", { /* ... */ });
  };

4. Amount columns returned `NaN`

Symptom: Random entries showed NaN instead of 500.00.
Cause: Number(entry.amount).toFixed(2) — if amount is undefined or null, Number(undefined).toFixed(2) = "NaN".
Fix:

  {Number(entry.amount ?? 0).toFixed(2)}

5. The over_budget_date column didn't exist in production

Symptom: After deploying, the bot couldn't find active budgets.
Cause: The ALTER TABLE migration ran only in the local dev server. Vercel serverless functions are fresh processes — the webhook handler never ran it.
Fix:

  // webhook.ts — runs on every cold start
  async function runMigrations() {
    try {
      await db.execute("ALTER TABLE budgets ADD COLUMN over_budget_date DATE");
    } catch {
      // Column already exists — fine
    }
  }

Quick Reference

Deploy your own in 8 steps:

# 1. Clone
git clone https://github.com/ShatilKhan/yunus
cd yunus

# 2. Install dependencies
curl -fsSL https://bun.sh/install | bash
bun install

# 3. Create a Telegram bot
#    Message @BotFather → /newbot → save the token

# 4. Set up Turso database
turso auth login
turso db create yunus
turso db show yunus --url       # → TURSO_DATABASE_URL
turso db tokens create yunus    # → TURSO_AUTH_TOKEN

# 5. Set environment variables
#    BOT_TOKEN, TURSO_DATABASE_URL, TURSO_AUTH_TOKEN
#    WEBHOOK_SECRET (random string for webhook auth)
#    DASHBOARD_URL (your Vercel URL)

# 6. Deploy to Vercel
vercel --prod

# 7. Set Telegram webhook
#    POST https://api.telegram.org/bot<TOKEN>/setWebhook
#    ?url=https://<your-domain>/api/webhook
#    &secret_token=<WEBHOOK_SECRET>

# 8. Start using it
#    Open Telegram → message your bot → /start
#    You're admin. Add your partner:
#    /admin add <their-telegram-id>

Build it. Use it. Stop wondering where your money went.

Built with TypeScript, Bun, Grammy.js, Turso, Tailwind CSS v4, shadcn/ui, Recharts, React 19, and GitHub Copilot. Open source at github.com/ShatilKhan/yunus.

Engineering of Small Things: Hermes Plugin

ShatilKhan — Mon, 01 Jun 2026 06:11:03 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

Most "give your agent a new model provider" tutorials are stories of bravely subclassing things. You inherit from a base class, you override three methods, you read the wire-format docs of two vendors, you write an adapter, you handle the streaming chunks, you wire it into a settings page somewhere. By the time you've shipped, you've forgotten what you were trying to do.

Hermes Agent's provider-plugin SDK refuses to play that game. The whole thing is a declarative dataclass and one registry call. If the thing you want to add already speaks OpenAI on the wire which most modern gateways and aggregators do — you can be done in twenty-six lines.

This post walks you through the pattern with a real working example: the omnizen-provider plugin I shipped to expose Omnizen's gateway to Hermes. You don't have to care about Omnizen specifically the same shape works for any OpenAI-compatible gateway (Together, Groq, Fireworks, your home-grown vLLM, your in-house router). Omnizen just happens to be a convenient real example because the URL is the only thing you'd swap out.

The shape Hermes wants

A Hermes provider plugin lives at plugins/model-providers/<your-name>/ and ships two files:

plugin.yaml — a short manifest so Hermes can discover and version the plugin.
__init__.py — instantiates a ProviderProfile, then calls register_provider() on it.

That's it. There is no adapter class to subclass, no chat-completions method to implement, no streaming-chunk handler. The ProviderProfile is declarative: you describe what the provider is, and Hermes's existing OpenAI-compatible call path handles all the actual work.

The fields ProviderProfile cares about:

Field	What it's for
`name`	Internal identifier; the key shown in `hermes model`
`aliases`	Short aliases users can type instead of the full name
`env_vars`	Tuple of env vars the plugin reads — Hermes uses this for "is this provider configured?" detection
`display_name`	Human-friendly name in `hermes model`
`description`	One-line pitch under the name in the picker
`signup_url`	Where Hermes sends users who don't have a key yet
`base_url`	The OpenAI-compatible chat-completions endpoint
`default_aux_model`	Model Hermes uses for internal calls (planning probes, tool description embeddings) when no model is specified
`fallback_models`	Models Hermes tries in order when the primary fails or isn't picked

That's the whole API surface. If you can fill in those fields, you have a working provider.

My Plugin

Here's the entire __init__.py for the Omnizen plugin — no abbreviation, no "…and so on":

And the manifest next to it:

You can checkout the code here:
Hermes-Omnizen

What happens at runtime

Omnizen AI integration" width="800" height="1292">

The flow is symmetric on both ends:

At Hermes startup, the plugin's __init__.py executes once. The register_provider(omnizen) call drops the ProviderProfile into Hermes's in-memory registry. From Hermes's point of view, the provider now exists; nothing more is needed.
The user runs hermes model, picks the provider from the menu, and Hermes stores their choice.
The user runs hermes chat — or invokes a tool, or kicks off a multi-step plan, or hops to another agent through the Agent Communication Protocol. Hermes builds a standard OpenAI chat-completions request, reads OMNIZEN_API_KEY from the env, and POSTs to base_url. The gateway answers in OpenAI's SSE envelope. Hermes's existing parser handles the stream and the tool-call frames. None of that code knows the difference between Omnizen and OpenAI proper — the wire format is identical, so the same call path serves both.

The reason this works is the OpenAI Chat Completions API has become the lingua franca for "talk to an LLM." If the thing you're building a Hermes plugin for already speaks OpenAI — and most modern gateways do — your job is describe the gateway, not implement an adapter. The runtime does the rest.

Why the pattern matters (even if you skip the rest of the post)

A few lessons that generalise beyond Hermes:

Treat aggregators as a single "provider" in your agent's mental model. It keeps the pluggable-model interface clean — one wire format, one auth, one place to swap. Don't try to make your agent multiplex five providers itself if a gateway is already doing that work.
OpenAI-compatible is the lingua franca, even when the backend isn't OpenAI. If the thing you're calling speaks OpenAI on the wire, your agent doesn't need to know what's behind it — Anthropic, MiniMax, your home-grown Llama, doesn't matter.
Provider plugins should be declarative, not procedural. Hermes gets this right: I described what the provider is, I didn't write any code about what to do. The runtime knows what to do because the wire format is fixed.
You shouldn't have to maintain a fork to ship a vendor. When your provider SDK is this small (ProviderProfile + register_provider), adding a new vendor is a PR-sized commit, not a months-long integration. Hermes ships fifteen or so of these out of the box — the cost is so low it might as well be free.

If you're building anything that wants to be "model-agnostic," this is the seam to expose.

Gotchas

The things you only learn by shipping one of these:

The default_aux_model matters more than you think. Hermes uses it for any internal call where the user didn't pick a model — planning probes, tool-description embeddings, name-it. If you set it to a heavyweight model, every interaction feels slow and twice as expensive before the user has even said anything. Pick a cheap-fast model for the aux; let the user spend on the chat call. I default to kimi-k2 here because it's roughly the speed of a thought.
Fallbacks are silent. fallback_models swap in automatically when the primary fails (rate limit, 5xx). Great — until you're debugging "why does my answer have a different vibe today?" and realise Hermes quietly fell back two models down the chain. Log the actual responding model: the usage.model field on the SSE stream tells you the truth; the picker only tells you the intent.
The plugin registers at import time. Which means if the plugin module isn't on Hermes's discovery path, Hermes won't see it. Symptom: hermes model doesn't list your provider. Cause: missing __init__.py in a parent directory, wrong working directory at launch, or the plugin folder is in ~/Documents/cool-hermes-stuff and Python can't see it. Fix: install the plugin as a module so it's on sys.path, don't just copy-paste it into a random folder and hope.
OpenAI-compatible ≠ identical to OpenAI. Most gateways disagree with the OpenAI SDK on at least one streaming-chunk shape — usually the final usage frame, sometimes the role on the first delta. Hermes is forgiving here, but if you build your own provider plugin and watch your assistant's last token vanish into thin air, this is where to start looking. Send one real chat through and watch the stream end-to-end before you ship.

References

Hermes Agent: NousResearch/hermes-agent
The worked example plugin: anchorblock/hermes-agent · plugins/model-providers/omnizen/
Omnizen gateway: omnizen.ai
HermsexOmnizen: hermes-omnizen

The gateway-side of this — how the Omnizen API actually fans one virtual key out to multiple model brands behind the curtain — is a separate post for another day. For this tutorial, all you need to know is it speaks OpenAI on the wire. The pattern works the same for any gateway that does.

Hijacking OpenClaw with Claude

ShatilKhan — Sat, 25 Apr 2026 21:55:41 +0000

This is a submission for the OpenClaw Writing Challenge

ClawCon Michigan

Prelude

My boss has been nagging me about "being more verbal" and "showing proof of work" and here I was pushing code when no one was seeing it.

So I decided to try out OpenClaw for as our product manager (our human product manager ran away to Thailand, it's True!)

I have no idea how to set it up or how it works. I had only seen tiktoks saying both good and bad stuff. And a Fireship video I saw weeks ago. That's pretty much my knowledge on this crab.
So today we make it folks!
Our Clawfficer!

The Problem: We Had Claude Code, But Not Claude

Here's the thing. My company gave us access to Claude Code (the CLI tool) through our dev environments. But they didn't give us Claude web accounts or API keys. No console.anthropic.com. No OAuth flow. No nothing.

So I'm sitting there with this powerful CLI tool installed, but I can't even log in the "normal" way because that requires a web account.

Sound familiar? If your office IT is anything like mine, you probably have access to tools but not the accounts that make them "officially" work.

Time to mad-scientist our way through this.

What even is OpenClaw?

If you've come this far to read my post I'm assuming you know what OpenClaw is ¯_(ツ)/¯
I mean it's not like it has the largest growing repo in history ¯_(ツ)/¯

But here's the catch: OpenClaw needs Claude(or any other AI model) to actually do the thinking. And Claude usually needs an API key or web OAuth to work.

Except... we already have Claude Code installed. And Claude Code has a trick.

The Symlink Hack

When you install Claude Code globally:

npm install -g @anthropic-ai/claude-code

It creates a claude binary in your PATH. But most people don't realize, this binary carries its OWN AUTHENTICATION!

When you run claude /login (which we could do because we had the CLI but we can't because boss removed the email account ┐( ˘_˘)┌ ), it opens a browser and does OAuth with your Claude Pro/Max subscription. It then stores a refresh token at:

~/.claude/.credentials.json

Now here's the beautiful part: Claude Code can run in headless mode.

echo "Summarize these commits" | claude -p --output-format=text

No API key. No ANTHROPIC_API_KEY env var. No web console. Just the OAuth token that Claude Code manages itself, auto-refreshing forever.

We basically hijacked the Claude Code CLI's authentication mechanism and piped it into our OpenClaw workflow. The CLI becomes our "API layer" without us ever touching an API key.

This is how Claude Code's OAuth flows into our OpenClaw setup without ever exposing an API key

But of course we ain't done yet!

LOOP!

We have an agent, we have a runtime.
So we still gotta make it survive restarts "( – ⌓ – )

So we wrap it as a systemd user service. Voila! now it starts on boot and restarts if crashes

We override PATH in the systemd unit so it can find the claude symlink.
Without that PATH override, systemd's stripped-down environment can't find Claude Code, and the whole digest flow breaks. It's a one-line fix that took us an embarrassing amount of time to figure out.

Meet the Clawfficer

So what does our "mad science" actually do?

We built a Discord bot that acts as our product manager. We call it the Clawfficer.
If you add clawfficer to your server channel , he will summarize daily and weekly github updates in Natural language.. SO not just generic auto generated bullet points, you could ask it "Hey what's the update on this project?" or "Hey we should add this to the roadmap and assign Shatil" or "I found this issue , can you assign Shatil to get a look at it?" , clawfficer will do his due diligence and assign the respective dev AND tag the message url in the github issue!

Here's some photos we took of Clawfficer in Action!

Here I ask Clawfficer to assign Mahim(my college) to an issue

Here we see the issue was created and assigned with the discord message refrence

It's shown that the issue was created by me because I used my own github PAT(personal access token) for the repo access.

Here we see Clawfficer in his natural environment sharing summaries

Every day at 9 AM and every Sunday at 10 AM, the bot pulls activity from all 8 of our repos across all branches (not just main , we have more repos but just included the most active ones for testing on the agent).

Then it pipes all that data into:

claude -p --output-format=text

And Claude spits back a human-readable prose summary. Not bullet points. Not raw JSON. Actual sentences like:

"Medihelp saw 12 commits across 3 branches this week, mostly schema migrations by Mahim. The eyecraft landing page got its first PR review."

The bot posts this to #roadmap. My boss sees it. I stop getting nagged about "proof of work."

Everyone wins.

The Claude Code symlink approach means you can:

Use your existing subscription (Claude Pro/Max)- same billing bucket as your interactive usage
Run headlessly in scripts, cron jobs, and bots
Never handle an API key - OAuth tokens live in ~/.claude/ and auto-refresh
Deploy anywhere that has Node.js and your user context

It's not "officially supported" as an API replacement. But it works. And for internal tools that need to "just work" without procurement battles, that's gold.

Stuff I Spent way too much time on

1. Branch Coverage Matters

GitHub's /commits endpoint defaults to the default branch. If your team works on feature branches (and they should), your digest will look empty even when people are pushing code.

Fix: Iterate all branches, dedupe by commit SHA. Obvious in hindsight, painful in production.

2. The OAuth Token is Everything

The ~/.claude/.credentials.json file is the single point of auth failure. If it expires or gets corrupted, claude -p exits with code 1 and your digest falls back to bullet points.

Fix: Run claude interactively once to re-auth. The CLI handles refresh tokens automatically after that.

3. systemd PATH is Not Your Shell PATH

Your interactive shell has claude in PATH. systemd doesn't. Explicitly set Environment=PATH=... in your unit file or the spawn fails silently.

The Clawfficer is intentionally minimal. I deliberately didn't build a lot of other regular features. (I mean I only built it yesterday in 8 hours without any prior knowledge of Claw so ¯_(ツ)_/¯ )
But the foundation is there. And more importantly, the authentication pattern is there.Claude Code's CLI isn't just an interactive coding assistant , it's a headless LLM engine that happens to already be authenticated.

Shatil Khan builds things at Anchorblock and argues with crabs on the internet. Follow for more questionable engineering decisions that somehow work.

Giving Your Accounting App a Brain: NestJS "MCP"

ShatilKhan — Thu, 23 Apr 2026 23:23:42 +0000

Recap

Let's be real: in the last blog we were running a local MCP server on my pc, wiring it up to GitHub Copilot like mad scientists. It was awesome. But it was a lab experiment. The "brain" was tethered to my machine.

So... what if we built the brain into the app itself?

The System

So here's the setup. We have three players in this game:

The Web App: React, Vite, Redux Toolkit. The chat lives at /magic-bookkeeping.
The Backend: NestJS, PostgreSQL, Redis. This is where the real work happens.
The AI Service: Claude Haiku 3.5 via Requesty.AI, sitting in between.

User be like: Yo what items we got?
Agent: Calls the itemAll tool to check the item inventory and then cool pause RENDERS a Full UI Component with item details! Not texts!
Also works for like Bengali and Voice inputs by the way

The frontend Contract:

This is what's keeping them connected.

The MCP Layer: But Not Actually MCP?

Plot twist: we call it MCP, but it's not really the Model Context Protocol. There's no stdio. No SSE. No @modelcontextprotocol/sdk. No JSON-RPC. We basically built our own tool-calling façade that looks like OpenAI's function spec so Claude knows what to do with it.

Since this was already a heavy enough ERP system with a lot of code that was written before the AI era,adapting it to a separate mcp server wouldn't be that easy, plus it would also mean we would have to maintain another server.

The Controller (only two endpoints!):

when a user first requests any info list_tool will list all available tools for the ai model
call_tool is where the magic happens, we pass in a system prompt for the ai service so that it knows how to select the tools for any specific operations or which tools to call for let's say getting items or adding new item to inventory.

the tool dto:

why "any" ?
Because every tool has a different structure.
arguments: any is probably the most honest TypeScript type ever written

And here is how the tools are dispatched:

tools.json is read from disk on every request, not cached. The switch pattern means adding a tool requires editing both the JSON file and this service. (cut me some slack , it was my first time building stuff like this :))

Anatomy of a mcp tool

there's two types of tools for this project

Data Tools
Component Tools data tools handles the actual service calls and response payloads while component tool is just used used for generative UI which we'll get to later.

here's a data tool declared inside tools.json:

this is how we handle the tool via our mcp service:

Result is the raw entity returned by the domain service.

Now compare it to the component tool
a create item tool in tools.json:

handler in mcp.service.ts:

Instead of touching the database the backend returns a "render this component" envelope. The frontend's registry maps AiItemForm to the actual React component.

The Cool Part: Generative UI

Okay so the AI can fetch data. Great. But here's where it gets spicy. What if instead of returning boring JSON, the backend says: "Hey frontend, render this form"?

But we can't just ask it to use html templates , no? The forms need to dynamic, the same form the user uses to enter item details or add a new entry to the inventory should also be rendered here basically. But how did I achieve this?
Quite simply I wrap those already existing form components as separate render-able components , put them in a component registry and then it's just a matter of prompting the model correctly so it renders the right form based on user intent.

The response type that makes this possible:

When render_type === 'component', the frontend looks up a component by name in a static registry and renders it inline in the chat. No LLM-generated markup, no code-eval; the model only selects which component and fills its props from the Tool Registry:

Adding a new generative component requires editing this file. There is no runtime discovery ,the server can only refer to components the frontend has already imported.

Finally it all comes together inside the Chat!

If component_name isn't in the registry, the branch silently falls through to , no error, no fallback UI.Callbacks are hard-wired for AiItemForm only.(Cause I'm lazy)
The form-vs-list distinction is a string-includes check on the name.

And lastly here's how a user's message would flow through the system and repond with generative components:

it's 5 am in my place now so that's it for now, you can checkout the other blogs in the series or don't I don't care, this was a company project so I couldn't share the full code :)

Sayonara people

aurthor's note: maybe I'll add in a video later on of the working project, it's obviously not something you could just put in prod but something that at least works, some parts need more work, but if you've Actually read this far! Thanks!

Moneyshot#1: Month 1 till I make $1k MRR

ShatilKhan — Sat, 21 Feb 2026 20:11:23 +0000

Hello again Internet!
I am writing after a long while and this blog is a bit different from my engineering blogs. This is more of a practical blog of some goals I am going to set for myself, which I had previously done years ago for coding or learning to code & I guess and it has paid off and I wanted to do that again but with a different goal in mind.

I made this video back in 2023 probably and around the end of 2023 or 2022 I think where I kind of publicly posted that I'd code every day

which I mean I didn't code every single day but you know I'll share the GitHub repo or GitHub profile after I had posted that video,

and I actually committed to it, and I actually started doing some projects and contributing to some open source projects. And I did get to work with pretty amazing people. I did get to work on a project for AWS Open Source, which obviously none of them sprouted into success, or none of them sprouted into major things. But what happened was after that the following year I got my first job and then I have been working professionally with startups and agencies since then So yeah it didn't make sense at that moment when I actually posted the video that I code every day but it now makes sense that I did commit to something and then I started doing it. And I'd done that previously years ago as well when I first started to code. and when I first started I used to do digital art as well so when I first did digital art ,there's thing called Inktoberfest where you would like draw something for the entire month of October and I also did Hacktoberfest where you would code or contribute some code to some repositories (open source repositories) for the entire month of October and these things didn't mean that you would probably be successful at any specific coding area or any specific skilled area but the goal was to be consecutive and consecutively keep doing it without worrying about the results.

After I started working professionally as a developer since the last two years, the software industry as a whole has shifted drastically that I've experienced. I do three part-time jobs. One of them is an office job. And I think I'm doing more work than any developer would have done three or four years ago. that's mainly due to AI and AI has enabled people to do more but it has been demanding from people more as well. The one thing that I have looked and I have experienced is that the overall outlook of everyone and every industrial mechanism has changed from improving or focused on results to just making money So the key mechanism of the AI industry or the software industry as a whole has been to make money obviously. But there was a video from GitHub around 5 or 6 years ago, you can watch it on YouTube, it was basically an advertisement for GitHub, but not a typical advertisement. It wasn't advertised in a way like GitHub as a product, but rather it advertised code as a means to connect different parts of society. So, the video was mainly about a girl making a prosthetics arm for her brother, and in another part of the world, somebody else used that code to build something else that they needed.
With the current industrial standards, I feel like that wave has faded. Like actually developing something for betterment, actually trying to, I mean people are still developing things to help people, but most of those things are more focused on profitability. So, they're helping people, but they're also focused on actually making money. And even though I say that the outlook has changed, I don't mean that in a negative way, but moreover it has become much easier for a single person, like for example, Open Claw or Peter Steinberger, people like those to make money or make profitable businesses out of their skillsets. And obviously not everyone can do it, you need a lot of expertise and global experience, but there's also people who have been building, indie hackers who have been developing for years. And I wanna build shitty products that's also one goal is to build a lot of shitty products and have a lot of fucking fun doing it for people, for myself, but mostly to enjoy the process that I have enjoyed before just building things not just software but anything.

If money is the main goal or like the standards of the industry have changed to making money or making it easier for people to run businesses then let's do that. Let's just go for that and make as much as possible so that we can actually try it out. I've already said that I tried out everything. I tried out art, doing art and doing programming and going all in into it because it was so interesting. And right now this trend of building stuff is very intriguing. So that's why I feel like I should challenge myself, but this time with a specific number in mind to get to that goal.

This goal is much different from the previous goals I set for myself. The primary one was to just learn things. Learning to code, learning to draw, learning anything basically. And the secondary goal was to earn something, earn some money or some monetary means by doing what I love or doing what I'm good at, which was the skills I had previously learned from my first goal.

This time I am gonna set a specific amount or specific target in mind for the goal which is the 1k MRR which means that it's not just like a specific amount per month but more of it needs to be be set in some rules and those rules I do need to follow through. So the first and foremost would be that it obviously needs to be a MRR because it needs to be a monthly recurring review. It's not just I need to make that amount once and then the goal is set. It wouldn't work like that.It would need to be a sustainable MRR or a recurring revenue per month. That is why I set the goal with the $1000 in mind.

These are the rules I’m setting for myself. The product or the way I’m going to reach that monetary target, will be by my own means. So it cannot be any part-time job, any full-time job, or something I’m doing for my employer. I am going to be the owner of the product.

I’m also keeping the field a bit broad, and maybe I’ll broaden it later. Primarily because I don’t want to focus only on SaaS products. I can do more than SaaS, and I don’t have to confine myself to that. I could do research projects. I know how to program a microcontroller or a Raspberry Pi, I can figure it out. I’ve worked with Arduino and a bit of IoT. I’ve done basic UI/UX design and graphic design. So I can use any of those skills.

That’s one rule. I’d say that’s the second rule—the first is that it needs to be my own thing, not from an employer. The second is that I can utilize any of the skills I have to produce that amount. The third is using any tools at my disposal. That means not banning AI, but using it efficiently, not as much as possible, because that could ruin things. I try to avoid using AI for everything, and instead use it where it makes sense, where it’s better than doing it myself. For example, I do some QA tasks with AI using specific tools, cloud code, and other workflows.

Another rule is that working with clients is allowed, as long as I’m the one building the projects. I’ll still own them, even if I’m supplying a service. So it could be like a SaaS, but even if it’s not, there's IoT-based projects or other things I can produce.

The final step would be to broaden the horizon later on, maybe investing in something beyond software or hardware. I’m not sure yet, but it’s something I think I could explore.

That’s the primary direction I’m setting for myself, and that’s what I’m going to follow. I’m not sure how far I’ll get, but I’m going to keep going toward this goal.

Check out my new blog on MCP!

ShatilKhan — Wed, 20 Aug 2025 10:02:39 +0000

ShatilKhan

Aug 3 '25

Building my first Local MCP server using Swagger & OpenAPITools

#mcp #openapi #softwareengineering #tooling

6 min read

Building my first Local MCP server using Swagger & OpenAPITools

ShatilKhan — Sun, 03 Aug 2025 14:30:00 +0000

Let's be real: enterprise software can feel like a labyrinth. Our app at AnchorBlock, AnchorBooks.ai, is a beast with hundreds of features for finance and bookkeeping. It's powerful, but finding what you need can mean a dozen clicks through a maze of menus.

So, I got this crazy idea: what if you could just talk to the app? What if you could say, "Hey, create an invoice for client X with these items," and it would just... happen?

That's the dream, right? To give our app a brain. This is the story of how I took the first step, moving from a complex API to a simple chat prompt. In this first part of our two-part series, we're going full mad-scientist-in-the-lab. We'll build a local tool server using the Model Context Protocol (MCP) and hook it up to GitHub Copilot, proving we can control our entire backend with plain English.

Let's get our hands dirty.

Step 1: The Rosetta Stone for AI - Turning an API into Tools

An AI model, as smart as it is, has no idea what a POST /api/item request is. You can't just give it your backend URL and hope for the best. It needs a manual, an instruction book that clearly explains what's possible.

For us, that manual was our Swagger (OpenAPI) documentation. With over 249 endpoints, our NestJS backend was well-documented, which turned out to be the secret ingredient. Each endpoint definition, with its inputs and outputs, was a potential "skill" we could teach our AI.

But was I going to manually write a wrapper script for all 249 endpoints? Absolutely not. My laziness (I call it efficiency) led me to a game-changing tool: OpenAPITools.

Think of OpenAPITools as a magic translator. You feed it your swagger.json file, and it spits out a ready-to-use MCP server structure, complete with Python scripts for every single API endpoint. It's like giving the AI a universal remote for our app, and OpenAPITools just programmed all the buttons for us.

Here’s a quick look at that workflow:

Step 2: A Peek Under the Hood: The Anatomy of a Single Tool

Let's zoom in on one example to see how this actually works. Say we want to create a new item in our inventory.

In our NestJS backend, we have a CreateItemDto that defines exactly what data is needed. It's decorated with @ApiProperty for Swagger, which is key.

The Source of Truth: dto/create-item.dto.ts

When OpenAPITools reads this, it generates two crucial files:

The AI's Cheat Sheet: tools.json (Snippet) This file is the manifest. It tells the AI, "Hey, there's a tool called ItemCreator. It needs a name, a type, a price, and so on." The schema here is a direct translation of our DTO.

The Worker Bee: ItemCreator-main.py This Python script is the muscle. Its job is dead simple: get the JSON input from the AI, build a real HTTP request with the right headers (including our JWT token for auth!), and fire it off to our actual NestJS backend.

Extract parameters from the AI's request

Build the payload for our NestJS API

Get our secret JWT token from the environment

Make the actual API call!

Send the result back to the AI

And just like that, every single one of our 249 endpoints had its own little Python worker, ready and waiting for orders.

Step 3: Firing Up the Local Brain

With our tools ready, we needed a "switchboard operator" to direct traffic from the AI agent to the correct Python script. The generated project includes a lightweight Node.js server that does exactly this. For local testing, it runs in stdio mode, communicating silently in the background.

The stdio-server.js file orchestrates everything, but the gist is simple:

It starts up and reads our tools.json to know what tools are available.

It listens for two main commands from an agent: ListTools (what can you do?) and CallTool (do this thing!).

When CallTool comes in, it finds the right Python script, passes along the inputs, and pipes the result back to the agent.

I just pop open my terminal, run node index.js, and my local AI "brain" is online.

Step 4: The "It's Alive!" Moment: Hooking up GitHub Copilot

This is where it gets really cool. We have a server running on our machine that knows how to use our app. Now, let's connect an AI to it. GitHub Copilot's agent mode is perfect for this.

Here’s how you can do it too:

Light Up the Server In your terminal, navigate to your MCP project folder and run the server.

node index.js

It will just sit there, waiting. That's what it's supposed to do!

Tweak Your VS Code Settings
Open your VS Code User settings.json file. The easiest way is to press Ctrl+Shift+P (or Cmd+Shift+P) and type Preferences: Open User Settings (JSON).
Tell Copilot About Your Server
Add this snippet to your settings.json. This tells Copilot, "Hey, there's a tool server available. If I say @anchorbooks, you should run this command to talk to it."

{
  // ...your other settings...
  "github.copilot.mcp.enabled": true,
  "github.copilot.mcp.servers": {
    "anchorbooks": { // Call it whatever you want
      "command": "node",
      "args": [
        // IMPORTANT: Use the FULL, absolute path to your index.js file
        "G:\\Office\\anchorbooks\\item-mcp-tool\\index.js"
      ]
    }
  }
}

Pro Tip: Make sure the path is correct! This trips up a lot of people.

Let the Magic Happen Restart VS Code to make sure the settings take effect. Now, open the GitHub Copilot chat panel and type @—you should see your server's name (@anchorbooks) pop up!

I sent my first command:

@anchorbooks create a new item of type goods named "Premium Arabica Beans" with a selling price of 25 and purchase price of 15. Use unit "kg", sales account 1, purchase account 2, for organization 1.

I held my breath. A few seconds later... success!

Copilot parsed my sentence, correctly identified the ItemCreator tool, mapped all the parameters, and sent the request to my local Node.js server. The server executed the Python script, which made a real, authenticated API call to my backend. A new item was created in my database, and the JSON response appeared right in my chat window.

(Placeholder: Screenshot of the Copilot chat with the prompt and the successful tool execution and JSON response)

It felt like magic. I could now manage invoices, update bills, transfer stock—perform over 33 complex backend operations—just by chatting with Copilot.

What's Next?

We've built a powerful local playground. We proved that we can bridge the gap between human language and a complex API. But let's be honest, this is a lab experiment. The "brain" is tethered to my machine and depends on an external tool like VS Code.

This setup is awesome, but it's not a product.

In Part 2 of this series, we're cutting the cord. I’ll show you how we took this successful experiment and turned it into a real, integrated feature by:

Ditching the local server and building the MCP logic directly into our NestJS backend.

Creating our very own chat interface right inside the AnchorBooks.ai app.

Plugging into powerful models like Claude 3.5 for smarter, faster tool use.

Stay tuned, because that's when we truly give our application a mind of its own.

Author's Note: No code repos shared here since it was a company project. I wanted to share my experience building stuff & will continue the story in the 2nd blog along with more code examples for better understanding. This workflows also works with complex operations like invoice creation or generating new customer and multi stage workflows as well which we'll discuss in future blogs.

Stop Your Code From Having a Mid-Life Crisis. An Introduction to OOP.

ShatilKhan — Sun, 27 Jul 2025 18:34:46 +0000

ShatilKhan

Jul 27 '25

Engineering of Small Things #5: OOP Basics in TypeScript

#typescript #beginners #tutorial #oop

5 min read

Engineering of Small Things #5: OOP Basics in TypeScript

ShatilKhan — Sun, 27 Jul 2025 14:30:00 +0000

Ahoy!
Back after quite a while, I originally planned to release this blog & couple others a long time ago but I guess life gets in the way.

Today we are going to look into some basic concepts of Object Oriented Programming.
And this isn't meant to be any kind of high level overview. Just me sharing my learning.
So! with that , let's begin!

What is Object Oriented Programming anyway?

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code: data in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods).

The Six Pillars of OOP: A Family Story

1. Classes: The Blueprint of You

First things first, what's a class?

Think of a Class as a blueprint. It's not a person, but it describes what makes a person. For instance, a Human class would be a blueprint defining that all humans have properties like a name, age, and eyeColor.

2. Objects: You, the Instance

So if a Class is the blueprint, what are you? You, my friend, are an Object.

An object is a real, living, breathing instance created from a class. While the Human class is the idea, you are the implementation. You have a specific name, a specific age, and so on. In code, we create a 'new' object from our class.

A better visualization of the difference between Objects & Classes:

3. Encapsulation: Your Personal Bubble

Encapsulation is about bundling your properties (data) and your methods (behaviors) together in that neat little Human object. It also means you can have secrets!

Some things about you are public, like your name. Anyone can ask for it. But some things are private, like your deepest, darkest thoughts. You keep those encapsulated. In OOP, this prevents outsiders from messing with the internal state of an object.

Onward we go!

4. Abstraction: Don't Overthink it!

Abstraction means hiding the complexity and showing only the essentials.

Think about meeting someone. You say "Hello!" and they say "Hello!" back. You don't need to know the complex biological processes of how their brain processed your greeting and formulated a response. You just need to know the simple interface: the greet() method. Abstraction hides the messy details.
Similar stuff happens when you go for a walk, you don't need to understand how your body keeps balance or how it pushes you forward to follow Newton's law. You just need to put one feet in front of the other.

You don't get the whole story, just the parts you need to interact with.

5. Inheritance: Your Family Legacy

Serious Life Talk!
Let's say you fall in love! And Decide to have babies!

Your children will inherit traits from you. They might get your last name or your eye color.

Inheritance lets a new class (a Child) adopt the properties and methods of an existing class (a Parent). This saves you from rewriting the same code over and over. The child can have all the parent's features, plus their own unique ones.

So let's say YOU , The Parent, are a human:

You have your name, age & last name
And then you decide to have your first child:

You name your first child "Itchy"
So NOW your child will naturally inherit your last name:

Now we can use the properties the Child inherited from the parent to carry out tasks:

Just like that your kid got your last name & other stuff from your DNA (Class). Kid could inherit your crippling depression & anxiety as well.

6. Polymorphism: Different Folks, Different Strokes

Polymorphism is a big word for a simple idea: "many forms." It means you can treat objects of different classes in the same way, but they each behave in their own unique style.

Imagine you ask everyone in the family to doTheirChore().
The Parent might respond by "mowing the lawn", while the Child responds by "tidying up toys". The same instruction (doTheirChore()) produces different results. That's polymorphism in action!
We could add a chore(funtion) to each respective Classes (Parent & Child)

We can then assign the chores to the classes:

And finally we can add new function calls & execute the Chores!

Wrapping Up

And there you have it! The big ideas of OOP, explained through the story of you and your family. It's a powerful way to structure your code, and once you get the hang of it, you'll see how it makes building complex things so much more manageable.

I'm still on this learning journey myself. A massive shout-out to the repo that got me started and helped me understand these concepts in depth:

jafari-dev / oop-expert-with-typescript

A complete guide for learning object oriented programming pillars, SOLID principles and design patterns with TypeScript!

Object Oriented Programming Expert with TypeScript

This repository is a complete guide and tutorial for the principles and techniques of object-oriented programming. It can be a reference for all interested in programming and software developers. You will find simple and practical examples in all sections to make the concepts easier to understand.

View on GitHub

And if you want to see my personal study notes and the code examples I'm tinkering with, I've open-sourced them here:

My OOP in TS Study Repo:

ShatilKhan / OOP-TS-Study

Study on Object Oriented Programming with TypeScript

OOP-TS-Study

Study on Object Oriented Programming with TypeScript

What's Object-oriented-programming?

Class
Objects
Data Abstraction
Encapsulation
Inheritance
Polymorphism

We can use TypeScript Playground to run the code. We can also use VS Code directly.

Running TypeScript Code in Visual Studio Code

Prerequisites

Node.js and npm installed on your machine.

Steps

Install TypeScript Open the terminal in Visual Studio Code and run the following command to install TypeScript globally:
```
npm install -g typescript 
```
Check TypeScript Installation: Verify that TypeScript is installed by running:
```
tsc --version
```
Create a tsconfig.json File In your project directory, create a tsconfig.json file to configure the…

View on GitHub

You might see that some of the code is a few months old, as I stated at the beginning I initially planned to publish this blog a while ago but just couldn't find the time.
And I'm also experimenting with writing techniques & how to better present coding topics.
If you like this one, make sure to check out other blogs in this series.
Engineering of Small Things Series is basically written up to share where I explore fundamental topics of how the web works.
More to come soon!
And Happy Coding!

ক্লাউড কম্পিউটিং কি জিনিস ?

ShatilKhan — Fri, 07 Feb 2025 06:27:30 +0000

Author's Note: This blog is a bit different compared to my other blogs. This blog is specifically meant for student who want to learn a basic idea about cloud computing. This is also part of my work as an AWS Cloud Club Captain at my Campus. So on this blog I try to give students a general idea about cloud. And since my primary audience for this blog is Bangladeshi students I thought I would try to explain things in Bengali to keep it fun!

এখন আসি আসল কথায়, ক্লাউড কম্পিউটিং জিনিস টা আসলে কি?

আপনার Day-to-day লাইফের সবচেয়ে সহজ আর চেনার মত একটা উদাহরণ দিতে গেলে বলা যায় ড্রাইভ স্টোরেজ(ড্রপবক্স, গুগল ড্রাইভ ইত্যাদি) । এইধরণের সার্ভিস গুলা মোটামুটি সবাই ইউজ করে বা না করলেও ফিচার গুলা সবার ফোনেই এক্টিভ । এই ক্ষেত্রে আসলে কি হচ্ছে?
ধরেন আপনি আপনার কোন ছবি ড্রাইভ স্টোরেজে রাখলেন, এখন সেটা আপনি যেকোন জায়গা থেকে এক্সেস করতে পারবেন।
এই যে আপনার ফাইল/ছবিগুলা রাখলেন, এখন আপনার ফোন থেলে ডিলিট করে দিলেও সেটা পরে আপনি এক্সেস করতে পারবেন, right?
এই ডাটা টা সেভ হচ্ছে কোন এক বান্দার সার্ভারে, আপনি যখন ডাটা চাইবেন তখন বেসিকেলি সার্ভার সেই ডাটা আপনাকে দিবে। এই যে দূরে কোন সার্ভারে ডাটা রাখার যেই ব্যাপার টা, এটাই ক্লাউড কম্পিউটিং এর সবচেয়ে বেসিক অংশ।

আরো কিছু বেসিক উদারণ হচ্ছে ওয়েবসাইট হোস্ট করা। ওয়েবসাইট হোস্ট করলেও সেটা কোন সার্ভারে থাকে, পরে যে কেউ সেখান থেকে এক্সেস করতে পারে একটা পাবলিক ডোমেইন এড্রেস দিয়ে।

এখন আসি Amazon Web Services বা AWS নিয়ে

"Amazon Web Services, Inc. is a subsidiary of Amazon that provides on-demand cloud computing platforms and APIs to individuals, companies, and governments, on a metered, pay-as-you-go basis. Clients will often use this in combination with autoscaling." - Wikipedia

এখন এই কথার মানে কি? on-demand, metered, pay-as-you-go, auto-scaling?

এই ব্লগের উদ্দেশ্য , যে স্টুডেন্ট ক্লাউড নিয়ে কিছুই জানে না তাদের কে জানানো। তাই AWS কে সহজ ভাবে বুঝাচ্ছি।

AWS হচ্ছে বিশ্বের সবচেয়ে বড় ক্লাউড প্রোভাইডার। মানে AWS বিভিন্ন ধরণের ক্লাউড রিলেটেড সার্ভিস দেয় কাস্টমার দের। এর মধ্যে কিছু বেসিক সার্ভিস হলো ওয়েবসাইট হোস্টিং, ডোমেইন সেটাপ , ডাটাবেস ম্যানেজ করা ।
এখন কথা হচ্ছে এগুলা দেয়ার কারণ কি?
ধরলাম ক্লাউড কম্পিউটিং নামের কোন জিনিস নাই। এখন আপনই একটা কম্পানি খুলতে চাচ্ছেন, সেক্ষেত্রে আপনার ওয়েবসাইট লাগবেই। এখন আপনাকে সেই সাইট চালাইতে গেলে আগে নিজে একটা সার্ভার কম্পিউটার কেনা লাগবে, যেগুলার দাম লাখ লাখ টাকা। সেই সার্ভার রাখার জন্যে রুম লাগবে, রুমের আবার এসি লাগবে, নাহলে সার্ভারের মাথা গরম হয়ে যাবে।

তার মানে আপনার বিজনেস শুরু করতে গেলে আপনার বড় একটা এমাউন্টের ইনভেস্টমেন্ট লাগবে।
এখন আসি ক্লাউডে।

আপনার সার্ভার লাগবে? ভাড়া নেন!
AWS বেসিকেলি নিজেদের সার্ভার গুলা আপনাকে অল্প মূল্যে ভাড়া দিবে। যার বদলে আপনাকে pay-as-you-go বা যতটুকু স্টোরেজ আপনার লাগবে সেই অনুযায়ী পেমেন্ট করবেন।

এখন কিছু বেসিক AWS সার্ভিস নিয়ে আলোচনা করি।

S3 বা Simple Storage Service হচ্ছে AWS র সবচেয়ে বেসিক অফারিং, যেটা আমরা মোটামুটি ডেইলি কোন না কোন ভাবে ইউজ করি। যেমন আপনই গুগল ড্রাইভে কোন ছবি রাখলে সেটার ড্রাইভ লিংক যে কারো সাথে শেয়ার করতে পারেন, S3 সেই সুবিধাটাই দেয়। তবে এক্ষেত্রে আরো অনেক ফিচার আছে, আমি ব্যাপার অনেক বেশি সিমপ্লিফাই করে বলছি।

এটার সহজ একটা উদারণ দেই, এই যে ব্লগ টা পড়ছেন, যেই ইমেজ গুলা এখানে দেখতে পাচ্ছেন, এগুলা আসলে আমি যখন আপলোড করছি, জিনিস টা আগে S3 তে যায়, তারপর সেখান থেকে একটা লিংক জেনারেট হয়, তারপর সেই লিংক টা এখানে আসে, যেটার মাধ্যমে আপনারা ইমেজ গুলা দেখতে পান।

এখন আসি Amplify নিয়ে, এগুলা নিয়ে ওতটা বলবো না কারণ বিগিনার হিসেবে জাস্ট ক্লাউডের আইডিয়া দেয়ার জন্যে বলা।
Amplify দিয়ে বেসিকেলি আমরা আমাদের যেকোন ওয়েবসাইট হোস্টিং আর ডিপ্লয়মেন্টের কাজ করতে পারি। যারা আগে কখনো নিজেদের কোন ওয়েবসাইট হোস্ট করে থাকবেন তাদের জন্যে জিনিস টা বোঝা সহজ হবে।
বেসিকেলি আপনার GitHub রিপো বা কডের ফাইল আপলোড করলে Amplify সেটা হোস্ট করে একটা হোস্টেড ডিপ্লয়মেন্ট লিংক দেবে। ডোমেইন নেম সেটাপের জন্য আমরা AWS Route 53 র মত সার্ভিস ইউজ করতে পারি যেখানে আমরা কোন কাস্টম ডোমেইন নেম কিনে সেটাপ করতে পারবো। তবে সেগুলা এই ব্লগের বিষয় নয়, আগামী কোন ব্লগে এই রিলেটেড প্রসেস নিয়ে আলোচনা করবো।

এবং সবশেষে EC2 বা Elastic Compute Cloud, এটাও বিগিনারদের জন্য বোঝা একটু কমপ্লেক্স মনে হতে পারে। তবে আমি চেষ্টা করবো সহজভাবে বোঝানোর।
ধরেন আপনার ল্যাপটপ বা পিসি টা মানধাতার আমলের, ৪ জিবি র‍্যাম , ৪ কোরের প্রসেসর ইত্যাদি। এখন আপনই আপনার পিসিতে কোন একটা রিসোর্স ইন্টেন্সিভ কাজ করতে চাচ্ছেন, যেটার জন্যে অনেক র‍্যাম লাগবে বা আরো বেশি প্রসেসিং পাওয়ার লাগবে।
EC2 আপনার জন্যে একটা ভার্চুয়াল পিসি / মেশিন (VM) রেডি করে দিবে। মানে ধরেন আপনার ৮ জিবি/১৬ জিবি র‍্যামের পিসি লাগবে। ওই যে আগে বলছিলাম যে সার্ভার ভাড়া নেয়ার ব্যাপার টা। এমাজন বেসিকেলি অনেক গুলা সার্ভার কম্পিউটার শেয়ারে ভাড়া দিচ্ছে। আর একটা সার্ভারের র‍্যাম কয়েকশ জিবি বা তার বেশি হয়, প্রসেসিং পাওয়ারও । তখন ওরা বেসিকেলি আপনাকে নির্দিষ্ট এমাউন্ট ভাড়া দিবে , যতটুকু আপনার দরকার (৮ জিবি র‍্যাম/৪ কোর প্রসেসর, ১৬জিবি র‍্যাম / ৮ কোর প্রসেসর)। এবং আপনই যতটুকু ইউজ করবেন সেই অনুযায়ী আপনার খরচ আসবে। এখন প্রশ্ন আসতে পারে, তাহলে এই যে এত হাই লেভেলের মেশিন লার্নিং মডেল বা এডভান্স এলগিরদম নিয়ে বড় কম্পানিগুলায় কাজ হয়, এগুলা তাহলে ওরা এভাবে করে?

ঠিক ধরেছেন!
হ্যাঁ অনেকেই নিজস্ব সার্ভার কিনে,কিন্তু ছোট কম্পানি বা স্টার্টাপ গুলা ম্যাক্সিমাম এভাবেই কাজ করে। আপনার বেশি লার্নিং মডেল ট্রেইন করাতে যেই জিপিউ রিসোর্স লাগবে সেটাও ক্লাউডের মাধ্যমে এক্সেস নিয়ে করা হয়। তবে এগুলা বিগিনার টপিকের বাইরে পরে তাই অন্যদিন আলোচনা করবো।

ব্লগ টা মেইনলি এবস্যুলুট বিগিনার দের উদ্দেশ্য করেই বানানো। কারণ অনেক ক্ষেত্রেই বাংলাদেশে বেশিরভাগ ভার্সিটি গুলোতে আলাদাভাবে কোন ক্লাউডের কোর্স বা এধরণের শেখার সুবিধা নাই। কিন্তু AI নিয়ে সবাই লাফায়, ওয়েব ডেভেলপমেন্ট নিয়ে এত মাতামাতি, দিনশেষে কোন না কোন পর্যায়ে যায়ে ক্লাউডের কাজ শিখতেই হবে। তাই এই ব্লগের উদ্দেশ্য ছিল স্টুডেন্ট দের সেই বিষয়ে বেসিক আইডিয়া দেয়া।

Author's Note: If you want to learn more about the topic's mentioned & would love to see more blogs on this, I'd appreciate if you comment down below to show your interest.

Engineering of Small Things #4 : WebSockets

ShatilKhan — Fri, 27 Dec 2024 05:09:07 +0000

Hello Again!

Recently I was working on a website where I needed to pull data from the server periodically, it wasn't really required as the database updated only once a week or so. But still I thought it would be nice to have a way if I could periodically get data from server without having to request it from the client side. SO then I came across socket servers!
It basically allows two-way communication between a client & a server. We can also setup timeout methods so that the server automatically sends data to the client on a regular interval.
So I studied a bit on the topic , got some help from chatgpt :)
But also I like to learn from experience engineers rather than regular courses. One of the engineers I admire is @husseinnasser . I followed a short crash course from Nasser about WebSockets as well. Because as a non-CSE student I didn't really know how the underlying connections work. So I needed to learn from scratch!
And it was indeed a great experience. I first learned about protocols! HTTP, HTTP 1.1, TCP, UDP
This gave me a good foundation to understand what's going on in a WebSocket server.
Then I made a raw websokcet server using http. I set up certain breakpoints & tested the connection between the server & the client. It was unique way to learn because I didn't write much frontend code for this. Instead I tested the client by directly sending client messages from the browser console!

First we'll need a basic http server :

Basic Package Requirements & Connection :

Now there is a Null connection variable here, we'll get to it later.

Base http server initiate:

But this is just a request-response server. Once a response is received, connection is gone. We need a reliable connection. This is where TCP comes in. When I pass in this http server into a WebSocket server it will then send an UPGRADE 1.1 header request to the server from the client side. It will request to switch protocol from http to http 1.1 & establish a TCP connection for full-duplex communication.
Pass in the http server into the websocket server to create a TCP connection:

Server Listening:

the websocket server can choose weather to accept the request or not ,
accepting sends back swithing protocol 101 response , which opens up the full duplex communication between client & server
1st parameter is a custom protocol , could be for chatting , gaming, null means we'll accept anything, no specific protocol needed
2nd paramter - we can check the origin of the request, generally the url the request was sent from , to checck if it's atrusted source
Below are the events that we can use , open, close, message etc.The main point of WebSockets is having these events.
When each event occurs we can get a certain response from server automatically without the client needing to initiate a request
Socket Events:

Notice we see the null connection here that we initiated in the beginning. This tells the server that we can accept ANYTHING. Any type of data is accepted as we are just testing.
Now we can send & receive connection between the server & client
From the Debug console in VS Code we can send a server message:

Then from the browser console, we can send a client response:

The connection stays open as long as nobody closes the connection.
If the server shuts down, the connection will close
if the client browser initiates the event ws.close the connection will close.
But this is just basic connection. Now We will make a function that will keep sending messages from the WebSocket server to the client on a regular interval. Think of game streaming , twitch, video streaming etc.

Pass in the function after we open the connection:

We can log this stream of messages on the client side using onmessage event

Voila We just made a full-duplex two-way communication between a server & a client.

Super fun stuff to learn!

Codebase:

ShatilKhan / socket-server

exploring how socket servers work

socket-server

exploring how socket servers work

View on GitHub

Check out the video to see the code in action:

Engineering of Small Things #3 : Small Language Models

ShatilKhan — Thu, 19 Dec 2024 10:33:28 +0000

Disclaimer! I am NOT an AI Influencer! This is literally just me learning about how to implement a hugging face model for the first time.
And Boy Was it Hard! :))

What is this even about?

I built a document Question & answering bot for this demonstration. It takes an Image & we can query & ask questions regarding that Image.
I had no idea how to implement language models going into this. So it was a really fun experience. Now this is part of a bigger project. Today I'm just sharing one part of it.

Going Crazy

This was for a hackathon project where I was trying to use @streamlit & HuggingFace , I never even had a hugging face account & had only basic tutorial level experience on @streamlit . But I really wanted to learn & implement something on my own. I was tired of following tutorials & it didn't matter if it was a standard solution or not!

But like the heading says, I did go crazy a couple times :)

The beginning of Insanity

Now I'm a web developer who had only heard about hugging face, didn't really care about the hype. But then I decided to experiment a little with this tech. I did not have the necessary setup on my local device , so firstly I had to install PyTorch & TesseractOCR on my local PC first. I will not be sharing this trauma :)
Those who know...know 😫

But I will take you through how I implemented it!

First we need the basic ingredients! A transformer!

How does it work? - I have no f**king Idea!
What does it do? - Makes language model go "brrrr"

And a library to read Image files.

Basic Imports:

Now to initialize our pipeline.
What does that even mean? Basically we are selecting a language model from huggingface model catalogue. And also setting what type of model that is. Here comes the main point of this blog. Small Language Models. At first I did try to use a popular Large Language Model (Mistral) , but here's the thing, after we've initialized a pipeline, when I run the program for the first time, it needs to download the model onto my local device. But like I've stated before, I have shitty internet & the Mistral-8B was like 2GB+. Every time I would start the project, the model would download halfway & give up.
So I opted to choose a Small Language Model called impira/layoutlm-document-qa

This is a 500 MB model that was a good enough job of answering questions from an uploaded document. But there's some parameters, like the uploaded document needs to be an image, hence the need for a separate library to read image files (PIL).

Pipeline Initialization:

But here's the hard lesson I learned. I used streamlit cloud to deploy the project. So it was running on a cloud gpu. But after a few minutes of usage it would become WAY TOO resource intensive & the project would shut down due to streamlit cloud's resource limitations. I couldn't figure this out for SOO long. But then streamlit came to the rescue again. Using st.cache we can cache out data so that they become less resource intensive. But I was using st.cache_data at first, now this API only caches Images or other Data, NOT AI MODELS. Because AI Language Models are classified as resources. So later I had to switch to st.cache_resource which finally solved the problem!

Caching Pipeline Initialization:

The next steps were pretty easy once I solved the main problem.
On the next stage I used an if-statement to check if image file is uploaded & loaded the pipeline so the SLM could read the file.

Verify Image Upload:

After that I initialized a form using st.form to submit a question

Initialize form:

If a question is submitted , the image will be opened & the AI Model will query the image.

Open Query:

Now the query performed doesn't just produce one answer. Remember, this is a language model, it doesn't understand human language, but can only predict the next word based on training data. So in this case it will produce multiple answer.
Finally it will choose the most probable answer and show it to the user!

Get the best answer:

Here's the main file: https://github.com/ShatilKhan/Hemo/blob/main/hemo.py

There's a lot of other features as it is part of a larger project, I just explained the part where I used a Language Model is all.
Hopefully I'll write more about other features of this project soon!
Happy Coding!

DEV Community: ShatilKhan

Engineering of Small Things: Telegram Bots

What I Built

Why Telegram?

Demo

Screenshots

The Comeback Story

What was broken

The incremental note hack — my favorite fix

What the comeback changed

The Hack: Zero-Login Auth via Telegram initData

Why this matters

The Why: A generalizable pattern

My Experience with GitHub Copilot

The Stack

The unusual choice: Turso (edge SQLite) over PostgreSQL

Production Gotchas

1. CSS never loaded on the dashboard

2. Webhook cold starts missed schema migrations

3. new Date() is not your friend

4. Amount columns returned NaN

5. The over_budget_date column didn't exist in production

Quick Reference

Engineering of Small Things: Hermes Plugin

The shape Hermes wants

My Plugin

What happens at runtime

Why the pattern matters (even if you skip the rest of the post)

Gotchas

Hijacking OpenClaw with Claude

ClawCon Michigan

Prelude

The Problem: We Had Claude Code, But Not Claude

What even is OpenClaw?

The Symlink Hack

LOOP!

Meet the Clawfficer

Stuff I Spent way too much time on

1. Branch Coverage Matters

2. The OAuth Token is Everything

3. systemd PATH is Not Your Shell PATH

Giving Your Accounting App a Brain: NestJS "MCP"

Recap

The System

The MCP Layer: But Not Actually MCP?

Anatomy of a mcp tool

The Cool Part: Generative UI

Moneyshot#1: Month 1 till I make $1k MRR

Check out my new blog on MCP!

Building my first Local MCP server using Swagger & OpenAPITools

Building my first Local MCP server using Swagger & OpenAPITools

Extract parameters from the AI's request

Build the payload for our NestJS API

Get our secret JWT token from the environment

Make the actual API call!

Send the result back to the AI

Stop Your Code From Having a Mid-Life Crisis. An Introduction to OOP.

Engineering of Small Things #5: OOP Basics in TypeScript

Engineering of Small Things #5: OOP Basics in TypeScript

What is Object Oriented Programming anyway?

The Six Pillars of OOP: A Family Story

1. Classes: The Blueprint of You

2. Objects: You, the Instance

3. Encapsulation: Your Personal Bubble

4. Abstraction: Don't Overthink it!

5. Inheritance: Your Family Legacy

6. Polymorphism: Different Folks, Different Strokes

Wrapping Up

jafari-dev / oop-expert-with-typescript

A complete guide for learning object oriented programming pillars, SOLID principles and design patterns with TypeScript!

Object Oriented Programming Expert with TypeScript

Table of Contents

ShatilKhan / OOP-TS-Study

Study on Object Oriented Programming with TypeScript

OOP-TS-Study

What's Object-oriented-programming?

Running TypeScript Code in Visual Studio Code

Prerequisites

Steps

ক্লাউড কম্পিউটিং কি জিনিস ?

3. `new Date()` is not your friend

4. Amount columns returned `NaN`