အခုတလော ရုံးမှာ Restful API server ပိုင်းကို ရေးနေရတယ်။ အဲဒီမှာ CodeIgniter Routing Structure နဲ့ အဆင်မပြေတာကို တွေ့လာရတယ်။ Restful API တွေက Controller နဲ့ Model ပဲရှိတယ်။ view ဆိုတာက JSON သို့မဟုတ် XML return ပြန်တဲ့ page ပဲ ရှိတယ်။ အဲဒီတော့ API server ပိုင်းရေးတဲ့ အခါမှာ MVC pattern ဆိုတာက သိပ်အရေးပါတာမဟုတ်ဘူးဆိုတာကို သတိထားမိတယ်။

CodeIgniter ရဲ့ structure က

http://www.domain.com/controller/action/parameter/parameter

controller ကတော့ ရှင်းတယ်။ file တစ်ခု နဲ့ ရေးရလို့။ အဲလိုပဲ action ကလည်း function တစ်ခုနဲ့ ရေးရတော့ တော်တော်လေးကို ရှင်းတယ်။ code ကို ပြန်ဖတ်ရတာလည်း နားလည်တာပေါ့။ သို့ပေမယ့် API တွေ ရေးရတော့ အခုလို ဖြစ်သွားတတ်တယ်။

http://www.domain.com/users/:username/

http://www.domain.com/users/:username/blogs/

http://www.domain.com/users/:username/blogs/:id/

http://www.domain.com/users/:username/blogs/:id/coments/

http://www.domain.com/users/:username/blogs/:id/coments/:id

/:username ဆိုရင် သက်ဆိုင်ရာ user ရဲ့ data တွေ ထွက်လာမယ်။
/:username/blogs ဆိုရင် သူ့ ရဲ့ blog list ထွက်လာမယ်။
/blogs/:id ဆိုရင် blog တွေထဲကမှ id တစ်ခုအတွက် data ထွက်လာမယ်။
/blogs/:id/comments ဆိုရင် comments အကုန်ပေါ့။
/blogs/:id/comments/:id ဆိုရင်တော့ comments တစ်ခုအတွက် id ပေါ့။

အဲဒီမှာ စပြီး ပြဿနာ ဖြစ်တာကတော့ controller က dynamic ဖြစ်နေတာပဲ။ /users/name ဆိုပြီး သုံးပါလားလို့ ဆိုလို့ရပေမယ့် link လမ်းကြောင်းက developers အချို့အတွက် complain တက်စရာ ဖြစ်သွားမှာ အမှန်ပဲ။ ကျွန်တော့် အနေနဲ့လည်း /users/:username ကို /users/name/:username ထက် ပိုသဘောကျတယ်။ တိုသလို လွယ်တယ်။ /name ထည့်လိုက်တဲ့အတွက် /id ကော မရှိဘူးလားဆိုပြီး မေးခွန်းက ရှိလာပြန်တယ်။ Controller ကို သတ်မှတ်လို့ မရတဲ့အတွက် စကတည်းက index မှာပဲ စရမှာပဲပေါ့။ index မှာ username ကို စစ်ပြီးတော့ ရှိခဲ့ရင် သက်ဆိုင်ရာ user ရဲ့ data ကို ပြန်ခေါ်ပြပေးရုံပဲ။

ဒီအထိ ရှင်းပါသေးတယ်။ /blogs ဆိုတာကို ထပ်ထည့်လိုက်တော့ သက်ဆိုရင် user information ကို မပြပေးရတော့ပဲ /blogs လာပြီဆိုရင် blog အားလုံးရဲ့ list ကို ပြဖို့ condition ထပ်ရေးရပါတယ်။

/blogs/:id ဆိုရင် blogs id ကို ရှိမရှိ ထပ်စစ်ရပါမယ်။ အဲဒီ blog id ကလည်း လက်ရှိ username ရဲ့ blog id ဟုတ်မဟုတ် ထပ်စစ်ရပါမယ်။ နောက်ဆုံး /blogs/:id/comments/:id အထိ ကို ရေးတဲ့အခါမှာ condition တွေ အများကြီး သုံးရပါမယ်။ အကုန်လုံးက index() function ထဲမှာ စစ်ထားရပါမယ်။ တနည်းပြောရင် controller/action အပြင်

controller/controller/action ဖြစ်သွားတဲ့အခါရှိသလို /controller/controller/controller/action ဆိုပြီး ရှိသွားတဲ့အခါလည်း ရှိပြန်ကော။ တနည်းပြောရင် url က ရှည်သွားတဲ့အခါမှာ CodeIgniter framework ပုံစံက အရမ်းကို ရှုပ်ထွေးကုန်တာ အမှန်ပဲ။

အဲလိုပဲ CodeIgniter ကို အခြေခံထားတဲ့ Ava framework ပုံစံက လည်း ရှုပ်ထွေးကုန်တယ်။ အစက Restful အတွက် ဆိုပြီး သီးသန့် RestController ထည့်ထားပေမယ့် တကယ်တန်း link တွေက အရမ်းကို ရှည်လာတဲ့ အခါမှာ အဆင်မပြေတော့ပါဘူး။

ဒီနေ့ ဘာကို သွားတွေ့မိသလဲဆိုတော့ Sinatra ပုံစံကို ယူထားတဲ့ Slimframework ဆိုတာကိုပါ။ တော်တော်များများကတော့ slim အစား limonade ကို recommend လုပ်ကြတယ်။ Documentation ကို ကြည့်ကြည့်တာကတော့ limonade က ပိုပြည့်ပြည့်စုံစုံ ရေးထားပေမယ့် limo လို အစိမ်းရောင်ကြီး သုံးထားတော့ documentation ကို ကျွန်တော့် မျက်လုံးက ကြာကြာမဖတ်နိုင်ဘူး။ limonade မှာ သုံးထားတဲ့ structure ကို သိပ်သဘောမကျလှဘူး။ ကျွန်တော်ကတော့ Slimframework မှာ သုံးထားတဲ့ structure ကို သဘောကျမိတယ်။

Slim နဲ့ hello world ကို ဒီလိုရေးရပါတယ်။ GET , POST , PUT , DELETE method တွေကို သတ်မှတ်ပြီးသားပါ။ ဒါကြောင့် GET ဖြစ်လား POST ဖြစ်လား PUT ဖြစ်လား DELETE ဖြစ်လား စစ်ရတဲ့ အလုပ်တော့ သက်သာသွားတယ်။

Sinatra ရဲ့ routing ပုံစံကို express ,node web framework ကို လေ့လာခဲ့တုန်းက သိခဲ့တယ်။ အဲဒီကတည်းက တော်တော်သဘောကျမိခဲ့တာ။ အဓိက သဘောကျတဲ့ အချက်ကတော့ routing ပုံစံပဲ။ router ကို မိမိသဘောကျ သတ်မှတ်ထားပြီး ဒါလာရင် ဒီ function သွားဆိုပြီး ရေးလို့ရလို့ပါပဲ။ လက်ရှိ ကျွန်တော် CodeIgniter Router မှာ ကြုံနေရဲ့ ပြဿနာတွေကို Sinatra ပုံစံအတိုင်းဆိုရင် လွယ်လွယ်လေးနဲ့ ဖြေရှင်းလို့ရပါလိမ့်မယ်။ အဆင်ပြေတယ်ဆိုရင် Slimframework လေးကို လေ့လာပြီး နောက် လုပ်မယ့် projects ရောက်ရင် ပြောင်းသုံးမယ်လို့ စဉ်းစားထားတယ်။ အခု projects တွေကတော့ နောက်ဆုတ်ဖို့ အချိန်မရှိတော့ဘူး။ code တွေက ရှုပ်ထွေးနေပေမယ့် ကောင်းကောင်း အလုပ်လုပ်နေတယ်။ သို့ပေမယ့် slimframework ထက် node က express framework ကို ပိုသဘောကျနေမိတာ အမှန်ပဲ။ သို့ပေမယ့် node.js က mysql နဲ့ တွဲသုံးရတာ အချို့ကိစ္စတွေ တော်တော်လက်ပေါက်ကပ်တာတော့ အမှန်ပါပဲ။

သောကြာနေ့ညက rackspace မှာ cloud server ကို လပေးနဲ့ စမ်းကြည့်တယ်။ အဓိကတော့ MZ နဲ့ Ornagai အတွက် server ပေါ့။ အရင်ဆုံး ကိုယ့် blog ကို ကိုယ်တင်တော့ nginx ကို သုံးမယ်ဆိုပြီး ဆုံးဖြတ်ထားလို့ ngix ကို တင်လိုက်တယ်။ php fpm ကို သွင်းလိုက်တယ်။ ပုံမှန် .php file ကို စမ်းကြည့်တယ်။ ရတယ်။ ဒါနဲ့ wordpress တင်ဖို့ လုပ်တော့ စပြီး တိုင်ပတ်တာပဲ။ .htaccess အလုပ်မလုပ်တော့တဲ့ အတွက်ကြောင့် wordpress configure က စပြီး ဂဂျောင်ပါလေရောပေါ့ဗျာ။ သို့ပေမယ့် wordpress website မှာရေးထားတဲ့အတွက်ကြောင့် အဆင်ပြေသွားတယ်။

