ক্যাপস্টোন — শেখা সবকিছু জুড়ে একটি আসল সিস্টেম বানানো

১ · প্রোগ্রাম লেখা থেকে সিস্টেম বানানো

অভিনন্দন — আপনি কোর্সের ক্যাপস্টোনে পৌঁছেছেন। গত ৫১টি পর্বে আপনি একটি একটি করে যন্ত্র হাতে পেয়েছেন: ভ্যারিয়েবল, লুপ, পয়েন্টার, ফাইল, hash table, Big-O, process, thread, socket. এবার প্রশ্ন একটাই — এই যন্ত্রগুলো একসাথে জুড়ে কি এমন কিছু বানাতে পারবেন, যা সত্যিই কেউ ব্যবহার করতে পারে?

এই কাজের নাম capstone প্রজেক্ট। ইমারতের খিলানের একদম মাথার পাথরটি সব পাথরকে একসাথে ধরে রাখে — সেখান থেকেই নামটি এসেছে। কোর্সের শেষ প্রজেক্টও ঠিক তাই করে: আলাদা আলাদা শেখা জিনিসকে একটি পূর্ণ সিস্টেমে বাঁধে।

পেশাদার সফটওয়্যার প্রায় সবসময় একটি চক্র মেনে তৈরি হয়। নিচের ছবিটি মনে গেঁথে রাখুন — এই পর্বের বাকি সব অংশ এই চক্রেরই একেকটি ধাপ।

২ · প্রজেক্ট বেছে নিন — চারটি ক্যাপস্টোন ট্র্যাক

ক্যাপস্টোনের জন্য আমরা চারটি ট্র্যাক প্রস্তাব করছি। প্রতিটিই C-এর জগতের ক্লাসিক প্রজেক্ট — বিশ্বের নামকরা বিশ্ববিদ্যালয়ের সিস্টেম কোর্সেও এগুলোই বারবার আসে। যেকোনো একটি বেছে নিন; এই পর্বে আমরা ট্র্যাক D (key-value store) শুরু থেকে শেষ পর্যন্ত বিস্তারিত দেখব, কারণ এর নকশার শিক্ষা বাকি তিনটিতেও হুবহু খাটে।

৩ · মূল উদাহরণ: মিনি ডেটাবেস — চাহিদা আর নকশা

ধরুন আপনার এলাকার একটি কোচিং সেন্টার ছাত্রদের রোল আর নাম দ্রুত খুঁজতে চায়। কয়েকটি কম্পিউটার থেকে একসাথে তথ্য রাখা ও খোঁজা যাবে, আর বিদ্যুৎ চলে গেলেও তথ্য হারাবে না। আমরা বানাব একটি key-value store — নাম দিলাম “kvdb”. key হবে রোল (roll42), value হবে নাম (Rafi).

ধাপ ১ — চাহিদা লিখে ফেলুন

কোড লেখার আগে এক পাতায় specification লিখুন। এতে থাকবে কী করবে, কী করবে না, আর সীমা কত। “করবে না”-এর তালিকাটি সবচেয়ে গুরুত্বপূর্ণ — এটাই আপনাকে scope creep থেকে বাঁচায়।

ধাপ ২ — Protocol ঠিক করুন

Client আর server কোন ভাষায় কথা বলবে, সেই নিয়মের নাম protocol. আমরা বেছে নিচ্ছি সবচেয়ে সহজটি — প্রতি লাইনে একটি কমান্ড, লাইনের শেষে \n. এর বড় সুবিধা: nc localhost 7000 দিয়ে হাতে লিখেই সার্ভার পরীক্ষা করা যায়। Redis আর memcached-এর মতো বিখ্যাত সিস্টেমও মানুষের পড়ার মতো text কমান্ড বোঝে।

ধাপ ৩ — নকশা: একটি অনুরোধের যাত্রা

এবার দেখা যাক একটি কমান্ড সিস্টেমের ভেতরে কোন কোন অংশ পার হয়। প্রতিটি অংশ আলাদা একটি module, আর প্রতিটির কাজ একটাই। “পরে” চাপুন:

