Kite Education Center

ပထမဦးဆုံး class တွေအနေနဲ့ဖွင့်လှစ်ပေးမဲ့ KEC ရဲ့ ပညာဒါန အတန်းလေးများ။
ပညာဒါန class တွေဆိုပေမဲ့ စနစ်တကျ သင်ကြားပေးမှာမလို့ join ချင်သည့်သူများအနေနဲ့လည်း အဆုံးထိတက်ရောက်ပေးနိုင်မည့်သူများသာ join ပေးဖို့ မေတ္တာရပ်ခံပါတယ် ခင်ဗျာ။

ကျနော် http အကြောင်းပိုနားလည်အောင် http server ဆောက်ကြည့်ရာကနေ သိလာတာလေးတွေကို share ချင်ပါတယ်။ လိုအပ်တာရှိရင် လဲ ပြန်shareပေးပါ။

Understanding Ports

internet ပေါ်မှာ device တွေက တခုနဲ့တခု ချိတ်နေကြပြီး device တိုင်းမှာ IP address ကိုယ်ဆီရှိကြပါတယ်။ device တခုကနေ other device ကို data ပို့ချင်ရင် အဲ့ other device ရဲ့ IP address ကို သုံးရပါတယ်။

Device B မှာ email server program, web server program, file server program ဆိုပြီး server program တွေအများကြီး ရှိတယ်ဆိုပါစို့။
Device A က web request တခု ပို့လိုက်ရင် IP address ကို သုံးပြီး device B ဆီကိုတော့ ရောက်သွားပါလိမ့်မယ်။
ဒါမဲ့ အဲ့ဒီ web request ကို server program တွေအများကြီးထဲကမှ correct program ဖြစ်တဲ့ web server program ဆီကို ဘယ်လိုပို့မှာလဲ?

Ports တွေကို သုံးပြီးပို့မှာပါ။ standard ports တွေကို သုံးပြီးပို့မှာပါ။

ယနေ့ခေတ် Web server တိုင်းက port no. 443 မှာ listen ရမယ်ဆိုတာ standard ပါ။
Web browser တိုင်းကလဲ web request တွေကို port no. 443 နဲ့ တွဲပြီး ပို့ရပါတယ်။
ဆိုတော့ A ရဲ့ web req က B ကို ရောက်ရင် သူနဲ့ အတူ destination port no. 433 ဆိုပြီး တွဲပါလာမှာပါ။
အဲ့ကျ B က အဲ့ req ကို port 443 မှာ listen နေမဲ့ web server ဆီကို forward လိုက်မှာပါ။

ကိုယ်ပါကို server ဆောက်ပြီး port no. 8080 မှာ listen ခိုင်းဖူးမှာပါ။ အဲ့ကျရင် အဲ့ server ကို web req ပို့ချင်ရင် http://localhost:8080 ကို သုံးရမှာပေါ့။

IP => right machine
Port => right program

Understanding TCP

web req က right program တော့ ရောက်ပြီ။ လက်တွေ့မှာ A ကနေ B ကို web req ပို့ရင် တခုလုံးအနေနဲ့ မဟုတ်ပဲ data packets လေးတွေအဖြစ် ခွဲစိတ်ပြီး ပို့တာပါ။
အဲ့ data packets လေးတွေက B ကိုရောက်ရင်
⦁ ရှေ့ နောက်မညီတာမျိုး ဖြစ်နေနိုင်တယ်။
⦁ တချို့ကောင်တွေ ပျောက်နေတာမျိုး ဖြစ်နေနိုင်တယ်။
⦁ တချို့ duplicate နေတာလဲ ဖြစ်နိုင်တယ်။
အဲ့တာတွေကို device B's OS ထဲက TCP က fix ပေးပြီး clean byte stream အဖြစ် ပြန်ထုတ်ပေးပါတယ်။ ဒီထိက OS ကပဲလုပ်ပေးတာပါ။

ထို့နောက် အဲ့ဒီ byte stream ကို ကျနော်တို့ရေးထားတဲ့ web server program(see example below)က လက်ခံရရှိပါတယ်။
ပြီးရင်သူက အဲ့ဒီ byte stream ကို Stringify လုပ်တယ်။ http string ရလာတယ်။ http string ကို req parsing လုပ်တယ်။ req တခုရလာရင် အဲ့တာကို respond တယ်။
နောက်ထပ် routing တို့၊ static file servingတို့ ထည့်ရေးသွားလို့ ရတယ်။

