GitHub Copilot နဲ့ Baby Monitor Timmy ကို ဘယ်လိုတည်ဆောက်နေလဲ

Baby Monitor Timmy က ရိုးရှင်းတဲ့ အကြံတစ်ခုကနေ စတင်ခဲ့တာပါ—အိမ်မှာ ကိုယ်ရေးကိုယ်တာလုံခြုံမှုကို လေးစားတဲ့ ကလေးစောင့်ကြည့်စက်တစ်ခုပါ။ cloud မှာ မှတ်တမ်းတင်တာမရှိ၊ ကလေးအခန်းကနေ မလိုအပ်ဘဲ ဒေတာထွက်သွားတဲ့ လမ်းကြောင်းတွေလည်း မရှိပါဘူး။ လူအများ မမြင်ကြတာကတော့ Timmy ကို Zurich မှာ ကျွန်တော်တစ်ယောက်တည်း တည်ဆောက်နေတာဖြစ်ပြီး၊ GitHub Copilot ကတော့ ကျွန်တော့်ရဲ့ အလွန်မြန်တဲ့ တွဲဖက်ပရိုဂရမ်မာပါ။

လူနဲ့ AI အတူလုပ်တဲ့ လုပ်ငန်းစဉ်

တာဝန်ခွဲဝေမှုက ရှင်းပါတယ်—လုပ်ဆောင်ချက်တွေကို ကျွန်တော်သတ်မှတ်တယ်၊ ဦးစားပေးတွေ သတ်မှတ်တယ်၊ architecture ဆိုင်ရာ ဆုံးဖြတ်ချက်တွေ ချတယ်။ Copilot က အကောင်အထည်ဖော်ရာမှာ ကူညီတယ်—ကုဒ်ရေးခြင်း၊ စမ်းသပ်မှုတွေ ထည့်ခြင်း၊ bug ဖြစ်ရတဲ့အကြောင်းရင်းကို ရှာဖွေဖော်ထုတ်ခြင်းနဲ့ ဖြန့်ချိရေးအဆင့်တွေ ပြင်ဆင်ခြင်းတို့ပါ။

ပုံမှန် sprint တစ်ခုမှာ ကျွန်တော့်အတွက် အကြမ်းဖျင်း ဒီလိုပါ—

1. လုပ်ဆောင်ချက်ဖော်ပြချက်: လုပ်ဆောင်ချက်က ဘာလုပ်ရမလဲဆိုတာကို ခြွင်းချက်အခြေအနေတွေနဲ့ ကန့်သတ်ချက်တွေအပါအဝင် ကျွန်တော် ဖော်ပြပါတယ်။
2. အကောင်အထည်ဖော်ခြင်း: Copilot က ကုဒ်အကြံပြုပြီး ပရောဂျက်မှာ ရှိပြီးသား စည်းကမ်းပုံစံတွေကို လိုက်နာပါတယ်။
3. စမ်းသပ်ခြင်း: အလိုအလျောက် end-to-end စမ်းသပ်မှုတွေက emulator နှစ်ခုမှာ လုပ်ဆောင်ပြီး ကလေးစက်/မိဘစက်တို့ကြား တကယ့်ချိတ်ဆက်မှုကို စစ်ဆေးပါတယ်။
4. ဖြန့်ချိခြင်း: စမ်းသပ်မှုတွေ အောင်မြင်ရင် Android နဲ့ iOS build တွေကို သက်ဆိုင်ရာ store နဲ့ စမ်းသပ်ရေး track တွေအတွက် ပြင်ဆင်ပါတယ်။

ဒီစက်ဝန်းက လုပ်ဆောင်ချက်အသစ်တွေနဲ့ bug ပြင်ဆင်မှုတွေအတွက် ထပ်ခါတလဲလဲ လုပ်ဆောင်ပါတယ်။ ကုဒ်တစ်ကြောင်းစီကို ကျွန်တော်ကိုယ်တိုင် မရေးပေမယ့်၊ ဘာကို တည်ဆောက်မလဲ၊ ဘာကြောင့် တည်ဆောက်မလဲ၊ အကြံပြုချက်တစ်ခုက Timmy နဲ့ ကိုက်ညီမညီကိုတော့ ကျွန်တော် ဆုံးဖြတ်ပါတယ်။

စိတ်ကူးမှ WebRTC အထိ

