🥇हैबर से लेखों के वैयक्तिकृत चयन के लिए टेलीग्राम बॉट

"क्यों?" जैसे प्रश्नों के लिए एक पुराना लेख है - नेचुरल गीकटाइम्स - अंतरिक्ष को स्वच्छ बनाना.

बहुत सारे लेख हैं, व्यक्तिपरक कारणों से उनमें से कुछ मुझे पसंद नहीं हैं, और कुछ, इसके विपरीत, छोड़ना अफ़सोस की बात है। मैं इस प्रक्रिया को अनुकूलित करना और समय बचाना चाहूंगा।

उपरोक्त लेख में इन-ब्राउज़र स्क्रिप्टिंग दृष्टिकोण का सुझाव दिया गया था, लेकिन निम्नलिखित कारणों से मुझे वास्तव में यह पसंद नहीं आया (भले ही मैंने इसे पहले भी इस्तेमाल किया हो):

आपके कंप्यूटर/फोन पर विभिन्न ब्राउज़रों के लिए, यदि संभव हो तो आपको इसे फिर से कॉन्फ़िगर करना होगा।
लेखकों द्वारा सख्त फ़िल्टरिंग हमेशा सुविधाजनक नहीं होती है।
उन लेखकों की समस्या हल नहीं हुई है जिनके लेख आप मिस नहीं करना चाहते, भले ही वे साल में एक बार प्रकाशित होते हों।

लेख रेटिंग के आधार पर साइट में निर्मित फ़िल्टरिंग हमेशा सुविधाजनक नहीं होती है, क्योंकि अत्यधिक विशिष्ट लेख, उनके मूल्य के बावजूद, मामूली रेटिंग प्राप्त कर सकते हैं।

प्रारंभ में, मैं एक आरएसएस फ़ीड (या यहां तक कि कई) उत्पन्न करना चाहता था, वहां केवल दिलचस्प चीजें छोड़ना चाहता था। लेकिन अंत में, यह पता चला कि आरएसएस पढ़ना बहुत सुविधाजनक नहीं लगता: किसी भी मामले में, किसी लेख पर टिप्पणी/वोट करने/इसे अपने पसंदीदा में जोड़ने के लिए, आपको ब्राउज़र से गुजरना होगा। इसीलिए मैंने एक टेलीग्राम बॉट लिखा जो मुझे व्यक्तिगत संदेश में दिलचस्प लेख भेजता है। टेलीग्राम स्वयं उनका सुंदर पूर्वावलोकन बनाता है, जो लेखक/रेटिंग/विचारों के बारे में जानकारी के साथ मिलकर काफी जानकारीपूर्ण लगता है।

कट के नीचे कार्य की विशेषताएं, लेखन प्रक्रिया और तकनीकी समाधान जैसे विवरण हैं।

संक्षेप में बॉट के बारे में

भंडार: https://github.com/Kright/habrahabr_reader

टेलीग्राम में बॉट: https://t.me/HabraFilterBot

उपयोगकर्ता टैग और लेखकों के लिए एक अतिरिक्त रेटिंग सेट करता है। उसके बाद, लेखों पर एक फ़िल्टर लागू किया जाता है - हैबे पर लेख की रेटिंग, लेखक की उपयोगकर्ता रेटिंग और टैग द्वारा उपयोगकर्ता रेटिंग का औसत जोड़ा जाता है। यदि राशि उपयोगकर्ता द्वारा निर्दिष्ट सीमा से अधिक है, तो लेख फ़िल्टर को पास कर देता है।

बॉट लिखने का एक अतिरिक्त लक्ष्य मनोरंजन और अनुभव प्राप्त करना था। इसके अलावा, मैंने नियमित रूप से खुद को यह याद दिलाया मैं गूगल नहीं हूं, और इसलिए कई चीजें यथासंभव सरलता से और यहां तक कि प्राथमिक रूप से भी की जाती हैं। हालाँकि, इससे बॉट लिखने की प्रक्रिया में तीन महीने लगने से नहीं रोका जा सका।

बाहर गर्मी का मौसम था

जुलाई समाप्त हो रहा था, और मैंने एक बॉट लिखने का फैसला किया। और अकेले नहीं, बल्कि एक दोस्त के साथ जो स्काला में महारत हासिल कर रहा था और उस पर कुछ लिखना चाहता था। शुरुआत आशाजनक लग रही थी - कोड को एक टीम द्वारा काटा जाएगा, कार्य आसान लग रहा था और मुझे लगा कि कुछ हफ़्ते या एक महीने में बॉट तैयार हो जाएगा।

