TCP နဲ႕ UDP ဘာကြာ လည္း ?

TCP နဲ႕ UDP ဘာကြာ လည္း ? အလုပ္ထဲမွာ NLB အေၾကာင္းေျပာရင္းနဲ႕ ေျပာျဖစ္တယ္ ။ TCP က destination အတိအက်ကို လာျပီး ၊ UDP က broadcast ပုံစံသြားတယ္လို႕ ထင္ေနတယ့္ သူေတြ ေတြ႕လိုက္ရလို႕ပါ။ UDP မွာ Dest အမွန္က pick-up လုပ္၊ မဟုတ္တယ့္သူေတြ က drop တယ္လို႕ထင္ေနၾကတယ္။ Hub နဲ႕ Switch ကြာပံုနဲ႕ ေရာေနတယ္ထင္တယ္။ Tech engineer ေတြနဲ႕ေျပာတာမဟုတ္လို႕ (က်ေနာ္တို႕ PM နဲ႕ senior software eng တစ္ေယာက္ပါ)၊ non-technical ပံုစံပဲေျပာျဖစ္တယ္။

တစ္ခုက က်ေနာ္ severfault မွာဖတ္ဖူးတယ့္ CEO level explanation ။ ဆိုက်ပါေတာ့၊ CEO က စာရြက္သုံးရြက္ကို လုံးျပီး အမိႈက္ပုံးထဲကို ျပစ္ခ်င္တယ္။ စာရြက္သုံးရြက္က သူပို႕ခ်င္တယ့္ data ( packets) ပါ။ CEO ၾကီးက source ၊ အမိႈက္ပုံးက destination ေပါ့။ ဘယ္လိုျပစ္မလည္းဆိုတယ့္ manner က TCP / UDP ပါပဲ။ TCP လိုျပစ္ရင္ေတာ့ ပထမ တစ္ရြက္ျပစ္တယ္၊ ဝင္မဝင္ၾကည့္တယ္၊ ဝင္ရင္ ေနာက္တစ္ရြက္ထပ္ျပစ္တယ္။ ျပဳတ္က်သြားရင္ေတာ့ ( ထေကာက္ျပီးေတာ့) ေနာက္တစ္ခါထပ္ျပစ္တယ္။ အဓိကက စာရြက္သုံးရြက္လုံး အမိႈက္ပုံးထဲဝင္တာ ေသခ်ာဖို႕ စနစ္တက်ျပစ္တယ္ပဲ ဆိုပါေတာ့။ UDP ဆိုရင္ေတာ့ တစ္ ႏွစ္ သုံး ဆိုျပီး အမိႈက္ပုံးရွိမယ့္ဘက္ကို အကုန္ျပစ္လိုက္မယ္၊ ဝင္တာမဝင္တာ ဂ႐ုမစိုက္ဘူး ၊ မဝင္လည္းေနပါေစေပါ့။

CEO level က အရမ္း briefly ျဖစ္ေနတယ္။ ေနာက္ example တစ္ခုေျပာမယ္။ We should call it "Project manager level explanation" လို႕ေျပာေတာ့ PM က မ်က္ေထာင့္နီနဲ႕ၾကည့္တယ္။
က်ေနာ္တို႕ စာတစ္ေစာင္ ပို႕မယ္ဆိုပါေတာ့။ စာက Data ၊ က်ေနာ္က source ၊ က်ေနာ္ပို႕ခ်င္တယ့္ လိပ္စာက Destination ေပါ့။ ဘယ္လိုပို႕မလည္း ( transmission method ) ႏွစ္ခုေရြးစရာရွိမယ္ ။ DHL နဲ႕ ပံုမွန္ unregistered post mail ေပါ့။

DHL နဲ႕ပို႕တယ္ဆိုပါေတာ့ ၊
1. DHL က အိမ္ေရွ႕ကိုေရာက္ေအာင္လာမယ္ ( route)
2. အိမ္တခါးကို လာေခါက္မယ္ ( 3 way hand-shake)
3. ဒီ address မွာ ဒီစာကို လက္ခံႏိုင္ေၾကာင္း ေသခ်ာမွ
4. စာကိုေပးျပီးရင္လည္း လက္ခံရရွိေၾကာင္း လက္မွတ္ထိုးခိုင္းမယ္ ( Acknowledgement)
5. တကယ္လို႕ လက္ခံမယ့္ဘက္က လူမရွိရင္ပဲျဖစ္ျဖစ္ ၊ လက္ခံဖို႕အရမ္းအလုပ္ေတြရွုပ္ေနရင္ပဲျဖစ္ျဖစ္ ၊ ေနာက္တစ္ေခါက္ျပန္ပို႕မယ္ ( transmission control, windowing)
6. ဒီလိပ္စာက ဒီလူမရွိေတာ့တာမ်ိဳး၊ လိပ္စာမွားေနတာမ်ိဳးဆို sender ကိုျပန္ အေၾကာင္းၾကားမယ္။
Sender ဖက္က ပို႕လိုက္တာ ေရာက္မေရာက္ သိႏိုင္မယ္ ၊ လိုအပ္ရင္ ေနာက္တစ္ေခါက္ ၊ ေနာက္တစ္ေနရာ ပို႕ဖို႕လိုအပ္ရင္ လည္းသိရမွာေပါ့။

Unregisterd post mail ဆိုရင္ေတာ့
1. အိမ္ေအာက္က mailbox ကိုလာမယ္ ( route)
2. စာတိုက္ပုံးထဲ ထဲခဲ့မယ္
လက္ခံရမယ့္လူ အိမ္ေျပာင္းသြားလို႕ သူလက္ထဲမေရာက္လည္း တာဝန္မယူဖူး။ ေရာက္လားမေရာက္လားလည္း မသိႏိုင္ဘူး။
ဒီ example မွာ connection less နဲ႕ connection oriented ပံုစံကို ထဲ့မေျပာႏိုင္ေပမယ့္ ႏွစ္ခုလုံးက destination ကိုသိျပီး destination ကိုပဲေရာက္ေအာင္လာၾကတာပါပဲ။ Transmission control ပါတာနဲ႕ မပါတာပဲ အဓိကကြဲတယ္လို႕ ေျပာရင္ရပါတယ္။

Technical engineer ကိုဒါမ်ိဳးေျပာလို႕ မရႏိုင္ေပမယ့္ ၊ ဘာမွန္းမသိ စြတ္ေျပာတတ္တယ့္ သူေဌးေတြ ( PM ေတြေရာေပါ့) အတြက္ေတာ့ သူတို႕ညာဏ္နဲ႕ လိုက္မွီတယ့္ explanation ျဖစ္မယ္ထင္ပါတယ္ :D ။

စာမေရးတာၾကာျပီ ၊ ဘာမွ မလုပ္တာၾကာျပီ ။ တစ္ခုခုေသျခာျပန္လုပ္မယ္လို႕ စိတ္ကူးျပီး တျခား colleague တစ္ေရာက္စီကေန သူ download လုပ္ထားတယ့္ game အသစ္ေတြ 36 GB ဒီေန႕ copy လုပ္လိုက္ပါတယ္ ။

Divinity

SQL Editor In Java

အင္း ...ဒီေန႕လည္း အားအားယားယား တစ္ခုစမ္းၾကည္႕ျဖစ္တယ္။

Eclipseမွာ SQL ေရးခ်င္လို႕စမ္းၾကည္႕တာပါ။ Plug-in တစ္ခုပါပဲ။ လြယ္ပါတယ္။ မူရင္းေရးထားတဲ႔သူက အေတာ္ေလးျပည္႕ျပည္႕စံုစံုေရးထားတဲ႔အတြက္ သိပ္ျပီး၀င္အာမေခ်ာင္ခ်င္ပါဘူး။ ဘယ္မွာသံုးလုိ႕ရတယ္။ ဘယ္လို သံုးလုိ႕ရတယ္ဆိုတာေလးေလာက္ပဲ ပြားပါမယ္။

ခင္မ်ားတို႕ေတာ႔ Java နဲ႕ဘာေတြေရးေနၾကရလဲမသိဘူး။ ကြ်န္ေတာ္ကေတာ႔ SQL ေတြခဏခဏျပင္ရတဲ႔အလုပ္မ်ိဳးျဖစ္ေနေတာ႔ တစ္ေန႕လာ ဒီ sql ေတြကိုပဲ SQL DEVELOPER ကေန SCRIPT ေပါင္း ရွစ္ေသာင္းေလးေထာင္ဆိုတာမ်ိဳးေရးရတာကိုပ်င္းပါတယ္။ အျမဲတမ္းေရးေနရတဲ႔ေနရာကိုၾကာေတာ႔မုန္းလာပါတယ္။ Eclipse မွာပဲ တစ္ထုိင္တည္းေရးတာေရာ Test တာေရာလုပ္ခ်င္ပါတယ္။ ပ်င္းတာကိုေျပာခ်င္တာပါ။ IDE ေလးႏွစ္ခုကိုဖြင္႔ျပီးေျပာင္းလုိက္ရမွာကိုေတာင္ပ်င္းပါတယ္။ ပ်င္းရတာလည္း အေၾကာင္းရိွပါတယ္။

