Habr မှ ဆောင်းပါးများ၏ စိတ်ကြိုက်ရွေးချယ်မှုအတွက် Telegram bot

"ဘာကြောင့်လဲ" ကဲ့သို့သော မေးခွန်းများအတွက် ဆောင်းပါးဟောင်းတစ်ခုရှိပါသည်- Natural Geektimes - အာကာသကို သန့်စင်အောင်ပြုလုပ်ခြင်း။.

ဆောင်းပါးတွေအများကြီးရှိပါတယ်၊ တချို့က ကိုယ်မကြိုက်တဲ့အကြောင်းအရာတွေကြောင့်၊ တချို့က ဆန့်ကျင်ဘက်အနေနဲ့ ကျော်သွားရတာ သနားစရာပါ။ ဒီလုပ်ငန်းစဉ်ကို အကောင်းဆုံးဖြစ်အောင်လုပ်ပြီး အချိန်ကုန်သက်သာစေချင်ပါတယ်။

အထက်ဖော်ပြပါ ဆောင်းပါးသည် in-browser scripting ချဉ်းကပ်နည်းကို အကြံပြုထားသော်လည်း အောက်ဖော်ပြပါ အကြောင်းရင်းများကြောင့် ၎င်းကို ကျွန်ုပ် (အရင်က အသုံးပြုဖူးသော်လည်း) မကြိုက်ပါ။

• သင့်ကွန်ပြူတာ/ဖုန်းရှိ မတူညီသောဘရောက်ဆာများအတွက် ဖြစ်နိုင်ပါက ၎င်းကို ထပ်မံပြင်ဆင်ရပါမည်။
• စာရေးဆရာများ၏ တင်းကျပ်သော စစ်ထုတ်မှုသည် အမြဲတမ်း အဆင်ပြေမည်မဟုတ်ပါ။
• တစ်နှစ်တစ်ကြိမ်ထုတ်ဝေသော်လည်း သင်လက်လွတ်မခံချင်သော စာရေးဆရာများ၏ ပြဿနာမှာ မဖြေရှင်းနိုင်ပါ။

ဆောင်းပါးအဆင့်သတ်မှတ်ချက်များကို အခြေခံ၍ ဆိုက်တွင် ထည့်သွင်းထားသော စစ်ထုတ်ခြင်းသည် အမြဲတမ်း အဆင်ပြေမည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် အထူးပြုဆောင်းပါးများသည် ၎င်းတို့၏တန်ဖိုးရှိသော်လည်း အနည်းငယ်မျှသာ အဆင့်သတ်မှတ်ခြင်းကို ရရှိနိုင်ပါသည်။

အစပိုင်းမှာတော့ RSS feed (ဒါမှမဟုတ် အများအပြား) ကို စိတ်ဝင်စားစရာကောင်းတဲ့ အရာတွေပဲ ထားခဲ့ချင်ခဲ့တာ။ ဒါပေမယ့် နောက်ဆုံးမှာတော့ RSS ကိုဖတ်ရတာ သိပ်အဆင်ပြေပုံမပေါ်ဘူး- ဘယ်လိုပဲဖြစ်ဖြစ်၊ ဆောင်းပါးတစ်ပုဒ်အတွက် မှတ်ချက်/မဲပေး/အနှစ်သက်ဆုံးတွေကိုထည့်ဖို့၊ ဘရောက်ဆာကနေသွားရပါမယ်။ ထို့ကြောင့် ကျွန်ုပ်ထံသို့ ကိုယ်ရေးကိုယ်တာ မက်ဆေ့ချ်တစ်ခုဖြင့် စိတ်ဝင်စားစရာကောင်းသော ဆောင်းပါးများကို ပေးပို့သည့် တယ်လီဂရမ် bot တစ်ခုကို ရေးသားခဲ့သည်။ Telegram ကိုယ်တိုင်က ၎င်းတို့ထဲမှ လှပသော အစမ်းကြည့်ရှုမှုများကို ပြုလုပ်ပေးသည်၊ ၎င်းသည် စာရေးသူ/အဆင့်သတ်မှတ်ခြင်း/အမြင်များအကြောင်း အချက်အလက်များနှင့် ပေါင်းစပ်ထားသောကြောင့် အတော်လေးကို သတင်းအချက်အလက်ပေးပုံရသည်။

ဖြတ်တောက်မှုအောက်တွင် အလုပ်၏အင်္ဂါရပ်များ၊ စာရေးခြင်းလုပ်ငန်းစဉ်နှင့် နည်းပညာဆိုင်ရာ ဖြေရှင်းချက်များကဲ့သို့သော အသေးစိတ်အချက်များပါဝင်သည်။

bot အကြောင်း အတိုချုပ်

သိုလှောင်မှု- https://github.com/Kright/habrahabr_reader

တယ်လီဂရမ်တွင် ဘော့တ်- https://t.me/HabraFilterBot

အသုံးပြုသူက တဂ်များနှင့် စာရေးဆရာများအတွက် အပိုအဆင့်သတ်မှတ်ချက်တစ်ခု သတ်မှတ်သည်။ ၎င်းနောက်၊ ဆောင်းပါးများတွင် စစ်ထုတ်ခြင်းကို အသုံးချသည် - Habré တွင် ဆောင်းပါး၏ အဆင့်သတ်မှတ်ချက်၊ စာရေးဆရာ၏ အသုံးပြုသူ အဆင့်သတ်မှတ်ချက်နှင့် တဂ်အားဖြင့် အသုံးပြုသူ အဆင့်သတ်မှတ်ချက်များအတွက် ပျမ်းမျှအား ပေါင်းထည့်ပါသည်။ ပမာဏသည် အသုံးပြုသူသတ်မှတ်ထားသော အဆင့်ထက် ပိုများပါက၊ ဆောင်းပါးသည် စစ်ထုတ်မှုကို ကျော်သွားမည်ဖြစ်သည်။

bot တစ်ခုရေးခြင်း၏ ဘေးထွက်ပန်းတိုင်မှာ ပျော်ရွှင်မှုနှင့် အတွေ့အကြုံများရရှိရန်ဖြစ်သည်။ ထို့အပြင်၊ ကျွန်ုပ်သည် ယင်းကို မှန်မှန်သတိပေးသည်။ ကျွန်ုပ်သည် Google မဟုတ်ပါ။ထို့ကြောင့် များစွာသော အရာများကို တတ်နိုင်သမျှ ရိုးရိုးရှင်းရှင်းနှင့် မူလအတိုင်းပင် လုပ်ဆောင်ပါသည်။ သို့သော်၊ ၎င်းသည် bot ကိုရေးသားခြင်းလုပ်ငန်းစဉ်ကိုသုံးလကြာအောင်မတားဆီးနိုင်ခဲ့ပါ။

အပြင်မှာ နွေရာသီ

ဇူလိုင်လကုန်တော့ bot တစ်ခုရေးဖို့ ဆုံးဖြတ်လိုက်တယ်။ တစ်ယောက်တည်းမဟုတ်ဘဲ စကလာကို ကျွမ်းကျွမ်းကျင်ကျင်နဲ့ ရေးချင်တဲ့ သူငယ်ချင်းတစ်ယောက်နဲ့ပါ။ အစပိုင်းတွင် အလားအလာကောင်းပုံရသည် - ကုဒ်ကို အဖွဲ့တစ်ဖွဲ့က ဖြတ်ပစ်မည်၊ အလုပ်က လွယ်ကူပုံပေါ်ပြီး ရက်သတ္တပတ်နှစ်ပတ် သို့မဟုတ် တစ်လအတွင်း bot အဆင်သင့်ဖြစ်မည်ဟု ကျွန်တော်ထင်ခဲ့သည်။