इस तथ्य के बावजूद कि मैं स्वयं पिछले कुछ वर्षों से समय-समय पर चट्टान पर कोड लिख रहा हूं, आमतौर पर कोई भी इस कोड को नहीं देखता या देखता है: पालतू परियोजनाएं, कुछ विचारों का परीक्षण, डेटा प्रीप्रोसेसिंग, एफपी से कुछ अवधारणाओं में महारत हासिल करना। मुझे वास्तव में इस बात में दिलचस्पी थी कि एक टीम में लेखन कोड कैसा दिखता है, क्योंकि रॉक पर कोड बहुत अलग तरीकों से लिखा जा सकता है।

क्या जा सकता था इसलिए? हालाँकि, आइए चीजों में जल्दबाजी न करें।
जो कुछ भी होता है उसे प्रतिबद्ध इतिहास का उपयोग करके ट्रैक किया जा सकता है।

एक परिचित ने 27 जुलाई को एक रिपॉजिटरी बनाई, लेकिन कुछ और नहीं किया, इसलिए मैंने कोड लिखना शुरू कर दिया।

30 जुलाई

संक्षेप में: मैंने हैबर के आरएसएस फ़ीड का विश्लेषण लिखा।

com.github.pureconfig टाइपसेफ़ कॉन्फ़िगरेशन को सीधे केस क्लास में पढ़ने के लिए (यह बहुत सुविधाजनक साबित हुआ)
scala-xml xml पढ़ने के लिए: चूँकि शुरू में मैं rss फ़ीड के लिए अपना स्वयं का कार्यान्वयन लिखना चाहता था, और rss फ़ीड xml प्रारूप में है, इसलिए मैंने पार्सिंग के लिए इस लाइब्रेरी का उपयोग किया। दरअसल, RSS पार्सिंग भी सामने आई।
scalatest परीक्षणों के लिए. यहां तक कि छोटी परियोजनाओं के लिए भी, परीक्षण लिखने से समय की बचत होती है - उदाहरण के लिए, एक्सएमएल पार्सिंग को डीबग करते समय, इसे फ़ाइल में डाउनलोड करना, परीक्षण लिखना और त्रुटियों को ठीक करना बहुत आसान होता है। जब बाद में कुछ अजीब html को अमान्य utf-8 वर्णों के साथ पार्स करने में एक बग दिखाई दिया, तो इसे एक फ़ाइल में रखना और एक परीक्षण जोड़ना अधिक सुविधाजनक हो गया।
अक्का के अभिनेता। वस्तुतः, उनकी बिल्कुल भी आवश्यकता नहीं थी, लेकिन परियोजना मनोरंजन के लिए लिखी गई थी, मैं उन्हें आज़माना चाहता था। परिणामस्वरूप, मैं यह कहने के लिए तैयार हूं कि मुझे यह पसंद आया। ओओपी के विचार को दूसरी तरफ से देखा जा सकता है - ऐसे अभिनेता हैं जो संदेशों का आदान-प्रदान करते हैं। अधिक दिलचस्प बात यह है कि आप कोड को इस तरह से लिख सकते हैं (और लिखना चाहिए) कि संदेश न पहुंचे या संसाधित न हो (सामान्यतया, जब खाता एक ही कंप्यूटर पर चल रहा हो, तो संदेश खो नहीं जाना चाहिए)। सबसे पहले मैं अपना सिर खुजा रहा था और कोड में कचरा था और अभिनेता एक-दूसरे की सदस्यता ले रहे थे, लेकिन अंत में मैं एक सरल और सुरुचिपूर्ण वास्तुकला के साथ आने में कामयाब रहा। प्रत्येक एक्टर के अंदर के कोड को सिंगल-थ्रेडेड माना जा सकता है; जब एक एक्टर क्रैश हो जाता है, तो एसीसीए उसे पुनः आरंभ करता है - परिणाम एक काफी दोष-सहिष्णु प्रणाली है।

9 अगस्त

मैंने प्रोजेक्ट में जोड़ा scala-scrapper Habr से html पृष्ठों को पार्स करने के लिए (लेख रेटिंग, बुकमार्क की संख्या आदि जैसी जानकारी निकालने के लिए)।

और बिल्लियाँ. जो चट्टान में हैं.

फिर मैंने वितरित डेटाबेस के बारे में एक किताब पढ़ी, मुझे सीआरडीटी (संघर्ष-मुक्त प्रतिकृति डेटा प्रकार) का विचार पसंद आया, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), इसलिए मैंने हैब्रे पर लेख के बारे में जानकारी के लिए एक क्रमविनिमेय अर्धसमूह का एक प्रकार का वर्ग पोस्ट किया।

