Turing Programming Training Center

Turing Programming Training Center Programming/Software Development နဲ.ပတ်သတ်ပြီး Human Resources တွေမွေးထုတ်ရာသင်တန်းတခု

16/05/2026

How does JavaEE work.
Java က စထုတ်တုန်းက SE ပဲရတယ် standard edition ပေါ့ ဆိုချင်တာက desktop application ပဲရေးဖို.လုပ်ထားတာ။ နောက်ကျတော့ JavaEE ထုတ်လာတယ် အဲ့တော့ enterprise application လွယ်လွယ်ပြောရရင် server side web application ရေးလို.ရလာတယ်။

PHP လိုကောင်မျိုးကျတော့ စထုတ်ကတည်းက server side scripting language အနေနဲ.ထုတ်တာ။ Programming language တွေက ဘယ်လိုလုပ်ပြီး web server တွေနဲ.ချိတ်ဆက်လုပ်တယ် ဒါမှမဟုတ် ဘယ်လိုလုပ် web application ပေးရေးတယ်ဆိုတာကိုနားလည်ဖို. HTTP protocol ရယ် Web server အကြောင်းရယ် နားလည်ဖို.လိုတယ်။
အရင်က အဲ့ဒီအကြောင်းဒီမှာရေးဖူးတယ်

https://web.facebook.com/thet.khine.587/posts/10207213385452495
PHP လို server side scripting language တွေကျတော့ web server နဲ.တန်းချိတ်ပြီးအလုပ်လုပ်တယ်။ Apache လို web server မျိုးပေါ့။ Web server တွေသည် external application program တွေနဲ.ချိတ်ဆက်လုပ်ဖို. interface ပေးထားတယ်။ CGI လို.ခေါ်ကြတယ်။ Common Gateway interface ပေါ့။ Request တခုလာမယ် အဲ့ကနေ web server က တခြား external program ကိုခေါ်မယ် နောက်လိုအပ်တဲ့ data တွေလှမ်းပေးမယ်။ နောက် external program (eg PHP) လိုကောင်က ထွက်လာတဲ့ output တွေကို web client ကိုပြန်ပေးမယ်ပေါ့။ CGI တွေက request တခုလာ process တခုလုပ်လေးလာတော့ နောက်ပိုင်း fast CGI သုံးလာတယ်။

ထားတော့ Java ဘက်ကျတော့ အဲ့လိုမဟုတ်ဘူး web server နဲ.တိုက်ရိုက်မချိတ်ဘူး အဲ့တော့ ဘာလုပ်ရသလဲဆိုတော့ ကိုယ်ပိုင် HTTP server(web server) ဆောက်ရတယ်။ ဉပမာ Java နဲ. Web server ရေးလိုက်တယ်(JavaSE က network programming သုံးပြီး socket program တွေနဲ.လုပ်လိုက်တယ်) ဒါဆို web content တွေ serve လုပ်လို.ရပြီ။ အဲ့ layer အပေါ်ကိုမှ server side program တွေ ရေးလို.ရအောင် servlet ဆိုတဲ့ class တွေထပ်ထဲ့လိုက်တယ်။

Servlet သည် Web request ကိုလက်ခံမယ် output ကိုပြန်ပေးမယ် အဲ့တာလေးပဲ basic flow က ။ ခုနက servlet API ကို support ပေးထားတဲ့ container တွေကို servlet container လို.ခေါ်တယ် ဥပမာ tomcat ပေါ့။
အဲ့တော့ tomcat ထဲမှာဘာပါလဲ ဆိုရင် အဓိက web server (Coyote http connector လို.သုံးတယ်) နောက် servlet ကို support လုပ်ဖို. servlet container( Catalina လို.ခေါ်တယ်) ပါတယ်။

နောက် ခုနက Servlet သည် Java code တွေချည်းရေးရတာ ဆိုချင်တာက html view layout တွေရေးမယ်ဆိုရင် IO command တွေကနေ string နဲ.ရိုက်ထုတ်ရတာ။ အဲ့တော့ view အပိုင်းအဆင်မပြေဘူး အဲ့တာကိုရှင်းဖို.အတွက် JSP ထုတ်လိုက်တယ်( JavaServer Page ) ပေါ့ HTML , Java code တခါတည်းပေါင်းရေးလို.ရသွားတယ်။ JSP ဆိုတာလဲ တကယ်တမ်းက servlet ပါပဲ JSP page ကို compile လုပ်ရင် servlet ပြန်ရတယ်။

ခုနက JSP ကနေ servlet ထုတ်ပေးတဲ့ကောင်ကို JSP Engine လို.ခေါ်တယ်။ Tomcat မှာဆို Jasper engine ပေါ့။ နောက် JSF လို MVC ကောင်တွေထွက်လာတယ် သူတို.လဲ အောက်ဆုံးမှာ Servlet ကိုသုံးရတာပါပဲ။
JavaEE component တွေ technologies တွေ မအောင်မြင်တာကြောင့် third party framework တွေ Spring လိုကောင်တွေထုတ်လာတယ်။ Spring ကျတော့ အဓိက DI support ပေးတယ်။ နောက်ကွယ်မှာ အဓိက server side သုံးတာကတော့ servlet based ကိုပဲသုံးတာ။ Front Contoller pattern ကိုသုံးထားတဲ့ servlet က request တွေကိုအကုန်ဖမ်းထိန်းပြီး မှ နောက် ဆိုင်ရာ controller တွေဆီကိုပို.ပေးတာ။ DispatcherServlet လို.ခေါ်တယ်။

နောက်ပိုင်း Node.js က rest API framework တွေခေတ်စားလာတော့ Java ဘက်မှာခုနက container တွေမလိုပဲ framework ထဲမှာတင် web server ပါလာအောင် content handling ထဲ့ပေးထားတဲ့ micro framework တွေပေါ်လာတယ် eg. spark.

10/05/2026

Why use token authentication