ပြီးခဲ့သည့်နှစ်အနည်းငယ်အတွင်း ကျွန်ုပ်ကိုယ်တိုင် ကျောက်တုံးပေါ်တွင် ကုဒ်ကို ရံဖန်ရံခါ ရေးနေသော်လည်း၊ ဤကုဒ်ကို မည်သူမျှ မမြင် သို့မဟုတ် ကြည့်ရှုလေ့ရှိသည်- အိမ်မွေးတိရစ္ဆာန်ပရောဂျက်များ၊ အိုင်ဒီယာအချို့ကို စမ်းသပ်ခြင်း၊ ဒေတာကို ကြိုတင်လုပ်ဆောင်ခြင်း၊ FP မှ သဘောတရားအချို့ကို ကျွမ်းကျင်အောင်ပြုလုပ်ခြင်းမျိုး မရှိပါ။ အဖွဲ့တစ်ဖွဲ့မှာ ကုဒ်ရေးတဲ့ပုံစံက ဘယ်လိုပုံစံလဲဆိုတာကို ကျွန်တော် တကယ်ပဲ စိတ်ဝင်စားခဲ့ပါတယ်၊ ဘာကြောင့်လဲဆိုတော့ ကျောက်ပေါ်မှာ ကုဒ်ကို ပုံစံအမျိုးမျိုးနဲ့ ရေးသားနိုင်လို့ပါပဲ။

ဘာများဖြစ်နိုင်မှာလဲ ဒါကြောင့်? သို့သော် အလျင်စလိုမနေရအောင်။
ဖြစ်ပျက်သမျှအားလုံးကို commit history ကိုသုံးပြီး ခြေရာခံနိုင်ပါတယ်။

အသိမိတ်ဆွေတစ်ယောက်က ဇူလိုင် ၂၇ မှာ သိုလှောင်ခန်းတစ်ခုကို ဖန်တီးခဲ့ပေမယ့် တခြားဘာမှ မလုပ်တဲ့အတွက် ကုဒ်ကို စရေးခဲ့တယ်။

ဇူလိုင်လ 30

အတိုချုပ်- Habr ၏ rss feed ကို ခွဲခြမ်းစိတ်ဖြာရေးသားခဲ့သည်။

• com.github.pureconfig typesafe configs ကို case classes သို့ တိုက်ရိုက်ဖတ်ခြင်းအတွက် (အလွန်အဆင်ပြေသွားသည်)
• scala-xml xml ကိုဖတ်ရှုခြင်းအတွက်- အစပိုင်းတွင် ကျွန်ုပ်သည် rss feed အတွက် ကျွန်ုပ်၏ကိုယ်ပိုင်အကောင်အထည်ဖော်မှုကို ရေးလိုခဲ့ပြီး rss feed သည် xml ဖော်မတ်ဖြင့် ခွဲခြမ်းစိပ်ဖြာရန်အတွက် ဤစာကြည့်တိုက်ကို အသုံးပြုခဲ့သည်။ တကယ်တော့ RSS ပိုင်းခြားစိတ်ဖြာမှုလည်း ပေါ်လာတယ်။
• scalatest စမ်းသပ်မှုများအတွက်။ သေးငယ်သောပရောဂျက်များအတွက်ပင်၊ စာရေးစမ်းသပ်မှုများသည် အချိန်ကုန်သက်သာစေသည် - ဥပမာ၊ xml ပိုင်းခြားစိတ်ဖြာခြင်းကို အမှားရှာသည့်အခါ၊ ၎င်းကို ဖိုင်တစ်ခုသို့ဒေါင်းလုဒ်လုပ်ရန်၊ စမ်းသပ်မှုများရေးရန်နှင့် အမှားများကိုပြင်ရန် ပို၍လွယ်ကူသည်။ မမှန်ကန်သော utf-8 စာလုံးများဖြင့် ထူးဆန်းသော html ကိုခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် နောက်ပိုင်းတွင် ချွတ်ယွင်းချက်တစ်ခုပေါ်လာသောအခါ၊ ၎င်းကို ဖိုင်တစ်ခုတွင်ထည့်ကာ စမ်းသပ်မှုတစ်ခုထည့်ရန် ပို၍အဆင်ပြေလာသည်။
• Akka မှသရုပ်ဆောင်များ။ ဓမ္မဓိဋ္ဌာန်အရတော့ သူတို့ လုံးဝ မလိုအပ်ပေမယ့် ပရောဂျက်ကို အပျော်သဘောနဲ့ ရေးထားတယ်၊ အဲဒါတွေကို စမ်းကြည့်ချင်တယ်။ ရလဒ်အနေနဲ့ သဘောကျတယ်လို့ ပြောဖို့ အဆင်သင့်ဖြစ်နေပါပြီ။ OOP ၏စိတ်ကူးကို တစ်ဖက်မှကြည့်နိုင်သည် - မက်ဆေ့ချ်ဖလှယ်သည့် သရုပ်ဆောင်များရှိသည်။ ပိုစိတ်ဝင်စားစရာကောင်းတာက မက်ဆေ့ချ်တွေ မရောက်နိုင်သလို မလုပ်ဆောင်နိုင်စေမယ့် နည်းလမ်းနဲ့ ကုဒ်ရေးနိုင်တာ (ယေဘုယျအားဖြင့် ပြောရမယ်ဆိုရင်တော့ ကွန်ပြူတာတစ်ခုတည်းမှာ အကောင့်ဖွင့်ထားတဲ့အခါ မက်ဆေ့ချ်တွေ မဆုံးရှုံးသင့်ပါဘူး)။ ပထမတော့ ကျွန်တော် ခေါင်းကုတ်နေပြီး အချင်းချင်း စာရင်းသွင်းတဲ့ သရုပ်ဆောင်တွေနဲ့ ကုဒ်မှာ အမှိုက်တွေ ရှိနေပေမယ့် နောက်ဆုံးမှာတော့ အတော်လေး ရိုးရှင်းပြီး အံဝင်ခွင်ကျ ဗိသုကာလက်ရာကို ဖန်တီးနိုင်ခဲ့တယ်။ သရုပ်ဆောင်တစ်ဦးစီရှိ ကုဒ်ကို ကြိုးတစ်ချောင်းတည်းဟု ယူဆနိုင်သည်၊ သရုပ်ဆောင်တစ်ဦး ပျက်သွားသောအခါ acca သည် ၎င်းကို ပြန်လည်စတင်သည် - ရလဒ်သည် မျှတသော အမှား-ခံနိုင်ရည်ရှိသော စနစ်ဖြစ်သည်။

9 သြဂုတ်လ

ပရောဂျက်မှာ ထည့်လိုက်တယ်။ scala-scrapper Habr မှ html စာမျက်နှာများကို ခွဲခြမ်းစိတ်ဖြာရန်အတွက် (ဆောင်းပါးအဆင့်သတ်မှတ်ချက်၊ စာညှပ်အရေအတွက် စသည်ဖြင့်) ကဲ့သို့သော အချက်အလက်များကို ထုတ်ယူရန်။

ကြောင်များ။ ​ကျောက်​ကပ်​​တွေထဲ

ထို့နောက် ဖြန့်ဝေထားသောဒေတာဘေ့စ်များအကြောင်း စာအုပ်တစ်အုပ်ကိုဖတ်ပြီး CRDT (ပဋိပက္ခကင်းစင်သောပုံတူဒေတာအမျိုးအစား၊ https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr) ထို့ကြောင့် Habré တွင် ဆောင်းပါးအကြောင်း အချက်အလက်အတွက် ဖလှယ်နိုင်သော တစ်ပိုင်းအုပ်စု၏ အမျိုးအစား အတန်းကို တင်ခဲ့သည်။