वास्तव में, यह विचार बहुत सरल है - हमारे पास ऐसे काउंटर हैं जो नीरस रूप से बदलते हैं। पदोन्नति की संख्या धीरे-धीरे बढ़ रही है, प्लसस की संख्या (साथ ही माइनस की संख्या) भी बढ़ रही है। यदि मेरे पास किसी लेख के बारे में जानकारी के दो संस्करण हैं, तो मैं उन्हें "एक में विलय" कर सकता हूं - जो काउंटर की स्थिति बड़ी होती है उसे अधिक प्रासंगिक माना जाता है।

सेमीग्रुप का अर्थ है कि किसी लेख के बारे में जानकारी वाली दो वस्तुओं को एक में विलय किया जा सकता है। कम्यूटेटिव का मतलब है कि आप ए + बी और बी + ए दोनों को मर्ज कर सकते हैं, परिणाम ऑर्डर पर निर्भर नहीं करता है, और अंत में नवीनतम संस्करण ही रहेगा। वैसे यहां साहचर्य भी है.

उदाहरण के लिए, जैसा कि योजना बनाई गई थी, आरएसएस ने पार्सिंग के बाद लेख के बारे में थोड़ी कमजोर जानकारी प्रदान की - व्यूज की संख्या जैसे मेट्रिक्स के बिना। फिर एक विशेष अभिनेता ने लेखों के बारे में जानकारी ली और इसे अद्यतन करने और पुराने संस्करण के साथ विलय करने के लिए html पृष्ठों पर चला गया।

सामान्यतया, जैसा कि अक्का में है, इसकी कोई आवश्यकता नहीं थी, आप बस लेख के लिए अपडेटडेट संग्रहीत कर सकते थे और बिना किसी मर्ज के एक नया ले सकते थे, लेकिन रोमांच की राह ने मुझे आगे बढ़ाया।

12 अगस्त

मैं अधिक स्वतंत्र महसूस करने लगा और केवल मनोरंजन के लिए, मैंने प्रत्येक चैट को एक अलग अभिनेता बना दिया। सैद्धांतिक रूप से, एक एक्टर का वजन लगभग 300 बाइट्स होता है और उन्हें लाखों में बनाया जा सकता है, इसलिए यह पूरी तरह से सामान्य दृष्टिकोण है। मुझे ऐसा लगता है कि समाधान काफी दिलचस्प निकला:

एक अभिनेता अक्का में टेलीग्राम सर्वर और संदेश प्रणाली के बीच एक सेतु था। उसने बस संदेश प्राप्त किए और उन्हें वांछित चैट अभिनेता को भेज दिया। चैट अभिनेता प्रत्युत्तर में कुछ वापस भेज सकता है - और इसे टेलीग्राम पर वापस भेज दिया जाएगा। जो बहुत सुविधाजनक था वह यह कि यह अभिनेता जितना संभव हो सके उतना सरल निकला और इसमें संदेशों का जवाब देने के लिए केवल तर्क शामिल थे। वैसे तो हर चैट में नए लेखों की जानकारी आती थी, लेकिन फिर भी मुझे इसमें कोई दिक्कत नजर नहीं आती.

सामान्य तौर पर, बॉट पहले से ही काम कर रहा था, संदेशों का जवाब दे रहा था, उपयोगकर्ता को भेजे गए लेखों की एक सूची संग्रहीत कर रहा था, और मैं पहले से ही सोच रहा था कि बॉट लगभग तैयार था। मैंने धीरे-धीरे लेखक के नाम और टैग को सामान्य करने ("sd f" को "s_d_f" से बदलने) जैसी छोटी सुविधाएँ जोड़ीं।

बस एक ही चीज़ बची थी छोटा लेकिन — राज्य कहीं भी नहीं बचा।

सबकुछ गलत हुआ

आपने देखा होगा कि मैंने बॉट अधिकतर अकेले ही लिखा है। तो, दूसरा भागीदार विकास में शामिल हो गया, और कोड में निम्नलिखित परिवर्तन दिखाई दिए:

MongoDB राज्य को संग्रहीत करता हुआ दिखाई दिया। उसी समय, प्रोजेक्ट में लॉग टूट गए, क्योंकि किसी कारण से मोंगा ने उन्हें स्पैम करना शुरू कर दिया और कुछ लोगों ने उन्हें विश्व स्तर पर बंद कर दिया।
टेलीग्राम में ब्रिज अभिनेता को पहचान से परे बदल दिया गया और उसने स्वयं संदेशों को पार्स करना शुरू कर दिया।
चैट के लिए अभिनेताओं को निर्दयतापूर्वक हटा दिया गया और उनकी जगह एक ऐसे अभिनेता को ले लिया गया जिसने एक ही बार में सभी चैट के बारे में सारी जानकारी छिपा दी। हर छींक से मुसीबत में फंस गया ये एक्टर! ठीक है, हां, जैसे किसी लेख के बारे में जानकारी अपडेट करते समय, इसे सभी चैट एक्टर्स को भेजना मुश्किल होता है (हम Google की तरह हैं, लाखों उपयोगकर्ता चैट में प्रत्येक के लिए लाखों लेखों की प्रतीक्षा कर रहे हैं), लेकिन हर बार चैट अपडेट की जाती है, मोंगा में जाना सामान्य बात है। जैसा कि मुझे बहुत बाद में एहसास हुआ, चैट का कामकाजी तर्क भी पूरी तरह से खत्म हो गया था और उसकी जगह कुछ ऐसा सामने आया जो काम नहीं करता था।
प्रकार की कक्षाओं का कोई निशान नहीं बचा है।
अभिनेताओं में एक-दूसरे के प्रति अपनी सदस्यता के साथ कुछ अस्वास्थ्यकर तर्क प्रकट हुए हैं, जिससे दौड़ की स्थिति पैदा हो गई है।
प्रकार के फ़ील्ड के साथ डेटा संरचनाएँ Option[Int] -1 जैसे जादुई डिफ़ॉल्ट मानों के साथ Int में बदल दिया गया। बाद में मुझे एहसास हुआ कि mongoDB json को स्टोर करता है और इसे वहां स्टोर करने में कुछ भी गलत नहीं है Option ठीक है, या कम से कम -1 को कोई नहीं के रूप में पार्स करें, लेकिन उस समय मुझे यह नहीं पता था और मैंने इसके लिए अपना शब्द मान लिया कि "ऐसा ही होना चाहिए।" मैंने वह कोड नहीं लिखा, और मैंने फिलहाल उसे बदलने की जहमत नहीं उठाई।
मुझे पता चला कि मेरा सार्वजनिक आईपी पता बदल जाता है, और हर बार मुझे इसे मोंगो की श्वेतसूची में जोड़ना पड़ा। मैंने स्थानीय स्तर पर बॉट लॉन्च किया, मोंगा एक कंपनी के रूप में मोंगा के सर्वर पर कहीं था।
अचानक, टेलीग्राम के लिए टैग और संदेश स्वरूपण का सामान्यीकरण गायब हो गया। (हम्म, ऐसा क्यों होगा?)
मुझे यह पसंद आया कि बॉट की स्थिति एक बाहरी डेटाबेस में संग्रहीत होती है, और पुनः आरंभ करने पर यह ऐसे काम करता रहता है जैसे कि कुछ हुआ ही न हो। हालाँकि, यह एकमात्र प्लस था।

दूसरा व्यक्ति कोई विशेष जल्दी में नहीं था, और ये सभी परिवर्तन सितंबर की शुरुआत में ही एक बड़े ढेर में दिखाई देने लगे। मैंने तुरंत परिणामी विनाश के पैमाने की सराहना नहीं की और डेटाबेस के काम को समझना शुरू कर दिया, क्योंकि... मैंने पहले कभी उनके साथ व्यवहार नहीं किया। मुझे बाद में ही एहसास हुआ कि कितना वर्किंग कोड काटा गया था और उसके स्थान पर कितने बग जोड़े गए थे।

सितंबर