အဓိက နည်းပညာတာဝန်က အစကတည်းက ရှင်းပါတယ်—ဖုန်းနှစ်လုံးကြား အချိန်နှင့်တပြေးညီ အသံနဲ့ ဗီဒီယိုပို့ဆက်ခြင်းပါ။ WebRTC က သိသာတဲ့ရွေးချယ်မှုဖြစ်ပေမယ့် Flutter နဲ့ ပေါင်းစပ်ဖို့က မလွယ်ပါဘူး—ICE candidates၊ SDP negotiation၊ TURN fallback နဲ့ DataChannels တွေက မှန်ကန်တဲ့အစဉ်အတိုင်း အတူတကွ အလုပ်လုပ်ရပါတယ်။

Copilot က ဒီအပိုင်းတွေကို တစ်ဆင့်ချင်း ပေါင်းစပ်ရာမှာ ကူညီခဲ့ပါတယ်—peer connection တည်ဆောက်ခြင်း၊ အရေးကြီးတဲ့ အစဉ်ကို မှန်ကန်စွာထားခြင်း (offer မတိုင်မီ DataChannel၊ setRemoteDescription မတိုင်မီ onTrack) နဲ့ signaling ကို Firebase Firestore ပေါ်မှာ ထားခြင်းတို့ပါ။ နောက်တစ်ဆင့်မသွားခင် အပိုင်းတိုင်းကို emulator နှစ်ခုလုံးမှာ အလုပ်လုပ်စေခဲ့ရပါတယ်။

ECDH ဖြင့် လုံခြုံစွာ ချိတ်ဆက်ခြင်း

အရေးအကြီးဆုံး လုပ်ဆောင်ချက်တွေထဲက တစ်ခုက လုံခြုံတဲ့ ချိတ်ဆက်မှုစနစ်ပါ။ စက်နှစ်လုံးက ၎င်းတို့ရဲ့ အထောက်အထားကို အလယ်ဗဟို server တစ်ခုက အာမခံပေးစရာမလိုဘဲ အပြန်အလှန် ယုံကြည်မှုတည်ဆောက်ရပါတယ်။ ဖြေရှင်းနည်းကတော့ Firebase မှတစ်ဆင့် ECDH P-256 key exchange ပြုလုပ်ပြီး ကြားခံတိုက်ခိုက်မှု (man-in-the-middle attack) ကို ရှာဖွေသိရှိနိုင်တဲ့ မျက်မြင်အတည်ပြုနံပါတ် (SAS) နဲ့ ပေါင်းစပ်အသုံးပြုခြင်းပါ။

Copilot က cryptographic chain ကို အကောင်အထည်ဖော်ရာမှာ ကူညီခဲ့ပါတယ်—key ထုတ်လုပ်ခြင်း၊ public key ဖလှယ်ခြင်း၊ shared secret ရယူခြင်း၊ SAS တွက်ချက်ခြင်းနဲ့ နောက်ပိုင်း signaling data အားလုံးအတွက် AES-256-GCM encryption ပြုလုပ်ခြင်းတို့ပါ။ pairing key ကို backend ဆီ မပို့ပါဘူး—၎င်းရဲ့ SHA-256 hash ကိုသာ Firestore document identifier အဖြစ် သုံးပါတယ်။

လုံခြုံရေးစစ်ဆေးမှု: အားနည်းချက်များကို ရှာဖွေပြီး ပြင်ဆင်ခြင်း

AI အကူအညီနဲ့ ဖွံ့ဖြိုးတိုးတက်ရေးဆိုတာ ကျွန်တော့်အတွက် စာရိုက်တာ ပိုမြန်လာရုံမဟုတ်ပါဘူး။ စနစ်တကျ bug ရှာဖွေရာမှာလည်း ကူညီပါတယ်။ အာရုံစိုက်လုပ်ဆောင်ခဲ့တဲ့ security audit sprint တစ်ခုမှာ Copilot က codebase ကို ခွဲခြမ်းစိတ်ဖြာပြီး ပြင်ရမယ့် ပြဿနာ ခြောက်ခု ကို တွေ့ရှိခဲ့ပါတယ်—

• signaling data အတွက် input validation မရှိခြင်း
• ICE candidate ကို ကိုင်တွယ်ရာတွင် ဖြစ်နိုင်သော race condition များ
• စနစ်တကျ မဖယ်ရှားထားသော session data အဟောင်းများ
• ခွင့်ပြုချက်ကျယ်လွန်းသော Firestore security rules များ
• certificate pinning အတွက် ထည့်သွင်းစဉ်းစားမှုမရှိခြင်း
• TURN credential flow တွင် error handling မလုံလောက်ခြင်း