အခ်ိန္မ်ားရရင္ Developer တုိင္းသိသင္႔တဲ႔ 97 ခ်က္ဆိုတဲ႔ Oreily က စာအုပ္ေလးဖတ္ၾကည္႕ေစခ်င္ပါတယ္။ အဲဒီမွာ သိသင္႔တာေတြအေတာ္မ်ားမ်ားပါပါတယ္။ ကြ်န္ေတာ္လည္းျမည္းၾကည္႕ပါတယ္။ ကိုယ္တုိင္လည္း လိုက္နာတာရိွသလုိ မလုိက္နာျဖစ္တာေတြလည္းရိွပါတယ္။

ကြ်န္ေတာ္႔အယူအဆအရေတာ႔ Developer ေတြက Codes နည္းႏိုင္သမွ်နည္းနည္းပဲေရးဖုိ႕ၾကိဳးစားရပါမယ္။ ျဖစ္ႏိုင္ရင္Program ေလးတစ္ခုေရးထား၊ အျမဲတမ္းေရးရတဲ႔ Script မ်ိဳးဆိုရင္ Copy&&Paste ေတာင္မလုပ္နဲ႕။ အဲဒီလို သက္သက္သာသာေနလုိ႕ရေအာင္ၾကိဳးစားသင္႔ပါတယ္။ လူမေရးရင္ လူေၾကာင္႔မွားတာမရိွပါဘူး။ အေၾကာင္းတစ္ရာမွာ မမွားႏိုင္ဘူးဆိုရင္ေတာင္ အေၾကာင္းတစ္ေထာင္ေလာက္ဆိုရင္ လူက စျပီး ပ်င္းလာပါျပီ။ အဲဒီလိုအလုပ္မ်ိဳးကို Tedious work လုိ႕ေခၚပါတယ္။ မခက္ေပမယ္႔ အၾကာၾကီး ထပ္တလဲလဲလုပ္ရတာမ်ိဳးပါ။ အဲဒါေတြကို ျဖစ္ႏိုင္ရင္ program ေလးဘာေလးေရးထားဖုိ႕စဥ္းစားပါ။

အခုလုပ္ရတဲ႔ အလုပ္က ျမန္ဖုိ႕လည္းမလုိဘူး။ ခက္တာလဲမဟုတ္ဘူး။ ေသခ်ာဖုိ႕သိပ္အေရးၾကီးတယ္။ အဲဒါေၾကာင္႔ ကြ်န္ေတာ္ဂရုစို္က္တာ ေသေသခ်ာခ်ာနဲ႕ Quality ေကာင္းေကာင္းျဖစ္ဖုိ႕ပါပဲ။ လုပ္ငန္းသဘာ၀အရ ကြ်န္ေတာ္ တိတိက်က်လုပ္ရပါတယ္။ Eclipse မွာ sql ေရးတာက Editor က ပိုျပီး ေရးလုိ႕ အဆင္ေျပလုိ႕ပါ။ ပိုျပီးလည္း ရင္းႏီးတယ္လို႕ခံစားရပါတယ္။ ေနာက္တစ္ခုက Version Control က Eclipse နဲ႕ခ်ိတ္ထားတဲ႔အတြက္ Eclipse မွာေရးလုိက္ရင္ ေရႊ႕ေနေျပာင္းေန ကူးေနစရာမလုိပါဘူး။ ကြ်န္ေတာ္ပ်င္းတာက Eclipse မွာေရးျပီးသား sql ကို ကူးျပီး SQL developer မွာ run ၾကည္႕ဖုိ႕ကို မကူးခ်င္တာပါ။

အဲဒီေတာ႔ Plug-in တစ္ခုရွာၾကည္႕တာပါ။

ရွာၾကည္႕ေတာ႔လည္း ထြင္ထားတာက ၾကာလွပါျပီ။ ကိုယ္႔ဘာသာမသိေသးတာပါ။

ေရးရမွာပ်င္းပါတယ္။

http://download.oracle.com/docs/cd/E13095_01/oepe-website/db-tools/gettingStarted/files/gettingStarted.html

အဲဒီမွာ နည္းနည္းၾကည္႕ျပီးလုပ္လုိက္ပါ။

သိပ္ေတာ႔လည္းမၾကာပါဘူး။ႏွစ္ဆယ္႔ငါးမိနစ္ဆို စသံုးလုိ႕ရပါျပီ။ မရေသးရင္ ေတာ္ေတာ္ညံ႕ပါလားလို႕ ကိုယ္႔ကိုယ္ကိုေျပာပါ။

အဲဒီမွာျပထားတာကေတာ႔ Oracle Database နဲ႕ခ်ိတ္တာပါပဲ။ ခ်ိတ္တာကလည္း oracle thin client နဲ႕အရင္ web server ေတြက ခ်ိတ္သလိုမ်ိဳးခ်ိတ္တာပါပဲ။ အဲဒါေတြက မထူးဆန္းပါဘူး

သံုးရမွာက အဲဒီမွာ Database connection ရျပီဆိုရင္ sql editor နဲ႕ sql file ေတြကို ဖြင္႔ျပီး Alt+X နဲ႕run ရင္ result ေတြကို တခါတည္းျမင္ရတဲ႔အတြက္ တစ္ေနရာထဲမွာ ျငိမ္ျငိမ္ေလးေနျပီး အလုပ္ျဖစ္ပါျပီ။ ထုိင္ေနရင္း အလုပ္ျဖစ္တာ ဥဥေနတဲ႔ဘဲပဲရိွတယ္ဆိုတာကို သတိရပါတယ္။ အလုပ္ျဖစ္ေအာင္လုပ္ပါ။

ကြ်န္ေတာ္ေပးခ်င္တဲ႔အၾကံကေတာ႔ Trial and error, ကို တတ္ႏိုင္သမွ် ေနာက္ဆံုးမွသံုးပါ။ Developer ေကာင္းတစ္ေယာက္ျဖစ္ဖုိ႕ အရင္စဥ္းစားပါ။ တစ္ေယာက္ေယာက္ကေမးရင္ Are you sure၊? အရင္ေမးပါဦး။ ေမးတာက တလြဲဆိုရင္ အေျဖလည္းတလြဲျဖစ္ေနမယ္။ ေသခ်ာသိေအာင္လုပ္ပါ။ Knowledge is Power ဆိုတာၾကီးကို ကြ်န္ေတာ္တို႕ အားတုိင္းေျပာေနတာနဲ႕ ဘာမွန္းေတာင္မသိေတာ႔ေလာက္ေအာင္ အဓိပၸါယ္ေတြေ၀းကုန္ပါျပီ။ a little Knowledge is a dangerous thing ဆိုတာလည္းရိွပါတယ္။ Java ေရးတာကိုမွမဟုတ္ပါဘူး။ ဘာကိုပဲေလ႔လာေလ႔လာ အေျခခံကို ခုိင္ေအာင္လုပ္ျပီးတာနဲ႕ လမ္းကိုေရြးပါ။ ဘာလုပ္မွာလဲ ဆိုတာကိုေယာင္၀ါး၀ါးမျဖစ္ေစနဲ႕။ Certification ေတြကို အထင္ေသးတာ၊ၾကီးတာမရိွပါဘူး။ လုပ္ဖုိ႕လုိတာကို လုပ္ရပါတယ္။ စနစ္တက်ေလ႔လာေနဖုိ႕လိုပါတယ္။

ကိုယ္မသိေသးတာကို အထင္မေသးပါနဲ႕။ သိေအာင္လုပ္ျပီးမွ အထင္မၾကီးပဲေနခ်င္ေန။ မသိေသးဘဲနဲ႕ ဒါေလးေတြကလြယ္ပါတယ္မလုပ္ပါနဲ႕။ မေန႕ညက Java Developer's Notes ဖတ္ရင္းနဲ႕ သေဘာက်တာေတြေတြ႕ပါတယ္။ အေျခခံေလးေတြေပမယ္႔ ေသခ်ာသိလုိက္ရတာ ေက်နပ္ဖုိ႕ေကာင္းပါတယ္။

အရင္ရံုးက senior တစ္ေယာက္ Configure လုပ္ခဲ႔တဲ႔ Framework Setup ေတြကို ျပင္ၾကည္႕ရင္း သူတုိ႕လုပ္တာစနစ္က်တာကို သတိျပဳမိပါတယ္။ ဘာမဆို စကတည္းက စနစ္က်မွ ေနာက္ပိုင္းမွာ အဆင္ေျပပါတယ္။ စကတည္းက လြဲေနတဲ႔ Design မ်ိဳးကို ျပင္ရရင္ လိုတာထက္ပိုျပီးဒုကၡေရာက္ပါတယ္။

