Using Android as Remote Control for Ubuntu PC

ကျွန်တော့်အနေနဲ့ အခုနောက်ပိုင်း BarCamp, Developer Conference နဲ့ အခြား Seminer တွေမှာ အလျှင်းသင့်သလို ပါဝင်ဆွေးနွေးဖြစ်ပါတယ်။ နိုဝင်ဘာ ၂၃ ရက် (မနက်ဖြန်) စတင်တော့မယ့် Developer Conference Yangon – 2013 မှာလည်း Mobile Web နဲ့ပက်သက်တဲ့ အကြောင်းအရာတစ်ခုကို “The Approach of Responsive Web Design” ဆိုတဲ့ခေါင်းစဉ်နဲ့ ပါဝင်ဆွေးနွေးဖို့ စီစဉ်ထားပါတယ်။

အကြောင်းအရာတစ်ခုကို ဦးဆောင်ဆွေးနွေးရာမှာ PowerPoint Slide တွေ တစ်ခုပြီးတစ်ခု ထိုင်ပြပြီး အဲ့ဒီ Slide တွေမှာရေးထားတဲ့ စာကို ဖတ်ပြနေယုံနဲ့တော့ အဆင်မပြေပါဘူး။ သက်ဆိုင်ရာအကြောင်းအရာကို ပရိတ်သတ်ရော ဦးဆောင်ဆွေးနွေးသူကပါ စိတ်ဝင်တစား၊ တက်ကြွစွာ တင်ပြဆွေးနွေးမှ Presentation ကောင်းတစ်ခုဖြစ်မှာပါ။ ဒီနေရာမှာ Body Language က အတော်လေး အရေးပါတယ်လို့ ကျွန်တော်ယုံကြည်ပါတယ်။ ဒါပေမယ့် ကျွန်တော်တို့ဆီက Conference တွေမှာ ပစ္စည်းကိရိယာအခက်အခဲ အချို့ရှိနေတက်ပါတယ်။ Wireless Hand-free Mic တွေ မရှိကြပါဘူး။ Remote Control တွေ မရှိကြပါဘူး။ ဒီတော့ ဦးဆောင်ဆွေးနွေးသူက Laptop နဲ့ Mic အသင့်နေရာချထားတဲ့ စင်နောက်မှာ ပုံသေမတ်တက်ရပ်ပြီးတော့ပဲ ဆွေးနွေးကြရပါတယ်။ Laptop နဲ့ Mic နားကနေ ခွာလို့မရတော့ အရေးကြီးပါတယ်ဆိုတဲ့ Body Language မပါဝင်နိုင်တော့ပါဘူး။

ဒါကိုဖြေရှင်းဖို့အတွက် Wireless Mic နဲ့ Remote Control လိုပါတယ်။ ဒီနေရာမှာ Android Phone တစ်လုံးကို အသုံးပြုပြီး Ubuntu PC တစ်ခုကို Remote Control လုပ်ပုံလေး ဖော်ပြပေးချင်ပါတယ်။

၁. ပထမဦးဆုံး Ubuntu မှာ SSH Server နဲ့ xdotool တို့ကို Install လုပ်ထားဖို့လိုပါတယ်။ ဒီနည်းနဲ့ Install လုပ်နိုင်ပါတယ်။

sudo apt-get install openssh-server xdotool

SSH Server ကတော့ Android ကနေ Ubuntu ကို Remote Access လှမ်းလုပ်နိုင်ဖို့ဖြစ်ပါတယ်။ xdotool ကတော့ လက်ရှိ Run နေတဲ့ X Session ကို Command Line ကနေ Manage လုပ်နိုင်ဖို့ ဖြစ်ပါတယ်။

၂. ပြီးရင် Ubuntu Remote Control ဆိုတဲ့ App ကို Google Play Store မှာ ရယူနိုင်ပါတယ်။ Play Store Account မရှိရင်လည်း APK Downloader ကိုအသုံးပြုပြီး Play Store App တွေကို Download လုပ်ယူနိုင်ပါတယ်။ ရယူလိုတဲ့ App ရဲ့ Play Store URL ကို ထည့်ပေးလိုက်ယုံပါပဲ။ Download ရယူပြီးရင် Remote Control အဖြစ် အသုံးပြုလိုတဲ့ Android Device မှာ Install လုပ်ပေးပါ။

ubuntu-remote-installer

ubuntu-remote-app

၃. App ကို Run ပြီး Ubuntu ကို ချိတ်ဖို့အတွက် Setting တွေ ထည့်ပေးရပါမယ်။ ဒီနေရာမှာ App က Network နဲ့ SSH ကိုသုံးပြီး Ubuntu ကို Remote Access လုပ်မှာဖြစ်လို့ Android Device မှာ Wifi ဖွင့်ထားဖို့လိုသလို၊ Ubuntu PC နဲ့ Android Device တို့ဟာလည်း Network တစ်ခုထဲမှာ ရှိနေဖို့လိုအပ်တာကို သတိပြုပါ။

ubuntu-remote-add

Add your first ubuntu client ကိုနှိပ်ပြီး Setting Dialog ပေါ်လာတဲ့အခါ၊ Ubuntu PC ရဲ့ IP Address, User Name နဲ့ Password တို့ကို ထည့်ပေးရပါမယ်။

ubuntu-remote-setup

တစ်ချို့ Action တွေက Ubuntu ရဲ့ Root User အဖြစ်ဆောင်ရွက်ဖို့လိုလို့ Superuser Password ပါ ထည့်ပေးထားသင့်ပါတယ်။ ပြီးရင် Connect နှိပ်လိုက်တာနဲ့ App က Ubuntu PC ကို SSH အသုံးပြု ချိတ်ဆက်သွားမှာပါ။

၄. ချိတ်ဆက်ပြီးသွားတဲ့အခါ ရရှိလာတဲ့ Interface မှာပါဝင်တဲ့ Default Shortcut တွေကို အသုံးပြူပြီး Ubuntu PC ကို Restart လုပ်ခြင်း၊ Shutdown လုပ်ခြင်း၊ Screenshot ရယူခြင်း၊ Music Playback ပြုလုပ်ခြင်းတို့ကို Android Device ကနေ ပြုလုပ်နိုင်ပြီဖြစ်ပါတယ်။

ubuntu-remote-shortcuts

Custom Command ကို နှိပ်ပြီးတော့ နှစ်သက်ရာ Shell Command တွေ ထည့်သွင်းနိုင်ပါသေးတယ်။ Shortcut တွေ ထပ်ထည့်လိုရင်၊ ဒါမှမဟုတ် လက်ရှိ Shortcut ကို Edit လုပ်လိုရင် Shortcut ကို သုံးစက္ကန့်ခန့် နှိပ်ထားပေးရပါတယ်။

ubuntu-remote-shortcut

Shortcut Icon ကို အသင့်ပါလာတဲ့ Icon တွေ သုံးနိုင်သလို၊ Custom Icon နဲ့လည်း သတ်မှတ်ထားနိုင်ပါတယ်။ Command အနေနဲ့လည်း အသင့် Preset ပေးထားတဲ့ Command စာရင်းထဲက ရွေးနိုင်သလို၊ Custom Command တွေလည်း သတ်မှတ်ထားနိုင်ပါသေးတယ်။

၅. Default Shortcut တွေထဲမှာ ကျွန်တော့်အတွက် တစ်ကယ်လိုအပ်တဲ့ လုပ်ဆောင်ချက်က ပါမလာပါဘူး။ ကျွန်တော်က Android Device ကို Remote အနေနဲ့ အသုံးပြုပြီး Presentation ပြုလုပ်လိုတာပါ။ ကျွန်တော့် Presentation က LibreOffice Impress ကိုသုံးထားတာဆိုရင်တော့ ဒီလောက်တောင် ခေါင်းစားနေဖို့ မလိုပါဘူး။ LibreOffice Impress Remote App ကို သုံးလိုက်ယုံပါပဲ။ အခုကျွန်တော်တို့ ဖော်ပြနေတဲ့ Ubuntu Remote App တောင် မလိုပါဘူး။

ဒါပေမယ့် ကျွန်တော့် Presentation က LibreOffice Impress ကို သုံးထားတာမဟုတ်သလို၊ Remote ကိုသုံးပြီး Presentation တင်မက တစ်ခြားကိစ္စတွေပါ ဆောင်ရွက်လိုတဲ့အတွက် LibreOffice App ကို မသုံးပြု Ubuntu Remote App ကို ရွေးချယ်ထားတာပါ။ ကျွန်တော့် Presentation က Chromium Browser နဲ့ အလုပ်လုပ်တာပါ။ ဒါပေမယ့် Remote က ဒါတွေသိစရာမလိုပါဘူး။ လက်ရှိ Active ဖြစ်နေတဲ့ Window ထံ Up/Down Key Press Action ပေးပို့နိုင်ရင် ရပါပြီ။ ဒါကြောင့်.. အောက်ပါ Command တွေကိုသုံးပြီး Shortcut အသစ်နှစ်ခု တည်ဆောက်ထားလိုက်ပါတယ်။

DISPLAY=:0 xdotool getactivewindow key Up
DISPLAY=:0 xdotool getactivewindow key Down

ubuntu-remote-down

ဒီနည်းနဲ့ Ubuntu PC ပေါ်က Presentation ကို Android Device ကနေ Control လုပ် စီမံနိုင်သွားပြီဖြစ်ပါတယ်။

၆. နောက်ဆုံးတစ်ခုအနေနဲ့ကတော့.. ဒီ Remote App နဲ့ပဲ Ubuntu PC က File တွေကို စီမံနိုင်ပါသေးတယ်။ ဘယ်ဘက်အပေါ်နားက SFTP ကို ရွေးပြီး စီမံနိုင်ပါတယ်။

ubuntu-remote-sftp

လက်ရှိမှာ PC အတွက် Ubuntu နဲ့ Mobile အတွက် Android အသုံးပြုနေသူတွေအတွက် အသုံးဝင်လိမ့်မယ်လို့ မျှော်လင့်ပါတယ်။

ကျေးဇူးတင်ပါတယ်…

Howto Setup HTTPS for Your Website

SSL/TLS and HTTPS

အင်တာနက်မှာ အချက်အလက်တွေ ပေးပို့ဆက်သွယ်တဲ့အခါ၊ အဲ့ဒီအချက်အလက်တွေကို ကြားဖြတ်ဖမ်းယူ ခံရနိုင်တဲ့ အန္တရာယ် ရှိနေပါတယ်။ တစ်လောကပဲ အမေရိကန် အစိုးရအဖွဲတစ်ခုဖြစ်တဲ့ NSA ကအင်တာနက်အသုံးပြုသူတွေရဲ့ အချက်အလက်တွေကို ကြားဖြတ်ဖမ်းယူ နေပါတယ်ဆိုတဲ့ ကိစ္စတစ်ခု ဟိုးလေးတစ်ကျော် ဖြစ်ခဲ့ပါသေးတယ် (PRISM)။ အင်တာနက် Website တွေနဲ့ ဆက်ဆံပြီး နေစဉ် ပေးပို့ရယူဆက်သွယ်နေတဲ့ အချက်အလက်တွေထဲမှာ ကျွန်တော်တို့ရဲ့ တစ်ကိုယ်ရေ ကိုယ်ရေးကိုယ်တာတွေ ပါနိုင်ပါတယ်။ အရေးကြီးတဲ့ Password တွေ ပါနိုင်ပါတယ်။ Credit Card No. တွေ ပါနိုင်ပါတယ်။ ဒီလိုအချက်အလက်တွေကို မသမာသူတစ်ဦးက ကြားဖြတ်ဖမ်းယူ ရရှိသွားမယ်ဆိုရင် ကျွန်တော်တို့အတွက် အတော်လေး ထိခိုက်ဆုံးရှုံး နစ်နာစရာ ရှိပါတယ်။ ကြားဖြတ်ဖမ်းယူနိုင်တဲ့ နည်းပညာတွေကလည်း အမျိုးမျိုးရှိနေပြီး၊ ကနေ့ခေတ်မှာ.. နည်းပညာအတော်အသင့် နားလည်ယုံနဲ့ ကြားဖြတ်ဖတ်ယူခြင်း လုပ်ငန်းကို ဆောင်ရွက်နိုင်နေပါတယ်။

Secure Socket Layer (SSL) ဆိုတဲ့နည်းပညာက အဲဒီလိုကြားဖြတ် ဖမ်းယူခြင်းကနေ ကာကွယ်ဖို့အတွက်၊ ပေးပို့ဆက်သွယ်တဲ့ အချက်အလက်တွေကို ဝှက်စာ  အဖြစ် ပြောင်းပေးတဲ့ (Encryption) နည်းပညာတစ်မျိုး ဖြစ်ပါတယ်။ အကယ်၍ တစ်စုံတစ်ယောက်က ကြားဖြတ်ဖမ်းယူခဲ့ရင်တောင် ဝှက်စာကိုပဲ ရရှိမှာဖြစ်လို့ ဝှက်စာဖော်နိုင်တဲ့ Key မရရှိရင် မူရင်းအချက်အလက်တွေက ဘာလဲဆိုတာ မသိနိုင်တော့ပါဘူး။ Transport Layer Security (TLS) ကတော့ SSL ကို အဆင့်မြှင့်ထားတဲ့ ပိုမိုအားကောင်းတဲ့ ဝှက်စာစနစ် ဖြစ်ပါတယ်။ HTTPS ဆိုတာကတော့ အဲ့ဒီ SSL/TLS ဝှက်စာစနစ်ကို Web နည်းပညာနဲ့ ပေါင်းစပ်ပေးတဲ့ ဆင့်ပွား နည်းပညာဖြစ်ပါတယ်။ တနည်းအားဖြင့် SSL/TLS ကို Website တွေအတွက် အသုံးပြုနိုင်အောင် ကူညီပေးတဲ့ နည်းပညာပါ။

Website တွေတည်ဆောက်တဲ့အခါ၊ ကျွန်တော်တို့က Website အသုံးပြုသူတွေရဲ့ Privacy နဲ့ လုံခြုံရေးကို ကာကွယ်ပေးဖို့ တာဝန်ရှိပါတယ်။ အဲ့ဒီထဲမှာ ဝှက်စာစနစ်တပ်ဆင်ထားတဲ့ HTTPS နဲ့ အသုံးပြုနိုင်အောင် ဖန်တီးပေးခြင်းလည်း တစ်ခုအပါအဝင် ဖြစ်ပါတယ်။ နေ့စဉ် အင်တာနက် အသုံးပြုနေသူ တစ်ယောက်အဖို့ Google, Twitter, Facebook အစရှိတဲ့ လုပ်ငန်းတွေက သူတို့ရဲ့ Website တွေကို HTTPS နဲ့ လုံခြုံစွာ အသုံးပြုနိုင်အောင် ဆောင်ရွက်ပေးထားတာကို သတိပြုမိမှာပါ။

ကျွန်တော်တို့ Website တွေအတွက် HTTPS စနစ်တပ်ဆင်နည်း တစ်ခုကို ဖော်ပြပေးလိုက်ပါတယ်။

Register with StartSSL

အခြေခံအားဖြင့်.. ဝှက်စာ ပြောင်းလဲခြင်း၊ ဖော်ထုတ်ခြင်း လုပ်ငန်းစဉ်ကို ပံ့ပိုးပေးနိုင်တဲ့ SSL Certificate Provider တစ်ဦးဆီက Certificate တွေကို ဝယ်ယူရမှာ ဖြစ်ပါတယ်။ ဒီနေရာမှာတော့.. အခမဲ့ဝန်ဆောင်မှုပေးနေတဲ့ StartSSL ဆိုတဲ့ Provider ထံကနေ ရယူတပ်ဆင်ပုံကို ဖော်ပြပေးသွားမှာ ဖြစ်ပါတယ်။

StartSSL က အသုံးပြုနေတဲ့ Browser ကို မှတ်ထားမှာဖြစ်လို့၊ အခုချိန်ကစပြီး “Browser တစ်ခုတည်းကိုသာ လုပ်ငန်းစဉ် ပြီးဆုံးတဲ့အထိ သတ်သတ်မှတ်မှတ် အသုံးပြုသွားရမယ်” ဆိုတဲ့အချက်ကို ပထမဦးဆုံး သတိပြုစေလိုပါတယ်။

ပထမဆုံးအဆင့်အနေနဲ့ StartSSL Sign Up Form မှာ လိုအပ်တဲ့အချက်အလက်တွေ ဖြည့်စွက်ပြီး မှတ်ပုံတင်လိုက်ပါ။

startssl-reg

အချက်အလက်တွေ ဖြည့်စွက်ပြီး Continue နှိပ်လိုက်ရင် StartSSL က Verification Code တစ်ခုကို Email နဲ့ပေးပို့ပါလိမ့်မယ်။ Email နဲ့ ရရှိထားတဲ့ Verification Code ကို နောက်တစ်ဆင့်မှာ ဖြည့်သွင်းပြီး Continue ထပ်လုပ်လိုက်ပါ။

startssl-email-verify

အဲ့ဒီလို Verify လုပ်လိုက်ရင် StartSSL က Review ပြုလုပ်နေလို့ နာရီတစ်ချို့စောင့်ဖို့ ပြောပါလိမ့်မယ်။ လက်တွေ့မှာ မိနစ်အနည်းငယ်ပဲ ကြာပါတယ်။ နောက်ထပ် Email တစ်စောင်နဲ့ ဆက်သွားရမယ့် Link တစ်ခုကို မကြာခင်မှာ ပေးပို့လာပါလိမ့်မယ်။ အဲ့ဒီ Email ထဲက Link ကို နှိပ်လိုက်ရင် ဝှက်စာ ပြောင်းခြင်းလုပ်ငန်း ဆောင်ရွက်နိုင်တဲ့ စာမျက်နှာတစ်ခုကို ရောက်သွားပါလိမ့်မယ်။

startssl-auth-key-gen

တစ်ခုသတိပြုရမှာက ဒီအဆင့်ဟာ ကျွန်တော်တို့ အသုံးပြုရမယ့် SSL Key အဆင့် မဟုတ်သေးပါဘူး။ StartSSL က ကျွန်တော်တို့ရဲ့ Browser ကို မှတ်တမ်းတင်ရာမှာ သုံးမယ့် Key ဖြစ်ပါတယ်။ Browser မှာ ဒီ Key ရှိနေမှသာ နောက်ပိုင်း StartSSL Control Panel ကို ပြန်ဝင်လို့ရမှာ ဖြစ်ပါတယ်။ အဲ့ဒီ စာမျက်နှာမှာ High Grade ကို ရွေးပြီး Continue ထပ်လုပ်လိုက်ပါ။

startssl-install-auth-key

ဒီအဆင့်ကတော့ ဘာမှရွေးစရာမရှိပါဘူး။ Install နှိပ်လိုက်ယုံပါပဲ။ StartSSL က Browser မှာ Authorization Key တစ်ခု Install လုပ်ပြီး မှတ်တမ်းတင် ထားလိုက်ပါလိမ့်မယ်။

startssl-install-complete

ဒီအဆင့်မှာလည်း ဘာမှရွေးစရာမလိုတော့ပါဘူး။ Browser မှာ Authorization Key ကို Install လုပ်ပြီးဖြစ်ကြောင်း အသိပေးခြင်းဖြစ်ပါတယ်။ ထပ်ပြီး သတိပေးပါရစေ။ နောင်မှာ StartSSL Control Panel ကိုဝင်ဖို့အတွက် ဒီ Key ရှိနေမှသာ ဝင်လို့ရမှာပါ။ အဲ့ဒီ Key ကို Backup လုပ်ပြီး သိမ်းထားသင့်ပါတယ်။ Backup လုပ်ပုံလုပ်နည်းကို F.A.Q Page မှာ ကြည့်လိုရပါတယ်။ ဒီအဆင့်မှာ Finish ကိုနှိပ်လိုက်ရင် Control Panel ကို ရောက်ရှိသွားမှာဖြစ်ပါတယ်။ မရောက်ခဲ့ရင်လည်း Menu ကနေ Control Panel ကို ရွေးခြင်းအားဖြင့် ဝင်ရောက်နိုင်ပါတယ်။

starssl-domain-validate

နောက်တစ်ဆင့်အနေနဲ့ HTTPS တပ်ဆင်မယ့် Website ရဲ့ Domain Name ပိုင်ရှင်ဖြစ်ကြောင်း သက်သေပြဖို့ လိုပါတယ်။ Control Panel ထဲမှာ အထက်ကပုံက ပြထားသလို Validations Wizard ကိုဝင်ပြီး ကျွန်တော်တို့ Website ရဲ့ Domain Name ကို Validate လုပ်နိုင်ပါတယ်။ Type မှာ Domain Name Validation ကိုရွေးပြီး Continue နှိပ်ပေးရပါမယ်။

startssl-domain-choose

နောက်တစ်ဆင့်မှာ ကျွန်တော်တို့ Website ရဲ့ Domain Name ကို ထည့်သွင်းပြီး Continue လုပ်ပေးလိုက်ပါ။ ကျွန်တော်တို့က postmaster, hostmaster, webmaster အစရှိတဲ့ Email Account တွေ (သို့မဟုတ်) Domain Name Register လုပ်စဉ်က အသုံးပြုထားတဲ့ Email Account ကို ပိုင်ဆိုင်သူဆိုရင် Domain Name ရဲ့ ပိုင်ရှင်ဖြစ်ကြောင်း StartSSL က အသိအမှတ်ပြုပေးမှာဖြစ်ပါတယ်။

startssl-domain-email

ကျွန်တော်တို့ကလည်း Domain Name ကို အမှန်တစ်ကယ်ပိုင်ဆိုင်ပြီး ဒီ Email Account တွေထဲက တစ်ခုခုကို Access လုပ်ခွင့်ရှိသူဖြစ်ဖို့တော့ လိုပါတယ်။ အဆင်ပြေတဲ့ Email Address တစ်ခုကိုရွေးပြီး Continue လုပ်လိုက်ပါ။

startssl-domain-email-verify

StartSSL က နောက်ထပ် Verification Code တစ်ခုကို Email နဲ့ပေးပို့ပါလိမ့်မယ်။ ရရှိလာတဲ့ Verification Code ကို နောက်တစ်ဆင့်မှာ ထည့်သွင်းပြီး Continue ထပ်လုပ်ပေးလိုက်ရင် Domain Validation လုပ်ငန်း ပြီးသွားပါပြီ။ Domain Validation Succeed Message ကို နောက်တစ်ဆင့်မှာ လာပြတဲ့အခါ Finish နှိပ်ပေးလိုက်ယုံပါပဲ။

ဆက်လက်ပြီး SSL Certificate တည်ဆောက်ခြင်းလုပ်ငန်းကို ဆက်လက်ဆောင်ရွက်ရမှာဖြစ်လို့ Control Panel ထဲက Certificates Wizard ကို ရွေးပေးပါ။

startssl-start-certificate

Certificate Target အတွက် Web Server SSL/TLS Certificate ကို ရွေးပြီး Continue လုပ်ပေးပါ။

startssl-certificate-pwd

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

startssl-private-key

နောက်တစ်ဆင့်မှာ ရရှိလာတဲ့ Textbox ထဲက Key ကို Copy ကူးယူပြီး ssl.key ဆိုတဲ့ File အမည်နဲ့ သိမ်းပေးရပါမယ်။ ပြီးရင် Continue နှိပ်ပေးပါ။

