Eclipse IDE, Project cannot import

Eclipse IDE, Project cannot import

အင္း ... အလြယ္ေလးတစ္ခုပါ။

မသိေသးရင္ခက္ေနတတ္လုိ႕။

"Some projects cannot be imported because they already exist in the workspace".

တစ္ခါတေလ အေရးရယ္အေၾကာင္းရယ္ၾကမွ Eclipse IDE က အဲဒီလို message ၾကီးနဲ႕ဆီးၾကိဳတတ္ပါတယ္။

လုပ္လို႕ရတာ ႏွစ္နည္းေလာက္ရိွပါတယ္။ ဒီထက္မကလည္းရိွႏိုင္တယ္။

ပထမနည္းက အလြယ္နည္း။ Project ကို workspace ထဲကို ကူးထည္႕။ ျပီးရင္ UI ကေန New Project ဆိုျပီး same project name ေပးလိုက္ရင္ တခါတည္း project view မွာ New Project အေနနဲ႕ ျမင္ရပါတယ္။ Import လုပ္ျပီးသား ျဖစ္သြားတာပါပဲ။

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

.project ဆိုတဲ႔ file ကို ရွာျပီး text editor တစ္ခုခုနဲ႕ဖြင္႔ပါ။ အဲဒီမွာ project name ေျပာင္းလုိက္ရင္လည္း အိုေကသြားပါလိမ္႔မယ္။

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

ကြ်န္ေတာ္ျဖစ္ေစခ်င္တာကေတာ႔ community ေလးတစ္ခုပါ။ တကယ္အလုပ္လုပ္ေနတဲ႔သူေတြရဲ႕ စကား၀ုိင္းမ်ိဳးေပါ႔။ သိျပီးသားတစ္ေယာက္က ငါးမိနစ္ေလာက္ေျပာလုိက္ရင္ က်န္တဲ႔သူေတြ ရွာခ်ိန္သက္သာသြားတယ္။ Effective ျဖစ္တာေပါ႔။ အဲဒါမ်ိဳးေတြ Contribute လုပ္ခ်င္ပါတယ္။

Java မွာဆို JDK 1.3,1.4 ေတြမွာ ျပႆနာေတြေတာ္ေတာ္မ်ားမ်ားရိွတတ္တယ္။ JDK update လုပ္လိုက္ရင္ ေကာင္းသြားမွာသိေပမယ္႔ တစ္ခါတစ္ေလ JDK upgrade လုပ္လုိ႕မရတဲ႔ systemဟာင္းၾကီးေတြမွာဆို မလိုအပ္ဘဲ အလုပ္ပိုရတယ္။ တခါလည္း Sun ရဲ႕ OS မွာပါတဲ႔ default JDK က မစံုမလင္ျဖစ္တာၾကံဳဖူးတယ္။ ျဖစ္တတ္တာကို သိထားရင္ အေျဖမွန္ေတြ႕ဖုိ႕လြယ္တယ္။ Sun က JDK ထုတ္တာပဲ သူ႕ OS ေတြမွာ complete JDK ပါမွာပဲဆိုရင္ေတာ႔ ျပႆနာအစစ္ လမ္းစေပ်ာက္သြားပါျပီ။

Let's make our Tech world better .........

Let's share what we had learnt to each others ...

Regards,

Zero

How to maintain Legacy systems in 10 min

How to maintain Legacy systems in 10 min

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

Legacy system ဆိုတာ ေရွးကတည္းက မပစ္ရက္ဘဲ သိမ္းထားတဲ႔ ဘိုးဘြားပိုင္ ဗီရိုၾကီးလို၊ ေနရရွဳပ္သေလာက္ အသံုးမက်တဲ႔ software ေတြပါ။ အဲဒီလို sytems ေတြကို စင္ကာပူ အႏွံ႕မွာေတြ႕ရပါတယ္။

အဲဒီေတာ႔ ဘယ္လို Maintain လုပ္မလဲ။

(ျဖစ္ႏုိင္ရင္ အလြယ္ဆံုးက အလုပ္ေျပာင္းလိုက္)။

အဲဒီလိုမွ မျဖစ္ႏုိင္ရင္ မရိွဖို႕မ်ားတဲ႔ documentation ေတာင္းၾကည္႕။