Authentication ဆိုတာက system တခုကိုသုံးခွင့်ရှိတဲ့ user ဟုတ်မဟုတ်(identity) ကိုစစ်တာ ဥပမာ ကျောင်းထဲဝင်ဖို့
ကျောင်းသား ဒါမှမဟုတ် ဆရာ ဒါမှမဟုတ် ကျောင်းမှာအလုပ်လုပ်နေတဲ့သူတွေပဲဝင်လို့ရမယ်။ ကျောင်းကို system လို့သတ်မှတ်ရင်
ခုနက ကျောင်းသား ဆရာ စတာတွေက valid user ပဲ။ အပြင်လူဝင်လို့မရဘူး။ ဥပမာ facebook သုံးရင် facebook user ဖြစ်မှ
သုံးလို့ရမယ်။

Authorization

Authorization ဆိုတာကျတော့ user က valid user ဖြစ်ပြီ(already authenticated) ဒါပေမဲ့ resource တခုခုကို
access လုပ်ဖို့ right ရှိသလားဆိုတာစစ်တာ၊ ဥပမာကျောင်းထဲ ကျောင်းသားကဝင်လို့ရပေမဲ့ ကျောင်းအုပ်ကြီး ဗီဒိုတော့ဖွင့်ခွင့်ရှိမှာမဟုတ်ဘူး။
အဲ့တာက Authorization, ဥပမာ user level role ပဲရှိတဲ့သူက admin level role ရှိတဲ့ page, function စတာတွေ
သုံးလို့မရဘူး။

Token based authentication ဆိုတာ Web, Mobile, Server to server(microservices) စတာတွေမှာ
token တခုကိုသုံးပီးတော့ authenticated လုပ်တာကိုပြောတာ။ Token ဆိုတာ ကတော့ များသောအားဖြင့် user identity ဒါမှမဟုတ် grant ကို hash ယူထားတာပါပဲ။
Physical token (key card လိုကောင်တွေ) တွေရှိသလို software token တွေရှိပါတယ်။ software token ဘက်မှာဆို OAuth, JWT စတာမျိုးတွေရှိကြပါတယ်။

JWT ကဒီမှာရေးထားဖူးပါတယ်။
https://www.facebook.com/thet.khine.587/posts/pfbid02NLUMj5Vi8cu5gFXNv1CFHg2SNuXrrXtuyRkqU6tggA7hQKCYfUdcRKG87rJWLCvWl

Token based authentication flow က ဒီလိုသွားတယ် အကြမ်းဖျင်းပေါ့

user က login ဝင်ဖို့ username,password နဲ့ပေးလိုက်တယ် server ဘက်က username password မှန်ရင် token
ပြန်ပေးလိုက်တယ်။ အဲ့ token ကို နောက် API call တွေဖို့ header ထဲမှာထဲ့ပေးလိုက်တာ။ဒါဆို server က token
ကိုစစ်ပြီး valid token ဆိုရင် authenticated ဖြစ်ပြီဆိုပြီးသတ်မှတ်လိုက်တာ။

များသောအားဖြင့် access token, refresh token ဆိုပြီးသုံးကြတယ်။ Access token က သက်တမ်းတိုတယ်။
ဘာလို့ဆိုတော့ token ကိုရသွားရင်ပေါက်သွားမှာစိုးလို့၊ အဲ့တော့ acess token expiry ဖြစ်သွားရင် refresh token
ကိုသုံးပြီး access token ပြန်ထုတ်တယ်။ refresh token ကျတော့ expire time ကိုကြာကြာထားလေ့ရှိတယ်။

Web application တွေဆိုရင် session based authentication ကိုလဲသုံးလို့ရတယ်။ User က login ဝင်မယ်။
Credential မှန်ရင် unique session ID ထုတ်ပေးလိုက်မယ်။ Session ID ကိုဘယ်လိုထုတ်သလဲဆိုတော့ timestamp,
user_id, random number, hash စတာတွေသုံးပြီးထုတ်တယ်။ Language တခုနဲ့တခုတော့မတူဘူး Guess လုပ်ရခက်အောင်
unique ဖြစ်တဲ့ hash ပဲ။ ပြဿနာက သူ့ကို file system ဖြစ်ဖြစ် (PHP မှာဆို file မှာသိမ်းတယ်) DB မှာဖြစ်ဖြစ်သိမ်းရတယ်။
အဲ့တော့ scalable မဖြစ်ဘူး။ဥပမာ ဒီ session က valid ဖြစ်လား စစ်ဖို့ File read, DB Read လုပ်နေတာ မျိုးသည် IO ပါတယ်။
JWT လို token မျိုးကျတော့ in memory မှာတင် hash တွက်လို့ရတယ် ပိုမြန်တယ်။
နောက် session တွေသည် ဆိုင်ရာ web server နဲ့ tie ဖြစ်တယ်။ တကယ်လို့ ကိုယ်က scalability ရဖို့ load balancer
နောက်မှာ web server ၂ ခုသုံးရမယ်ဆိုရင် web server1 နဲ့ session ID ထုတ်ထားတဲ့ request သည် web server 1 ဆီကိုပဲသွားရတယ်
အဲ့တော့ load balancing မှာအဆင်မပြေဘူး။ sticky session လို့ခေါ်တယ်။
Token based ကျတော့အဲ့လိုမဖြစ်ဘူး ကြိုက်တဲ့ကောင်သွား microservices architecture မှာဆိုအိုကေတယ်။

များသောအားဖြင့် web session တွေကို cookie မှာသိမ်းကြတယ်အဲ့တော့ CRSF attack ဖြစ်နိုင်တယ်။

Token တွေကို server ဘက်ကနေ revoke လုပ်နိုင်တယ်။အဲ့အခါကျတော့ tigher control ဖြစ်တယ်။

Federate authentication

Authentication system တခုထဲကိုသုံးပြီးတော့ multiple system တွေကို access ပေးတာ၊ ဥပမာ Facebok, Google
သုံးပြီးတော့ medium တို့လိုကောင်တွေကို register/login ဝင်လို့ရတယ် ဒါမျိုးကို Federate authentication လို့ခေါ်တယ်။
SSO (Single Sign On )လို့လဲသုံးကြသေးတယ်။