ကြ်န္ေတာ္ကိုယ္တုိင္လည္း အျမဲတမ္းေလ႔လာေနရတဲ႔ေနရာမ်ိဳးမွာပဲေနခ်င္ပါတယ္။ ဘာမဆို သင္လုိ႕မတတ္ေလာက္ေအာင္ခက္တာမရိွပါဘူး။ ကိုယ္႔ရဲ႕ အသိဥာဏ္ေပၚမူတည္ျပီး နားလည္ပံုကြာတာပဲရိွပါလိမ္႔မယ္။ ကိုယ္ညံ႕ေနတာေတြကို မ်ားမ်ားျဖည္႕ဆည္းပါ။ ေတာ္တဲ႔သူေတြ ေတာ္တဲ႔ေနရာကိုေရာက္သြားပါမယ္။ ညံ႕တဲ႔သူေတြလိုက္လို႕မမီေအာင္ေတာ္ဖုိ႕ပဲလိုပါတယ္။ ညံ႕တဲ႔သူေတြကို အျပစ္တင္ေနစရာမရိွပါဘူး။ တကယ္႔လက္ေတြ႕ဘ၀မွာ ကိုယ္႔ကိုယ္ကို ဘယ္ေလာက္ယံုၾကည္ျပီး ကိုယ္တုိင္ဘယ္ေလာက္ၾကိဳးစားသလဲဆိုတာက ကိုယ္ဘာျဖစ္လာမလဲဆိုတာကို ပိုင္းျဖတ္တာပါ။

ဒီမွာေလေပါေနရတာလည္းအေၾကာင္းရိွပါတယ္။ စိတ္ဓာတ္ေတြပိုေကာင္းလာရင္ ေလ႔လာမႈမွာ အားပိုရိွလာဖုိ႕ပါ။ ကိုယ္႔ပန္းတိုင္ကို ေသခ်ာသိရင္ မေရာက္အေရာက္သြားမွာပါပဲ။ ေသခ်ာမသိရင္ အားမပါဘူး။

ကဲနည္းနည္းေလာက္ေတာ႔ အပ်င္းေျပစမ္းၾကည္႕လုိက္ပါ။

iHateJavaCozNowILoveFunctionalProgramming_Zero_Divided_By_Zero_Is_Zero

၆၃ မက်တဲ႔သူမျဖစ္ေစနဲ႔။

၆၃ မက်တဲ႔သူမျဖစ္ေစနဲ႔။

မေန႕က Aဂ်ိဳင္း စာအုပ္တစ္အုပ္ကို ျမည္းရင္း ဘာေတြ႕လည္းဆိုေတာ႔ မျပီးႏုိင္တဲ႔ ကိစၥကိုျပီးေအာင္လုပ္ခိုင္းရင္ အခိုင္အမာကာကြယ္ဖုိ႕ေျပာထားတာဖတ္လိုက္ရတယ္။

Aဂ်ိဳင္းဆိုတာ Agile ကိုေျပာတာပါ။

ဒီႏွစ္ထဲမွာ Target လုပ္ထားတာက SCJA ေျဖဖို႕ျဖစ္တဲ႔အတြက္ စာမ်ားမ်ားဖတ္ျဖစ္ပါတယ္။ အထူးသျဖင္႔ Agile နဲ႕ Spring ကို အမ်ားဆံုးဖတ္ပါတယ္။

Singapore မွာ Software Engineering ကိုေကာင္းေကာင္းနားလည္တဲ႔သူ အနည္းငယ္ပဲရိွတယ္ဆုိတာကိုေျပာရင္ ယံုၾကပါ႔မလားမသိဘူး။ စလံုးေတြ စျပားေတြသိပ္ေတာ္တာပဲဆိုတာကို မၾကာမၾကာၾကားရပါတယ္။ ေတာ္တာလည္းရိွေပမယ္႔ ေရွာ္တာေတြက ပိုမ်ားပါတယ္။

သူတို႕ရဲ႕ Life မွာ စာမ်ားမ်ားဖတ္ခ်ိန္မရေတာ႔တာလည္းပါပါတယ္။ အခုေခတ္မွာ ဘယ္ႏိုင္ငံသားပဲျဖစ္ျဖစ္ မ်ားမ်ားေလ႔လာတဲ႔သူက မေလ႔လာတဲ႔သူထက္ သာသြားတာပါပဲ။ သိပ္အထင္မၾကီးနဲ႕။ အေတြ႕အၾကံဳအရလုပ္ေနၾကေပမယ္႔ တကယ္တမ္း သီအုိရီကို ေသြဖယ္တာေတြေၾကာင္႔ ထြင္ျပီးသားဘီးျပန္ထြင္ေနရတဲ႔ ပေရာဂ်တ္ေတြအမ်ားၾကီးပါပဲ။ reinventing the wheel ျဖစ္ရင္ ေသခ်ာေပါက္ ဒုကၡနဲ႕လွလွေတြ႕ပါျပီ။

Singapore မွာ ဘာေတြကိုအျဖစ္လုပ္လဲဆိုတာေတြကိုခ်ည္းပဲေရးရင္ေတာင္ ေတာ္ေတာ္မ်ားမ်ားရပါမယ္။ Team Lead ေတြဟာ စာမဖတ္တာၾကာတဲ႔အခါ Failed ျဖစ္မယ္႔ Project ကို လူႏွစ္ဆထည္႕ေနတုန္းပဲရိွပါေသးတယ္။ အဲဒါဆို သီအုိရီအရ ပိုျပီးေသခ်ာေပါက္ Failed ျဖစ္ပါတယ္။ မသိလုို႕ ေရးေနတဲ႔သူေတြကို လူသစ္ေတြက လာလာေမးတဲ႔ interactions ကမ်ားလုိ႕ပါ။ သိပ္ေတာ္တဲ႔လူေတြကိုလည္း လြယ္လြယ္နဲ႕ငွားလို႕မရပါဘူး။ ေပါေခ်ာင္ မေကာင္းပဲရိွပါတယ္။ ေပါေခ်ာင္ေကာင္းဆိုတာ software engineer ေတာ႔မရပါဘူး။ အဲဒါကို သီအိုရီကဘယ္လုိေရးထားလဲဆိုရင္ မိန္းမတစ္ေယာက္က ၉ လမွာ ကေလးတစ္ေယာက္ေမြးလုိ႕ရရံုနဲ႕ မိန္းမကိုးေယာက္ေပါင္းျပီးတစ္လတစ္ေယာက္ေမြးလုိ႕မရသလုိပဲတဲ႔ .....။ အဲဒါေလးကိုေတာ႔ဖတ္ထားဖုိ႕လိုပါတယ္ ... Team lead လုပ္မယ္႔သူေတြေပါ႔ေလ။

Agile Development မွာ User ကို Development Process မွာ အဓိကထားပါတယ္။ တစ္ခုေရးျပီးတာနဲ႕ Userကိုျပ၊ မၾကိဳက္ရင္ျပင္ ၊ ျပန္ျပ၊ ေက်နပ္တဲ႔အထိျဖစ္ရင္ ေက်နပ္ေၾကာင္းကို တစ္ခါတည္း confirm လုပ္၊ ဆက္ေရး။ အဲဒီလိုသြားရပါတယ္။ စင္ကာပူမွေတာ႔ Change Request လုိခ်င္ေလာဘက မ်ားေလေတာ႔ user ကို milestone ေရာက္မွျပ၊ မၾကိဳက္ရင္လည္းပုိ႕ထားတဲ႔ User Requirement ေတြနဲ႕ ကိုင္ေပါက္၊ ညာခ်၊ အဲဒါေတြဟာ လူၾကီးလူေကာင္းမဆန္ဘူး။ ပိုက္ဆံအေခ်ာင္လုိခ်င္တဲ႔ အေခ်ာင္သမားပဲဆန္တယ္။ ႏိုင္ငံတကာမွာ Agile ကို တြင္တြင္က်ယ္က်ယ္လုပ္လာလို႕ software ေတြ quality ပိုေကာင္းလာတယ္။ User satisfaction ရတယ္။ ပိုက္ဆံအမ်ားၾကီးရၾကတယ္။ ဒီမွာေတာ႔ Deadline သာအမိ၊ Deadline သာအဖ၊ Quality သည္ ဒုတိယဆိုတဲ႔စကားကို ဥံဳခံရြတ္ေနတုန္းပဲရိွေသးတယ္။ Budget ကိုတြက္တဲ႔ေနရာမွာ စစ္တမ္းေကာက္ရင္ စင္ကာပူဟာ Software Engineering မွာေရွ႕ကေျပးပါတယ္။ ရိွတဲ႔လူနဲ႕ ျ႔ပီးေအာင္လုပ္မယ္ဆုိတဲ႔ မျဖစ္ညစ္က်ယ္ တစ္ထြာတစ္မိုက္ဥာဏ္ကလည္း မ်ားပါတယ္။Software ျပီးသြားရင္ External QA ျဖတ္ရမယ္ဆုိတာကိုလည္း ေမ႔ထားတာ ႏွစ္ေပါင္းမနည္းေတာ႔ပါဘူး။

