ဒီေန႕ emo ေလး နဲ႕ facebook မွာ စကားေျပာေတာ့ Concept ကို ဘယ္မွာ သြားသင္ရမလဲလို႕ ေမးတယ္။ သူ ဝါသနာပါတာက Designer။ PHP ေလ့လာဖို႕လိုလားလို႕ ေမးေတာ့ ကၽြန္ေတာ္ကလည္း ေျပာပါတယ္။ သိရံုေလာက္ပဲ လံုေလာက္တယ္။ ေတဇာ အေျဖက ပိုရွင္းတယ္။ SmashingMag မွာ Programming Language အေၾကာင္းပါလားလို႕ ေမးလိုက္ေတာ့ အေျဖက ရွင္းသြားတာပဲ။
Continue Reading »

8 people like this post.

Unlike

Framework ေတြပါ ထပ္မံျဖည့္စြက္ထားပါတယ္။ စာလံုးေပါင္းမွားေနတာေတြ ျပန္ျပင္ထားပါတယ္။ web designer မ်ားအေနနဲ႕ လုိအပ္တာမ်ားကို ျဖည့္စြက္ေျပာေပးေစလိုပါတယ္။ သက္ဆိုင္ရာ developer မ်ားလည္း မွားေနတာေတြ ေထာက္ျပႏိုင္ပါတယ္။ ကၽြန္ေတာ္က PHP တစ္ခုပဲသိပါတယ္။

1 person likes this post.

Unlike

web လိုင္းမွာ ရိွတဲ့ အပိုင္းကို အနည္းဆံုး က်ဳံ႕ျပီး ေရးဆြဲထားပါတယ္။ အျခားအပိုင္းေတြ ထပ္ျဖည့္လိုက္ရင္ ပိုရႈပ္ကုန္မွာဆုိးလို႕ အရွင္းဆံုးပိုင္းကို ေရးထားပါတယ္။ ကိုယ္အခု ဘယ္ေရာက္ေနျပီ။ ဘယ္ကို ဆက္သြားမလဲ။ ဘာေတြ လုပ္ခ်င္လဲဆိုတာ စဥ္းစား ဆံုးျဖတ္ႏုိင္ေအာင္ပါ။

2 people like this post.

Unlike

960 css framework ကို သံုးျပီး HTML Layout ခ်ပံုပါ။

3 people like this post.

Unlike

MZ မွာေမးထားတာေလးကို blog မွာလည္း အျခားသူေတြ သိေအာင္ ထပ္ေျဖေပးလိုက္ပါတယ္။

က်ေတာ္က ဒီလိုနားလည္ ထားတယ္…
ဥပမာ . Facebook မွာဆိုရင္ Game ေတြ အမ်ားၾကီးပါတယ္။ အဲဒီ Game ေတြက သာမာန္ web programming နဲ႔ ေရးလို႔ မရဘူးဗ်ာ။ အဲဒါကို တျခား java ျဖစ္ျဖစ္ c ျဖစ္ျဖစ္ ေရးထားမယ္ေပါ့။ အဲဒီ အေျခေနမွာဆုိရင္ ကို ေရးလိုက္တဲ့ဟာက my application ျဖစ္သြားျပီေပါ့။ အဲဒါကုိမွ web site မွာတင္ခ်င္တယ္ဆိုေတာ့ my application ကေန web application ကိုေျပာင္းဖို႔ အတြက္ web service ကို အသံုးျပဳတာလို႔ က်ေတာ္က နားလည္ ထားတယ္။ အဲဒီ အေတြးက မွန္ပါသလား။

ခင္မင္စြာျဖင့္ စိုင္းထက္

အဲလိုမဟုတ္ပါဘူး။