ဒါပေမယ့် site က နှေးနေတယ်။ တော်တော်လေးကို နှေးနေတာ။ ဘာဖြစ်လို့ နှေးမှန်းမသိဘူး ဖြစ်နေတယ်။ အခုအချိန်တော့ ထင်သလောက် မနှေးတော့ဘူး။ နှေးရခြင်း အကြောင်းက DNS cache က fully update မဖြစ်သေးတာကြောင့်ပါ။ နောက်ပြီး configure တွေ လွဲနေတာကြောင့်လည်း ပါတယ်။ PHP APC နဲ့ ဆို မြန်တယ်ဆိုတာနဲ့ PHP APC ကို သွင်းပြီး wordpress နဲ့ တွဲသုံးလိုက်တာ အရမ်းကို မှန်သွားတယ်။ W3 Plugin က PHP APC ကို support လုပ်ပေးတယ်ဆိုတော့ ဘာမှ ပြင်စရာ မရှိဘူး။

တင်ပြီးတော့ ကိုယ့် site ကို ကိုယ်သဘောကျနေတုန်း သိပ်တောင် မခံလိုက်ဘူး။ ၆ နာရီလောက်ကြာတော့ server down သွားတယ်။ ဘာဖြစ်တာလည်းဆိုတာကို စစ်ကြည့်လိုက်တော့ out of memory ဖြစ်ပြီး php fpm က အလုပ်မလုပ်တော့ဘူး။ ssh လည်း ချိတ်မရတော့ဘူး။ ဘာဆို ဘာမှ လုပ်မရတော့ဘူး။ တော်သေးတာက rackspace ရဲ့ control မှာ restart ချတာ ပါပေလို့ပဲ။ restart ပြန်ချလိုက်ရတယ်။ ကြည့်ရတာ PHP APC က memory တော်တော် စားတဲ့ ပုံပေါ်တယ်။ ( တကယ်တန်း ပြဿနာက PHP APC ကြောင့် မဟုတ်မှန်း နောက်မှ သိရပါသည် ) APC ဖြုတ်ပြီးပေမယ့်လည်း နှေးနေတုန်းပဲ။ ဟိုရှာဒီရှာ ဟိုပြင် ဒီပြင်လုပ်။ file cache တွေလည်း လျှောက်ထည့်။ အရမ်းနှေးနေတုန်းပဲ။

နောက်ဆုံးမှ terminal မှာ free ဆိုတာကို ရိုက်ကြည့်လိုက်တော့ အားပါးပါး 6248 KB (6 MB) ပဲ လွတ်တော့တယ်။ ဒါနဲ့ ဘာကြောင့်လည်းဆိုတာကို ထပ်ပြီး စစ်ကြည့်ဖို့ $ps aux နဲ့ ကြည့်လိုက်​ေတာ့ php-fpm တွေ အများကြီး run နေတယ်။ ဒါဆိုသေချာပြီ php-fpm config လွဲကို လွဲနေပြီ။ ဒါနဲ့ /etc/php5/fpm/pool.d/www.conf မှာ ဝင်ကြည့်လိုက်တော့

pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 8
pm.max_spare_servers = 40

idle အဆင့်မှာတင် စစခြင်းကို 25 process တောင် ဝင်ယူလိုက်တာကို။ macbook pro 4GB memory မှာ မသိသာပေမယ့် 512 MB မှာတော့ သိသာသွားပြီ။ အနိမ့်ဆုံး 8 ကနေ အများဆုံး 40 အထိ idle လုပ်ခွင့်ပေးထားတယ်။ php-fpm က process တစ်ခုကို အနည်းဆုံး 11 MB လောက်ယူတယ်။ ဒီတော့ phpfpm စလိုက်တာနဲ့ 25 * 11 = 275 MB လောက် နေရာ ယူပလိုက်ပြီ။ လူ အဝင်များလာရင် 40 ဆိုတော့ 440 MB လောက် အများဆုံး idle အဆင့်မှာ ကျန်ခဲ့ပြီ။ max childer အတွက် php-fpm ကြီးပဲ 550m MB လောက် နေရာယူခွင့်ပေးထားတယ်။

သေချာတာပေါ့။ ဒါကြောင့် နှေးနေတာ ဖြစ်မယ် ဆိုပြီး php-fpm config ကို ဒီလို ပြင်လိုက်တယ်။

pm.max_children = 20
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

အဲလိုလည်း ပြင်လိုက်ကော တော်တော်လေးကို မြန်သွားတယ်။ php-fpm က အများဆုံးယူမှ 220 MB ပဲ ရှိတော့တယ်။ အယောက် ၂၀ ထက် ကျော်ရင်တော့ concurrency မှာ ပြဿနာရှိနိုင်ပေမယ့် လက်ရှိ blog တွေ MZ အပါအဝင် အယောက် ၂၀ တပြိုင်တည်းရှိတဲ့ အချိန် တော်တော်ရှားပါတယ်။ start_server ကို ပေးဖို့အတွက် min+[(max-min)/2] ဆိုတဲ့ formula နဲ့ တွက်ပြီး ပေးထားပါတယ်။ အခု ကတော့ server က stable ဖြစ်သွားပြီဆိုတော့ ornagai ကို ပြောင်းဖို့ လုပ်ရမယ်။ ornagai အခြေအနေ ကြည့်ပြီး MZ ကို ပြောင်းဖို့ အတွက် စဉ်းစားရမယ်။

Nginx က တကယ့်ကို မြန်ပါတယ်။ Apache ထက်စာရင် မြန်တာကတော့ အသေအချာပဲ။ အခုလို config ပြင်ထားလိုက်တော့ memory မှာ ပုံမှန် 113876 KB လောက်တော့ free ကျန်နေတယ်။ OS က အလုပ်လုပ်ရတာ အဆင်ပြေတာပေါ့။ 6 MB လောက်နဲ့ OS တစ်ခုလုံး ဘာမှ လုပ်လို့ မရတာ အသေချာပဲ။ unmanagement VPS ကို သုံးတဲ့အခါမှာ သေချာ config လုပ်တတ်ရင် share ထက်စာရင် အများကြီးမြန်ပေမယ့် config မလုပ်တတ်ရင်တော့ share လောက်တောင် အသုံးမကျတာ အမှန်ပါပဲ။ config လုပ်တတ်ဖို့ကလည်း ကိုယ်သုံးတဲ့ OS ရဲ့ command line တွေ သိရအုံးမယ်။ vi ကို သုံးတတ်ရအုံးမယ်။ nginx ကို သုံးရင်းနဲ့ config နည်းနည်းပါးပါး လုပ်တတ်လာသလို သဘောကျလာတာလည်း အမှန်ပါပဲဗျာ။ ကိုယ့် blog အမြန်နှုန်းကို သဘောကျလွန်းလို့ ခဏခဏ စမ်းကြည့်ဖြစ်နေတယ်။ အရင်တုန်းကတော့ ခဏခဏ down လို့ စိတ်ညစ်ရပေမယ့် အခုကတော့ တော်တော်လေးကို အဆင်ပြေသွားပါပြီ။

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

ရေပြည့်နေရင် ရေထပ်ဖြည့်လို့ မရဘူး

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

အဲလို တွေးတာ မှန်သင့်သလောက် မှန်ပေမယ့် မှားနေတယ်ဆိုတာ သဘောပေါက်လာတယ်။ ဘာကြောင့် မှားတာလဲ ? language တစ်ခုကို မေ့ပစ်လိုက်ရင် looping , for loop , while loop စတဲ့ concept တွေ မေ့ခိုင်းတာနဲ့ အတူတူပဲ။ တနည်းပြောရင်း တခြား language မှာ looping ၊ condition တို့ operator တွေကို ပြန်လေ့လာရမယ့် သဘောဖြစ်နေတယ်။

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

နောက်ထပ် language တစ်ခုကို ဖြစ်ဖြစ် framework တစ်ခုကို ဖြစ်ဖြစ် လေ့လာတဲ့ အခါမှာ လက်ရှိ ကိုယ်တတ်ကျွမ်းထားတဲ့ အရာကို မေ့ပစ်စရာ မလိုဘူး။ သို့ပေမယ့် ဘယ်သူပိုသာတယ်။ ဘယ်သူပိုကောင်းတယ် စတာတွေကို နိှုင်းယှဉ် ဖို့ ကြိုးစားနေရင်တော့ ခွက်တစ်ခွက်ထဲမှာ နောက် ရေထပ်ဖြည့်သလိုပဲ။ Django က Django ပဲ။ CI က CI ပဲ။ Ava က Ava ပဲ ဆိုပြီး သီးသန့် စီထားပြီး လေ့လာတတ်ဖို့ ပဲလိုတယ်။