အဲဒီလိုေလာကမ်ိဳးမွာ ရွင္သန္ဖို႕ ဘာမွသိပ္မ်ားမ်ားသိဖုိ႕မလိုပါဘူး Skills က knowledge ထက္ပိုအေရးၾကီးတယ္လို႕ေျပာလုိ႕ရပါတယ္။ စင္ကာပူမွာ သိပ္ျမန္တဲ႔ေကာင္ေတြအမ်ားၾကီးပဲ။ ဘာခိုင္းခိုင္း အေသအေၾကျျမန္တယ္။ Analysis ကို အခ်ိ္န္မေပးႏိုင္ဘူး။ ေရးတာပဲ။ ေရးျပီးရင္းေရးေနတာပဲ။ Framework ကဘာလုိ႕ Bean ကို Inject လုပ္တာလည္းမေမးနဲ႕။ သိဘူး။ ေရးေတာ႔ေရးေနတာပဲ။ ကိုယ္ဘာေရးေနမွန္းနားမလည္တဲ႔ေကာင္ေတြ အမ်ားၾကီးပဲ။ အဲဒါေတြဘယ္ကေရာက္လာတာလဲ။ ဘာလို႕ေရာက္တာလဲအထိ မသြားေတာ႔ဘူး။ ေရးလုိ႕ရရင္ေတာ္ျပီ။ Configure ဒီလိုလုပ္၊ ဒီလိုေလးေရး။ ဒါပဲ။ ဒီေလာက္ဆို ရပ္တည္လုိ႕ရျပီ။ တကယ္တမ္း Struts နဲ႕ Spring ဘာကြာလဲ၊ ဘာလုိ႕ကြာလဲ။ Lightweight framework ေတြက Modern Software Industry မွာ ဘာလုိ႕လြမ္းမႈိးသြားလဲ ...အဲဒါေတြမေျပာနဲ႕ေတာ႔ ...ေရးျ႔ပီးရင္းေရး ... Quality အသင္႔အတင္႔ေလာက္ေရးတတ္ရင္ရျပီ။

တကယ္တမ္း ... သိေအာင္ၾကိဳးစားၾကည္႕ျပီး အေပၚစီးက ျမင္ႏိုင္ရင္ ေလ႔လာတဲ႔ေနရာမွာ အမ်ားၾကီးလြယ္ကူပါတယ္။ Java မွမဟုတ္ပါဘူး OO concept က ဒါေတြပဲရိွတယ္။ ဘယ္လို implements လုပ္သလဲေလာက္ေလ႔လာလိုက္ရင္ Java ရဲ႕ Branch ေတြကို ေလ႔လာတဲ႔အခါ အမ်ားၾကီး အက်ိဳးရိွပါတယ္။ ပိုေကာင္းတဲ႔ Code ေတြကို လြယ္လြယ္နဲ႕ေရးႏုိင္လာပါမယ္။ ပိုျပီးေထာင္႔ေစ႔တဲ႔အျမင္ရလာပါမယ္။ အေျခခံေလးေတြဆိုျပီး အဆင္႔မေက်ာ္လုိက္ပါနဲ႕။ အဆင္႔ေက်ာ္ထားရင္ ဘာျဖစ္မလဲ .....။ ၆၃ မက်တဲ႔သူျဖစ္သြားပါမယ္။

Design Pattern စာအုပ္ထဲမွာေျပာထားတာတစ္ခုကို မွတ္မိလို႕ျပန္ေျပာရရင္ Inheritance သိပ္ေကာင္းတယ္ဆိုျပီး မလုိဘဲေလွ်ာက္သံုးတာကိုေရးထားတာပါ။ ဘဲေတြက ပ်ံတယ္ဆိုတဲ႔ ဘဲ class ကို extends လုပ္တာမ်ားသြားေတာ႔ plastics ဘဲဆိုလည္း super class ကဘဲလိုပဲ ပ်ံေနေတာ႔တာပဲ။ အဲဒီလုိေတြျဖစ္လာေတာ႔မွ interface သံုးျပီး implements ၾကတာေတြျဖစ္လာတာပါ။ OO Concept ေတြဘယ္ေလာက္ေက်လဲသိေအာင္ Design Pattern နည္းနည္းေလာက္ေတာ႔ျပန္ဖတ္ပါ။ ကိုယ္က မ်ားမ်ားသိတယ္ဆိုရင္ ပူစရာမလိုပါဘူး။ ဖတ္လုိက္မွ ေအာ္ ဒီလိုၾကီးလားဆိုရင္ေတာ႔ ျပန္စဥ္းစားပါ။ ကိုယ္႔ေၾကာင္႔ Software ထဲမွာ plastic ဘဲ ဘယ္ႏွစ္ေကာင္ပ်ံကုန္ျပီလဲဆိုတာကိုေပါ႔ေလ။

စာမ်ားမ်ားဖတ္ပါ။ ၆၃ က်ခ်င္ရင္ စာဖတ္ပါ။ စင္ကာပူက ညီေလးေတြကို ေျပာခ်င္ပါတယ္။ Library မွာ ဖတ္ပါ။ ဖတ္လုိ႕ၾကိဳက္မွ၀ယ္ပါ။ ၀ယ္တဲ႔အခါ ကိုယ္နဲ႕အဆင္ေျပတဲ႔စာအုပ္တုိက္ကို မွတ္ထားပါ။ ဥပမာ ... တစ္ခ်ိဳ႕က Manning ကရွင္းတာေတြကို သေဘာက်တယ္။ In action series ေတြ သိပ္ရွင္းတယ္။ေကာင္းတယ္။ ဒါေပမယ္႔ တစ္ခ်ိဳ႕ကမၾကိဳက္ဘူး။ ၾကာတယ္လုိ႕ထင္တယ္။ Apress ကိုတစ္ခ်ုိဳ႕ကၾကိဳက္တယ္။ တစ္ခ်ို႕ကHead First ေတြၾကိဳက္တယ္။ တစ္ခ်ိဳ႕က Packet ကိုၾကိဳက္တယ္။ ကို္ယ္ၾကိဳက္တာကိုယ္ဖတ္ပါ။ အဓိကကဖတ္ေနဖို႕နဲ႕ သံုးၾကည္႕ဖုိ႕ပါပဲ။

သံုးၾကည္႕ဖုိ႕ဆိုတာကို နည္းနည္းခ်ဲ႕ေျပာခ်င္ပါတယ္။ သံုးတယ္ဆိုတာက သံုးတတ္ရင္ေတာ္ပါျပီ။ တစ္ခ်ိဳ႕ကိစၥေတြမွာ နားလည္ဖုိ႕ ေရးၾကည္႕ရပါတယ္။ ကြ်န္ေတာ္တို႕လုိ Academic ပိုင္းကလာတဲ႔သူေတြက လက္ေတြ႕လုပ္ရမွာ အေတာ္ေလးပ်င္းပါတယ္။ ဒီလိုလုပ္ရင္ ရတယ္ဆုိတာကို သိရင္ ရပ္ထားတာမ်ားပါတယ္။ တကယ္လုပ္ၾကည္႕မွ Tips and Tricks ေလးေတြကိုသိရပါတယ္။ အဲဒီလိုသိေအာင္ေတာ႔ အနည္းနဲ႕အမ်ားတကယ္လုပ္ၾကည္႕ဖုိ႕လုိပါမယ္။

အခု လုပ္ေနတာက Insurance company တစ္ခုရဲ႕ software ကို maintain လုပ္ၾကတာပါ။ ဘယ္ေလာက္တလြဲေတြလုပ္ထားလည္းဆိုတာကိုေရးလုိက္ရင္ Insurance system ၾကီးဒီေလာက္သက္ဆိုးရွည္ေနတာကိုေတာင္ အံ႔ၾသမိပါတယ္။ အဲဒီလို ၆၃ မက်တဲ႔ေကာင္ေတြ ေရးသြားလုိ႕လည္း ငါတုိ႕အလုပ္ေတြေပါေနေသးတာလုိ႕ ၾကံဖန္ေက်းဇူးတင္မိပါတယ္။