facebook မွာေရးခ်င္တယ္ဆို၇င္ fbml ကို သံုးျပီးေတာ့ ေရးရမယ္။ အဆင္အေျပဆံုးကေတာ့ PHP နဲ႕fbml ကို တြဲသံုးျပီး ေရးတာေပါ့။ အဲလိုေရးဖို႕အတြက္ အရင္ဆံုး facebook မွာ API key ယူရတယ္။ API key ရျပီးေတာ့မွ PHP ကေနဆုိရင္ facebook phplibrary နဲ႕ fbml ကို သံုးျပီးေရးရတယ္။ app run တာကေတာ့ ကိုယ့္ host မွာ။ ျပတာကေတာ့ facebook ကေနေပါ့။ API နဲ႕ FBML က အလုပ္လုပ္သြားေပးတာပါ။ API ဆိုတာက facebook နဲ႕ ကိုယ္ေရးထားတဲ့ API ကို ၾကားခံေဆာင္ရြက္ေပးတာပါ။ အဲလို ေဆာင္ရြက္ေပးဖုိ႕အတြက္ ကိုယ္က facebook site မွာ app register လုပ္ရတယ္။ အဲဒီ အခါ API key ရလာမယ္။ API key ရမွ ဆက္သြယ္လုိ႕ရမယ္။ API key ဆိုတာက security သေဘာမ်ဳိးနဲ႕ သံုးတာပါ။ ဥပမာ API ကို အသံုးျပဳျပီး facebook မွာ ၅ မိနစ္ တစ္ခါ post ေတြ အလိုအေလ်ာက္တင္ေနလို႕ရတယ္။ အဲဒီအခါ facebook က ခြင့္မျပဳဘူးဆုိရင္ ဘယ္ API က လာတယ္။ အဲဒီ API ကို ဘယ္ user က register လုပ္ထားလဲဆိုတာကို သိျပီး ban လုိက္လို႕ရတယ္။

oAuth က နည္းနည္းရႈပ္တယ္။ နည္းနည္းပိုရွင္းတဲ့ AuthSub ကို ေျပာတာ ပိုေကာင္းမယ္။ AuthSub ဆုိတာက google ရဲ႕ နည္းပညာပါ။ oAuth ကို အေျခခံထားတာပဲ။ user ေတြရဲ႕ contact list ကို site တစ္ခုကေန ယူေတာ့မယ္ဆိုပါဆုိ႕။ အဲဒီလိုအခါမွာ user ရဲ႕ username နဲ႕ pwd ထည့္ရမယ္။ အဲဒီ site က ယံုၾကည္စိတ္ခ်ရမႈ ရိွခ်င္မွရိွမယ္။ အဲလိုမ်ဳိးေတြအတြက္ oAuth ေပၚလာတာပါ။ AuthSub က oAuth ထက္ ပိုရွင္းေအာင္ လုပ္ထားေပးတယ္။

Google Contact list ကို web site က request လုပ္လုိက္ရင္ google website ကိုေရာက္သြားမယ္။ google website မွာ user က login ဝင္။ ဝင္ျပီးတဲ့အခါမွ google က ဒီ site က contact list ကို ေတာင္းေနျပီ။ မင္းေပးမွာလားလုိ႕ ေမးေရာ။ ကိုယ္က ေပးလိုက္လို႕ေျပာတဲ့အခါမွ google ကေန ေပးလုိက္တာ။ အဲဒီ အခါမွာ လာခဲ့တဲ့ site ကိုေရာက္သြားေရာ။ အဲဒီအတြက္ session token ပို႕လိုက္တယ္။ username နဲ႕ pwd ေတာ့ မပို႕ဘူး။ session token ျဖစ္တဲ့အတြက္ အခ်ိန္အၾကာၾကီးမရတဲ့အတြက္ username နဲ႕ pwd ကို site က ခိုးလုိ႕မရေတာ့ဘူး။ user အတြက္လည္း စိတ္ခ်ရတယ္။ site အတြက္လည္း user ရဲ႕ ယံုၾကည္မႈကိုရတယ္။

