
> (၂၀၂၀) သြဂုတ်လ ၁၉ ရက်ကစပြီးရင် oakword.tech ဒိုမိန်းက သုံးလို့ရတော့မှာမဟုတ်ပါဘူး။ တစ်လ (၅)ဒေါ်လာ ပေးရတဲ့ droplet ခနဲ့၊ တစ်နှစ်စာပြည့်သွားတဲ့ ဒိုမိန်းကြေးကို ဆက်မပေးချင်တော့တာကြောင့်ပါ။ ပြီးတော့ ကိုယ်လေ့လာချင်တဲ့ အပိုင်းတွေကိုလည်း လေ့လာပြီးသွားပြီလို့ ထင်တဲ့အတွက် droplet ကိုလည်း destroy လိုက်ပါပြီ။ source code ကတော့ github မှာ ဆက်ရှိနေပါမယ်။

အရင်နှစ် နိုဝင်ဘာ လဝက် လောက်မှာ ထင်တယ်၊ DigitalOcean ကိုစစမ်းသုံး ဖြစ်တယ်။ သူဘယ်လို အလုပ်လုပ်တယ်ဆိုတာတွေ သိပြီးတာတော့ ကြာပြီ။ သူများ ဘလော့ တွေဖတ်ရင်လည်း သူ့ကောင်းကြောင်းတွေ အမြဲတမ်း တွေ့ရတာဆိုတော့ ရင်းနှီးနေတာတော့ ကြာပြီ။ မှတ်မှတ်ရရ လွန်ခဲ့တဲ့ နှစ်နစ်လောက်က nodeJS စလုပ်တော့ hosting တွေလိုက်ရှာရင်း တွေ့ဖူးတယ်။ ဒါပေမယ့် ပိုက်ဆံပေးရတယ် ဆိုတော့ လက်ရှောင်ပြီး free ရတဲ့ heroku ပဲသုံးဖြစ်တယ်။ ပြီးတော့ payment က JCB ပေးလို့ရတယ်ဆိုတာကို မသိတာလည်းပါတယ်။ ကိုယ့်မှာ credit card မရှိတော့ မရဘူးထင်ပြီး စိတ်မဝင်စားတော့ပဲ ထားလိုက်တော့တာ။ တလောကမှ ပြန်ကြည့်ရင်း JCB ရတာသွားတွေ့တော့ account ဖွင့်ဖြစ်သွားတာ။

ကိုယ်က နဂိုကတည်းက linux သုံးတာဆိုတော့ droplet တွေစမ်းကြည့်ဖို့ အခက်အခဲတော့ မရှိဘူး။ ဒါပေမယ့် account ဖွင့်ပြီးတော့လည်း သုံးစရာက မရှိဘူးလေ။ လုပ်လက်စ ပရောဂျက် ဆိုတာလည်း မရှိတော့ တစ်ခုခုစလုပ်ဖို့ ကောင်းမယ်ဆိုပြီး စဉ်းစားမိတယ်။ ကိုယ်လောလောဆယ် လေ့လာချင်ပေမယ့် မလေ့လာဖြစ်သေးတဲ့ stack တွေအားလုံး ထည့်သုံးလို့ရမယ့် ပရောဂျက်တစ်ခု စသင့်တယ်လို့ ထင်တယ်။ အဲ့တော့ ကိုယ်စမ်းလုပ်ကြည့်ချင်တဲ့ ဟာတွေကို ချရေးကြည့်ဖြစ်တယ်။

1. Linux Web Server
2. NGINX
3. MongoDB
4. Fastify
5. Redis
6. Svelte

နောက်ဆုံးတော့ Dictionary Web Application တစ်ခုရေးမယ်ဆိုပြီး စဉ်းစားမိသွားတယ်။ ကို Saturngod ရဲ့ Ornagai v3 က ဒေတာတွေကို MongoDB ထဲကို import လုပ်မယ်။ ပြီးရင် fastify ကိုသုံးပြီး API နဲ့ Backend ကို ရေးမယ်။ API အတွက် server side caching ကို Redis နဲ့လုပ်မယ်။ ပြီးရင်တော့ ဒိုမိန်းတစ်ခုဝယ်ပြီး ချိတ်ထားလိုက်ရင် အဆင်ပြေပြီ ဆိုပြီး စဉ်းစားမိသွားတာ ဆိုပါတော့။ အဲ့လိုနဲ့ပဲ Oakword Dictionary ဆိုပြီးလုပ်ဖြစ်သွားတာ။