ခုနက session id လိုကောင်မျိုးက ဆိုင်ရာ system DB, file system မှာသိမ်းတဲ့အတွက် ဥပမာ app1 က db ကို app2 ကို
ပေးသုံးမှ login ဝင်လို့ရမဲ့ပုံစံဖြစ်တယ်။ Token ကျတော့ သိမ်းထားတာမရှိတဲ့အတွက် Federate authentication
ပိုအဆင်ပြေတယ်။

08/05/2026

Type System in programming Languages

လက်ရှိသုံးနေတဲ့ Programming Languages တွေအများကြီးရှိပါတယ်။ အဲ့ဒီ programming languages တွေရဲ. Type system တွေအကြောင်းဆွေးနွေးချင်ပါတယ်။ Type ဆိုတာက programming မှာတော့ programmer ကနေ define လုပ်လို.ရတဲ့ variable တွေ object တွေ ရဲ. အမျိုးအစားကို ပြောတာပါ။ ဥပမာ integer, float, string, object အစရှိသည်ဖြင့်ပေါ့။ Type တွေကိုဘာကြောင့် ပေးထားရသလဲဆိုတော့ programmer အနေနဲ. Higher abstraction ကိုမှန်မှန်ကန်ကန် နဲ.လွယ်လွယ်ကူကူတည်ဆောက်နိုင်အောင်ပါ။ ဒီနေရာမှာ Abstraction ဆိုတာ ကိုသိစရာမလိုတဲ့ inner details (eg memory representation of float in binary)ဖယ်ပြီး သုံးနိုင်တာကိုပြောချင်တာပါ။ ဆိုလိုချင်တာက machine language level မှာ float ရယ် integer ရယ်ဆိုပြီး ခွဲထားတာမရှိပါဘူး။ အဲ့တော့ programmer က float ကို represent လုပ်ဖို.အတွက် binary representation ကိုသိဖို.လိုလာပါပြီ။ နောက်ပြီး float နှစ်ခုပေါင်းမယ်ဆိုရင် floating point arithmetic(in binary)ကိုသိဖို.လိုလာပါပြီ။ programming language တွေက float လို data type မျိုးကို ထည့်သွင်းပေးထားတဲ့အတွက် programmer တွေဟာ ခုနကလို (binary arithmetic) လို low level detail သိစရာမလိုပဲ၊ higher abstraction ကိုသုံးပြီး program ရေးလို.ရသွားပါပြီ။ နောက်တခုက type နဲ.ပတ်သတ်တဲ့ error တွေကို low level အနေနဲ.ဆိုရင် ဖမ်းဖို.သိပ်မလွယ်လှပါဘူး ၊ဥပမာ float တန်ဖိုးသိမ်းထားတဲ့ memory location တခုကို string operation သွားလုပ်ချင်လဲလုပ်နိုင်ပါတယ် ၊အဲ့ဒါကို သိနိုင်တဲ့ နည်းမရှိပါဘူး။ ဒါကြောင့် high level programming language တွေမှာ type ကိုပေးထားတဲ့အပြင် type နဲ.ပတ်သတ်တဲ့ error တွေကိုပါ ဖမ်းပေးနိုင်တဲ့ အတွက် program ရေးရတာပိုမိုလွယ်ကူ လာတာပဲဖြစ်ပါတယ်။ ဥပမာ String နဲ. Integer နဲ.သွားမြှောက်တာမျိုး လုပ်လို.မရပါဘူး ၊ လုပ်ရင်လဲ compiler ကနေ error ပြမှာပါ။ ဒါဟာ type system ပေးထားတာရယ် type system မှာလိုက်နာရမဲ့ type နဲ.ဆိုင်တဲ့ rule တွေထုတ်ထားတာကြောင့်ဖြစ်ပါတယ်။ ယေဘုယျအားဖြင့် programming languages တွေကို သက်ဆိုင်ရာ type system အရ နှစ်မျိုးခွဲနိုင်ပါတယ်။ Statically Typed language နဲ. Dynamically Type language ဆိုပြီး ခွဲလို.ရပါတယ်။

Statically Typed Language
Statically Type language ဆိုတာ ဘယ်လို programming language အမျိုးလဲဆိုတော့ သူ. Language မှာရေးထားတဲ့ variable တွေရဲ. type ကို compile time မှာ သတ်မှတ်ခြင်းခံရရင် statically typed language လို.ဆိုရမှာပါ။ နောက်သိသာတဲ့ အချက်တစ်ခုက statically typed programming language မှာရှိတဲ့ variable တွေရဲ. Data type ဟာ တသမတ်တည်း မပြောင်းလဲပဲ တည်ရှိနေမှာပါ။ ဥပမာ ကျွန်တော်တို.က variable တစ်လုံးကို int( Integer) လို.ပေးထားမယ်ဆိုရင် သူ.ရဲ. type program အစကနေ အဆုံးထိ ဟာအမြဲတမ်း int ပဲဖြစ်နေမှာပါ။ run time (program execution)လုပ်နေတုံးအချိန်မှာလဲ ပြောင်းလဲခြင်းရှိမှာမဟုတ်ပါဘူး။ ထင်ရှားတဲ့ statically typed programming language တွေကတော့ C,C++, Java,C #,Scala,Go အစရှိတဲ့ programming language တွေဖြစ်ပါတယ်။ C # ကတော့နောက်ပိုင်းမှာ type inferencing , dynamic type တွေကိုပါ support လုပ်လာပါတယ်။ အဲ့တော့ C # ဟာ hybrid typed language လို.ပြောရင်တောင်ရပါတယ်။ ဥပမာ အောက်မှာပေးထားတဲ့ Java program ဟာ error ပြပါလိမ့်မယ်