$ nc localhost 7000
SET roll42 Rafi      ← Enter চাপলেই "\n" যুক্ত হয়

recv() #1: "SET rol"
recv() #2: "l42 Rafi\n"
লাইন সম্পূর্ণ: "SET roll42 Rafi"

struct request {
    cmd   = CMD_SET
    key   = "roll42"    /* 6 অক্ষর, সীমা 31 */
    value = "Rafi"      /* 4 অক্ষর, সীমা 255 */
}

hash("roll42") % 16  →  bucket 11   (উদাহরণ মান)
bucket 11: [ "roll7" → "Mitu" ]  ← আগে থেকেই একজন আছে

bucket 11: [ "roll42" → "Rafi" ] → [ "roll7" → "Mitu" ]
store নিজের জন্য key ও value কপি করে রাখল (malloc)

$ nc localhost 7000
SET roll42 Rafi
OK
GET roll42
Rafi

৪ · Interface আগে — header-ই হলো চুক্তি

পর্ব ২৯-এ দেখেছিলেন, header file হলো একটি module-এর বাইরের চেহারা — সে কোন কোন ফাংশন দেয়, আর কীভাবে ডাকতে হয়। বড় সিস্টেমে header আরও বড় ভূমিকা নেয় — এটি দুই দলের মধ্যে একটি লিখিত চুক্তি। আপনি, আপনার বন্ধু আর AI — তিনজন আলাদা module লিখলেও header ঠিক থাকলে শেষে সব জোড়া লাগবে। তাই নিয়ম হলো: কোড লেখার আগে header লিখুন।

/* kv.h — the store's contract. Nothing outside kv.c sees the struct. */
#ifndef KV_H
#define KV_H
#include <stddef.h>

typedef struct kv kv;                 /* opaque: fields hidden in kv.c */

enum kv_status { KV_OK = 0, KV_NOT_FOUND, KV_NO_MEMORY, KV_TOO_LONG };

kv  *kv_open(size_t buckets);         /* NULL on failure */
void kv_close(kv *db);                /* frees everything, NULL is fine */

/* Copies key and value. The caller keeps ownership of its strings. */
enum kv_status kv_set(kv *db, const char *key, const char *value);

/* On success *out points INSIDE the store: read it, do not free it,
   and do not keep it after the next kv_set/kv_del on the same key. */
enum kv_status kv_get(const kv *db, const char *key, const char **out);

enum kv_status kv_del(kv *db, const char *key);
size_t         kv_count(const kv *db);
#endif

এই কয়েকটি লাইনে অনেকগুলো নকশার সিদ্ধান্ত লুকিয়ে আছে। প্রতিটি আপনি আগের কোনো পর্বে শিখেছেন:

মেমরির মালিকানার তিন নিয়ম

C-তে বড় সিস্টেমের বেশিরভাগ crash আসে একটি প্রশ্নের অস্পষ্ট উত্তর থেকে — “এই মেমরি free করবে কে?” উত্তরটি header-এ লিখে রাখুন, আর পুরো প্রজেক্টে একই নিয়ম মানুন:

1. যে malloc করে, সে-ই free করে। Store-এর ভেতরের কপি store মোছে; caller-এর string caller মোছে।
2. ধার করা pointer বেশিক্ষণ রাখবেন না। kv_get যে pointer দেয়, সেটি পরের kv_set-এর পর আর বৈধ নাও থাকতে পারে। বেশিক্ষণ লাগলে নিজে কপি করে নিন। না মানলে পাবেন use-after-free.
3. প্রতিটি পথে cleanup. মাঝপথে error হলেও যা নেওয়া হয়েছিল তা ফেরত দিতে হবে, নইলে memory leak. পর্ব ৩০-এর “একটি cleanup লেবেল” কৌশলটি এখানে কাজে আসে।

MVP-র হৃদয় — ২২ লাইনে