startssl-choose-domain

ဆက်လက်ပြီး ကျွန်တော်တို့ Validate လုပ်ထားပြီး HTTPS တပ်ဆင်လိုတဲ့ Domain Name ကို ရွေးပေးရပါမယ်။ နောက်တစ်ဆင့်မှာ Sub-Domain Name တစ်ခုထည့်ဖို့ တောင်းပါလိမ့်မယ်။

startssl-subdomain

www (သို့မဟုတ်) အခြားနှစ်သက်ရာ Sub-Domain ထည့်ပြီး Continue လုပ်လိုက်ရင် ကျွန်တော်တို့လိုချင်တဲ့ SSL Certificate တစ်ခုကို ရရှိမှာပဲဖြစ်ပါတယ်။

startssl-cert

နောက်တစ်ဆင့်မှာ ရရှိလာတဲ့ Textbox ထဲက Certificate Key ကို ssl.crt ဆိုတဲ့ File အမည်နဲ့ ကူးယူသိမ်းဆည်း ထားရပါမယ်။ ပုံမှာ လိုင်းတားထားတဲ့ Certificate Authority (CA) နဲ့သက်ဆိုင်တဲ့ အချက်အလက်တွေ ပါဝင်တဲ့ Key File Link နှစ်ခုကို Right Click နှိပ်ပြီး Save As… နဲ့ Download ရယူသိမ်းဆည်း ထားဖို့လည်း လိုပါသေးတယ်။

Setting Up Web Server

အခုဆိုရင် ဝှက်စာပြောင်းရာမှာ လိုအပ်တဲ့ Private Key လည်း ရပါပြီ။ Certificate Key လည်း ရပါပြီ။ CA Key တွေလည်း ရပါပြီ။ StartSSL ဘက်ကနေ ဆောင်ရွက်ရမယ့် ကိစ္စအားလုံး ပြီးစီးသွားပြီ ဖြစ်ပါတယ်။ ဒီအချက်အလက်တွေကို ကျွန်တော်တို့ Website ရဲ့ Web Server မှာ တပ်ဆင် ထည့်သွင်းပေးဖို့ပဲ လိုပါတော့တယ်။ Web Server Setup နဲ့ပက်သက်ပြီး ဆက်လက်ဖော်ပြတဲ့အခါ Ubuntu Server OS နဲ့ Apache Web Server တို့မှာ Setup ပြုလုပ်ပုံကို ဖော်ပြသွားမှာ ဖြစ်ပါတယ်။ အခြား OS သို့မဟုတ် အခြား Web Server တွေအတွက် Setup ပြုလုပ်ပုံကတော့ တူမှာမဟုတ်ပါဘူး။

Key အနေနဲ့ ဝှက်စာဖော်တဲ့ Description Key တစ်ခု လိုပါသေးတယ်။ Terminal ဖွင့်ပြီး အခုလို ထည့်သွင်းခြင်းအားဖြင့် ဖန်တီးနိုင်ပါတယ်။

openssl rsa -in ssl.key -out private.key

openssl Command က Password လာတောင်းတဲ့အခါ SSL Key တည်ဆောက်စဉ်က ပေးခဲ့တဲ့ Password ကို ပြန်ပေးရမှာ ဖြစ်ပါတယ်။ Description Key ကို private.key ဆိုတဲ့အမည်နဲ့ သိမ်းသွားမှာဖြစ်လို့ အခုဆိုရင် စုစုပေါင်း Key File (၅) ခု ရရှိသွားပြီဖြစ်ပါတယ်။

  1. ssl.key
  2. ssl.crt
  3. ca.pem
  4. sub.class1.server.ca.pem
  5. private.key

ဒီ File တွေကို Web Server ထံ Upload ပြုလုပ်ပေးဖို့လိုပါတယ်။

ဆက်လက်ပြီး Apache Web Server အတွက် SSL Module ကို Enable လုပ်ပေးရပါမယ်။ Ubuntu Server မှာ အခုလို Command နဲ့ Enable ပြုလုပ်နိုင်ပါတယ်။

sudo a2enmod ssl
sudo service apache2 restart

ပထမ Command က SSL Module ကို Enable ပြုလုပ်ခြင်းဖြစ်ပြီး ဒုတိယ Command ကတော့ Apache Server ကို Restart ပြုလုပ်လိုက်တာပါ။ SSL Module ကို Enable လုပ်လိုက်တာနဲ့ Apache က SSL Port ဖြစ်တဲ့ Port 443 မှာ စတင် အလုပ်လုပ်သွားမှာ ဖြစ်ပါတယ်။

ပြီးရင်တော့.. Port 443 ကနေဝင်ရောက် လာတဲ့ Request တွေကို ဝှက်စာအဖြစ် ပြောင်းလဲခြင်း၊ ပြန်လည်ဖော်ထုတ်ခြင်း လုပ်ငန်းတွေကို ဆောင်ရွက်စေဖို့ Setting ကို အခုလို သတ်မှတ်ပေးရမှာပါ။

<VirtualHost *:443>
  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

  SSLCertificateFile /path/to/ssl.crt
  SSLCertificateKeyFile /path/to/private.key
  SSLCertificateChainFile /path/to/sub.class1.server.ca.pem
  ServerAdmin webmaster@email.com

  DocumentRoot /path/to/document/root
</VirtualHost>

Setting ရေးသားရမယ့်နေရာကတော့ Web Server တစ်ခုနဲ့တစ်ခု တူမှာမဟုတ်ပါဘူး။ Default Setting အတိုင်းသုံးနေတဲ့ Web Server တစ်ခုမှာဆိုရင်တော့ /etc/apache2/sites-enabled/000-default ဆိုတဲ့ File ထဲမှာ ဖြည့်စွက် ရေးသားပေးရမှာ ဖြစ်ပါတယ်။

Setting နမူနာကို လေ့လာကြည့်ရင်.. ကျွန်တော်တို့ရရှိပြီးဖြစ်တဲ့ Key File (၅) ခုထဲက သုံးခုကို အသုံးပြုထားတာကို တွေ့ရမှာဖြစ်ပါတယ်။ /path/to/ တွေ နေရာမှာ Key File တွေတည်ရှိတဲ့ Location အမှန်နဲ့ အစားထိုး ထည့်သွင်းပေးဖို့ လိုပါလိ့မ်မယ်။ ဒီလို Setting သတ်မှတ်ပြီးရင် Apache Server ကို Restart လုပ်ပေးလိုက်ပါ။

sudo service apache2 restart

အခုဆိုရင် ကျွန်တော်တို့ Website ကို HTTPS တပ်ဆင်ခြင်းလုပ်ငန်းစဉ် ပြီးဆုံးပြီဖြစ်ပါတယ်။ Web Browser URL မှာ https://eimaung.com/ လို့ ထည့်သွင်း စမ်းသပ်နိုင်ပြီ ဖြစ်ပါတယ်။

eimaung.com

ပုံမှာပြထားသလို..  ဒီ Website နဲ့ ဆက်သွယ်နဲ့ ဆက်သွယ်မှုများဟာ လုံခြုံ နေကြောင်း၊ သော့ပုံလေးနဲ့ HTTPS တို့ကို တွဲဖက်ပြီး URL Bar မှာ ဖော်ပြပေးနေတာကို တွေ့ရမှာပဲဖြစ်ပါတယ်။

ကျေးဇူးတင်ပါတယ်…

Reference

Angular JS Intro – Slide Creator App

Single Page Applications (SPA) တွေ တည်ဆောက်ရာမှာ Client-side MVC Framework တွေရဲ့ အရေးပါပုံကို BackboneJS အကြောင်း ပြောတုန်းက ထည့်သွင်းဖော်ပြခဲ့ပါတယ်။ ဒီနေရာမှာတော့ Angular JS  အကြောင်းကို ဖော်ပြပေးချင်ပါတယ်။

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

Client-side MVC Framework တွေထဲမှာ Proven ဖြစ်ပြီး လက်တွေ့ အသုံးများကြတာတွေကတော့ BackboneJS, KnockoutJS, EmberJS နဲ့ AngularJS တို့ဖြစ်ပါတယ်။ ဒီ Framework တွေကို လေ့လာကြည့်တဲ့အခါမှာ၊ လေ့လာရ ဒီလောက်မလွယ်ကူတာကို တွေ့ရပါတယ်။ အားလုံးကို အချိန်တိုအတွင်း ကျွမ်းကျင်ဖို့ဆိုတာ မဖြစ်နိုင်ပါဘူး။ ဒီတော့ ကိုယ့်အတွက် အသင့်တော်ဆုံးဖြစ်နိုင်မယ့် တစ်ချို့ကို ဦးစားပေးပြီး ရွေးချယ်လေ့လာ ရပါတယ်။

Choosing a Framework

Framework တွေ လေ့လာတဲ့အခါ သူတို့ရဲ့ Features နဲ့ Learning Curve တို့ရဲ့ Balance ကို သတိပြုဖို့ လိုပါတယ်။ တစ်ချို့ Framework တွေက လုပ်ဆောင်ချက် ရှုပ်ထွေးစုံလင်တဲ့အတွက် လေ့လာချိန် ပိုလိုနိုင်ပါတယ်။ ဒါပေမယ့် Feature စုံလို့ ကျွမ်းကျင်သွားရင် အခြေခံကိစ္စ အတော်များများကို Framework က လုပ်ပေးသွားတဲ့အတွက် အလုပ်ပိုတွင်စေမှာ ဖြစ်ပါတယ်။ တစ်ချို့  Framework တွေကတော့ Feature အနည်းဆုံးနဲ့ ကျစ်ကျစ်လစ်လစ်ပဲ တည်ဆောက်ထားတက်ပါတယ်။ ဒါကြောင့် လေ့လာရတာ ပိုလွယ်ကောင်းလွယ်နိုင်ပါတယ်။ ဒါပေမယ့် တစ်ချို့ အခြေခံလိုအပ်ချက်တွေကအစ ကိုယ်တိုင် လိုက်ရေးနေရတာမျိုးတော့ ရှိနိုင်ပါတယ်။

Feature စုံတဲ့ Framework ကြီးတွေမှာလည်း အားနက်ချက်တွေတော့ ရှိတက်ပါတယ်။ ဥပမာ – တစ်ချို့ Project တွေမှာ သူ့ရဲ့လုပ်ဆောင်ချက်တွေက လိုတက်ထက် ပိုနေတက်ပါတယ်။ ပြီးတော့ Framework က လုပ်ငန်းအားလုံးကို တာဝန်ယူကူညီဖို့ ကြိုးစားနေတဲ့အတွက် Framework က မလုပ်ပေးနိုင်တဲ့ အထူးလုပ်ဆောင်ချက် လိုလာခဲ့ရင်လည်း Framework ရဲ့ လုပ်ဆောင်ချက်တွေက အဟန့်အတား ဖြစ်လာတက်ပါတယ်။ ကိုယ်လိုချင်တဲ့ လုပ်ဆောင်ချက်ကို မရေးခင်၊ Framework ရဲ့ လုပ်ဆောင်ချက်တွေကို ဖယ်ထုတ်တဲ့ Code တွေ အရင်ရေးရတက်ပြန်ပါတယ်။

Developer တစ်ယောက်နဲ့တစ်ယောက် အကြိုက်မတူနိုင်ပါဘူး။ ကျွန်တော်ကတော့ သေးငယ်ကျစ်လစ်တဲ့ Framework များကိုသာ အမြဲဦးစားပေး ရွေးချယ်ဖြစ်ပါတယ်။ ဒါကြောင့်လည်း Client-side MVC တွေထဲမှာ အကျစ်လစ်ဆုံးဖြစ်တဲ့ BackboneJS ကို ဦးဆုံးလေ့လာဖြစ်ပါတယ်။

Why Angular JS

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

အခုနောက်ပိုင်းမှာ Angular JS က အတော်လေးကို နာမည်ကျော်လာပါတယ်။ “သိပ်ကောင်းတယ်” လို့ ပြောကြပါတယ်။ ဒါနဲ့ပဲ Angular JS ရဲ့ အားသာချက် အားနည်းချက်များနဲ့၊ BackboneJS နဲ့မတူ တစ်မူ ထူးခြားချက်များကို လေ့လာဖြစ်ခဲ့ပါတယ်။

အဲ့ဒီလို လေ့လာတဲ့အခါ တွေ့ရတာကတော့ Angular JS ကို MVC Framework လို့ မခေါ်သင့်ဘူးဆိုတာကို သတိပြုမိပါတယ်။ MVC Pattern ရဲ့ သဘာဝက Data Model နဲ့ View Presentation ကို Decouple လုပ်ဖို့ ဖြစ်ပါတယ်။ Angular JS မှာလည်း Code Coupling ကို လျှော့ချပြီး Maintainable Code တွေ ရေးသားနိုင်အောင် စုစည်းပေးထားပေမယ့် Model View Controller ရယ်လို့ ကဏ္ဍခွဲသုံးရပ်နဲ့ ပီပြီပြင်ပြင် တည်ဆောက်ထားခြင်း မဟုတ်ပါဘူး။ ဒါကြောင့် Angular JS ကိုလေ့လာရင် MVC ဆိုတဲ့ ဘောင်ထဲကနေ မလေ့လာသင့်ပါဘူး။ MVC ဘောင်ထဲက သွားစဉ်းစားရင် ခေါင်းကိုက်သွားပါလိမ့်မယ်။

နောက်ထပ်ထူးခြားချက်ကတော့… Static Content အတွက် ရည်ရွယ်တီထွင်ထားတဲ့ HTML ကို Dynamic App တွေမှာ သုံးနေရတာက အဓိကပြဿနာလို့ Angular JS က ရှုမြင်ပါတယ်။ ဒါကြောင့် Custom Control တွေ ရေးသားဖြည့်စွက်ခြင်းအားဖြင့် HTML ကို App Interface မှာ ထိရောက်အောင် အသုံးချနိုင်ဖို့ စီစဉ်ထား ပေးပါတယ်။

နောက်ထပ်ထူးခြားချက်ကတော့ Two Way Data Binding ဖြစ်ပါတယ်။ Data နဲ့ Interface ကို အမြဲတန်း Full Synchronize ဖြစ်နေစေတဲ့ လုပ်ဆောင်ချက်ပါ။ ဒါတွေက BackboneJS မှာ မပါဝင်တဲ့ နည်းစနစ်တွေပါ။ ပြီးတော့ Logging, Error Handling and Debugging, Testing စတဲ့ လုပ်ဆောင်ချက်တွေပါ တစ်ပါတည်းပါဝင်တဲ့ ဘက်စုံပြည့်စုံတဲ့ Framework ကြီးတစ်ခု ဖြစ်ပါတယ်။

Angular JS ဟာ BackboneJS ထက် အဘက်ဘက်က ပိုမိုပြည့်စုံပါတယ်။ ဒါပေမယ့် Angular JS ကိုယ်တိုင်က သူ့ရဲ့ Intro Guide မှာပြောထားတဲ့ အချက်တစ်ချက်ကို သတိပြုရပါမယ်။

“Like any abstraction, it comes at a cost of flexibility. In other words not every app is a good fit for Angular. Angular was built for the CRUD application in mind. But to understand what Angular is good at one also has to understand when an app is not a good fit for Angular.”

Angular JS ဟာ CRUD App တွေအတွက် ရည်ရွယ်တည်ဆောက်ထားတာဖြစ်လို့ တစ်ချို့ App တွေနဲ့တော့ အံဝင်ချင်မှဝင်ပါမယ်။ ဥပမာ – ကျွန်တော် jQuery နဲ့ တည်ဆောက်ထားတဲ့ ShowKeyMan ဆိုတဲ့ JavaScript Card Game ကို Angular JS နဲ့ တည်ဆောက်ရင် ဘယ်လိုမှ အဆင်ပြေနိုင်မှာ မဟုတ်ပါဘူး။ ဒါပေမယ့် BackboneJS နဲ့ဆိုရင်တော့ အဆင်ပြေနိုင်ပါတယ်။ BackboneJS နဲ့ဆိုရင် အခု jQuery သက်သက်နဲ့ ရေးထားတာထက် အများကြီးပိုပြီး Maintainable ဖြစ်သွားမှာပါ။ ဒါပေမယ့်လည်း App တွေရဲ့ 90% လောက်က CRUD App တွေဖြစ်မှာမို့ App အများစုကတော့ Angular JS နဲ့ သင့်တော်မှာပါ။

Presentation Creator with Angular JS

Angular JS ကိုအသုံးပြုပြီး Presentation Creator App တစ်ခုတည်ဆောက်ပုံကို ဖော်ပြပေးချင်ပါတယ်။ ပထမဆုံးအဆင့်ဖြစ်တဲ့ HTML Structure ကို လေ့လာကြည့်ပါ။

ပေးထားတဲ့ HTML ကိုလေ့လာကြည့်ရင် ဦးဆုံးသတိထားမိမှာက.. ng-app, ng-controller, ng-repeat စတဲ့ Attributes တွေဖြစ်ပါတယ်။ ဒါ HTML Attribute တွေမဟုတ်ပါဘူး။ Angular JS က ဖြည့်စွက်တည်ဆောက်ထားတဲ့ Directive များဖြစ်ပါတယ်။ ကျွန်တော်တို့ကိုယ်တိုင်လည်း Custom HTML Element တွေ Attribute တွေကို Directive အနေနဲ့ တည်ဆောက်နိုင်ပါတယ်။

Angular JS App တစ်ခုအဖြစ် အလုပ်လုပ်စေဖို့ ng-app Directive မဖြစ်မနေသတ်မှတ်ပေးဖို့လိုပါတယ်။ နမူနာမှာလို ng-app=”ngSlides” ဆိုပြီး အမည်တစ်ခု သတ်မှတ်ပေးနိုင်သလို ng-app ဆိုပြီး နောက်ကအမည် မထည့်ပဲလည်း အသုံးပြုနိုင်ပါတယ်။

ng-controller ကတော့ သက်ဆိုင်ရာအစိတ်အပိုင်းအတွက် Data များပြင်ဆင်ခြင်း၊ Event များသတ်မှတ်ခြင်း တို့ကို နောက်ကွယ်ကနေ တာဝန်ယူဆောင်ရွက်မယ့် Handler သတ်မှတ်ဖို့ အသုံးပြုပါတယ်။ ng-controller=”SlideController” လို့ သတ်မှတ်ထားတဲ့အတွက် SlideController Function အတွင်းမှာ ရေးသားထားတဲ့ သတ်မှတ်ချက်တွေကို အဲ့ဒီ <div> Element အတွင်းမှာ ရယူအသုံးပြုနိုင်စေမှာ ဖြစ်ပါတယ်။

ng-repeat ကတော့ For-Each Loop နဲ့တူပါတယ်။ ပေးထားတဲ့ Array တစ်ခုကို အသုံးပြုပြီး အလိုအလျှောက် Repeat လုပ်ပေးသွားမှာပါ။ ng-repeat=”slide in slides” လို့သတ်မှတ်ထားတဲ့အတွက် slides Array ကို Loop လုပ်ပြီး လက်ရှိ Element ကို Repeat လုပ်ပေးသွားမှာပါ။ ဥပမာ – slides Array မှာ Index (၃) ခုရှိရင် လက်ရှိ Element ကို သုံးခါဖော်ပြပေးသွားမှာပါ။ slides Array ထဲမှာ ရှိရမယ့် တန်ဖိုးတွေကိုတော့ Controller ဖြစ်တဲ့ SlideController က သတ်မှတ်ပေးမှာ ဖြစ်ပါတယ်။

ဆက်လက်သတိပြုရမှာကတော့ တွန့်ကွင်းနှစ်ထပ် {{  }} နဲ့ ထည့်သွင်း ရေးသားထားတဲ့ Code တွေ ဖြစ်ပါတယ်။ အခြေခံအားဖြင့် JavaScript Code တွေကို အဲ့ဒီလို တွန့်ကွင်းနှစ်ထပ်နဲ့ HTML အတွင်းမှာ ထည့်သွင်းရေးသားနိုင်တယ်လို့ ဆိုနိုင်ပါတယ်။

Repeater အတွင်းမှာ slides Array ကနေရရှိလာတဲ့ slide Object ရဲ့ state, title နဲ့ body ကို တွန့်ကွင်းနှစ်ထပ်နဲ့ သက်ဆိုင်ရာနေရာတွေမှာ ဖော်ပြစေပါတယ်။ $index Variable ကတော့ Loop Counter ဖြစ်ပါတယ်။

ဆက်လက်သတိပြုရမှာကတော့ <next> Element နဲ့ <previous> Element တို့ဖြစ်ပါတယ်။ အဲ့ဒီ Element တွေက ကျွန်တော်တို့ ကိုယ်တိုင် Angular Directive အနေနဲ့ တည်ဆောက်ထားတဲ့ Custom HTML Element တွေဖြစ်ပါတယ်။

ဆက်လက်ရေးသားထားတဲ့ Form မှာ ng-submit Directive ပါဝင်ပါတယ်။ HTML onSubmit Attribute နဲ့ အခြေခံအားဖြင့် အတူတူပါပဲ။ ng-submit=”addSlide()”  လို့ သတ်မှတ်ထားလို့ Form ကို Submit လုပ်လိုက်ရင် addSlide() Function ကို အလုပ်လုပ်ပေးသွားမှာပါ။

နောက်ဆုံးသတိပြုရမှာကတော့ <input> နဲ့ <textarea> မှာ ထည့်သွင်းထားတဲ့ ng-model Directive ဖြစ်ပါတယ်။ ng-model ကို လွယ်အောင် ဒီလိုမှတ်နိုင်ပါတယ်။ ng-model=”slideTitle” လို့ သတ်မှတ်လိုက်ခြင်းဟာ slideTitle အမည်နဲ့ Variable တစ်ခု သတ်မှတ်လိုက်ပြီး အဲ့ဒီ Variable ကို လက်ရှိ Element နဲ့ Sync လုပ်ပေးလိုက်ခြင်း ဖြစ်ပါတယ်။ တစ်နည်းအားဖြင့် လက်ရှိ <input> Element ရဲ့ တန်ဖိုးပြောင်းတိုင်း slideTitle Variable ရဲ့ တန်ဖိုးလည်း အလိုလို လိုက်ပြောင်းပါလိမ့်မယ်။ အလားတူပဲ slideTitle Variable ရဲ့တန်ဖိုးကို ပြောင်းလိုက်ရင်လည်း <input> Element ရဲ့ တန်ဖိုး လိုက်ပြောင်းသွားမှာ ဖြစ်ပါတယ်။ အပြန်အလှန်ချိတ်ဆက်ထားတဲ့ Two Way Data Binding ဖြစ်ပါတယ်။

ဆက်လက်ပြီး လိုအပ်တဲ့ JavaScript တွေကို လေ့လာကြည့်ပါမယ်။