Problem Solving Skills တိုးတက္ဖုိ႕ အေသခ်ာဆံုးနည္းက Systematic ျဖစ္ဖုိ႕သတိထားပါ။ ဘယ္သူေျပာတာကုိမွမယံုနဲ႕။ Codes ေျပာတာကိုယံု။ ကိုယ္႔ဘာသာကိုယ္ source code ၾကည္႕။ ဘယ္သူဘာေျပာေျပာ source code ေလာက္မေသခ်ာဘူး။ Right Track ကို သြားဖုိ႕ အျမန္ဆံုးနဲ႕ ျပႆနာကိုေဖာ္ထုတ္ႏုိင္ဖုိ႕ အတြက္ အျမဲေလ႔က်င္႔ေနပါ။

အျမဲသံုးေနရတဲ႔ folder ေတြ software ေတြဆီကို click သံုးခ်က္ထက္ပိုႏွိပ္ျ႔ပီးသြားေနရရင္ ငေပါ Developer ပါပဲ။ အဲဒီလို Efficient မျဖစ္တာေတြကိုေရွာင္ပါ။ ကိုယ္႔စက္ထဲမွာ ဘာပဲသိမ္းသိမ္း structure က်က်သိမ္းပါ။ Mail ကို Archive လုပ္ရင္လည္း ျဖစ္ကတတ္ဆန္းမလုပ္ပါနဲ႕။ စနစ္က်ပါ။

အထက္လူၾကီးကိုေျပာရင္ ေယာင္၀ါး၀ါးမလုပ္ပါနဲ႕။ ျပတ္ျပတ္သားသား တိတိက်က်ေျပာပါ။ အလုပ္ကို အခ်ိ္န္မဆြဲပါနဲ႕။ ျပီးမွနားပါ။ ျမန္ျမန္မလုပ္တာၾကာရင္ လူက ေႏွးသြားတတ္ပါတယ္။ အဲဒီလိုျဖစ္လာရင္ တစ္ျခားတစ္ခုခုကို ေလ႔လာပါ။ ကိုယ္႔အစြမ္းအစကို မတံုးသြားေစပါနဲ႕ သက္သက္သာသာေနရာမွာ ၾကာၾကာေနေလေလ ညံ႕ေလပါပဲ။ တစ္ခ်ိန္ၾကရင္ အရင္က အတူတူဆိုတဲ႔လူေတြနဲ႕ ကိုယ္နဲ႕ သိပ္ကြာသြားမယ္။ အဲဒီလိုျဖစ္ခ်င္သလားကိုယ္႔ကိုယ္ကိုေမးပါ။

Java မွာ စိတ္ေလေလာက္စရာ Dependency Issues ေတြရိွပါတယ္။ အဲဒါေတြၾကံဳရင္ Forum ေတြဖတ္ပါ။ လူမ်ားေတြဘယ္လုိေျဖရွင္းသလဲ စိတ္ေအးေအးနဲ႕ေလ႔လာပါ။ စိတ္ဘယ္ေတာ႔မွမပူနဲ႕။ စိတ္ပူေနစရာမလိုဘူး။ ဒီအလုပ္က ကမာၻမွာအခက္ဆံုးမဟုတ္ဘူး။ ကိုယ္႔ထက္ေတာ္တဲ႔သူေတြ ရွာထားလိမ္႔မယ္။ မေတြ႕ရင္လည္းကိုယ္႔ထက္ညံ႕တဲ႔ေကာင္ေတြမေတြ႕ေသးဘူးလုိ႕မွတ္ပါ။ နားလည္ေအာင္ၾကည္႕ျပီးမွ ေျဖရွင္းပါ။ ရမ္းကစ္တာေတြမလုပ္ပါနဲ႕။အခ်ိန္ကုန္ပါတယ္။

API ေတြကိုဖတ္ပါ။ အဲဒီလိုေျပာရင္ ရယ္စရာတစ္ခုကိုသတိရပါတယ္။ ထမင္းစားေနုတုနု္း ကြ်န္ေတာ္တို႕ Java သမားႏွစ္ေယာက္က API အေၾကာင္းေျပာေနတာကုိ တစ္ျခား Language ေရးတဲ႔သူငယ္ခ်င္းက dot ေလးခ်လိုက္ရံုနဲ႕မရဘူးလားဆိုျပီး အေရးထဲ IDE ရဲ႕ auto completion (intellisense) နဲ႕လာယွဥ္ေျပာေနလုိ႕ အေတာ္ေလးစိတ္ေလရပါတယ္။ Eclipse ကလည္း Auto Completion မွာ ထိပ္တန္းကရိွပါတယ္။ ေရးထားတဲ႔သူေတြကလည္း ကမာၻမွာ အေတာ္ဆံုးေတြပါ။ API ကေတာ႔ Java သမားေတြ အတြက္ အေကာင္းဆံုးေလ႔လာစရာပါပဲ။ API ထဲမွာ ဘာေတြလုပ္လုိ႕ရသလဲဆိုတာၾကည္႕လုိက္ရင္ အေတာ္ေလးအိုေကသြားပါတယ္။

Java သမားတစ္ေယာက္ဟာ တကယ္ေရးတဲ႔ေနရာမွာ ၾကာၾကာေလးေနဖုိ႕လိုပါတယ္။မဟုတ္ရင္ Training ground မျဖတ္သန္းခဲ႔တဲ႔ စစ္သားေတြလုိပဲ။တကယ္တမ္းၾကေတာ႔ ၆၃ မက်ေတာ႔ဘူး။

ျမန္မာေတြက မညံ႕ပါဘူး။ အခု ဖိလစ္ပင္းေတြနဲ႕ အိႏၵိယေတြ၊ တရုတ္ေတြ စင္ကာပူကို Mass Export လုပ္ေနခ်ိန္မွာ Software သမားေတြအေနနဲ႕ အမ်ားၾကီးေလ႔လာဖုိ႕လိုပါတယ္။ အထူးသျဖင္႔ ကုလားေတြက စာဖတ္ပါတယ္။ က်န္တဲ႔ ဖဦးထုပ္နဲ႕ တရုတ္ကေတာ႔ ထင္သေလာက္မဟုတ္တာမ်ားပါတယ္။ အဲဒီလုိ အျပိဳင္အဆိုင္ပိုမ်ားလာတဲ႔အခ်ိန္မွာ တပမ္းသာဖုိ႕က တကယ္ေတာ္တဲ႔လူျဖစ္ဖုိ႕နဲ႕ Flexibility ေကာင္းဖုိ႕၊ ၆၃ က်ဖုိ႕လိုပါတယ္။ ကိုယ္႔မွာ အားနည္းေနတဲ႔အပိုင္းကိုရွာပါ။ ျဖည္႕ဆည္းပါ။ တစ္ႏွစ္ေလာက္အတြင္းမွာ ဒီက ေရးေနတဲ႔ သာမန္ Developer ေတြကို ေက်ာ္တက္ႏိုင္ပါတယ္။ ဘာမွမပူပါနဲ႕။ ျမန္မာေတြေလာက္ဘယ္သူမွ အားအားယားယား ေလ႔လာဖုိ႕ အခ်ိ္န္မရိွပါဘူး။ ဒီကို ေရာက္ေနတဲ႔ Computer ကညီငယ္ေတြ၊ IT ကညီငယ္ေတြ၊ညီမငယ္ေတြအားလံုး ေက်ာင္းမွာ ဖတ္ခဲ႔တဲ႔စာေတြကိုျပန္ေတြးလုိက္ပါ။ အဲဒီဖတ္ခဲ႔တာေတြရဲ႕တစ္၀က္ေလာက္ကိုပံုမွန္ဖတ္ပါ။ စင္ကာပူမွာ ျမန္မာေတြေတာ္တာကို လက္ခံလာတဲ႔ ကုမၸဏီေတြအမ်ားၾကီးရိွပါတယ္။ ထပ္ျပီးသက္ေသျပၾကပါ။ ေနာက္လူေတြအတြက္ အေကာင္းဆံုးကူညီေပးလုိက္ဖုိ႕က ကိုယ္႔ေနရာမွာ ကိုယ္ဟာ အေကာင္းဆံုးလူျဖစ္ေနဖုိ႕ပါပဲ။

ညံ႕ေနတာကို ညံ႕ေနမွန္းမသိတဲ႔သူကေတာ႔ ဆက္ျပီးညံ႕ေနဦးမွာပါ။

စိတ္ဓာတ္ကေနစရပါမယ္။ တကယ္သိခ်င္ရင္ သိဖုိ႕ အမ်ားၾကီးအခြင္႔အလမ္းေပၚပါတယ္။ သိခ်င္စိတ္မရိွတဲ႔သူကေတာ႔ အခြင္႔အလမ္းေပၚရင္လည္း မေလ႔လာတဲ႔အတြက္ ဘာမွ အက်ိဳးမရိွပါဘူး။