တကယ်တော့၊ အိုင်ဒီယာက အလွန်ရိုးရှင်းပါတယ် - ကျွန်ုပ်တို့တွင် monotonically ပြောင်းလဲသည့်ကောင်တာများရှိသည်။ pluses အရေအတွက် (အပြင် minuses အရေအတွက်) ကဲ့သို့ ပရိုမိုးရှင်းအရေအတွက်သည် တဖြည်းဖြည်းကြီးထွားလာသည်။ ကျွန်ုပ်တွင် ဆောင်းပါးတစ်ပုဒ်နှင့် ပတ်သက်သည့် အချက်အလက် ဗားရှင်းနှစ်မျိုးရှိပါက၊ ကျွန်ုပ်သည် ၎င်းတို့အား "တစ်ခုတည်းသို့ ပေါင်းစည်းနိုင်သည်" - ပိုကြီးသော ကောင်တာ၏ အခြေအနေသည် ပိုသက်ဆိုင်သည်ဟု ယူဆပါသည်။

Semigroup ဆိုသည်မှာ ဆောင်းပါးတစ်ခုနှင့် ပတ်သက်သည့် အချက်အလက်ပါရှိသော အရာဝတ္ထုနှစ်ခုကို တစ်ခုသို့ ပေါင်းစည်းနိုင်သည်ဟု ဆိုလိုသည်။ Commutative ဆိုသည်မှာ သင် A+B နှင့် B+A နှစ်ခုလုံးကို ပေါင်းစည်းနိုင်သည်၊ ရလဒ်သည် အမိန့်အပေါ်မမူတည်ပါ၊ အဆုံးတွင် နောက်ဆုံးဗားရှင်းသည် ကျန်ရှိနေမည်ဖြစ်သည်။ စကားမစပ်၊ ဒီနေရာမှာ ပေါင်းသင်းဆက်ဆံမှုလည်းရှိတယ်။

ဥပမာအားဖြင့်၊ စီစဉ်ထားသည့်အတိုင်း၊ ခွဲခြမ်းစိတ်ဖြာပြီးနောက် rss သည် ကြည့်ရှုမှုအရေအတွက်ကဲ့သို့သော မက်ထရစ်များမပါဘဲ ဆောင်းပါးနှင့်ပတ်သက်သည့် အနည်းငယ်အားနည်းသော အချက်အလက်ကို ပေးဆောင်သည်။ ထို့နောက် အထူးသရုပ်ဆောင်တစ်ဦးသည် ဆောင်းပါးများနှင့်ပတ်သက်သည့် အချက်အလက်များကို ရယူပြီး ၎င်းကို အပ်ဒိတ်လုပ်ကာ ဗားရှင်းအဟောင်းနှင့် ပေါင်းစည်းရန် html စာမျက်နှာများသို့ ပြေးသွားခဲ့သည်။

ယေဘူယျအားဖြင့်ပြောရလျှင်၊ akka ကဲ့သို့ပင်၊ ဤအရာအတွက် မလိုအပ်ပါ၊ သင်သည် ဆောင်းပါးအတွက် updateDate ကို ရိုးရိုးရှင်းရှင်း သိမ်းဆည်းနိုင်ပြီး ပေါင်းစည်းခြင်းမရှိဘဲ အသစ်တစ်ခုကို ယူနိုင်သော်လည်း စွန့်စားမှုလမ်းက ကျွန်ုပ်ကို ဦးဆောင်သွားပါသည်။

12 သြဂုတ်လ

ကျွန်မက ပိုလွတ်လပ်လာပြီး အပျော်သဘောသက်သက်နဲ့ စကားပြောခန်းတစ်ခုစီကို သီးခြားသရုပ်ဆောင်တစ်ယောက်အဖြစ် လုပ်ခဲ့တယ်။ သီအိုရီအရ၊ သရုပ်ဆောင်တစ်ဦးကိုယ်တိုင်က 300 bytes အလေးချိန်ရှိပြီး ၎င်းတို့ကို သန်းပေါင်းများစွာဖြင့် ဖန်တီးနိုင်သောကြောင့် ၎င်းသည် လုံးဝပုံမှန်ချဉ်းကပ်မှုဖြစ်သည်။ အဖြေက တော်တော်စိတ်ဝင်စားဖို့ကောင်းတယ်လို့ ထင်ပါတယ်-

မင်းသားတစ်ယောက်သည် ကြေးနန်းဆာဗာနှင့် Akka ရှိ မက်ဆေ့ချ်စနစ်ကြားတွင် တံတားတစ်ခုဖြစ်သည်။ သူက ရိုးရိုးရှင်းရှင်းပဲ မက်ဆေ့ချ်တွေကို လက်ခံပြီး လိုချင်တဲ့ chat actor ဆီကို ပို့လိုက်တယ်။ ချတ်သရုပ်ဆောင်သည် တုံ့ပြန်မှုတစ်ခုခုကို ပေးပို့နိုင်ပြီး တယ်လီဂရမ်သို့ ပြန်လည်ပေးပို့မည်ဖြစ်သည်။ အလွန်အဆင်ပြေသည့်အချက်မှာ ဤမင်းသားသည် တတ်နိုင်သမျှရိုးရှင်းပြီး မက်ဆေ့ချ်များကို တုံ့ပြန်ခြင်းအတွက် ယုတ္တိရှိခြင်းသာဖြစ်သည်။ စကားမစပ်၊ ဆောင်းပါးအသစ်များအကြောင်း အချက်အလက်များသည် ချက်တင်တိုင်းသို့ ရောက်လာသော်လည်း၊ ဤအရာတွင် ပြဿနာတစ်စုံတစ်ရာ မတွေ့ရတော့ပါ။

