Habr बाट लेखहरूको व्यक्तिगत चयनको लागि टेलिग्राम बोट

"किन?" जस्ता प्रश्नहरूको लागि पुरानो लेख छ - प्राकृतिक Geektimes - स्पेस क्लिनर बनाउने.

त्यहाँ धेरै लेखहरू छन्, व्यक्तिपरक कारणहरूका लागि तिनीहरूमध्ये केही मलाई मनपर्दैन, र केही, यसको विपरित, यो छोड्नु दुखको कुरा हो। म यस प्रक्रियालाई अनुकूलन गर्न र समय बचत गर्न चाहन्छु।

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

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

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

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

काटिएको तल कामका विशेषताहरू, लेखन प्रक्रिया र प्राविधिक समाधानहरू जस्ता विवरणहरू छन्।

बटको बारेमा छोटकरीमा

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

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

प्रयोगकर्ताले ट्याग र लेखकहरूको लागि अतिरिक्त मूल्याङ्कन सेट गर्दछ। त्यस पछि, लेखहरूमा फिल्टर लागू हुन्छ - Habré मा लेखको मूल्याङ्कन, लेखकको प्रयोगकर्ता मूल्याङ्कन र ट्यागद्वारा प्रयोगकर्ता मूल्याङ्कनको लागि औसत थपिएको छ। यदि रकम प्रयोगकर्ता-निर्दिष्ट थ्रेसहोल्ड भन्दा ठूलो छ भने, लेखले फिल्टर पास गर्दछ।

बोट लेख्ने एक पक्ष लक्ष्य रमाईलो र अनुभव प्राप्त गर्नु थियो। साथै, म नियमित रूपमा आफैलाई सम्झाउँछु म Google होइन, र त्यसैले धेरै कुराहरू सम्भव भएसम्म सरल र प्राथमिक रूपमा पनि गरिन्छ। यद्यपि, यसले बोट लेख्ने प्रक्रियालाई तीन महिना लिनबाट रोक्न सकेन।

बाहिर गर्मी थियो

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

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

के हुन सक्थ्यो त्यसैले? यद्यपि, चीजहरू हतार नगरौं।
कमिट ईतिहास प्रयोग गरेर सबै कुरा ट्र्याक गर्न सकिन्छ।

एक परिचितले जुलाई 27 मा भण्डार सिर्जना गरे, तर अरू केहि गरेन, त्यसैले मैले कोड लेख्न थाले।

30 जुलाई

छोटकरीमा: मैले Habr को आरएसएस फीड को पार्सिङ लेखे।

• com.github.pureconfig टाइपसेफ कन्फिगहरू सीधा केस वर्गहरूमा पढ्नको लागि (यो धेरै सुविधाजनक भयो)
• scala-xml xml पढ्नको लागि: सुरुमा म आरएसएस फिडको लागि आफ्नै कार्यान्वयन लेख्न चाहन्थें, र आरएसएस फिड xml ढाँचामा छ, मैले यो पुस्तकालयलाई पार्सिङको लागि प्रयोग गरें। वास्तवमा, आरएसएस पार्सिङ पनि देखा पर्यो।
• 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é मा लेखको बारेमा जानकारीको लागि कम्युटेटिभ सेमिग्रुपको टाइप क्लास पोस्ट गरें।

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

एक अर्धसमूह को अर्थ एक लेख बारे जानकारी संग दुई वस्तु एक मा मर्ज गर्न सकिन्छ। कम्युटेटिभ भनेको तपाईले A + B र B + A दुबै मर्ज गर्न सक्नुहुन्छ, नतिजा अर्डरमा निर्भर हुँदैन, र अन्तमा नयाँ संस्करण रहनेछ। खैर, यहाँ संगतता पनि छ।

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

सामान्यतया भन्नुपर्दा, अक्कामा जस्तै, यसका लागि कुनै आवश्यकता थिएन, तपाईले लेखको लागि अपडेट मिति भण्डारण गर्न सक्नुहुनेछ र कुनै मर्ज बिना नयाँ लिन सक्नुहुनेछ, तर साहसिक बाटोले मलाई नेतृत्व गर्यो।

12 अगस्ट

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

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

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

एउटै कुरा बाँकी थियो सानो तर - राज्य कतै बचेको छैन।

सबै गलत भयो