নকশা কাগজে থাকলে চলবে না, দ্রুত চালিয়ে দেখতে হবে। নিচের প্রোগ্রামটি kvdb-র সবচেয়ে ছোট সংস্করণ: stdin থেকে কমান্ড পড়ে, ছোট একটি টেবিলে রাখে, আর protocol অনুযায়ী উত্তর দেয়। Network নেই, ফাইল নেই, hash নেই — শুধু মূল যুক্তি। চালিয়ে দেখুন:

#include <stdio.h>
#include <string.h>
#define CAP 8
char keys[CAP][16], vals[CAP][32]; int n = 0;

int find(const char *k) {                /* later: hash table */
    for (int i = 0; i < n; i++) if (strcmp(keys[i], k) == 0) return i;
    return -1;
}
int main(void) {
    char line[80], cmd[8], k[16], v[32];
    while (fgets(line, sizeof line, stdin)) {
        int got = sscanf(line, "%7s %15s %31s", cmd, k, v);
        int i = got >= 2 ? find(k) : -1;
        if (got == 3 && !strcmp(cmd, "SET") && (i >= 0 || n < CAP)) {
            if (i < 0) i = n++;
            strcpy(keys[i], k); strcpy(vals[i], v); puts("OK");
        } else if (got == 2 && !strcmp(cmd, "GET")) puts(i >= 0 ? vals[i] : "(nil)");
        else if (got == 2 && !strcmp(cmd, "DEL") && i >= 0) { keys[i][0] = 0; puts("OK"); }
        else puts("ERR");
    }
}

৫ · ধাপে ধাপে বানানো — MVP থেকে concurrency

বড় প্রজেক্টের সবচেয়ে বড় শত্রু হলো “সবকিছু একসাথে লিখে শেষে চালাব” মানসিকতা। তখন ভুল হাজার লাইনের কোথায়, কেউ বলতে পারে না। এর বদলে আমরা বানাব MVP — সবচেয়ে ছোট সংস্করণ যা পুরোটা চলে — তারপর একটি একটি milestone যোগ করব। প্রতিটি মাইলস্টোনের শেষে প্রোগ্রাম চলবে, test পাস করবে, আর git-এ একটি commit ও tag থাকবে।

নিচের ডায়াগ্রামে দেখুন প্রজেক্টের ফোল্ডার কীভাবে বড় হচ্ছে। উজ্জ্বল চিহ্নিত ফাইলগুলো সেই ধাপে বদলেছে বা নতুন এসেছে:

$ make && ./kvdb
SET roll42 Rafi
OK

$ ./kvdb --data class.kv      # SET … তারপর Ctrl+D
$ ./kvdb --data class.kv
GET roll42
Rafi                          ← তথ্য টিকে আছে

$ ./kvdb --port 7000 --data class.kv
(অন্য terminal) $ nc localhost 7000
GET roll42
Rafi

client A: SET roll1 Anika   → OK
client B: GET roll1         → Anika
client C: DEL roll1         → OK   (কেউ কাউকে আটকে রাখেনি)

$ make test
PASS 41, FAIL 0
$ ./bench 1000000
SET: … ops/sec   GET: … ops/sec   (আপনার মেশিনের সংখ্যা)

প্রতিদিনের git আর make অভ্যাস

প্রতিটি ছোট কাজ শেষে একটি commit — “কাজ করছে” এমন একটি নিরাপদ বিন্দু। কিছু ভেঙে গেলে সেখানে ফিরে যেতে পারবেন। নতুন বড় ফিচার আলাদা branch-এ বানান, আর পাস করলে তবেই মূল branch-এ আনুন। বিস্তারিত পাবেন Software Engineering ও Git কোর্সে।

git switch -c feature/persistence     # নতুন কাজের জন্য আলাদা branch
make                                  # gcc -Wall -Wextra -g ... (শূন্য warning)
make test                             # সব test পাস না করলে commit নয়
git add storage.c storage.h Makefile
git commit -m "storage: save table with temp file + atomic rename"
git tag v0.2