တနည္းေျပာရင္ သာမာန္ web programming နဲ႕ပဲ ေရးရတာပဲ။ facebook app လည္း သာမာန္ web programming နဲ႕ပဲေရး၇တာပဲ။ သက္ဆိုင္ရာ API function ေတြကိုေတာ့ ယူသံုးရတယ္။ ဥပမာ။ facebook API function ကေန friendlist ေတြရႏိုင္တယ္။ user information ေတြရႏိုင္တယ္။ register လုပ္တယ္ဆိုတာက user information ရဖို႕ပဲ။ facebook connect သံုးလိုက္ေတာ့ user လည္း register လုပ္စရာမလုိေတာ့ဘူး site ကလည္း information ရတယ္။ အဲလိုမ်ဳိး web service ေတြက အလုပ္လုပ္ေပးတာ။

ဥပမာ။ ။ ကၽြန္ေတာ္ လက္ရိွေရးေနတဲ့ ornagai ဆိုပါဆို႕။ API ကေတာ့ ေရးေနဆဲ မျပီးေသးဘူး။ API register လုပ္ထားတဲ့သူက ornagai ရဲ႕ စာလံုးေတြကို အျခား site ကေန retrieve လုပ္လုိ႕ရတယ္။ ကၽြန္ေတာ့္ site ကို လာစရာမလုိပဲနဲ႕ API function ေခၚျပီး retrieve လုပ္လို႕ရမယ္။ အဲဒီအတြက္ အျခား site ေတြကလည္း စာလံုးတစ္ခုကို mouse ေထာက္လိုက္တာနဲ႕ ornagai dictionary API ကို ယူျပီး ornagai ကေန စာလံုးရွာျပီး return ျပန္လာမယ္။ ျပန္လာတဲ့စာလံုးကို ေရးထားတဲ့ app ကေန ရယူျပီး ျပန္ျပီးေပးတယ္။

Google Map API ကို အသံုးျပဳျပီးေတာ့ ေျမပံုေပၚမွာ ပံုေတြထည့္တာ point ေတြထည့္တာ စတာေတြလုပ္လုိ႕ရတယ္။

http://map.etelegram.net.mm

ဆိုရင္ Google Map API သံုးျပီးေတာ့ ျမန္မာႏိုင္ငံက ျမိဳ႕ေတြကို point ေတြနဲ႕ ခ်ထားတာ။ အဲလိုလုပ္ဖုိ႕ google map api key ကို အရင္ဆံုး ယူရတယ္။ API key တစ္ခုက register လုပ္ထားတဲ့ site ကပဲ ေခၚလို႕ရတယ္။ http://map.etelegram.net.mm/ က API key ကို http://map.mymap.com.mm ကေန ေခၚလို႕မရဘူး။  API key တစ္ခု ရယူဖုိ႕က တစ္ခုနဲ႕ တစ္ခုမတူဘူး။ Google Map ဆိုရင္ site ပဲလိုေပမယ့္ facebook ဆိုရင္ facebook user ျဖစ္ရမယ္။ သံုးမယ္ website လည္းလိုတယ္။

ဒါေပမယ့္ Twitter အသံုးျပဳတဲ့ REST လိုက်ေတာ့ ဘာမွ မလုိျပန္ဘူး။ oAuth လုိတဲ့အပိုင္းရိွသလို မလိုတဲ့ အပိုင္းရိွတယ္။ user တစ္ေယာက္ရဲ႕ tweet ေတြကို ထုတ္ၾကည့္ခ်င္ရင္ twitter ကေပးထားတဲ့ REST web service ကေန ထုတ္လိုက္လို႕ရတယ္။ ဘယ္ site ကေန ျဖစ္ျဖစ္ ဘယ္ app ကေန ျဖစ္ျဖစ္ ထုတ္ယူလို႕ရပါတယ္။ ဒါေပမယ့္ ကိုယ့္ status တင္ေတာ့မယ္ဆိုရင္ oAuth လိုအပ္ပါတယ္။ oAuth သေဘာတရားက AuthSub သေဘာတရားနဲ႕ ဆင္တူပါတယ္။ SOAP ဆိုတာက ထပ္ရိွေသးတယ္။ SOAP ကေတာ့ အခုခ်ိန္မွာ ေခတ္သိပ္မရိွေတာ့ဘူး။ သံုးတဲ့လူလည္း ေတာ္ေတာ္နည္းသြားျပီ။