မစောင့်ပါနဲ့ ။ ချက်ခြင်း ရေးကြည့်ပါ ။

မှတ်မှတ်ရရ python နဲ့ mywebfont ကို ရေးလိုက်တာ တစ်ရက်ပဲ ကြာတယ်။ ဒီမတိုင်ခင်မှာ python လုပ်မယ် လုပ်မယ်နဲ့ မလုပ်ဖြစ်ဘူး။ စာအုပ် ဖတ်ဖို့ ဖွင့်လိုက်တိုင်း ပြန်ပြန် ပိတ်ပြီး အခြားဟာတွေ လုပ်ဖြစ်နေတယ်။ mywebfont ကို google app engine မှာ တင်တော့မယ်ဆိုတော့ java လား python လား ဆိုပြီး ရွေးရပြီ။ နဂို ဓာတ်ခံ java ကို အကြောင်း မရှိပဲ မကြိုက်တာဆိုတော့ python နဲ့ ရေးမယ်ဆိုပြီး ရေးလိုက်တာပဲ။ ဘာမှ ထွေထွေထူးထူး မလေ့လာထားဘူး။ google မှာ ရိုက်ရိုက်ပြီး ရှာသွားလိုက် ရေးလိုက် လုပ်သွားတာပဲ။ for loop ဘယ်လို ပတ်ရတယ်။ condition ဘယ်လို ရေးရလဲ ဆိုတာတွေကို google မှာ ရှာသွားတယ်။ တစ်ခါတစ်လေ php မှာ ဒီ function ကို python မှာ ဘယ်လို ရေးရမလဲမသိဘူး လို့ စဉ်းစားမိရင်လည်း google မှာ ရှာလိုက်တယ်။ ဥပမာ။ ။substr ကို python မှာ ဘယ်လိုရေးရမှန်းမသိဘူး။ php substr in python ဆိုပြီး google မှာရှာလိုက်တာနဲ့ လိုချင်တဲ့ အဖြေ တန်းရတယ်။ တနည်းပြောရင် php လေ့လာထားတာက python လေ့လာဖို့ကို လာပြီး အထောက်အကူ ပေးတယ်။ php ကိုသာ မေ့လိုက်ရင် python လေ့လာရတာဟာ ပိုခက်သွားလိမ့်မယ် ထင်တယ်။ တတ်ကျွမ်းထားတဲ့ language တစ်ခုကို မေ့ဖို့ကတော့ တော်တော်လေးကို ခက်ခဲပါတယ်။ မေ့ဖို့ မကြိုးစားပဲ လိုအပ်တဲ့ နေရာမှာ လိုသလို အသုံးချတတ်အောင် လုပ်ထားဖို့ပဲ လိုတယ်။

အတွေးအခေါ်

Django ကို လေ့လာရင်းနဲ့ စာရေးဆရာ ပြောထားတဲ့ အချက်လေးကို သဘောကျသွားတယ်။ Django မှာ ဒီလို ရေးတယ်။ ဟို framework မှာတော့ ဒီလို ရေးတယ်။ ဟို language မှာတော့ ဒီလိုသုံးတယ်ဆိုပြီး လိုက်တွေးနေဖို့ မလိုဘူး။ Django မှာ သုံးထားတဲ့ MVC နဲ့ CI မှာ သုံးထားတဲ့ MVC ပိုင်းတွေ မတူဘူး။ framework ကို ရေးထားတဲ့သူရဲ့ အတွေးအခေါ်မှာ မူတည်ပြီးတော့ framework တည်ဆောက်ပုံက ဖြစ်ပေါ်နေတာ။ ဥပမာ။။ Ava ရေးတုန်းက စဉ်းစားထားတဲ့ စဉ်းစားမှုမျိုးဟာ Django မှာ မပါသလို အချို့ အရာတွေက CI မှာ မပါဘူး။ ကိုယ့်လိုအပ်ချက်နဲ့ ကိုက်ပြီး ရေးထားတာ။ အဲလိုမျိုး Django ရေးထားတဲ့သူကလည်း သူလိုအပ်တယ်ထင်တာတွေကို ပေါင်းထည့်ထားတာပဲ။ CI လည်း အဲလိုပဲ။ fuelphp လည်း ကောင်းမယ်ထင်တဲ့ဟာတွေ ပေါင်းထည့်ထားတာပဲ။ ဒါကြောင့် ဘာက ပိုကောင်းတယ်ဆိုတာကို နိှုှင်းယှဉ်မယ့် အစား သူဘာကြောင့် ဒီလို သုံးရတာလဲဆိုတာကို နားလည်အောင် ကြိုးစားသင့်တယ်။ အဲဒီ အချက်လေးကို သဘောပေါက်သွားတာနဲ့ ရှေ့ဆက်လေ့လာဖို့ လမ်းတွေ အများကြီး ပွင့်သွားတယ်။ framework ရေးထားတဲ့သူရဲ့ အတွေးအခေါ်တွေ စဉ်းစားတဲ့ ပုံတွေကို framework တစ်ခုကို လေ့လာရင်းနဲ့ တွေ့နိုင်တယ်။ သူ ဘယ်အပိုင်းကို အားသန်တယ်။ ဘာကြောင့် ဒီလိုရေးရတာလဲ ဆိုတာကို ကြည့်ရင်းနဲ့ သဘောပေါက်လာလိမ့်မယ်။ အဲဒီလို သဘောမပေါက်ရင်တော့ လေ့လာရတာက တော်တော်လေးကို ခက်လိမ့်မယ်။

Django မှာ သုံးထားတဲ့ အပိုင်းလေးတွေက သဘောကျဖို့ ကောင်းတယ်။ CI နဲ့ လုံးလုံးကို မတူဘူး။ CI က ပေါ့ပါး အသုံးလွယ်ပြီး လွယ်လွယ်လေ့လာဖို့ ဦးစားပေးတယ်။ Django က စနစ်ကျပြီး ခိုင်ခံတဲ့ ဖွဲ့စည်းပုံကို ဦးစားပေးတယ်။ သူတို့ စဉ်းစားပုံကို သဘောမပေါက်ပဲ ကိုယ့်အတွေးအခေါ်ကသာ အမှန်ဆုံးလို့ ဆုတ်ကိုင်ထားရင်တော့ သူတို့ပြောချင်တဲ့ အရာကို သဘောပေါက်မှာ မဟုတ်တော့ဘူး။ သူတို့ ပေးချင်တဲ့ message ကို လက်ခံဖို့ ကိုယ့်မှာ ခွက်လွတ်တစ်လုံး အသင့်ရှိနေဖို့ လိုတယ်။ ကိုယ့် ခွက်က ပြည့်နေပေမယ့် နောက်ထပ် ခွက်တစ်ခုနဲ့ ထပ်ပြီး လက်ခံနိုင်အောင် ကြိုးစားလို့ ရပါသေးတယ်ဗျာ။ Django ကို လေ့လာရင်းနဲ့ သဘောပေါက်လာပြီး ပြီးရင်တော့ Node.js ကို လေ့လာဖို့ ဆန္ဒတွေ စောမိလေရဲ့။

MAMP မှာ pspell ကို မထည့်ထားလို့ ornagai မှာ spell checking ကို ဖြုတ်လိုက်ရတယ်။ ဒါပေမယ့် စိတ်က သိပ်မကျေနပ်ဘူး။ ပြန်ထည့်မယ်ဆိုပြီး စဉ်းစားပေမယ့် php ကို ပြန် compile လုပ်ရမှာကြောင့် မလုပ်ဖြစ်ဘူး ဖြစ်နေတယ်။ ဒါနဲ့ google က api လေး ပေးထားရင်တော့ php လည်း ပြန်ပြီး compile လုပ်စရာမလိုဘူး။ server တိုင်းအတွက်လည်း သုံးလို့ရသွားမယ်ဆိုပြီး ရှာလိုက်တော့ တွေ့ပါတယ်ဗျာ။ code ကလည်း လွယ်လွယ်လေးပဲ။ code example ကို အောက်မှာပဲ ကြည့်လိုက်ပါ။ ornagai.com မှာတော့ အမြန်ဆုံး ထည့်သွင်းနိုင်အောင် ကြိုးစားလိုက်အုံးမယ်။ Ornagai.com ကို v3 အနေနဲ့ ပြန်ရေးမယ်ဆိုတာကလည်း မရေးဖြစ်သေးဘူး။ ဒီ spell check ကိုတော့ ဒီအပတ်အတွင်း ထည့်နိုင်အောင် ကြိုးစားလိုက်အုံးမယ်။