पहले तो मैंने सोचा कि मोंगा पर महारत हासिल करना और इसे अच्छी तरह से करना उपयोगी होगा। फिर मुझे धीरे-धीरे समझ आने लगा कि डेटाबेस के साथ संचार व्यवस्थित करना भी एक कला है जिसमें आप बहुत सारी दौड़ लगा सकते हैं और गलतियाँ भी कर सकते हैं। उदाहरण के लिए, यदि उपयोगकर्ता को दो संदेश प्राप्त होते हैं जैसे /subscribe - और प्रत्येक के जवाब में हम तालिका में एक प्रविष्टि बनाएंगे, क्योंकि उन संदेशों को संसाधित करने के समय उपयोगकर्ता ने सदस्यता नहीं ली है। मुझे संदेह है कि मोंगा के साथ मौजूदा स्वरूप में संचार सर्वोत्तम तरीके से नहीं लिखा गया है। उदाहरण के लिए, उपयोगकर्ता की सेटिंग उसी समय बनाई गई थी जब उसने साइन अप किया था। यदि उसने सदस्यता के तथ्य से पहले उन्हें बदलने की कोशिश की... तो बॉट ने कुछ भी जवाब नहीं दिया, क्योंकि एक्टर में कोड सेटिंग्स के लिए डेटाबेस में गया, उसे नहीं मिला और क्रैश हो गया। जब मुझसे पूछा गया कि आवश्यकतानुसार सेटिंग्स क्यों नहीं बनाई गईं, तो मुझे पता चला कि यदि उपयोगकर्ता ने सदस्यता नहीं ली है तो उन्हें बदलने की कोई आवश्यकता नहीं है... संदेश फ़िल्टरिंग प्रणाली किसी तरह से गैर-स्पष्ट रूप से बनाई गई थी, और कोड को करीब से देखने के बाद भी मैं ऐसा कर सका समझ में नहीं आ रहा कि शुरुआत में इसका उद्देश्य यही था या इसमें कोई त्रुटि है।

चैट में सबमिट किए गए लेखों की कोई सूची नहीं थी; इसके बजाय, यह सुझाव दिया गया कि मैं उन्हें स्वयं लिखूं। इससे मुझे आश्चर्य हुआ - सामान्य तौर पर, मैं सभी प्रकार की चीजों को परियोजना में घसीटने के खिलाफ नहीं था, लेकिन यह उस व्यक्ति के लिए तर्कसंगत होगा जो इन चीजों को लाया और खराब कर दिया। लेकिन नहीं, दूसरे प्रतिभागी ने सब कुछ छोड़ दिया, लेकिन कहा कि चैट के अंदर की सूची कथित तौर पर एक खराब समाधान थी, और "एक लेख y उपयोगकर्ता x को भेजा गया था" जैसी घटनाओं के साथ एक संकेत बनाना आवश्यक था। फिर, यदि उपयोगकर्ता नए लेख भेजने का अनुरोध करता है, तो डेटाबेस को एक अनुरोध भेजना आवश्यक था, जो घटनाओं में से उपयोगकर्ता से संबंधित घटनाओं का चयन करेगा, नए लेखों की एक सूची भी प्राप्त करेगा, उन्हें फ़िल्टर करेगा, उपयोगकर्ता को भेजेगा और इसके बारे में घटनाओं को वापस डेटाबेस में डालें।

दूसरे प्रतिभागी को अमूर्तता की ओर कहीं ले जाया गया, जब बॉट को न केवल हैबर से लेख प्राप्त होंगे और न केवल टेलीग्राम पर भेजे जाएंगे।

मैंने किसी तरह सितंबर की दूसरी छमाही के लिए घटनाओं को एक अलग संकेत के रूप में लागू किया। यह इष्टतम नहीं है, लेकिन कम से कम बॉट ने काम करना शुरू कर दिया और मुझे फिर से लेख भेजना शुरू कर दिया, और मुझे धीरे-धीरे पता चला कि कोड में क्या हो रहा था।

अब आप शुरुआत में वापस जा सकते हैं और याद रख सकते हैं कि रिपॉजिटरी मूल रूप से मेरे द्वारा नहीं बनाई गई थी। ऐसा क्या हो सकता था? मेरा पुल अनुरोध अस्वीकार कर दिया गया. यह पता चला कि मेरे पास रेडनेक कोड था, मुझे नहीं पता था कि एक टीम में कैसे काम करना है, और मुझे वर्तमान कार्यान्वयन वक्र में बग को ठीक करना था, और इसे प्रयोग करने योग्य स्थिति में परिष्कृत नहीं करना था।

मैं परेशान हो गया और प्रतिबद्ध इतिहास और लिखे गए कोड की मात्रा पर ध्यान दिया। मैंने उन क्षणों को देखा जो मूल रूप से अच्छे से लिखे गए थे, और फिर टूटे हुए थे...

इसे बकवास करो

मुझे लेख याद आ गया आप Google नहीं हैं.

मैंने सोचा कि वास्तव में कार्यान्वयन के बिना किसी को भी किसी विचार की आवश्यकता नहीं है। मैंने सोचा कि मुझे एक कामकाजी बॉट चाहिए, जो एक साधारण जावा प्रोग्राम के रूप में एक ही कंप्यूटर पर एक ही कॉपी में काम करेगा। मुझे पता है कि मेरा बॉट बिना पुनरारंभ किए महीनों तक काम करेगा, क्योंकि मैं पहले भी ऐसे बॉट लिख चुका हूं। यदि यह अचानक गिर जाता है और उपयोगकर्ता को दूसरा लेख नहीं भेजता है, तो आसमान ज़मीन पर नहीं गिरेगा और कुछ भी विनाशकारी नहीं होगा।

यदि कोड बस काम नहीं करता है या टेढ़ा काम करता है तो मुझे डॉकर, मोंगोडीबी और "गंभीर" सॉफ़्टवेयर के अन्य कार्गो पंथ की आवश्यकता क्यों है?

मैंने प्रोजेक्ट छोड़ दिया और सब कुछ वैसा ही किया जैसा मैं चाहता था।

लगभग उसी समय, मैंने नौकरियाँ बदल दीं और खाली समय की अत्यधिक कमी हो गई। सुबह मैं ठीक ट्रेन में उठा, शाम को मैं देर से लौटा और अब कुछ नहीं करना चाहता था। कुछ देर तक मैंने कुछ नहीं किया, फिर बॉट को ख़त्म करने की इच्छा मुझ पर हावी हो गई और सुबह काम पर जाते समय मैंने धीरे-धीरे कोड को फिर से लिखना शुरू कर दिया। मैं यह नहीं कहूंगा कि यह उत्पादक था: अपनी गोद में लैपटॉप के साथ हिलती हुई ट्रेन पर बैठना और अपने फोन से स्टैक ओवरफ्लो को देखना बहुत सुविधाजनक नहीं है। हालाँकि, कोड लिखने में बिताया गया समय पूरी तरह से किसी का ध्यान नहीं गया और परियोजना धीरे-धीरे कार्यशील स्थिति की ओर बढ़ने लगी।

मेरे दिमाग में कहीं न कहीं संदेह का कीड़ा था जो mongoDB का उपयोग करना चाहता था, लेकिन मैंने सोचा कि "विश्वसनीय" राज्य भंडारण के फायदों के अलावा, ध्यान देने योग्य नुकसान भी थे:

डेटाबेस विफलता का एक और बिंदु बन जाता है।
कोड अधिक जटिल होता जा रहा है, और इसे लिखने में मुझे अधिक समय लगेगा।
कोड धीमा और अक्षम हो जाता है; मेमोरी में किसी ऑब्जेक्ट को बदलने के बजाय, परिवर्तन डेटाबेस में भेजे जाते हैं और यदि आवश्यक हो, तो वापस खींच लिया जाता है।
एक अलग तालिका में घटनाओं के भंडारण के प्रकार पर प्रतिबंध हैं, जो डेटाबेस की विशिष्टताओं से जुड़े हैं।
मोंगा के परीक्षण संस्करण की कुछ सीमाएँ हैं, और यदि आप उनका सामना करते हैं, तो आपको मोंगा को किसी चीज़ पर लॉन्च और कॉन्फ़िगर करना होगा।

मैंने मोंगा को काट दिया, अब बॉट की स्थिति को केवल प्रोग्राम की मेमोरी में संग्रहीत किया जाता है और समय-समय पर json के रूप में एक फ़ाइल में सहेजा जाता है। शायद टिप्पणियों में वे लिखेंगे कि मैं गलत हूं, डेटाबेस का उपयोग यहीं किया जाना चाहिए, आदि। लेकिन यह मेरा प्रोजेक्ट है, फ़ाइल के साथ दृष्टिकोण यथासंभव सरल है और यह पारदर्शी तरीके से काम करता है।

-1 जैसे जादुई मानों को बाहर फेंक दिया और सामान्य मान लौटा दिए Option, चैट जानकारी के साथ ऑब्जेक्ट पर वापस भेजे गए लेखों के साथ हैश तालिका का भंडारण जोड़ा गया। पांच दिन से अधिक पुराने लेखों के बारे में जानकारी हटाना जोड़ा गया, ताकि सब कुछ संग्रहीत न हो। मैं लॉगिंग को कार्यशील स्थिति में लाया - लॉग फ़ाइल और कंसोल दोनों में उचित मात्रा में लिखे गए हैं। कई व्यवस्थापक आदेश जोड़े गए जैसे स्थिति को सहेजना या उपयोगकर्ताओं और लेखों की संख्या जैसे आंकड़े प्राप्त करना।