तपाईंले याद गर्नुभएको होला कि मैले बोट प्रायः एक्लै लेखेको छु। त्यसोभए, दोस्रो सहभागी विकासमा संलग्न भयो, र निम्न परिवर्तनहरू कोडमा देखा पर्‍यो:

• MongoDB भण्डारण राज्य देखा पर्यो। उही समयमा, परियोजनामा ​​लगहरू भाँचिएका थिए, किनभने केही कारणका लागि मोंगाले तिनीहरूलाई स्प्याम गर्न थाले र केही मानिसहरूले तिनीहरूलाई विश्वव्यापी रूपमा बन्द गरे।
• टेलिग्राममा पुल अभिनेता पहिचान भन्दा बाहिर परिवर्तन भयो र सन्देशहरू पार्स गर्न थाले।
• च्याटका लागि अभिनेताहरूलाई निर्दयी रूपमा काटियो, र तिनीहरूको सट्टा एक अभिनेताद्वारा प्रतिस्थापित गरियो जसले सबै च्याटहरूको बारेमा सबै जानकारी एकैचोटि लुकायो। हरेक हाछ्युँका कारण यो अभिनेता समस्यामा परे । ठीक छ, हो, जस्तो कि कुनै लेखको बारेमा जानकारी अपडेट गर्दा, सबै च्याट अभिनेताहरूलाई पठाउन गाह्रो हुन्छ (हामी गुगल जस्तै छौं, लाखौं प्रयोगकर्ताहरू प्रत्येकको लागि च्याटमा लाखौं लेखहरू पर्खिरहेका छन्), तर हरेक पटक च्याट अपडेट हुन्छ, मोङ्गामा जानु सामान्य हो। मैले धेरै पछि महसुस गरेझैं, च्याटहरूको कार्य गर्ने तर्क पनि पूर्ण रूपमा काटिएको थियो र यसको ठाउँमा काम नगरेको कुरा देखा पर्‍यो।
• त्यहाँ टाइप कक्षाहरूको कुनै ट्रेस बाँकी छैन।
• एकअर्काको सदस्यता लिएर अभिनेताहरूमा केही अस्वस्थ तर्कहरू देखा परेका छन्, जसले दौड अवस्था निम्त्याउँछ।
• प्रकार को क्षेत्रहरु संग डाटा संरचना Option[Int] जादुई पूर्वनिर्धारित मानहरू जस्तै -1 सँग Int मा परिणत भयो। पछि मैले महसुस गरें कि mongoDB ले json भण्डार गर्दछ र त्यहाँ भण्डारण गर्नमा केहि गलत छैन Option राम्रो, वा कम्तिमा -1 को रूपमा पार्स गर्नुहोस्, तर त्यो समयमा मलाई यो थाहा थिएन र यसको लागि मेरो शब्द लिएको थियो कि "यस्तो हुनुपर्छ।" मैले त्यो कोड लेखेको छैन, र मैले यसलाई समयको लागि परिवर्तन गर्ने चिन्ता गर्दिन।
• मैले थाहा पाएँ कि मेरो सार्वजनिक IP ठेगाना परिवर्तन हुन्छ, र प्रत्येक पटक मैले यसलाई Mongo को श्वेतसूचीमा थप्नुपर्ने थियो। मैले स्थानीय रूपमा बोट सुरू गरें, मोंगा कतै कम्पनीको रूपमा मोंगाको सर्भरमा थियो।
• अचानक, टेलिग्रामको लागि ट्याग र सन्देश ढाँचाको सामान्यकरण गायब भयो। (हम्म, त्यो किन हुनेछ?)
• मलाई यो मनपर्यो कि बोटको अवस्था बाह्य डाटाबेसमा भण्डार गरिएको छ, र जब पुन: सुरु हुन्छ यसले काम गरिरहन्छ मानौं केहि भएको छैन। यद्यपि, यो मात्र प्लस थियो।

दोस्रो व्यक्ति कुनै विशेष हतारमा थिएन, र यी सबै परिवर्तनहरू सेप्टेम्बरको सुरुमा पहिले नै एउटा ठूलो थुप्रोमा देखा पर्‍यो। मैले तुरुन्तै परिणामस्वरूप विनाशको मापनको कदर गरेन र डाटाबेसको काम बुझ्न थाले, किनभने ... मैले उनीहरूसँग पहिले कहिल्यै व्यवहार गरेको छैन। पछि मात्र मैले महसुस गरें कि कति कार्य कोड काटिएको थियो र यसको स्थानमा कति बगहरू थपिएको थियो।