<?php
header("Content-Type: text/xml; charset=utf-8");
$url="https://www.google.com/tbproxy/spell?lang=en";
$text = urldecode("mystary");

$body = '<?xml version="1.0" encoding="utf-8" ?>';
$body .= '<spellrequest textalreadyclipped="0" ignoredups="1" ignoredigits="1" ignoreallcaps="1">';
$body .= '<text>'.$text.'</text>';
$body .= '</spellrequest>';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $body);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$contents = curl_exec($ch);
curl_close($ch);

print $contents;
?>

မနေ့က PHPFog ရဲ့ invitation ရတာနဲ့ စမ်းဖြစ်တယ်။ PHPFog ကို အသုံးပြုချင်တာကတော့ ကြာလှပြီ။ သို့ပေမယ့် လူတိုင်း register လုပ်ပြီး သုံးခွင့်မရှိဘူး။ သူ invite လုပ်တဲ့သူတွေပဲ သုံးခွင့်ရှိပါတယ်။ PHPFog ကို register လုပ်တဲ့အခါမှာ survy ဖြည့်ထားတဲ့သူတွေကို ဦးစားပေးပြီး Beta access ရပါတယ်။ မနေ့က ရတော့ တော်တော်ပျော်သွားပါတယ်။ heroku ကို သိကတည်းက PHP လည်း အဲလိုမျိုး ရှိရင် ကောင်းမှာပဲ လို့ စဉ်းစားမိတယ်။ PHP Fog ကို သိသိခြင်းမှာပဲ register လုပ် survy လုပ်ထားတာ တော်တော်တော့ကြာသွားပြီ။

PHPFog ကတော့ ပုံမှန် ထက် အသုံးလွယ်အောင် ဖန်တီးပေးထားတယ်။ ၁ လ ကို $29 လောက်တော့ ပေးရတယ်။ $29 ဆိုတာက Application တစ်ခုတည်းအတွက်နော်။ စျေးကတော့ မသေးလှဘူး။ သို့ပေမယ့် Amazon မှာ ထားပြီး scalability ဖြစ်တာကြောင့် Techcrush , Mashable လိုမျိုး လူတွေ အရမ်း အဝင်များတဲ့ site တွေအတွက် အရမ်းကို အဆင်ပြေပါတယ်။ Free အနေနဲ့ ၆လ စမ်းလို့ရပါတယ်။

တစ်ခါတည်း one step တည်းနဲ့ wordpress , joomla, drupal , sugarCRM တွေကို တည်ဆောက်လို့ရတယ်။ နောက်ပြီးတော့ ကိုယ်ပိုင် php file အသုံးပြုလို့ရသလို phpframewok အချို့လည်း အသုံးပြုလို့ရပါတယ်။ အမျိုးအစား ရွေးပြီးရင်တော့ plan ရွေးရပါတယ်။

ပြီးရင်တော့ domain ရွေးပေးရတယ်။ ကျွန်တော်ကတော့ စမ်းမှာ ဖြစ်လို့ subdomain ပဲယူလိုက်တယ်။ ပြီးရင်တော့ file တွေစတင်လို့ရပါပြီ။ နောက်ပြီး database လည်း အသုံးပြုလို့ရပါတယ်။ database က amazon ပေါ်မှာပဲ တင်ထားပါတယ်။ phpmyadmin လည်း ပေးတော့ manage လုပ်ရတာ အဆင်ပြေတာပေါ့။

file တင်မယ်ဆိုရင်တော့ Git ကို သုံးတတ်ဖို့ လိုပါတယ်။ Git သုံးထားတာတော့ file တွေ upload တင်ရတာ အဆင်ပြေတယ်။ နောက်ပြီး ပြန်ပြင်ရတာလည်း အဆင်ပြေတယ်။ ပြင်ပြီး update လုပ်ရင် git ကြောင့် ပြင်ထားတဲ့ file လေးတွေပဲ တင်သွားတော့ FTP ထက်စာရင် အများကြီးကို အဆင်ပြေတယ်။

သုံးကြည့်တော့ မဆိုးဘူး။ လွယ်တယ်။ စျေးများပေမယ့် ခေါင်းမစားရဘူး။ developer တွေ စိတ်ကြိုက်ပါ။ apache.conf ကို ပြင်ခွင့်ပေးထားတယ်။ php.ini ကို စိတ်ကြိုက် ပြင်လို့ရတယ်။ ၆ လ လောက်တော့ ကောင်းကောင်းလည်း ဆော့လို့ရသွားတာပေါ့။

ဘာပဲ ပြောပြော invite လုပ်တဲ့ PHPFog ကို ကျေးဇူးတင်ပါတယ်။ PAAS ဆိုတာကို သုံးဖူးသွားတာပေါ့။

Ava framework ကို ရေးပြီးတာတော့ ကြာပြီ။ ဒါပေမယ့် bluehost မှာ တင်တော့ ပြဿနာ တက်တာပဲ။ ဘာလို့လည်းဆိုတော့ memory usages အရမ်းများနေလို့။ ဘာကြောင့်များတာလဲလို့ code ကို ကြည့်လိုက်တော့ class ကို recursive ဖြစ်နေတာတွေ့ ရတယ်။

 $this->load=$this; 

အဲဒါက အဓိက ပြဿနာပဲ။ အဲဒီ recursive က dead lock ဖြစ်သွားပြီး memory limit ပြည့်သွားတာ။ အစက hosting ကို သွားပြီး အပြစ်တင်သေးတယ်။ ဒါပေမယ့် ကိုယ့်ဘာသာ code ကို သေချာပြန်စစ်တော့ အဲဒီ နေရာက ပြဿနာ တက်ပါလေရော။ ပြန်ပြင်မယ်ဆိုတော့လည်း လက်ရှိ ရေးထားတဲ့ အပိုင်းတွေကို အကုန်လိုက်မပြင်ချင်ဘူး။ application folder က အပိုင်းကို မပြင်ရအောင် core တစ်ခုလုံး ပြင်ဖို့ ကြိုးစားရကော။ သို့သော် မရ။ ဘယ်လို ရေးရမယ်ဆိုတဲ့ idea ကို ကောင်းကောင်းမရဘူး။ Google ကလိုက်ရှာတော့လည်း မတွေ့ဘူး။ တော်တော်များများက $this->load=$this; နဲ့ ရေးထားတဲ့ tutorial တွေ အရမ်းများနေတယ်။

မဖြစ်သေးပါဘူး။ light version ကနေ စရေးရမယ်ဆိုပြီး စဖြစ်လိုက်တာပဲ။ ရေးမယ်တာ ပြောတာ။ ဘယ်က စရမှန်း မသိ။ UML တွေ ဆွဲကြည့်ရင်းနဲ့ သဘောတစ်ခုပေါက်သွားတာက Singleton ကို ငါ သုံးသင့်တာပဲ ဆိုပြီး သဘောပေါက်သွားတယ်။ Objective-c ကို အဲမှာ ကျေးဇူးတင်ရမယ်။ Objective-C လေ့လာရင်းနဲ့ memory တွေ အတတ်နိုင်ဆုံး နည်းအောင် ဘယ်လိုရေးသင့်လဲဆိုတာကို စဉ်းစားတတ်လာတာ။ iPhone 3Gs လို memory နည်းနည်းလေးမှာ ဘယ်လိုမျိုး သုံးရင် အဆင်ပြေမလဲဆိုတာကို ထည့်သွင်းစဉ်းစားလာရတာကြောင့်လည်း ပါတယ်။ အဲဒါက လက်ရှိ Ava framework ကို ပြန်ပြင်ဖို့ အများကြီး အထောက်အပံ့လာဖြစ်တယ်။ Core တစ်ခုလုံးကို Singleton ထားပြီး အဲဒီမှာပဲ initialize လုပ်သွားရင် သက်သာသွားမယ်။ recursive မဖြစ်တော့ဘူး။

နောက်တချက်က Loader ကို ခေါ်တဲ့ အခါမှာ Passing by Reference နဲ့ အသုံးပြုရင် ပိုသက်သာသွားမယ်။ class ကို ခဏခဏ load ခေါ်နေစရာ မလိုတော့ဘူး။ ဒီတော့ ဒီလို ရေးဖြစ်သွားမယ်။

controller.php မှာ load ကို ဒီလိုခေါ်လိုက်တယ်။

$this->load =& load_class('Loader');

ပြီးတော့ load_class အတွက် function ထဲမှာ

function &load_class($class)
{
	static $objects = array();

	if($class=='Loader')
	{
		$name="Ava_Loader";
	}
	// Does the class exist?  If so, we're done...
	if (isset($objects[$name]))
	{
		return $objects[$name];
	}

	$objects[$class] =& instantiate_class(new $name());
	return $objects[$class];
}