ယေဘုယျအားဖြင့်၊ ဘော့တ်သည် အလုပ်လုပ်နေပြီး၊ မက်ဆေ့ဂျ်များကို တုံ့ပြန်ခြင်း၊ အသုံးပြုသူထံ ပေးပို့သည့် ဆောင်းပါးစာရင်းကို သိမ်းဆည်းထားပြီး၊ ဘော့တ်သည် အဆင်သင့်ဖြစ်လုနီးပါးဖြစ်နေပြီဟု ကျွန်ုပ်တွေးနေမိသည်။ စာရေးဆရာအမည်များနှင့် တဂ်များကို ပုံမှန်ဖြစ်စေခြင်း (“sd f” ကို “s_d_f” ဖြင့် အစားထိုးခြင်းကဲ့သို့ အင်္ဂါရပ်ငယ်များကို ဖြည်းဖြည်းချင်း ထည့်သွင်းပါသည်။

တစ်ခုပဲကျန်တော့တယ်။ သေးငယ်သော်လည်း - နိုင်ငံတော်သည် မည်သည့်နေရာတွင်မှ မကယ်တင်နိုင်ခဲ့ပါ။

အားလုံးမှားသွားပါပြီ။

ငါ bot ကို အများအားဖြင့် တစ်ယောက်တည်း ရေးခဲ့တာကို မင်း သတိပြုမိလိမ့်မယ်။ ထို့ကြောင့်၊ ဒုတိယပါဝင်သူသည် ဖွံ့ဖြိုးတိုးတက်မှုတွင် ပါဝင်ခဲ့ပြီး၊ အောက်ပါပြောင်းလဲမှုများသည် ကုဒ်တွင် ပေါ်လာသည်-

• MongoDB သည် သိမ်းဆည်းရန် အခြေအနေ ပေါ်လာသည်။ တစ်ချိန်တည်းမှာပင်၊ အကြောင်းတစ်ခုခုကြောင့် Monga သည် ၎င်းတို့ကို စပမ်းလုပ်ခဲ့ပြီး အချို့သောလူများက ၎င်းတို့ကို တစ်ကမ္ဘာလုံးတွင် ပိတ်လိုက်ခြင်းကြောင့် ပရောဂျက်ရှိ မှတ်တမ်းများ ကျိုးသွားခဲ့သည်။
• Telegram ရှိ တံတားသရုပ်ဆောင်သည် အသိအမှတ်မပြုဘဲ အသွင်ပြောင်းကာ မက်ဆေ့ချ်များကို သူ့ကိုယ်သူ ခွဲခြမ်းစိတ်ဖြာရန် စတင်ခဲ့သည်။
• ချတ်များအတွက် သရုပ်ဆောင်များကို မညှာမတာ ဖြတ်တောက်ခဲ့ပြီး ယင်းအစား ချတ်အားလုံးနှင့်ပတ်သက်သည့် အချက်အလက်အားလုံးကို တစ်ပြိုင်နက် ဝှက်ထားသည့် သရုပ်ဆောင်တစ်ဦးဖြင့် အစားထိုးခဲ့သည်။ နှာချေတိုင်း ဒီမင်းသား ဒုက္ခရောက်တယ်။ ဟုတ်ပါတယ်၊ ဆောင်းပါးတစ်ပုဒ်ရဲ့ အချက်အလက်ကို အပ်ဒိတ်လုပ်တဲ့အခါ၊ ချတ်သရုပ်ဆောင်တွေဆီ ပို့ရတာက ခက်ခဲပါတယ် (ကျွန်ုပ်တို့ဟာ Google လိုပဲ၊ သုံးစွဲသူ သန်းပေါင်းများစွာဟာ chat တစ်ခုစီအတွက် ဆောင်းပါးတစ်သန်းကို စောင့်နေကြပါတယ်) ဒါပေမယ့် ချတ်ကို အပ်ဒိတ်လုပ်တိုင်း၊ Monga ကိုသွားရတာ ပုံမှန်ပါပဲ။ တော်တော်ကြာတော့ ကျွန်တော် သဘောပေါက်လာသလိုပဲ၊ chats တွေရဲ့ အလုပ်လုပ်တဲ့ ယုတ္တိကိုလည်း လုံးဝဖြတ်တောက်ပြီး သူ့နေရာမှာ အလုပ်မလုပ်တဲ့ အရာတစ်ခု ပေါ်လာတယ်။
• အမျိုးအစား အတန်းများတွင် ခြေရာမကျန်တော့ပါ။
• အချို့သော ကျန်းမာရေးနှင့် မညီညွတ်သော ယုတ္တိဗေဒသည် ပြိုင်ဆိုင်မှု အခြေအနေတစ်ခုသို့ ဦးတည်သွားစေသည့် ၎င်းတို့၏ စာရင်းသွင်းမှုများနှင့်အတူ သရုပ်ဆောင်များထဲတွင် ပေါ်လာသည်။
• အမျိုးအစားနယ်ပယ်များပါရှိသော ဒေတာဖွဲ့စည်းပုံများ Option[Int] -1 ကဲ့သို့ မှော်ဆန်သော မူရင်းတန်ဖိုးများဖြင့် Int အဖြစ်သို့ ပြောင်းလဲသွားသည်။ နောက်ပိုင်းမှာ mongoDB က json ကို သိမ်းထားတယ်ဆိုတာ သိသွားပြီး အဲဒီမှာ သိမ်းတာ ဘာမှ မမှားပါဘူး။ Option ကောင်းပြီ၊ သို့မဟုတ် အနည်းဆုံး -1 ကို None အဖြစ် ခွဲခြမ်းစိပ်ဖြာရန်၊ သို့သော် ထိုအချိန်တွင် ကျွန်ုပ်သည် ဤအရာကို မသိခဲ့ဘဲ "ထိုသို့ဖြစ်သင့်သည်" ဟု ကျွန်ုပ်၏ စကားကို ခံယူခဲ့ပါသည်။ ကျွန်တော် ဒီကုဒ်ကို မရေးထားဘူး၊ လောလောဆယ်တော့ အဲဒါကို ပြောင်းဖို့ စိတ်မ၀င်စားဘူး။
• ကျွန်ုပ်၏ အများသူငှာ IP လိပ်စာသည် ပြောင်းလဲတတ်သည်ကို တွေ့ရှိခဲ့ရပြီး အခါတိုင်း ၎င်းကို Mongo ၏ ခွင့်ပြုချက်စာရင်းတွင် ထည့်သွင်းရမည်ဖြစ်ပါသည်။ ဘော့တ်ကို ပြည်တွင်းမှာ စတင်ခဲ့တယ်၊ Monga ဟာ ကုမ္ပဏီတစ်ခုအနေနဲ့ Monga ရဲ့ ဆာဗာတွေပေါ်မှာ ရှိနေခဲ့ပါတယ်။
• ရုတ်တရက်၊ ကြေးနန်းစာအတွက် တဂ်များနှင့် မက်ဆေ့ချ်ဖော်မတ်ကို ပုံမှန်ပြုလုပ်ခြင်း ပျောက်သွားသည်။ (ဟမ်၊ ဘာဖြစ်လို့ ဖြစ်ရတာလဲ။)
• ဘော့တ်၏ အခြေအနေကို ပြင်ပဒေတာဘေ့စ်တစ်ခုတွင် သိမ်းဆည်းထားခြင်းကို နှစ်သက်ပြီး ပြန်လည်စတင်သောအခါတွင် ၎င်းသည် ဘာမှမဖြစ်ခဲ့သကဲ့သို့ ဆက်လက်လုပ်ဆောင်နေပါသည်။ သို့သော် ဤအရာသည် တစ်ခုတည်းသော အပေါင်းဖြစ်ခဲ့သည်။

ဒုတိယလူသည် အထူးအလျင်လိုမှုမရှိဘဲ၊ ဤပြောင်းလဲမှုများအားလုံးသည် စက်တင်ဘာလအစတွင်ရှိနေပြီဖြစ်သော အမှိုက်ပုံကြီးတစ်ခုတွင် ပေါ်လာသည်။ ထွက်ပေါ်လာတဲ့ ပျက်စီးခြင်းရဲ့ အတိုင်းအတာကို ကျွန်တော် ချက်ချင်း သဘောမပေါက်ဘဲ ဒေတာဘေ့စ်ရဲ့ လုပ်ဆောင်ချက်ကို နားလည်လာတယ်...။ အရင်က သူတို့နဲ့ မဆက်ဆံဖူးဘူး။ အလုပ်လုပ်သောကုဒ်ကိုဖြတ်တောက်ပြီး ၎င်း၏နေရာတွင် ချွတ်ယွင်းချက်မည်မျှထည့်ထားသည်ကို နောက်ပိုင်းမှသာ သိရှိလာခဲ့သည်။

စက်တင်ဘာလ

အစကတော့ Monga ကို ကျွမ်းကျင်ပြီး ကောင်းကောင်းလုပ်တတ်ဖို့ အသုံးဝင်မယ်လို့ ထင်ပါတယ်။ ထို့နောက် ဒေတာဘေ့စ်နှင့် ဆက်သွယ်ရေးကို စည်းရုံးခြင်းသည် သင်သည် ပြိုင်ပွဲများစွာကို ပြုလုပ်နိုင်ပြီး အမှားအယွင်းများ ပြုလုပ်နိုင်သည့် အနုပညာတစ်ခုလည်းဖြစ်ကြောင်း ဖြည်းဖြည်းချင်း နားလည်လာသည်။ ဥပမာအားဖြင့်၊ အကယ်၍ သုံးစွဲသူသည် နှစ်သက်သည့် မက်ဆေ့ချ်နှစ်ခုကို လက်ခံရရှိပါက၊ /subscribe - နှင့် တစ်ခုချင်းစီကို တုံ့ပြန်သည့်အနေဖြင့် ကျွန်ုပ်တို့သည် ထိုမက်ဆေ့ချ်များကို လုပ်ဆောင်နေချိန်တွင် အသုံးပြုသူစာရင်းသွင်းထားခြင်းမရှိသောကြောင့် ဇယားတွင် ထည့်သွင်းမှုတစ်ခုကို ဖန်တီးပါမည်။ Monga နှင့် ၎င်း၏ လက်ရှိပုံစံဖြင့် ဆက်သွယ်ခြင်းသည် အကောင်းဆုံးနည်းလမ်းဖြင့် ရေးသားထားခြင်းမဟုတ်ကြောင်း ကျွန်ုပ်သံသယရှိပါသည်။ ဥပမာအားဖြင့်၊ သူအကောင့်ဖွင့်ချိန်တွင် အသုံးပြုသူ၏ဆက်တင်များကို ဖန်တီးထားသည်။ စာရင်းသွင်းခြင်းမပြုလုပ်မီ ၎င်းတို့ကို ပြောင်းလဲရန် ကြိုးစားခဲ့လျှင်... bot သည် ဘာမှမတုံ့ပြန်ခဲ့ပါ။ အကြောင်းမှာ သရုပ်ဆောင်ရှိကုဒ်သည် ဆက်တင်များအတွက် ဒေတာဘေ့စ်ထဲသို့ ဝင်သွားပြီး ၎င်းကို ရှာမတွေ့၍ ပျက်သွားသောကြောင့်ဖြစ်သည်။ လိုအပ်သလို ဆက်တင်တွေကို ဘာကြောင့် မဖန်တီးတာလဲလို့ မေးတဲ့အခါ၊ အသုံးပြုသူ စာရင်းသွင်းမထားပါက ၎င်းတို့ကို ပြောင်းလဲရန် မလိုအပ်ကြောင်း သိရှိခဲ့ရပါတယ်... မက်ဆေ့ချ် စစ်ထုတ်ခြင်းစနစ်သည် သိသိသာသာကို တစ်နည်းနည်းနဲ့ ပြုလုပ်ထားခြင်းဖြစ်ပြီး ကုဒ်ကို အနီးကပ်ကြည့်ပြီးနောက်မှာပင် ကျွန်ုပ်တတ်နိုင်ပါသည် အစတွင် ဤနည်းဖြင့် ရည်ရွယ်ထားခြင်းရှိမရှိ သို့မဟုတ် အမှားအယွင်းတစ်ခုရှိမရှိ နားမလည်ပါ။

ချတ်သို့တင်သွင်းသည့် ဆောင်းပါးစာရင်းမရှိပါ၊ ယင်းအစား ၎င်းတို့ကို ကျွန်ုပ်ကိုယ်တိုင်ရေးရန် အကြံပြုထားသည်။ ဒါက ကျွန်မကို အံ့အားသင့်စေတယ် - ယေဘုယျအားဖြင့်၊ ပရောဂျက်ထဲကို အရာအားလုံးကို ဆွဲထုတ်တာကို မကန့်ကွက်ပါဘူး၊ ဒါပေမယ့် ဒီအရာတွေကို ယူဆောင်လာပြီး ဖောက်ထည့်ခဲ့တဲ့သူအတွက် ယုတ္တိတန်ပါလိမ့်မယ်။ သို့သော်၊ ဒုတိယပါဝင်သူသည် အရာအားလုံးကို စွန့်လွှတ်လိုက်ပုံရသော်လည်း ချတ်အတွင်းရှိစာရင်းသည် ဆိုးရွားသောဖြေရှင်းချက်ဟု ယူဆရပြီး “ဆောင်းပါး y ကို အသုံးပြုသူ x သို့ ပေးပို့လိုက်သည်” ကဲ့သို့သော ဖြစ်ရပ်များနှင့် နိမိတ်ပြရန် လိုအပ်သည်ဟု ဆိုသည်။ ထို့နောက်၊ အသုံးပြုသူက ဆောင်းပါးအသစ်များ ပေးပို့ရန် တောင်းဆိုပါက၊ ဖြစ်ရပ်များမှ အသုံးပြုသူနှင့် သက်ဆိုင်သည့် ဖြစ်ရပ်များကို ရွေးချယ်ပေးမည့် ဒေတာဘေ့စ်သို့ တောင်းဆိုချက်တစ်ခု ပေးပို့ရန် လိုအပ်သည်၊ ၎င်းသည် ဖြစ်ရပ်များမှ အသုံးပြုသူနှင့် သက်ဆိုင်သည့် ဖြစ်ရပ်များကို ရွေးချယ်ကာ ဆောင်းပါးအသစ်များစာရင်းကိုလည်း ရယူပါ၊ ၎င်းတို့ကို စစ်ထုတ်ကာ အသုံးပြုသူထံ ပေးပို့မည်ဖြစ်သည်။ ပြီးတာနဲ့ ဒီအကြောင်းအရာတွေကို ဒေတာဘေ့စ်ထဲကို ပြန်ထည့်ပါ။

bot သည် Habr မှ ဆောင်းပါးများသာမက တယ်လီဂရမ်သို့သာ ပေးပို့ခံရသည့်အခါတွင် ဒုတိယပါဝင်သူသည် abstraction များဆီသို့ တစ်နေရာရာသို့ သယ်ဆောင်သွားပါသည်။

စက်တင်ဘာလ၏ ဒုတိယနှစ်ဝက်အတွက် သီးခြားလက္ခဏာပုံစံဖြင့် အဖြစ်အပျက်များကို တစ်နည်းနည်းဖြင့် အကောင်အထည်ဖော်ခဲ့ပါသည်။ အဲဒါက အသင့်တော်ဆုံးမဟုတ်ပေမယ့် အနည်းဆုံးတော့ bot က အလုပ်စလုပ်ပြီး ဆောင်းပါးတွေ ထပ်ပို့တော့တယ်၊ ကုဒ်ထဲမှာ ဘာတွေဖြစ်နေလဲဆိုတာကို ဖြည်းဖြည်းချင်း ရှာတွေ့ခဲ့တယ်။

ယခု သင်သည် အစသို့ ပြန်သွားနိုင်ပြီး သိုလှောင်မှုအား ကျွန်ုပ်က မူလဖန်တီးထားခြင်းမဟုတ်ကြောင်း သတိရပါ။ ဒီလိုမျိုး ဘာများဖြစ်နိုင်မှာလဲ? ကျွန်ုပ်၏ တောင်းဆိုချက်ကို ပယ်ချခဲ့သည်။ ကျွန်ုပ်တွင် လည်ပင်းနီကုဒ် ရှိသည်၊ အဖွဲ့တစ်ခုတွင် မည်သို့လုပ်ဆောင်ရမည်ကို မသိသောကြောင့်၊ လက်ရှိ အကောင်အထည်ဖော်မှုမျဉ်းကွေးတွင် အမှားအယွင်းများကို ပြုပြင်ရမည်ဖြစ်ပြီး ၎င်းကို အသုံးပြုနိုင်သော အခြေအနေသို့ ပြန်လည်မွမ်းမံရန် လိုအပ်ပါသည်။

ကျွန်တော် စိတ်ဆိုးသွားပြီး ကွန်မန့်မှတ်တမ်းနဲ့ ရေးထားတဲ့ ကုဒ်ပမာဏကို ကြည့်လိုက်တယ်။ မူရင်းရေးထားတဲ့ အခိုက်အတန့်တွေကို ကြည့်လိုက်တော့ ကြေကွဲသွားတယ်...

F*rk အဲဒါ

ဆောင်းပါးကို သတိရမိတယ်။ သင်သည် Google မဟုတ်ပါ။.

အကောင်အထည်မဖော်ဘဲနဲ့ ဘယ်သူမှ စိတ်ကူးကို အမှန်တကယ် မလိုအပ်ဘူးလို့ ထင်ခဲ့တယ်။ ရိုးရှင်းသော java ပရိုဂရမ်တစ်ခုအနေဖြင့် ကွန်ပျူတာတစ်ခုတည်းတွင် ကော်ပီတစ်ခုတည်းတွင် အလုပ်လုပ်မည့် bot တစ်ခုရှိချင်သည်ဟု ကျွန်တော်ထင်ခဲ့သည်။ ကျွန်ုပ်သည် ယခင်က ထိုသို့သော ဘော့တ်များကို ရေးသားထားပြီးဖြစ်သောကြောင့်၊ ကျွန်ုပ်၏ bot သည် ပြန်လည်စတင်ခြင်းမရှိဘဲ လနှင့်ချီ၍ အလုပ်လုပ်မည်ကို ကျွန်ုပ်သိပါသည်။ အကယ်၍ ၎င်းသည် ရုတ်တရက် ပြုတ်ကျပြီး အသုံးပြုသူအား အခြားဆောင်းပါးကို မပေးပို့ပါက၊ ကောင်းကင်ယံသည် မြေပေါ်သို့ ကျရောက်မည်မဟုတ်သည့်အပြင် မည်သည့်အရာမျှ ကပ်ဆိုးဖြစ်လာမည်မဟုတ်ပေ။

ကုဒ်ရိုးရှင်းစွာအလုပ်မလုပ်ပါက၊ သို့မဟုတ် လိမ်လည်၍မရပါက Docker၊ mongoDB နှင့် အခြားကုန်တင်ကုန်ချဘာသာတရားတို့၌ အဘယ်ကြောင့်လိုအပ်သနည်း။

ပရောဂျက်ကို ဖြတ်ပြီး လိုချင်တာမှန်သမျှ လုပ်ခဲ့တယ်။

တစ်ချိန်တည်းမှာပဲ အလုပ်ပြောင်းပြီး အားလပ်ချိန်တွေ အရမ်းနည်းလာတယ်။ မနက်မိုးလင်းတော့ ရထားပေါ်မှာ အိပ်ရာက နိုးတော့ ညနေ နောက်ကျမှ ပြန်ရောက်တော့ ဘာမှ မလုပ်ချင်တော့ဘူး။ ကျွန်တော် ဘာမှမလုပ်ဘဲ ခဏကြာတော့ ဘော့တ်ကို ပြီးအောင် လုပ်ချင်စိတ်က ကျွန်တော့်ကို လွှမ်းမိုးသွားပြီး မနက်အလုပ်သွားဖို့ ကားမောင်းရင်း ကုဒ်ကို ဖြည်းဖြည်းချင်း ပြန်ရေးခဲ့တယ်။ အဲဒါက ထိရောက်တယ်လို့ ကျွန်တော် မပြောပါဘူး- သင့်ပေါင်ပေါ် လက်ပ်တော့တစ်လုံးနဲ့ တုန်ခါနေတဲ့ ရထားပေါ်မှာ ထိုင်ပြီး သင့်ဖုန်းထဲက အလျှံပယ်တွေကို ကြည့်ရတာ သိပ်အဆင်မပြေပါဘူး။ သို့သော်၊ ကုဒ်ရေးသည့်အချိန်သည် လုံးဝသတိမထားမိဘဲ လွင့်သွားကာ ပရောဂျက်သည် အလုပ်လုပ်သည့်အခြေအနေသို့ ဖြည်းညှင်းစွာ ရွေ့လျားလာသည်။

ကျွန်ုပ်၏စိတ်၏နောက်ကျောတစ်နေရာတွင် mongoDB ကိုအသုံးပြုလိုသည့်သံသယပိုးများရှိနေသည်၊ သို့သော် "ယုံကြည်စိတ်ချရသော" ပြည်နယ်သိုလှောင်မှု၏အားသာချက်များအပြင်၊ သိသာထင်ရှားသောအားနည်းချက်များရှိသည် -

• ဒေတာဘေ့စ်သည် ပျက်ကွက်မှု၏ နောက်တစ်ခု ဖြစ်လာသည်။
• ကုဒ်သည် ပိုမိုရှုပ်ထွေးလာပြီး ၎င်းကိုရေးရန် အချိန်ပိုကြာလိမ့်မည်။
• ကုဒ်သည် နှေးကွေးပြီး ထိရောက်မှုမရှိတော့ဘဲ မန်မိုရီအတွင်းရှိ အရာဝတ္ထုတစ်ခုကို ပြောင်းလဲမည့်အစား အပြောင်းအလဲများကို ဒေတာဘေ့စ်သို့ ပေးပို့ပြီး လိုအပ်ပါက ပြန်ဆွဲထုတ်ပါသည်။
• ဒေတာဘေ့စ်၏ထူးခြားချက်များနှင့်ဆက်စပ်နေသည့် သီးခြားဇယားတစ်ခုရှိ အဖြစ်အပျက်များ၏ သိုလှောင်မှုအမျိုးအစားအပေါ် ကန့်သတ်ချက်များရှိသည်။
• Monga ၏အစမ်းသုံးဗားရှင်းတွင် ကန့်သတ်ချက်အချို့ရှိပြီး ၎င်းတို့ကိုသင်ဝင်ရောက်ပါက Monga ကိုဖွင့်ပြီး တစ်ခုခုကိုပြင်ဆင်သတ်မှတ်ရမည်ဖြစ်သည်။

ငါ monga ကိုဖြတ်လိုက်သည်၊ ယခု bot ၏အခြေအနေကိုရိုးရှင်းစွာပရိုဂရမ်၏မှတ်ဉာဏ်တွင်သိမ်းဆည်းထားပြီး json ပုံစံဖိုင်တစ်ခုသို့မကြာခဏသိမ်းဆည်းထားသည်။ မှတ်ချက်များတွင် ၎င်းတို့သည် ကျွန်ုပ်မှားသည်ဟု ရေးကြလိမ့်မည်၊ ဤနေရာသည် ဒေတာဘေ့စ်ကို အသုံးပြုသင့်သည် စသည်တို့ ဖြစ်ကောင်းဖြစ်နိုင်သည်။ သို့သော် ဤအရာသည် ကျွန်ုပ်၏ပရောဂျက်ဖြစ်သည်၊ ဖိုင်နှင့်ချဉ်းကပ်ပုံသည် အတတ်နိုင်ဆုံးရိုးရှင်းပြီး ပွင့်လင်းမြင်သာသောပုံစံဖြင့် အလုပ်လုပ်ပါသည်။

-1 ကဲ့သို့ မှော်တန်ဖိုးများကို ပစ်ချပြီး ပုံမှန်တန်ဖိုးများကို ပြန်ပေးသည်။ Optionချတ်အချက်အလက်ဖြင့် အရာဝတ္ထုထံ ပြန်ပို့သည့် ဆောင်းပါးများပါရှိသော hash table တစ်ခု၏ သိုလှောင်မှုကို ပေါင်းထည့်ထားသည်။ အားလုံးကို သိမ်းဆည်းခြင်းမခံရစေရန် ငါးရက်အထက် ဆောင်းပါးများအကြောင်း အချက်အလက်များကို ဖျက်လိုက်ပါသည်။ ကျွန်ုပ်သည် မှတ်တမ်းမှတ်ရာကို အလုပ်လုပ်သည့်အခြေအနေသို့ ယူဆောင်လာပါသည် - မှတ်တမ်းများကို ဖိုင်နှင့် ကွန်ဆိုးလ်နှစ်ခုလုံးအတွက် ကျိုးကြောင်းဆီလျော်သော ပမာဏဖြင့် ရေးသားထားသည်။ သိမ်းဆည်းသည့်အခြေအနေ သို့မဟုတ် အသုံးပြုသူအရေအတွက်နှင့် ဆောင်းပါးများကဲ့သို့သော စာရင်းအင်းရယူခြင်းကဲ့သို့သော စီမံခန့်ခွဲရေးအမိန့်အများအပြားကို ထည့်သွင်းခဲ့သည်။

သေးငယ်သောအရာများကို ပြုပြင်ထားသည်- ဥပမာ၊ ဆောင်းပါးများအတွက် အသုံးပြုသူ၏ စစ်ထုတ်မှုကို ကျော်သွားချိန်တွင် ကြည့်ရှုမှု၊ ကြိုက်နှစ်သက်မှု၊ မကြိုက်မှုများနှင့် မှတ်ချက်များ အရေအတွက်ကို ယခု ဖော်ပြထားပါသည်။ ယေဘူယျအားဖြင့် သေးငယ်သောအရာများကို မည်မျှပြုပြင်ရမည်ကို အံ့သြစရာပင်။ စာရင်းကို သိမ်းဆည်းထားပြီး ထိုနေရာတွင် "မမှန်ခြင်း" အားလုံးကို မှတ်သားပြီး တတ်နိုင်သမျှ ပြုပြင်ပေးခဲ့ပါသည်။

ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် မက်ဆေ့ချ်တစ်ခုတွင် ဆက်တင်အားလုံးကို တိုက်ရိုက်သတ်မှတ်ရန် စွမ်းရည်ကို ထည့်သွင်းခဲ့သည်-

/subscribe
/rating +20
/author a -30
/author s -20
/author p +9000
/tag scala 20
/tag akka 50

ပြီးတော့ တခြားအဖွဲ့ /settings ၎င်းတို့ကို ဤဖောင်တွင် အတိအကျပြသသည်၊ သင်သည် ၎င်းမှ စာသားကိုယူ၍ ဆက်တင်အားလုံးကို သူငယ်ချင်းထံ ပေးပို့နိုင်သည်။
သေးငယ်သော အရာဟု ထင်ရသော်လည်း အလားတူ ကွဲပြားချက်များ များစွာရှိသည်။

ရိုးရှင်းသော linear မော်ဒယ်ပုံစံဖြင့် ဆောင်းပါးကို စစ်ထုတ်ခြင်းအား အကောင်အထည်ဖော်ခဲ့သည် - အသုံးပြုသူသည် စာရေးဆရာများနှင့် တဂ်များအတွက် အပိုအဆင့်သတ်မှတ်ချက်တစ်ခုအပြင် အတိုင်းအတာတန်ဖိုးတစ်ခု သတ်မှတ်နိုင်သည်။ စာရေးဆရာအဆင့်သတ်မှတ်ချက်၏ ပေါင်းလဒ်၊ တဂ်များအတွက် ပျမ်းမျှအဆင့်သတ်မှတ်ချက်နှင့် ဆောင်းပါး၏အမှန်တကယ်အဆင့်သတ်မှတ်ချက်သည် အတိုင်းအတာတန်ဖိုးထက် ပိုများနေပါက ဆောင်းပါးကို အသုံးပြုသူအား ပြသမည်ဖြစ်သည်။ command /new ဖြင့် ဆောင်းပါးများအတွက် bot ကို သင်မေးနိုင်သည် သို့မဟုတ် bot သို့ စာရင်းသွင်းပြီး ၎င်းသည် နေ့စဥ်အချိန်မရွေး ကိုယ်ရေးကိုယ်တာမက်ဆေ့ခ်ျတစ်ခုသို့ ဆောင်းပါးများ ပေးပို့မည်ဖြစ်သည်။

ယေဘူယျအားဖြင့်ပြောရလျှင်၊ ဆောင်းပါးတစ်ခုစီအတွက် နောက်ထပ်အင်္ဂါရပ်များ (အချက်အချာကျသော မှတ်ချက်အရေအတွက်၊ စာညှပ်များ၊ အဆင့်သတ်မှတ်ချက်ပြောင်းလဲမှုများ၏ ဒိုင်းနမစ်များ၊ ဆောင်းပါးအတွင်းရှိ စာသားပမာဏ၊ ရုပ်ပုံများနှင့် ကုဒ်များ၊ သော့ချက်စကားလုံးများ) ကို အသုံးပြု၍ သုံးစွဲသူအား ok ပြရန် ဆောင်းပါးတစ်ခုစီအောက်မှာ မဲပေးပြီး အသုံးပြုသူတိုင်းအတွက် စံနမူနာတစ်ခု လေ့ကျင့်ပေးပေမယ့် အရမ်းပျင်းခဲ့ပါတယ်။

ထို့အပြင်၊ အလုပ်၏ယုတ္တိဗေဒသည် ဤမျှလောက်ထင်ရှားမည်မဟုတ်ပါ။ ယခု ကျွန်ုပ်သည် လူနာZero အတွက် +9000 အဆင့်သတ်မှတ်ချက်ကို ကိုယ်တိုင်သတ်မှတ်နိုင်ပြီး +20 အဆင့်သတ်မှတ်ချက်ဖြင့် သူ့ဆောင်းပါးများအားလုံးကို လက်ခံရရှိရန် အာမခံနိုင်ပါမည် (ဟုတ်ပါတယ်၊ အချို့သောတဂ်များအတွက် -100500 ကို သတ်မှတ်မထားပါက)။

နောက်ဆုံးဗိသုကာလက်ရာသည် အတော်လေးရိုးရှင်းပါသည်။

1. ချတ်နှင့် ဆောင်းပါးအားလုံး၏ အခြေအနေများကို သိမ်းဆည်းထားသည့် သရုပ်ဆောင်။ ၎င်းသည် ဒစ်ခ်ပေါ်ရှိ ဖိုင်တစ်ခုမှ ၎င်း၏အခြေအနေကို ဒေါင်းလုဒ်လုပ်ကာ ဖိုင်အသစ်တစ်ခုသို့ အခါအားလျော်စွာ ပြန်သိမ်းသည်။
2. RSS feed ကို ရံဖန်ရံခါ လာရောက်ကြည့်ရှုသူ၊ ဆောင်းပါးအသစ်များအကြောင်း လေ့လာသူ၊ လင့်ခ်များကို ကြည့်ရှု၊ ခွဲခြမ်းစိတ်ဖြာကာ ဤဆောင်းပါးများကို ပထမဆုံး သရုပ်ဆောင်သူထံ ပေးပို့သည့် သရုပ်ဆောင်။ ထို့အပြင်၊ တခါတရံတွင် ပထမသရုပ်ဆောင်ထံမှ ဆောင်းပါးများစာရင်းကို တောင်းဆိုသည်၊ သုံးရက်ထက်မပိုသော ဆောင်းပါးများကို ရွေးချယ်ကာ အချိန်အကြာကြီး မွမ်းမံပြင်ဆင်ပြီး ၎င်းတို့ကို အပ်ဒိတ်လုပ်ပါ။
3. ကြေးနန်းစာနဲ့ ဆက်သွယ်ပေးတဲ့ သရုပ်ဆောင်။ ဒီစာကို ခွဲခြမ်းစိတ်ဖြာပြီး အပြည့်အစုံ ယူလာတုန်းပဲ။ ဖော်ရွေသောနည်းဖြင့်၊ တစ်ခုသည် အဝင်မက်ဆေ့ချ်များကို ခွဲခြမ်းစိပ်ဖြာနိုင်ရန် ၎င်းကို နှစ်ပိုင်းခွဲပြီး ဒုတိယတစ်ခုသည် ပို့မထားသော မက်ဆေ့ချ်များကို ပြန်လည်ပေးပို့ခြင်းကဲ့သို့သော သယ်ယူပို့ဆောင်ရေးဆိုင်ရာ ပြဿနာများကို ဖြေရှင်းပေးပါသည်။ ယခု ပြန်လည်ပေးပို့ခြင်း မရှိတော့ဘဲ error တစ်ခုကြောင့် ရောက်ရှိလာသော မက်ဆေ့ချ်သည် ရိုးရိုးရှင်းရှင်း ပျောက်ဆုံးသွားလိမ့်မည် (မှတ်တမ်းများတွင် မှတ်သားထားခြင်းမရှိပါက) သို့သော် ယခုအချိန်အထိ မည်သည့်ပြဿနာမျှ မဖြစ်သေးပါ။ လူများစွာသည် bot ကိုစာရင်းသွင်းပြီး မက်ဆေ့ချ်ပို့ရန် ကန့်သတ်ချက်သို့ရောက်ရှိပါက ပြဿနာများ ဖြစ်ပေါ်လာနိုင်သည်။)

ကျွန်တော် သဘောကျတာက akka ကြောင့် သရုပ်ဆောင် 2 နဲ့ 3 ရဲ့ ပြုတ်ကျမှုက bot ရဲ့ စွမ်းဆောင်ရည်ကို မထိခိုက်စေပါဘူး။ အချို့သော ဆောင်းပါးများသည် အချိန်မီ မွမ်းမံထားခြင်း သို့မဟုတ် အချို့သော မက်ဆေ့ချ်များသည် ကြေးနန်းစာသို့ မရောက်နိုင်သော်လည်း အကောင့်သည် သရုပ်ဆောင်အား ပြန်လည်စတင်ပြီး အရာအားလုံး ဆက်လက်လုပ်ဆောင်နေပါသည်။ ကြေးနန်းသရုပ်ဆောင်က မက်ဆေ့ချ်ကို အောင်မြင်စွာပေးပို့ပြီးမှသာ ဆောင်းပါးကို အသုံးပြုသူထံ ပြသထားသည့် အချက်အလက်ကို ကျွန်ုပ်သိမ်းဆည်းပါသည်။ ကျွန်ုပ်ကို ခြိမ်းခြောက်သည့် အဆိုးဆုံးမှာ မက်ဆေ့ချ်ကို အကြိမ်များစွာ ပေးပို့ခြင်း (၎င်းသည် ပေးပို့ပါက၊ သို့သော် အတည်ပြုချက်သည် တစ်နည်းနည်းဖြင့် ပျောက်ဆုံးသွားသည်)။ မူအရ၊ ပထမမင်းသားသည် သူ့ကိုယ်တွင်းရှိ အခြေအနေများကို မသိမ်းဆည်းဘဲ ဒေတာဘေ့စ်အချို့နှင့် ဆက်သွယ်မိပါက၊ သူလည်း မမြင်နိုင်လောက်အောင် ပြုတ်ကျပြီး အသက်ပြန်ရှင်လာနိုင်သည်။ သရုပ်ဆောင်တွေရဲ့ အခြေအနေကို ပြန်လည်ထိန်းသိမ်းဖို့ Akka ဇွဲရှိရှိနဲ့ ကြိုးစားနိုင်ပေမယ့် လက်ရှိအကောင်အထည်ဖော်မှုက ရိုးရှင်းမှုနဲ့ ကိုက်ညီပါတယ်။ ကျွန်ုပ်၏ကုဒ်သည် မကြာခဏ ပျက်သွားခြင်းမဟုတ်ပါ - ဆန့်ကျင်ဘက်အနေနှင့် မဖြစ်နိုင်အောင် ကြိုးပမ်းအားထုတ်မှုများစွာ ပြုလုပ်ခဲ့ပါသည်။ ဒါပေမယ့် အမိုက်စားဖြစ်သွားပြီး ပရိုဂရမ်ကို သီးခြားအပိုင်းပိုင်းအဖြစ် ခွဲထုတ်နိုင်မှုဟာ ကျွန်တော့်အတွက် တကယ်အဆင်ပြေပြီး လက်တွေ့ကျပုံပေါက်ပါတယ်။

