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

"क्यों?" की शैली में प्रश्नों के लिए एक पुराना लेख है - प्राकृतिक Geektimes - अंतरिक्ष क्लीनर बनाना ।

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

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

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

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

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

कटौती के तहत, कार्य सुविधाओं, लेखन प्रक्रिया और तकनीकी समाधान जैसे विवरण।

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

रिपोजिटरी: https://github.com/Kright/habrahabr_reader

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

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

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

बाहर की खिड़की गर्मियों की थी

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

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

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

एक दोस्त ने 27 जुलाई को भंडार का निर्माण किया, लेकिन कुछ और नहीं किया, इसलिए मैंने कोड लिखना शुरू कर दिया।

30 जुलाई

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

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

9 अगस्त

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

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

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

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

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

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

आम तौर पर, अक्का की तरह, इसके लिए कोई ज़रूरत नहीं थी, यह सिर्फ लेख के लिए अद्यतन को संग्रहीत करने और किसी भी विलय के बिना एक नया लेने के लिए संभव था, लेकिन मैं एक साहसिक सड़क के नेतृत्व में था।

12 अगस्त

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

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

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

केवल एक छोटा था लेकिन - राज्य कहीं भी कायम नहीं रहा।

सब गड़बड़ हो गया

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

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

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

सितंबर

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

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

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

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

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

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

एफ * आरके

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

परिणामस्वरूप वास्तुकला काफी सरल थी:

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

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

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

परिणाम

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

बॉट से लिंक: https://t.me/HabraFilterBot
गिथब: https://github.com/Kright/habrahabr_reader

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

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