API ေတြ web service ေတြေၾကာင့္ ဘာလုပ္လို႕ရလဲဆိုေတာ့ sync ေတြ လုပ္လုိ႕ရလာတယ္။ ဥပမာ Google Calendar ဆိုပါဆုိ႕။ Google Calendar က online ပဲရတယ္။ App တစ္ခုေရးျပီး Google Clanedar API ကို ယူသံုးလိုက္ျပီး data ေတြ အကုန္ဆြဲခ်လိုက္လို႕ရတယ္။ ေနာက္ျပီးေတာ့ APP မွာ ထည့္ထားတာေတြကို Google Calendar API ကေန တင္ေပးလိုက္လုိ႕ရတယ္။ Syn လုပ္ျပီးသြားရင္ Google Calendar မွာရိွတာေတြနဲ႕ ကိုယ့္ app မွာရိွတာေတြနဲ႕ အတူတူျဖစ္သြားျပီ။

ဒီေလာက္ဆို၇င္ web service , web API ေတြအေၾကာင္း နားလည္ျပီလို႕ ထင္ပါတယ္။

5 people like this post.

Unlike

Firebug အတြက္ add-on ေလးပါ။ မဆိုးဘူး။ ကိုယ္႔ code ထဲမွာ ျမန္ေအာင္ ဘယ္အပိုင္းေတြလုပ္ဖို႕လိုလဲဆိုတာကို analyst လုပ္ေပးတယ္။ firefox မွာ အရင္ဆံုး firebug သြင္းထားဖို႕ေတာ့ လိုတယ္။ ကၽြန္ေတာ္႔ code ေတြမွာ cache မပါတာကို အခုမွ သတိထားမိတယ္။ ေနာက္ပိုင္း cache ေတြထည့္ျပီး ေရးမွျဖစ္မယ္။
http://code.google.com/speed/page-speed/docs/using.html

Like

Unlike

Developer သည္ Developer သာျဖစ္သည္။ Web Designer သည္ Designer သာျဖစ္သည္။ ထိုႏွစ္ခုပူးေပါင္းလိုက္ေသာအခါ website ဟူျပီး ျဖစ္လာသည္။ ထို႔ေၾကာင့္ Developer သည္ design idea ရိွမည္မဟုတ္သလို design ပိုင္းကို နားလည္သည္မဟုတ္။ သိရံုသာသိသည္။ သူေရးသားရမည့္ code ကိုသာ နားလည္တတ္ကၽြမ္းသည္။ programmer တစ္ေယာက္သည္ designer ေပးေသာ design ကို ေရးထားေသာ code ႏွင့္ အလြယ္တကူပူးေပါင္းတတ္သည္။ ထို႔ေၾကာင့္ Developer သည္ Photoshop သံုးတတ္ခ်င္မွ သံုးတတ္မည္။ အေရာက္ ေရြးခ်ယ္တတ္ခ်င္မွ တတ္မည္။ သို႔ေသာ္ Designer လိုခ်င္တဲ့ ပံုစံကိုေတာ့ ရေအာင္ ေရးႏိုင္သူျဖစ္သည္။ Designer နဲ့ ညိွနိႈင္းကာ ေဆာင္ရြက္ရသည္။ Continue Reading »

Like

Unlike

အရင္က စမ္းမယ္ စမ္းမယ္နဲ့ မစမ္းျဖစ္လိုက္ဘူး.. ဒီေန့မွပဲ စမ္းျဖစ္တာ….