function &instantiate_class(&$class_object)
{
	return $class_object;
}

By Reference နဲ့ပဲ ခေါ်လိုက်တာကြောင့် loader class က အဆင်ပြေသွားပြီ။ နောက်ပြီး model class ကိုလည်း ပြန်ပြောင်းရသေးတယ်။ model class မှာ တစ်ခု ထပ်စဉ်းစားရတာက လက်ရှိ controller က ခေါ်ထားတဲ့ ဟာတွေပဲ ပြန်ပြီး ခေါ်လို့ရရမယ်။ ဥပမာ controller က model1 ကို ခေါ်ထားတော့ model2 ထဲမှာ model1 ကို ထပ်ခေါ်စရာမလိုပဲ တိုက်ရိုက် ခေါ်လို့ရရမယ်။

အဲဒီတော့ အကုန်လုံးကို ပြန်ပြီး assign လုပ်လိုက်တယ်။

function _assign_libraries($use_reference = TRUE)
	{
			$Ava =& get_instance();
			foreach (array_keys(get_object_vars($Ava)) as $key)
			{
				if ( ! isset($this->$key) AND $key != $this->_parent_name)
				{
					// In some cases using references can cause
					// problems so we'll conditionally use them
					if ($use_reference == TRUE)
					{
						$this->$key = NULL; // Needed to prevent reference errors with some configurations
						$this->$key =& $Ava->$key;
					}
					else
					{
						$this->$key = $Ava->$key;
					}
				}
			}
	}

Model လိုမျိုး view မှာလည်း အဲဒီ အတိုင်းပဲ။ ဒါကြောင့် view ကိုခေါ်တဲ့ အခါမှာ ပြန်ပြီး assign လုပ်ပေးဖို့လိုတယ်။

$_ava_Ava =& get_instance();
			foreach (get_object_vars($_ava_Ava) as $_ava_key => $_ava_var)
			{
				if ( ! isset($this->$_ava_key))
				{
					$this->$_ava_key =& $_ava_Ava->$_ava_key;
				}
			}

လက်ရှိ Base class ကို singleton အနေနဲ့ သုံးလိုက်တာဟာ ပြဿနာတွေ အများကြီး ပြေလည်သွားတယ်။ UML ဆွဲတုန်းက idea သာ ရတာ။ ခက်တာက ဘယ်လို ရေးရမှန်းမသိ။ ကိုယ့်ဘာသာကိုယ်တောင် ရှက်မိတယ်။ PHP ကို သိရုံပဲ သိသေးပါလား ဆိုပြီး တွေးမိလေရဲ့။ By Reference တွေနဲ့ ဘယ်အချိန်မှာ ဘယ်လို ခေါ်ရေးရမှန်း မသိဘူး။ ဒါနဲ့ CodeIgniter ရဲ့ မူရင်း code ကို အသေးစိတ် လိုက်ဖတ်ရင်းနဲ့ သူရေးထားတာ သဘောပေါက်လာတာ။ အခု လက်ရှိ code တွေအကုန်လုံးက CodeIgniter က code တွေကို မှီငြမ်းထားတာပါပဲ။

ဒီနေ့တော့ lite version လေး ပြီးတာ ကျေနပ်သွားတယ်။ မနက်ဖြန်ဆိုရင်တော့ Ava Framework ကို စလို့ရပြီ။ core တစ်ခုလုံးကိုတော့ အစ အဆုံးပြန်ပြင်ရေးရမယ်။ အဲဒါပြီးမှပဲ Ava Documentation ကို သေချာအောင် ပြန်ပြီး ရေးရမယ်။ အခုတော့ http://www.avaframework.com ဆိုပြီး domain name ပဲ ဝယ်ထားတယ်။ Ava framework လေးကိုတော့ သေသေချာချာ လေးလုပ်ဖို့ စဉ်းစားထားတယ်။ Ornagai ကို ava နဲ့ ပြန်ပြင်ဖို့ စဉ်းစားထားတာကြောင့်လည်း ပါတာပေါ့။ ဒါနဲ့ Ava ဆိုတာက အဝ နော်။ အာဗ မဟုတ်ဘူး။ အင်းဝမြို့ နာမည်ကို အစွဲပြုပြီး အဝ လို့ ပေးထားလိုက်တာ။

ပထမဆုံး ပေးခဲ့တဲ့ နာမည်က Apiwork ။ နောက်တော့ Nifty ။ ပြီးတော့ Nod ။ နောက်ဆုံး အဝ ဆိုတဲ့ နာမည်လေးနဲ့မှ စိတ်ကျေနပ်သွားတာနဲ့ အဝ ဆိုပြီး ပဲ ပေးလိုက်တာ။ lite version ကို စမ်းကြည့်ပါ။ လိုတာတွေ ရှိလည်း ပြောပါ။ lite version က MVC design pattern ကို apply လုပ်ထားတာပဲ ရှိပါတယ်။ ဘာ function မှ မပါဘူး။ လုံးဝ foundation core အဆင့်ပေါ့။ framework ကိုယ်ပိုင် ရေးချင်တဲ့သူတွေအတွက် အရမ်းကို ကောင်းမွန်တဲ့ core လို့ပဲ ဆိုရမှာပေါ့။ နောက်ပြီး သုံးထားတာက MIT license ပါ။ ဒါကြောင့် လွတ်လွတ်လပ်လပ် သုံးလို့ရတယ်။ ပြင်လို့ရပါတယ်။

ဒီ post ကို ဖတ်မိကတည်းက ချက်ခြင်း ဘာသာပြန်ချင်စိတ် ရှိနေပေမယ့် မအားတာနဲ့ လုံးဝကို ဘာပြန်မပြန်နိုင်ဘူး ဖြစ်သွားတယ်။ ရတဲ့ အချိန်လေးမှာ ၂ ပိုင်းခွဲပြီးတော့ ရေးလိုက်တယ်။ အစကတော့ ဘာသာပြန်မလို့ပဲ နောက်တော့ ခေါင်းစဉ် အချက်လောက်ပဲ ယူပြီး ကိုယ့်ဘာသာကိုယ် ရေးချင်တဲ့ အကြောင်းတွေပဲ ရေးဖြစ်လိုက်တယ်။ ဘာသာပြန်တာကနေ မှီငြမ်းတာ ဖြစ်သွားတာပေါ့။ Education နဲ့ သက်ဆိုင်တာကြောင့်လည်း MZ Blog မှာပဲ သွားရေးဖြစ်တယ်။ နောက်ပြီး အခုတလော မအားရဘူးဆိုတာကလည်း Ava အတွက် Documentation ရေးနေတာကြောင့်လည်း ပါတယ်။ အခုထက်ထိတော့ Documentation က မပြီးသေးဘူး။ စလုံးရေးစ ပဲ ဖြစ်နေသေးတယ်။ Documentation ကတော့ လက်ရှိ framework ရဲ့ အသက်ပဲ။ အချိန်ပေးရတာ မှန်ပေမယ့် နောက်ပိုင်း အသုံးဝင်မှာမို့ သေချာရေးဖို့လိုတယ်။ နောက်ပိုင်း အသုံးဝင်မှာမို့ဆို ဘာသုံးမှာမို့လဲဆိုတော့ မသိသေးဘူးပဲ ပြောရမလားပဲ။ python ကလည်း လေ့လာနေရင်း objective -c ရောက်သွားတာနဲ့ Django တောင် မလုပ်ဖြစ်တော့ဘူး။ ROR ပဲ လုပ်ရင် ကောင်းမလား Django ပဲ လေ့လာရင် ကောင်းမလား စဉ်းစားနေတုန်းပဲ။ အခုလောလောဆယ်တော့ objective -c နဲ့ပဲ လုပ်နေရတော့ အဲဒါပဲ လုပ်ဖြစ်နေတယ်။ များများလုပ်တော့ များများသိလာတာပေါ့။

PHP Developer တွေအတွက် အသုံးဝင်မယ့် အချက် ၁၀ ချက် ဆိုပြီး အပိုင်း ၁ နဲ့ အပိုင်း ၂ ခွဲရေးထားတယ်။ လက်ရှိ လေ့လာနေတဲ့သူတွေအတွက်တော့ အသုံးဝင်မယ်လို့ ထင်ပါတယ်။