ပထမဦးဆုံးအနေနဲ့ var app = angular.module(‘ngSlides’, []); လို့ရေးသားပြီး Angular JS Module Object တစ်ခု တည်ဆောက်ပါတယ်။ ngSlides ဆိုတာ HTML မှာ ng-app နဲ့တွဲပြီး ကျွန်တော်တို့ပေးခဲ့တဲ့အမည် ဖြစ်ပါတယ်။ နောက်က Array အလွတ်ရဲ့ အဓိပ္ပါယ်ကတော့ ဒီ App Module ဟာ တစ်ခြား မှီခိုထားတဲ့ Module မရှိဘူးဆိုတဲ့အဓိပ္ပါယ်ပါ။ ရှိရင် တန်းစီပြီးထည့်ပေးနိုင်ပါတယ်။

ဆက်လက်ပြီး ကျွန်တော်တို့ အသုံးပြုလိုတဲ့ Controller ကို HTML မှာ သတ်မှတ်ခဲ့တဲ့အတိုင်း SlideController အမည်နဲ့ controller() Method အသုံးပြုပြီး တည်ဆောက်ပါတယ်။ ထူးခြားချက်ကတော့ $scope Variable ဖြစ်ပါတယ်။ Controller က $scope Variable ထဲကို လိုအပ်တဲ့ တန်ဖိုးတွေနဲ့ Function တွေ ထည့်သွင်းတဲ့အလုပ်ကို အဓိကလုပ်မှာ ဖြစ်ပါတယ်။ $scope Variable ထဲမှာ ရှိနေတဲ့တန်ဖိုးတွေကို ဒီ Controller က တာဝန်ယူစီမံနေတဲ့ HTML Element အတွင်းမှာ လိုသလို အသုံးချနိုင်မှာပါ။

ပထမဆုံးဆုံး $scope.slides = [] ဆိုပြီး slides Variable ထဲကို Array အလွတ်တစ်ခု ထည့်သွင်းပေးပါတယ်။ HTML ဘက်မှာ ng-repeat ကိုသုံးပြီး slides Array ကို Loop လုပ်ခဲ့တာကို မှတ်မိဦးမှာပါ။

ဆက်လက်ပြီး addSlide() Function သတ်မှတ်ပါတယ်။ HTML ထဲမှာ ng-submit=”addSlide()” လို့ သတ်မှတ်ခဲ့လို့ Form Submit လုပ်တာနဲ့ ဒီ Function အလုပ်လုပ်သွားမှာပါ။ Code တစ်ကြောင်းချင်းကိုတော့ အသေးစိတ်မပြောတော့ပါဘူး၊ ကိုယ်တိုင်လေ့လာကြည့်ပါ။ Angular JS နဲ့ ပက်သက်တဲ့ အပိုင်းတွေကိုသာ အဓိကပြောချင်ပါတယ်။ Sync လုပ်ထားတဲ့အတွက် $scope.slideTitle ဆိုတဲ့ Variable ထဲမှာ၊ HTML ဘက်က ng-model=”slideTitle” လို့ သတ်မှတ်ထားတဲ့ <input> Element မှာ ထည့်သွင်းထားတဲ့တန်ဖိုး အလိုလို ရှိနေမယ်ဆိုတာကို သတိပြုပါ။ ပြီးတော့… $scope.slideTitle = ” ဆိုတဲ့ လိုင်းကိုလည်း သတိပြုပါ။ ဒီလို Variable ကို Clear လုပ်လိုက်တာနဲ့ <input> Element ရဲ့ တန်ဖိုးလည်း Clear လိုက်ဖြစ်သွားမှာပါ။

သက်ဆိုင်ရာ Function Name တွေမှာတင် လုပ်ဆောင်ချက်အဓိပ္ပါယ် ပါဝင်ပါတယ်။ removeSlide(), hideAll(), next(), previous(), စသဖြင့် Function တွေ သတ်မှတ်ထားပါတယ်။ အထူးသတိပြုရမှာက အောက်ဆုံးက Directive Block နှစ်ခုဖြစ်ပါတယ်။ <next> နဲ့ <previous> ဆိုတဲ့ Element နှစ်ခုကို ကြေငြာသတ်မှတ်ထားခြင်း ဖြစ်ပါတယ်။ ဒီမှာ ကြေငြာသတ်မှတ်ထားလို့ HTML ထဲမှာ <next> နဲ့ <previous> Element များကို ရယူအသုံးပြုနိုင်ခြင်း ဖြစ်ပါတယ်။

Directive Function က Object တစ်ခုကို Return ပြန်ပေးခြင်းဖြစ်ပါတယ်။ restrict: ‘E’ ဆိုတဲ့အဓိပ္ပါယ်က လက်ရှိသတ်မှတ်ထားတဲ့ “next” ဟာ Element တစ်ခုဖြစ်ပါတယ်လို့ ကြေငြာတာပါ။ Attribute Directive တစ်ခုသတ်မှတ်လိုတာဆိုရင် restrict: ‘A’ လို့ ပြောပေးရပါတယ်။ ‘C’ ‘M’ စတဲ့ အခြားအမျိုးအစားတွေ ရှိပါသေးတယ်။

ဒီ Directive နေရာမှာ ဖော်ပြစေလိုတဲ့ HTML Template အပြည့်အစုံကိုတော့ template Property နဲ့ သတ်မှတ်ပေးနိုင်ပါတယ်။ link Property ကိုတော့ ဒီ Directive ရဲ့ Behavior တွေသတ်မှတ်ဖို့ အသုံးပြုနိုင်ပါတယ်။ နမူနာမှာတော့ ဒီ Directive ကို click လုပ်လိုက်ရင် Controller ထဲမှာ ကြိုတင်သတ်မှတ်ထားတဲ့ next() နဲ့ previous() Function တို့ကို ခေါ်ယူအလုပ်လုပ်ဖို့ သတ်မှတ်ထားပါတယ်။

ဒါပါပဲ… ဒီလောက်လေးရေးလိုက်ယုံနဲ့ Presentation Slide များ တည်ဆောက်ခြင်း ပယ်ဖျက်ခြင်း၊ Navigate လုပ်ခြင်းတို့ကို ဆောင်ရွက်နိုင်တဲ့ Single Page Application တစ်ခုကို ရရှိမှာဖြစ်ပါတယ်။

ngslide

Source Code အပြည့်အစုံကို Github မှာ တင်ထားပေးပါတယ်။ Download ရယူပြီး စမ်းသပ်လေ့လာနိုင်ပါတယ်။

Conclusion

ဒီနမူနာမှာ Model ရဲ့ အခန်းကဏ္ဍ သိပ်မပါဝင်တာကို တွေ့ရပါလိမ့်မယ်။ လက်တွေ့မှာ Data နဲ့ပက်သက်တဲ့ ကိစ္စရပ်များအတွက် Provider တွေကို Service အနေနဲ့သော်လည်ကောင်း၊ Factory အနေနဲ့သော်လည်ကောင်း သီးခြားသတ်မှတ်နိုင်ပါတယ်။ ပြီးတော့ URL Routing, Logging, Animation နဲ့ အခြားခြားသော Angular JS ရဲ့ လုပ်ဆောင်ချက်ပေါင်းများစွာတော့ ဒီနမူနာမှာ အသုံးပြုမထားပါဘူး။ အများကြီး ကျန်သေးတဲ့အတွက် အသေးစိတ်ကို အချိန်ပေးလေ့လာသင့်ကြောင်း တိုက်တွန်းလိုပါတယ်။

လက်ရှိအချိန်ထိ ကျွန်တော်အတွက် အဓိကအချက်အခဲကတော့ Directive များ တည်ဆောက်ဖို့ ဆုံးဖြတ်ရခြင်းဖြစ်ပါတယ်။ နမူနာမှာဆိုရင် addSlide() removeSlide() စတဲ့ လုပ်ဆောင်ချက်များကို HTML နဲ့ ဒီအတိုင်းရေးထားပြီး next() နဲ့ previous() ကိုတော့ Directive အနေနဲ့ တည်ဆောက်အသုံးပြု ထားပါတယ်။ ဘယ်လိုရေးရေး အလုပ်လုပ်နေတဲ့အတွက် ဘယ်အချိန်မှာ Directive တွေတည်ဆောက်သင့်ပြီး ဘယ်အချိန်မှာ HTML အတိုင်းပဲ အသုံးပြုသင့်သလဲ ဆိုတာ ဆုံးဖြတ်ရတာ ခေါင်းစားပါတယ်။ ဒီအချက်ကို ပြတ်ပြတ်သားသား ဆုံးဖြတ်နိုင်ဖို့ အများအသုံးပြုလေ့ရှိတဲ့ Best Practice တွေကို ဆက်လက်လေ့လာ လိုက်ပါဦးမယ်။

ကျေးဇူးတင်ပါတယ်…

Going to SPA with BackboneJS

Gmail တို့ Facebook တို့လို Application တွေကိုအသုံးပြုတဲ့အခါ သတိထားကြည့်ပါ။ သူတို့မှာရှိတဲ့ လုပ်ဆောင်ချက်တွေကို စာမျက်နှာ တစ်မျက်နှာတည်းနဲ့ အသုံးပြုနိုင်အောင် စီမံထားကြပါတယ်။ ဥပမာ – Gmail မှာ Login ဝင်ဝင်ခြင်းတွေ့မြင်ရ မှာက Inbox ပါ။ Email တစ်စောင်ကို ဖတ်ဖို့ဖွင့်လိုက်ရင် နေရာမှာတင်ပဲ ဖွင့်ပေးပါတယ်။ နောက်စာမျက်နှာ တစ်ခုကို သွားစရာမလိုပါဘူး။ အလားတူပဲ Email ပို့ချင်လို့ Compose Mail ကို နှိပ်လိုက်ရင်လည်း Email ရေးသားနိုင်တဲ့ Interface က လက်ရှိစာမျက်နှာမှာပဲ ပေါ်လာမှာပါ။ တစ်ယောက်ယောက်က Chat Message ပို့လိုက်လို့ လက်ခံရရှိရင်လည်း ဒီစာမျက်နှာပေါ်မှာပဲ လက်ခံရရှိကြောင်း လာပြပေးမှာပါ။ အဲ့ဒီလို စာမျက်မှာတစ်ခုတည်းနဲ့ လုပ်ဆောင်ချက်အားလုံးကို ဆောင်ရွက်ပေးနိုင်အောင် တည်ဆောက်ထားတဲ့ Web Application တွေကို Single Page Application (SPA) လို့ ခေါ်ပါတယ်။

SPA တွေဟာ JavaScript ကို အဓိက Programming Language အနေနဲ့ အသုံးပြု ရေးသားထားတဲ့ App တွေပါ။ အရင်က JavaScript ဆိုတာ Web App တစ်ခုတည်ဆောက်ရာမှာ အထောက်အပံ့ပေးတဲ့ အဖြည့် Language တစ်ခုမျှသာပါ။ အခုနောက်ပိုင်းမှာတော့ သူကအဓိက ဖြစ်လာပါပြီ။ Server-side Language တွေကတောင် JavaScript ကို အားဖြည့်ပေးရတဲ့ အဖြည့်နည်းပညာတွေ ဖြစ်လာပါတယ်။ အခုလို Application တစ်ခုလုံးရဲ့ အဓိက Language အဖြစ် သုံးရတော့မယ်ဆိုတော့ ရေးသားရမယ့် Code တွေကလည်း တော်တော်များ လာမှာပါ။ Code တွေများလာတဲ့အခါ အဲ့ဒီ Code တွေကို ပြင်ဆင်ရလွယ်အောင်၊ ဖြည့်စွက်ရလွယ်အောင် စနစ်တစ်ကျ စုစည်းရခြင်းက စိန်ခေါ်မှုတစ်ရပ် ဖြစ်လာပါတယ်။ ဒါကြောင့်လည်း အခုနောက်ပိုင်းမှာ ရေးသားထားတဲ့ Code တွေကို လုပ်ဆောင်ချက်ကဏ္ဍအလိုက် သီးခြားစီ စနစ်တကျခွဲခြား စုစည်းပေးနိုင်တဲ့ Client-side MVC လို့ခေါ်တဲ့ JavaScript Framework တွေ ခေတ်စားလာခဲ့ပါတယ်။

MVC ရဲ့ မူရင်းအဓိပ္ပါယ်က Model-View-Controller ဖြစ်ပါတယ်။ Client-side MVC Framework တွေမှာတော့ MVC ရဲ့ အဓိပ္ပါယ်က Model-View-Controller မဟုတ်တော့ပါဘူး။ Model-View-Collection လို့ သုံးကြလေ့ ရှိပါတယ်။ တစ်ချို့ Framework တွေကိုတော့ MVC လို့မသုံးပဲ MVVM Framework လို့ ခေါ်ကြပါတယ်။ Model-View-ViewModel ဆိုတဲ့အဓိပ္ပါယ်ဖြစ်ပါတယ်။ တစ်ချို့ကိုတော့ MVP Framework လို့ ခေါ်ကြပြန်ပါတယ်။ MVP ကတော့ Model-View-Presenter ဆိုတဲ့ အဓိပ္ပါယ်ပါ။ အခေါ်ကွဲပေမယ့် ရည်ရွယ်ချက်ကတော့ Single Page Application တွေ တည်ဆောက်ရာမှာ လိုအပ်တဲ့ အခြေခံအထောက်အပံ့တွေ ပေးနိုင်ဖို့နဲ့ Code တွေကို စနစ်တစ်ကျ စုစည်းပေးနိုင်ဖို့ ဖြစ်ပါတယ်။ လက်ရှိလူသုံးများနေတဲ့ Client-side MVC Framework တွေထဲက BackboneJS အကြောင်း ဖော်ပြချင်ပါတယ်။

BackboneJS MVC

MVC pattern ရဲ့ အဓိကရည်ရွယ်ချက်ကတော့ Data နဲ့ Presentation ကို ခွဲခြားရေးသား လိုခြင်းဖြစ်ပါတယ်။ ဒီတော့မှာ Data က Presentation ကို မှီခိုစရာမလိုပဲ သီးခြားအလုပ်လုပ်နိုင်မှာ ဖြစ်သလို Presentation ကလည်း Data ကို မှီခိုစရာမလိုပဲ သီးခြားအလုပ်လုပ်နိုင်မှာ ဖြစ်ပါတယ်။ BackboneJS ကလည်း Data Model နဲ့ Presentation Rendering ကို ခွဲခြားရေးသားနိုင်အောင် စီစဉ်ထားပေးပါတယ်။ ထူးခြားချက်ကတော့ Controller ဖြစ်ပါတယ်။ BackboneJS MVC မှာပါဝင်တဲ့ C ဟာ Collection ကို ရည်ညွှန်းခြင်းဖြစ်ပါတယ်။ Controller ကိုရည်ညွှန်းတာ မဟုတ်ပါဘူး။ MVC Pattern မှာ Controller ဆိုတာ Input/Output များ စီမံခြင်းတာဝန်ကိုယူပြီး Model နဲ့ View က ကြားကနေ ချိတ်ဆက်ပေးတဲ့ ကဏ္ဍဖြစ်ပါတယ်။ ဒါပေမယ့် BackboneJS မှာတော့ Controller သီးခြားပါဝင်ခြင်းမရှိပါဘူး။ JavaScript App တစ်ခုရဲ့ Input/Output လုပ်ဆောင်ချက်လို့ ဆိုရမယ့် Event များစီမံခြင်းကိစ္စကို View Template နဲ့သာ တွဲဖက်ရေးသားရပါတယ်။

နောက်ထပ်ထူးခြားချက်ကတော့၊ Server-side နည်းပညာတွေရဲ့ MVC မှာ View ဟာ Client-side ဖြစ်တဲ့ Browser အတွင်းမှာဖော်ပြပြီး၊ Model Data ကတော့ Server-side ဖြစ်တဲ့ Web Server မှာဖြစ်ပါတယ်။ ဒါကြောင့် View နဲ့ Model ဟာ သီးခြားအလုပ်တာမှ၊ လုံးဝကိုသီးခြားစီ အလုပ်လုပ်တဲ့သဘော ဖြစ်ပါတယ်။ Data Model မှာ ဖြစ်ပေါ်နေတဲ့ အပြောင်းအလဲများကို သိရဖို့ View က Controller ရဲ့အကူအညီနဲ့ Model ဆီကနေ တစ်ကူးတစ်က တောင်းခံရယူရပါတယ်။ Client-side MVC မှာတော့ Data Persistence လို့ခေါ်တဲ့ အချက်အလက်များ အမြဲသိမ်းဆည်းခြင်းကို Server-side မှာ ပြုလုပ်ပေမယ့်၊ တစ်ကယ့် Live Data Model ကတော့ Client-side မှာပဲရှိနေတာဖြစ်ပါတယ်။ Data Model မှာ အပြောင်းအလဲရှိတာနဲ့ Data Model က View ကို တိုက်ရိုက် အသိပေးလိုက်နိုင်လို့ View နဲ့ Model ဆက်ဆံရေး ပိုပြီးထိရောက် လာတဲ့သဘော ဖြစ်ပါတယ်။

ဒါတွေက BackboneJS နဲ့ Client-side MVC များရဲ့ ထူးခြားချက်များဖြစ်ပါတယ်။

Building a Todo List with BackboneJS

BackboneJS ကိုအသုံးပြုပြီး Todo List App တစ်ခုတည်ဆောက်ပုံကို ဆက်လက်ဖော်ပြပါမယ်။ အမှန်တော့ Todo List လို့ App လေးလောက်အတွက် MVC တွေဘာတွေ မလိုပါဘူး။ ဒီအတိုင်း လက်တမ်းချရေးလိုက်လဲ ရတာပါပဲ။ jQuery နဲ့ ရေးသားပုံကိုလည်း ရှေ့ပိုင်းမှာဖော်ပြခဲ့ပြီး ဖြစ်ပါတယ်။ Code လည်း ဘယ်လောက်မှ မများပါဘူး။ ဒါပေမယ့် App ကြီးရင်ကြီးလာသလို နောက်ပိုင်းမှာ Maintain လုပ်ရခက်တဲ့ ပြဿနာတွေ ရှိလာတော့မှာ ဖြစ်ပါတယ်။ အခုဖော်ပြတဲ့အခါမှာ App ရဲ့ Feature တွေထက် BackboneJS ရဲ့သဘောသဘာဝကိုသာ အဓိကထား ဖော်ပြသွားမှာပါ။

HTML Template

ပထမဦးဆုံးအနေနဲ့ ကျွန်တော်တို့ App အတွက် လိုအပ်တဲ့ အခြေခံ Template ကို HTML နဲ့ အခုလို တည်ဆောက်ပါတယ်။

အဲ့ဒီထဲက #app လို့သတ်မှတ်ထားတဲ့ Section က App ရဲ့ အဓိက Interface ဖြစ်ပါတယ်။

<section id="app">
    <header>
        <h1>Tasks</h1>
        <input id="new" placeholder="Your task">
    </header>

    <section id="main">
        <ul id="list"></ul>
    </section>
</section>

အထဲမှာ Header နဲ့ #main Section ဆိုပြီး နှစ်ပိုင်းထပ်ခွဲထား ပါတယ်။ Header ထဲမှာ ခေါင်းစဉ်နဲ့ လုပ်ငန်းသစ်တွေ ထည့်နိုင်တဲ့ Text Input တစ်ခုပါဝင်ပါတယ်။ #main Section ထဲမှာတော့ လုပ်ငန်းတွေကို စာရင်းနဲ့ဖော်ပြနိုင်ဖို့ <ul> Element တစ်ခု ထည့်သွင်းထားပါတယ်။ သူ့အောက်မှာ <script> Element နဲ့ ရေးထားတဲ့ Template ကတော့ ဖော်ပြဖို့မဟုတ်ပါဘူး။ JavaScript ကနေ ခေါ်သုံးဖို့ ကြိုတင်ရေးသားထားတာပါ။

<script type="text/template" id="item-template">
    <div class="view">
        <input type="checkbox" class='toggle' <%= done ? 'checked' : '' %>>
        <label><%- title %></label>
        <button class='destory'>×</button>
    </div>
</script>

type မှာ text/template လို့သတ်မှတ်ထားတာကို သတိပြုပါ။ အမှန်ဆိုရင် text/javascript ဖြစ်ရမှာပါ။ ဒါမှမဟုတ်ရင်လည်း type Attribute လုံးဝမထည့်ပဲ ထားရမှာပါ။ အခုတော့ text/template လို့သတ်မှတ်ထားတဲ့ Browser က နားမလည်တဲ့အတွက် HTML အနေနဲ့လည်း ဖော်ပြသွားမှာ မဟုတ်သလို JavaScript အနေနဲ့လည်း အလုပ်လုပ်ပေးသွားမှာ မဟုတ်ပါဘူး။ ဒီအတိုင်းကျော်သွားမှာပါ။ ကျွန်တော်တို့က အသုံးလိုမှ ရယူအသုံးပြုမှာ ဖြစ်ပါတယ်။ ဒါကြောင့် id ကိုတော့ item-template လို့ သတ်မှတ်ထားခဲ့ပါတယ်။

ဒီ Template ကို သီးခြား JavaScript Library တစ်ခုဖြစ်တဲ့ UnderscoreJS မှာပါဝင်တဲ့ Template Engine နဲ့ ရယူအသုံးချဖို့ ရည်ရွယ်ထားတာပါ။ ဒီနေရာမှာ JavaScript Template Engine အကြောင်းတော့ အကျယ်မချဲ့နိုင်ပါဘူး။ ကျွန်တော်တစ်ခါ ဖော်ပြဘူးတဲ့ Video တစ်ခုမှာ သူ့ရဲ့အခြေခံသဘောကို လေ့လာနို်ငပါတယ်။

ထူးခြားချက်အနေနဲ့ Template ထဲက Checkbox Input အတွက် done ဆိုတဲ့ တန်ဖိုးပေါ်မူတည်ပြီး checked Attribute ထည့်မထည့် စီစစ်ထားပါတယ်။ ပြီးတော့ <label> Element ထဲမှာလည်း title ဆိုတဲ့ တန်ဖိုးကို ရိုက်ထုတ်ခိုင်းထားပါတယ်။ ဒါကြောင့် done နဲ့ title ဆိုတဲ့ တန်ဖိုးနှစ်ခုကိုပေးပြီး ဖော်ပြခိုင်းရင် UnderscoreJS က တန်ဖိုးတွေကို သူ့နေရာနဲ့သူ သင့်တော်သလို အစားထိုး အသုံးပြုပြီး ဖော်ပြပေးသွားမှာပါ။

ဆက်လက်ပြီး JavaScript File လေးခုကို ချိတ်ဆက်ထားပါတယ်။ jQuery နဲ့ UnderscoreJS တို့ကိုလည်း ထည့်သွင်းအသုံးပြုမှာမို့ ချိတ်ဆက်ထည့်သွင်း ထားပါတယ်။ BackboneJS ကတော့ အဓိကဖြစ်လို့ သူ့ကိုလည်း ထည့်သွင်းထားပါတယ်။ app.js ထဲမှာတော့ ကျွန်တော်တို့ရဲ့ Todo List App Code တွေကို ရေးသားမှာဖြစ်ပါတယ်။

The MVC Code

app.js ထဲမှာ ရေးသားရမယ့် Code အပြည့်အစုံကို ဖော်ပြပေးလိုက်ပါတယ်။