ဒါပေမဲ့ ယနေ့ခေတ်မှာ ဒီအဆင့်တွေကို developer အများစု မရေးတော့ပါဖူး။ အဲ့အဆင့်တွေကို nodejs's http module တို့၊ express js တို့က တာဝန်ယူပေးထားပါတယ်။

const net = require("net");

const server = net.createServer((socket) => {
let buffer = Buffer.alloc(0);

socket.on("data", (chunk) => {
buffer = Buffer.concat([buffer, chunk]);

// Try to process as many requests as possible from the buffer
while (true) {
const bufferStr = buffer.toString();

const headerEnd = bufferStr.indexOf("\r\n\r\n");
if (headerEnd === -1) {
// Not even full headers yet
return;
}

const headerPart = bufferStr.slice(0, headerEnd);
const lines = headerPart.split("\r\n");

const [method, path, version] = lines[0].split(" ");

const headers = {};
for (let i = 1; i < lines.length; i++) {
const [k, v] = lines[i].split(": ");
headers[k.toLowerCase()] = v;
}

const contentLength = parseInt(headers["content-length"] || "0");

const bodyStart = headerEnd + 4;
const totalLength = bodyStart + contentLength;

if (buffer.length < totalLength) {
// We don't have full body yet
return;
}

// ✅ We have one full HTTP request
const bodyBuffer = buffer.slice(bodyStart, totalLength);
const bodyText = bodyBuffer.toString();

console.log("==== REQUEST ====");
console.log(method, path);
console.log("Body:", bodyText);
console.log("=================");

// Remove this request from the buffer
buffer = buffer.slice(totalLength);

// --- Handle request ---
let responseBody = "";

if (method === "GET" && path === "/") {
responseBody = "Home page";
} else if (method === "POST" && path === "/echo") {
responseBody = "You sent: " + bodyText;
} else {
responseBody = "Not found";
const response =
`HTTP/1.1 200 OK\r
Content-Type: text/plain\r
Content-Length: ${Buffer.byteLength(responseBody)}\r
Connection: keep-alive\r
\r
${responseBody}`;

socket.write(response);

// ⚠️ DO NOT close the socket!
// We keep it alive for the next request
}
});

socket.on("end", () => {
console.log("Client disconnected");
});
});

server.listen(8080, () => {
console.log("Listening on http://localhost:8080");
});

I hope this help you in some way. Thanks.
}

𝙒𝒆𝙗 𝙚𝒄𝙤𝒔𝙮𝒔𝙩𝒆𝙢 ထဲမှာ 𝙁𝒓𝙤𝒏𝙩𝒆𝙣𝒅 𝑫𝙚𝒗𝙚𝒍𝙤𝒑𝙚𝒓 ရဲ့ အခန်းကဏ္ဍ

ဒါကိုနားလည်ဖို့ website အသုံးပြုသူ(website user/user)ရဲ့ နေရာကနေအရင်ဝင်ကြည့်ရအောင်ဗျာ။
ကျနော်တို့ website တခုခုကိုသုံးချင်ရင် browser ကတဆင့်သုံးရတယ်ပေါ့နော်။
browser ကိုသွားတယ်။ သုံးချင်တဲ့ website ရဲ့ နာမည်ကို ရိုက်ထည့်တယ်။ ဒါဆို ရပြီ။ website ကို ချက်ချင်း မြင်ရပြီ။ လိုင်းကောင်းရင်ပေါ့:)။

ခင်ဗျားအမြင်မှာတော့ ချက်ချင်းထင်ရပေမဲ့ တကယ်တော့ နောက်ကွယ်မှာအဆင့်တွေများကြီး အလုပ်လုပ်သွားတာပါ။
အဲ့အဆင့်တွေကို အကြမ်းပြောပြပါမယ်။