ကိုယ်က ပုံမှန် static sites တွေပဲရေးခဲ့ဖူးတာ ဆိုတော့ nodeJS နဲ့ server side ပရောဂျက် တစ်ခုလောက် ရေးပြီး deploy လုပ်ကြည့်ချင်စိတ်တော့ ရှိတယ်။ နဂိုတုန်းကတော့ Express နဲ့ဖြစ်ဖြစ်၊ Adonis နဲ့ဖြစ်ဖြစ်ရေးမယ်လို့ စိတ်ကူးထားပေမယ့် ပုံမှန် API အတွက် code base ငယ်ငယ်လေးပဲဆိုတော့ တခြား factor တွေထက် performance ကိုပိုပြီး ဦးစားပေးစဉ်းစားသင့်တယ်လို့ ထင်တဲ့အတွက် အမြန်ဆုံးဆိုတဲ့ Framework တွေကို ရွေးကြည့်ဖြစ်တယ်။ Polka နဲ့ Fastify ထဲက တစ်ခုခုကို ရွေးရမယ်ဆိုတော့ community manintained လည်းဖြစ်၊ Lightweight လည်းပိုဖြစ်တဲ့Polka ကို သဘောကျပေမယ့် Redis နဲ့ Integration အတွက်ဆိုရင် ပိုပြီး သက်တမ်းရင့်တဲ့ Fastify ကပိုအဆင်ပြေမယ်လို့ ထင်တဲ့အတွက် Fastify ကိုပဲ ရွေးဖြစ်တယ်။

API ရေးနေရင်းနဲ့ တစ်ခုစဉ်းစားမိတာက အခုလောလောဆယ်မှာ English to Myanmar ရော Myanmar to English ရော အဘိဓာန် ဒေတာတွေကို Public API လုပ်ထားတာမျိုး မရှိသေးဘူးလို့ (ကျွန်တော် မသိတာလည်း ဖြစ်နိုင်ပါတယ်)။ အဲ့တော့ လုပ်လက်စနဲ့ Public API Source တစ်ခု အဖြစ်ပါလုပ်မယ်ဆိုပြီး ဆုံးဖြတ်ခဲ့ပါတယ်။Access-Control-Allow-Origin ကို \* အဖြစ်ပြောင်းထားတာကလွဲရင် ဘာမှလည်း လုပ်စရာပိုသွားတာ မဟုတ်ဘူးလေ။ အဲ့လိုနဲ့ပဲ Backend ရေးပြီးသွားတယ်ပဲဆိုပါတော့။ ပြဿနာကတော့ ကိုယ့်စက်ထဲမှာ MongoDB နဲ့ Redis က ရပ်ရပ်သွားပြီး ပြန်စလို့မရဘဲ စက်ကို restart ချချပစ်ရတာမျိုးတော့ရှိတယ်။ ဒါပေမယ့် droplet ထဲမှာ သုံးတော့ ဘာပြဿနာမှ မဖြစ်ဘူး။ ubuntu အချင်းချင်းပဲကို တစ်ခါတစ်ခါ ဘာဖြစ်မှန်းမသိဘူး။ ဗားရှင်းကွာတာပဲထင်ပါရဲ့။ droplet က 18 နဲ့ ကိုယ့်စက်က LTS မဟုတ်သေးတဲ့ 19.04 လေ။

FrontEnd ပိုင်းကိုလည်း နဂိုစဉ်းစားထားတဲ့အတိုင်း svelte နဲ့ပဲရေးဖြစ်တယ်။ တစ်ခါမှ မရေးဘူးတာဖြစ်တဲ့အတွက် learn လုပ်ရင်းရေးရမှာဆိုတော့ နည်းနည်းကြာမယ်ထင်ပေမယ့် ရေးကြည့်တော့မှ တစ်ခြားစီပဲ။ ရေးရတဲ့ပုံစံက vue နဲ့ တော်တော်လေး ဆင်တာကိုတွေ့ရတယ်။ Documentation ကလည်း vue နည်းပါး ကောင်းပါတယ်။ မြန်မြန်ဆန်ဆန်ပဲ ရေးပြီးသွားတယ်။ ကိုယ်က ပုံမှန် React ရေးနေတဲ့သူဖြစ်တဲ့အတွက် Tooling ကတော့ သိပ်အားမရဘူး။ React မှာဆို project configuration မှာရော၊ autocomplete၊ auto-import၊ linting၊ prettier စသဖြင့် တော်တော်လည်း ပြည့်စုံတဲ့ ခံစားချက်မျိုးကို ဘယ် frontend framework မှာမှ မရဘူး။ ဒါကတော့ personal preference နဲ့လည်း ဆိုင်ကောင်းဆိုင်နိုင် ပါလိမ့်မယ်။ ကျွန်တော်ကိုယ်တိုင်လည်း competetive programming ပြိုင်ပွဲတစ်ခုမှာ autocomplete တွေ၊ autosuggestion တွေမပါတဲ့ code editor တွေက ပိုပြီး စိတ်ရှုပ်ရသက်သာတယ်ဆိုတာကို ကိုယ်တွေ့ ကြုံဖူးပါတယ်။ သို့ပေငြား React တို့ Flutter တို့လို UI code တွေရေးတဲ့နေရာမှာတော့ autocomplete တွေ၊ autosuggestion တွေက တော်တော်လေး အကျိုးပြုတာလည်း ကိုယ်တွေ့ပါပဲ။

ဒေတာ တွေကိုတော့ robomongo သုံးပြီး import လုပ်ပါတယ်။ မှတ်မှတ်ရရ ဒေတာတွေကို import လုပ်ပြီးတော့ secure ပိုဖြစ်အောင်ဆိုပြီး ufw ကို ကိုယ့် IP ကလွဲလို့ အကုန် deny လုပ်လိုက်ပါတယ်။ အဲ့ဒီမှာ ပြဿနာ စတာပါပဲ။ ufw ကို မည်ကဲ့သို့လုပ်လိုက်သည်မသိ ssh အတွက်ပါ deny လုပ်မိသွားပါတယ်။ droplet ကို ဘယ်ကနေမှ access လုပ်လို့မရတော့ပါဘူး။

ကံကောင်းချင်တော့ digitalocean က website ကနေ access လုပ်ဖို့ console တစ်ခုပေးထားပါတယ်။ အဲ့ console ကနေမှ ufw ကို ssh allow လုပ်ရတယ်။ အကုန်လုံးပြင်ဆင်ပြီးသွားပြီ ဆိုတော့မှ NGINX ကို setup လုပ်ရပါတယ်။ DigitalOcean community tutorials တွေအကူအညီနဲ့ အချိန်သိပ်မယူလိုက်ရပါဘူး။ SSL အတွက်ကတော့ free ရတဲ့ certbot ပဲသုံးလိုက်တယ်။

နောက်ဆုံးမှ Backend ရော Frontend ပါ server နှစ်ခုလုံးကို PM2 နဲ့ run ထားလိုက်တယ်။ အခု [oakword.tech](https://oakword.tech) မှာ တိုက်ရိုက် စမ်းသပ် အသုံးပြုလို့ရပါပြီ။ source code ကိုတော့ [github](https://github.com/frencojobs/oakword) မှာ တင်ပေးထားပါတယ်။ API ကိုလည်း အင်္ဂလိပ်လိုရော၊ မြန်မာလိုပါ သုံးလို့ရပါတယ်။

```bash
curl https://api.oakword.tech/word/google
curl https://api.oakword.tech/word/ကြောင်
```

မြန်မာလို ခေါ်ရင်တော့ document ရှိသလောက် ပြည့်ပြည့်စုံစုံ မထွက်လာသေးတာမျိုးတော့ရှိတယ်။ side project အနေနဲ့လုပ်တာဖြစ်တဲ့အတွက် အရမ်းတော့ အာရုံထားမလုပ်ဖြစ်ဘူး။ နောက်ပိုင်းတော့ အချိန်ရရင် တဖြည်းဖြည်းပြင်သွားဖို့တော့ရှိပါတယ်။


အဘိဓာန် ဒေတာတွေကို Public API လုပ်ထားတာမျိုး မရှိသေးတော့ Oakword Dictionary ဆိုပြီး လေ့လာချင်ပေမယ့် မလေ့လာဖြစ်သေးတဲ့ stack တွေအားလုံး ထည့်သုံးလို့ရမယ့် ပရောဂျက်တစ်ခု စလုပ်ဖြစ်သွားတယ်။

Oakword Dictionary


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

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

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

တက္ကသိုလ်တက်ပြီးနောက်မှာတော့ အသက်ကြီးလာလို့ထင်ပါတယ် "ကြီးလာရင် -" ဆိုတဲ့မေးခွန်းမျိုးတွေ ထပ်မကြုံရတော့ဘူး။ မေးခွန်းက အသွင်ပြောင်းပြီး "ဘာမေဂျာယူထားလဲ"၊ "ဘယ်မေဂျာယူမှာလဲ" ဆိုတာမျိုးဖြစ်သွားတယ် ထင်ပါတယ်။ မေဂျာရွေးပြီးသွားရင်ကော ဘယ်လိုမျိုး ထပ်မေးကြဦးမယ်မသိဘူး။ နောက်ဆိုရင် intern ဘယ်မှာဆင်းမှာလဲ၊ ဘယ်မှာ အလုပ်လုပ်မှာလဲ ဆိုတာမျိုးတွေပါ မေးကြလိမ့်မယ်ထင်တယ်။

တကယ်တော့ မေးခွန်းတွေအမျိုးမျိုးနဲ့ လှည့်ပတ်မေးနေကြပေမယ့် သိချင်ကြတာကတော့ တစ်ခုတည်းလို့ ထင်တယ်။ ကိုယ်မသေခင်ဘာလုပ်သွားချင်လဲ ဆိုတာ။ နည်းလမ်းမျိုးစုံနဲ့ ဖြေနေကြတာဖြစ်ပေမယ့် တကယ့်ရည်ရွယ်ချက်က ကိုယ်မထွက်ခွာသွားရခင် ဘယ်လိုနေထိုင်သွားချင်လဲ၊ ဒါမှမဟုတ် ကိုယ်နေထိုင်သွားချင်တဲ့ဘဝကို ရောက်အောင် ဘယ်လိုသွားမလဲ ဆိုတာပဲလေ။ အဲ့လိုစဉ်းစားကြည့်တော့ "ကိုယ်ဘာဖြစ်ချင်သလဲ" ဆိုတဲ့ မေးခွန်းကတော်တော်ဖြေရလွယ်သွားတယ်။ ချမ်းချမ်းသာသာနေခဲ့ရသူမဟုတ်တော့ သူဌေးအရမ်းဖြစ်ချင်တယ်။ ဒါဆို သူဌေးဖြစ်ဖို့ကအဓိကလားဆိုတော့ အဲ့လိုလည်းမဟုတ်ဘူး။ ချမ်းသာချင်တယ်ဆိုတာက အမျိုးမျိုးသောမေးခွန်းတွေလိုပဲ၊ အဓိကရည်မှန်းချက်မဟုတ်ဘူး ကြားထဲက အဆင့်တစ်ဆင့်သက်သက်ပဲ။ ကိုယ်မသေခင် နေထိုင်သွားချင်တဲ့ ဘဝပုံစံဆိုတာက သပ်သပ်ရှိပြီး သူကမှ အဓိကရည်မှန်းချက် အစစ်။ ကိုယ်နှစ်သက်တဲ့၊ ကိုယ်နေထိုင်သွားချင်တဲ့ဘဝပုံစံကိုတော့ ကဗျာဆန်ဆန်၊စာမှန်မှန် မရေးတတ်တော့ ရေးမပြတော့ဘူး။ တကယ်တော့ "ကြီးလာရင် ဘာဖြစ်ချင်လဲ" ဆိုတာ bucket list ထဲက ပထမဦးစားပေး item တစ်ခုသက်သက်ပဲလေ။


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

When I Grow Up


တစ်ခါတစ်လေ လုပ်စရာလပ်နေတဲ့ အချိန်တွေမှာဆို YouTube ကြည့်ရင်ကြည့်၊ မကြည့်ရင် Google Earth မှာ နေရာစုံ လျှောက်ကြည့်ဖြစ်တာများတယ်။ ဂိမ်းဆော့တတ်သူ မဟုတ်တော့ ပျင်းရင် ဇာတ်ကားကြည့်ရုံအပြင် လုပ်စရာ ထွေထွေထူးထူး မရှိဘူး။ သူများတွေလို စီးရီး တွေလည်း မကြည့်တတ်တော့၊ 13 Reasons Why ကလွဲရင် ဘာမှ မကြည့်ဖြစ်၊ GoT တို့ Stranger Things တို့ ဆိုတာလည်း တစ်ပိုင်းအပြင် မကြည့်နိုင်ဘူး၊ ပျင်းဖို့ကောင်းလွန်းတယ်လို့ ခံစားရလို့ ဆက်မကြည့်ဖြစ်ဘူး။ တကယ်တော့ ဇာတ်ကားလည်း ပုံမှန်မကြည့်ဖြစ်တာကြာပြီ။ အဲ့တော့ Google Earth ကိုပဲ ကြည့်ဖြစ်ရင်းနဲ့ တော်တော်တောင် ကမ္ဘာနှံ့နေပြီ။ Street View ကလည်း နောက်ပိုင်း တော်တော်နှံ့လာပြီဆိုတော့ နေရာစုံပတ်ကြည့်ပြီး သွားချင်တဲ့ နေရာလေးတွေ ရေးမှတ်ထားဖြစ်တယ်။ Inaccessible Island, Nightingale Island စသဖြင့်ပေါ့။ အဲ့ဒီမှာ ရေးမှတ်မထားပေမဲ့ စိတ်ဝင်စားမိတဲ့ တစ်နေရာရှိတယ်၊ North Sentinel Island ဆိုတာ။

အဲ့ကျွန်းကို Google Earth စကြည့်စကတည်းက မြန်မာနိုင်ငံပတ်ဝန်းကျင်တွေပတ်ကြည့်ရင်း သတိထားမိတယ်။ သူ့ကိုစသတိထားမိတာက ကျွန်းစပ်မှာတစ်ဝက်မြုပ်နေတဲ့ သင်္ဘောကြောင့်ပါ။ တကယ်က သင်္ဘောပျက်တစ်စီးကို Goole Earth မှာတွေ့ဖို့ဆိုတာ မခက်ဘူးရယ်၊ နေရာတော်တော်များများမှာ သင်္ဘောပျက်၊ လေယာဉ်ပျက်တွေကို တွေ့နိုင်တယ်။ ဒါပေမယ့် ဘာကြောင့်မှန်းမသိ စိတ်ဝင်စားလို့ ဝီကီပီးဒီးယားမှာ North Sentinel Island ဆိုပြီးရှာဖတ်ကြည့်မိတယ်။ အဲ့တော့မှသိတာ ဒီ North Sentinel lsland ဆိုတာ နယ်နယ်ရရ ကျွန်းမှမဟုတ်ဘဲ၊ သမိုင်းအစဉ်အလာရှိ နာမည်ကြီးကျွန်း။ ကိုယ်ဘာကြောင့်မသိခဲ့လဲဆိုတာ စဉ်းစားလို့မရဘူး။ သူ့သမိုင်းက ဖတ်လေလေ စိတ်ဝင်စားဖို့ကောင်းလေလေဘဲ (၈ တန်းတုန်းကကျက်ခဲ့ရတဲ့ သမိုင်းနဲ့များ ကွာချက်)။ သူ့သမိုင်းက ဟိုးရှေးကတည်းကစတာ ၂၀၁၈ လောက်အထိနံမည်တွင်ဆဲပဲ၊ အကောင်းတွေရော အဆိုးတွေရော။

North Sentinel Island နဲ့ South Sentinel Island တို့ဆိုတာက ဘင်္ဂလားပင်လယ်အော်မှာရှိပြီး အက်ဒမန်ကျွန်းစုထဲမှာ ပါတယ်။ မြန်မာနိုင်ငံနဲ့ ပိုနီးပေမယ့် အိန္ဒိယအစိုးရ ရေပိုင်နက်ထဲမှာကျရောက်တယ်။ Sentinelese လို့ခေါ်တဲ့ လူရိုင်းမျိုးနွယ်စုတွေ နေထိုင်ကြတယ်။ အဲ့ဒီ sentinelese တွေက အာဖရိကကနေ ပထမဆုံးခွာလာပြီး လွန်ခဲ့တဲ့နှစ်ပေါင်း ၆၀၀၀ လောက်က အက်ဒမန်ကျွန်းဆီ ရောက်လာတာဖြစ်မယ်လို့ ခန့်မှန်းရတယ်လို့ဆိုတယ်။ အဲ့ကတည်းက တခြားလူသားတွေနဲ့ အဆက်အသွယ်မလုပ်ဘဲ နေလာတာ အခုထိ ကမ္ဘာ့သီးခြားအဖြစ်ဆုံး မျိုးနွယ်စုအဖြစ် သတ်မှတ်ခံရသည်အထိပဲ။ ၁၈၆၇ မတိုင်မီအထိ North Sentinel Island ဟာ မှတ်တမ်းအထောက်အထားမဲ့ ပျောက်နေခဲ့တယ်ပြီး ဘယ်သူမှရှာမတွေ့၊ သတိမထားမိခဲ့ကြဘူးလို့ ဆိုတယ်။ ၁၇၇၁ မှာ ဗြိတိသျှနယ်မြေသစ်စူးစမ်းလေ့လာသူ ဂျွန်ရစ်ချီက အက်ဒမန်ကျွန်းဘက်မှာ အလင်းရောင်တစ်ချို့ တွေ့ခဲ့တယ်လို့ဆိုပေမယ့် သေသေချာချာ စူးစမ်းခဲ့ခြင်းမရှိခဲ့ဘူး။ ၁၈၆၇ မှာ NINEVAH ဆိုတဲ့ အိန္ဒိယကုန်သင်္ဘောတစ်စီးက တိမ်းမှောက်ပြီး North Sentinel Island ကို ရောက်သွားခဲ့တယ်။ သင်္ဘောပေါ်ပါ လူ ၁၀၀ ကျော်လောက်ဟာ လူရိုင်းတွေရဲ့ တိုက်ခိုက်မှုကိုခံရပြီး အစိုးရကကယ်ဆယ်ခဲ့ရတယ်။ အဲ့ဒီနောက်ပိုင်းမှာ အင်္ဂလိပ်အစိုးရက ကျွန်းအကြောင်းကိုသိပြီး ခပ်ကင်းကင်းနေတာ အကောင်းဆုံးဖြစ်မယ်လို့ယူဆပြီး ကျွန်းကိုလက်ရှောင်နေခဲ့တယ်။ ၁၈၈၀ မှာ ဗြိတိသျှရေတပ်မှူး Maurice Vidal Portman ဆိုသူက ကျွန်းသား လူရိုင်းတွေနဲ့ မိတ်ဆွေဖွဲ့ဖို့ကြိုးစားခဲ့တယ်။ လူရိုင်း ၆ ယောက်ကိုဖမ်းခေါ်နိုင်ခဲ့ပြီး လူနေမြို့ပြဖြစ်တဲ့ Port Blair ကို ခေါ်ဆောင်ခဲ့တယ်။ မိတ်ဆွေဖွဲ့ဖို့ ရည်ရွယ်ချက်ကောင်းနဲ့ ခေါ်လာခဲ့တာဖြစ်ပေမယ့် လူသားတွေနဲ့အဆက်အသွယ်မဲ့ သီးသန့်နေလာခဲ့တာ ဖြစ်တော့ လူနေရပ်ဝန်းကိုရောက်စမကြာခင်မှာဘဲ နေမကောင်းဖြစ်ခဲ့ကြပြီး အကြီးပိုင်းနှစ်ယောက်က သေသွားခဲ့တယ်။ ကျန်တဲ့ လေးယောက်ကိုလည်း လက်ဆောင်ပစ္စည်းတွေနဲ့အတူ ကျွန်းကိုအမြန်ပြန်ပို့ပေးခဲ့တယ်။ မစ္စတာ Portman ဟာ ဖမ်းဆီးခေါ်ဆောင်သွားတဲ့ကိစ္စနဲ့၊ သေဆုံးသွားတဲ့ နှစ်ယောက်အတွက်ရှင်းပြလိုတဲ့သဘောအတွက် လက်ဆောင်ပစ္စည်းတွေထည့်ပေးခဲ့တာဖြစ်ပေမယ့် လူရိုင်းတွေဟာနားလည်သွားခဲ့ပုံမပေါ်ပါဘူး။ မစ္စတာ Portman ကိုယ်တိုင်လည်း အဲ့ဒီကိစ္စကို အရေးမထားခဲ့ကြောင်း ဆိုပါတယ်။ လူရိုင်းတွေနဲ့ ပြင်ပ ဆက်သွယ်ရေးကတော့ ပိုမိုဆိုးရွားသွားခဲ့ပါတယ်။

၁၈၉၆ မှာ Port Blair ထောင်မှ အကျဉ်းသားတစ်ဦးဟာ ထောင်ဖောက်ပြေးပြီး၊ ဝါးဖောင်တစ်ခုနဲ့ North Sentinel Island ဆီထွက်ပြေးခဲ့ပါတယ်။ ဒါပေမယ့် ကံမကောင်းစွာနဲ့ပဲ ကျွန်းသားတွေရဲ့သတ်ဖြတ်ခြင်းကို ခံခဲ့ရပါတယ်။ အလားတူထွက်ပြေးတဲ့ အခြားအကျဉ်းသားတွေဟာလည်း သတ်ဖြတ်ခံခဲ့ရတယ်လို့ ဆိုပါတယ်။ လွတ်လပ်ရေးရပြီးနောက်မှာ အိန္ဒိယအစိုးရက ကျွန်းသားတွေနဲ့တွေ့ဆုံမိတ်ဆွေဖွဲ့ဖို့ကြိုးစားခဲ့ပေမဲ့ မအောင်မြင်ခဲ့ပါဘူး။

Google Earth မှာအခုမြင်နေရတဲ့ ကမ်းစပ်က သင်္ဘောပျက်ဟာ Primrose လို့ခေါ်တဲ့ ကုန်သင်္ဘောဖြစ်ပါတယ်။ Primrose ဟာ ၁၉၈၁ သြဂုတ်လမှာ ကျွန်းစပ်ကျောက်တန်းမှာ သောင်တင်မိခဲ့ပါတယ်။ အကူအညီခေါ်ဆောင်ခဲ့ပြီး ရောက်မလာခင်အထိ သင်္ဘောသားတွေနဲ့ ကပ္ပတိန်ဟာ ကျွန်းပေါ်မတက်ဘဲ သင်္ဘောပေါ်မှာသာ စောင့်ဆိုင်းနေခဲ့ကြပါတယ်။ စောင့်ဆိုင်းနေစဉ်ကာလအတွင်းမှာ ရန်လိုတဲ့ကျွန်သားတွေရဲ့ မြား၊ လှံ၊ လက်နက်တွေနဲ့ ကမ်းစပ်မှခြောက်လှန့်နေတာကို မြင်တွေ့ခဲ့ရပါတယ်။ ဒါပေမဲ့ သင်္ဘောနဲ့ ကျွန်းဟာ အတန်ငယ်လှမ်းတဲ့အတွက် စိတ်မပူခဲ့ကြပါဘူး။ မကြာခင်မှာ ကျွန်းသားတွေက ဝါးဖောင်တွေ၊ လှေတွေဆောက်နေတာကို မြင်ရတဲ့အခါမှာတော့ သင်္ဘောသားတွေဟာအလွန်စိုးရိမ်သွားခဲ့ကြပါတယ်။ အရေးပေါ်အချက်ပြမီးတွေ ထုတ်ကာ၊ အစွမ်းကုန်ဆက်သွယ်ဖို့ကြိုးပမ်းခဲ့ကြပေမဲ့ အလွန်ဆိုးရွားစွာတိုက်ခတ်နေတဲ့ မုန်တိုင်းကြောင့် တစ်ပတ်ကြာသည်အထိ အခြားသင်္ဘောတွေက သတိမပြုမိခဲ့ကြပါဘူး။ တစ်ပတ်ကြာမှ ဟယ်လီကော်ပတာနဲ့ ကယ်ဆယ်ခဲ့ရပြီး လက်မတင်လေး လွတ်မြောက်ခဲ့တယ်လို့ ဆိုပါတယ်။

၂၀၀၆ ဇန်နဝါရီမှာ လှေတစ်စင်းပေါ်မှာအိပ်ပျော် (အရက်မူးတယ်လို့လည်းဆိုတယ်) ပြီး မျှောသွားတဲ့ ငါးဖမ်းသမားနှစ်ဦးဟာ သတ်ဖြတ်ခံခဲ့ရပါတယ်။ အဲ့ဒီကိစ္စဖြစ်ပြီးတဲ့နောက်မှာ အိန္ဒိယအစိုးရက ကျွန်းပတ်ပတ်လည်ရေဇုန်သုံးမိုင်ကို ဖြတ်သန်းမသွားရနယ်မြေအဖြစ် သတ်မှတ်ခဲ့ပါတယ်။ ၂၀၁၈ နိုဝင်ဘာမှ အမေရိကန် ခရစ်ယာန်သာသနာပြုတစ်ဦးဟာ တရားမဝင်သာသနာပြုသွားရင်းသတ်ဖြတ်ခံခဲ့ရပါတယ်။ အဲ့ဒီနောက်မှာတော့ အိန္ဒိယအစိုးရက ကျွန်းကိုသွားရောက်ပတ်သက်ခြင်းမပြုဖို့ အမိန့်ထုတ်ပြန်ခဲ့ပါတယ်။ ကျွန်းရဲ့သမိုင်းဟာဒီမှာ တစ်ခန်းရပ်ပါတယ်။

North Sentinel Island ဟာ bucket list ထဲသွားချင်တဲ့နေရာထဲမှာတော့ မပါပါဘူး။ မသွားရဲတာကလွဲရင် သွားတော့သွားချင်ပါသေးတယ်။ တခြားမှတ်ထားတဲ့နေရာတွေလည်း ရှိပါသေးတယ်။ နောက်တစ်ခါတော့ တကယ်သွားချင်တဲ့နေရာလေး ရေးဖြစ်မယ်ထင်ပါတယ်။


သမိုင်းအစဉ်အလာရှိ နာမည်ကြီးကျွန်း။ ကိုယ်ဘာကြောင့်မသိခဲ့လဲဆိုတာ စဉ်းစားလို့မရဘူး။ သူ့သမိုင်းက ဖတ်လေလေ စိတ်ဝင်စားဖို့ကောင်းလေလေဘဲ၊ အကောင်းတွေရော အဆိုးတွေရော။

North Sentinel Island


Sometimes you probably might wonder how fast your web application can proceed, or your javascript code can work. Or possibly a user of your application (generally a customer) might want to complain about the speed of your work and this is an important factor in representing your project in front of your app's consumers and sponsors. They wonder the most when your app is matter in working with source that needs speed, especially I mean the most to frameworks and projects that are intended to the customers who need the fastness than the others. Together with the advancement of technology, you can now test the performance with the help of browsers' extensions and developer tools like benchmarks. They work of course well, but as a proficient javascript developer, you should know that you can do the same with originally provided APIs.

### With Date Object

Testing the performance is all about dealing with time. The great thing is that almost every programming language has a date class, with the help of it we can handle the counting of time easier. So, let me write a few code representing the calculation of performance together with date object. Don't forget that you are facing with computer processing that can perform a lot even in a short time. They really are super fast, therefore, you can't count it's working rate per time with seconds, if so the error percent will be huge and your test can't be accurate. Date object has a method called `getTime()` that can return the number of milliseconds since 1 January 1970 00:00:00, and that might really be useful in our testing. (To have more accurateness, milliseconds in not sufficient enough to perform the test. High resolution time could be measured using the `performance API` that we'll cover later in the next part of this article.)

I just want to show you also can just do that way, and I also intended to the runtime scripts that will not be supported by the performance API. For the browsers used scripts, I want you to prefer the performance API that results in high resolution time and it's the highly recommended `API` supported for performance testing.

```js
let startTime, endTime, timeTaken;

startTime = new Date().getTime();
setTimeOut(() => {
  console.log("nothing");
  endTime = new Date().getTime();
  timeTaken = endTime - startTime;
}, 1000);

console.log(`It took about ${timeTaken} milliseconds`);
```

### With performance API

Can you see that I mentioned _"about "_ in the last line of code, that means that the way we did earlier results in an inaccurate value of time, because milliseconds were not enough to measure that great rate of work. What we need to do so is to find high resolution time, and in that way it might be really good. That's important because if you don't know the precise performance of your application, you also can't optimize it in a really good way.

How can you get the high resolution time? That's the easy one. You can get it by calling the now method of the performance object. And we can use it in the same way we did earlier.

```javascript
let perf = window.performance;
let time = perf.now();
```

But from here, I'm not doing the same as the performance object also provided other useful ways to do so and we will use them, we should use them.

You can use `performance.mark` to mark with tags like marking start time and end time, but the `mark` methods will result not the same as the `getTime` method, it's more precise and it's what we are saying, High Resolution Time. And you can measure the time taken between two marked tags by the method `performance.measure`. After measuring, the API will store you measured data in the Entries array of the performance API. The `performance.measure` method takes three parameters, the first is the name of your data in which your measured entries will be stored, the next two are the former start tag and the latter end tag you've been marked.

In a few lines of code, I can show how to do so.

```javascript
performance.mark("startTime");

setTimeOut(() => {
  console.log("nothing");
  performance.mark("endTime");
  performance.measure("timeTaken", "startTime", "endTime");

  let measures = performance.getEntriesByName("mySetTimeout");
  let measure = measures[0];
  console.log("setTimeout milliseconds:", measure.duration);

  performance.clearMarks();
  performance.clearMeasures();
}, 1000);
```

The method measure results in an object with the elements:

```json
{
  "name": "Name of the Entry",
  "entryType": "Type of the Entry",
  "startTime": "starting time",
  "duration": "time taken"
}
```

Therefore, to get the time taken you have to call the entry duration. Don't forget the last lines that cleared the cached entries, if not, these entries will appear and mess your code up next time you measure. You'll see the duration is pretty precise than the `getTime` method, and that's may be the reason why we should use the performance API. In fact, Date object is not created for the performance testing but the performance object is.


Performance API, a forgotten one, is actually very useful.

Measuring performance of your JavaScript code


Together with the advancement of web technology, I saw that people prefer more to single page applications than multiple pages applications. But there're still a lot of questions about using single page applications (from now on I will refer to SPA) everywhere, such as should we use SPAs in every of our web applications, and projects? Honestly, for me the answer is 'I don't know' . How do I know the likes and unlikes of every people, but out of everyone I like them. For some reasons, I love them. I saw people saying that they makes the application uglier, but I don't think so. The advantage of SPAs is that during the loading state (technically while the browser's request and server response are working) ,we can make the clients not to feel bored by showing some cool UI effects and animations, skeleton structures and some awesome loading effects other than the spanning circle of the browser (and also the running dots in Firefox and IE).

### SPA or MPA
. 
Nothing is perfect. Even though SPA seems great, it's not flawless. With single page applications, we can get responsive design and fast loading as it loaded most resources such as HTML, CSS, and some scripts once throughout it's lifespan. They don't update the whole page but only the required content by the help of modern web technologies such as AJAX(asynchronous javascript and XML) and HTML5. You now can choose many of many javascript frameworks for the better performance of your _SPA (Vue, React, Angular, Mithril, and others)_ We don't have build every response of query from server, only data is transmitted and your javascript functions will render it to the view. If your projects needs SEO optimization, SPA is not a good choice. And as another bad thing, a lot security issues can occur if you don't handle it specifically. SPA is good for social networks that don't need SEO optimization, and simple applications with small data.Other opinions such as depending too much on javascript , browser history, and scalability can be solve with wits, skill and experience on coding.And maintainability can no longer be an issue as there are debugging tools for each frameworks, some frameworks even have really large community such as react and angular.

After a long and tedious lines, its time for what I really want to say.

When you want to build dead simple applications, requiring skill to master frameworks can sometimes be an issue. But it's not what I really want you to know, these skills can be useful, the issue it that we are linking all the codes from frameworks but don't use it. If you want to listen an event, you don't need to create an Observable (stream if it sounds wired) until you need the other functionalities that they offer. It sometimes can slow down the performance of your applications.

```javascript
Rx.Observable.fromEvent(button, "click").subscribe(() => {
  console.log("Button has been clicked!");
});
```

It will be the same if you do this in vanilla javascript,

```javascript
button.addEventListener("click", () => {
  console.log("Buttton has been clicked!");
});
```

These frameworks are not there for that, they are for maintaining complex codes, complex ideas and large-scaled applications, don't misappropriate them.

### Routing

Routing or navigating is a non-trivial matter in single page applications. The code I will implement will be capable of routing with hash or hash-bang. For those who think that routing with hashes does not seems cool should dig deep about Web History API or routing frameworks and library. The reason I don't implement such a cool routing is that it needs to be handle also from the server, maybe there're some people who dig into SPA not to touch the server side will not think that cool routing will not seems cool.

So let's start, first abstract the final version how can we manage the routes.

```javascript
let router = new Router({ outlet: "#router-outlet" });
let routes = {
  "/": `<p>This is home page</p>`,
  "/about": `<p>This is about page</p>`,
};

router.forRoot(routes);
```

By splitting them into small parts. We know that,

Router has to be a class and its argument is an object where we can define router outlet, the place where our routes data will be rendered.

Prototype of Router, `forRoot` function accepts an object of routes in the interface of { path : template }

The good thing for our router is that as it works with hashes, changes of hashes in location object can be easily tracked so we can track it according to the changes we should update the template of the current route.

Our router will work only when the `forRoot` function is called, it will take the routes that the function provide and navigate to each routes when the changes from hash of location is tracked. So we should define a function called navigate that takes the hash from the URL, and if there's no hash it could set `'#/'`. We also should run it for the first time when the browser loaded the page for the first the first time.

```javascript
//create the Router class
class Router {
  constructor(config) {
    this.outlet = config.outlet; // user defined router-outlet URL
  }
  forRoot(routes) {
    this.routes = routes;
    window.addEventListener("hashchange", () => {
      // track the hashchange
    });
  }
}
```

The basic structure is done, we have to define what we have said, navigate function. Our navigate function in constructor will look like this,

```javascript
this.navigate = (routes) => {
  if (!location.hash) location.hash = "#/"; //If there's no hash
  let path = location.hash.substr(1); // remove the hash
  //It's time to render
  if (routes[path]) {
    document.getElementById(this.outlet).innerHTML = routes[path];
  }
};
```

This navigate function will have to work in the hashchange event and also when the forRoot is called, so router will work for the first time after page loading. Let's put these pieces in place.

```javascript
class Router {
  constructor(config) {
    this.outlet = config.outlet;
    this.navigate = (routes) => {
      if (!location.hash) location.hash = "#/";
      let path = location.hash.substr(1);
      if (routes[path]) {
        document.getElementById(this.outlet).innerHTML = routes[path];
      }
    };
  }
  forRoot(routes) {
    this.routes = routes;
    this.navigate(routes);
    window.addEventListener("hashchange", () => {
      this.navigate(routes);
    });
  }
}
```

This router works fine, I intended to ones who needs only a router engine, not two way data-binding, not directives and no reducers and state managements.

You can import templates using AJAX and then you can build a dead so simple SPA. I hope this article would be useful. Thanks.


How can you make one in vanilla JavaScript, intuitively.