छोटी-छोटी चीजों का एक समूह तय किया गया: उदाहरण के लिए, लेखों के लिए उपयोगकर्ता के फ़िल्टर को पारित करने के समय विचारों, पसंद, नापसंद और टिप्पणियों की संख्या अब इंगित की गई है। सामान्य तौर पर, यह आश्चर्य की बात है कि कितनी छोटी-छोटी चीजों को ठीक करना पड़ा। मैंने एक सूची रखी, वहां सभी "अनियमितताओं" को नोट किया और जहां तक संभव हो उन्हें ठीक किया।

उदाहरण के लिए, मैंने सभी सेटिंग्स को सीधे एक संदेश में सेट करने की क्षमता जोड़ी:

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

और दूसरी टीम /settings उन्हें बिल्कुल इसी रूप में प्रदर्शित करता है, आप उससे टेक्स्ट ले सकते हैं और सभी सेटिंग्स किसी मित्र को भेज सकते हैं।
यह एक छोटी सी बात लगती है, लेकिन इसमें दर्जनों समान बारीकियां हैं।

एक सरल रैखिक मॉडल के रूप में लेख फ़िल्टरिंग लागू की गई - उपयोगकर्ता लेखकों और टैग के लिए एक अतिरिक्त रेटिंग, साथ ही एक सीमा मूल्य निर्धारित कर सकता है। यदि लेखक की रेटिंग, टैग के लिए औसत रेटिंग और लेख की वास्तविक रेटिंग का योग सीमा मूल्य से अधिक है, तो लेख उपयोगकर्ता को दिखाया जाता है। आप या तो बॉट से /नया कमांड के साथ लेखों के लिए पूछ सकते हैं, या बॉट की सदस्यता ले सकते हैं और यह दिन के किसी भी समय व्यक्तिगत संदेश में लेख भेजेगा।

सामान्यतया, मेरे पास प्रत्येक लेख के लिए अधिक सुविधाएँ (हब, टिप्पणियों की संख्या, बुकमार्क, रेटिंग परिवर्तन की गतिशीलता, लेख में पाठ की मात्रा, चित्र और कोड, कीवर्ड) निकालने और उपयोगकर्ता को एक ओके/ दिखाने का विचार था। प्रत्येक लेख के अंतर्गत वोट देना और प्रत्येक उपयोगकर्ता के लिए एक मॉडल को प्रशिक्षित करना ठीक नहीं है, लेकिन मैं बहुत आलसी था।

इसके अलावा, कार्य का तर्क इतना स्पष्ट नहीं होगा। अब मैं मैन्युअल रूप से पेशेंटज़ीरो के लिए +9000 की रेटिंग सेट कर सकता हूं और +20 की थ्रेशोल्ड रेटिंग के साथ मुझे उसके सभी लेख प्राप्त करने की गारंटी होगी (जब तक कि, निश्चित रूप से, मैं कुछ टैग के लिए -100500 सेट नहीं करता)।

अंतिम वास्तुकला काफी सरल निकली:

एक अभिनेता जो सभी चैट और लेखों की स्थिति संग्रहीत करता है। यह डिस्क पर एक फ़ाइल से अपनी स्थिति लोड करता है और इसे समय-समय पर, हर बार एक नई फ़ाइल में सहेजता है।
एक अभिनेता जो समय-समय पर आरएसएस फ़ीड पर जाता है, नए लेखों के बारे में सीखता है, लिंक देखता है, विश्लेषण करता है और इन लेखों को पहले अभिनेता को भेजता है। इसके अलावा, यह कभी-कभी पहले अभिनेता से लेखों की एक सूची का अनुरोध करता है, उन लेखों का चयन करता है जो तीन दिन से अधिक पुराने नहीं हैं, लेकिन लंबे समय से अपडेट नहीं किए गए हैं, और उन्हें अपडेट करता है।
एक अभिनेता जो टेलीग्राम से संचार करता है। मैं अभी भी संदेश पार्सिंग को पूरी तरह से यहां लाया हूं। सौहार्दपूर्ण तरीके से, मैं इसे दो भागों में विभाजित करना चाहूंगा - ताकि एक आने वाले संदेशों को पार्स कर सके, और दूसरा परिवहन समस्याओं से निपट सके जैसे कि न भेजे गए संदेशों को फिर से भेजना। अब कोई दोबारा भेजना नहीं है, और एक संदेश जो किसी त्रुटि के कारण नहीं आया है वह बस खो जाएगा (जब तक कि यह लॉग में नोट न किया गया हो), लेकिन अभी तक इससे कोई समस्या नहीं हुई है। शायद समस्याएँ उत्पन्न होंगी यदि बहुत से लोग बॉट की सदस्यता लेते हैं और मैं संदेश भेजने की सीमा तक पहुँच जाता हूँ)।