ဒီပြဿနာ ခြောက်ခုလုံးကို sprint တစ်ခုတည်းမှာ ပြင်ဆင်ခဲ့ပါတယ်။ ဒီနေရာမှာ Copilot က အားကောင်းပါတယ်—ဖိုင်အများကြီးဖတ်ခြင်း၊ ပုံစံတွေကို နှိုင်းယှဉ်ခြင်းနဲ့ ကျွန်တော် ပိုမိုနီးကပ်စွာ စစ်ဆေးရမယ့်နေရာတွေကို အမှတ်အသားပြုခြင်းပါ။

အဆင့်လိုက် Sprint များ: အက်ပ် ဘယ်လိုတိုးတက်လာခဲ့လဲ

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

• v1.8: ချိတ်ဆက်မှုစနစ်ကို အပြည့်အဝ ပြန်လည်ဒီဇိုင်းလုပ်ခြင်း—Firebase မှတစ်ဆင့် စာလုံး 4 လုံးပါ ကုဒ်နဲ့ ECDH P-256 ကို အသုံးပြုပြီး ယခင် direct-key နည်းလမ်းကို အစားထိုးခဲ့ပါတယ်။
• v1.10: လုံခြုံရေးခိုင်မာအောင်လုပ်တဲ့ sprint—အားနည်းချက် ခြောက်ခုကို စစ်ဆေး၊ ပြင်ဆင်တဲ့ လုပ်ငန်းစဉ်ပါ။
• v1.11: မျက်နှာပြင်အားလုံးအတွက် dark mode နှင့် အခုဖတ်နေတဲ့ ပင်မစာမျက်နှာနဲ့ ဘလော့ဂ်။
• v1.12: မိဘမျက်နှာပြင်ကို အကြီးအကျယ် ပြန်လည်မွမ်းမံခြင်း၊ night vision mode နှင့် ကင်မရာ frame များကို ခွဲခြမ်းစိတ်ဖြာကာ လှုပ်ရှားမှုရှာဖွေခြင်း။

sprint တိုင်းက အခြေခံပုံစံတူပါတယ်—ရည်မှန်းချက်ကို ဖော်ပြ၊ အကြံပြုချက်တွေကို ပြန်လည်သုံးသပ်၊ အလိုအလျောက် စမ်းသပ်၊ ပြီးရင် စမ်းသပ်အသုံးပြုသူတွေဆီ ဖြန့်ချိပါတယ်။

စက်များစွာတွင် E2E စမ်းသပ်ခြင်း

ကလေးစောင့်ကြည့်စက်ကို စက်တစ်လုံးတည်းနဲ့ မှန်ကန်စွာ မစမ်းသပ်နိုင်ပါဘူး။ ကလေးစက်တစ်လုံးနဲ့ မိဘစက်တစ်လုံး လိုပါတယ်။ ပရောဂျက်က တစ်ပြိုင်နက် လည်ပတ်နေတဲ့ Android emulator နှစ်ခုနဲ့ စတင်ခဲ့ပြီး အခုတော့ local iOS simulator နဲ့ စက်အစစ် စစ်ဆေးမှုတွေပါ ထပ်ဖြည့်ထားပါတယ်။ အလိုအလျောက် Android test script ကတော့—

1. emulator နှစ်ခုလုံးမှာ အက်ပ်ကို ထည့်သွင်းတယ်
2. စက်နှစ်လုံးလုံးမှာ ချိတ်ဆက်မှုအဆင့်တွေကို ဖြတ်သန်းတယ်
3. အသံနဲ့ ဗီဒီယိုချိတ်ဆက်မှု တည်ဆောက်ပြီးကြောင်း စစ်ဆေးတယ်
4. push-to-talk၊ ကင်မရာထိန်းချုပ်မှုနဲ့ အခြားလုပ်ဆောင်ချက်တွေကို စမ်းသပ်တယ်

emulator နှစ်ခုလုံးက IP address တစ်ခုတည်းကို မျှဝေသုံးထားတာကြောင့် (10.0.2.15)၊ STUN ကနေတစ်ဆင့် direct peer-to-peer ချိတ်ဆက်မှု မဖြစ်နိုင်ပါဘူး။ စမ်းသပ်မှုတိုင်းက Cloudflare TURN relay ကို ဖြတ်သန်းရပါတယ်။ ဒါက စိတ်အနှောင့်အယှက်ဖြစ်ပေမယ့် အသုံးဝင်ပါတယ်—အရှုပ်ထွေးဆုံး ချိတ်ဆက်လမ်းကြောင်းကို အကြိမ်တိုင်း စမ်းသပ်ပြီးသား ဖြစ်စေလို့ပါ။

ကျွန်တော် သင်ယူခဲ့တာများ

AI တွဲဖက်ပရိုဂရမ်မာနဲ့ အက်ပ်တစ်ခုလုံး တည်ဆောက်ရင်း အချက်အနည်းငယ် သင်ယူခဲ့ပါတယ်—