ဒီေဆာင္းပါးက နည္းနည္းေတာ႔ လုိရင္းမေရာက္သလုိျဖစ္ေနပါတယ္။

တကယ္႔ Main Theme ကေတာ႔တစ္ခုတည္းပါ။ Let's prove we are the best !!!!!!!!!!!!!!!!!!!

regards_zeroDividedByZeroIsZerO

Dedicated to all young Software Engineers ..., Coders, Debuggers,Deployers,DBAs,BAs and QAs.

Git :)

Java အေၾကာင္းေရးထားတာေတြအကုန္ျပန္ဖတ္ျပီး Main Theme ေပ်ာက္ေနတာကိုသတိထားမိပါတယ္။

အခုတေလာ အခ်ိန္ကလည္း မဟားတရား အားေနေတာ႔ ဘာမွမစဥ္းစားဘဲ Java ေရးလုိ႕ရတယ္ဆိုတဲ႔ အယူအဆကို အေကာင္အထည္ေဖာ္တဲ႔အေနနဲ႕ ... သင္ခန္းစာေတြပါေရးပါမယ္။ တကယ္ေတာ႔ကိုယ္႔ဘာသာကိုယ္ဖတ္ရတာ ျမန္ပါတယ္။ ျပန္ေရးရတာ အေတာ္ေလးပ်င္းဖုိ႕ေကာင္းပါတယ္။Teach yourself Java in 12 seconds

sysout + ctrl+Space in eclipse.

then it will show : System.out.println();

Modify it a bit as following :

System.out.println("Hello Dying World!!!!");

run...

အဲဒါမ်ိဳးေတြေတာ႔မေရးခ်င္ပါဘူး။

ေလးနက္တဲ႔အေၾကာင္းအရာေတြကိုလည္း မ်ားမ်ားေရးခ်င္ပါတယ္။ မ်ားမ်ားဖတ္ေလေလ မေရးျဖစ္ေလေလျဖစ္ေနတဲ႔အတြက္ ...ၾကိဳးစားျပီးပံုမွန္ေရးပါမယ္။

ဒီေန႕လည္း Git ကို စမ္းၾကည္႕ပါတယ္။ Git ကိုမေျပာခင္ Version Control System ေတြအေၾကာင္းနည္းနည္းေျပာခ်င္ပါတယ္။ ကေလးေေတြသိေအာင္လုိ႕ပါ။

Source Code ေတြကို တစ္ေနရာမွာသိမ္းထားျပီး Version ခြဲထားတာမ်ိဳးပါ။ ဥပမာဆိုပါေတာ႔ ..ကြ်န္ေတာ္အခုေရးေနတဲ႔ Dynamic Patcher ဆိုတဲ႔ Project ကို ကြ်န္ေတာ္စေရးတယ္။ Version Controlတစ္ခုခုမွာ import လုပ္ထားလိုက္တယ္။ ေနာက္ေန႕ၾကရင္ ဆက္ေရးတယ္။ ျပီးရင္ ပထမေန႕မွာ import လုပ္ထားတဲ႔ Version Control System ထဲကို ထပ္ထည္႕တယ္ဆိုပါေတာ႔။

Version Control System မွာက Dynamic Patcher verion 1, version 2 ဆိုျပီး ႏွစ္ခုျဖစ္ေနပါမယ္။

ေနာက္ထပ္ ကြ်န္ေတာ္႔သူငယ္ခ်င္းတစ္ေယာက္ကလည္း ဆက္ေရးျပီး Update လုပ္လိုက္ရင္ version 3 ျဖစ္သြားပါမယ္။ ကြ်န္ေတာ္က ဆက္ေရးခ်င္ရင္ အဲဒီ version 3 ကို check out ျပန္လုပ္ျပီး ဆက္ေရးရံုပါပဲ။

Version Control System ထဲကို သြင္းရင္ check in လုပ္တယ္လုိ႕ေျပာပါတယ္။ ျပန္ထုတ္ရန္ check out လုပ္တယ္လုိ႕ေျပာၾကပါတယ္။ Team နဲ႕ေရးတဲ႔အခါ source code ေတြကို merge လုပ္ဖုိ႕ update လုပ္ဖုိ႕ေတြအတြက္ Version Control System ကမရိွမျဖစ္လုိပါတယ္။

အခုလုပ္ေနတဲ႔ရံုးမွာေတာ႔ Borland Star Team သံုးပါတယ္။ အင္မတန္ အဆင္ေျပပါတယ္။ အရင္ရံုးမွာလည္း CVS ရိွပါတယ္။ အဆင္ေျပပါတယ္။

Version Control System ေတြရဲ႕ အားသာခ်က္က ဥပမာ ကြ်န္ေတာ္က Dynamic Patcher ကိုေရးျပီးသြားလုိ႕ customer က CR(Change Request) လုပ္ရင္ Main Project ကို မထိပဲ Branch ခြဲထုတ္ျပီး Branch မွာ Update လုပ္၊ Enhance လုပ္ျပီးမွ testing လုပ္လို႕ရပါတယ္။ ေနာက္ဆံုး အားလံုးအိုေကျပီဆုိမွ Main Branch နဲ႕ျပန္ေပါင္းျပီး Software ကို ျပန္ျပီး Deploy လုပ္လုိက္ရံုပါပဲ။

Git ကေတာ႔ Open Source ျဖစ္ပါတယ္။ Linux Kernel ကို ေရာ Adroid ေတြရဲ႕ source ေတြေရာ အဲဒီမွာ host လုပ္ထားပံုေထာက္ရင္ စိတ္ခ်ရပါတယ္လို႕ေျပာျပီးသားျဖစ္ေနပါျပီ။ အလကားရတာ မ်ားမ်ားသံုးတာဟာ Java သမားတိုင္းရဲ႕တာ၀န္ျဖစ္ပါတယ္။ အလကားရတာကို crash ျဖစ္တဲ႔အထိ သံုးပစ္ရပါမယ္။ ... Java ေရးတဲ႔သူတုိင္းဟာ အသစ္ကို စိန္ေခၚႏိုင္တဲ႔သူမ်ိဳးျဖစ္ရပါမယ္။ အေျပာင္းအလဲကိုမေၾကာက္ပါနဲ႕။ ေနာက္ဆံုးေပၚနည္းေတြဟာ လူေတြကို လြယ္ေအာင္လုပ္ေပးတာပါ။ ပိုျပီးလြယ္သထက္လြယ္လာပါတယ္။ ....

Eclipse အတြက္ စျပီးေရးၾကတဲ႔သူေတြကို အထူးေက်းဇူးတင္ပါတယ္။ အခုလည္း Git အတြက္ plug in ေလးကူးလုိက္ရံုပါပဲ။ Java ေရးတယ္ဆိုေတာ႔ Eclipse ေနာက္ဆံုးဗားရွင္းျဖစ္တဲ႔ Helios ကို သိမယ္ထင္ပါတယ္။ မသိရင္ လည္း update လုပ္လုိက္ပါ။ အဲဒီမွာ Market Place ပါလာပါတယ္။ iTunes ရဲ႕ app store အထာမ်ိဳးပါပဲ။ ပိုျပီး ရွာရေဖြရလြယ္ပါတယ္။ Git plug in ေလးသြင္းလုိက္ရံုပါပဲ။

အခုဒီလိုေလးေျပာေတာ႔ ဒါကိုမ်ားေရးေနတယ္လုိ႕ထင္ပါမယ္။ အားေနရင္ တျခားနည္းလမ္းေတြနဲ႕လည္းၾကိဳးစားၾကည္႕ပါ။ :P။

Git Plug in install လုပ္ျပီးရင္ ထံုးစံအတိုင္း Eclipse ကို restart လုပ္ပါ။ ျပီးရင္ ကိုယ္ေရးထားတဲ႔ project ကိုright click ေထာက္ျပီး share လုိက္ပါ။ Git repo မွာ share လုိက္ရံုပါပဲ။

That's all for Git integration in eclipse and basic knowledge for Version Control System .

Regards_zeroDivdedByZeroIsZero

public void callWarning(){

callWarningHelper();

}

public callWarningHelper implements DebtOfStarBucks throws notEnoughCashException(){

try{

System.out.println("

.........By the way, bro ................Didn't post for a long time meh ...

Don't be lazy as me :)

I will post a lot this month and next month :)");

//PURPOSELY THROWS EXCEPTION TO MAKE AN INFINITE LOOP

throw new Exception();

}catch(Exception exceptionIsNotError){

logger.error(exceptionIsNotError.toString());

callWarning();

}

}

Linux commands (1)