Big-O দিয়ে আগেই অনুমান

MVP-র find ছিল O(n) — ১০ লাখ key হলে প্রতিটি GET-এ গড়ে ৫ লাখ তুলনা। Hash table-এ গড় খরচ O(1), শর্ত একটাই: load factor নিয়ন্ত্রণে রাখা। টেবিল ভরে এলে বড় করে সব key নতুন করে বসানো (rehashing) একবারে O(n), কিন্তু অনেক অপারেশনের ওপর ভাগ করলে প্রতিটির গড় খরচ এখনো O(1) — পর্ব ৩৯-এর amortized হিসাব। আর ফাইলে পুরো টেবিল লেখা O(n), তাই প্রতিটি SET-এ নয়, কয়েক সেকেন্ড পরপর বা বন্ধ হওয়ার সময় লিখুন। এই ট্রেড-অফ লিখে রাখুন: “বিদ্যুৎ গেলে শেষ কয়েক সেকেন্ডের তথ্য হারাতে পারে।”

৬ · প্রমাণ করুন — test, sanitizer আর মাপজোখ

“আমার মেশিনে তো চলছে” — এটি কোনো প্রমাণ নয়। পেশাদার সিস্টেমের প্রতিটি দাবির পেছনে একটি যন্ত্র থাকে, যা প্রতিবার নিজে থেকে যাচাই করে। আপনার kvdb-র জন্য একটি test plan:

Test লিখতে বড় কোনো library লাগে না। একটি ছোট macro আর দুটি গণনাই যথেষ্ট — একে বলে test harness. নিচের উদাহরণে আমরা MVP-র parse অংশটিকে আলাদা ফাংশনে এনে পরীক্ষা করছি। শেষ test-টি একটি আসল নকশার ভুল ধরে ফেলে — চালিয়ে দেখুন কোনটি:

#include <stdio.h>
#include <string.h>

