Turing Programming Training Center

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.

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
ပိုအဆင်ပြေတယ်။

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

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

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

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