<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Sar Yay Club</title><link>https://www.saryay.club/posts/</link><description>Recent content in Posts on Sar Yay Club</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sat, 21 Jan 2023 11:09:37 +0800</lastBuildDate><atom:link href="https://www.saryay.club/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Saryay Club Mastadon</title><link>https://www.saryay.club/posts/saryay-club-mastadon/</link><pubDate>Sat, 21 Jan 2023 11:09:37 +0800</pubDate><guid>https://www.saryay.club/posts/saryay-club-mastadon/</guid><description>Welcome to the Mastodon Train!
Twitter အစားထိုး Mastodon ကို Saryay Club အတွက် https://club.saryay.club/ မှာ စမ်းပြီး လုပ်ထားပါတယ်။
Sign Up လုပ်လိုက်တာနဲ့ username@club.saryay.club ဆိုပြီး သူများတွေ follow လုပ်လို့ရမှာ ဖြစ်တယ်။ ဥပမာ @mm@club.saryay.club.
Deployment ကတော့ https://github.com/tmm1/flyapp-mastodon ကို ယူပြီး Fly.io မှာ deploy လုပ်ထားတယ်။
စမ်းပြီး သုံးကြည့်ကြပါဦး
PS. Mobile app တွေလည်း ရှိပါတယ်။ ဒီမှာ ကြည့်ပါ။</description></item><item><title>7 Network Layers</title><link>https://www.saryay.club/posts/network-layer/</link><pubDate>Sun, 24 Jan 2021 15:12:00 +0800</pubDate><guid>https://www.saryay.club/posts/network-layer/</guid><description>Networking ဟာ software engineer တိုင်သိထားသင့်တဲ့ အခြေခံအကြောင်အရာ တခုပဲဖြစ်ပါတယ်။ Mobile engineer ပဲဖြစ်ဖြစ် API/Backend engineer ပဲဖြစ်ဖြစ် frontend engineer ပဲဖြစ်ဖြစ် data ကို network ပေါ်ကနေ transfer လုပ်ရသည်ဖြစ်သည့်အတွက် networking layer တွေအကြောင်း Protocal တွေအကြောင်း သိဖို့ကောင်းပါတယ်။
Network Layers ပထမဦးဆုံး အခြေခံအကျဆုံးဖြစ်တဲ့ Network Layers ၇ ခုအကြောင်းကနေ စပြောမှာ ဖြစ်ပါတယ်။
ဒါကတော့ Layer ၇ ခု ဖြစ်ပါတယ်။
Layer 5 ကနေ Layer 7 မှာဆိုရင် ကြားဖူးနေကျဖြစ်မယ့် HTTP, FTP, SSH, SSL, DNS စတဲ့ protocol တွေပါပါတယ်။
Layer 4 မှာတော့ TCP တို့ UDP တို့ပါပါတယ်။
Layer 3 မှာ IP packet တွေနဲ့ IP Routing ပါပါတယ်။
Layer 2 မှာတော့ Ethernet packet တွေနဲ့ Ethernet switching ပါပါတယ်။
Layer 1 မှာဆိုရင်တော့ physical network device တွေပါပါတယ်။
data တခုကို ေနာက်တနေရာကို ပို့တယ်ဆိုရင် Layer 7 ကနေ Layer 1 ကို သွားပါတယ်။ လက်ခံမယ်ဆိုရင်တော့ Layer 1 ကနေ Layer 7 ကို ပြန်သွားပါတယ်။ Layer တခုချင်းစီကလည်း သူတို့နဲ့ဆိုင်တဲ့ အချက်အလက်တွေကို ပို့လိုက်မယ့် packet ထဲကို header အနေနဲ့ထည့်ပေးလိုက်တာ ရှိပါတယ်။</description></item><item><title>Introduction to Bloom Filters</title><link>https://www.saryay.club/posts/introduction-to-bloom-filters/</link><pubDate>Sun, 29 Nov 2020 12:16:44 +0800</pubDate><guid>https://www.saryay.club/posts/introduction-to-bloom-filters/</guid><description>ဒီတခေါက်မှာတော့ သိပ်မကြာသေးခင်ကမှ ဖတ်ထားတဲ့ Bloom filters ဆိုတဲ့ data structure ဘယ်လို အလုပ်လုပ်လဲ ဘယ်လိုနေရာတွေမှာ သုံးလေ့ရှိလဲဆိုတာ ပြောပြပါမယ်။
False Positive and False Negative ဒီ data structure အကြောင်းမပြောခင်မှာ ပြောချင်တဲ့ တခုကတော့ &amp;ldquo;False Positive&amp;rdquo; နဲ့ &amp;ldquo;False Negative&amp;rdquo; အကြောင်းပါ။
ဥပမာ ကိုယ်က ရောဂါတခုခု (ဥပမာ Covid) ရှိမရှိ ဆေးစစ်ကြည့်တယ်ပဲ ဆိုပါတော့
False Positive ဆိုတာ ဆေးစစ်လို့ ရလာတဲ့ result က ရောဂါတွေ့တယ်လို့ ပြောပေမယ့် ကိုယ့်မှာ တကယ်မရှိတာကို ပြောတာပါ။ False Negative ကတော့ result က မရှိဘူး ပြောပေမယ့် ကိုယ့်မှာ ရှိနေတဲ့ အခြေအနေကို ပြောပါတယ်။ ဒီနှစ်ခု အကြောင်း တခြား example တွေနဲ့ ဒီ post မှာ ရှင်းပြထားပါတယ်။
Hashing နောက်တခု ထပ်ပြောချင်တာတော့ hash function ပါ။ hashing လုပ်တယ်ဆိုတာ အကြမ်းဖျည်းအားဖြင့် item တခုခုထည့်လိုက်ရင် Maths formula တခုခုနဲ့ ဒီ item ရဲ့ identifier ကို ပြန်ပေးတဲ့ formula ပါ။ ဥပမာ &amp;quot;Maung Wa&amp;quot; ကို MD5 လို့ ခေါ်တဲ့ hash function နဲ့ hash လုပ်တယ်ဆိုရင် ca4bf781bee1949e054502c40b1f3deb လို့ အမြဲတမ်း ပြန်ပေးပါတယ်။</description></item><item><title>Creating SAML IDP provider with Ruby on Rails.</title><link>https://www.saryay.club/posts/2020-07-02-saml_idp_rails/</link><pubDate>Thu, 02 Jul 2020 07:48:30 +0630</pubDate><guid>https://www.saryay.club/posts/2020-07-02-saml_idp_rails/</guid><description>Creating SAML IDP provider with Ruby on Rails.
Rails SAML IDP Provider with devise Recently I was working on single sign on solution for my company. After researching, we decided to use SAML for authentication. I believe everyone reading this post is already familiar with Rails and SAML. Security Assertion Markup Language, SAML is an open standard for exchanging authentication and authorization data between parties in XML format. It contains identity provider IDP which acts as a centralized authentication services and service providers SP use response XML from IDP to authenticate users. In simpler way, users logged in to IDP will automatically logged in to SP.</description></item><item><title>Software Development နဲ့ပတ်သက်လို့ ကျောင်းမှာမသင်ခဲ့ရတာလေးတစ်ချို့</title><link>https://www.saryay.club/posts/some-things-about-software-development-that-i-did-not-learn-at-school/</link><pubDate>Sun, 14 Jun 2020 10:20:50 +0900</pubDate><guid>https://www.saryay.club/posts/some-things-about-software-development-that-i-did-not-learn-at-school/</guid><description>ကွန်ပျူတာသိပ္ပံကျောင်းသားတစ်ယောက်အနေနဲ့ Software Engineering ဆိုတာကို ဘာသာရပ်တစ်ခုအနေနဲ့ သင်ရပါတယ်။ စဥ်းစားကြည့်ပါ။ ဘဝမှာ ခင်ဗျားရေးဖူးတဲ့ အခက်ခဲဆုံး ပရိုဂရမ်က doubly linked list implementation လောက်ပဲရှိသေးမယ်။ ဒါပေမဲ့ ခင်ဗျားကို ဆော့ဖ်ဝဲကို ဘယ်လိုအဖွဲ့အစည်းတွေနဲ့ရေးကြတယ်။ Process တွေက ဘယ်လို၊ အဆင့်အဆင့်တွေ ဘယ်လိုရှိတယ်။ လူတွေအများကြီးကို ဘယ်လို manage လုပ်ရတယ်။ Stakeholder တွေနဲ့ ဘယ်လိို ဆွေးနွေးရတယ်ဆိုတာတွေ ပြောလည်း မျက်စိထဲမြင်မှာမဟုတ်ဘူး။ ပရိုဂရမ်တွေနဲ့ ကုတ်တွေနဲ့ ဘယ်လိုဆက်စပ်နေပါတယ်ဆိုတာတောင် ကောင်းကောင်းမြင်သေးတာမဟုတ်ဘူးကိုး။
ကျွန်တော်ဒီနေ့ရေးချင်တဲ့ အကြောင်းအရာကတော့ ကျောင်းတုံးက ဒါမှမဟုတ် ကျောင်းပြီးကာစတုံးက ဒါတွေသိခဲ့ရင်ကောင်းမှာလို့ ပြန်တွေးမိတဲ့ software engineering နဲ့ပတ်သက်တဲ့ အသိလေးတစ်ချို့ပါပဲ။
Waterfall is old-school. Agile is now state-of-the-art. ပထမဆုံးပြောချင်တဲ့ ကိစ္စကတော့ Software Development Life Cycle (SDLC) တွေပါ။ ကျောင်းမှာတုန်းကဆို Waterfall process model ရော Agile Development Methodologies တွေအကြောင်းရော သင်ခဲ့ရပါတယ်။ နှစ်ခုလုံးမှာ သူ့အားသာချက်အားနည်းချက်ရှိတယ်ဆိုပြီး သင်ခဲ့ရတော့ ဘယ်ဟာက လက်တွေ့ပိုကျတယ် ဘယ်ဟာကိုပို အလေးထားပြီးလေ့လာသင့်သလဲဆိုတာ ခွဲခြားမသိခဲ့ပါဘူး။
နောက်ပိုင်း အလုပ်ခွင်ထဲရောက်လာတဲ့အခါ Agile methodoglies တွေက အရမ်းကိုတွင်ကျယ်နေပြီး Waterfall ကို သိပ်မသုံးကြတော့တာကြုံရပါတယ်။ ဘာလို့ Agile ကိုပိုသုံးကြလဲဆိုတော့ Waterfall Process နဲ့ရေးတဲ့ ဆော့ဖ်ဝဲတွေက အချိန်သိပ်ကြာပါတယ်။ နောက်ပိုင်းဆော့ဖ်ဝဲက နေရာတကာမှာ သုံးလာကြတယ်။ အရင်က ဆော့ဖ်ဝဲတစ်ခုကို ရေးချင်ရင် တစ်နှစ်နှစ်နှစ်ကနေ လေးငါးခြောက်နှစ်လောက်ထိိကြာပါတယ်။ ပြီးရင် အဲ့ဒီ ဆော့ဖ်ဝဲကို package လုပ်ပြီး ရောင်းကြ ဖြန့်ချီကျ သုံးကြရတယ်။ အဲ့တော့ ဆော့ဖ်ဝဲကို update လုပ်ချင်ရင်လည်း အချိန်သိပ်ကြာတဲ့ အတွက် စကတည်းက specification တွေကို ဖြစ်နိုင်သမျှကြိုစဥ်းစားကြတယ်။ အဲ့တော့ အချိန်တွေပိုကြာတယ်။ အဲ့လိုနဲ့ သံသရာလည်ပါတယ်။</description></item><item><title>htop Explain - process</title><link>https://www.saryay.club/posts/htop-explain-2-processes/</link><pubDate>Sat, 13 Jun 2020 20:42:42 +0800</pubDate><guid>https://www.saryay.club/posts/htop-explain-2-processes/</guid><description>Process monitoring လုပ်တဲ့ tool တခုဖြစ်တဲ့ htop ဘယ်လိုအလုပ်လဲ ဘယ်ကနေ data တွေ ယူလဲဆိုတဲ့ series ရဲ့ ဒုတိယမြောက် post ဖြစ်ပါတယ်။ ပထမအပိုင်း htop Explain - uptime ကို ဒီမှာ ဖတ်နိုင်ပါတယ်။
terminal မှာ htop ကို ဖွင့်ကြည့်လိုက်နဲ့ အခုလက်ရှိ run နေတဲ့ process တွေကိုလည်း မြင်ရမှာပါ။
အပေါ်က ပုံထဲမှာ အခုလောလောဆယ် process ၇၄ ခု ရှိနေပါတယ်။ process တွေကို task လို့လည်း ခေါ်ပါတယ်။ htop ကတော့ process အစား task လို့ သုံးပါတယ်။
ကိုယ်က htop လို့ ရိုက်ကြည့်လိုက်လို့ process တွေအကုန်မမြင်ရဘူးဆိုရင် Shift + k ကို နှိပ်ကြည့်ပြီးတော့ kernel ကနေ run နေတဲ့ process တွေကိုပါ မြင်ရမှာ ဖြစ်ပါတယ်။ Process ID (PID) column ကို နှိပ်ကြည့်ပြီးပဲဖြစ်ဖြစ် F7 (Sort) ကိုနှိပ်ပြီးတော့ PID လို့ ရွေးလိုက်တာပဲဖြစ်ဖြစ် process ၁ ကနေ အစဥ်လိုက်တိုင်း အကုန်မြင်ရပါလိမ့်မယ်။
Process ID / PID Operating system က process တခုစတိုင်း process id တခု သတ်မှတ်တယ်။ ၁ ကနေပြီးတော့ ကိုယ့်ရဲ့ စက်ရဲ့ process limit ထားတဲ့အထိ id တွေ ပေးပါတယ်။ limit ရောက်သွားရင်လည်း မသုံးတော့တဲ့ process id တွေကို ပြန်သုံးပါတယ်။ အဲလိုမှမဟုတ်ပဲ process id တွေအကုန်လုံးလည်း သုံးထားတယ် နောက် process အသစ်လည်း စချင်တယ်ဆိုရင်တော့ error တက်ပါလိမ့်မယ်။ Linux မှာဆို process id တွေ အကုန်ကုန်သွားပြီး ကိုယ့်စက်က resource တွေကို အကုန်ကုန်အောင်လုပ်ပစ်တဲ့ fork bomb လို့ခေါ်တဲ့ virus လိုဟာမျိုးရှိပါတယ်။</description></item><item><title>Strategy and Template Design Patterns</title><link>https://www.saryay.club/posts/strategy-and-template-method-patterns/</link><pubDate>Sat, 06 Jun 2020 17:29:16 +0900</pubDate><guid>https://www.saryay.club/posts/strategy-and-template-method-patterns/</guid><description>ဒီနေ့ Gang of Four design pattern တွေထဲက လက်တွေ့မှာ ခဏခဏကြုံရပြီး ခပ်ဆင်ဆင် ဖြစ်နေတဲ့ ဒီဇိုင်းပုံစံနှစ်ခုအကြောင်း နည်းနည်းရေးချင်တယ်။ Strategy pattern နဲ့ Template pattern အကြောင်းပါ။ နှစ်ခုလုံးက code duplication နဲ့ conditional branch တွေအများကြီးခွဲတဲ့ပြသနာကို ဖြေရှင်းတဲ့ နည်းတွေပါ။
အရင်ဆုံး တစ်ခုချင်းဘာဆိုတာကြည့်လိုက်ရအောင်
Strategy pattern ဒီ pattern ကိုဘယ်ချိန်တွေမှာ သုံးလဲဆိုတော့ ကိုယ်လုပ်ချင်တဲ့ operation တစ်ခုမှာ input data အမျိုးအစားပေါ်မူတည်ပြီးပဲ ဖြစ်ဖြစ်၊ situation တစ်ခုခုအပေါ်မူတည်ပြီးတော့ပဲ ဖြစ်ဖြစ် လုပ်ပုံလုပ်နည်းကွာသွားတာနေရာတစ်နေရာရှိနေရင် သုံးတယ်။ ဥပမာအနေနဲ့ subscription ecommerce application တစ်ခုမှာ order ကို refund လုပ်ရမယ်ဆိုပါတော့။ refund လုပ်တဲ့ အဆင့်တွေက အများစုက တူတူပဲ။
Refund amount ကိုတွက်ချက်ရမယ် order ကို cancel လုပ်မယ် customer အပေါ်မူတည်ပြီး refund အမျိုးအစားကို တွက်ချက်ရမယ်။ အပြည့်ပြန်ပေးမှာလား တစ်ဝက်ပဲပြန်ပေးမှာလားပေါ့။ နောက်ပြီးတော့ payment gateway ကနေ ပိုက်ဆံပြန်ပေးရမယ်။ ပြီးရင် ပိုက်ဆံပြန်ပေးပြီးပါပြီ ဆိုပြီး အီးမေးလ်ပို့မယ်။ အဲ့ဒီမှာ customer ကို ပိုက်ဆံပြန်ပေးတဲ့အချိန်မှာ policy တွေက အမျိုးအစား လေးမျိုး လောက်ရှိတယ်ဆိုပါစို့။ လေးမျိုးလုံးကလည်း လုပ်နည်းလုပ်ဟန်မတူဘူးဆိုရင် အဲ့ဒီကုတ်က ဘယ်ပေါ်လစီနဲ့ကိုက်လဲ အပေါ်မူတည်ပြီး conditional လေးခုစစ်ရတော့မယ်။</description></item><item><title>Introduction to algorithms</title><link>https://www.saryay.club/posts/introduction-to-algorithms/</link><pubDate>Thu, 04 Jun 2020 20:57:47 +0630</pubDate><guid>https://www.saryay.club/posts/introduction-to-algorithms/</guid><description>Algorithms ဆိုတာ problem တစ်ခုကို ဖြေရှင်းဖို့ သက်မှတ်နည်းလမ်း တစ်ခု့ဖြစ်တယ်။ Algorithms တွေကို project အသေးလေးတွေက အစ အကြီးတွေမှာပါ တွေ့ရလိမ့်မယ်။ Sorting, Searching, Routing တွေမှာ algorithms တွေအများဆုံးသုံးကြတယ်။ အလုပ် interview တွေ မှာလဲ algorithm နဲ့ပတ်သက်တဲ့ problems တွေ မေးလေ့မေးထရှိတဲ့ အတွက် career အတွက်အလွန်အရေးပါတဲ့အရာဖြစ်တယ်။
What is algorithms Algorithm တွေကဘယ်လောက်အရေးပါလဲ။ Algorithm ကောင်းတွေက ဘယ်လောက်အရေးပါလဲဆို algorithm ဘယ်လောက်ကောင်းလဲပေါ်မူတည်ပြီး algorithm တွေရဲ့ running time အရမ်းကွာသွားနိုင်တယ်။ ကိုယ်က ဘယ်လောက် performance မြင့်တဲ့ language ကြီးနဲ့ပဲ ရေးရေး algorithm မကောင်းရင် ကြာမှာပဲ။
Algorithms တွေကိုဘယ်လိုတိုင်းတာမလဲ ကျွန်တော်တို့ algorithm တွေကိုတိုင်းတာရာမှာ algorithm ရဲ့ time complexity and space complexity ဆိုပြီး တိုင်းတာလို့ရတယ်။
Time complexity ဆိုတာ algorithm ရဲ့ running time ကို တိုင်းတာတာဖြစ်ပီး Space complexity ဆိုတာ algorithm ရဲ့ run နေတဲ့အချိန် memory ပေါ်မှာ data ဘယ် လောက် နေရာယူနေလဲ + Lines of code (LOC) ကိုတိုင်းတာတာဖြစ်တယ်။ များသောအားဖြင့်တော့ algorithms တွေကို time complexity တိုင်းကြတယ်။ ဘာလို့လဲဆိုတော့ space complexity က resource က limit ရှိတဲ့အခြေအနေမျိုးတွေမှာ ဥပမာ small IOT တွေတို့ မော်ဒယ်နိမ့်တဲ့ mobile device တွေတို့လို device တွေရဲ့ resource ကို တိုးလို့မလွယ်တဲ့အချိန်မှာ ပိုအရေးပါတယ်။</description></item><item><title>htop Explain - uptime</title><link>https://www.saryay.club/posts/htop-explain-1-uptime/</link><pubDate>Mon, 25 May 2020 20:57:47 +0800</pubDate><guid>https://www.saryay.club/posts/htop-explain-1-uptime/</guid><description>htop က Linux နဲ့ Apple OSX မှာ အသုံးများတဲ့ process monitoring tool တခု ဖြစ်ပါတယ်။ terminal based ဖြစ်ပြီးတော့ lightweight လည်းဖြစ်တယ်။ ကိုယ့်ရဲ့ စက်မှာ CPU ဘယ်လောက်သုံးနေလဲ Memory(RAM) ဘယ်လောက်သုံးနေလဲဆိုတာကို process လိုက် အသေးစိတ် အချိန်နဲ့ တပြိုင်တည်း ကြည့်လို့ရပါတယ်။
ဒီ post series မှာ htop ရဲ့ အစိတ်အပိုင်းတခုချင်းစီလိုက် data က ဘယ်ကနေလာလဲ Operating System (OS) ရဲ့ အစိတ်အပိုင်းတွေ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာ ကြည့်သွားမှာပါ။ ဒီ series ရဲ့ original article ကို https://peteris.rocks/blog/htop မှာ သွားဖတ်လို့လည်း ရပါတယ်။
Uptime ပထမဆုံးကတော့ ကိုယ့် system က ဘယ်အချိန်ထဲက run နေတာလဲဆိုတာကို uptime လို့ ရိုက်ပြီး ကြည့်လို့ရပါတယ်။
အဲဒီ information ကိုပဲ ကိုယ့်ရဲ့ command line terminal ထဲမှာ အခုလို ကြည့်လည်း ရပါတယ်။
ubuntu@saryay.club:~$ uptime 12:54:42 up 91 days, 10:27, 1 user, load average: 0.25, 0.11, 0.04 ubuntu@saryay.club:~$ which uptime /usr/bin/uptime ဒီ information က /proc/uptime ကနေ လာပါတယ်</description></item><item><title>HTTP calls in your code and how to test them?</title><link>https://www.saryay.club/posts/2020-05-21_http_calls_in_your_code_and_how_to_test_them/</link><pubDate>Wed, 20 May 2020 11:48:30 +0630</pubDate><guid>https://www.saryay.club/posts/2020-05-21_http_calls_in_your_code_and_how_to_test_them/</guid><description>This is a problem I always encountered whenever I try to test code that calls an external HTTP api. As web application developers, we call external APIs all the time.
And whenever that comes up, I entered into a dilema of how to test that API call. First, let us consider our options:
Option 1: We can actually send the API call and observe the response. This is obviously not pragmatic. If it&amp;rsquo;s not an idempotent API call (i.e the result is different if you call it more than once), it is not reliably reproducible. And, not all APIs have public sandbox endpoints that you can just hit.</description></item></channel></rss>