Linux console ေပၚမွာ အလုပ္လုပ္တယ့္ အခါ တစ္ခ်ိဳ႕ command ေတြက သိထားရင္ command line interface မွာ အေတာ္အသုံးဝင္ပါတယ္။ မသိလည္းရတယ္ ၊ သိရင္ ပိုအဆင္ေျပတယ့္ command ေလးေတြေပါ့။ နည္းနည္းခ်င္း ေခါင္းထဲေပၚလာသေလာက္ ေရးသြားပါမယ္။

...........
Log file လိုဟာမ်ိဳးကို ဖတ္တယ့္အခါမွာ tail command ကသုံးဝင္ပါတယ္ ။ ဆိုၾကပါေတာ့၊ httpd ရဲ့ access_log file ။ Apache process run ေနျပီး user ေတြက access လုပ္ေနတိုင္း access_log ကေရးေနပါတယ္။ ဒီလို log မ်ိဳးရဲ့ ေနာက္ဆုံး process ေတြ log ကို လိုခ်င္ရင္ အလြယ္တကူက `cat /var/log/httpd/access_log ဆိုျပီး cat ထုတ္လိုက္တာမ်ိဳး ၊ tail -n50 /var/log/httpd/access_log ဆိုျပီး ေနာက္ဆုံး လိုင္း 50 ေခၚၾကည့္တာတို႕ လုပ္လိုက္တာမ်ားတယ္။ ဒါေတြက ဒီ command ကို ႐ိုက္လိုက္တယ့္ အခ်ိန္က log ထဲမွာရွိတာကိုျပတာပါ။ Real time ေတာက္ေလွ်ာက္လာေရးေနတာကို ဖတ္ခ်င္ရင္ေတာ့

tail -f /var/log/httpd/access_log

ဆိုျပီး tail -f ကိုသုံးပါတယ္။ ဒါဆို console ထဲမွာ log file ကပြင့္လာျပီး log မွာ တစ္လိုင္းအသစ္လာေရးတိုင္း တစ္လိုင္းတက္တက္လာတယ္။ ဒါဆို debug လုပ္ဖို႕ ပို အဆင္ေျပပါတယ္။

........
တစ္ခါတစ္ေလ log file ( text file တစ္ခုခုေပါ့) ကို ရွင္းလိုက္ခ်င္တာမ်ိဳးေတြမွာ ၊ အထဲက စာေတြ လိုက္ဖ်က္ရရင္လည္း မလြယ္ဘူး။ File ကိုဖ်က္ျပစ္လိုက္ျပီး ၊ process က log ျပန္လာေရးခိုင္းတာကလည္း ေျပာရင္ သိပ္မေကာင္းဖူး။ File ကို ဖ်က္ျပစ္လိုက္ရတာကိုက မေကာင္းဘူး။ အထဲက content ကိုပဲ ရွင္းလိုက္ခ်င္ရင္ ဒီလိုေလးက လြယ္တယ္ ။

> /path/to/log.file

အေရွ႕က '>' ေလးက command ထဲမွာပါပါတယ္။ တစ္ကယ္က

echo "" > /path/to/log.file

ကိုလုပ္သြားတာပါ။ echo command နဲ႕ output pipe '>' ကိုသိရင္ ဒါကိုသိပါလိမ့္မယ္။ File ထဲက content ကို blank space တစ္ခုနဲ႕ overwrite လုပ္လိုက္တာပါ။ အဲေတာ့ log file က empty log ျဖစ္သြားတာေပါ့။

..........
ေနာက္တစ္ခုကေတာ့ shell arguments ေတြပါ။ အသုံးျဖစ္ဆုံးကေတာ့ ! နဲ႕ !$ ပါ ။
! က ေနာက္ဆုံးသုံးခဲ့တယ့္ argument ကို ကိုယ္စားျပဳပါတယ္။ တကယ္လို႕ အေပၚမွာ file တစ္ခုကို vi သုံးျပီး edit ထားတယ္။ အခု တျခား directory ကိုေရာက္ေနျပီ ။ File path ၾကီးကရွည္လို႕ ျပန္မ႐ိုက္ခ်င္ဖူးဆိုရင္

!vi

လို႕ သုံးလို႕ရပါတယ္။ Shell history ထဲက ေနာက္ဆုံး vi command ကိုျပန္ေခၚေပးပါလိမ့္မယ္။

.......
!$ ကေတာ့ last command ရဲ့ argument ကိုပဲယူတာပါ။

ls -l /bar/nyar/thar/da/kar/file

လို႕ ရွာျပီး၊ ေနာက္တစ္လိုင္းမွာ အဲ file ကို vi မွာ edit ဖို႕ဆိုရင္ ပံုမွန္ဆို vi /bar/nyar/thar/da/kar/file ဆိုျပီး ရွည္ရွည္လွ်ားလွ်ား႐ိုက္ေနရပါမယ္။ အဲေတာ့

vi !$

လို႕႐ိုက္လိုက္ရင္ ေနာက္ဆုံး command ရဲ့ argument ကိုျပန္ယူျပီး vi သြားပါလိမ့္မယ္ ။
( Up arrow နဲ႕ last command ကိုျပန္ေခၚ၊ Home ကိုႏွိပ္ျပီး ls -l ကိုဖ်က္ vi လို႕႐ိုက္ ၊ ဒါလည္းရပါတယ္။ ဒါေပမယ့္ ပိုမရွည္ဖူးလား။ ဒါေတာင္ Home တို႕ End တို႕ကို Shell environment ထဲမွာ set ထားမွပါ။ Unix အမ်ားစုမွာ default အားျဖင့္မပါပါဘူး။ Home ႏွိပ္လိုက္ရင္ ^ ေတြနဲ႕ ေပၚလာပါလိမ့္မယ္။ )

..........
အခုေတာ့ ေတာ္ေလာက္ျပီ။ အခုသုံးလိုက္မိတာေလးေတြ ေျပာျပတာပါ။ ေနာက္ၾကံုရင္ ၾကံုတာေတြ ေရးပါအုန္းမယ္ ။ တစ္ခ်ိဳ႕ command ေတြက သူ႕ေနာက္က option ေတြအရမ္း powerful ျဖစ္တာေတြရွိပါတယ္။ find တို႕လို command မ်ိဳးေပါ့။ exec လို အသုံးတယ့္တာေတြလည္း ရွိပါေသးတယ္။ ေနာက္မ်ားမွ ....

Divinity

RAID is not *Backup*

Well,I've heard of this since a few years back. It could never protect from Human errors, e.g, mistakenly issued a DROP database command. :)

Some people believe RAID 1 could save them from the risk of data looses due to hardware failure since they have 2 copies of every things. That's partially true. RAID 1 could save you from data looses due to 'a hard drive failure', not any of hardware failure. In a RAID 1 system, it includes 2 hard drives minimum ( could be 3 with a hot-spare) and a RAID controller card. Everything on a primary HDD is mirrored across on secondary one. So even if the primary HDD is failed, we could still continue our business since every bits of data are still exist on the secondary HDD. Probability of failing both HDDs at the same time is a very rare chance, approximately 0.01% chances only. Looks promising, right ?

But as I've said above, RAID controllers are involved in RAID systems and they play the main role in it. In most cases, when a RAID controller fails, it might make some improper I/O onto the hard drives which can bring your system into file system corruption. The chances of failing RAID controller is a bit high if we are dealing with integrated raid cards. Dedicated RAID controllers are much better in this case.


...................................

I've had this problem one time a year ago on Windows System running on RAID 5. It makes my system hang and gives BSOD on next reboot ( still BSOD even on the other known good machines). At that time I got a few luck to copy out all data using a Linux Live CD and it was a development server which is not too critical.

Just in a few days ago, one of our client gives us a call and says their payment gateway system is not accessible. What a generic report from a user 'not accessible' with no specific details. I could browse to their admin web UI and ssh in and looks around. But when i tried to create a file using 'touch' I got an error. Well, this's it. Initially, I was totally clam as I know this system is running on 2 mirrored HDDs. If a HDD fails, I can just swap it with a new HDD and bingo. That is what I've in my mind while travelling down to data center.

But it was not that fortunate. I was surprised to see both HDD having the same IO issue. Magic fsck could not help me this time. Try those HDDs with another spare identical machine, Kernel panic. I whispers "that's good. you give me something interesting bullsh*t for today". By running ServeRAID on the problematic machine, I could see it can't detect the HDDs all the the time even to the new HDD I just brought from office. Only thing I can do is I can backup databases and some data from linux rescue mode. Yes, some lib directories are not even browsable at this point.

I've left with no choice but to prepare a new server to replace. This existing system has self compiled Apache and some modules, including openssl and some libraries which supports TLS. It's not a difficult things, but it takes time. It's 11pm already when I started installing a new server. Well, that's an almost overnight working day.

...................................

When a RAID controller's gone, it has a chance all your data could be gone/corrupted too. So backup is a 'must' even if you are running on RAID 50. Be planned, be prepared.


Divinity

SUID ဆိုတာ

Linux / Unix system ေတြအေၾကာင္းေလ့လာရင္ SUID / SGID ဆိုတယ့္ အသုံးအႏွုန္းမ်ိဳး ေတြ႕ရတတ္ပါတယ္ ။ SUID ဆိုတာ Set User ID ကို အတိုေခၚတာပါ။ Executable file ေတြရဲ့ permission မွာ ေပးေလ့ရွိပါတယ္ ။ SUID ေပးရတယ့္ ရည္ရြယ္ခ်က္က executable permission ရွိတယ့္ ဘယ္ user ကပဲ execute လုပ္လုပ္ ၊ ဒီ command / file ကို file owner ရဲ့ identity နဲ႕ run လိုက္ပါတယ္။ ဆိုလိုတာကေတာ့ root user ရဲ့ file တစ္ခုကို everyone executable ေပးထားမယ္၊ ဒါေပမဲ့ SUID set ထားရင္ ဘယ္ user ကပဲ run run ဒီ file က root user အေနနဲ႕ run ပါမယ္။ အနီးစပ္ဆုံး လို႕ ထင္တယ့္ windows ဥပမာကေတာ့ run as administrator နဲ႕ run သလိုေပါ့။ ( သိပ္ေတာ့မတူသလိုပါပဲ။ Run as administrator ကိုေသခ်ာမသိလို႕ မေျပာႏိုင္ပါဘူး)

Linux / Unix မွာ file permission ကို rwx ( Read, Write, Execute) ဆိုျပီး သတ္မွတ္ပါတယ္။ SGID / SUID ေပးထားရင္ေတာ့ s ဆိုတာေလးေတြ႕ရေလ့ရွိပါတယ္။ဥပမာေလး ေျပာရေအာင္ ။

User တိုင္းကို cd တို႕ ls တို႕လို command မ်ိဳးကိုေတာ့ ေပးသုံးရပါတယ္။ အဲလို command တစ္ခုရဲ့ permission ကိုၾကည့္ရင္

$ ls -l /bin/ls
-rwxr-xr-x 1 root root 116688 2010-04-28 23:56 /bin/ls

File ရဲ့ owner က root ျဖစ္ျပီး other users ( Everyone ေပါ့ဗ်ာ Windows မွာေတာ့) ကို Executable permission ေပးထားတာေတြ႕ပါလိမ့္မယ္ ။ Linux File permission ( rwx တို႕ ၊ 700 တို႕ 777 တို႕ )အေၾကာင္းသိျပီးသား လို႕ ယူစလို႕ ဒါကိုမရွင္းေတာ့ပါဘူး။ ls command ကို User တိုင္းက အသုံးျပဳႏိုင္တယ္။ ေနာက္ထပ္ User တိုင္း သုံး လို႕ရတယ့္ command ေလးတစ္ခုကိုၾကည့္ရေအာင္။ Password change တယ့္ passwd command ပါ။

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 25836 2009-09-14 20:14 /usr/bin/passwd

သူလည္း everyone executable ေပးထားတယ္ ဒါေပမယ့္ တတိယအလုံးမွာ x မဟုတ္ပဲ s ျဖစ္ေနတယ္။ ဒါ SUID set ထားတယ္လို႕ ေဖာ္ျပတာပါ။ ls command တုန္းကလိုပဲ သူ႕မွာလည္း ေနာက္ဆုံးအလုံးက 'x' ၊ ဒါဆို others မွာ executable permission ေပးထားတာေပါ့။ ကြာတာက ၊ ေရွ႕မွာ 's' ျဖစ္ေနတယ္။ ls command တုန္းကလိုပဲ User တိုင္းကသုံးႏိုင္တယ္။ ဒါေပမဲ့ ဒီ passwd command ကို သုံးျပီး လုပ္သမွ်အလုပ္တိုင္းကိုေတာ့ root အေနနဲ႕ လုပ္သြားမွာျဖစ္ပါတယ္။ SUID ကို security consideration တစ္ခုအေနနဲ႕ သတ္မွတ္ၾကေလ့ရွိပါတယ္။ Command တိုင္း file တိုင္းကို အားတိုင္း SUID set မလုပ္ဖို႕ အျပင္းအထန္ ကန္႕ကြက္ပါတယ္။ ဘာလို႕လည္း ?

ခုနက passwd command ေလးကိုပဲ ၾကည့္ရေအာင္။ User တစ္ေယာက္ရဲ့ password ဟာ /etc/shadow ဆိုတယ့္ file ထဲမွာ hash အေနနဲ႕ ရွိပါတယ္။ တကယ္လို႕သာ ဒီ hash ေတြကို ရရင္ rainbow table ေတြဘာေတြနဲ႕ decipher လုပ္ႏိုင္ေကာင္းလုပ္ႏိုင္ပါတယ္။ Root user ရဲ့ password လည္း hash အေနနဲ႕ ရွိပါတယ္။ အဲေတာ့ ဒီ /etc/shadow file ထဲက data က အရမ္းအေရးၾကီးတယ့္ sensitive data ပါ။ ျဖစ္ႏိုင္ရင္ ဘယ္ user ကိုမွ ေပးမၾကည့္သင့္ဖူးေပါ့။ ဒီ /etc/shadow file ရဲ့ owner က default အေနနဲ႕ root ျဖစ္ျပီး permission က 700 ( Owner သာလွ်င္ rwx ရွိျပီး က်န္တယ့္လူေတြ read ေတာင္လုပ္လို႕မရတယ့္ permission) ေပးထားေလ့ရွိပါတယ္။

အဲမွာ စတာပါပဲ ၊ User တစ္ေယာက္က password change ရင္ passwd command ရဲ့ process တစ္ခုအေနနဲ႕ password အသစ္ကို hash ေျပာင္းျပီး ဒီ /etc/shadow file ထဲမွာရွိတယ့္ သူ႕ရဲ့ password hash ကို ျပင္ရပါမယ္။ ဒါမွ password အသစ္ျဖစ္မွာကိုး။ ဒါေပမယ့္ root user ကပဲ ဒီ file ကို edit လို႕ရတယ္။ ဒါဆို password change တိုင္း root ကိုလွမ္း change ခိုင္းရမွာလား ။ ဒါဆိုလည္း မဟုတ္ေသးဘူး။ ဒါေတြေၾကာင့္ password change ရာမွာသုံးတယ့္ passwd command ကို root အေနနဲ႕ SUID set ထားလိုက္ပါတယ္။ passwd command က လုပ္တယ့္ အလုပ္မွန္သမွ် ၊ /etc/shadow မွာ hash update လုပ္တာအပါအဝင္၊ အားလုံးကို ဒီ file ရဲ့ owner ျဖစ္တယ့္ root user အေနနဲ႕ လုပ္သြားလိုက္တယ္။ /etc/shadow ကို everyone editable ေပးရတာထက္ အမ်ားၾကီးေကာင္းတာေပါ့။ ဒီေလာက္ဆိုရင္ SUID ဆိုတာ ဘာလုပ္တယ္၊ ဘယ္လိုဆိုတာ သိေလာက္ပါျပီ။

အေပၚမွာ ေျပာခဲ့သလိုပဲ SUID set ရင္ အလြန္သတိထားရပါတယ္။ ဒီ executable file က ဘာေတြလုပ္သလည္းဆိုတာရယ္ သူ႕ source ရယ္ကို သိသင့္ပါတယ္။ SGID set ထားတယ့္ file တစ္ခုက တစ္ျခား user ကို write permission မေပးရပါဘူး။ Edit လုပ္ျပီး သူလိုခ်င္တယ့္ command ေတြေျပာင္းသြားရင္ ကိုယ္ပဲ ျပသနာျဖစ္ပါမယ္။ Shell script လိုဟာမ်ိဳး ၊ source file လိုဟာမ်ိဳးကို SUID မေပးသင့္ပါဘူး။ Content ကိုျမင္ေနရလို႕ Buffer Over Flow(BOF) flaw ရွိတာတို႕ဘာတို႕ ျဖစ္ႏိုင္ပါတယ္။ ျဖစ္ႏိုင္ရင္ Compiled binary ကိုပဲ SUID ေပးသင့္ပါတယ္။ ဒါေတာင္ safe လို႕ေျပာလို႕မရပါဘူး။

ခုတစ္ေလာ စာမေရးျဖစ္တာၾကာလို႕ Clonezilla ေလးနဲ႕ server တစ္ခုကို image အျဖစ္ေျပာင္းေနတာ ထိုင္ေစာင့္ရင္း ဒီ post ကိုေရးလိုက္ပါတယ္။ SGID ေတာ့ ေနာက္မွေပါ့ ။ ဘာေရးရမွန္းမသိသလို စာစီမရတာလည္းၾကာျပီ ။ :D


Regards
Divinity