ပထမဆုံးတစ်ကြောင်းဖြစ်တဲ့ var app = {}; ကတော့ app လို့ခေါ်တဲ့ JSON Object အလွတ်တစ်ခု တည်ဆောက်လိုက်ခြင်းဖြစ်ပါတယ်။ ကျန်လုပ်ဆောင်ချက်အားလုံးကို app ထဲမှာ ထည့်သွင်းသွားမှာဖြစ်လို့ သူ့ကို ကျွန်တော်တို့ Application ရဲ့ Namespace လို့လည်း ဆိုနိုင်ပါတယ်။ ဆက်လက်ပြီး Task တစ်ခုချင်းအတွက် Data Model ကိုသတ်မှတ်ပါတယ်။

// Model
app.Todo = Backbone.Model.extend({
    defaults: {
        title: '',
        done: false
    },
    
    toggle: function() {
        this.save({
            done: !this.get('done')
        });
    }
});

Model တစ်ခုသတ်မှတ်ဖို့အတွက် Backbone.Model.extend ကို အသုံးပြုသတ်မှတ်ရပါတယ်။ ရိုးရိုး MVC တွေမှာ Model ဆိုတာ သက်ဆိုင်ရာကဏ္ဍရဲ့ Data နဲ့ပက်သက်တဲ့ လုပ်ဆောင်ချက်ပေါင်းများစွာ ပါဝင်တဲ့ အစိတ်အပိုင်း တစ်ခုလုံးကို ဆိုလိုတာပါ။ Backbone MVC ရဲ့ Model ကတော့ Data အမျိုးအစားတစ်ခုမှာ ပါဝင်ရမယ့် Attribute များကို စုစည်းထားတဲ့ Object တစ်ခုမျှသာဖြစ်ပါတယ်။ အခုသတ်မှတ်ထားတဲ့ Todo ဆိုတဲ့ Data အမျိုးအစားမှာ တန်ဖိုးအနေနဲ့ title နဲ့ done ဆိုတဲ့နှစ်ခု ပါဝင်မှာဖြစ်ပြီး ဖြည့်စွက်လုပ်ဆောင်ချက် အနေနဲ့ toggle() Function ပါဝင်မှာဖြစ်ပါတယ်။

အမှန်တော့ အခုတည်ဆောက်ထားတဲ့ Model Object ရရှိဖို့ JSON နဲ့လည်း ကိုယ်တိုင်တည်ဆောက်နိုင်ပါတယ်။ Backbone.Model နဲ့တည်ဆောက်တဲ့အတွက် အခြားလုပ်ဆောင်ချက်တွေ ဖြည့်စွက်ရရှိသွားပါတယ်။ ဒီနေရာမှာတော့ Feature အားလုံးကိုမဖော်ပြနိုင်ပါဘူး။ နမူနာမှာတော့ defaults ကို အသုံးပြုထားပါတယ်။ ဒါကြောင့် နောက်ပိုင်းမှာ app.Todo Model ကို အသုံးပြုပြီး Backbone Model Object တည်ဆောက်တိုင်းမှာ Default အဖြစ်သတ်မှတ်ထားတဲ့ title:” နဲ့ done: false က အသင့်ပါဝင်သွားစေမှာ ဖြစ်ပါတယ်။

toggle() Function ကတော့ တစ်ကြိမ်အလုပ်လုပ်ရင် done ကို true ပြောင်းပေးပြီး နောက်တစ်ကြိမ် အလုပ်လုပ်ရင် false ပြန်ပြောင်းတဲ့ လုပ်ဆောင်ချက်ကို လုပ်ပေးမှာဖြစ်ပါတယ်။ this.get(‘done’) က လက်ရှိ Backbone Object ရဲ့ done တန်ဖိုးကို ရရယူပေးပါတယ်။ အဲ့ဒါကို ရှေ့က ! သင်္ကေတနဲ့ အငြင်းလုပ်ထားတော့ တစ်ကြိမ်အလုပ်လုပ်တိုင်း ဆန့်ကျင်ဘက်တန်ဖိုး ပြောင်းပေးသွားတဲ့သဘော ဖြစ်ပါတယ်။ အခုဆိုရင် app.Todo ဆိုတဲ့ Backbone Model Object တစ်ခု ကျွန်တော်တို့ ရရှိသွားပါပြီ။

ဆက်လက်ပြီး Collection တစ်ခု တည်ဆောက်ပါတယ်။

// Collection
var TodoList = Backbone.Collection.extend({
    model: app.Todo,
    
    url: '/',

    nextOrder: function() {
        if ( !this.length ) {
            return 1;
        }
        return this.last().get('order') + 1;
    }
});

app.Todos = new TodoList();

Collection ဆိုတာ Model အစုအဝေးဖြစ်ပါတယ်။ Database System တွေရဲ့ Table နဲ့တူတယ်လို့ ဆိုနိုင်ပါတယ်။ အခုလည်း ရရှိထားပြီးဖြစ်တဲ့ app.Todo Model Object တွေကို စုစည်းသိမ်းဆည်းဖို့ TodoList ဆိုတဲ့ Model Collection တစ်ခုကို Backbone.Collection.extend နဲ့ တည်ဆောက်ထားပါတယ်။ စုစည်းသိမ်းဆည်းမယ့် Model အမျိုးအစားအဖြစ် app.Todo ကို သတ်မှတ်ပေးထားပါတယ်။ ကျွန်တော်တို့ဖော်ပြမယ့် နမူနာမှာ Model Data တွေကို Database စနစ်တစ်ခုနဲ့ သိမ်းဆည်းတဲ့လုပ်ဆောင်ချက် မပါဝင်ပါဘူး။ ဒါပေမယ့် Data Persistent Layer ရှိတဲ့ Location က မပါရင် မဖြစ်လို့ url: ‘/’ လို့ထည့်သွင်းပေးထားပါတယ်။ ဒီသတ်မှတ်ချက်က ကျွန်တော်တို့နမူနာမှာတော့ ဘာအလုပ်မှ လုပ်ပေးမှာမဟုတ်ပါဘူး။

ဒီ Collection မှာ သိမ်းဆည်းတဲ့ app.Todo Model တွေကို Auto Increment တန်ဖိုးတစ်ခု သတ်မှတ်ပေးဖို့အတွက် nextOrder() Function ကိုလည်း ထည့်သွင်းသတ်မှတ်ထားပေးပါတယ်။ ဒီတော့မှာ Collection ထဲမှာ Model တစ်ခုမထည့်သွင်းခင် Unique Number တစ်ခုကို တွဲဖက်ထည့်သွင်းစေမှာ ဖြစ်ပါတယ်။ အားလုံးပြီးတော့မှ app.Todos အမည်နဲ့ Model Collection ကို လက်တလောတည်ဆောက်လိုက်တဲ့ TodoList Backbone Collection Object သုံးပြီး သတ်မှတ်ပေးလိုက်ပါတယ်။ ဒါကြောင့် app.Todo Model တွေကို app.Todos Collection မှာ စုစည်းထားဖို့ အသင့်ဖြစ်နေပါပြီ။

ဆက်လက်ပြီး App Interface View ကို တည်ဆောက်ပါတယ်။

// App View ( Whole Todo List )
app.AppView = Backbone.View.extend({
    el: '#app',
    
    events: {
        'keypress #new': 'createOnEnter'
    },
    
    initialize: function() {
        this.$input = this.$('#new');
        this.$main = this.$('#main');
        
        this.listenTo(app.Todos, 'add', this.addOne);
    },
    
    render: function() {
        if ( app.Todos.length ) {
            this.$main.show();
        } else {
            this.$main.hide();
        }
    },
    
    addOne: function( todo ) {
        var view = new app.TodoView({ model: todo });
        $('#list').append( view.render().el );
    },
    
    newAttributes: function() {
        return {
            title: this.$input.val().trim(),
            order: app.Todos.nextOrder(),
            done: false
        };
    },
    
    createOnEnter: function( event ) {
        if ( event.which !== 13 ||
                !this.$input.val().trim() ) {
            return;
        }
    
        app.Todos.create( this.newAttributes() );
        this.$input.val('');
    }

});

View တစ်ခုတည်ဆောက်မှာဖြစ်လို့ Backbone.View.extend ကို အသုံးပြုရပါတယ်။ View အဖြစ် အသုံးချမယ့် Element အနေနဲ့ #app ကို သတ်မှတ်ထားပါတယ်။ ကြိုတင်သတ်မှတ်ထားတဲ့ Element မရှိရင်လည်း တည်ဆောက်နိုင်ပါတယ်။ နမူနာမှာတော့ HTML ထဲမှာ ဒီအတွက် ရည်ရွယ်တည်ဆောက်ထားတဲ့ #app ရှိနေလို့ el: ‘#app’ လို့ သတ်မှတ်ပေးထားပါတယ်။

Event တစ်ခုပဲပါဝင်ပါတယ်။ #new Element မှာ Keypress လုပ်ရင် createOnEnter() ဆိုတဲ့ လုပ်ဆောင်ချက်ကို လုပ်ပါလို့ သတ်မှတ်ထားခြင်း ဖြစ်ပါတယ်။ createOnEnter() ကို လက်ရှိ View ထဲမှာပဲ ထည့်သွင်းသတ်မှတ်ထားတာကို တွေ့ရမှာပါ။ #new Text Input မှာ Enter Key နှိပ်တဲ့အခါ app.Todos Collection ထဲကို app.Topdo Model အသစ်တစ်ခု တည်ဆောက် ထည့်သွင်းစေလိုက်ခြင်း ဖြစ်ပါတယ်။ အဲ့ဒီလို တည်ဆောက်ရာမှာ ထည့်သွင်းပေးရမယ့် တန်ဖိုးတွေကိုတော့ newAttributes() Function နဲ့ ခွဲခြားသတ်မှတ်ထားပါတယ်။ #new Input ထဲကတန်ဖိုးကို title အဖြစ်၊ app.Todos Collection ရဲ့ Auto Increment တန်ဖိုးကို order အဖြစ်နဲ့၊ done ကို false သတ်မှတ်ပေးထားပါတယ်။

ဒီနေရာမှာ သတိပြုရမှာကတော့ initialize() မှာ သတ်မှတ်ထားတဲ့ –

this.listenTo(app.Todos, 'add', this.addOne);

– ဆိုတဲ့ Statement ဖြစ်ပါတယ်။ Backbone View ရဲ့ listenTo() လုပ်ဆောင်ချက်က Collection မှာ အပြောင်းအလဲရှိတဲ့အခါ ဆောင်ရွက်စေလိုတဲ့ လုပ်ဆောင်ချကို သတ်မှတ်ထားဖို့ အသုံးပြုနိုင်ပါတယ်။ နမူနာသတ်မှတ်ချက်အရ app.Todos Collection မှာ Model အသစ်တိုးလာတိုင်း addOne() Function ကို ဆောင်ရွက်ဖို့ သတ်မှတ်ထားတာပါ။ addOne() Function ကတော့ ဆက်လက်ရေးသားမယ့် Todo View ကို သုံးပြီး #list ထဲမှာ Todo Item တစ်ခု ထည့်သွင်းလိုက်ဖို့ jQeury append() Function သုံးပြီးသတ်မှတ်ထားပါတယ်။ ဒါကြောင့် Collection မှာတစ်ခုတိုးတိုင်း #list မှာလဲ Item တစ်ခုက အလိုအလျှောက် လိုက်တိုးသွားမှာ ဖြစ်ပါတယ်။

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

// Item View ( Each Task )
app.TodoView = Backbone.View.extend({
    tagName: 'li',
    
    events: {
    'click .toggle': 'toggleDone',
    'click .destory': 'clear'
    },
    
    template: _.template( $('#item-template').html() ),

    initialize: function() {
        this.listenTo(this.model, 'change', this.render);
        this.listenTo(this.model, 'destroy', this.remove);
    },

    render: function() {
        this.$el.html( this.template( this.model.toJSON() ) );
        
        this.$el.toggleClass( 'done', this.model.get('done') );
        
        return this;
    },
    
    toggleDone: function() {
        this.model.toggle();
    },
    
    clear: function() {
        this.model.destroy();
    }
});

Todo View အတွက်တော့ အသင့်ရှိနေတဲ့ Element ကို မသုံးပါဘူး။ <li> Element တစ်ခု တည်ဆောက်အသုံးပြုဖို့ tagName: ‘li’ လို့ သတ်မှတ် ပေးထားပါတယ်။ Event နှစ်ခု ပါဝင်ပါတယ်။ .toggle လို့ခေါ်တဲ့ Checkbox Input ကို Click လုပ်ရင် toggleDone() Function ကို အလုပ်လုပ်ဖို့ သတ်မှတ်ထားပြီး၊ .destory လို့ခေါ်တဲ့ Delete Button ကို Click လုပ်ရင် clear() Function ကို အလုပ်လုပ်ဖို့ သတ်မှတ်ထားပါတယ်။

template Attribute ကို သတိပြုပါ။ အသေစိတ်ဖော်ပြရမယ့် Template Structure ကို ဒီနေရာမှာ တည်ဆောက်မနေပဲ UnderscoreJS ရဲ့ _.template() Function ကိုသုံးပြီး HTML ထဲမှာ ကျွန်တော်တို့ ရေးသားထားခဲ့တဲ့ #item-template ကို ခေါ်ယူသတ်မှတ်ပေးလိုက်ခြင်း ဖြစ်ပါတယ်။ အဲ့ဒီ #item-teamplate မှာ Checkbox Input တွေ Delete Button တွေကို တစ်ခါတည်း ထည့်သွင်းသတ်မှတ်ထားပြီး ဖြစ်ပါတယ်။

initialize() မှာ linstenTo သုံးပြီး Model တန်ဖိုး ပြောင်းတဲ့အခါ render() Function ကို အလုပ်လုပ်စေဖို့နဲ့ Model ပယ်ဖျက်လိုက်တဲ့ အခါ remove() Function ကို အလုပ်လုပ်ဖို့ သတ်မှတ်ထားပါတယ်။ render() ကိုတော့ ကျွန်တော်တို့ ဆက်လက်ရေးသားထားပါတယ်။ remove() ကတော့ ရေးစရာမလိုပါဘူး။ Backbone View Object မှာပါဝင်တဲ့ remove() ကို extend လုပ်စဉ်ကတည်းက ပါဝင်လာပြီးဖြစ်ပါတယ်။

ဒီနေရာမှာလည်း App View မှာလိုပါပဲ၊ Model အပြောင်းအလဲကိုကြည့်ပြီး View က အလိုအလျှောက် အလုပ်လုပ်သွားမှာ ဖြစ်ပါတယ်။ Model တန်ဖိုး ပြောင်းသွားတိုင်း အလိုအလျှောက် အလုပ်လုပ်ရမယ့် render() Function ထဲမှာ လက်ရှိ Element အတွက် ‘done’ class ကို Toggle လုပ်ပေးဖို့ jQuery ရဲ့ toggleClass() ကို သုံးထားပါတယ်။ ဒီတော့မှ Done ဖြစ်သွားတဲ့ Todo Item နဲ့ မဖြစ်သေးတဲ့ Item တွေကို CSS နဲ့ ကွဲပြားအောင် သတ်မှတ်ထားနိုင်မှာပါ။ toggleDone() Function ကတော့ app.Todo Model တည်ဆောက်စဉ်က ထည့်သွင်းထားတဲ့ toggle() ကိုပဲ ပြန်လည်ခေါ်ယူ အသုံးပြုထားပါတယ်။

အခုဆိုရင် app.Todo Model, app.Todos Collection, app.AppView View, app.TodoView စသဖြင့် လိုအပ်ချက်အားလုံး ပြည့်စုံသွားပါပြီ။ ဆက်လက်ပြီး HTML Document ထဲမှာ -

new app.AppView();

ဆိုတဲ့ Script နဲ့ App ကို စတင်လိုက်ရင် Single Page Todo List App တစ်ခုကို ရရှိပြီဖြစ်ပါတယ်။

bb-todo-screenshot

Text Input Box မှာ ဆောင်ရွက်ရန်ရှိတဲ့လုပ်ငန်းတစ်ခုကို ထည့်သွင်းပြီး Enter နှိပ်လိုက်ရင် app.AppView ရဲ့ createOnEnter() Event အလုပ်လုပ် သွားတဲ့အတွက် app.Todos Collection မှာ Model တစ်ခုတိုးသွားမှာပါ။ app.AppView ထဲမှာပဲ Collection မှာ အသစ်တိုးခဲ့ရင် addOne() လုပ်ဆောင်ချက်ကို ဆောင်ရွက်ဖို့ listenTo လုပ်ထားလို့ addOne() က User Interface မှာလည်း အလိုအလျှောက် Todo Item တစ်ခု တိုးပေးသွားမှာပါ။

အလားတူသဘောမျိုးတဲ့ Todo Item တစ်ခုချင်းစီကို စီမံနေတဲ့ app.TodoView ထဲမှာလည်း .toggle နဲ့ .destory တို့အတွက် လုပ်ဆောင်ချက်များနဲ့ listenTo များကိုယ်စီသတ်မှတ်ထားလို့ ပယ်ဖျက်ခြင်း၊ Done ပြုလုပ်ခြင်းတို့ကိုလည်း ဆောင်ရွက်နိုင်သွားမှာ ဖြစ်ပါတယ်။

Conclusion

အခုဆိုရင် Todo List App တစ်ခုကို Client-side MVC Framework တစ်ခုဖြစ်တဲ့ BackboneJS ကို အသုံးပြုတည်ဆောက် ရရှိသွားပြီဖြစ်ပါတယ်။ Data Model အတွက် သတ်မှတ်ချက်တွေနဲ့ View တစ်ခုချင်းအတွက် သတ်မှတ်ချက်တွေကို ခွဲခြားရေးသားထားနိုင်တဲ့ အားသာချက်ကို ရရှိစေယုံမက၊ Model သို့မဟုတ် Collection မှာ အပြောင်းအလဲရှိတိုင်း View ကို အလိုအလျှောက် သက်ရောက်စေအောင် သတ်မှတ်ထားနိုင်လို့ လက်တွေ့ SPA တွေတည်ဆောက်ရာမှာ အတော်လေး အဆင်ပြေစေမှာပါ။ ဒါကြောင့်လည်း BackboneJS ကို Disqus, Khan Academy, WalMart Mobile, AirBnb စတဲ့ App များက အသုံးပြုထားကြတာ ဖြစ်ပါတယ်။

ကျွန်တော်တို့ရဲ့ နမူနာ App ဟာ လက်ရှိမှာ Client-side App သက်သက်ဖြစ်လို့ Browser ဖွင့်ထားစဉ်သာ Data ကိုသိမ်းထားပေးမှာပါ။ Document ကို Reload လုပ်လိုက်ရင်ပဲ ဖြစ်ဖြစ်၊ Browser ကို ပိတ်ပြီးပြန်ဖွင့် လိုက်ရင်ပဲဖြစ်ဖြစ် Data တွေ ရှိတော့မှာမဟုတ်ပါဘူး။ Data တွေကို အမြဲသိမ်းဆည်းစေလို ရင်တော့ HTML5 LocalStorage သို့မဟုတ် နှစ်သက်ရာ Server-side နည်းပညာတစ်ခုနဲ့ တွဲဖက်ပြီးတော့ ဆက်လက် ဖြည့်စွက်နိုင်ပါတယ်။ နည်းလမ်းနှစ်မျိုးလုံးအတွက် BackboneJS မှာ အခြေခံ လုပ်ဆောင်ချက်တွေ အသင့်ပါဝင်ပြီး ဖြစ်ပါတယ်။

ဒီ Article မှာ ဖော်ပြထားတဲ့ နမူနာကို Addy Osmani ရဲ့ Developing Backbone.js Applications စာအုပ်ကို ကိုးကားဖော်ပြထားခြင်း ဖြစ်ပါတယ်။ မူရင်းနမူနာက ပိုမိုပြည့်စုံပေမယ့် လုပ်ဆောင်ချက် ရှုပ်ထွေးလို့ စတင်လေ့လာစမှာ နားလည်ရခက်နိုင်ပါတယ်။ ဒါကြောင့် နားလည်ရလွယ်ရ မဖြစ်မနေ ပါဝင်ရမယ့် လုပ်ဆောင်ချက်များနဲ့ ပြန်လည်ရေးသားဖော်ပြထားတာပါ။ ဖော်ပြခဲ့တဲ့နမူနာကို Github မှာ Download ရယူနိုင်ပါတယ်

ကျေးဇူးတင်ပါတယ်။

Awesome Icons for Awesome Developer

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

စာအုပ်ဆိုင်တွေမရောက်တာ ကြာပါပြီ။ အခုလို အကြောင်းတိုက်ဆိုင်လို့ ရောက်တဲ့အခါ အံ့အားသင့် ရတာကတော့ Facebook အသုံးပြုနည်း၊ Gmail အသုံးပြုနည်း၊ Twitter အသုံးပြုနည်း စတဲ့စာအုပ်များက နည်းပညာစာအုပ်စဉ်ကို စိုးမိုးထားတာကို တွေ့လိုက်ရပါတယ်။ ပြီးတော့ Hacking အကြောင်း စာအုပ်တွေလည်း ပါပါသေးတယ်။

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

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

Usability and Icons

Website လေးတစ်ခုသုံးဖို့အရေး အသုံးပြုနည်းဖတ်နေရမယ်ဆိုရင် လက်တွေ့မှာ ဘယ်သူမှသုံးမှာ မဟုတ်ပါဘူး။ User Interface ကိုကြည့်လိုက်တာနဲ့ အလိုလို အသုံးပြုတက်နေရမှာ၊ Usable ဖြစ်နေရမှာ Intuitive ဖြစ်နေရမှာဖြစ်ပါတယ်။ ဒီလို Usable ဖြစ်တဲ့ Website Interface များတည်ဆောက်တဲ့အခါမှာ Icon များရဲ့အခန်းကဏ္ဍက အတော်လေးအရေးပါပါတယ်။ Button တစ်ခုရဲ့ လုပ်ဆောင်ချက်ကို စာတွေနဲ့ အရှည်ကြီး ရေးပြနေမယ့်အစား Icon လေးတစ်ခုနဲ့ ဖော်ပြလိုက်ယုံနဲ့ အသုံးပြုသူက ပိုမိုနားလည်နိုင်ပါတယ်။ ဥပမာ – မှန်ဘီလူးပုံလေးကိုမြင်ရင် Search လုပ်ဆောင်ချက်မှန်း အလိုလိုသိနိုင်စေသလို Diskette ပုံးလေးကိုတွေ့ရင် Save လုပ်ဆောင်ချက်ဖြစ်ကြောင်း အလိုလိုသိနိုင်စေပါတယ်။

Website မှာ အသုံးပြုတဲ့ Icon တွေဟာ ဟိုနားတစ်မျိုး၊ ဒီနားတစ်ဖုံ ဖြစ်နေလို့တော့ မရပါဘူး။ ရုပ်ဆိုးပါတယ်။ သုံးထားတဲ့ Icon အားလုံးက Icon Set တစ်ခုတည်းကလာတဲ့ တူညီတဲ့ Icon တွေဖြစ်ဖို့လိုပါတယ်။ ကျွန်တော့်မှာ အခမဲ့ရတဲ့ Icon Set တွေစုစည်းထားတာ အများကြီးရှိပါတယ်။ Project တစ်ခုစတော့မယ် ဆိုတိုင်း အဲ့ဒီထဲက လက်ရှိ Project နဲ့ ကိုက်ညီနိုင်တဲ့ Icon Set ကို ရွေးချယ်ရပါတယ်။ Icon Set တစ်ခုတည်းနဲ့ Project မှာပါဝင်မယ့် Function စုံအောင် ဖော်ပြနိုင်ရင်တော့ အကောင်းဆုံးပါပဲ။ တစ်ခါတစ်လေတော့လည်း နီးစပ်တဲ့ Icon Set နှစ်ခုသုံးခုကို ပေါင်းစပ် အသုံးပြုရပါတယ်။ ကျွန်တော်ကိုယ်တိုင် Designer တစ်ယောက်မဟုတ်သလို၊ ကျွန်တော့် Team ထဲမှာလည်း Icon Designer မရှိလို့ Icon Set တွေကို ကိုယ်တိုင်ရေးဆွဲ အသုံးပြုနိုင်ခြင်းတော့ မရှိသေးပါဘူး။

Introducing An Icon Set

ဒီ Article မှာ အဲ့ဒီ Icon Set တွေအားလုံးကို လွှင့်ပြစ်လိုက်လို့ရလောက်အောင် ပြီးပြည့်စုံပြီး ကောင်းမွန်တဲ့ Icon Set တစ်ခုကို ဖော်ပြလိုပါတယ်။ Icon Font နည်းစနစ်ကို အသုံးပြုထားတဲ့ Icon Set တစ်ခုဖြစ်ပါတယ်။ Icon Font များအကြောင်းကို အရင်ဆုံး ဖော်ပြလိုပါတယ်။

အမှန်တော့ Icon ဆိုတာ 16×16, 32×32, 48×48, 128×128 စသဖြင့် Size အလိုက် Icon အရွယ်အစားနဲ့ ကြိုတင်ရေးဆွဲထားတဲ့ ပုံတွေပါ။ Website တစ်ခုမှာ အသုံးပြုတဲ့ Icon များဟာ အရေအတွက်အားဖြင့် (၅၀) လည်းဖြစ်နိုင်ပါတယ်။ (၁၀၀) လည်းဖြစ်နိုင်ပါတယ်။ Icon ဆိုတာ အရွယ်အစားသေးငယ်တဲ့ ပုံလေးတွေ ဖြစ်ပေမယ့် အရည်အတွက် ၅၀-၁၀၀ ရှိတဲ့ ပုံတွေကို ဖော်ပြနိုင်ဖို့အတွက် (ပုံမှန်ဆိုရင်) Web Browser က Web Server ထံ Request ပေါင်း ၅၀-၁၀၀ လောက် ပေးပို့ဖို့ လိုတက်ပါတယ်။ ဒီလိုအပ်ချက်က Website ကို အလွန်နှေးသွားစေနိုင်ပါတယ်။ ဒီပြဿနာကိုဖြေရှင်းဖို့ CSS Sprite နည်းပညာတွေ အသုံးပြုရပါတယ်။ အသုံးလိုတဲ့ Icon ၅၀-၁၀၀ ကို စုစည်းပြီး Image တစ်ခုတည်းဖြစ်သွားအောင် ပြောင်းပြီးတော့မှ CSS နဲ့ ဖော်ပြလိုတဲ့ Icon ကိုပဲရွေးချယ် ဖော်ပြတဲ့ နည်းစနစ်ဖြစ်ပါတယ်။ ဒီနေရာမှာ အသေးစိတ် မဖော်ပြနိုင်ပါဘူး။ CSS Sprite ဆိုတဲ့ Keyword နဲ့သာ Google မှာ ရှာဖွေလေ့လာကြည့်ပါ။

Icon တွေရဲ့ နောက်ပြဿနာတစ်ခုက Size ဖြစ်ပါတယ်။ ကိုယ်အသုံးပြုလိုတာက 24×24 Icon တွေဖြစ် ပေမယ့် ရှိနေတာက 16×16 သို့မဟုတ် 32×32 ဆိုရင် အဆင်မပြေပါဘူး။ ရှိနေတဲ့ Size ကို ဆွဲခြုံ့လိုက်လို့၊ ဆွဲချဲ့လိုက်လို့ မရပါဘူး။ Bitmap Image တွေဖြစ်လို့ Icon တွေ ဝါးကုန်တာမျိုး ဖြစ်သွားမှာပါ။ နောက်ပိုင်းမှာ SVG ကဲ့သို့ Vector Graphic Icon တွေ သုံးလာကြတာ ရှိပေမယ့် SVG တွေရဲ့ File size က ကြီးနေတက်သလို Browser Support မှာလည်း ပြဿနာရှိပါတယ်။

Icon Font

အခုနောက်ပိုင်း ခေတ်စားလာတဲ့ Icon Font နည်းစနစ်ကတော့ Icon တွေမှာရှိနေတဲ့ ပြဿနာတွေကို ဖြေရှင်းပေးနိုင်လာခဲ့ပါတယ်။ Icon Font ဆိုတာ ကျွန်တော်တို့ အင်္ဂလိပ်စာ၊ မြန်မာစာများ ဖော်ပြဖို့သုံးတဲ့ Font တွေလိုပါပဲ။ ဒါပေမယ့် Font File ထဲမှာ အင်္ဂလိပ်စာ၊ မြန်မာစာလို စာလုံးတွေ ရေးဆွဲထည့်သွင်း ထားရမယ့်အစား Image လေးတွေ ရေးဆွဲထည့်သွင်းထားတဲ့ Font များဖြစ်ပါတယ်။ ဥပမာ – <b>E</b> လို့ ရေးသားထည့်သွင်းမယ်ဆိုရင် ပုံမှန်အားဖြင့် E Character ကိုဖော်ပြရမှာ ဖြစ်ပေမယ့် Font File ထဲက E Character နေရာမှာ ခဲတံပုံလေးနဲ့ အစားထိုးထားရင် E ဆိုတဲ့စာလုံးအစား ခဲတံပုံလေးက အစားထိုးဖော်ပြ နေစေမှာ ဖြစ်ပါတယ်။

အခြေခံအားဖြင့် ကျွန်တော်တို့သုံးလိုတဲ့ Font က အသုံးပြုသူရဲ့ စက်ထဲမှာ ရှိနေမှသာ အဆင်ပြေမှာပါ။ ဒါပေမယ့် ကျွန်တော်တို့အသုံးပြုလိုတဲ့ Icon Font တွေ အသုံးပြုသူရဲ့ စက်ထဲမှာ ရှိနေဖို့အတွက် သိပ်စိတ်ပူဖို့မလိုပါဘူး။ CSS3 Font-Embed ကို Browser အားလုံး (IE6/7 အပါအဝင်) က Support လုပ်တဲ့အတွက် Website နဲ့အတူ Font ကို တွဲဖက်ထည့်သွင်း (Embed) လုပ်ပေးလိုက်လို့ ရပါတယ်။

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

Benefit of Icon Fonts

Icon Font တွေက မူလ Image Icon တွေမှာ ရှိနေတဲ့ ပြဿနာအခက်အခဲတွေကို ဖြေရှင်းပေးသလို့ ဖြည့်စွက်ရရှိလာတဲ့ အကျိုးကျေးဇူးတွေကလည်း ရှိနေပါသေးတယ်။

၁.) Icon Font တွေဟာ Vector Graphic တွေဖြစ်တဲ့အတွက် Size အတွက် စိတ်ပူဖို့မလိုပါဘူး။ အသုံးပြုလိုတဲ့ Size ကို သတ်မှတ်အသုံးပြုလို့ ရပါတယ်။

၂.) Icon Font တွေဟာ Image Font တွေထက် File Size အားဖြင့် အတော်လေးသေးပါတယ်။ မူလကတည်းက Font File တစ်ခုတည်းမှာ Icon တွေစုစည်းထားတာဖြစ်လို့ CSS Sprite နည်းစနစ်တွေ ထပ်သုံးနေဖို့လည်း မလိုတော့ပါဘူး။ Website Performance အများကြီးပိုကောင်း သွားနိုင်ပါတယ်။

၃.) Icon Font တွေဟာ ရိုးရိုးစာ Text ကဲ့သို့အလုပ်လုပ်တာ ဖြစ်တဲ့အတွက် Icon Font တစ်ခုတည်းကို သတ်မှတ်လို့တဲ့ Color အရောင်နဲ့ အလွယ်တစ်ကူ သတ်မှတ်အသုံး ပြုနိုင်ပါတယ်။ အရောင်နှစ်မျိုးလိုချင်လို့ Icon Set နှစ်မျိုးသုံးစရာ မလိုတော့ပါဘူး။

၄.) Font တွေက Unicode Font တွေဖြစ်လို့ Icon ပေါင်း ထောင်ဂဏာန်းအထိ (လိုအပ်ရင်) စုစည်းထည့်သွင်းနိုင်ပါတယ်။ အဲ့ဒီလိုထည့်လိုက်လို့ ဘာပြဿနာမှ ဖြစ်စရာမရှိပါဘူး။

ဒီလိုဒီလို အားသာချက်တွေက Icon Font တွေ ပြောင်းလဲအသုံးပြုကြသင့်တဲ့ အချက်တွေပါပဲ။ Icon Font ရဲ့ အဓိကကျတဲ့ အားနည်းချက်ကတော့ တစ်ချက်တည်းပါ။ Icon တွေဟာ Monochrome ဖြစ်မှသာ အဆင်ပြေခြင်းဖြစ်ပါတယ်။ Gradient တွေ၊ Shadow တွေ၊ အရောင်တွေ ရောစပ်ထားတဲ့ ရှုပ်ထွေးတဲ့ Icon တွေ (ရနိုင်ပေမယ့်) လိုချင်ရင် သိပ်အဆင်မပြေပါဘူး။ ဒါပေမယ့် ကျွန်တော်ကတော့ ဒါကို အားနည်းချက်လို့ မမြင်ပါဘူး။ တစ်ချို့ ကိစ္စတွေက ရှုပ်ထွေးနေစရာမလိုပါဘူး။ ရိုးရှင်းတဲ့အရာကို ရိုးရိုးရှင်းရှင်းအသုံးပြုတာလည်း ကောင်းတာပါပဲ။

Font Awesome

Icon Font တွေထဲက ကျွန်တော်ရွေးချယ်ဖော်ပြလိုတဲ့ တစ်ခုကတော့ Font Awesome ဖြစ်ပါတယ်။ Twitter Bootstrap CSS Framework နဲ့တွဲဖက်အသုံးပြုဖို့ ရည်ရွယ်ဖန်တီးထားတဲ့ Icon များဖြစ်ပါတယ်။ ဒါပေမယ့် Twitter Bootstrap မပါပဲ ဒီအတိုင်းလဲ အသုံးပြုနိုင်ပါတယ်။

ဒီ Article ရေးသားချိန်နောက်ဆုံး ထွက်ထားတဲ့ Font Awesome 3.2.1 မှာ Icon ပေါင်း (၃၆၁) ခု ပါဝင်ပါတယ်။ အသုံးပြုပုံကို ဆက်လက်ဖော်ပြသွားပါမယ်။

ပထမဦးဆုံး Font Awesome ကို Download ရယူပါ။ ရရှိလာတဲ့ Archive ကို ဖြည်လိုက်ရင် css, font, less, sass ဆိုပြီး Folder လေးခု ပါဝင်ပါလိ့မ်မယ်။ less နဲ့ sass က CSS Preprocessor နည်းပညာများ ဖြစ်ပါတယ်။ ကျွန်တော်တို့အတွက် မလိုအပ်ပါဘူး။ ရှင်းသွားအောင် ဖျက်ပြစ်လိုက်လို့ ရပါတယ်။

font Folder ထဲမှာ .eot, .ttf, .svg စသဖြင့် Format အမျိုးမျိုးနဲ့ Font File တွေရှိပါတယ်။ စမ်းသပ်နိုင်ဖို့ font Folder နဲ့ သူ့အထဲက Font File တွေလိုအပ်ပေမယ့် ကျွန်တော်တို့ တိုက်ရိုက်ကိုင်တွယ်ဖို့ မလိုအပ်ပါဘူး။ ဒီအတိုင်းထားလိုက်ယုံပါပဲ။ css Folder ထဲကို ဝင်ကြည့်လိုက်ရင် font-awesome.css, font-awesome.min.css, font-awesome-ie7.css, font-awesome-ie7.min.css ဆိုပြီး CSS File လေးခု ပါဝင်တာကို တွေ့ရပါလိမ့်မယ်။ အဲ့ဒီထဲက font-awesome.min.css တစ်ခုကို အသုံးပြုရင်လုံလောက်ပါပြီ။ IE7 ကိုပါ Support လုပ်လိုမှသာ font-awesome-ie7.min.css ကိုပါ ထည့်သွင်းအသုံးပြုပေးရမှာပါ။

HTML Document မှာ font-awesome.min.css ကို <link> Element နဲ့ ချိတ်ဆက်ပြီးရင် Font Awesome မှာပါဝင်တဲ့ Icon ပေါင်း (၃၆၁) ခုကို စတင်ထည့်သွင်း အသုံးပြုနိုင်ပြီဖြစ်ပါတယ်။ Icon တွေထည့်သွင်းဖို့ <i> Element ကို အသုံးပြုနိုင်ပါတယ်။ ဥပမာ – Camera Icon လေးတစ်ခု ထည့်သွင်းလိုရင် အခုလိုထည့်သွင်းနိုင်ပါတယ် -

<i class="icon-camera-retro"></i>

<i> Element အတွက် class ကို icon-camera-retro လို့ သတ်မှတ်ပေးလိုက်ယုံပဲ ဖြစ်ပါတယ်။ Icon (၃၆၀) လုံးအတွက် class တွေကို သိရှိလိုရင် Font Awesome Cheatsheet မှာ ကြည့်ရှုနိုင်ပါတယ်။

Icon Size ကို CSS နဲ့ လိုသလောက် သတ်မှတ်နိုင်ပါတယ်။ ဒါ့အပြင် – icon-large, icon-2x, icon-3x, icon-4x အစရှိတဲ့ class များကို အသုံးပြုပြီးတော့လည်း Size အမျိုးမျိုး သတ်မှတ်နိုင်ပါတယ်။ ဥပမာ – စောစောက Camera Icon ကိုပဲ ခပ်ကြီးကြီးဖော်ပြစေလိုရင် အခုလို ရေးသားသတ်မှတ် နိုင်ပါတယ် -

<i class="icon-camera-retro icon-4x"></i>

Icon ကို သူ့အတိုင်းမဟုတ်ပဲ ဘောင်နဲ့ဖော်ပြစေလိုရင် icon-border ဆိုတဲ့ Class ကို အသုံးပြုနိုင်ပါတယ်။ ဥပမာ -

<i class="icon-camera-retro icon-border"></i>

font-awesome-1

ထည့်သွင်းထားတဲ့ Icon ကို ချာလပါတ်လည်နေစေလိုရင်တော့ icon-spin ဆိုတဲ့ Class ကို အသုံးပြုနိုင်ပါတယ်။ ဥပမာ -

<i class="icon-cog icon-spin"></i>

Icon ကို Bullet List ရဲ့ List Item Icon အဖြစ် အသုံးပြုလိုရင်တော့ icon-li ဆိုတဲ့ Class ကို အသုံးပြု နိုင်ပါတယ်။ Parent <ul> မှာတော့ icons-ul ဆိုတဲ့ Class သတ်မှတ်ထားပေးသင့်ပါတယ်။ ဥပမာ -

<ul class="icons-ul">
  <li><i class="icon-li icon-circle-arrow-right"></i>Home</li>
  <li><i class="icon-li icon-circle-arrow-right"></i>About</li>
  <li><i class="icon-li icon-circle-arrow-right"></i>Contact</li>
  <li><i class="icon-li icon-circle-arrow-right"></i>Info</li>
  <li><i class="icon-li icon-circle-arrow-right"></i>FAQs</li>
</ul>

font-awesome-2

Icon ကို Rotate လုပ်ပြီးဖော်ပြစေလိုရင်တော့ icon-rotate-90, icon-rotate-180, icon-rotate-270, icon-flip-horizontal, icon-flip-vertical စတဲ့ Class များကိုအသုံးပြုနိုင်ပါတယ်။

Icon တွေကို တစ်ခုပေါ်တစ်ခု ထပ်ပြီးဖော်ပြစေလိုရင်တော့ icon-stack နဲ့ icon-stack-base တို့ကို ပေါင်းစပ်အသုံးပြုနိုင်ပါတယ်။ ဥပမာ -

<span class="icon-stack">
  <i class="icon-camera"></i>
  <i class="icon-ban-circle icon-stack-base"></i>
</span>

Parent <span> မှာ icon-stack သတ်မှတ်ထားပြီး၊ အောက်ခံအဖြစ်ဖော်ပြစေလိုတဲ့ Icon မှာတော့ icon-stack-base သတ်မှတ်အသုံးပြုရခြင်း ဖြစ်ပါတယ်။

ဒါတွေအပြင် CSS နဲ့လည်း လိုသလိုဖြည့်စွက်သတ်မှတ်နိုင်ပါသေးတယ်။ ဥပမာ – Icon ရဲ့အရောင်ကို အနီးရောင်အဖြစ် ဖော်ပြစေလိုရင် အခုလို သတ်မှတ်နိုင်ပါတယ်။

<i class="icon-camera-retro" style="color:red"></i>

နမူနာမှာ Inline-Style နဲ့ color:red CSS Rule ကိုသတ်မှတ်ထားပါတယ်။ လက်တွေ့မှာ တစ်ခုမဟုတ်ပါဘူး၊ CSS မှာ Text အတွက် သတ်မှတ်လို့ရတဲ့ Rule တွေ အားလုံးကို သတ်မှတ်အသုံး ပြုနိုင်မှာဖြစ်ပါတယ်။

font-awesome-3

Conclusion

Icon ပေါင်း (၃၆၁) ခုဆိုတာ Website တစ်ခု Application တစ်ခုမှာ လိုအပ်နိုင်တဲ့ Icon တွေအတွက် လုံလောင်စေနိုင်မယ့် အရည်အတွက်ဖြစ်ပါတယ်။ Popular Framework ဖြစ်တဲ့ Twitter Bootstrap နဲ့ တွဲဖက်အသုံးပြုဖို့ ရည်ရွယ်ဖန်တီးထားခြင်း၊ Stack, Spin, Rotate စတဲ့ လုပ်ဆောင်ချက်များ အသင့် ပါဝင်ခြင်းနဲ့ Icon Font တွေမှာ ရရှိနိုင်တဲ့ အားသားချက်တွေကို ရရှိနိုင်မှာဖြစ်လို့ Web Developer များအတွက် အတော်လေး အသုံးဝင်မယ့် Product တစ်ခုဖြစ်ကြောင်း ဖော်ပြလိုက်ရပါတယ်။

အခုဖော်ပြခဲ့တဲ့ နမူနာတွေကို Font Awesome Examples စာမျက်နှာမှာလည်း လေ့လာနိုင်ပါတယ်။

Writing Dynamic CSS

အခုနောက်ပိုင်း နည်းပညာအကြောင်းအရာတွေကို Article အဖြစ် မရေးဖြစ်တာ ကြာပါပြီ။ နည်းပညာဝေမျှလိုတာ ရှိလာရင် Facebook မှာပဲ ပြောဖြစ်လာပါတယ်။ ပေါ့ပေါ့ပါးပါးနဲ့ မြန်မြန်ဆန်ဆန် ပြောချင်ရာကို ပြောလိုက်နိုင်တဲ့အတွက်ပါ။ ဒါပေမယ့် “နှုတ်တစ်ရာ စာတစ်လုံး” ဆိုတဲ့ဆိုရိုးက ရှိနေပါတယ်။ Facebook (နဲ့ အခြား social network တွေ) ဟာ လူတွေရဲ့ နေ့စဉ်လူမှုဆက်ဆံရေးမှာ အစားထိုးနေရာယူ လာတဲ့ ကွန်ယက်တွေ ဖြစ်ပါတယ်။ ဒီ လူမှုကွန်ယက်တွေမှာ ရေးသားပြောဆိုချက်တွေဟာ “စကား” များသာ ဖြစ်ပါတယ်။ “စာ” လို့ပြောဖို့ခက်ပါတယ်။ ဒါကြောင့်လည်း Facebook လိုနေရာမျိုးမှာ ရေးသားထားချက်များကို အကိုးအကား အထောက်အထား ပြုစရာအဖြစ် ရရှိနိုင်မှာမဟုတ်ပါဘူး။

ကျွန်တော်ဟာ Professional Web Developer လို့အမည်ရတဲ့ စာအုပ်တစ်အုပ်ကို လွန်ခဲ့တဲ့ (၆) လခန့်က စတင်ရေးသားပြုစုခဲ့ပြီး၊ ဩဂုတ်လ (၇) ရက်နေ့မှာ မိတ်ဆက်ကြေငြာနိုင်ခဲ့ပါတယ်။ အဲ့ဒီစာအုပ်မှာ ဒီနည်းပညာဘလော့ဂ်မှာ ရေးသားထားခဲ့တဲ့ Article တွေကို အလျှင်သင့်သလို အသုံးပြုခြင်း၊ ကိုးကားခြင်းတို့ကို ပြုလုပ်ဖြစ်ခဲ့ပါတယ်။ အခုလည်း နည်းပညာအကြောင်းလေး တစ်ခု ပြောစရာရှိလာတဲ့ အတွက်၊ နောင်လိုအပ်ရင် ညွှန်ပြ၊ ကိုးကားနိုင်အောင် အပျင်းထူမနေတော့ပဲ Article တစ်ခုအဖြစ် ရေးသားဖော်ပြချင်ပါတယ်။

CSS Preprocessors

CSS ဟာ Logicless Language တစ်မျိုးဖြစ်ပါတယ်။ HTML Element များကို “မည်သို့မည်ပုံ ဖော်ပြရမည်” လို့ သတ်မှတ်ကြေငြာထားတဲ့ ကြေငြာချက် အစုအဝေးသာ ဖြစ်ပါတယ် (အသေးစိတ်ကို ဒီမှာဖတ်နိုင်ပါတယ်)။ သူ့မှာ Variable, Conditional Statement, Function စတဲ့ လုပ်ဆောင်ချက်တွေ ပါဝင်ခြင်းမရှိပါဘူး။ သဘာဝအရ လိုလည်းမလိုအပ်ပါဘူး။ ကျွန်တော့်အမြင်မှာလည်း Logic တွေမပါလို့ CSS က အားနည်းနေတယ်လို့ မမြင်ပါဘူး။ တစ်ချို့ကိစ္စတွေက ရိုးရှင်းလေ ကောင်းလေပါပဲ။

ဒါပေမယ့် တစ်ချို့ က CSS မှာ Programming Language များကဲ့သို့ Logic များ ထည့်သွင်းရေးသားနိုင်ရင် ပိုကောင်းသွားမယ်လို့ ယူဆကြပါတယ်။ ဥပမာ – Color Code တစ်ခုကို Variable ထဲမှာထည့်သိမ်းပြီး အသုံးပြုမယ်ဆိုပါစို့။ Variable ရဲ့ တန်ဖိုးကို ပြောင်းလိုက်ယုံနဲ့ သူ့ကိုအသုံးပြုထားတဲ့ နေရာအားလုံးကို သက်ရောက်စေမှာဖြစ်လို့ အများကြီးပိုပြီး Maintainable ဖြစ်သွားစေတဲ့သဘောပါ။ တစ်ချို့ ထပ်ခါထပ်ခါ ရေးရမယ့် ကိစ္စတွေကိုလည်း Function အနေနဲ့ ခွဲထားပြီး လိုသလိုခေါ်သုံးနိုင်မယ် ဆိုရင်လည်း စိတ်ဝင်စားစရာပါပဲ။

ဒါတွေကြောင့်လည်း LESS CSS, SASS အစရှိတဲ့ CSS Preprocessor နည်းပညာတွေ ရေပန်းစား လာတာပါ။ ဒီနည်းပညာတွေက CSS ကို Programming Logic တွေနဲ့ ရေးသားနိုင်အောင် အကူအညီပေးပါတယ်။ ဥပမာ – LESS CSS ကိုအသုံးပြုပြီး အခုလိုရေးသားနိုင်ပါတယ် -

@color: #4D926F;

#header {
  color: @color;
}
h2 {
  color: @color;
}

အခြေခံအားဖြင့် ရိုးရိုး CSS ရေးသားပုံအတိုင်းပဲ ရေးရတာပါ။ ဒါပေမယ့် @color ဆိုတဲ့ Variable ထဲမှာ #4D926F ဆိုတဲ့ တန်ဖိုးတစ်ခုကို ထည့်သွင်းထားတာကို သတိပြုပါ။ အဲ့ဒီလို Color တန်ဖိုးရှိနေတဲ့ @color Variable ကို ဆက်လက်ရေးသားတဲ့ CSS တွေထဲမှာ ရယူအသုံးပြုထားခြင်း ဖြစ်ပါတယ်။ ဒီသဘောကိုပဲ SASS နဲ့ အခုလို ရေးသားနိုင်ပါတယ် –

$color: #4D926F;

#header {
  color: $color;
}
h2 {
  color: $color;
}

ရေးသားပုံ အတူတူပါပဲ။ LESS မှာ Variable တွေက @ Sign နဲ့စရပြီး SASS မှာတော့ $ Sign နဲ့စပေးရခြင်းသာ ကွာသွားတာပါ။

Function ကဲ့သို့သော လုပ်ဆောင်ချက်ကို LESS CSS မှာ Mixin လို့ခေါ်ပါတယ်။ အခုလိုရေးသားရပါတယ် –

.rounded-corners (@radius: 5px) {
  -webkit-border-radius: @radius;
  -moz-border-radius: @radius;
  border-radius: @radius;
}

#header {
  .rounded-corners;
}
#footer {
  .rounded-corners(10px);
}

ကြိုတင်ကြေငြာထားတဲ့ .rounded-corners Mixin ကို ဆက်လက်ရေးသားတဲ့ CSS တွေထဲမှာ လိုသလို ပြန်လည်ခေါ်ယူထားခြင်း ဖြစ်ပါတယ်။

ပြီးတော့ CSS မှာ Nested Selector တွေသုံးပြီး အခုလိုရေးရလေ့ ရှိပါတယ် –

#header h1 {
  font-size: 26px;
  font-weight: bold;
}
#header p {
  font-size: 12px;
}
#header p a {
  text-decoration: none;
}

အလားတူရလဒ်ရရှိဖို့ LESS CSS နဲ့ အခုလိုရေးသားနိုင်ပါတယ်။

#header {
  h1 {
    font-size: 26px;
    font-weight: bold;
  }
  p { font-size: 12px;
    a {
      text-decoration: none; 
    }
  }
}

အခြားသော စိတ်ဝင်စားဖွယ်လုပ်ဆောင်ချက်တွေ ပါဝင်သေးပေမယ့် အသေးစိတ်ကိုတော့ စိတ်ဝင်စားရင် lesscss.org နဲ့ sass-lang.com ကိုယ်တိုင်လေ့လာ နိုင်ပါတယ်။ ကျွန်တော်တော့ ဒီနည်းပညာတွေ မသုံးသလို ဒီနေရာမှာ အဓိက ဖော်ပြလိုတာလည်း ဒီနည်းပညာတွေ မဟုတ်ပါဘူး။ စာဖတ်သူက ဒီလိုနည်းပညာတွေ ရှိနေတာကို မသိသေးရင် သိသွားအောင်သာ ထည့်သွင်းဖော်ပြတာပါ။

CSS Preprocessor နည်းပညာတွေကို မသုံးရခြင်းက ကျွန်တော့်မှာ အကြောင်းပြချက် နှစ်ချက်ရှိပါတယ်။ နံပါတ်တစ်ကတော့ Pre Process လုပ်ရခြင်း ဖြစ်ပါတယ်။ ဒီနည်းပညာတွေဟာ Web Standard မဟုတ်သလို Browser တွေကလည်း နားမလည်တဲ့အတွက်၊ ရေးသားထားတဲ့ Code က သူ့အတိုင်းတော့ အလုပ်မလုပ် နိုင်ပါဘူး။ Browser နားလည်တဲ့ Standard CSS ဖြစ်အောင် အရင် Process လုပ်ရပါသေးတယ်။ Process လုပ်ပြီး ရလာတဲ့ Standard CSS ကမှ Browser ထဲမှာ လက်တွေ့အလုပ်လုပ် သွားမှာပါ။ ဒီလို Preprocess အဆင့်ပိုလာတဲ့အတွက် CSS ရဲ့ မူလ Dynamic သဘာဝ အားသာချက်ကို ဆုံးရှုံးစေပါတယ်။

နောက်တစ်ချက်ကတော့ Debug ဖြစ်ပါတယ်။ Preprocessor ကိုသုံးပြီး ရေးနေပေမယ့် တစ်ကယ်အလုပ် လုပ်တာက Process လုပ်ပြီးရလာတဲ့ CSS ဖြစ်လို့၊ ပြဿနာကြုံလာတဲ့အတွက် အဲ့ဒီ Process လုပ်ထားရလာတဲ့ CSS မှာအဖြေရှာရမှာပါ။ ဒီအချက်က နည်းနည်း ကိုးလိုးကန့်လန့် ဖြစ်နေပါတယ်။ ရရှိလာမယ့် အားသာချက်တွေနဲ့ ဒီလို အပိုရှုပ်ထွေးမှုတွေကို နှိုင်းယှဉ်လိုက်တဲ့အခါ (အများစုက Preprocessor နှစ်သက်ကြပေမယ့်) ကျွန်တော်ကတော့ CSS အတိုင်း ရေးရတာကိုသာ ပိုမိုနှစ်သက်ပါတယ်။

Dynamic CSS

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

CSS File တွေကို အခြေခံအားဖြင့် .css Extension နဲ့ သိမ်းဆည်းပေးရပါတယ်။ Dynamic CSS လုပ်ဆောင်ချက်ရရှိဖို့ PHP ကဲ့သို့ Server-side Script တွေရဲ့ အကူအညီလိုအပ်ပါတယ်။ ဒါပေမယ့် Web Server တွေကို File Extension .php ပေးထားတဲ့ File များထဲက Script တွေကိုသာ အလုပ်လုပ်အောင် သတ်မှတ်ထားကြလေ့ရှိပါတယ်။ ဒါကြောင့် ပထမအဆင့်အနေနဲ့ ကျွန်တော်တို့ရဲ့ CSS File ကို .php Extension နဲ့ သိမ်းဆည်း ရေးသားဖို့ လိုပါတယ်။ ဥပမာ – style.php

ဒီလိုသတ်မှတ်ပြီးရင် CSS ထဲမှာ PHP Script တွေ ရောစပ်ရေးသားနိုင်ပါပြီ။ အထက်မှာဖော်ပြခဲ့တဲ့ Variable နမူနာကို PHP နဲ့ CSS ပေါင်းစပ်ပြီး အခုလို ရေးသားနိုင်ပါတယ်။

<? header("Content-type: text/css") ?>
<? $color = '#4D926F' ?>

#header {
  color: <?= $color ?>;
}
h2 {
  color: <?= $color ?>;
}

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

<? function rounded_corners($radius = '5px') { ?>
  -webkit-border-radius: <?= $radius ?>;
  -moz-border-radius: <?= $radius ?>;
  border-radius: <?= $radius ?>;
<? } ?>

#header {
  <? rounded_corners() ?>
}
#footer {
  <? rounded_corners('10px') ?>
}

ဒါဘာမှတော့ မထူးဆန်းပါဘူး။ ပုံမှန်အားဖြင့် HTML Document တွေထဲမှာ PHP Script တွေရောစပ်ရေးသား သလိုပဲ၊ CSS Style တွေထဲမှာ PHP Script တွေ ရောစပ်ရေးသား လိုက်ခြင်းပဲဖြစ်ပါတယ်။ ဒီနည်းနဲ့ CSS ကို Dynamic CSS ဖြစ်အောင်ရေးသားနိုင်သလို Preprocessors တွေကပေးတဲ့ Reusability နဲ့ Maintainability ကို ရရှိနိုင်စေပါတယ်။ Pre Process လုပ်ဖို့ မလိုအပ်ပါဘူး။ အသုံးပြုလိုရင် HTML ကနေ ပုံမှန်နည်းလမ်းအတိုင်း ချိတ်ဆက်လိုက်ယုံပါပဲ။ ဥပမာ -

<link rel="stylesheet" href="style.php">

ဒီနေရာမှာ အဓိကကျတာကတော့ style.php ထဲမှာ ရေးသားရမယ့် –

<? header("Content-type: text/css") ?>

- ဆိုတဲ့ သတ်မှတ်ချက်ဖြစ်ပါတယ်။ File က .php Extension နဲ့ ဖြစ်နေတဲ့အတွက် ပုံမှန်ဆိုရင် PHP Script File အနေနဲ့ ယူဆထားမှာပါ။ ဒါပေမယ့် header() Function သုံးပြီး File ရဲ့ Content Type ကို text/css လို့ ပြောင်းထားတဲ့အတွက် Extension .php ဖြစ်နေပေမယ့် CSS File တစ်ခုကဲ့သို့ အလုပ်လုပ်သွားစေမှာပဲ ဖြစ်ပါတယ်။

Conclusion

PHP အဖွင့်/အပိတ် Tag တွေ ထည့်ရေးနေရတဲ့အတွက် Dynamic CSS နည်းနဲ့ရေးတဲ့ Code ဟာ Preprocessor နည်းပညာတွေရဲ့ Code လောက်တော့ ရှင်းလင်းခြင်း မရှိပါဘူး။ Tag တွေက မျက်စိအမြင်မှာ ရှုပ်နေပါတယ်။ ဒါပေမယ့် လိုချင်တဲ့ Maintainability ကိုတော့ ရရှိနိုင်နေဆဲ ဖြစ်ပါတယ်။ ကျွန်တော့်လို ရိုးရှင်းတဲ့မူလ CSS ကိုသာနှစ်သက်ပြီး၊ အချို့ နေရာတွေမှာလည်း Programming Logic လေးတွေကို လိုသလို ထည့်သွင်းရေးသား လိုသူအတွက်တော့ Dynamic CSS နည်းစနစ်က အတော်လေး အဆင်ပြေပါတယ်။ CSS ရဲ့ မူလရိုးရှင်းမှုကို မထိခိုက်ပဲ Programming ရဲ့ အားသာချက်တွေကိုလည်း ရယူနိုင်တဲ့အတွက်ဖြစ်ကြောင်း ဖော်ပြလိုက်ရပါတယ်။

Building A Note Taking App with TinyMVC

လွန်ခဲ့တဲ့ရက်အချို့က TinyMVC လို့ခေါ်တဲ့ PHP micro Framework တစ်ခုကို မိတ်ဆက် ပေးခဲ့ပါတယ်။ အခု.. အဲ့ဒီ Framework ကိုသုံးပြီး တည်ဆောက်ထားတဲ့ Note Taking App လေးတစ်ခုအကြောင်းကို ဖော်ပြပေးချင်ပါတယ်။ ရှေ့ဆက်မပြောခင်မှာ Source Code ကို ကြိုတင်ရယူလိုတယ်ဆိုရင် Download ရယူနိုင်ပါတယ်။ လက်တွေ့အရင် စမ်းကြည့်ချင်တယ်ဆိုရင်လည်း Demo တင်ထားပေးပါတယ်။

ဒီ Note Taking Application ကို တည်ဆောက်ဖို့အတွက် MVC structure နဲ့ လိုအပ်တဲ့ Routing လုပ်ဆောင်ချက်ကိုတော့ TinyMVC framework မှာ အသင့်ပါပြီး ဖြစ်ပါတယ်။ ဆက်လက်ပြီး multi-user အသုံးပြုနိုင်တဲ့ စနစ်တစ်ခုဖြစ်ဖို့အတွက် User Account Creation နဲ့ Signin စနစ်တစ်ခုကို တည်ဆောက်မှာဖြစ်ပါတယ်။

Creating User M-V-C

ဒါကြောင့် user အတွက် model-view-controller file များ တည်ဆောက်ပေးဖို့ လိုပါမယ်။ လိုအပ်တဲ့ file နဲ့ directory တွေ တည်ဆောက်ပြီးပြီဆိုရင်တော့ file structure က အခုလိုပုံစံ ဖြစ်နေမှာပါ။

tinynote/
|-- models/
|   |-- user.php [user model]
|-- views/
|   |-- user/ [user views]
|   |   |-- signin.php
|   |   |-- 404.php
|-- controllers/
|   |-- user.php [user controller]
+-- includes/
+-- data/
+-- template/
|-- index.php
|-- router.php
|-- config.php
|-- 404.php

ပထမဦးဆုံး controllers/user.php ထဲမှာ ဘယ် action ဆိုရင် ဘာအလုပ်လုပ်ရမယ်ဆိုတဲ့ သတ်မှတ်ချက်တွေကို အရင်သတ်မှတ်ပေးရမှာပါ။

switch($action) {
  case "":
  case "signin":
  case "signin-failed":
  case "create-failed":
    show_signin();
    break;
  case "try-signin":
    try_signin();
    break;
  case "account":
    show_account();
    break;
  case "signout":
    signout();
    break;
  default:
    show_404();
}

action က blank, signin, singin-failed, create-failed တို့ထဲက တစ်ခုခုဖြစ်မယ်ဆိုရင် show_signin() function ကို အလုပ်လုပ်မှာဖြစ်ပါတယ်။ တနည်းအားဖြင့် Request URL က user/ သို့မဟုတ် user/signin သို့မဟုတ် user/signin-failed သို့မဟုတ် user/create-failed ဘာပဲလာလာ show_signin() function မှာ သတ်မှတ်ထားတဲ့ အလုပ်တွေကိုပဲ လုပ်မယ်ဆိုတဲ့သဘောဖြစ်ပါတယ်။ ကျန်တဲ့ action တွေကိုလည်း သင့်တော်တဲ့ function တွေနဲ့ တွဲဖက်ပေးထားပါတယ်။ Request URL က တွဲဖက်ပေးထားတဲ့ action တစ်ခုနဲ့မှမကိုက်ညီရင်တော့ show_404() function ကို အလုပ်လုပ်ဖို့ သတ်မှတ်ထားတာဖြစ်ပါတယ်။

function show_signin() {
  if(is_auth()) {
    redirect("home");
  }

  render("signin");
}

show_signin() function က လက်ရှိ အသုံးပြုသူဟာ sigin ဝင်ထားပြီးသားသူ ဖြစ်နေမလား စစ်ပါတယ်။ ဟုတ်တယ်ဆိုရင် login page ကို ပြမနေတော့ပဲ home/ ကိုပဲ redirect() လုပ်သွားဖို့ သတ်မှတ်ထားတာ ဖြစ်ပါတယ်။ sigin မဝင်ထားသူဆိုရင်တော့ signin template ကို ဖော်ပြပေးမှာဖြစ်ပါတယ်။ Framework function တစ်ခုဖြစ်တဲ့ render() က signin template ဖြစ်တဲ့ views/user/signin.php ကို main template ဖြစ်တဲ့ template/index.php မှာ အလိုအလျှောက် တွဲဖက်ပြီး ဖော်ပြပေးသွားမှာ ဖြစ်ပါတယ်။

code တွေကိုတော့ ဒီနေရာမှာ အကြမ်းဖျဉ်းပဲ ဖော်ပြပေးပါမယ်။ အပြည့်အစုံကိုတော့ Source Code Download ရယူပြီး လေ့လာနိုင်ပါတယ်။

signin template file ထဲမှာတော့ signin form နဲ့ create account form နှစ်ခုစလုံးကို tab control တစ်ခုနဲ့ တွဲထည့်ပေးထားပါတယ်။ အဲ့ဒီ tab control က Framework နဲ့အတူ တွဲထည့်ပေးထားတဲ့ Twitter Bootstrap CSS Framework ရဲ့ လုပ်ဆောင်ချက်ကို အသုံးပြုထားတာဖြစ်လို့ ကျွန်တော်တို့ ဘာမှ အများကြီးရေးဖို့မလိုပါဘူး။ Twitter Bootstrap က သတ်မှတ်ထားတဲ့အတိုင်း HTML structure တည်ဆောက်ပြီး သတ်မှတ်ထားတဲ့ class တွေ သတ်မှတ်ပေးယုံပဲဖြစ်ပါတယ်။

Twitter Bootstrap အကြောင်းကို အသေးစိတ် သိရှိလိုရင်တော့ ကျွန်တော်တို့ရေးဖူးထဲ Article တစ်ခုမှာ လေ့လာနိုင်သလို.. မူရင်း Site မှာလည်း သွားရောက် လေ့လာနိုင်ပါတယ်။

MVC pattern အရ Data နဲ့ပက်သက်တဲ့ ကိစ္စတွေဟာ Model ထဲမှာ ရှိရမှာဖြစ်ဖို့ models/user.php ထဲမှာ Database နဲ့ တွဲဖက်လုပ်ရမယ့်အလုပ်တွေကို ရေးသားထားပြီး controller နဲ့ view ကနေ လိုအပ်သလို ခေါ်ယူအသုံးပြုမှာဖြစ်ပါတယ်။