အခုခေတ်ကြီးက နာမည်ပေးရတာ ခက်တဲ့ ခေတ်လို့ပဲ ဆိုရမလားမသိဘူး။ Nifty ဆိုတဲ့ နာမည်လေး ကြိုက်လို့ ပေးထားတာ အခု ကို ဒီဘီ ပြောလို့ ရှာကြည့်လိုက်တာ Nifty PHP framework က ရှိပြီးသားဖြစ်နေတယ်။ အခြား နာမည်လှလှလေး နောက်ပြီး Nifty နဲ့ အဓိပ္ပာယ်တူတဲ့ စာလုံးတွေကို ရှာကြည့်တော့လည်း ရှိပြီးသားတွေပဲ။ Nod ဆိုတာကတော့ ခေါင်းညိတ် တယ်ဆိုတဲ့ အဓိပ္ပာယ်ပါ။ ornagai မှာတော့

ခေါင်းညိတ်သည် ။ ခေါင်းညိတ်ပြသည်။ ။ ခေါင်းတစ်ညိမ့်ညိမ့်လုပ်သည် ။ ပန်းစသည် လေ၌တစ်ညိမ့်ညိမ့်လှုပ်ရှားနေသည် ။ ခေါင်းညိတ်ခြင်း ။ ခေါင်းညိတ်ပြခြင်း ။

လို့ ဆိုထားပါတယ်။ NOD 32 ရဲ့ Nemocnica na Okraji Disku (“Hospital at the end of the disk”) လို့ အမည်ရပါတယ်။ အဲဒီ အမည်က ဘယ်က လာတာလဲဆိုတော့ Nemocnice na okraji města (Hospital at the End of the City) ဆိုတဲ့ TV series နာမည်ကို ပြန်လည် ပြုပြင်ထားတယ်လို့ ဆိုပါတယ်။။ Nod Framework ဆိုတာကတော့ လက်ရှိ နာမည်မရှိသေးတာကြောင့် အဲဒီ နာမည်ပဲ ယူလိုက်ရတယ်။ ဒီနေ့ MRT ပေါ်မှာ စဉ်းစားမိတဲ့ နာမည်က Ava လို့ ခေါ်ကြတဲ့ အင်းဝ ပဲ။ အဲဒီ နာမည်လေးကို ပိုကြိုက်တာနဲ့ မနက်မှာပဲ Ava လို့ ထပ်ပြောင်းလိုက်တယ်။

နာမည်ရှာရတာ တော်တော်ခက်တာပဲဗျာ။ နာမည်လှလှလေးတွေ မြန်သမျှ Framework တွေ က ရှိပြီးသား ဆိုတော့ နာမည်ထပ်ပေးလို့ မကောင်းဘူး။ PHP framework မဟုတ်ခဲ့ရင်တော့ python , ruby စတဲ့ framework နာမည်တွေက ရှိပြီးသားတွေ ဖြစ်နေတယ်။ ဒီနေ့ document စရေးဖို့ ကြိုးစားနေတာ။ CodeIgniter လိုမျိုး Document ပုံစံကို သဘောကျပေမယ့် HTML template အတွက် Dreamweaver လိုမျိုး Application သုံးနေရလိမ့်မယ်။ Dreamweaver ကလည်း ဝယ်မသုံးနိုင်။ ခိုးပြီးလည် းမသုံးချင်တော့ မသုံးဘူးပေါ့ ။ ဒါနဲ့ ကိုယ့်ဘာသာ ကိုယ် document ရေးဖို့ php နဲ့ပဲ Ava Framework ကို သုံးပြီး ရေးကြည့်အုံးမယ်။

Document က အရေးကြီးတယ်။ လက်ရှိ framework ကို အခြားသူတွေ ကောင်းကောင်း သုံးကြည့်ဖို့ စမ်းကြည့်ဖို့ document က လိုအပ်တယ်။ framework တစ်ခုလုံးက ကျွန်တော့်အတွက်ကတော့ အရမ်းပဲ လွယ်ကူ ရိုးရှင်းလွန်းတယ်။ သို့ပေမယ့် အခြားသူတွေအတွက် အဲလောက်တော့ မလွယ်ဘူးထင်တာပဲ။ MVC ဆိုတာ ဘာမှန်းမသိတဲ့ PHP developer တွေ ရှိသေးတယ်။ site တစ်ခုလုံးက MVC နဲ့ database ပိုင်းကိုတော့ PDO သုံးထားတယ်။ MVC ဆိုတာက pattern ပါပဲ။ ထွေထွေထူးထူးတော့ မဟုတ်ပါဘူးလေ။ အခုတော့ အိပ်တော့မယ်။ PHP ရေးရတာ objective c ရေးရတာထက် ပျော်ဖို့ ကောင်းတယ်။ objective c ရေးရင် ခဏခဏ memory leak ပြဿနာ ဖြစ်တယ်။ အဲဒါကိုလည်း သတိထားပြီး ရေးတတ်အောင် ကြိုးစားရအုံးမယ်။

Language တစ်ခုကနေ တစ်ခုကို ကူးပြောင်းပြီး လေ့လာတယ်ဆိုတာ လွယ်တော့မလွယ်ဘူး။ အဲလိုပဲ framework တစ်ခုကို အသဲစွဲအောင် ကြိုက်ပြီး သုံးနေတဲ့သူတွေ နောက်ထပ် framework တစ်ခုကို ပြောင်းသုံးဖို့ ဆိုတာ မလွယ်ဘူး။ CI ကို ကျွန်တော်လည်း အသေကြိုက်ခဲ့တယ်။ ဒါကြောင့် CI ကို တုပြီး ကိုယ့်ဘာသာကိုယ် framework ရေးရင်းနဲ့ နောက်ဆုံး Ava ဖြစ်သွားပြီး MZ user ကို Ava ပေါ်မှာပဲ ရေးဖြစ်သွားတာပေါ့။ Ava မှာ Restful ကို ထည့်ရမယ်။ အဲဒါ အရေးကြီးတယ်။ ဘာလို့လည်းဆိုတော့ Ornagai API က Restful ကို အသုံးပြုထားလို့ပဲ။

Python converter နဲ့ ပြောင်းတာ အဆင်မပြေတာနဲ့ ကိုယ့်ဘာသာ ရေးထားတဲ့ PHP ကို ပြန်စမ်းကြည့်ဖို့ စဉ်းစားထားတာ ကြာပြီ။ MZ ကို ပြောင်းဖို့ ကြည့်လိုက်တော့ နောက်ပိုင်းရေးထားတဲ့စာတွေက Latin မှာသွားသိမ်းထားတာ ࿽ လိုမျိုး ပုံစံတွေနဲ့ ဆိုတော့ PHP code နဲ့က အဆင်မပြေဘူး။ ကို ရာဗီ ကိုတော့ ပြောင်းတာ error တက်တာ ပြောထားသေးတယ်။ ဒေါက်တာ ကာဘွန် ရေးထားပေးတဲ့ java converter နဲ့တော့ မစမ်းရသေးဘူး။

MZ database က 500 MB လောက် ရှိတယ်။ ဒါကြောင့် ပြောင်းရခက်နေတာ။ Unicode ပြောင်းတာနဲ့ အတူတူ vanilla ကိုလည်း ပြောင်းမှာဆိုတော့ Vanilla ကို export လုပ်လိုက်တယ်။ file size က 200 MB လောက်ပဲ ရှိတော့တယ်။ အဲဒီ sql ကို ကိုရာဗီ ရဲ့ python နဲ့ ပြောင်းတာလည်း မရဘူး။ ဒါနဲ့ မနေ့က လေယာဉ်ပျံ ပေါ်မှာ php converter ကို ထပ်ပြီး update လုပ်ပြီး ရေးလိုက်တယ်။ အဓိက ပြဿနာက memory ပဲ။ ဒါနဲ့ *nix အဓိက ဆင်းပြီး shell script ရေးရင်း ကောင်းမလားလို့ တောင် စဉ်းစားသေးတယ်။ shell script ဆိုတာနဲ့ ဘာကို သွားစဉ်းစားမိလဲဆိုတော့ cat နဲ့ > filename ကို သွား သတိရတယ်။ cat ကတော့ *nix တွေမှာ file read တဲ့ အနေနဲ့ ခေါ်ပြီး php zg_cli.php > output.txt ဆိုရင် output အနေနဲ့ file write သွားပေးတယ်။ php က file write တာ မဟုတ်ပဲ os က သွား write ပေးတာ ဖြစ်တော့ နည်းနည်း ပိုမှန်တယ်။