Database design ကို ၾကည္႕။ ဘယ္ေလာက္အသံုးမက်လဲဆိုတာကို duplicate columns ေတြ table တစ္မ်ိဳးမွာ နာမည္တစ္မ်ိဳးျဖစ္ေနတဲ႔ Column name ေတြကို အကဲခတ္လိုက္။ ဒါဆို ဘယ္ေလာက္ ခ်ီးထုပ္က်တဲ႔ system လည္းသိလာမယ္။

Source Code က compile ေတာင္လုပ္လုိ႕ရခ်င္မွရမယ္။ ဒါေပမယ္႔ ဘုရားစာဆိုထား။ ကံေကာင္းေအာင္။ ဖြင္႔ခါနီးမွာ အရဟံေလးဘာေလးရြတ္၊ ဥံဳ ဆိုျပီး ဖြင္႔ၾကည္႕လုိက္ရင္ ... အဲဒီမွာ အံ႕အားသင္႔စရာေကာင္းေလာက္ေအာင္ ျဖစ္သလိုေလးလုပ္သြားတဲ႔ေကာင္ေတြရဲ႕ codes ေတြကို ေတြ႕ရမယ္။ အဲဒါဆို သတ္ေသလိုက္ရမလား။ .... မဟုတ္ေသးဘူး။ မလုိဘူး။ ကိုယ္႔ကိုယ္ကို တစ္ခုပဲယံုၾကည္။ ေရွ႕ကေကာင္ေတြထက္ ေတာ္လုိ႕ ငါ္႔လက္ထဲေရာက္လာတာလုိ႕ပဲေတြးလုိက္။ ဟုတ္ဟုတ္မဟုတ္ဟုတ္။

စိတ္ထဲမွာတစ္ခုပဲထား။ ေရွ႕ကကိစၥေတြမွာ မွားရင္ တတ္ႏိုင္သမွ်ျပင္မယ္။ ငါျပင္သမွ်ကိုေတာ႔ ငါတာ၀န္ယူတယ္။ အဲဒါကို နည္းနည္း လူသိေအာင္လုပ္ထားပါ။ အရင္က ႏွစ္ေပါင္းမ်ားစြာ ဘာမွမျဖစ္ဘဲ run လာတယ္လို႕ေျပာရင္ Are U sure, dude? လုိ႕ေသခ်ာေမးထားပါ။ ဘာမွမျဖစ္ဘဲ run ေနတာနဲ႕ ဘာျဖစ္ေနမွန္းမသိဘဲ run ေနတာနဲ႕ဟာ ငတံုးေတြအတြက္ေတာ႔ အတူတူပဲ။

စိတ္ပိုင္းဆုိင္ရာမွာ အဲဒီလို ျပင္မဟဲ႕လို႕ပိုင္းျဖတ္ျပီးရင္ တစ္ခုကို အေသမွတ္ပါ။ ျမင္ေနရတဲ႔ source code ဟာ ကိုယ္တစ္ေယာက္တည္းသံုးေနတာမဟုတ္ဘူးဆိုတာကို သံုးခါေလာက္ ႏွလံုးသြင္းပါ။ Legacy မွာ ဒီ codes ေတြကို တျခား system ေတြက share သံုးေနတာ ၊ interface ေတြက တစ္ဆင္႔ သံုးေနတာ၊ web service share ထားတာ အကုန္ျဖစ္ႏုိင္တယ္။ လံုး၀မထင္မွတ္ေလာက္ေအာင္ အသံုးမက်တဲ႔ ေနာက္တစ္ခုခုေတာင္မွ ျဖစ္ႏုိင္တယ္။