static int pass = 0, fail = 0;
#define CHECK(cond) do { if (cond) pass++; else { fail++; \
    printf("FAIL line %d: %s\n", __LINE__, #cond); } } while (0)

/* unit under test: split "CMD key [value]" */
int parse(const char *line, char *cmd, char *key, char *val) {
    return sscanf(line, "%7s %15s %31s", cmd, key, val);
}

int main(void) {
    char c[8], k[16], v[32];
    CHECK(parse("SET roll42 Rafi", c, k, v) == 3 && strcmp(v, "Rafi") == 0);
    CHECK(parse("GET roll42", c, k, v) == 2 && strcmp(k, "roll42") == 0);
    CHECK(parse("", c, k, v) < 1);                      /* empty line */
    CHECK(parse("GET abcdefghijklmnopqrstuvwxyz", c, k, v) == 2);  /* long key */
    printf("PASS %d, FAIL %d\n", pass, fail);
    return fail != 0;
}

একটি বাগ শিকারের গল্প

সব unit test পাস করছে, কিন্তু stress test-এ মাঝে মাঝে crash. এমন বাগ চোখে খুঁজে পাওয়া প্রায় অসম্ভব — যন্ত্রকে কাজে লাগাতে হয়। নিচের debugger-ধাঁচের ডায়াগ্রামে পুরো শিকারটি দেখুন:

1/* kv.c */2char *dup_str(const char *s) {3    size_t n = strlen(s);4    char *p = malloc(n);5    if (p == NULL) return NULL;6    memcpy(p, s, n + 1);7    return p;8}

gcc -g -fsanitize=address,undefined *.c -o kvdb_asan   # মেমরি ও UB-এর ভুল
gcc -g -fsanitize=thread  *.c -o kvdb_tsan -pthread   # thread-এর race (ASan-এর সাথে একসাথে নয়)
valgrind --leak-check=full ./kvdb < tests/cmds.txt    # sanitizer ছাড়া build-এ leak খোঁজা

৭ · AI-এর যুগে: AI আপনার টিমমেট, মালিক আপনি

আজ একজন পেশাদার প্রোগ্রামার প্রায় প্রতিদিনই AI-এর সাহায্য নেন। প্রশ্ন তাই “AI ব্যবহার করব কি না” নয়, বরং “কীভাবে করলে আমার সিস্টেম ভালো হবে, খারাপ নয়”। এই কোর্সের পুরো দর্শন এখানে এসে এক জায়গায় মেলে: নকশা, ভাগ করা, যাচাই আর দায় — এই চারটি কাজ আপনার। টাইপ করার কাজটি AI-এর সাথে ভাগ করা যায়।

AI-এর কোডে লাল পতাকা

AI-এর লেখা module গ্রহণ করার আগে চেকলিস্ট

• Header একটুও বদলায়নি; শুধু অনুমতি দেওয়া ফাইলগুলোই বদলেছে
• -Wall -Wextra দিয়ে শূন্য warning, আর make asan test পাস
• প্রতিটি malloc-এর জোড়া free কোথায়, দেখিয়ে দিতে পারি
• Stress test-এ reference সংস্করণের সাথে ফল মিলেছে
• প্রতিটি ফাংশন কী করে আর কেন এভাবে করে, নিজের ভাষায় বলতে পারি
• অন্য কোথাও থেকে নেওয়া কোড থাকলে তার উৎস ও লাইসেন্স জানি এবং README-তে লিখেছি

৮ · কাজটি দেখান — GitHub, README আর ডেমো

একটি ভালো প্রজেক্ট যদি শুধু আপনার ল্যাপটপে থাকে, তাহলে পৃথিবীর কাছে সেটির অস্তিত্বই নেই। চাকরি বা ইন্টার্নশিপে — বাংলাদেশে হোক বা বিদেশে — নিয়োগকারীরা প্রায়ই সার্টিফিকেটের চেয়ে বেশি দেখতে চান আপনি কী বানিয়েছেন। একটি গোছানো GitHub portfolio সেই প্রশ্নের উত্তর দেয়, আপনি ঘরে না থাকলেও।

একটি ভালো README-এর কাঠামো

অপরিচিত একজন আপনার repository খুলে প্রথম যা পড়েন, তা হলো README. প্রথম ৩০ সেকেন্ডে তাঁকে বোঝাতে হবে — এটি কী, কীভাবে চালাব, আর কেন আকর্ষণীয়। নিচের কাঠামোটি অনুসরণ করুন:

# kvdb — a tiny key-value database in C

A multi-client key-value store with a text protocol, a hash table,
crash-safe file persistence and a test suite. Built as my C capstone.

## Quick start
    make && ./kvdb --port 7000 --data class.kv
    nc localhost 7000        # then type: SET roll42 Rafi

## Protocol      SET k v -> OK | GET k -> value or (nil) | DEL k -> OK or (nil)
## Design        diagram + one paragraph per module (net, parse, kv, storage)
## Testing       make test, make asan; stress test against a reference model
## Performance   numbers measured on my laptop, with the exact command used
## Limits        no auth, no spaces in values, last few seconds may be lost on power cut
## What I learned / Credits (libraries, tutorials, AI help - stated honestly)

৯ · কোর্সের পথ — ৫২টি পর্বের যাত্রা, আর এরপর কোথায়

একবার পেছনে তাকান। প্রথম পর্বে প্রশ্ন ছিল “C কেন?” আজ আপনি এমন একটি সিস্টেমের নকশা বোঝেন, যেখানে hash table, ফাইল, socket আর thread একসাথে কাজ করে। প্রতিটি মডিউল ক্যাপস্টোনে কোথায় কাজে লাগল, দেখুন:

এরপর কোন পথে?

C আপনাকে দিয়েছে কম্পিউটারের ভেতরটা দেখার চোখ। এখন সেই চোখ নিয়ে যেকোনো দিকে যেতে পারেন। ABCL TECH-এর এই কোর্সগুলো ঠিক এখান থেকে শুরু হয়: