PhyoDynamic Academy

ကိုယ်တိုင်လုပ်ထားတဲ့ Website Link ကို ပထမဆုံးဖွင့်ကြည့်မိတဲ့ည

ည ၇ နာရီကျော်ပြီ။

သူ့ Laptop screen မှာ စာကြောင်းလေးတစ်ကြောင်းပေါ်နေတယ်။

Deployment Successful.

သူက ခဏငြိမ်နေတယ်။

ပြီးတော့ အောက်က Link ကို Copy ကူးပြီး
ဖုန်းထဲမှာ ဖွင့်ကြည့်လိုက်တယ်။

Loading ခဏလေးဖြစ်ပြီးနောက်—

သူ့နာမည်ပါတဲ့ Website လေး ပေါ်လာတယ်။

Design က Perfect မဖြစ်သေးဘူး။
Mobile မှာ စာတချို့ နည်းနည်းကပ်နေတယ်။
Button တစ်ခုကလည်း သူလိုချင်သလောက် မလှသေးဘူး။

ဒါပေမယ့် သူပြုံးမိသွားတယ်။

မနေ့ကအထိ ဒီ Website က
သူ့ခေါင်းထဲက Idea တစ်ခုပဲရှိသေးတာ။

ဒီနေ့တော့—

ဖုန်းနဲ့ဖွင့်လို့ရတယ်။
Link ပို့လို့ရတယ်။
တခြားလူတစ်ယောက်ကို ပြလို့ရတယ်။

သူ Link ကို သူငယ်ချင်းတစ်ယောက်ဆီ ပို့လိုက်တယ်။

ခဏအကြာမှာ Reply ပြန်လာတယ်—

“ဒါကို ကိုယ်တိုင်လုပ်ထားတာလား?”

သူက Keyboard ကိုကြည့်ပြီး
တိတ်တိတ်လေး ပြန်ရေးလိုက်တယ်—

“ဟုတ်တယ်… မပြီးသေးဘူး။ ဒါပေမယ့် ငါလုပ်ထားတာ।”

တစ်ခါတလေ ပျော်ရွှင်မှုက
Project တစ်ခု Perfect ဖြစ်သွားတဲ့အချိန်မှ ရောက်လာတာမဟုတ်ဘူး။

ကိုယ့်ခေါင်းထဲမှာပဲရှိခဲ့တဲ့ Idea တစ်ခု
တကယ်ဖွင့်ကြည့်လို့ရတဲ့အရာဖြစ်လာတဲ့အချိန်မှာလည်း ရောက်လာတတ်တယ်။

Version 1 က မလှသေးနိုင်ဘူး။
ဒါပေမယ့် “စိတ်ကူး” မဟုတ်တော့ဘူး။

GitHub Project ရှိပေမယ့် README ဘာရေးရမှန်းမသိရင် ဒီ Free Tool ကိုသုံးပါ

Project တစ်ခု Build ပြီးသွားပြီ။

Website Link ရှိတယ်။
GitHub Repository လည်းရှိတယ်။
Feature တွေလည်း အလုပ်လုပ်တယ်။

ဒါပေမယ့် Repository ဖွင့်လိုက်တော့—

README.md

ထဲမှာ ရှိတာက…

“This is my project.”

ဒီတစ်ကြောင်းတည်း 😁

ကိုယ့် Project ကို တခြားလူတစ်ယောက်ဝင်ကြည့်ရင်—

ဘာအတွက်လုပ်ထားတာလဲ၊
ဘယ်လို Run ရမလဲ၊
ဘာ Technology သုံးထားလဲ၊
ဘယ် Feature တွေပါလဲ

ဆိုတာ မသိနိုင်တော့ဘူး။

README ကို ဘာ Section တွေနဲ့ရေးရမလဲ မသိရင် အသုံးဝင်တဲ့ Free Tool တစ်ခုက—

readme.so

ဒီ Tool မှာ ကိုယ်လိုအပ်တဲ့ Section တွေကို ရွေးပြီး စီလို့ရတယ်။

ဥပမာ—

Project Title and Description
Demo
Screenshots
Features
Installation
Environment Variables
Run Locally
Tech Stack
API Reference
Deployment
Roadmap
License

Section တစ်ခုချင်းစီကို ထည့်၊ ဖြုတ်၊ နေရာပြောင်းပြီး Markdown Preview နဲ့ Raw Code ကို တန်းကြည့်လို့ရတယ်။

AI ကိုလည်း ဒီလိုခိုင်းလို့ရတယ်—

“ဒီ README structure ကိုအသုံးပြုပြီး ကျနော့် Project အတွက် ရိုးရှင်းပြီး Beginner-friendly ဖြစ်တဲ့ content ရေးပါ။ မရှိတဲ့ Feature တွေ မထည့်ပါနဲ့।”

တစ်ခုသတိထားရမှာက—

README က အရှည်ကြီးဖြစ်ဖို့မလိုဘူး။

Project ကို ပထမဆုံးမြင်တဲ့သူက—

“ဒါကဘာလဲ၊ ဘယ်လိုစမ်းရမလဲ”

ဆိုတာ ချက်ချင်းနားလည်ဖို့ပဲလိုတယ်။

Project Build လုပ်ပြီးတိုင်း Repository ကို အလွတ်မထားပါနဲ့။

Code က Project ကို အလုပ်လုပ်စေတယ်။
README က လူတွေကို Project နားလည်စေတယ်။

readme.so

https://readme.so/

အကုန်သိတဲ့သူဖြစ်ဖို့မလိုဘူး။ ဆက်လေ့လာနေတဲ့သူဖြစ်ဖို့ပဲလိုတယ်

Satya Nadella ပြောခဲ့တဲ့ စာကြောင်းတစ်ခုရှိတယ်။

“Don’t be a know-it-all; be a learn-it-all.”

အကုန်သိပြီးသားလူတစ်ယောက်လို နေဖို့ထက်
အမြဲဆက်လေ့လာနေတဲ့သူဖြစ်ဖို့ ပိုအရေးကြီးတယ်ဆိုတဲ့သဘောပါ။ ဒီစကားကို Microsoft က growth mindset နဲ့ ချိတ်ဆက်ပြီး ဖော်ပြထားပါတယ်။

တစ်ခါတလေ ကိုယ်က မေးခွန်းမေးဖို့ရှက်တတ်တယ်။

“ဒါလေးတောင် မသိဘူးလား” လို့
လူတွေထင်မှာစိုးတယ်။

Error တစ်ခုနားမလည်ပေမယ့်
နားလည်သလိုနဲ့ ကျော်သွားတယ်။

AI ထုတ်ပေးတဲ့ Code ကို မသိပေမယ့်
“အလုပ်လုပ်နေတာပဲ” ဆိုပြီး တန်းသုံးလိုက်တယ်။

အပြင်ကကြည့်ရင်တော့
သိနေတဲ့သူတစ်ယောက်လိုပဲ။

တကယ်တမ်း ကိုယ်တိုးတက်မယ့်အခွင့်အရေးကို
ကိုယ်တိုင်ပိတ်နေမိတာ။

Vibe Coding မှာ အကုန်သိထားဖို့မလိုဘူး။

မသိတာကို ရှာတတ်ဖို့၊
AI ကို ရှင်းပြခိုင်းတတ်ဖို့၊
Result ကို ပြန်စစ်တတ်ဖို့၊
မှားသွားရင် ဘာကြောင့်လဲ ပြန်ကြည့်တတ်ဖို့ပဲလိုတယ်။

ဒီနေ့မသိသေးတာက
ကိုယ်မတတ်နိုင်ဘူးဆိုတဲ့အဓိပ္ပါယ်မဟုတ်ဘူး။

မလေ့လာရသေးဘူးဆိုတဲ့အဓိပ္ပါယ်ပဲ။

ဒါကြောင့် အကုန်သိသလို နေဖို့မကြိုးစားပါနဲ့။

မေးပါ။
စမ်းပါ။
မှားပါ။
ပြန်လေ့လာပါ။

အကုန်သိတဲ့သူဖြစ်ဖို့ထက်
မနေ့ကထက် ဒီနေ့နည်းနည်းပိုသိလာတဲ့သူဖြစ်တာက ပိုတန်ဖိုးရှိတယ်။

GitHub က “နှစ်ယောက်လုံးပြင်ထားလို့ ဘယ်သူ့စကားနားထောင်ရမလဲ” လို့ ကိုယ့်ကိုပြန်မေးသောအခါ

Content

Project ကို မနေ့ညက ပြင်ထားတယ်။

ဒီနေ့ GitHub က Code အသစ်ယူဖို့—

git pull

လို့ Run လိုက်တယ်။

Terminal မှာ—

CONFLICT 🔴

ဆိုပြီးပေါ်လာတယ်။

ကိုယ်က File ဖွင့်ကြည့်လိုက်တော့—

> main

ကိုယ့်မျက်နှာ—

🙂
😐
😨

ဒါနဲ့ AI ကိုမေးလိုက်တယ်—

“ဒါတွေက ဘာတွေလဲ?”

AI က—

“This is a merge conflict.”

ကိုယ်က—

“ဘယ်ဟာကို ဖျက်ရမှာလဲ?”

AI က—

“It depends on which version you want to keep.”

ကိုယ့် feeling က—

“ဘယ် Version လိုချင်မှန်းသိရင်
ကျနော်က ခင်ဗျားကို မေးနေမှာမဟုတ်ဘူးလေ” 😭

ဒါနဲ့ ကိုယ်က အပေါ် Code ကိုကြည့်တယ်။
ကောင်းသလိုပဲ။

အောက် Code ကိုကြည့်တယ်။
ဒါလည်း ကောင်းသလိုပဲ။

နောက်ဆုံး ရဲရဲဝံ့ဝံ့နဲ့—

နှစ်ခုလုံးထားလိုက်တယ်။

Run ကြည့်လိုက်တော့—

Function name ထပ်နေတယ်။
Button နှစ်ခုပေါ်လာတယ်။
Navbar နှစ်ခုဖြစ်သွားတယ်။
Error က Terminal တစ်မျက်နှာအပြည့် 😭

ကိုယ့် feeling က—

“ရန်ဖြစ်နေတဲ့ Code နှစ်ခုကို
ပြန်ချစ်သွားအောင်ပေါင်းပေးမိတာပါ…” 😁

တကယ်တော့ Git မှာ လူနှစ်ယောက်က File တစ်ခုရဲ့ နေရာတူကို ပြင်ထားပြီး Git က ဘယ် Version ကိုသုံးရမလဲ အလိုအလျောက်မဆုံးဖြတ်နိုင်ရင် ဆိုတဲ့ conflict markers တွေနဲ့ နှစ်ဖက်လုံးကိုပြပေးပါတယ်။ ကိုယ်လိုချင်တဲ့ Code ကိုရွေးပြီး marker တွေကိုဖယ်ရှားရပါတယ်။

AI ကို ဒီလိုမေးကြည့်ပါ—

“Explain what each side of this merge conflict does. Do not resolve it yet. Tell me what functionality I would lose by choosing either version.”

Merge Conflict ဖြစ်လာတဲ့အခါ
အကုန်ဖျက်ပစ်တာထက်—

နှစ်ဖက်လုံး ဘာပြောင်းထားလဲ နားလည်ပြီးမှ ရွေးတာကောင်းတယ်။

မဟုတ်ရင် Git က Code နှစ်ခုရန်ဖြစ်နေတာကို
ကိုယ်က ဝင်ဖြန်ဖြေရင်း—

Project တစ်ခုလုံးနဲ့ ရန်ဖြစ်သွားနိုင်တယ် 😁

API ကပြန်ပေးတဲ့ Data တွေကြည့်ပြီး မူးနေရင် ဒီ Free Tool နဲ့ ပုံဖော်ကြည့်ပါ

API တစ်ခုချိတ်ပြီး
Response ပြန်ရလာတယ်။

ဖွင့်ကြည့်လိုက်တော့—

{
"data": {
"users": [
{
"profile": {
"settings": {
"..."

Bracket တွေ၊
Array တွေ၊
Object တွေ၊
Key တွေအများကြီးနဲ့—

Data ရလာတာတော့ သိတယ်။
ဘာက ဘယ်အောက်မှာရှိလဲ မသိတော့ဘူး 😵‍💫

အဲ့လိုအချိန်မှာ အသုံးဝင်တဲ့ free resource တစ်ခုက—

JSON Crack

JSON data ကို paste လုပ်လိုက်ရုံနဲ့
ရှုပ်နေတဲ့စာသားတွေကို interactive tree / graph ပုံစံပြောင်းပြပေးတယ်။

ဒါကြောင့်—

ဘယ် data က ဘယ်အောက်မှာရှိလဲ
Array ထဲမှာ ဘာတွေပါလဲ
Object တွေ ဘယ်လိုချိတ်ထားလဲ
ကိုယ်လိုချင်တဲ့ value ရဖို့ ဘယ် path ကိုသုံးရမလဲ

ဆိုတာ ပိုမြင်လွယ်သွားတယ်။

JSON အပြင် YAML, XML နဲ့ CSV တွေကိုလည်း ပုံဖော်ကြည့်နိုင်ပြီး format စစ်တာ၊ data format ပြောင်းတာနဲ့ graph ကို image အဖြစ် export လုပ်တာမျိုးတွေပါ လုပ်နိုင်ပါတယ်။ JSON Crack က free နဲ့ open-source tool ဖြစ်ပါတယ်။

AI ကိုလည်း Screenshot ဒါမှမဟုတ် Structure ပေးပြီး—

“Explain this API response in simple terms. Show me the exact path to access the user’s profile image.”

လို့ မေးလို့ရတယ်။

API Data ကို နားလည်ဖို့
Bracket အတန်းကြီးကို ထိုင်ကြည့်နေဖို့မလိုဘူး။

စာသားနဲ့မရှင်းရင် ပုံနဲ့ကြည့်ပါ။

တစ်ခုတော့ သတိထားပါ—

Password, secret API key, access token နဲ့ customer information လို sensitive data တွေကို public tool ထဲ မထည့်သင့်ပါဘူး။

JSON Crack

https://jsoncrack.com/

အမြဲတမ်း Safe ဖြစ်နေရင် ကိုယ်လုပ်နိုင်တာ ဘယ်လောက်ရှိလဲ မသိနိုင်ဘူး

Helen Keller ပြောခဲ့တဲ့ စာကြောင်းတစ်ခုရှိတယ်။

“Life is either a daring adventure or nothing.”

ဘဝမှာ အရာအားလုံးသေချာပြီး
ဘာအမှားမှမဖြစ်နိုင်တဲ့အချိန်ကို စောင့်နေရင်—

အသစ်တစ်ခုကို စတင်ဖြစ်ဖို့ခက်တယ်။

Project စချင်ပေမယ့်
အကုန်နားလည်ပြီးမှ စမယ်။

Website တစ်ခုလုပ်ချင်ပေမယ့်
Design အပြည့်အစုံရှင်းမှ စမယ်။

AI ကိုအသုံးပြုချင်ပေမယ့်
Prompt ကောင်းကောင်းရေးတတ်မှ စမယ်။

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

စွန့်စားတယ်ဆိုတာ
အကြီးကြီးဆုံးဖြတ်ချက်တစ်ခု ချလိုက်တာမျိုးပဲမဟုတ်ဘူး။

မသေချာသေးပေမယ့် Prompt တစ်ခု စမ်းကြည့်တာ။
မလှသေးပေမယ့် Version 1 တစ်ခု ထုတ်ကြည့်တာ။
မတတ်သေးပေမယ့် Feature အသစ်တစ်ခု လုပ်ကြည့်တာ။

အဲ့ဒီလို သေးငယ်တဲ့စမ်းသပ်မှုတွေလည်း
ကိုယ့်အတွက် Adventure တစ်ခုပါပဲ။

အဆင်မပြေရင် ပြန်ပြင်လို့ရတယ်။
မှားသွားရင် အသစ်တစ်ခုသိလာတယ်။
မကြိုက်ရင် နောက် Version ထပ်လုပ်လို့ရတယ်။

ဒါပေမယ့် လုံးဝမစမ်းကြည့်ရင်တော့—

ကိုယ်လုပ်နိုင်တယ်ဆိုတာကိုပါ
သိခွင့်ရမှာမဟုတ်ဘူး။

ဒီနေ့ ကိုယ့်လူရဲ့ Safe Zone အပြင်ဘက်မှာရှိနေတဲ့
အရာအသေးလေးတစ်ခုကို စမ်းကြည့်ပါ။

ကြီးမားတဲ့ခုန်ခြင်း မလိုဘူး။

သတ္တိနည်းနည်းနဲ့ ရှေ့တစ်လှမ်းပဲ လိုတယ်။

API Key အသစ်ထည့်ပြီးတာတောင် မရလို့ ဘဝကိုသံသယဝင်နေသောအခါ

Project ထဲမှာ API ချိတ်နေတယ်။

API Key ထည့်လိုက်တယ်။
Code ကိုလည်း AI နဲ့သေချာစစ်ထားတယ်။

Run ကြည့်လိုက်တော့—

API Key is missing 🔴

ကိုယ်က .env file ကိုပြန်ဖွင့်ကြည့်တယ်။

Key ရှိတယ်။

စာလုံးပေါင်းစစ်တယ်။
မှန်တယ်။

ဒါနဲ့ AI ကိုပြောလိုက်တယ်—

“API Key ထည့်ထားပေမယ့် မတွေ့ဘူးလို့ပြနေတယ်”

AI က—

“Check the variable name.”

ဆိုတော့ Variable Name ပြန်စစ်တယ်။

မှန်တယ်။

AI က—

“Check whether the .env file is in the root directory.”

Root မှာရှိတယ်။

AI က—

“Make sure there are no spaces around the equals sign.”

Space မရှိဘူး။

ကိုယ်က စိတ်တိုလာပြီး—

API Key အသစ်ထုတ်တယ်။
အဟောင်းဖျက်တယ်။
အသစ်ပြန်ထည့်တယ်။
Code ကိုပြန်ရေးတယ်။
Package ကိုပါ အပြစ်တင်တယ်။

Run ပြန်ကြည့်တယ်။

API Key is still missing 😭

တစ်နာရီလောက်ကြာတော့
AI က စာကြောင်းတိုလေးတစ်ကြောင်းပြန်မေးတယ်—

“Did you restart the development server?”

ကိုယ့်မျက်နှာ—

🙂
😐
😶
💀

Terminal ကိုပိတ်တယ်။
npm run dev ပြန်လုပ်တယ်။

Project က ချက်ချင်းအလုပ်လုပ်သွားတယ်။

ကိုယ့် feeling က—

“API Key မှာ အပြစ်မရှိပါဘူး။
AI မှာလည်း အပြစ်မရှိပါဘူး။
Server ကို Restart မလုပ်တဲ့ ကျနော့်မှာပဲ အပြစ်ရှိပါတယ်” 😭

Vite က .env file တွေကို server စတင်တဲ့အချိန်မှာ load လုပ်တာကြောင့် environment variable ပြောင်းပြီးရင် server ကို restart လုပ်ဖို့လိုပါတယ်။

ဒါကြောင့် .env ပြင်ပြီး မရသေးရင်—

Code တစ်ခုလုံး မဖျက်ခင်၊
API Key အသစ်မထုတ်ခင်၊
Laptop ကို ရောင်းမပစ်ခင်—

Dev Server ကို အရင် Restart လုပ်ကြည့်ပါ။ 😁

ကိုယ့်လူတွေရော
တစ်နာရီလောက်ပြင်ပြီးမှ Restart တစ်ချက်နဲ့ရသွားဖူးလား?