• Architecture က အရင်ကထက် ပိုအရေးကြီးတယ်။ ရှင်းလင်းတဲ့ စည်းကမ်းပုံစံတွေနဲ့ စာရွက်စာတမ်းကောင်းကောင်းရှိတဲ့ codebase က AI ကို ကိုက်ညီတဲ့ကုဒ် အကြံပြုနိုင်အောင် ကူညီပေးပါတယ်။ မရှင်းလင်းမှုက ကုန်ကျစရိတ်မြင့်လာစေပါတယ်။
• စမ်းသပ်ခြင်းက မဖြစ်မနေလိုအပ်တယ်။ AI က ထုတ်လုပ်တဲ့ကုဒ်ကိုလည်း လူကရေးတဲ့ကုဒ်နည်းတူ တင်းကျပ်စွာ စမ်းသပ်ရပါတယ်။ အလိုအလျောက် E2E စမ်းသပ်မှုတွေက ကိုယ်တိုင်စမ်းသပ်ရင် အလွယ်တကူ လွတ်သွားနိုင်တဲ့ ပြဿနာတွေကို ဖမ်းမိခဲ့ပါတယ်။
• လူက လုပ်ငန်းစဉ်ထဲမှာ ဆက်ရှိနေတယ်။ architecture ဆိုင်ရာဆုံးဖြတ်ချက်တိုင်း၊ လုံခြုံရေးအတွက် အလျှော့အတင်းတိုင်းနဲ့ ထုတ်ကုန်နယ်နိမိတ်တိုင်းကို ကျွန်တော်ပဲ တာဝန်ယူပါတယ်။ AI က အကောင်အထည်ဖော်မှုကို မြန်စေပေမယ့် ဆင်ခြင်ဆုံးဖြတ်နိုင်စွမ်းကို အစားမထိုးပါဘူး။
• မြန်ဆန်မှုက အရည်အသွေးမြှင့်တင်ဖို့ အခွင့်အရေးပေးတယ်။ လုပ်ဆောင်ချက်တွေကို ရက်ပိုင်းအစား နာရီပိုင်းအတွင်း ဖြန့်ချိနိုင်တာကြောင့် အသေးစိတ်မွမ်းမံခြင်းနဲ့ bug ပြင်ဆင်ခြင်းအတွက် ထပ်မံပြင်ဆင်နိုင်တဲ့အကြိမ် ပိုရပါတယ်။ မြန်တယ်ဆိုတာ ကောင်းတယ်လို့ အလိုအလျောက် မဆိုလိုပါဘူး။

ရှေ့ဆက်မည့်အရာများ

Baby Monitor Timmy က ဆက်လက်တိုးတက်နေပါတယ်။ iOS ဖြန့်ချိမှုက နီးကပ်လာပြီဖြစ်ပြီး၊ အဲဒီနောက်မှာ sensor လုပ်ဆောင်ချက်အသစ်တွေ နဲ့ လုံခြုံရေးကို ဆက်လက်ခိုင်မာအောင်လုပ်သွားပါမယ်။ လုပ်ငန်းစဉ်ကတော့ အလားတူပါပဲ—ဦးတည်ချက်နဲ့ နယ်နိမိတ်တွေကို ကျွန်တော်သတ်မှတ်ပြီး Copilot က မြန်မြန် အကောင်အထည်ဖော်၊ စစ်ဆေးရာမှာ ကူညီပါတယ်။

လုံခြုံရေးနှင့်ဆိုင်သော အဓိကအစိတ်အပိုင်းတွေကို အခု ရှင်းရှင်းလင်းလင်း အပိုင်းခွဲပြီး အများပြည်သူ ကြည့်ရှုနိုင်တဲ့ baby-monitor-timmy-core repositoryထဲမှာ ထားရှိထားပါတယ်။ အဲဒီနေရာမှာပဲ pairing၊ signaling နဲ့ backend interface တွေအတွက် architecture ဆိုင်ရာ ဆုံးဖြတ်ချက်တွေကို မှတ်တမ်းတင်ထားပါတယ်။

နောက်ထပ်ဆောင်းပါးများ

• Timmy ရဲ့ နောက်ကွယ်က နည်းပညာ
• Timmy က လုံခြုံစွာ ဘယ်လိုချိတ်ဆက်လဲ
• ကလေးစောင့်ကြည့်အက်ပ်တွေ ဘာကြောင့် Open Source ဖြစ်သင့်လဲ
• ကလေးအခန်းထဲက ကိုယ်ရေးကိုယ်တာလုံခြုံမှု

← ဘလော့ဂ်သို့ ပြန်သွားရန်