function check_auth($email, $password) {
  $db = new Database();

  $password = md5($password);
  $result = $db->get_query("SELECT * FROM users
            WHERE email='$email' AND password='$password'");

  if($result) {
    set_auth($result[0]['id']);
    return true;
  }

  return false;
}

function update_name($name) {
  $db = new Database();

  $user = get_user_data();
  $id = $user['id'];
  $result = $db->set_query("UPDATE users SET
            name='$name' WHERE id=$id");

  return $result;
}

အခုနမူနာဖော်ပြပေးထားတာက user model ထဲက function နှစ်ခု ဖြစ်ပါတယ်။ controller က request တွေကို handle လုပ်မှာဖြစ်လို့ User က signin form မှာ email နဲ့ password ရိုက်ထည့်လိုက်ရင် အဲ့ဒီ တန်ဖိုးတွေက controller ဆီကို try-signin ဆိုတဲ့ action အနေနဲ့ ရောက်ရှိမှာဖြစ်ပါတယ်။ controller က ရရှိလာတဲ့တန်ဖိုးကို ကိုယ်တိုင်မစစ်ပါဘူး။ model ထဲမှာ ရေးထားတဲ့ check_auth() function ကို လှမ်းခေါ်ပြီး စစ်ခိုင်းပါတယ်။ ဒီနည်းနဲ့ controller က request တွေကို handle လုပ်ပြီး၊ တစ်ကယ်လုပ်ရမယ့်အလုပ်ကို model က လုပ်ပေးပြီး လုပ်ငန်းတာဝန်ကို ခွဲခြား ရေးသားထားနိုင်မှာဖြစ်ပါတယ်။

model က sigin အချက်အလက်တွေ မှန်မမှန် အကြောင်းပြန်ပါတယ်။ controller က အကြောင်းပြန်ချက်ပေါ်မူတည်ပြီး.. မှန်တယ်ဆိုရင် signin ခွင့်ပြုပါတယ်။ မမှန်ဘူးလို့ model က ပြောလာရင်တော့ user/signin-failed ကို redirect လုပ်ပေးခြင်းဖြင့် user ကို signin failed ဖြစ်ကြောင်း အသိပေးပါတယ်။ signin template ထဲမှာတော့ အကယ်၍များ လက်ရှိအလုပ်လုပ်နေတဲ့ action က signin-failed ဖြစ်နေမယ်ဆိုရင် user ကို alert message ဖော်ပြပေးဖို့ အခုလို ရေးသားထားပေးပါတယ်။

<? if($action == "signin-failed"): ?>
<div class="alert">
  <button type="button" class="close" data-dismiss="alert">×</button>
  <strong>Sign in failed!</strong> email address or password invalid.
</div>

ဒီနည်းအတိုင်းပဲ Account Create လုပ်တဲ့ process ကိုလည်း user model-view-controller ထဲမှာပဲ သင့်တော်သလို ခွဲခြားရေးသားထားတာ ဖြစ်ပါတယ်။

Creating Home M-V-C

ဆက်လက်ပြီး Note တွေ စီမံဖို့အတွက် User Interface ကို တည်ဆောက်မှာဖြစ်ပါတယ်။ ဒီနေရာမှာ နှစ်ပိုင်းခွဲထားပါတယ်။ Note တွေစီမံနိုင်မယ့် UI ကို အသားပေးတဲ့ MVC ကို home MVC အဖြစ်တည်ဆောက်မှာဖြစ်ပြီး၊ အမှန်တစ်ကယ် အလုပ်လုပ်တဲ့ အပိုင်းကိုတော့ note MVC အဖြစ် သီးခြားတည်ဆောက်မှာ ဖြစ်ပါတယ်။ home MVC files တွေ တည်ဆောက်ပြီးနောက်မှာ file structure က အခုလို ရရှိမှာ ဖြစ်ပါတယ်။

tinynote/
|-- models/
|   |-- user.php
|   |-- home.php [home model]
|-- views/
|   +-- user/
|   |-- home/ [home views]
|   |   |-- home.php
|   |   |-- 404.php
|-- controllers/
|   |-- user.php
|   |-- home.php [home controller]
+-- includes/
+-- data/
+-- template/
|-- index.php
|-- router.php
|-- config.php
|-- 404.php

home မှာတော့ UI အဓိကဖြစ်လာတဲ့အတွက် Javascript တွေ အများအပြား ရေးသားရမှာဖြစ်ပါတယ်။ လိုအပ်တဲ့ Javascript Plugins တွေကိုလည်း ထည့်သွင်းရမှာဖြစ်ပါတယ်။ Plugins တွေကို သက်ဆိုင်ရာ home template မှာ ရွေးထည့်မနေတော့ပဲ main template ဖြစ်တဲ့ template/index.php မှာသာ ထည့်သွင်းပါတယ်။ ဒါမှသာ မည်သည့် view template ကမဆို ဒီ Plugins တွေကို ရယူအသုံးပြုနိုင်မှာဖြစ်ပါတယ်။

<?= include_js("jquery.js") ?>
<?= include_js("jquery.validate.js") ?>
<?= include_js("jquery.glow.js") ?>

<?= include_js("bootstrap.js") ?>
<?= include_js("wysihtml5.js") ?>
<?= include_js("bootstrap-wysihtml5.js") ?>

<?= include_js("app.js") ?>

template/index.php မှာ Framework function တစ်ခုဖြစ်တဲ့ include_js() ကိုသုံးပြီး အသုံးပြုလိုတဲ့ Javascript file အားလုံးကို ထည့်သွင်းထားပါတယ်။ Form validation တွေအတွက် jquery.validate plugin, Note တွေကို update လုပ်လိုက်ရင် effect ဖြစ်သွားကြောင်း flash လုပ်ပြီး ဖော်ပြဖို့အတွက် jquery.glow plugin, Twitter Bootstrap ရဲ့ dialog box တွေနဲ့ tab control တွေကို အသုံးပြုနိုင်ဖို့ bootstrap plugin, Note တွေကို Edit လုပ်ရတာ လွယ်ကူစေဖို့ Rich Tech Editor (wysihtml5) plugin, အဲ့ဒီ RTE plugin ကို Twitter Bootstrap နဲ့ လိုက်ဖက်အောင် တွဲဖက်ပေးတဲ့ bootstrap-wysihtml5 plugin စသဖြင့် အသုံးပြုလိုတဲ့ Plugins အားလုံးကို ထည့်သွင်းပေးပါတယ်။ template/js/ directory အောက်ကို သွားကြည့်မယ်ဆိုရင်လည်း script files တွေအားလုံးကို အသင့်ထည့်သွင်းထားတာကို တွေ့ရမှာပါ။ app.js ကတော့ ကျွန်တော်တို့ ကိုယ်တိုင်ရေးသားတဲ့ Note Mangement နဲ့ ပက်သက်တဲ့ script တွေ form validation နဲ့ ပက်သက်တဲ့ script တွေ၊ အားလုံးပါဝင်မှာ ဖြစ်ပါတယ်။ အမှန်တော့ အဓိက view template ဖြစ်တဲ့ views/home/home.php ထဲမှာ ဘာမှ ထွေထွေထူးထူး မရှိပါဘူး။ အခြေခံ HTML structure ပဲရှိတာပါ။ တစ်ကယ့် အလုပ်တွေက js/app.js ထဲမှာ Javascript နဲ့ ရေးသားထားတာ ဖြစ်ပါတယ်။

Creating Note M-V-C

Note တွေစီမံခြင်းနဲ့ ပက်သက်တဲ့ အဓိက Server-Side လုပ်ဆောင်ချက်တွေကို note MVC မှာ ရေးသားထားတာဖြစ်ပါတယ်။ MVC လို့ပြောပေမယ့် အမှန်တော့ view မပါပါဘူး။ UI က home မှာ တည်ဆောက်ထားပြီး အဲ့ဒီ home UI က note ရဲ့ လုပ်ဆောင်ချက်တွေကို Ajax Request တွေနဲ့ ဆက်သွယ်ရယူတာဖြစ်ပါတယ်။ file structure က အခုလို ရရှိလာမှာ ဖြစ်ပါတယ်။

tinynote/
|-- models/
|   |-- user.php
|   |-- home.php
|   |-- note.php [note model]
|-- views/
|   +-- user/
|   +-- home/
|-- controllers/
|   |-- user.php
|   |-- home.php
|   |-- note.php [note controller]
+-- includes/
+-- data/
+-- template/
|-- index.php
|-- router.php
|-- config.php
|-- 404.php

note controller ဖြစ်တဲ့ controllers/note.php က ထုံးစံအတိုင်း note နဲ့ ပက်သက်တဲ့ request action တွေကို ခုလို စီစဉ်ပေးပါတယ်။

if(!is_auth()) redirect("user/signin");

switch($action) {
  case "all":
    get_all();
    break;
  case "new":
    new_note();
    break;
  case "update":
    update_note();
    break;
  case "delete":
    delete_note();
    break;
  case "send":
    send_note();
    break;
  default:
    invalid_request_error();
}

function get_all() {
  $result = get_notes();
  echo json_encode($result);
}

function new_note() {
  $result = add_note();

  if($result) {
    echo json_encode(array(
      "err" => 0,
      "id" => $result
    ));
  } else {
    echo json_encode(array(
      "err" => 1,
      "msg" => "Unable to add new note!"
    ));
  }
}

ပထမဦးဆုံး Signin လုပ်ထားသူဟုတ်မဟုတ် စစ်ပါတယ်။ Signin လုပ်ထားသူမဟုတ်ရင် note controller က request action အားလုံးကို ငြင်းပယ်ပြီး Signin page ကို redirect လုပ်ပေးမှာဖြစ်ပါတယ်။

ဒီ note controller အပြည့်အစုံကို လေ့လာကြည့်ရင် view template ကို render လုပ်ခိုင်းတဲ့ ညွန်ကြားမှု တစ်ခုမှ မပါတာကို တွေ့ရပါလိမ့်မယ်။ တနည်းအားဖြင့် note controller က view template ဖော်ပြဖို့ design လုပ်ထားတာမဟုတ်ပဲ Ajax request တွေကို သင့်တော်သလို့ respond ပြန်လုပ်ပေးဖို့သာ design လုပ်ထားတာဖြစ်ပါတယ်။

Wrapping Up

အချို့သော အချက်လေးတွေကို ဖြည့်စွက်လိုက်မယ်ဆိုရင် ဒီ App ဟာ Fully Funtional ဖြစ်ဖို့ သိပ်မလိုတော့ပါဘူး။ ဥပမာ – User Account တွေမှာ Password တွေ Update လုပ်နိုင်တဲ့ လုပ်ဆောင်ချက်မျိုး ထည့်သွင်းပေးထားပေမယ်.. Forget Password လို လုပ်ဆောင်ချက်မျိုးတော့ မပါဝင်သေးပါဘူး။ တစ်ချို့ Note တွေကို ကိုယ်တိုင်ဆီကိုပဲဖြစ်ဖြစ်၊ တစ်ခြားသူတစ်ယောက်ယောက် ဆီကိုပဲဖြစ်ဖြစ် Email အနေနဲ့ ပေးပို့နိုင်တဲ့ လုပ်ဆောင်ချက်မျိုးလည်း ပါဝင်ပါသေးတယ်။ ဒါပေမယ့် Note တွေအားလုံးကို Export/Import လုပ်ယူနိုင်တဲ့ လုပ်ဆောင်ချက်တွေ၊ Email ပို့ပြီး Note ကို Post လုပ်နိုင်တဲ့ လုပ်ဆောင်ချက်မျိုးတွေတော့ မပါဝင်သေးပါဘူး။ Small Screen Device တွေမှာပါ အဆင်ပြေပြေ အလုပ်လုပ်အောင် ထည့်သွင်းထားပေမယ့်၊ Mobiel App နဲ့ တွဲဖက်နိုင်တဲ့ API model တော့ မပါဝင်သေးပါဘူး။

ဆက်လက် improve လုပ်လိုသူများ လွပ်လပ်စွာ ရယူပြင်ဆင်ခြင်း၊ ပြန်လည်ဖြန့်ဝေခြင်း ပြုလုပ်နိုင်ပါတယ်။ MIT license သုံးပြီး open source သတ်မှတ်ပေးထားပါတယ်။ အနည်းဆုံးတော့ TinyMVC framework ကို လေ့လာတဲ့နေရာမှာ နမူနာရပြီး အထောက်အကူဖြစ်စေမယ်လို့ မျှော်လင့်ပါတယ်။

View Demo | Download Source Code

ကျေးဇူးတင်ပါတယ်။

TinyMVC – PHP Micro Framework

PHP ဟာ Programming Language သက်သက်ဖြစ်လို့ အမှန်တစ်ကယ် Production သွားမယ့် Application တွေမှာ Framework တွေ အသုံးပြုဖို့ လိုနိုင်ပါတယ်။ Framework ဆိုတဲ့နေရာမှာ Zend Framework, CakePHP, Symfony, Codeigniter, Laravel, FuelPHP တို့လို Full-Fledge Framework တွေ ရှိသလို၊ F3 Framework, SlimPHP တို့လို Micro Framework တွေလည်း ရှိပါတယ်။ အခြားအခြားသော Framework တွေ များစွာရှိသေးလို့ တစ်ခါတစ်ရံမှာ ရွေးရခက်လို့တောင် စိတ်ညစ်ရနိုင်ပါတယ်။

Framework တွေက MVC လို Maintainable Structure တွေနဲ့ တည်ဆောက် အသုံးပြုနိုင်အောင် စီစဉ်ပေးထားလေ့ ရှိပါတယ်။ Security နဲ့ ပက်သက်တဲ့ လုပ်ဆောင်ချက်တွေ၊ Performance Optimization နဲ့ ပက်သက်တဲ့ လုပ်ဆောင်ချက် တွေကိုလည်း ဆောင်ရွက်ပေးတဲ့အတွက် Developer က ကိုယ့် Application ကိုသာ Focus လုပ်နိုင်စေမှာ ဖြစ်ပါတယ်။ ဒါ့အပြင် Messaging နဲ့ Logging လို့ Utility ပိုင်း လုပ်ဆောင်ချက်တွေ၊ Authentication နဲ့ Validation လို့ အမြဲတမ်းလိုအပ်တဲ့ လုပ်ဆောင်ချက်တွေ၊ Grid Control နဲ့ Reporting Control လို့ Components တွေနဲ့ ပေါင်းစပ်ပြီး လိုလေးသေးမရှိအောင် အသင့် ဖန်တီးပေးထားလေ့ ရှိပါတယ်။

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

Tiny Framework

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

တစ်ခြား Full-Fledge Framework တွေမှာလို MVC Pattern, Build-In Authentication, Database Wrapper, Security, Caching & Optimization, Messaging, Controls, Mailer, Scaffold Generator စသဖြင့် လုပ်ဆောင်ချက် အစုံပါဝင်တဲ့ Framework တစ်ခုဖြစ်ပါတယ်။ အမှန်တော့ Ruby on Rails ကို လေ့လာပြီး PHP နဲ့ လိုက်လံတုပထားတဲ့ Framework လို့လည်း ပြောနိုင်ပါတယ်။

နာမည်ကြီး Open Source Framework တွေ အများကြီး ရှိတဲ့ကြားထဲက ကိုယ်ပိုင် Framework တစ်ခု တည်ဆောက်အသုံးပြရခြင်း အကြောင်းရင်းများစွာ ရှိပါတယ်။ အဓိကတစ်ချက်ကတော့ “လေ့လာရ အထူးလွယ်ကူစေဖို့” ဖြစ်ပါတယ်။ Framework တွေရဲ့ အဓိကအားနည်းချက်က သူတို့ကို လေ့လာဖို့ Learning Curve တစ်ခုရှိခြင်းပါပဲ။ အချိန်ပေးရပါတယ်။ ကျွန်တော်တို့ဆီမှာက ဝန်ထမ်းဆိုတာ အမြဲဝင်ထွက်နေတက်တော့ အသစ်တစ်ယောက်လာတိုင်း Team က သုံးချင်တဲ့ Framework ကို ကျွမ်းကျင်ဖို့ လနဲ့ချီအချိန်ပေးနေရရင် မဟန်ပါဘူး။ အချိန်တိုအတွင်း မြန်မြန်ဆန်ဆန် လေ့လာလို့ ရရမယ်.. Developer တစ်ယောက်နဲ့တစ်ယောက် Project တွေ Handover လုပ်တဲ့အခါမှာလည်း လွယ်ကူမြန်ဆန်ရမယ် စသဖြင့် လိုအပ်ချက်လေးတွေ ရှိပါတယ်။

အမှန်တော့ Ruby တို့ Python တို့လို Language တွေကို အသုံးပြုချင်ပေမယ့် PHP ကိုပဲ တစ်စိုက်မတ်မတ် သုံးနေရခြင်း အကြောင်းရင်းကလည်း လေ့လာရလွယ်ကူခြင်းက အဓိကအချက်ဖြစ်ပါတယ်။ Tiny Framework က အတက်နိုင်ဆုံး ရိုးစင်းအောင်.. မလိုအပ်တဲ့ Feature တွေ မထည့်ပဲ.. မဖြစ်မနေ ပါဝင်ရမယ့် လုပ်ဆောင်ချက်တွေကိုသာ ထည့်သွင်းထားတဲ့ Framework ဖြစ်လို့ ကျွန်တော်ကိုယ်တိုင် ရှင်းပြမယ်ဆိုရင် Developer တစ်ယောက်ဟာ တစ်ရက် နှစ်ရက်အတွင် ကောင်းကောင်း အသုံးပြုနိုင်မှာဖြစ်ပါတယ်။ ကိုယ်တိုင်ဖန်တီးထားတော့ အတွင်းကျကျသိနေတဲ့အတွက် Project လုပ်နေရင်း Framework အကန့်အသတ်ကြောင့် ကြုံလာတဲ့ ပြဿနာတိုင်းကိုလဲ အလွယ်တစ်ကူ ကျော်လွားသွားနိုင်ပါတယ်။ လက်တွေ့အလုပ်လုပ်နေသူတိုင်း နည်းပညာနဲ့ Application Logic ကြောင့်မဟုတ်ပဲ အသုံးပြုနေတဲ့ Framework နဲ့ Tool ကြောင့် တစ်ချို့နေရာတွေမှာ အကြပ်တွေ့ကြရတာမျိုးကို ကြုံဖူးမှာပါ။

Modern App

အခုနောက်ပိုင်းမှာ application တွေရဲ့ တည်ဆောက်မှုပိုင်းက သိသိသာသာ ပြောင်းလဲလာပါတယ်။ Application တွေရဲ့ Core Logic က လွန်ခဲ့တဲ့နှစ်များကလို့ Server-Side မှာ တည်ရှိတာမဟုတ်တော့ပဲ၊ Client-Side ကို ရောက်လာပါတယ်။ Web Browser တွေရဲ့တိုးတက်လာမှု့နဲ့ Mobile Device တွေ မျိုးစုံပေါ်ထွက်လာခြင်းကြောင့် ဖြစ်ပါတယ်။

Server-Side ဆိုတာဟာ Data ကို API နဲ့ Support လုပ်ပေးတဲ့ လုပ်ဆောင်ချက်လောက်ကိုသာ အဓိကအသုံးပြုလာပြီး၊ Application ရဲ့ အဓိကလုပ်ဆောင်ချက်တွေက Web Browser တွေနဲ့ Mobile App တွေဘက်ကို ရောက်ရှိလာတာဖြစ်ပါတယ်။ ဒါကြောင့် Server-Side ဘက်မှာ ရှိနေတဲ့ Structure နဲ့ Component တွေ မလိုအပ်တော့ပဲ Client-Side MVC Framework တွေအနေနဲ့ Client-Side ဘက် လိုအပ်ချက် ဖြစ်လာပါတယ်။ တနည်းအားဖြင့်.. ပြည့်စုံလှပါတယ်ဆိုတဲ့ Server-Side Framework တွေရဲ့ လုပ်ဆောင်ချက်အချို့ဟာ မလိုအပ်တော့ပဲ.. အပိုသက်သက်ဖြစ်လာပါတယ်။

Server-Side အတွက်ဆိုရင် Micro Framework တွေက ပိုပြီးအသုံးတည့်လာတဲ့ သဘောလည်း ဖြစ်ပါတယ်။ အမှန်တော့ ဒီလိုရည်ရွယ်ချက်နဲ့ ဖန်တီးထားတဲ့ PHP Micro Framework တွေကို လက်ရှိမှာ တစ်ပုံကြီး ရှိနေပါတယ်။ ဒါပေမယ့်လည်း.. ကျွန်တော့်အနေနဲ့ကတော့ ကိုယ်တိုင်အတွင်းကျကျသိတဲ့ Framework တစ်ခုကိုသာ ပိုပြီးလိုချင်ပါတယ်။

TinyMVC – Micro Framework

ဒါကြောင့်.. Tiny Framework ကို နှစ်ပိုင်းခွဲရဖို့ ဖြစ်လာပါတယ်။ Client-Side Javascript App Framework နဲ့ Server-Side API Framework ဆိုပြီး ခွဲထုတ်ဖို့ လိုအပ်လာပါတယ်။

ပထမအဆင့်အနေနဲ့ မူလ Framework ကို Minimize လုပ်ပြီး Simple MVC Router အဖြစ် ပြောင်းလဲလိုက်ပါတယ်။ အမှန်တော့ API အတွက်ဆိုရင် MVC Pattern ကို ဆက်ပြီးသုံးနေဖို့တောင် မလိုအပ်ပါဘူး။ အထူးသဖြင့် View က API ရဲ့ အလုပ်မဟုတ်တဲ့အတွက် မလိုအပ်တော့ပါဘူး။ Data Model တည်ဆောက်ခြင်း၊ Methods နဲ့ Action တွေ စီမံခြင်းကသာ အဓိကလိုအပ်ချက်ဖြစ်မှာဖြစ်ပါတယ်။ ဒါပေမယ့်လည်း အခုချိန်မှာ ရိုးရိုး View Template အခြေပြု Application တွေကိုလည်း လုံးလုံးပြစ်ပယ်လို့တော့ မရသေးပါဘူး။ ဒါကြောင့် ရှုပ်ထွေးတဲ့ကိစ္စတွေဖယ်ထုပ်ပြီး MVC Router ကိုတော့ လိုအပ်ရင်အသုံးပြုနိုင်အောင် ပြန်လည်ထည့်သွင်းရတာ ဖြစ်ပါတယ်။

အခုဆိုရင် ပြည့်စုံပြီလို့ မပြောနိုင်သေးပေမယ့်.. အခြေခံလိုအပ်ချက်တွေ ရရှိနေပြီဖြစ်တဲ့ ဒီ Micro Framework လေးကို အများရယူအသုံးပြုနိုင်ဖို့ Github မှာ တင်ထားပေးပါတယ်။ MIT License နဲ့ Open Source အဖြစ် ပေးထားတာဖြစ်လို့ မည်သူမဆို လွပ်လွပ်လပ်လပ် ရယူ၊ ပြင်ဆင်၊ အသုံးပြုနိုင်ပါတယ်။

အတက်နိုင်ဆုံး ရိုးရှင်းအောင်ဖန်တီးထားလို့ README လေးဖတ်ပြီး Source Code ကို အနည်းငယ်လေ့လာယုံနဲ့ MVC Framework တွေနဲ့ ရင်းနှီးပြီးသူများ အလွယ်တစ်ကူ အသုံးပြုနိုင်လိမ့်မယ်လို့ မျှော်လင့်ပါတယ်။ အသုံးပြုပုံအသေးစိတ်ကိုတော့ နောက် Article တစ်ခုနဲ့ ဆက်လက်ဖော်ပြပေးပါမယ်။

အရင် Tiny Framework အပြည့်အစုံတုန်းကလည်း Open Source လုပ်ဖို့ အကြိမ်ကြိမ်ကြိုးစားခဲ့ပေမယ့် Documentation သပ်သပ်ရပ်ရပ် မလုပ်နိုင်တာရယ်၊ Community တစ်ခုဖြစ်အောင် ကြိုးစားဖော်ဆောင်ဖို့ အချိန်မပေးနိုင်တာရယ်ကြောင့် မလုပ်ဖြစ်တာဖြစ်ပါတယ်။ ဒီ Micro Framework ကိုတော့ အလားတူကိစ္စတွေကြောင့် ဆိုတာမျိုးမဖြစ်ရလေအောင် အခုကတည်းက စောစောစီးစီး  Release လုပ်လိုက်တာပဲ ဖြစ်ပါတယ်။

ကူညီပြီး Improve လုပ်ချင်တာပဲဖြစ်ဖြစ်.. ပါဝင် Contribute လုပ်လိုတာပဲဖြစ်ဖြစ်… အကြံပြုလိုတာများကိုပဲဖြစ်ဖြစ် ကြိုဆိုပါတယ်။ Github ဟာ Social Coding Platform တစ်ခုဖြစ်လို့ ပူးပေါင်းပါဝင်လိုသူများ အချိန်မရွေး ပါဝင်ကူညီနိုင်ကြောင်း ပြောချင်ပါတယ်။

Visit TinyMVC Github Page

ကျေးဇူးတင်ပါတယ်။

Resolve a Malware Infected Website

သင့်ရဲ့ Website ကို ဖွင့်ကြည့်လိုက်လို့  အခုလို Warning မျိုး တက်နေပြီဆိုရင်.. Website မှာ Malware Infect ဖြစ်နေပြီဆိုတဲ့သဘော ဖြစ်ပါတယ်။

သင့်ရဲ့ Website ထဲမှာ အသုံးပြုသူတွေအတွက် အန္တရာယ်ရှိနိုင်တဲ့ Script တွေကို သင့်မသိလိုက်ပဲ Attacker က ထည့်သွင်းသွားတဲ့သဘော ဖြစ်ပါတယ်။ တနည်းအားဖြင့် Attacker က သင့် Website ကို Full Control ရနေပြီဖြစ်လို့ အခုလို ထည့်သွင်းနိုင်တာလည်း ဖြစ်ပါတယ်။ Deface အလုပ်ခံရသကဲသို့ ဆိုးရွားတဲ့ လုံခြုံရေး ပေါက်ထွက်မှုတစ်ခု ဖြစ်ပါတယ်။

Google လို Search Engine တွေမှာ Malware နဲ့ အခြား အန္တရယ်ရှိ Script တွေကို Detect လုပ်တဲ့ စနစ်တွေ ရှိတဲ့အတွက် သင့် Website မှာ အခုလို Malware Infect ဖြစ်နေပြီဆိုတာကို သိနိုင်ပါတယ်။ ဒါ့အပြင် အသုံးပြုသူတွေက သတိထားမိရင်လည်း Report လုပ်နိုင်ပါတယ်။ ဒီလို Attack Site အနေနဲ့ Report လုပ်လာပြီဆိုတာနဲ့ Google က သင့် Website ကို Black List လုပ်လိုက်မှာဖြစ်ပါတယ်။ လုံခြုံရေးအလေးထားတဲ့ Mozilla Firefox လို့ Web Browser တွေ Google Chrome လို Web Browser နဲ့ ဝင်ကြည့်မယ်ဆိုရင် Web Browser တွေက  Black List လုပ်ခြင်း ခံထားရတဲ့ Website တွေကို ဝင်မကြည့်ဖို့ အထက်ကပုံမှာ ဖော်ပြထားသလို Warning တွေ ပေးမှာဖြစ်ပါတယ်။

ဒီလိုပြဿနာမျိုး ကြုံတွေ့လာရရင် ဖြေရှင်းရမယ့် အဆင့်တွေကို ဖော်ပြပေးပါမယ်…

၁.) ပထမဦးဆုံး စိတ်အေးအေးထားပြီး သင့် Website နဲ့ ဆက်စပ်နေတဲ့ Password အားလုံးကို အသစ်ပြောင်းထားသင့်ပါတယ်။ FTP, cPanel, Database, Site Admin စသဖြင့် ဆက်စပ် Password အားလုံးကို ပြောင်းရမှာဖြစ်ပါတယ်။

၂.) ဒီလို Malware မျိုးက Database တွေကို တိုက်ခိုက်လေ့မရှိပါဘူး။ ဒါကြောင့် အကြမ်းဖျင်းအားဖြင့်.. Database ထဲက အချက်အလက်တွေကတော့ Password ပြောင်းထားလိုက်ရင် လုံခြုံနေသေးတယ်လို့ ဆိုနိုင်ပါတယ်။