ေနာက္ျပီး တစ္ခုသိထားဖုိ႕က Obama ဘယ္ေလာက္ေတာ္ေတာ္ အေမရိကန္မြဲတာမကယ္ႏုိင္ဘူး .. ဆိုတာေလးကို သတိျပဳပါ။ ဆိုလိုတာက revamp လုပ္ထည္႕လုိက္မယ္လို႕ သိပ္ျပီး မစဥ္းစားေစခ်င္ဘူး။ ေလာေလာဆယ္ ဘယ္လို architecture မွာ သံုးထားလဲ။ အဲဒီ architecture ရဲ႕ limitation ေတြကို နားလည္သင္႔သေလာက္နားလည္ဖုိ႕လုပ္ပါ။ ျပင္တဲ႔အခါၾကရင္ function ေသးေသးေလးတစ္ခုပဲျဖစ္ျဖစ္ျပင္တာနဲ႕ ဘယ္ေနရာမွာ သံုးထားေသးလဲ ေသခ်ာေအာင္ လုပ္ပါ။ java သမားေတြဆို eclipse မွာ reference->workspace or reference-->project ေတြ ၾကည္႕ပါ။ source code control ေတြဘာေတြ ေသခ်ာသံုးပါ။ တကယ္လုိ႕ ကိုယ္ျပင္လုိက္တာၾကီးမွားသြားရင္ေတာင္ ခ်က္ခ်င္း rollback ျပန္လုပ္ႏုိင္ေအာင္လုပ္ထားပါ။

ျပင္တဲ႔အခါ Java မွာဆိုရင္ ကိုယ္ျပင္လုိက္တဲ႔ class ကို အတတ္ႏိုင္ဆံုး သပ္ရပ္သြားေအာင္လုပ္ပါ။ warning ေတြရိွရင္လည္း တတ္ႏိုင္သမွ်ရွင္းပါ။ Clean Code ျဖစ္ဖုိ႕ ၾကိဳးစားပါ။ ကိုယ္ေရးတာေတြဆိုရင္ေတာ႔ ပိုေတာင္ ဂရုစိုက္ပါ။ အလြယ္ဆံုး နည္းက One function once class ဆိုတာပါ။ အဲဒီလိုေျပာရင္ တစ္ခ်ိဳ႕ေတြကလည္း ပ်င္းၾကတယ္။ မပ်င္းပါနဲ႕။ Java ကို resuable ရေအာင္ ေရးႏုိင္ဖုိ႕ဆိုတာ အေျခခံ design pattern ေတြေက်ညက္ဖုိ႕ အမ်ားၾကီးလိုပါတယ္။

ကြ်န္ေတာ္ လြန္ခဲ႔တဲ႔ တစ္ႏွစ္ခြဲတုန္းက လုိင္း ၃၀၀၀ ရိွတဲ႔ class ေတြ ေရးခဲ႔တဲ႔ နေမာ္နမဲ႕ developer ပါ။ အခုအခ်ိန္မွာေတာ႔ ကိုယ္႔ေနာက္မွာ ကိုယ္ေရးတာကို ျပင္ရမယ္႔လူေတြအတြက္ပါၾကည္႕ပါတယ္။ common method ေတြကို helper class ေတြေရးသလို ဘံုထုတ္ထားလုိက္ပါ။ ေနာက္သံုးခ်င္တဲ႔ေနရာကလည္း ယူသံုးႏုိင္တာေပါ႔။ သိပ္ရွဳပ္ရွဳပ္ေထြးေထြး ျဖစ္လာရင္ တျခား class တစ္ခုမွာ business logic ေတြ ေျဖရွင္းဖုိ႕ helper တစ္ခုေရးလုိက္ပါ။ Action class ေတြမွာ အားလံုးစုေရးတာဟာ အသံုးမက်တဲ႔သူေတြလုပ္ေနၾကပါ။ အဲဒါမ်ိဳးဘယ္ေတာ႔မွ မလုပ္ပါနဲ႕။ Program ရဲ႕ readibilty က်သလို၊ အားလံုးက tightly coupled ျဖစ္ေနလိမ္႔မယ္။ သပ္သပ္ရပ္ရပ္ မေရးတတ္ေသးတဲ႔သူေတြအေနနဲ႕ flow diagram ေလး အၾကမ္းေလာက္ျခစ္လုိက္ဖုိ႕ ၀င္မေလးေစခ်င္ဘူး။ အဲဒီလို ေသေသခ်ာခ်ာေရးၾကည္႕မယ္ဆုိရင္ အပိုအလိုမရိွတဲ႔ clean code ေတြရလာမယ္။ method ေတြ ေဖာင္းပြမႈမရိွေတာ႔ပါဘူး။