ပထမသိရမှာက website တွေကို html code တွေပါတဲ့ html file တွေ, css code တွေပါတဲ့ css file တွေ, javascript code တွေပါတဲ့ JS file တွေနဲ့ရေးထားတာပါ။ ခင်ဗျားသုံးဖူးတဲ့၊ မြင်နေရတဲ့ website တွေတိုင်းရဲ့နောက်မှာ အဲ့ဒီ file တွေရှိတယ်။ browser ဆိုတဲ့ app က အဲ့ file တွေထဲက code တွေကို ဖတ်ပြီး ခင်ဗျားမြင်နေရတဲ့ website အဖြစ် ပြောင်းပေးတာပါ။ ဆိုတော့ -
code files for 'youtube' => browser => youtube

အခုခင်ဗျားမေးနေမှာက အဲ့ဒီ ‌html, css နဲ့ js files တွေက browser app ဆီ ဘယ်ကရောက်လာတာလဲ?

အဲ့ဒီ files တွေက browser ကို download လိုက်ထဲက တခါတည်းပါလာတာမဟုတ်ပါဘူး။ အဲ့လိုသာဆို ကမ္ဘာမှာရှိသမျှ website သောင်းခြောက်ထောင်အတွက် files တွေကို browser နဲ့အတူတပါတည်း download လိုက်ရမှာပေါ့။ ဒါမှ ခင်ဗျား ဘယ်website သုံးချင်ချင် သုံးလို့ရမှာလေ။ ဒါမဲ့ ခင်ဗျားရဲ့ laptop မှာ အဲ့ဒီ filesတွေအကုန် ဘလိုလုပ်ဆံ့မလဲ။ အဲ့နည်းက လက်တွေ့မကျတာအသိသာကြီးဗျာ။

တကယ်က အဲ့ files တွေက အဲ့ဒီ website ပိုင်ရှင်ရဲ့ computer ပေါ်မှာရှိနေတာပါ။ e.g. youtube website အတွက် files တွေဆို youtube ရဲ့ computer ပေါ်မှာရှိနေတာ။
အဆင့်ဆင့်ပြောရရင် ခင်ဗျားက -

၁. ခင်ဗျားက browser ရဲ့ search box မှာ 'youtube' or 'youtube.com' ကိုထည့်လိုက်တယ်။

၂. ဒါဆို browser က ခင်ဗျား youtube ကြည့်ချင်တာ သိတယ်။ အဲ့ကျ ခင်ဗျားအစား youtube website ပြပေးဖို့(render) အတွက်လိုတဲ့ ‌html, css နဲ့ js files တွေကို အဲ့ files တွေရှိနေမဲ့ youtube ရဲ့ computer တွေပေါ်ကို လှမ်းတောင်းလိုက်တယ်။ internet ကနေတဆင့်ပေါ့။ အဲ့တာကို request လုပ်ခြင်းလို့ခေါ်တယ်။ request ကတော့ ‌"ဟေ့ ငါ့ files တွေပေးအုံး" ပေါ့။

၃. အဲ့ "ဟေ့ ငါ့ files တွေပေးအုံး" ဆိုတဲ့ request က youtube computer ေပါ်ရောက်သွားလိမ့်မယ်။ အဲ့ကျ youtube computer က files တွေကို ခင်ဗျား သုံး နေတဲ့ computer/browser ဆီကို ပို့ပေးလိုက်တယ်။ အဲ့တာကို response လုပ်ခြင်းလို့ခေါ်တယ်။ response ကတော့ ‌html, css နဲ့ js files တွေပေါ့။

၄. ပြီးရင် အဲ့responseက ခင်ဗျား browser ဆီကို ရောက်လာတယ်။ browser က response ထဲက ‌html, css နဲ့ js files တွေကို ဖတ်ပြီး website အဖြစ်ပြောင်းပေးတယ်။

၅. ခင်ဗျား(website user/user)က စပြီး အသုံးပြုတယ်။

အဲ့ ‌html, css နဲ့ js files တွေကို youtube ရဲ့ frontend developers တွေက ရေးပြီး youtube computer ပေါ်တင်ထားတာပါ။ ဆိုတော့ ခင်ဗျား frontend dev လုပ်ရင်လဲ ဒီ files တွေကို ရေးရမှာဖြစ်ပြီး အဲ့ files တွေက အပေါ်ကရှင်းပြလိုက်တဲ့ဖြစ်စဥ်အတိုင်း Web ecosystem ထဲမှာ ခရီးဆက်ကြမှာပါပဲခင်ဗျာ။