public class TypingSystemDemo {
public static void main(String[] args) {
int a = 10;
a = "Hello";
}
}
ပထမ line မှာ a သည် integer အမျိုးအစား variable လို.ကြေငြာပါတယ်။သူ.ထဲကတန်ဖိုးကို 10 လို.ထဲ့ပါတယ်။ နောက်တကြောင်းမှာတော့ a ဟာ String type အဖြစ်ပြောင်းထဲ့ပါတယ် ၊ ဒါဆိုရင် statically typed language အဖြစ်တဲ့အတွက် compiler က error ပြမှာဖြစ်ပါတယ်။ Static typed language တွေမှာ type နဲ.ပတ်သတ်တဲ့ error တွေကို compile time(program ကိုရေးပြီး compile လုပ်သောအချိန်)မှာကတည်းက ပြပေးပါတယ်။ Type operation တွေဟာ invalid ဖြစ်နေတယ်ဆိုရင် program ဟာ compiled လုပ်လို.ရမှာမဟုတ်ပါဘူး။ compilation မအောင်မြင်နိုင်ပါဘူး။ type နဲ.ပတ်သတ်တဲ့ error တွေ (ဥပမာ Java မှာဆိုရင် int ထဲကို float ထဲ့တာမျိုး) (တခြားသော syntax error)တွေမှန်မှသာလျှင် program သည် successfully compile ဖြစ်ပါလိမ့်မယ်။ Statically typed language တွေရဲ. သဘောတရားအရ variable တွေကိုကြေငြာပြီးမှ (declaration လုပ်ပြီးမှ) ပေးသုံးလေ့ရှိပါတယ်။

Dynamically Type Language
Program မှာသုံးထားတဲ့ variable တွေရဲ. Type ကို compile time မှာ သတ်မှတ်တာမဟုတ်ပဲနဲ. Runtime ရောက်မှသတ်မှတ်ပေးရင် အဲ့ဒီလို language မျိုးကို dynamically typed language လို.သတ်မှတ်ပါတယ်။ နောက်ပြီး အဲ့ဒီ variable ရဲ. Type သည် program runtime မှာကြိုက်သလိုပြောင်းနေနိုင်ပါတယ်။ ဥပမာ variable တစ်ခုဟာ ပထမ integer type ဖြစ်နေပြီး နောက်မှ string ဒါမှမဟုတ် object type အနေနဲ.ဖြစ်ချင်လဲဖြစ်နေနိုင်ပါတယ်။ Variable declaration ကိုလဲ မကြေငြာပဲသုံးမယ်ဆိုရင်လဲ သုံးနိုင်ပါတယ်။ ထင်ရှားတဲ့ dynamically typed programming language တွေကတော့ Smalltalk, Ruby, Python, PHP, JavaScript,Dart အစရှိတာတွေဖြစ်ပါတယ်။ Dynamic typed language တွေဟာ runtime မှာ type နဲ.ပတ်သတ်တာတွေကို manage လုပ်ရတဲ့အတွက် Interpreter, ဒါမှမဟုတ် Virtual Machine အစရှိတာတွေကိုသုံးရပါတယ်။ အရင်ကတော့ dynamically typed language တွေဟာ statically typed language တွေထက် performance ကွာခြားချက် အများကြီးရှိပေမဲ့ အခုအချိန်မှာ virtual machine တွေ (JIT) နည်းပညာတွေတိုးတက်လာတာနဲ.အမျှ performance ကွာခြားချက်က ကျဉ်းမြောင်းလာပါပြီ။ အောက်က program လေးက JavaScript နဲ.ရေးထားတဲ့ dynamic typing demo program လေးပါ။

var a = 20;
console.log(typeof a);
a = "Hello";
console.log(typeof a);

ဒီကောင့်ကို firebug console မှာ ပဲဖြစ်ဖြစ် script tag ထဲမှာပဲဖြစ်ဖြစ် run လိုက်မယ်ဆိုရင်။ ပထမ console.log() ကနေ number ဆိုတာထုတ်ပေးမှာဖြစ်ပြီး ဒုတိယတခုကတော့ string ကိုထုတ်ပေးပါလိ့မ်မယ်။ ဒီ program ကဘာကိုပြသလဲဆိုတော့ dynamic language တွေရဲ. Nature ဖြစ်တဲ့ variable တွေရဲ. Type ကို runtime မှာ ပြောင်းလို.ရတယ် ဆိုတဲ့သဘာဝကိုပြတာပါ။ တကယ်လို. C # မှာ ခုနကကောင်ကို dynamic type သုံးပြီးရေးချင်ရင် ဒီလိုသုံးလို.ရပါတယ်။

using System;
namespace Dynamic
{
class DynamicDemo
{
static void Main(string []args)
{
dynamic d = 10;
Console.WriteLine( d.GetType() );
d = "Hello";
Console.WriteLine( d.GetType() ) ;
}
}
}
ဒီ C # program ကို compile ပြီး run လုပ်လိုက်မယ်ဆိုရင်
System.Int32
System.String
ထွက်လာမှာပါ။ ဒါဟာ C # ရဲ. Dynamic typing ကို support လုပ်တာကိုပြတာပါ။ dynamic ဆိုတဲ့ keyword ကိုသုံးရင် ကျွန်တော်တို.ဟာ C # မှာ type တွေကို runtime မှာပြောင်းပြီးရေးလို.ရပါတယ်။