method တစ္ခုကို တတ္ႏိုင္ရင္ duplicates ဘယ္ေတာ႔မွမလုပ္ပါနဲ႕။ ကြ်န္ေတာ္နမူနာတစ္ခုေပးပါမယ္။ ကြ်န္ေတာ္သာ ဘံုသံုးလုိ႕ရႏိုင္တဲ႔ method တစ္ခုကို ေနရာတုိင္းမွာ copy ။ paste လုပ္ထားတဲ႔ codes ကို တစ္နာရီေလာက္ျပင္ရျပီဆိုရင္ ေရွ႕က ေရးသြားတဲ႔ေကာင္ကို အယုတၱ အနတၱေတြ စျပီး ေရရြတ္ပါျပီ။ တကယ္႔ကို tedius ျဖစ္စရာမဟုတ္လား။ ေနာက္တစ္ခုက တစ္ေနရာမွာ ကိုယ္ျပင္ဖုိ႕က်န္ခဲ႔ရင္ အဲဒီကလည္းျပႆနာျဖစ္ႏုိင္တယ္။ အထူးသျဖင္႔ calculations ေတြအမ်ားၾကီးပါတဲ႔ method ေတြကို ဘယ္ေတာ႔မွ duplicates မလုပ္မိဖုိ႕ ၊ တတ္ႏိုင္သမွ် share သံုးဖုိ႕ၾကိဳးစားပါ။ တစ္ေနရာမွာ ျပင္လုိက္ရံုနဲ႕ အားလံုးမွာ အိုေကသြားတယ္ဆိုရင္ ေနာက္လူရဲ႕ အဆဲအဆို အေတာ္ေလးသက္သာသြားႏုိင္ပါတယ္။

ေနာက္တစ္ခုက testing ပါ။ ကုိယ္ျပင္လိုက္တာဟာ ေရွ႕က flow ကို ထိခုိက္လားမထိခိုက္လား ဘယ္လိုသိမွာလဲ။ Unit Testing မရိွရင္ေတာ႔ sorry ပဲေျပာရမွာပဲ။ ကိုယ္႔အပိုင္းကိုေတာ႔ ေသခ်ာစစ္ပါ။ တတ္ႏုိင္သမွ် extreme test ေတြလုပ္ပါ။

အားလံုးေရးျပီးရင္ အခ်ိန္နည္းနည္းေလးပိုယူျပီး system document လုပ္ဖုိ႕ၾကိဳးစားပါ။ ဘယ္သူ႕အတြက္မွ မဟုတ္ပါဘူး။ ကိုယ္႔ဘာသာကိုယ္ ပိုနားလည္ဖုိ႕ၾကိဳးစားတဲ႔သေဘာပါပဲ။ ေနာက္ေတာ႔ source code ကို Version Control System ထဲ check in ျပန္လုပ္ပါ။

တတ္ႏိုင္သမွ် ေရွ႕မွာ ေရးထားတဲ႔ codes ေတြကို ျပင္ဖုိ႕မၾကိဳးစားပါနဲ႕။ တကယ္ျပင္ရမယ္႔အခ်ိန္ၾကရင္သာ ေသခ်ာနားလည္ေအာင္လုပ္ျပီး ျပင္သင္႔သေလာက္ပဲျပင္ပါ။ တျဖည္းျဖည္းခ်င္း ပိုေကာင္းျပီး ပို stable ျဖစ္လာတဲ႔ sytem ျဖစ္ေအာင္ ေရရွည္လုပ္သြားၾကပါ။

Source code is the best documentation ဆိုတာေလးကိုလည္း သတိေပးလိုက္ပါတယ္။ Functional Spec: ေတြ၊ documentation ေတြထဲမွာ ဘာေတြေရးထားေရးထား source code မွာမပါရင္ အလကားပါပဲ။ တကယ္တမ္း လက္ေတြ႕ေလာကမွာ ျပည္႕စံုတဲ႔ documentation ကို ေတြ႕ရဖုိ႕ဆိုတာ ဘုရားပြင္႔တာကို ၾကံဳရသလို ၾကံဳေတာင္႔ၾကံဳခဲျဖစ္ေနတတ္ပါတယ္။ common sense နဲ႕ အာရံုေတြဖ်တ္လတ္ေအာင္ထားျပီး အေကာင္းဆံုးၾကိဳးစားဖုိ႕ပဲရိွပါတယ္။

Legacy Systems ေတြဟာ developers ေတြရဲ႕ အေကာင္းဆံုးေလ႔က်င္႔ေရးကြင္းပါပဲ။

Regards,

Zero

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