𝙁𝒓𝙤𝒏𝙩𝒆𝙣𝒅 𝑫𝙚𝒗 တွေသိသင့်တဲ့ 𝙬𝒆𝙗 𝙥𝒂𝙜𝒆 𝒓𝙚𝒏𝙙𝒆𝙧𝒊𝙣𝒈 နဲ့ 𝒑𝙚𝒓𝙛𝒐𝙧𝒎𝙖𝒏𝙘𝒆 𝒐𝙥𝒕𝙞𝒎𝙞𝒛𝙖𝒕𝙞𝒐𝙣

Browser တွေက html, js နဲ့ css files တွေကို server နေရလာတဲ့အခါ web page တခုပေါ်လာအောင် အခုလို အဆင့်ဆင့်လုပ်ပြီး render ကြတယ်။

၁.html parser က html file ကို ဖတ်ပြီး
e.g. Hello ဆို အောက်ကလို objectအဖြစ် တည်ဆောက်တယ်။ အဲ့လို object တွေကို dom nodeလို့ ခေါ်ပြီး အဲ့လို node တွေကိုချိတ်ပြီး DOM Tree ကို တည်ဆောက်တယ်။ ပြီးရင် အဲ့ dom tree data structure ကို memory ထဲမှာ hold ထားလိုက်တယ်။ အဲ့တာကြောင့် JS နဲ့ document.querySelector('h1').textContent = "hi"; ဆိုတာမျိုး‌ရေးပြီး mutate လို့ရတာပါ။

{
nodeType: 1,
tagName: "H1",
children: [
{
nodeType: 3,
textContent: "Hello"
}
]
}

၂. css parser က css ကို ဖတ်ပြီး CSSOM Tree ကို တည်ဆောက်တယ်။
၃. အဲ့ Tree ၂ ခုကို ပေါင်းပြီး Rendering Tree ဆိုတဲ့ ပေါင်းစပ် tree တခုကို တည်ဆောက်တယ်။ သူ့ရဲ့ nodeတွေ က DOM Tree ရဲ့ node တွေနဲ့ တူတူပဲ styles တွေ ပိုသွားတာပဲရှိပါတယ်။
၄. ပြီးရင် Render tree element တိုင်းအတွက် coordinates တွေကို တွက်ချက်တယ်။ အဲ့process ကို layout လုပ်တယ်လို့ခေါ်ပါတယ်။
၅. layout ချပြီး သွားတဲ့အခါမှာတော့ browser window မှာ paint လုပ်လိုက်ပါတယ်။ painting process အဆင့်လို့ခေါ်တယ်။ ဒါဆိုရင်တော့ web page ပေါ်သွားပါပြီ။

web page ပေါ်ပြီးနောက်မှာ user interaction ကြောင့်ဖြစ်စေ၊ javascript နဲ့ modify လို့ ကြောင့်ဖြစ်စေ(e.g. document.querySelector('h1').textContent = "hi" ) အပေါ်အဆင့်တွေထဲက အချို့ အဆင့်တွေကို browser ကပြန်လုပ်ပြီး web page ကို update လုပ်ပါတယ်။

Repaint

element တခုရဲ့ page ပေါ်မှာရှိတဲ့ position ကို မပြောင်းလဲစေသော styles တွေ(e.g. background-color, border-color, visibility)တွေကို ပြောင်းလိုက်ရင် browser ကအဲ့ element ကိုပဲ stylesအသစ်တွေသုံးပြီး update လုပ်ပါတယ်။ relayout မလုပ်ပါ။

Relayout
document structure, content or element position အစရှိတဲ့ positionပိုင်းဆိုင်ရာ ပြောင်းလဲဖို့လိုလာစေတဲ့ triggers/changes တွေဆိုရင်တော့ browser က relayout လုပ်ပါတယ်။ အဲ့ triggers တွေကတော့ -
- DOM manipulation(element addition, deletion, altering or changing element order)
- Contents changes, including text changes in form fields
- calculation or altering of CSS properties
- adding or removing style sheets
- changing the 'class' attribute
- browser window manipulation(resizing, scrolling)
- pseudo-class activation(:hover)