Advantages and Disadvantage of Statically Typed Language and Dynamically Typed Language
Static typed language တွေဟာ type နဲ.ပတ်သတ်တဲ့ type error ကို compile time မှာကတည်းက သိနိုင်တဲ့ bug early detection ကိုပေးပါတယ်။ Dynamically language တွေကတော့ဒါကိုမပေးနိုင်ပါဘူး။ Type information ကို program code ထဲမှာ ထဲ့ရေးရတဲ့အတွက် static typed language တွေဟာ documentation ကိုပိုမိုကောင်းမွန်စေပါတယ်။ ဥပမာ method တခုရဲ. Parameter ကို static typed language တွေမှာ မဖြစ်မနေထဲ့ရအတွက် ဒီ method ဟာဘယ်လို parameter တွေလက်ခံမလဲဆိုတာသီးသန်. Comment သို.မဟုတ် documentation ရေးစရာလိုပဲနဲ.သိနိုင်ပါတယ်။ Dynamically typed language တွေကျတော့ comment သို.မဟုတ် documentation ထဲ့ရေးမှသာသိနိုင်မှာပါ။ Static typed language မှာ type information ကိုကြိုသိတဲ့အတွက် type အပေါ်မူတည်ပြီး efficient ဖြစ်တဲ့ code ကိုထုတ်ထားလို.ရပါတယ် ဥပမာ a+b ဆိုရင် a နဲ. b နှစ်ခုလုံးဟာ integer ဆိုရင် integer addition ၊ တခုခုက floating point ပါရင် float addition, string တခုခုပါရင် string concantenation ဆိုပြီး compile time မှာကတည်းက ထုတ်ပေးတဲ့အတွက် program ဟာ မြန်သွားပါလိမ့်မယ်(runtime မှာ ဘာမှလုပ်စရာမလိုတော့လို.ပါ)။ Dynamic language တွေမှာကျတော့ ဘယ် operation လုပ်ရမလဲဆိုတာ(ဥပမာ integer addition or float addition )ဆိုတာ runtime ရောက်မှသိရတဲ့အတွက် အဲ့ decision ကိုချနေရတဲ့အတွက် သာမာန်အားဖြင့် type အပေါ်မူတည်ပြီး ဘယ် operation လုပ်ရမလဲဆိုတာ စစ်နေရတဲ့အတွက်နှေးပါတယ်။ နောက်တခုက static type language တွေမှာ type information ပါနေတဲ့အတွက် tool တွေ IDE တွေကနေ အလုပ်လုပ်ရတာ support ပေးရတာ အဆင်ပြေပါတယ်။ ဥပမာ type က string ဆိုရင် . ခေါက်လိုက်တာနဲ. String နဲ.ပတ်သတ်တဲ့ method, property တွေ IDE ကခေါ်တင်ပေးရတာလွယ်ပါတယ်။

Dynamically Typed Language တွေမှာကျတော့အဲ့လောက်အဆင်မပြေပါဘူး။ နောက်တခုက Refactoring ။ Refactoring ဆိုတာ program code တခုကို မူလ meaning မပြောင်းသွားပဲနဲ. Program ကို design အားဖြင့်ပိုကောင်းအောင် လုပ်တာကို ဆိုချင်တာပါ။ ဥပမာ ဖတ်ရခက်တဲ့ variable တခုကို နာမည်ပြောင်းမယ် method တခုကို နာမည်ပြောင်းမယ်ဆိုတာမျိုး ။ အဲ့ဒီအချိန်မှာ တခုခုက မှားသွားရင် static typed language တွေမှာ ချက်ခြင်းသိပါတယ်။ program က compile လုပ်လို.မှမရတော့တာကိုး။ Dynamic Language တွေမှာတော့ ဒါမျိုးကိုသိနိုင်ဖို.အတွက် unit test code တွေရေးရပါတယ် ၊ အလုပ်ပိုရှုပ်ပါတယ်။ unit test code တွေရဲ. Power ကတော့ compiler type checking ထက်သာကောင်းသာနိုင်ပါတယ်။