ကြ်န္ေတာ္တို႔ေတြ web design ေတြဆဲြတဲ့အခါမွာ font ေတြကလည္း အေရးပါလွပါတယ္။ header ကို ဘာ font သံုးမယ္။ paragraph ကို ဘာ font သံုးမယ္ဆိုျပီး ကြ်န္ေတာ္တို႔ေတြ ေရြးခ်ယ္ရတယ္။ အရင္က ကြ်န္ေတာ္တို႔ေတြမွာ ေရြးခ်ယ္စရာ မ်ားမ်ားမရိွဘူး။ Windows မွာ default ပါတဲ့ font နဲ့ mac မွာ default ပါတဲ့ font ေတြျဖစ္ဖို႔ အေရးၾကီးတယ္။ ေနာက္မို႔ဆို ကိုယ္႔ design က မလွပဲ ျဖစ္သြားမယ္။ ဒါေၾကာင့္ အမ်ားအားျဖင့္ Verdana,Times New Roman,Tahoma,Arial,Georgia စတာေတြေလာက္ပဲ ေရြးလို႔ရတယ္။ အမ်ားၾကီးေရြးခ်ယ္စရာမရိွဘူးေလ။ သူတို႔ စက္ထဲမွာ font မရိွရင္ အလကားပဲ။ ဒါေၾကာင့္ designer ေတြကေတာ့ browser ေတြထဲမွာ font embed ျဖစ္ေစခ်င္ၾကတယ္။
Continue Reading »

Like

Unlike

ကြ်န္ေတာ္ အရင္တုန္းက ကိုယ္႔ကိုယ္ developer တစ္ေယာက္လို႔ မဆိုရဲဘူး။ ဘာလို႔လည္းဆိုေတာ့ အရံသင့္ script ေတြကိုပဲ အသံုးမ်ားခဲ့တယ္ေလ။ Joomla , Wordpress စတာေတြကိုပဲ အဓိကသံုးခဲ့တယ္။ ကိုယ္တိုင္ own tune ေရးတယ္ဆိုတာ မရိွပါဘူး။ အခုတေလာ JQuery ကိုေလ့လာရင္း own tune ေလးေတြ ေရးျဖစ္တယ္။ CMS ၾကီး တစ္ခုေတာ့ ေရးဖို႔ အခ်ိန္မေပးႏိုင္ဘူးေပါ႔ ။ ဒါေပမယ္႔ ကိုယ္ လိုခ်င္တဲ့ဟာ ကို ကိုယ္ကိုယ္ တိုင္ဖန္တီးရတာ ေပ်ာ္ဖို႔ေကာင္းတယ္။ ေရးရတာ သိပ္ခက္ခဲရင္ ကိုယ္တိုင္ေရးလိုက္တာ ပိုေကာင္းတယ္ဗ်။ ကိုယ္႔ဘာသာကိုယ္ ေကာင္းေကာင္းျပဳျပင္ႏိုင္တယ္။ လိုအပ္သလို ထပ္ျဖည့္ႏိုင္တယ္။ အျခား service ေတြထပ္လုပ္ႏိုင္တယ္ေလ။ ကြ်န္ေတာ္တို႔အေနနဲ့ web developer တစ္ေယာက္ျဖစ္ဖို႔ ဘာေတြ လိုအပ္လဲ။ ဘာေတြ ျပင္ဆင္ဖို႔လိုလဲ။ ဘာေတြ ေလ့လာဖို႔လဲ။
Continue Reading »

6 people like this post.

Unlike

အခုအခ်ိန္မွာ OS ေတြ အျပိဳင္အဆိုင္ ျဖစ္ေနၾကျပီ။ Windows , Mac , Linux ဆိုျပီး အျပိဳင္အဆိုင္ျဖစ္ေနၾကပါတယ္။ ဒါက desktop ေပၚမွာ ျပိဳင္ဆိုင္မႈေတြေပါ႔။ ဒါ႔အျပင္ hand phone ေပၚမွာလည္း ျပိဳင္ဆိုင္မႈေတြ စပါျပီ။ Google ရဲ့ android ကလည္း စိတ္ဝင္စားစရာပါ။ အကုန္လံုးက သိၾကပါတယ္။ Desktop ေပၚျပီးရင္ Web ေပၚေရာက္လာမယ္။ application ေတြကို web ေပၚမွာ run မယ္။ ျပီးရင္ hand phone နဲ့ web တဲြမယ္။ အဲဒီအတြက္ hand phone ေလာကရဲ့ OS အတြက္ စတင္ျပိဳင္ဆိုင္ေနၾကပါျပီ။ android က open handset ျဖစ္ျပီး hand phone OS အတြက္ စိတ္ဝင္စားမႈ တစ္ခုပါ။ သူေအာင္ျမင္မယ္လို႔လည္း ေျပာမရလို႔ ေအာင္ျမင္မွာ မဟုတ္ဘူးလို႔လည္း ေျပာမရဘူးဗ်။ ဘာျဖစ္လို႔လည္းဆိုေတာ့ Linux လည္း ေအာင္ျမင္စရာလို႔ ထင္ရေပမယ္႔ Windows ေလာက္မေအာင္ျမင္ေသးတာအမွန္ပါ။ ဒါေပမယ္႔ အနာဂတ္အတြက္ linux ကို တျဖည္းျဖည္း စိတ္ဝင္စားလာၾကပါတယ္။