ကုဒ်ကွဲသွားပါက ၎င်းအကြောင်းကို သင်ချက်ချင်းသိရှိနိုင်စေရန်အတွက် အဝိုင်း-ci ကို ကျွန်ုပ်ထည့်သွင်းထားပါသည်။ အနည်းဆုံး၊ ဆိုလိုသည်မှာ ကုဒ်ကို စုစည်းမှု ရပ်သွားသည်ဟု ဆိုလိုသည်။ အစကတော့ Travis ထည့်ချင်ပေမယ့် ခက်ရင်းမပါတဲ့ ကျွန်တော့်ပရောဂျက်တွေကိုပဲ ပြခဲ့တယ်။ ယေဘုယျအားဖြင့်၊ ဤအရာနှစ်ခုလုံးကို open repositories တွင် လွတ်လပ်စွာသုံးနိုင်သည်။

ရလဒ်များကို

နိုဝင်ဘာလရောက်နေပြီ။ ဘော့တ်ကို ရေးထားသည်၊ ကျွန်ုပ် ၎င်းကို လွန်ခဲ့သော နှစ်ပတ်က အသုံးပြုခဲ့ပြီး နှစ်သက်ပါသည်။ တိုးတက်ဖို့ စိတ်ကူးတွေရှိရင် ရေးပါ။ ငွေရှာရာမှာ အဓိကအချက်ကို ကျွန်တော် မမြင်ပါဘူး - အဲဒါကို အလုပ်လုပ်ပြီး စိတ်ဝင်စားစရာကောင်းတဲ့ ဆောင်းပါးတွေ ပို့လိုက်ပါ။