အရာရာတိုင်းမှာ အားသာချက်ကြီးပဲရှိမနေနိုင်ပါဘူး အားနည်းချက်လဲရှိပါတယ်။ Static typed language တွေမှာ declaration တွေမလိုအပ်ပဲ type information တွေထဲ့ရေးနေရတဲ့အတွက် ပိုပြီး verbose(ရှုပ်ထွေး) ပါတယ်။Dynamic typed language တွေကျတော့ပို ရှင်းပါတယ်။ statically typed program တခုကို ပြင်ပြီးပြီဆိုရင် recompile လုပ်ရပါတယ်။ တချို. Programmer တွေကတော့ မကြိုက်ပါဘူး။ Dynamic Language တွေမှာတော့ recompile လုပ်စရာမလိုပဲ တန်း run ရုံပါပဲ။ Verbose ဖြစ်တာကိုပြင်ဖို.အတွက် modern programming language (C #,Scala) တို.မှာ type inferencing ကိုသုံးပါတယ်။ Type inferencing ဆိုတာ variable တခုရဲ. Type ကို compiler ကနေ အလိုအလျောက် ဆုံးဖြတ်တာကိုပြောတာပါ။ ဥပမာ ဒီ Java Statement ဆိုရင်

ArrayList arr = new ArrayList();

Type information က LHS မှာရော RHS မှာပါ ပါနေတာပါ။
C # မှာဆိုရင်

List lst = new List();
ဒီလိုကြေငြာလဲရပါတယ် တကယ်လို. Type inferencing သုံးမယ်ဆိုရင်

var lst = new List();

ဆိုပြီး သုံးလို.ရပါတယ် ပိုတိုပါတယ် ပိုလဲရှင်းသွားပါတယ်။ Scala မှာလဲ အဲလို type inferencing တွေပေးထားပါတယ်။ Static typed language တွေမှာမရတဲ့ နောက် dyamic language တွေရဲ. Feature တခုက method တွေ field တွေကို runtime မှာ change လို.ရတာပါ။ Self modifying code လိုကောင်မျိုးတွေရေးလို.လွယ်ပါတယ်။ အဲ့ဒီတော့ meta programming ကိုလွယ်လွယ်ကူကူ support လုပ်ပေးနိုင်ပါတယ်။ နောက်တခုက Duck Typing, ပါ duck typing ဆိုတာ ရှင်းပြထားတာတော့ အကောင်တကောင်က ဘဲလိုသွားမယ် ဘဲလိုအော်မယ်ဆို ဘဲပဲတဲ့။ ဆိုချင်တာက dynamic language တွေမှာ object တခုရဲ. Method တခုကို လှမ်းခေါ်မယ်ဆိုရင် (polymorphic operation)ပေါ့ အဲ့ဒီ object သည် ဘာ type ဖြစ်ရမယ် ဘယ်ကနေ implement လုပ်ရမယ် ဆိုတဲ့ (sub typing) restriction တွေမရှိပါဘူး။ Object တခုရဲ. Method ကိုလှမ်းခေါ်လို. အဲ့ဒီ object မှာ ခေါ်တဲ့ method ရှိရင် အလုပ်လုပ်မှာပါ။ Static typed language တွေမှာတော့ method name ရှိရုံနဲ.မပြီးပဲ (Subtype) ဖြစ်မှရမှာပါ။ နောက် Static typed language ရဲ.အားသာချက်တခုက Static Analysis Tool တွေနဲ.ကောင်းကောင်းအလုပ်လုပ်နိုင်တာပါပဲ။ Static Analysis Tool တွေက program တခုရဲ. Type information တွေကိုသုံးပြီး ဒီ program မှာဘယ်လိုဖြစ်နိုင်တဲ့ bug တွေရှိနိုင်လဲဆိုပြီးထုတ်ပေးနိုင်ပါတယ်။ Dynamic Language တွေအတွက်ကျတော့ type information ကို မရနိုင်တဲ့အတွက်အဆင်မပြေပါဘူး။ ဒါကို ကာကွယ်ဖို.အတွက် JavaScript မှာဆို TypeScript လိုကောင်မျိုး Microsoft ကထုတ်ထားပါတယ်။ TypeScript မှာ JavaScript statement အားလုံးရေးလို.ရပြီး Typed information ကိုအပိုဆောင်းထဲ့ပေးလို.ရပါတယ်။ အဲ့တော့ static type checking ပါလုပ်လို.ရသွားပါတယ်။ Dart မှာလဲထိုနည်းလည်းကောင်းပါပဲ။

Strongly Typed, Weakly Type, Memory Safe Language

Strongly typed language ဆိုတာ invalid type operation တွေကို compile time မှာရော runtime မှာပါ ဖမ်းပေးနိုင်တဲ့ language မျိုးကိုဆိုတာပါ။ ဥပမာ C #,Java,Scala တို.ပါ။ Invalid type operation ဆိုတာ များသောအားဖြင့် dangerous ဖြစ်တဲ့ type coercion (automatic type conversion ) ကိုပေးထားတာပါ။ ဥပမာ JavaScript မှာဆိုရင်ဒါမျိုးလုပ်လို.ရပါတယ်

var a ="10";
var b = a * 3;

a က string ပါ ဒါပေမဲ့ b ထဲကို a*3 လို.ထဲ့တဲ့အချိန်မှာ a ကို string ကနေ integer ပြောင်းပြီး multiplication လုပ်ပေးသွားတာပါ။ အပေါ်ယံကြည့်လို.ကောင်းတယ် အသုံးဝင်တယ်ထင်ရပေမဲ့ runtime မှာ a ထဲ ကstring သည် number တခုခုကို မပြောင်းနိုင်ရင် undefined ဖြစ်ပါလိမ့်မယ် undefined ကို a နဲ.မြှောက်ရင် b ရဲ.တန်ဖိုးက NaN (Not a Number) ရပါလိမ့်မယ်။ ဒါကြောင့် JavaScript က weakly typed language လို.ပြောရမှာပါ။

Memory Safe Language ဆိုတာ memory ပေါ်မှာရှိတဲ့ integer နေရာကို floating point တွေလာမထဲ့နိုင်အောင်(ဥပမာအနေဲ.ဆိုလိုတာပါ အဓိက ကတော့ invalid type operation on memoryပါ) ထိန်းပေးနိုင်တဲ့ language ကိုဆိုချင်တာပါ။ C,C++ မှာ pointer arithmetic ကိုသုံးပြီးတော့ memory ရှိတဲ့ int ကို float အနေနဲ.အသုံးပြုလို.ရပါတယ် Go မှာဒါမျိုးကို ကာကွယ်ပေးထားပါတယ်။ ဒါကြောင့် C,C++ ကို memory unsafe language လို.ပြောရမှာဖြစ်ပြီး Go ကို memory Safe Language လို.ပြောရမှာပါ။

19/04/2026

အရင် Python Free Course Group မှာတင်ထားတဲ့ video တွေ youtube ပေါ်ပြန်တင်ပေးထားတာ။ Python ကိုအခြေခံကနေ စသင်ပေးထားတာပါ။

https://www.youtube.com/playlist?list=PLVhJW4jnAwFQ-E62y9MPJY8t33E8RThPy

Send a message to learn more

14/04/2026

Programmer တွေဖို. နှစ်သစ်လက်ဆောင်ပေါ့။ အသုံးတည့်မဲ့ဟာတွေစုပေးလိုက်ပါတယ်။

Programmer brains
https://www.facebook.com/thet.khine.587/posts/10221864605043828

Programming နဲ. programming languages တွေဘယ်လိုလေ့လာရမလဲ

https://web.facebook.com/thet.khine.587/posts/10205561643639982

Programming Logic ကိုဘယ်လိုလေ့လာမလဲ
https://www.facebook.com/thet.khine.587/posts/10215603759566604

Technical Content တွေဘယ်လိုဖတ်ရလဲ
https://web.facebook.com/thet.khine.587/posts/10205779244319863

Self taught programmer ဖြစ်အောင်ဘယ်လိုလုပ်မလဲ
https://web.facebook.com/thet.khine.587/posts/10206651854134563

Learn how to learn
https://www.facebook.com/thet.khine.587/posts/10213150741202678

Work ethic for programmer
https://www.facebook.com/thet.khine.587/posts/10215603285314748

Soft Skill for Developer
https://www.facebook.com/thet.khine.587/posts/10211207600105365

Mobile Development roadmap
https://www.facebook.com/thet.khine.587/posts/10215591691984922

Frontend Developer Roadmap
https://www.facebook.com/thet.khine.587/posts/10215580098615095

2025 မှာဘာတွေ လေ့လာထားသင့်သလဲ
https://www.facebook.com/thet.khine.587/posts/10222649814833582

How to learn software design & Architecture
https://www.facebook.com/thet.khine.587/posts/10215481195142570

Developer ကောင်းဖြစ်ဖို. ဖတ်သင့်တဲ့စာအုပ်တွေ စာရင်း
https://www.facebook.com/thet.khine.587/posts/10205941924026754

How to learn to write better code.
https://web.facebook.com/thet.khine.587/posts/10213715615964194

Computer Science theory တွေဘယ်လိုသင်ရမလဲ
https://web.facebook.com/thet.khine.587/posts/10211299678487267

Object Oriented Programming and Design Pattern Series
https://web.facebook.com/thet.khine.587/posts/10208694997691875

Machine Learning Series
https://web.facebook.com/thet.khine.587/posts/10208114765306428

How JVM work 1-9 Series
https://web.facebook.com/thet.khine.587/posts/10205507889856171

JS React Web Related Series.
https://web.facebook.com/thet.khine.587/posts/10213369925322144

How thing work series
https://web.facebook.com/thet.khine.587/posts/10208712991581711

Type system in programming language series.
https://web.facebook.com/thet.khine.587/posts/10213468905236580

Practical Theory of Programming Languages Live Series PDF Part 1 to 8.
https://u.pcloud.link/publink/show...

Functional Programming Series https://www.facebook.com/thet.khine.587/posts/10215352497565211

Motivation theories in learning
https://www.facebook.com/thet.khine.587/posts/10210022287713296

ပြန်တင်ပေးတာပါ new year ကဟာကို

12/04/2026

မြန်မာ နှစ်သစ်ကူး ပိတ်ရက် ၁၃ ကနေ ၁၆ ရက်နေ့ထိ အတန်းတွေ ပိတ်မှာဖြစ်ပါတယ်

ငြိမ်းချမ်းသော နှစ်သစ်ဖြစ်ပါစေ။

03/04/2026

နက်ဖန် စမဲ့ JS React နဲ့ JavaEE Spring တန်းအတွက် group link တွေချပေးပြီးဖြစ်ပါတယ်။

ကျန်ခဲ့တဲ့သူများလာပြောပေးကြပါ။

03/04/2026

မနက်ဖန် စမဲ့ JS React နဲ့ JavaEE Spring တန်းအတွက် group link များကို ယခုည ပို့ပေးမှာဖြစ်ပါတယ် FYI

02/04/2026

35 common bad programming habits
Quora က post တခု ကြိုက်လို. ဆီလျော်သလို ပြန်ရေးပြီးပြန်တင်ပေးလိုက်တာ

1 Acting like you have all the answers
လူတိုင်း အကုန်မသိနိုင်ပါဘူး။ အားလုံးသိရမယ်ဆိုပြီး insecure ဖြစ်နေတာ မကောင်းပါဘူး။

2. Attending meetings all day
တနေကုန် meeting တွေနဲ.ညားနေရင်လဲအဆင်မပြေပါဘူး

3. Acting defensively when someone critiques your code.
သူများက ကိုယ့် code ကိုဝေဖန်ရင်မကြိုက်တာ။ အထူးသဖြင့်ကို.ထက်နားလည်တဲ့သူက ဝေဖန်ရင် ဒါသည် ဘယ်နေရာပြင်လိုက်ရင် ကောင်းမယ်ဆိုတဲ့ အကြံကိုပြန်တောင်းသင့်တယ် မဟုတ်ရင် ဘယ်တော့မှ skill တက်လာမှာမဟုတ်ဘူး။ အဝေဖန်မခံနိုင်တဲ့သူတွေကြုံဖူးတယ် နှစ်တွေသာကုန်သွားတယ် ဒီ skill ကနေကိုမတက်ဘူး။

4. Giving up too soon.
ဘာမှ မည်မည်ရရ မလုပ်ရသေးခင် မကြိုးစားရသေးခင်မှာ အရှုံးပေးလိုက်တာ လက်လျော့လိုက်တာ။

5. Refusing to ask for help.
ကိုက အရာအားလုံးမှာ မကျွမ်းကျင်နိုင်ဘူး။ အဲ့တော့ ကိုယ်မသိတဲ့နယ်ပယ်ဆို အကူညီတောင်းသင့်တောင်းရမယ် အဲ့လိုမဟုတ်ရင် အဆင်မပြေဘူး။ တခါတလေ သိတဲ့သူပြောလိုက်တာက ခနလေးနဲ. အကူညီရနိုင်တယ်။

6.Passing blame to others.
ဒါကတော့တွေ.ရတယ်။ ကိုယ်ရေးတဲ့ code တာ၀န်မယူတာ တခုခုဆိုလွှဲချတာ ။

7. Writing code that prematurely optimizes other code.
Optimization ကို အစောကတည်းက လုပ်တာ။ Optimization ကိုစောစောလုပ်လိုက်တော့ code တွေက နားလည်ရခက်သွားတယ်။

8. Ignoring the opinions of other developers.
သူများ တွေရဲ.အမြင်ကို ဂရုမစိုက်တာ ဥပမာ ကိုက backend ရေးမယ်ဆိုရင် front end ကတော့ ဘယ်လိုသုံးရမယ်ဆိုတာကို ထဲ့တွေးရမယ်။ ဒီလိုပဲ front end ရေးရင်လဲ backend သမား ဘာတွေလိုမယ် ဘယ်လိုအဆင်ပြေအောင် လုပ်ရမလဲတွေးရမယ်။

9. Not knowing how to optimize code.
Optimization ကိုနားမလည်တာ။ Algorithm တွေ Big O notation တွေ complexity တွေကို နားမလည်ဘူး။ Optimize ဘယ်လိုလုပ်ရမလဲဆိုတာမသိဘူး။

10. Undervaluing relationships with other members of the team
တခြားလူတွေနဲ. ဆက်ဆံရေးကို တန်ဖိုးမထားတာ။ Code ချည်းပဲရေးနေရပေမဲ့ team communication ကလဲအရေးပါသေးတယ်။

11. Engaging in office politics
တခြားလူတွေက ကိုယ်နဲ.အမြင်မတူတာရှိချင်ရှိမယ် ဒါပေမဲ့ ပြင်းပြန်းထန်ထန်တုန်.ပြန်တာမျိုးမဟုတ်ပဲ လိုက်လျောညီထွေရှိအောင် နေသင့်တယ်။

12. Freezing under pressure
Pressure အောက်မှာ အလုပ်မလုပ်နိုင်တာ။

13. Being incapable of writing bad code.
တခါတလေ real world မှာ deadline တွေ requirement တွေနဲ.လုံးချာလည်လိုက်နေတတ်ပါတယ်။ အဲ့အချိန်မှာ ကိုက အလုပ်က ပြီးရမယ် system ကျဖို.ကလဲမလွယ်ပါဘူး။ အဲ့တော့ တခါတလေ လိုအပ်ရင်လဲ bad code ရေးဖို.ပြင်ဆင်ထားရပါလိမ့်မယ်။

14. Over-engineering simple problems
Problem သေးသေးလေးတွေကို ရိုးရိုးရှင်းရှင်းနဲ. ရှင်းလို.ရတဲ့ နည်းလမ်းကို မသုံးပဲနဲ. ရှုပ်ထွေးတဲ့ နည်းလမ်းတွေသုံးတာ။

15. Acting like a boss. Not a leader.
ကိုကပဲ အမိန်.ပေးပြီးခိုင်းနေတာ. team ထဲက သူများတွေ ပါ အားဖြစ်အောင် ကိုယ်တိုင် ဦးဆောင်ပြီး ၀င်မလုပ်တာ။

16. Using the wrong tool for the job.
မသင့်တော်တဲ့ tool တွေသုံးတာ ။

17. Refusing to research coding questions
Coding အသစ်တွေ technique အသစ်တွေကို မလေ့လာတာ။

18. Not maintaining a good grasp on your tools.
ကိုယ်သုံးနေတဲ့ tool တွေနဲ. အကျွမ်းတ၀င်မရှိတာ။ ဥပမာ IDE ကိုကောင်းကောင်းမသုံးတတ်တာ။ build tool တွေ မနိုင်နင်းတာ။

19. Avoiding error messages
Program က error message တွေပြပြီဆိုရင် အကြောင်းရင်းကို သိအောင်မ လုပ်ပဲနဲ. error message ကိုပဲမပြအောင်လုပ်လိုက်တာ။

20. Counting the hours.
တနေ.တနေ. ငါဘယ်လောက် အလုပ်လုပ်ပြီးပြီလဲဆိုတာ နာရီနဲ.တွက်နေတာ။ တကယ်က အချိန်ဘယ်လောက်ကြာကြာလုပ်တယ်ဆိုတာထက် ဘာပြီးလဲကပိုအရေးကြီးတယ်။

21. Refusing to learn from mistakes.
အမှားထဲက သင်ခန်းစာမယူတာ။ အရင် Project တခုမှာ db structure ကဒီလိုမှားချလို. နောက် Project မှာလဲ အရင်လိုပဲတိုင်ပတ်မယ်။ ဒါကိုသင်ခန်းစာမယူရင် အရင် Project လိုပဲ fail ဖြစ်မယ်။

22. Being afraid of throwing away code.
Design မကောင်းတဲ့ code တွေ bad code တွေကို ဖျက်ပစ်ဖို. နှမြောနေတာ

23. Romanticizing your developer toolkit
ဒါကတော့ ကိုယ်သုံးနေတဲ့ tool တွေ language တွေ platform တွေအပေါ်မှာ စွဲလန်းနေတာ တခြားသင့်တော်တာရှိပေမဲ့ပြောင်းမသုံးနိုင်တာမျိုး။

24. Separating yourself from the developer community.
Developer community ကနေ ခပ်ရှောင်ရှောင်နေတာ။ (ဓတ်ပုံသွားမရိုက်တာကိုပြောတာမဟုတ်ဘူး development နဲ.ပတ်သတ်ပြီး အသစ်ထွက်တာတွေကို မလေ့လာတာ)

25. Not having a Twitter account.
Twitter Account မရှိတာ။ သူ.ဆီမှာဆို Project အကြီးကြီးတွေက update တင်ရင် အကုန်ချက်ချင်း twitter မှာသိရနိုင်တယ်။

26. Not giving back to the community.
Community ကိုဘာမှပြန်မပေးတာ ဥပမာ library ရေးတာမျိုး သင်ခန်းစာတွေ တင်တာမျိုး မလုပ်တာ။

27. Struggling for hours to solve something, solving it, and not documenting it.
အချိန်အကြာကြီး code ရေးပြီး documenation တော့မလုပ်တာ။

28. Writing too many or not enough comments in code.
Comment နည်းလွန်း များလွန်းတာ

29. Lazily refusing to update issues for product managers.
ကိုမှာရှိတဲ့ issue တွေကို PM တွေကို update မလုပ်တာ။

30. Frequently bundling unrelated features into the same initiative.
မဆိုင်တဲ့ feature တွေကို တနေရာထဲမှာ စုထဲ့ထားတာ။

31. Carefully coming up with a smart plan with other members of the team, only to completely abandon it and change course entirely when one unexpected thing happens.
အကြံကောင်းဆိုပြီး လုပ်လိုက်ပြီးမှ တခုခု မမျှော်လင့်တာဖြစ်လာတာနဲ. အကုန်လုံး အစကနေ အဆုံးပြောင်းပြစ်တာ

32. Sticking to a thought-out plan that clearly isn’t working.
အလုပ်မဖြစ်တာ သေချာတဲ့ plan ကိုဆက်လုပ်နေတာ။

33. Consistently apologizing for the bad code you’re writing
Bad code တွေအတွက် အမြဲတမ်းတောင်းပန်နေရတာ.

34. Not spending the energy you should performing code review
Code Review သေသေချာချာ မလုပ်တာ.

35. Not spending enough time mentoring other devs on your team.
Team ထဲကတခြားလူတွေကို သေသေချာချာ mentoring မလုပ်တာ မသင်ပေးတာ။

source

https://www.quora.com/What-are-some-bad-programming-practices-every-programmer-needs-to-be-aware-of-in-order-to-avoid-them

27/03/2026

OOP Design Pattern Series PDF ထုတ်ပေးထားတာ
Code ကလဲ repo မှာပါပြီးသား

PDF download link

https://github.com/mrthetkhine/designpattern/blob/master/Object-Oriented-Programming-and-Design-Pattern-Series.pdf

Address

Yangon

Alerts

Be the first to know and let us send you an email when Turing Programming Training Center posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Share