လက်ရှိ ၂ မျိုးရေးထားတယ်။ windows တွေအတွက်ကတော့ file read တဲ့ အခါမှာ တစ်ကြောင်းဆီကို read ခိုင်းလိုက်တယ်။ အဲဒီတော့ memory သိပ် မသုံးတော့ဘူး။ အရင်တုန်းက ရေးထားတာထက် အများကြီး ပိုမြန်သွားတယ်။ *nix OS တွေအတွက်ကတော့ cat ကို file read ဖို့အတွက် သုံးလိုက်တယ်။ အဲဒါက ရိုးရိုး PHP file read တဲ့ဟာထက်တော့ အများကြီးမြန်တယ်။ နှစ်ခုလုံးကို > output.ext နဲ့ ပဲ file output ထုတ်လိုက်တယ်။ လေယာဉ်ပေါ်မှာ ရေးပြီးတော့ convert စမ်းကြည့်တာ အဆင်ပြေတယ်။ ࿽ တွေလည်း UTF-8 အနေနဲ့ ပြောင်းလိုက်တော့ အဆင်ပြေတယ်။ တစ်ခုပဲလိုတာက php.ini မှာ utf-8 support လုပ်အောင် config တော့ လုပ်ပေးရတယ်။ လေယာဉ်ပေါ်မှာ ရေးပြီးတော့ convert ပြောင်းကြည့်တာ အကုန် ??? တွေ ဖြစ်ကုန်တယ်။ အစက ဘာကြောင့်မှန်းမသိ။ နောက်မှ သတိရမိတာ php.ini မှာ utf-8 support မလုပ်ထားလို့ ဖြစ်မယ်ဆိုပြီး iso code ကို utf-8 ပြောင်းပေးလိုက်တော့ အဆင်ပြေသွားတယ်။ လေယာဉ်ကတော့ ၃ နာရီ စီးရတယ်။ လေယာဉ်တက်တာနဲ့ ဘာနဲ့ ဆိုတော့ တကယ်တန်း ရေးချိန်ကတော့ ၂ နာရီခွဲလောက်ပဲ ရတယ်။ လေယာဉ်ပေါ်မှာ ထမင်းစားပြီးချိန် ကတည်းက ရေးလိုက်တာတော့ ခဏလေးပဲ။ အရင်တုန်းက mysqluf8 converter ကြောင့်လည်း ပါမယ်။ ရွာပတ်သွားတာက php.ini မှာ utf-8 support လုပ်အောင် ပြင်ပေးရမယ်ဆိုတာ မသိလိုက်တာပဲ။ ?? တွေ ပြောင်းကုန်လို့ code မှားနေလားဆိုပြီး စမ်းနေသေးတာ။ အချိန် တော်တော် ကြာသွားတယ်။ ဘာပဲ ပြောပြော ဒီတစ်ခေါက် လေယာဉ်မှာ အချိန်ကုန်တာ မြန်တယ်လို့ ဆိုရမယ်။ ဘယ်လိုလို ရန်ကုန် ပြန်ရောက်သွားမှန်းတောင် မသိလိုက်ဘူး။ MZ site တစ်ခုလုံး UTF-8 လည်း ပြောင်းလို့ ပြီးသွားရော ရန်ကုန် လေယာဉ်ကွင်းမှာ ဆိုက်ဖို့အတွက် ကြေငြာနေပြီ။ အခုတော့ အကုန် အဆင်သင့်ဖြစ်နေပြီ။ MZ ကို unicode ပြောင်းဖို့ မြန်မာ နှစ်သစ်ကူး ကို စောင့်နေတာ။

MZ အသစ်က unicode + vanilla ဖြစ်လိမ့်မယ်။ အရင် username , password တွေ အတိုင်းပဲ။ အဲ.. ရေးထားတဲ့ code ကို ရန်ကုန်ရောက်တော့ github ပေါ်မှာ push လုပ်ဖို့ ကြိုးစားတော့ ssh က မဖွင့်ထားပေးဘူးပဲ။ စလုံး ပြန်ရောက်မှပဲ converter source code ကို ပြန်တင်ပေးတော့မယ်။ အခြားလူတွေလည်း ဒေါက်တာ ကာဘွန် ရဲ့ java converter ကို စမ်းကြည့်စေချင်တယ်။ မဆိုးဘူး။ သူလည်း တော်တော်မြန်တယ်။ file size အကြီးကြီးတော့ အခုထက်ထိ မစမ်းရသေးဘူး။ စလုံး ပြန်ရောက်မှပဲ စမ်းကြည့်တော့မယ်။

အခုတလော ရုံးမှာ framework ပြဿနာ တော်တော်လေး ရှုပ်သွားတယ်။ အဲဒီတော့ ကိုယ်ပိုင် framework တစ်ခု တည်ဆောက်ခြင်းရဲ့ ကောင်းခြင်း မကောင်းခြင်းတွေတော့ သဘောပေါက်သွားတာပေါ့။ framework တစ်ခု တည်ဆောက်တော့မယ်ဆိုရင် အခုနောက်ပိုင်းကတော့ MVC pattern နဲ့ ပဲ တည်ဆောက်ကြပါတယ်။ MVC Pattern အတွက် တစ်ယောက်နဲ့ တစ်ယောက် approve မတူကြဘူးဗျ။ ကျွန်တော်ကတော့ Symfony နဲ့ CI ပဲ သုံးဖူးတော့ သူတို့ ၂ ခု မတူညီတာကို သိတယ်။ ROR ကတော့ မေ့သွားပြီလို့ ဆိုလို့ရမယ်။ ROR ကို ခဏလောက်ပဲ လုပ်ဖူးတယ်။ နောက်ပိုင်း စာအုပ်က version နဲ့ ထွက်တဲ့ version မတူတာနဲ့ ရှေ့မဆက်ဖြစ်တော့တာ အခုထက်ထိပဲ။ အဲ… လွဲကုန်အုံးမယ်

Framework လုပ်တော့မယ်ဆိုရင်တော့ MVC အပြင် SEO user friendly ဖြစ်ဖို့အတွက်လည်း စဉ်းစားဖို့လိုပါတယ်။ ကျွန်တော်ကတော့ CI ရဲ့ approve ကို သဘောကျပါတယ်။

http://www.domain.com/index.php/controller/action

အဲဒီ ပုံစံနဲ့သွားပါတယ်။ index.php နောက်က controller လာတယ်။ ပြီးတော့ action လာတယ်ပေါ့။ Symfony မှာဆိုရင်တော့

http://domain.com/controller.php/action

သူကတော့ index.php နဲ့ မဟုတ်တော့ဘူး။ သို့ပေမယ့် အတူတူပါပဲ။ Controller လာတယ်။ action လာတယ်ပေါ့။

ပုံမှန် သမာရိုးကျ MVC pattern တွေက Model ကနေ ဖြစ်စေ Controller က ဖြစ်စေ View ကို ခေါ်ကြပါတယ်။ နောက်ပြီး View က View ပါ။ Designer တစ်ယောက်အတွက် လွယ်လွယ်ကူကူ ပြုပြင်နိုင်ရပါမယ်။ အချို့ framework စတင်ဆောက်တဲ့ သူတွေဟာ View ကို OO တွေနဲ့ တည်ဆောက်ပြီး ခေါ်ယူသုံးစွဲရတာလေးတွေ ဖြစ်တတ်ပါတယ်။ CI ကော Symfony မှာကော View က View အနေနဲ့ပဲ တည်ရှိတာပါ။ View တစ်ခုကို ဆောက်ဖို့ ဘာမှထွေထွေထူးထူးမလိုပါ။ အချို့ framework တွေကတော့ template system တွေကို သုံးကြပါတယ်။

View ကို OO နဲ့ ရောတယ်ဆိုတာက view ဆိုတာကြီးက class ဖြစ်ပြီး function တွေနဲ့ Model တို့ Controller တို့လို ဖြစ်ကုန်တာပါ။ ဥပမာ header ခေါ်မယ်ဆိုရင် ViewClass::header(); ဆိုပြီး ဖြစ်ကုန်တာမျိုးပေါ့။ CI မှာဆိုရင်တော့ view ကို class အနေနဲ့ တည်ရှိတာမဟုတ်ပဲ လွယ်လွယ်ကူကူ ခေါ်လို့ရပါတယ်။ $this->load->view(“view_file.php”,$data_array); ဆိုပြီး ခေါ်လိုက်ပါတယ်။ တနည်းပြောရင် view က file အနေနဲ့ပဲ တည်ရှိတယ်။ သူက သီးသန့် ဖန်တီးဖို့ လိုတဲ့ class ကြီးမဟုတ်ဘူးပေါ့ဗျာ။ ဘာလို့လည်းဆိုတော့ designer က view အပိုင်းမှာ ပြင်မှာတွေ ထည့်တာတွေ လုပ်မှာမို့ပါ။ တကယ်လို့ Class ကြီးသာ ဖြစ်နေရင် Designer အနေနဲ့ ပြင်ရခက်ပြီလေ။ သူက coding တွေ looping တွေကို အဲလောက်ထိ သိတဲ့ သူတွေမှ မဟုတ်တာ။ Web Design ကိုသာ professional တတ်ကျွမ်းကြတာလေ။