e.g.
$body.css('padding', '1px');
ဆိုရင် browser က relayout လုပ်မှာပါ။ body တင်မကပဲ body's position ပြောင်းလဲမှု consequence အနေနဲ့ ဆက်စပ်တခြား element တွေအများကြီးရဲ့ position ကို ပြန် calculate လုပ်ရမှာပါ။

ဒီလိုမျိုး style changes တွေကို စုရေးထားလိုက်ရင်
$body.css('padding', '1px');//relayout
$body.css('color', 'red');//repaint
$body.css('margin', '2px');//relayout
browser က relayout ကို ပထမအကြောင်းပြီး ၁ ခါ၊ တတိယအကြောင်းပြီး ၁ခါ လုပ်မဲ့အစား အဆုံးထိဖတ်ပြီးမှ ၁ခါထဲမှာပဲ ပေါင်းပြီး new position calculations တွေကို လုပ်လိုက်ပါတယ်။ batch update လုပ်လိုက်တယ်။ အဲ့နည်းနဲ့browser က performance ကို auto-optimize လုပ်ပေးတယ်။

e.g.
$body.css('padding', '1px');
console.log($body.width()); // forces relayout/reflow NOW
$body.css('margin', '2px');

ဒီ code snippet လိုမျိုးကြ ပထမline ပြီး relayoutလုပ်ကိုလုပ်ရတယ်။ ဘာလို့ဆိုတော့ ဒုတိယline က body width value access ထားတာဆိုတော့ most updated valueပေးနိုင်အောင် position calculation/relayout ကိုလုပ်လုပ်ရတယ်။ တတိယlineမှာလဲ relayoutထပ်လုပ်ရတယ်။ ဆိုတော့ browserရဲ့ batch update optimizationကို ဖျက်ရာကြတယ်။ အကြောင်းမရှိပဲ value access code ကိုအဲ့လို ကြားထဲသွား မထားမိစေပါနဲ့ခင်ဗျာ။

Html, css, js ရရင် websites တွေစရေးလို့ရတာဟုတ်ပါတယ်။ ဒါမဲ့ beginner ကနေ level up လာချင်ရင်တော့ ဒီအပိုင်းတွေအပြင် web system တခုလုံးကို နားလည်ရပါမယ်။ ဒီ video မှာ web system ကို beginner-friendly ဖြစ်အောင်ရှင်းထားပါတယ်။



Video link - https://youtu.be/essS9YUdGfM

- JavaScript language ကိုလေ့လာချင်သူများ
- Web development ကိုလေ့လာချင်သူများ အတွက်

လက်တွေ့ Projects တွေလုပ်ရင်း သိသင့်တဲ့ concepts တွေကို ရှင်းပြပေးသွားမဲ့ Code Bridge ရဲ့ JS Course

Premium JavaScript course in Myanmar/Burmese - 01 ဒါကတော့ Code Bridge ရဲ့ မြန်မာဘာသာသင်တန်း (Premium JavaScript Course) မိတ်ဆက်ဗီဒီယိုပဲဖြစ်ပါတယ်။ ဒီဗီဒီယိုထဲမှာတော့- JavaScript ဆိုတာဘာလဲ?- ...

Code Bridge အနေနဲ့ ဒီ video မှာ -
၁. ၂၀၂၆ မှာ လေ့လာသင့်တဲ့ programming language
၂. ကိုယ်ပါကို language တခုကို ဘယ်လို ရွေးရမလဲ
၃. computer နယ်ပယ်ထဲမှာ အသုံးများတဲ့ abstraction ဆိုတဲ့ concept အကြောင်း

တွေကို ရှင်းပြထားပါတယ်ခင်ဗျာ။

2026 မှာ ဘယ် programming language ကို လေ့လာရမလဲ??? Code Bridge အနေနဲ့ ဒီ video မှာ - ၁. ၂၀၂၆ မှာ လေ့လာသင့်တဲ့ programming language၂. ကိုယ်ပါကို language တခုကို ဘယ်လို ရွေးရမလဲ၃. computer နယ်ပယ်ထဲမှာ အ....