सेप्टेम्बर

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

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

दोस्रो सहभागीलाई अमूर्तता तिर कतै लगियो, जब बोटले Habr बाट लेखहरू मात्र प्राप्त गर्दैन र टेलिग्राममा मात्र पठाइने छैन।

मैले सेप्टेम्बरको दोस्रो आधाको लागि छुट्टै चिन्हको रूपमा घटनाहरू लागू गरें। यो इष्टतम छैन, तर कम्तिमा बोटले काम गर्न थाल्यो र मलाई फेरि लेखहरू पठाउन थाल्यो, र मैले बिस्तारै कोडमा के भइरहेको थियो भनेर बुझें।

अब तपाईं सुरुमा फर्कन सक्नुहुन्छ र सम्झनुहोस् कि भण्डार मूल रूपमा म द्वारा सिर्जना गरिएको थिएन। यसरी के हुन सक्थ्यो र ? मेरो पुल अनुरोध अस्वीकार गरियो। यो पत्ता लाग्यो कि मसँग रेडनेक कोड छ, कि मलाई टोलीमा कसरी काम गर्ने भनेर थाहा थिएन, र मैले हालको कार्यान्वयन कर्भमा बगहरू समाधान गर्नुपर्‍यो, र यसलाई प्रयोगयोग्य अवस्थामा परिमार्जन गर्नुपर्दैन।

म विचलित भएँ र कमिट ईतिहास र लेखिएको कोडको मात्रा हेरे। मैले पलहरू हेरे जुन मूल रूपमा राम्रोसँग लेखिएको थियो, र त्यसपछि फेरि भाँचिएको थियो ...

F*rk यसलाई

लेख याद आयो तपाईं Google हुनुहुन्न.

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

यदि कोडले मात्र काम गर्दैन वा कुटिल रूपमा काम गर्दैन भने मलाई किन डकर, मोन्गोडीबी र "गम्भीर" सफ्टवेयरको अन्य कार्गो कल्ट चाहिन्छ?

मैले परियोजनालाई फोर्क गरें र मैले चाहे अनुसार सबै गरें।

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

मेरो दिमागको पछाडि कतै शंकाको कीरा थियो जुन मोन्गोडीबी प्रयोग गर्न चाहान्छ, तर मैले सोचे कि "भरोसेमंद" राज्य भण्डारणका फाइदाहरू बाहेक, त्यहाँ उल्लेखनीय बेफाइदाहरू थिए:

• डाटाबेस असफलताको अर्को बिन्दु हुन्छ।
• कोड थप जटिल हुँदै गइरहेको छ, र यसले मलाई यो लेख्न लामो समय लिनेछ।
• कोड ढिलो र अक्षम हुन्छ; मेमोरीमा वस्तु परिवर्तन गर्नुको सट्टा, परिवर्तनहरू डाटाबेसमा पठाइन्छ र आवश्यक भएमा, फिर्ता तानिन्छ।
• त्यहाँ छुट्टै तालिकामा घटनाहरूको भण्डारण प्रकारमा प्रतिबन्धहरू छन्, जुन डेटाबेसको विशेषताहरूसँग सम्बन्धित छन्।
• मोन्गाको परीक्षण संस्करणमा केही सीमितताहरू छन्, र यदि तपाइँ ती मा दौडिनुभयो भने, तपाइँले केहिमा मोंगा सुरु र कन्फिगर गर्नुपर्नेछ।

मैले मोंगा काटें, अब बोटको अवस्था केवल प्रोग्रामको मेमोरीमा भण्डार गरिएको छ र समय-समयमा 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 सेट गरें)।

अन्तिम वास्तुकला एकदम सरल भयो:

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

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

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

परिणामहरू

यो नोभेम्बर पहिले नै छ। बोटमा लेखिएको छ, म यसलाई पछिल्लो दुई हप्तादेखि प्रयोग गर्दैछु र मलाई यो मन पर्यो। यदि तपाइँसँग सुधारको लागि विचार छ भने, लेख्नुहोस्। म यसलाई मुद्रीकरण गर्ने बिन्दु देख्दिन - यसलाई काम गर्न दिनुहोस् र रोचक लेखहरू पठाउनुहोस्।

बट लिङ्क: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

सानो निष्कर्ष:

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

स्रोत: www.habr.com