ကျွန်တော်တို့ Framework ဆောက်မယ်ဆိုရင် .htaccess ကို စဉ်းစားဖို့လိုပါတယ်။ ကျွန်တော့် API work မှာကတော့ အောက်ကလို .htaccess ကို သုံးပါတယ်။
[lang name="shell"]
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?r=$1 [L,QSA]
[/lang]

အဲဒီမှာ ကျွန်တော်ရေးထားတာက ရောက်လာတဲ့ URL က လက်ရှိ ရှိနေတဲ့ file မဟုတ်ခဲ့ရင် ဒါမှမဟုတ် လက်ရှိ ရှိနေတဲ့ directory မဟုတ်ခဲ့ရင် index.php?r= ဆိုပြီး လွှဲလိုက်တာပေါ့။

ဥပမာ။။

http://www.mydomain.com/sample/test

ဆိုရင်

မြင်ရတော့ http://www.mydomain.com/sample/test ဖြစ်ပေမယ့် လက်တွေ့ အလုပ်လုပ်သွားတာကတော့ http://www.mydomain.com/index.php?rt=sample/text ပါ။ ဒါကြောင့် index.php ကနေ $_GET['r'] နဲ့ လှမ်းဖတ်။ ပြီးတော့ / နဲ့ ပိုင်းပြီး ပထမဆုံးက controller , ဒုတိယက action ဆိုပြီး ခွဲလိုက်လို့ရပါတယ်။ အဲဒါက  apache မှာ mod_rewrite ရှိနေလို့ပါ။ apache မှာ mod_rewrite မရှိဘူး သို့မဟုတ် IIS server မှာဆို ဘယ်လိုလုပ်မလဲ။ ကိုယ့် framework က IIS server နဲ့ ဆိုသုံးမရတော့ဘူးလား ဆိုပြီး စဉ်းစားဖို့ ဖြစ်လာပါတယ်။ ရပါတယ်။ idea လေးကို နည်းနည်းလေး ပြောင်းလိုက်တာပေါ့။

http://www.mydomain.com/index.php/sample/test

ဆိုပြီး ကျွန်တော်တို့တွေ url ကို ပြောင်းလိုက်တယ်။ PHP နဲ့ $_SERVER['REQUEST_URI'] ကနေ address ကို လှမ်းဖတ်ပြီး index.php နောက်က ဟာတွေကို ဆွဲထုတ်လိုက်ပါတယ်။ ပြီးတော့ ထုံးစံအတိုင်း controller နဲ့ action ကို ခွဲလိုက်တာပေါ့။

တကယ်တန်းတော့ htaccess file တစ်ခုတည်းနဲ့ url ကို ပြောင်းလို့ရပေမယ့် အချို့တွေက .htacces file မှာ url တစ်ခုခြင်းဆီ ထည့်တာတွေ ရှိတတ်ပါတယ်။ ဘယ်လိုမျိုးလဲဆိုတော့ ဒီ url လာရင် ဒီ file ကိုသွားဆိုပြီးတော့။ SEO URL friendly တော့ ဖြစ်ပေမယ့် ရေရှည်အတွက်ကတော့ မကောင်းဘူးပေါ့။ နောက်ပြီး url ကနေ controller နဲ့ action ကို ရပြီးတဲ့နောက်မှာ ဘာပြဿနာလဲဆိုတော့ controller နဲ့ action ကို ခေါ်တဲ့ ပြဿနာပါ။ ပုံမှန်အားဖြင့် PHP မှာ class ကို variable နဲ့ ခေါ်လို့ရပါတယ်။ အဲဒါကို မသိတဲ့အခါမှာ controller တွေ action ကို switch case နဲ့ စစ်ပြီး တစ်ခုခြင်းဆီ ခေါ်ပါတယ်။ အဲဒီတော့ ခုနက htaccess file လို ပြဿနာပဲ ထပ်ကြုံရမှာပေါ့။

ဟုတ်ပြီ။ htaccess ကတော့ ရပြီ။ အဲဒီမှာ နောက်ထပ် ပြဿနာတစ်ခု ထပ်ကြုံရမယ်။ ဒါပေမယ့် တော်တော်များများ ဂရုမထားမိကြဘူး။

[lang name="shell"]RewriteCond %{REQUEST_FILENAME} !-d[/lang]

ဆိုတဲ့ အကြောင်းကြောင့်ပါ။ အဲဒါက directory မဟုတ်ခဲ့ရင်လို့ပြောထားတာပါ။ ဥပမာ။ web_folder ဆိုတဲ့ folder အောက်က file တွေကို www.domain.com/web_folder/default.css ဆိုပြီး ခေါ်လို့ရအောင်ပေါ့။ အဲဒါ ဘာပြဿနာ ဖြစ်လဲလို့ မေးစရာ ဖြစ်လာတယ်။ ဟုတ် ပြဿနာပါ။ framework တည်ဆောက်တဲ့အခါမှာ file တွေ အများကြီးအပြင် folder တွေပါ များလာတယ်။ include , system, library, application စသည်ဖြင့် folder တွေ များလာတယ်။ အဲဒီ folder တွေ အားလုံးက www.domain.com အောက်မှာပဲ ရှိတယ်။ ဒီတော့ www.domain.com/include/ ဆိုပြီး ခေါ်လို့ရပါတယ်။ အဲဒီတော့ ဘာဖြစ်လဲ။ index.html နဲ့ ထည့်ပြီး ပိတ်ထားမှာပေါ့လို့ပြော ပါလိမ့်မယ်။ ဟုတ်ပါတယ်။ index.html ထည့်ရပါမယ်။ သို့ပေမယ့် အဲလို folder တွေ များသွားတော့ သင့် Controller က အကန့်အသတ် တွေဖြစ်သွားလိမ့်မယ်။

ကိုယ့် framework က www.domain.com/include/myaction ဆိုပြီးခေါ်လို့မရတော့ဘူး။ ဘာလို့လည်း include ဆိုတဲ့ folder ရှိနေတယ်လေ။ အဲဒီလို ပြဿနာကို ဖြေရှင်းဖို့အတွက် CI နည်းက တော်တော်ကောင်းပါတယ်။ framework နဲ့ ဆိုင်တာ အကုန်လုံးကို system ဆိုတဲ့ folder အောက်မှာ ထည့်လိုက်တယ်။ အဲဒီတော့ index.php နဲ့ system folder ပဲ domain.com အောက်မှာ ရှိတော့တယ်လေ။ system ဆိုတဲ့ controller name ကလွဲလို့ ကြိုက်တဲ့ controller နာမည်ပေးလို့ရပြီလေ။

PHP မှာ လူသုံးနည်းပြီး ကောင်းတဲ့ feature တစ်ခုက variable က data ကို action အနေနဲ့ ခေါ်လို့ရတာပဲ။ အောက်က code လေးကို ကြည့်ုလိုက်ပါ။

[lang name="php"]

$controller=”sampleController”;

$action = “action”;

$c=new $controller();

$c->$action();

[/lang]

အဲဒီ code ကို ကြည့်လိုက်ပါ။ ကျွန်တော် class နဲ့ action ကို variable နဲ့ dynamic ခေါ်ထားတာပါ။ အများအားဖြင့် အဲလို dynamic ခေါ်လို့ရတယ်ဆိုတာ သိပ်မသိကြဘူး။ အဲဒီအတွက်ကြောင့် framework ရေးတဲ့အခါမှာ controller  နဲ့ action ကို condition တွေနဲ့ စစ်ပြီး သီးသန့်စီ ခေါ်ထုတ်တာတွေ ဖြစ်ကုန်ပါတယ်။ ကျွန်တော်လည်း ကိုယ်ပိုင် framework ရေးရင်း ပြုပြင်ရင်း နဲ့ ဒီလို အကြောင်းအရာလေးတွေ ကို သိလာတာပါ။ CI သို့မဟုတ် အခြား framework တစ်ခုခုကို လေ့လာပြီးပြီ။ သုံးလည်း သုံးတတ်နေပြီ။ ကိုယ်ပိုင် framework စရေးတော့မယ်ဆိုရင် မစခင် အဲဒါလေးတွေ သိထားခြင်းအားဖြင့် ကိုယ်ပိုင် framework ရေးတဲ့ အခါမှာ အထောက်အကူဖြစ်မယ်လို့ထင်ပါတယ်။ ဒီ post ကတော့ ကျွန်တော့် အတွေ့အကြုံအရ ရေးထားတာပါ။ အခြားလူတွေနဲ့ idea တူချင်မှ တူပါလိမ့်မယ်။ ကျွန်တော်က CI သမားဖြစ်တော့ idea တွေက CI ကနေ ဆင်းသက်လာတယ်ဆိုတာ မငြင်းပါဘူး။ အခြား idea များကို ဆွေးနွေးချင်တယ်ဆိုရင်လည်း comment မှာ ဝင်ပြီးဆွေးနွေးလို့ရပါတယ်ဗျာ။