मुझे जो पसंद आया वह यह है कि अक्का के लिए धन्यवाद, अभिनेता 2 और 3 के गिरने से आम तौर पर बॉट के प्रदर्शन पर कोई असर नहीं पड़ता है। शायद कुछ लेख समय पर अपडेट नहीं होते हैं या कुछ संदेश टेलीग्राम तक नहीं पहुंचते हैं, लेकिन खाता अभिनेता को पुनः आरंभ करता है और सब कुछ काम करता रहता है। मैं यह जानकारी सहेजता हूं कि लेख उपयोगकर्ता को तभी दिखाया जाता है जब टेलीग्राम अभिनेता जवाब देता है कि उसने संदेश सफलतापूर्वक वितरित कर दिया है। सबसे बुरी बात जो मुझे धमकी देती है वह है संदेश को कई बार भेजना (यदि यह वितरित हो गया है, लेकिन पुष्टि किसी तरह खो गई है)। सिद्धांत रूप में, यदि पहले अभिनेता ने राज्य को अपने भीतर संग्रहीत नहीं किया, लेकिन कुछ डेटाबेस के साथ संचार किया, तो वह भी अदृश्य रूप से गिर सकता था और जीवन में वापस आ सकता था। मैं अभिनेताओं की स्थिति को बहाल करने के लिए अक्का दृढ़ता का भी प्रयास कर सकता हूं, लेकिन वर्तमान कार्यान्वयन अपनी सादगी के कारण मेरे लिए उपयुक्त है। ऐसा नहीं है कि मेरा कोड अक्सर क्रैश हो जाता है - इसके विपरीत, मैंने इसे असंभव बनाने में काफी प्रयास किया है। लेकिन बकवास होती है, और कार्यक्रम को अलग-अलग टुकड़ों-अभिनेताओं में तोड़ने की क्षमता मुझे वास्तव में सुविधाजनक और व्यावहारिक लगी।

मैंने सर्कल-सीआई जोड़ा ताकि यदि कोड टूट जाए, तो आपको तुरंत इसके बारे में पता चल जाएगा। कम से कम, इसका मतलब है कि कोड का संकलन बंद हो गया है। प्रारंभ में मैं ट्रैविस को जोड़ना चाहता था, लेकिन इसने बिना कांटे के केवल मेरे प्रोजेक्ट दिखाए। सामान्य तौर पर, इन दोनों चीजों का उपयोग खुले रिपॉजिटरी में स्वतंत्र रूप से किया जा सकता है।

परिणाम

यह पहले से ही नवंबर है. बॉट पर लिखा है, मैं इसे पिछले दो हफ्ते से इस्तेमाल कर रहा हूं और मुझे यह पसंद आया। यदि आपके पास सुधार के विचार हैं तो लिखें। मुझे इससे कमाई करने का कोई मतलब नहीं दिखता - इसे बस काम करने दें और दिलचस्प लेख भेजें।

बॉट लिंक: https://t.me/HabraFilterBot
जीथूब: https://github.com/Kright/habrahabr_reader

छोटे निष्कर्ष:

यहां तक कि एक छोटे प्रोजेक्ट में भी काफी समय लग सकता है।
आप Google नहीं हैं. गौरैयों को तोप से दागने का कोई मतलब नहीं है. एक सरल समाधान भी काम कर सकता है.
नई तकनीकों के साथ प्रयोग करने के लिए पालतू परियोजनाएँ बहुत अच्छी हैं।
टेलीग्राम बॉट काफी सरलता से लिखे गए हैं। यदि यह "टीम वर्क" और प्रौद्योगिकी के साथ प्रयोग नहीं होता, तो बॉट एक या दो सप्ताह में लिखा गया होता।
अभिनेता मॉडल एक दिलचस्प चीज़ है जो मल्टी-थ्रेडिंग और दोष-सहिष्णु कोड के साथ अच्छी तरह से चलती है।
मुझे लगता है कि मुझे समझ आ गया कि ओपन सोर्स समुदाय को फोर्क्स क्यों पसंद हैं।
डेटाबेस अच्छे हैं क्योंकि एप्लिकेशन स्थिति अब एप्लिकेशन क्रैश/रीस्टार्ट पर निर्भर नहीं करती है, लेकिन डेटाबेस के साथ काम करने से कोड जटिल हो जाता है और डेटा संरचना पर प्रतिबंध लग जाता है।

स्रोत: www.habr.com

हैबर से लेखों के वैयक्तिकृत चयन के लिए टेलीग्राम बॉट