ဘော့တ်လင့်ခ်- https://t.me/HabraFilterBot
Github- https://github.com/Kright/habrahabr_reader

သေးငယ်သောကောက်ချက်

• ပရောဂျက်သေးသေးလေးမှာတောင် အချိန်အများကြီးယူရပါတယ်။
• သင်သည် Google မဟုတ်ပါ။ အမြောက်များမှ စာငှက်များကို ပစ်ခတ်ရာတွင် အဓိပ္ပါယ်မရှိပါ။ ရိုးရှင်းသော ဖြေရှင်းနည်းသည် လည်း အလုပ်ဖြစ်နိုင်သည်။
• အိမ်မွေးတိရစ္ဆာန်ပရောဂျက်များသည် နည်းပညာအသစ်များကို စမ်းသပ်ရန်အတွက် အလွန်ကောင်းမွန်ပါသည်။
• Telegram bot တွေကို ရိုးရိုးရှင်းရှင်းနဲ့ရေးထားတယ်။ "အဖွဲ့လိုက်လုပ်ဆောင်ခြင်း" နှင့် နည်းပညာဆိုင်ရာ စမ်းသပ်မှုများကြောင့်မဟုတ်ပါက၊ ဘော့တ်ကို တစ်ပတ် သို့မဟုတ် နှစ်ပတ်အတွင်း ရေးသားပြီးဖြစ်လိမ့်မည်။
• သရုပ်ဆောင်မော်ဒယ်သည် Multi-threading နှင့် fault-tolerant code တို့နှင့် ကောင်းမွန်စွာ လိုက်ဖက်သော စိတ်ဝင်စားစရာကောင်းသော အရာတစ်ခုဖြစ်သည်။
• ပွင့်လင်းရင်းမြစ်အသိုင်းအဝိုင်းက ခက်ရင်းခွတွေကို နှစ်သက်ရတဲ့ အရသာကို ခံစားမိမယ်ထင်တယ်။
• အပလီကေးရှင်းအခြေအနေသည် အပလီကေးရှင်းပျက်စီးခြင်း/ပြန်လည်စတင်ခြင်းအပေါ်တွင်မူတည်တော့မည်မဟုတ်သောကြောင့် ဒေတာဘေ့စ်များသည် ကောင်းမွန်သော်လည်း ဒေတာဘေ့စ်တစ်ခုနှင့်လုပ်ဆောင်ခြင်းသည် ကုဒ်ကိုရှုပ်ထွေးစေပြီး ဒေတာဖွဲ့စည်းပုံအပေါ် ကန့်သတ်ချက်များချမှတ်ထားသောကြောင့် ဒေတာဘေ့စ်များသည် ကောင်းမွန်ပါသည်။

source: www.habr.com