၃.) Malware က အန္တရယ်ရှိတဲ့ Script တွေကို သင့် Website File တွေထဲမှာ ရောညှပ်ထည့်သွင်းသွားမှာ ဖြစ်သလို့၊ သီးခြား Script File တွေ အနေနဲ့လည်း ဖန်တီးသွားဦးမှာ ဖြစ်ပါတယ်။ အဲ့ဒီဖိုင်တွေက တစ်ကယ့်အစစ်အမှန် File တွေလို ဟန်ဆောင်နေမှာဖြစ်လို့ တစ်ခုချင်းရှာပြီး ရှင်းဖို့မှာ အတော်လေး ခက်ပါတယ်။ ဥပမာ – WordPress CMS သုံးထားတဲ့ Website မှာဆိုရင် Malware က wp-count.php, wp-apps.php စသဖြင့် WordPress မှာ အမှန်တစ်ကယ်လိုအပ်တဲ့ File လို့ ထင်ရအောင် Script File တွေကို ရုပ်ဖျက်ပြီး အမည်ပေးထားမှာ ဖြစ်ပါတယ်။ ဒါကြောင့် Script File တွေကို တစ်ခုချင်း ရှာဖွေရှင်းလင်းတာမျိုး လုပ်မနေသင့်ပါဘူး။ အကုန်ရှင်းနိုင်ဖို့ ခက်ပါတယ်။ ရှိသမျှ File အားလုံးကို ဖျက်ချပြီး.. Website တစ်ခုလုံး အစအဆုံးပြန်တင်ခြင်းကသာ စိတ်အချရဆုံး နည်းလမ်းဖြစ်ပါတယ်။ အစကတည်းက လုံခြုံရေးမပေါက်အောင် ဂရုစိုက်ရပြီး.. ပေါက်သွားပြီဆိုရင်တော့ အခုလို အလုပ်ရှုပ်ရတော့တာပါပဲ။

၄.) Website ကို ဖျက်ချပြီး အစအဆုံးပြန်တင်လိုက်ပြီဆိုရင် အကြမ်းဖျင်းအားဖြင့် Infect ဖြစ်နေတဲ့ Malware Script တွေအားလုံး ရှင်းသွားမှာ ဖြစ်ပါတယ်။ ဒါပေမယ့် Google ကတော့ သူရဲ့ Black List ထဲက သင့် Website ကို အလိုလို ပြန်ထုပ်ပေးမှာ မဟုတ်ပါဘူး။ ဒါကြောင့် Google Web Master Tools မှာ သင့် Website ကို မှတ်ပုံတင်ပြီး “Maleware Scan Request” လုပ်ပေးဖို့ လိုအပ်မှာဖြစ်ပါတယ်။

၅.) Maleware Scan Request က ရလဒ်ပြန်ရဖို့ အချိန် (၂၄) နာရီခန့် ကြာမြင့်မှာဖြစ်ပါတယ်။ Google က သင့် Website ကို Scan လုပ်ကြည့်လိုက်လို့ Clean ဖြစ်တယ်ဆိုရင် အလိုအလျှောက် Black List ထဲကနေ ပြန်ထုပ်ပေးသွားမှာဖြစ်လို့ သင့် Website လည်း ပုံမှန်အတိုင်း အလုပ်ပြန်လုပ်သွားမှာ ဖြစ်ပါတယ်။ ဒါပေမယ့် Google က Malware ရှိနေသေးကြောင်း တွေ့တယ်ဆိုရင်တော့ သင့်ကို ဘယ် Page တွေမှာ Maleware ရှိနေပါတယ်ဆိုတဲ့ Report ကို ပြန်ပေးမှာ ဖြစ်ပါတယ်။ Black List ထဲကလည်း ထုပ်ပေးဦးမှာ မဟုတ်ပါဘူး။

၆.) လက်ရှိ Infect ဖြစ်နေတဲ့ Malware ကို အထက်မှာဖော်ပြထားတဲ့အဆင့်တွေအတိုင်း ရှင်းလင်းလိုက်ရင် တစ်ကြိမ်တော့ ရှင်းသွားပါလိမ့်မယ်။ ဒါပေမယ့် နောက်ထပ် ပြန်မဖြစ်တော့ဘူးလို့ ယူဆလို့ မရသေးပါဘူး။ သင့် Website မှာ ရှိနေတဲ့ လုံခြုံရေးအားနည်းချက်ကြောင့်သာ အခုလို Malware Infect ဖြစ်တာဖြစ်လို့ အဲ့ဒီ လုံခြုံရေးအားနည်းချက်ကို ရှာဖွေပြင်ဆင်နိုင်မှသာ နောက်ထပ်အလားတူ ပြဿနာမျိုး ထပ်မံမကြုံတွေ့ရမှာဖြစ်ပါတယ်။ လုံခြုံရေးအားနည်းချက် ရှာဖွေပြင်ဆင်တာကတော့ အသုံးပြုထားတဲ့ နည်းပညာ၊ ရေးသားထားပုံနည်းစနစ်နဲ့ အခြား ကိစ္စရပ်ပေါင်းများကို ထည့်သွင်းစဉ်းစားရမှာဖြစ်လို့ ပုံသေနည်းနဲ့ ပြောပြနိုင်မှာ မဟုတ်ပါဘူး။ ရှာဖွေပြင်ဆင်ဖို့က Web Developer ပေါ်မှာပဲ လုံးလုံးမူတည်နေတဲ့ တာဝန်တစ်ရပ်ဖြစ်ပါတယ်။

ဒီကိစ္စနဲ့ ပက်သက်တဲ့ အသေးစိတ်အချက်အလက်တွေ၊ အကြံပြုချက်တွေနဲ့ သိသင့်သိထိုက်တဲ့အရာတွေကို Google အပါအဝင် လုံခြုံရေးအလေးထားသူတွေက အသိအမှတ်ပြုတဲ့ StopBadWare ဆိုတဲ့ Website မှာ သွားရောက်လေ့လာနိုင်ပါတယ်။

ကျွန်တော်တို့ Website တွေကို လူဇိုးတွေရဲ့ ရန်က အကာအကွယ်ပေးမဲ့ ဥပဒေတွေ၊ ထိရောက်အောင် အရေးယူပေးမယ့် ဥပဒေတွေ မရှိသေးတဲ့အတွက် ကျွန်တော်တို့ Web Developer တွေကိုယ်တိုင်ကပဲ ကိုယ့်လုံခြုံရေးကို ကိုယ်တာဝန်ယူရမှာဖြစ်လို့ လုံခြုံရေးအသိရှိကြဖို့ နှိုးဆော်လိုက်ရပါတယ်…

ကျေးဇူးတင်ပါတယ်

You Should REST

ကျွန်တော်တို့ Web Browser ကို ဖွင့်ပြီး URL bar မှာ http://www.google.com/search?q=rest လို့ ရိုက်ထည့်လိုက်မယ်ဆိုရင်.. ခဏနေတဲ့အခါ “rest” ဆိုတဲ့ Keyword အတွက် Google Search Result ကို ရရှိမှာဖြစ်ပါတယ်။ ဒီလို URL မှာ ရိုက်ထည့်လိုက်ယုံနဲ့ Google Search Result ရလာဖို့အတွက် နောက်ကွယ်မှာ လုပ်သွားတဲ့အလုပ်တွေ အများကြီးရှိပါတယ်။ အဲ့ဒီ လုပ်ဆောင်ချက်တွေထဲက အခုကျွန်တော်တို့ပြောချင်တဲ့ REST နဲ့ ပက်သက်တဲ့ လုပ်ဆောင်ချက်တစ်ချို့ကို ပြောချင်ပါတယ်။

၁. ပထမဦးဆုံး Web Browser က ကျွန်တော်တို့ ရိုက်ထည့်လိုက်တဲ့ URL ကို HTTP Request Format အဖြစ် ပြောင်းပေးပါတယ်။

GET /search?q=rest HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 ...
...

ဒီ Format ပထမလိုင်းက GET က Request Method ဖြစ်ပါတယ်။ အချက်အလက်တွေ ရယူလိုပါတယ် ဆိုတဲ့ အဓိပ္ပါယ်ဖြစ်ပါတယ်။ ဒီလိုရယူနိုင်ဖို့အတွက် ကျွန်တော်တို့ ထည့်သွင်းပေးလိုက်တဲ့ Request Parameter က /search?q=rest ဖြစ်ပါတယ်။ HTTP/1.1 Protocol ကို အသုံးပြုမှာဖြစ်ပြီး.. Request လုပ်လိုတဲ့ Host ကတော့ www.google.com ဖြစ်ပါတယ်။

ဒီထက်အသေးစိတ်ရမယ်ဆိုရင်တော့ User-Agent အပါအဝင် တစ်ခြားအချက်အလက် တွေလည်း Request Format ထဲမှာ ပါဝင်နိုင်ပါသေးတယ်။ ဒါပေမယ့် လိုရင်းက ဘာအချက်အလက်တွေ ပါသလဲဆိုတဲ့အချက် မဟုတ်ပါဘူး။ ဒီ Request Format ဟာ လူတစ်ယောက် ဖတ်ရှုလို့ နားလည်နိုင်တဲ့ Format ဖြစ်သလို.. တစ်ပြိုင်တည်းမှာပဲ Computer ကလည်း Process လုပ်နိုင်တဲ့ Format ဖြစ်နေတယ်ဆိုတဲ့အချက် ဖြစ်ပါတယ်။

လူအတွက်ရော စက်အတွက်ပါ Representable ဖြစ်တဲ့ Format ဖြစ်ပါတယ်။ ဒါဟာ REST (REpresentational State Transfer) ရဲ့ အခြေခံအကျဆုံးအချက် ဖြစ်ပါတယ်။ HTTP Protocol ဟာ Web Server နဲ့ Client တို့ ဆက်သွယ်တဲ့အခါ အခုလို Representable ဖြစ်နေအောင် ဖန်တီးတီထွင်ထားတဲ့ Protocol တစ်ခုဖြစ်ပါတယ်။

၂. Web Browser က ကျွန်တော်တို့ရိုက်ထည့်လိုက်တဲ့ URL ကို HTTP သတ်မှတ်ချက်နဲ့အညီ Format လုပ်ပြီးနောက် အဲ့ဒီ Formatted Data ကို Remote Host ဖြစ်တဲ့ www.google.com ကို ပေးပို့လိုက် ပါတယ်။ ဒီနေရာမှာ Network ပိုင်းဖြစ်တဲ့ အသုံးပြုသွားတဲ့ Port တွေ၊ Proxy ကျော်ဖြတ်ရတာတွေ၊ DNS Look Up လုပ်တာတွေ ရှိလာပါတယ်။ ဒါပေမယ့် ကျွန်တော်တို့ အဓိကဆွေးနွေးလိုတဲ့ REST ကိုပဲ Focus လုပ်လိုတဲ့အတွက် အသေးစိတ်မပြောတော့ပါပဲ။ Formatted Request Data ဟာ Google Web Server ရောက်သွားတယ်လို့ပဲ မှတ်ယူပြီး ဆက်ပြောသွားချင်ပါတယ်။

၃. Google Web Server က Request ကို လက်ခံရရှိပြီး.. လိုအပ်တဲ့ ရှာဖွေမှုလုပ်ဆောင်ချက်  ဆောင်ရွက်ပြီးတာနဲ့ Search Result ကို ပြန်ပို့ပေးမှာ ဖြစ်ပါတယ်။ အဲ့ဒီလို့ ပြန်ပို့ပေးတဲ့အခါမှာလည်း HTTP က သတ်မှတ်ထားတဲ့ Respond Format အတိုင်း ပြန်ပေးမှာဖြစ်ပါတယ်။

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Mon, 01 Oct 2012 05:17:10 GMT
X-Firefox-Spdy: 2

200 OK ဆိုတာ ပေးပို့လာတဲ့ Request ကို Google Server က လက်ခံဆောင်ရွက်ဖို့ အားလုံး အဆင်ပြေပါတယ် ဆိုတဲ့အဓိပ္ပါယ် ဖြစ်ပါတယ်။ HTTP Status Code လို့ခေါ်ပါတယ်။ တစ်ခြား Status Code တွေအနေနဲ့ 404 Not Found, 304 Not Modified, 403 Forbidden, 500 Internal Server Error စသဖြင့် ရှိဦးမှာဖြစ်ပါတယ်။

ပြန်လည်ပေးပို့လိုက်တဲ့ Search Result ကို text/html Format နဲ့ ပေးပို့လိုက်တာဖြစ်ပြီး gzip Compression သုံးပြီးတော့လည်း Compress လုပ်ပေးလိုက်ပါတယ်လို့ ဒီ Respond Header က ပြောပါသေးတယ်။ တစ်ခြား အသေးစိတ် အချက်အလက်တွေ ပါဝင်ဦးမှာဖြစ်ပေမယ့်.. အဓိက ပြောလိုတာက.. ဒီ Respond Header ကလည်း လူအတွက်ရော ကွန်ပျူတာအတွက်ပါ Representable ဖြစ်တဲ့ Format တစ်ခုဖြစ်တယ် ဆိုတဲ့အချက် ဖြစ်ပါတယ်။

HTTP Request / Respond တွေရဲ့ Header Information တွေကို Live HTTP Headers လို Browser Plugin တွေရဲ့အကူအညီနဲ့ လေ့လာနိုင်ပါတယ်။

၄. Web Browser က ပြန်လည်ရရှိလာတဲ့ Respond Header ကိုကြည့်ပြီး ပြန်လည် ပေးပို့လာတဲ့ Content ဟာ text/html ဖြစ်ကြောင်း သိရတဲ့အတွက် အဲ့ဒီ HTML ကို ကျွန်တော်တို့ ကြည့်ရှု့နိုင်အောင် Format လုပ်ပြီး ဖော်ပြပေးတဲ့အတွက် Search Result ကို ကျွန်တော်တို့ တွေ့မြင်ရတာ ဖြစ်ပါတယ်။

RESTful

ကနေ့အချိန်မှာ Web Application Development အတွက် Framework တွေ ရှိနေပြီး အများစုက Application တွေကို REST Manner နဲ့ တည်ဆောက်နိုင်အောင် စီစဉ်ထားပေးလေ့ ရှိပါတယ်။ RESTful ဆိုတဲ့အသုံးအနှုံးတစ်ခုရှိပါတယ်။ Application တည်ဆောက်သူက Application ရဲ့ ကဏ္ဍအားလုံးကို REST သဘာဝပေါ်မှာ အခြေပြု တည်ဆောက်ခြင်းကို ဆိုလိုတာဖြစ်ပါတယ်။ Request / Respond တွေမှာ HTTP ရဲ့ REST သဘာဝကို ထိထိရောက်ရောက်အသုံးချသလို URL Structure ကအစ Representable ဖြစ်နေအောင် တည်ဆောက်ကြခြင်းကို ဆိုလိုတာ ဖြစ်ပါတယ်။ ဥပမာ -

http://www.example.com/books/update/123

ဒီ URL ဟာ စာအုပ်အမှတ် 123 ကို Update လုပ်လိုက်ဖို့ ညွှန် ကြားတဲ့ URL ဖြစ်ကြောင်း လူတစ်ယောက် ဖတ်ရှုနားလည်နိုင်သလို၊ ကွန်ပျူတာကလည်း နားလည်နိုင်တဲ့ URL format တစ်ခုဖြစ်ပါတယ်။ ဒီလို Application ရဲ့ လုပ်ဆောင်ချက်အားလုံးကို Representable ဖြစ်အောင် ဖန်တီးရေးသားခြင်းကို RESTful ဖြစ်တယ်လို့ ခေါ်တာ ဖြစ်ပါတယ်။ ဒီလို RESTful URL တွေ အသုံးပြုနိုင်ဖို့ Framework တွေနဲ့အတူ ပါလာတဲ့ Routing စနစ်တွေကို အသုံးပြုဖို့လိုအပ်မှာ ဖြစ်ပါတယ်။

Web Application တစ်ခုရဲ့ လုပ်ဆောင်ချက်အားလုံးကို RESTful ဖြစ်နေအောင် ဖန်တီးထားခြင်းအားဖြင့် HTTP ရဲ့ ဆောင်ရွက်ချက်တွေကို အမှန်တစ်ကယ် ထိရောက်အောင် စီမံအသုံးချနိုင်မှာဖြစ်သလို၊ Maintainable ဖြစ်တဲ့ စနစ်တစ်ခုကိုလည်း Design လုပ်ပြီးသား ဖြစ်သွားစေမှာ ဖြစ်ပါတယ်။

Web Services

ကိုယ့် Web Application ရဲ့လုပ်ဆောင်ချက်တွေကို Service API အနေနဲ့ ပေးနိုင်ဖို့အတွက် Web Service Model တစ်ခု ဖန်တီးမယ်ဆိုရင်တော့ REST ဟာ အတော်လေးကို အရေးပါလာပါပြီ။ ဥပမာ – ကျွန်တော်တို့က Online Store တစ်ခု တည်ဆောက်မယ် ဆိုပါစို့။ http://api.ourstore.com/items ဆိုပြီး API Call လုပ်လိုက်တာနဲ့ ကျွန်တော်တို့ Store ရဲ့ Latest Items တွေကို တစ်ခြား Developer တွေက သူတို့ Website မှာ Integrate လုပ် ဖော်ပြပေးနိုင်မယ့် Service Model မျိုး ဖြစ်ပါတယ်။

ပြီးတော့.. ကနေ့အချိန်မှာ Desktop Browser သာမက၊ Mobile Browser, Mobile App စသဖြင့် Web ကို Access လုပ်နိုင်တဲ့ Client ပေါင်းစုံ ဖြစ်လာတဲ့အတွက် Developer တွေက Application ရဲ့ API Model ပိုင်းကို အဓိကတည်ဆောက်ပြီး Device ပေါင်းစုံအတွက် Client တွေကို အဲ့ဒီ API ပေါ်အခြေခံပြီး နောက်မှ ဖန်တီးယူတဲ့သဘော လုပ်လာကြပါတယ်။

Service API တွေကို စနစ်တစ်ကျ Design လုပ်ထားမှသာ မိမိအပါအဝင် ရယူအသုံးပြုတဲ့ Developer တွေအတွက် Implement လုပ်ရတာ လွယ်ကူအဆင်ပြေမှာဖြစ်မှာပါ။ API Call အတွက် URL Pattern တွေဟာ ပုံမှန်ဆိုရင် ခုလို ရှိနေနိုင်ပါတယ် -

...
/getAllBooks
/tagVerify
/makeCheckOut
/doCheckIn
/updateBook
/categorySearch
/getHistoryBooks
/doMythologyBooksSearch
/getNewestBooksSince
...

ဒီပုံစံမှာ noun နဲ့ verb တွေ ရောနေတာကို တွေ့ပါလိမ့်မယ်။ ရယူအသုံးပြုတဲ့ Developer တွေအတွက် မှတ်ရခက်သလို၊ စနစ်လည်း မကျပါဘူး။ /getAllBooks မှာ get ဆိုတဲ့ verb က ရှေ့ကနေပြီး၊ ရယူလိုတဲ့ AllBooks က နောက်ကနေပါတယ်။ /tagVerify မှာတော့ noun ဖြစ်တဲ့ tag က ရှေ့ကနေပြီး verb ဖြစ်တဲ့ Verify က နောက်ကနေပါတယ်။ /makeCheckOut မှာ make ဆိုတဲ့ verb ကို သုံးပြီး၊ /doCheckIn မှာတော့ do ဆိုတဲ့ verb ကို သုံးပါတယ်။

ဒီလို API Design စနစ်မကျမှု့က Implement လုပ်မယ့် Developer အတွက် အခက်တွေ့စေနိုင်သလို၊ API Designer ကိုယ်တိုင်အတွက်လည်း Maintain လုပ်ရ ခက်ခဲစေမှာဖြစ်ပါတယ်။ HTTP ရဲ့ Request Method တွေကို Verb အနေနဲ့ ထိရောက်အောင် အသုံးချပြီး တည်ဆောက်မယ်ဆိုရင်တော့ အများကြီး စနစ်ကျသွားစေမှာ ဖြစ်ပါတယ်။

HTTP မှာ Request Method တွေရှိပါတယ်… အဓိကကျတာတွေကတော့ POST, GET, PUT, DELETE တို့ဖြစ်ပါတယ်။ ဒီ Method တွေနဲ့ တွဲဖက်သုံးမယ်ဆိုရင် အများကြီး ပိုစနစ်ကျသွားစေမှာ ဖြစ်ပါတယ်။ ဥပမာ -

ဒီနည်းနဲ့ URL parameter နှစ်ခုတည်းနဲ့ HTTP Request Method လေးခုကို  ပေါင်းပြီး ကိစ္စတော်တော် များများကို ဆောင်ရွက်နိုင်မှာ ဖြစ်ပါတယ်။ Request / Respond တွေကလည်း မူလအနှစ်သာရမပျက် Representable ဖြစ်နေစေမှာဖြစ်လို့ ဒါဟာ RESTful API Design လို့ ခေါ်ဆိုနိုင်မှာ ဖြစ်ပါတယ်။

Service API ကောင်းတစ်ခု ပြည့်စုံဖို့ဆိုရင်တော့ နောက်ထပ် ထည့်သွင်းစဉ်းစားရမှာတွေ ရှိနိုင်ပါသေးတယ်။ Argument Association တွေ လိုအပ်လာရင် ဘယ်လိုပေးပို့ လက်ခံမလဲ။ Respond Data Format ကို ဘာသုံးမလဲ၊ JSON လား၊ XML လား။ Error တွေအတွက် Status Code တွေကို ဘယ်လို ပြန်ပေးမလဲ။ Authentication နဲ့ Security ကို ဘယ်လို စီမံမလဲ။ API Version တွေကို ဘယ်လိုစီမံမလဲ စသဖြင့် အများကြီး ထည့်သွင်းစဉ်းစားဖို့ လိုအပ်ပါသေးတယ်။

အသေးစိတ် ဆက်လက်လေ့လာလိုတယ်ဆိုရင်တော့ Teach a Dog to REST ဆိုတဲ့ talk တစ်ခုမှာ လေ့လာဖို့ အကြံပြုလိုပါတယ်။ လိုရင်းတိုရှင်းနဲ့ အထိရောက်ဆုံး ရှင်းပြထားပါတယ်။

Conclusion

HTTP ဟာ မူလကတည်းက REST Model နဲ့ Design လုပ်ထားတာ ဖြစ်ပါတယ်။ ကျွန်တော်တို့ Developer တွေကလည်း Application တွေ တည်ဆောက်တဲ့ အခါမှာ အဲ့ဒီ REST Model ကို ထိရောက်အောင် အသုံးချရမှာ ဖြစ်ပါတယ်။ Request တွေမှာ မှန်ကန်တဲ့ Method တွေ အသုံးပြု ဖို့လိုသလို Server Respond တွေမှာလည်း Respond Header တွေကို စနစ်တကျအသုံးချဖို့ လိုပါတယ်။

စနစ်ကျသပ်ရပ်တဲ့ RESTful Web Application တွေ Service API တွေ တည်ဆောက်ဖို့အတွက် တစ်စုံတစ်ရာ အထောက်အကူဖြစ်လိမ့်မယ်လို့ မျှော်လင့်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။