အကုန္လံုးက hand phone အတြက္ OS ေစ်းကြက္ဆီကို ဦးတည္ေနၾကပါတယ္။ windows mobile , iPhone , Symbian OS က ေစ်းကြက္ရိွျပီးသားေတြျဖစ္ျပီး အခု android ကလည္း စတင္ထိုးေဖာက္ေတာ့မွာပါ။

ကြ်န္ေတာ္တို႔ အနာဂတ္ကို ေမွ်ာ္ၾကည့္ရေအာင္။ ကြ်န္ေတာ္ျမင္တဲ့ အနာဂတ္က ကြ်န္ေတာ္႔အျမင္မွာ။ မျဖစ္ႏိုင္ဘူးလို႔လည္း ဆိုခ်င္ဆိုပါ။ ကြ်န္ေတာ္ကေတာ့ ကြ်န္ေတာ္႔ အျမင္ကို ပြင့္ပြင့္လင္းလင္း ေရးသားမွာပါ။

အမွန္တိုင္းဆိုရင္ ကြ်န္ေတာ္တို႔ေတြဟာ OS ကို အေလးထားလာတာကိုေတြ႕ရမွာပါ။ OS ရိွမွ application ေတြ အလုပ္လုပ္ႏိုင္မွာေလ။ ဒါဆို OS မရိွရင္ မျဖစ္ဘူးေပါ႔။ ေနာက္တစ္ခ်က္က internet ။ ကြ်န္ေတာ္တို႔ေတြဟာ ဘယ္ OS ပဲသံုးသံုး internet သံုးလို႔ရပါတယ္။ အနာဂတ္မွာေကာ။ OS ရိွမွ internet သံုးလို႔ရမွာလား။ OS မရိွပဲ internet connection ခ်ိတ္လို႔မရဘူးလား။

အဲဒီအတြက္ hand phone ကိုၾကည့္ရေအာင္။ hand phone OS ေသးေသးေလး နဲ့ internet ခ်ိတ္လို႔ရတယ္။ ေနာက္ျပီး အမ်ိဳးမ်ိဳးေသာ device ေတြကလည္း internet ခ်ိတ္လို႔ရပါတယ္။ ဒါဟာ စိတ္ဝင္စားစရာနည္းပညာပါ။ ကြ်န္ေတာ္တို႔ PC ေတြကေကာ windows မတက္လာပဲ…. Linux မတက္လာပဲ… internet သံုးလို႔မရဘူးလား။ မရပါဘူး။ အခုခ်ိန္ထိ မရေသးပါဘူး။ တစ္ခ်ိဳ႕ device ေတြေတာ့ ၾကားဘူးတယ္။ computer မဖြင့္ပဲ email စစ္တာေတြ internet ၾကည့္တာေတြ လုပ္လို႔ရတယ္တဲ့။ ဒါေပမယ္႔ လူေတြ သိပ္ဂရုမျပဳမိသလို သိသိသာသာ ေအာင္ျမင္မႈလည္း မရခဲ့ပါဘူး။

ကြ်န္ေတာ္႔အျမင္ေတာ့ ေနာက္တခ်ိန္ PC hardware ေတြက windows မဖြင့္ပဲနဲ့ internet တိုက္ရိုက္ ခ်ိတ္ဆက္လာႏိုင္ေလာက္ပါမယ္။ ဘာမွ သံုးလို႔မရေပမယ္႔ browser ေလးတစ္ခုဖြင့္လို႔ရရံုနဲ့ လံုေလာက္ပါတယ္။ OS မရိွပဲ ဘာလုပ္မွာလဲလို႔ ေမးစရာရိွတယ္။

OS ကိုဘာလို႔သံုးတာလဲ။ သာမာန္ user အတြက္ သီခ်င္း နားေထာင္ ၊ video ၾကည့္ ၊ အေခြကူး ၊ ပံုဆဲြ အျပင္ အျခား အမ်ိဳးမ်ိဳးေသာ အရာေတြအတြက္ေပါ႔။ Web ေပၚမွာ အခုအခ်ိန္ အရာအားလံုးကို မစြမ္းေဆာင္ႏိုင္ေသးပါဘူး။ စြမ္းေဆာင္ႏိုင္လည္း တစ္စုထဲ ျဖစ္မေနေသးပါဘူး။ ဒါလုပ္ခ်င္ရင္ ဟို website သြား။ ဒီ website သြားနဲ့ဆိုလည္း မျဖစ္ေသးပါဘူး။

အဲဒီအခ်ိန္ဆိုရင္ ကြ်န္ေတာ္တို႔ေတြအတြက္ Web OS ေတြ တြင္က်ယ္လာေကာင္းလာမွာပါ။ Web OS ေတြကို သံုးၾကည့္ေတာ့ Linux ေလာက္ေတာင္ မေကာင္းေသးတာကို ေတြ႕ရပါတယ္။ သေဘာေတာ့ က်စရာျဖစ္ေပမယ္႔ သံုးရတာ ေႏွးတယ္။ ကြ်န္ေတာ္႔ connection ေၾကာင့္လည္း ျဖစ္မွာပါ။ ဒါေပမယ္႔ အနာဂတ္မွာ အားကိုးစရာျဖစ္ေကာင္း ျဖစ္လာႏိုင္ပါတယ္။

တကယ္လို႔ connection ေတြဟာ ေၾကာက္ခမန္းလိလိ လွ်င္ျမင္လာရင္ microsoft အေနနဲ့ OS ၾကီးကို web ေပၚတင္ဖို႔ စဥ္းစားေကာင္း စဥ္းစားလာႏိုင္ပါတယ္။ ဒီလို ခိုးကူးေခြေတြကို ထိန္းခ်ဳပ္ျခင္းအတြက္ web ကေန အသံုးျပဳႏိုင္တာ အေကာင္းဆံုးပဲ။ ဒါေၾကာင့္ OS ေတြကို အနာဂတ္မွာ web ေပၚကို ေျပာင္းလာႏိုင္ပါတယ္။ Web ေပၚမွာလည္း open source OS နဲ့ ဝယ္သံုးရတဲ့ OS ေတြဆိုျပီး ျဖစ္လာႏိုင္ပါတယ္။ ဘယ္ေလာက္ၾကာမလဲဆိုတာေတာ့ မသိပါဘူး။ internet connection အလြန္ေကာင္းဖို႔လိုပါတယ္။ ဒါဟာ ကြ်န္ေတာ္႔ အေတြးပါ။

လက္ရိွ web OS မ်ား

eyeOS, YouOS, G.ho.st, Ulteo and
DesktopTwo ေတြပါ။

အကုန္လံုးက သူ႔ဟာနဲ့သူ ေကာင္းပါတယ္။ အျမန္ဆံုးကေတာ့ eyeOS ပါ။ သေဘာအက်ဆံုးကေတာ့ Ulteo နဲ့ desktop two ပါ။ ဒါေပမယ္႔ သံုးရတာ နည္းနည္း ၾကာတယ္။ Ulteo ကေတာ့ တက္လာဖို႔ ေစာင့္ရတာ အၾကာၾကီး။ Screnn Shoot ပဲၾကည့္လိုက္ရတယ္။ ထပ္ျပီးေတာ့ သံုးဖို႔ၾကိဳးစားၾကည့္ရအံုးမယ္။

Like

Unlike