روبوت Telegram لمجموعة مختارة مخصصة من المقالات من حبر

لأسئلة مثل "لماذا؟" هناك مقالة قديمة - Geektimes الطبيعية - جعل الفضاء أنظف.

هناك الكثير من المقالات، لأسباب ذاتية، بعضها لا يعجبني، وبعضها، على العكس من ذلك، من المؤسف أن أتخطيها. أرغب في تحسين هذه العملية وتوفير الوقت.

اقترحت المقالة أعلاه أسلوب البرمجة النصية داخل المتصفح، لكني لم أحبه حقًا (على الرغم من أنني استخدمته من قبل) للأسباب التالية:

• بالنسبة للمتصفحات المختلفة على جهاز الكمبيوتر/الهاتف الخاص بك، يجب عليك تكوينها مرة أخرى، إذا كان ذلك ممكنًا.
• التصفية الصارمة من قبل المؤلفين ليست مريحة دائمًا.
• مشكلة المؤلفين الذين لا تريد أن تفوت مقالاتهم، حتى لو كانت تنشر مرة واحدة في السنة، لم يتم حلها.

إن التصفية المضمنة في الموقع بناءً على تصنيفات المقالات ليست مريحة دائمًا، نظرًا لأن المقالات المتخصصة للغاية، على الرغم من قيمتها، يمكن أن تحصل على تصنيف متواضع إلى حد ما.

في البداية، كنت أرغب في إنشاء موجز RSS (أو حتى عدة قنوات)، مع ترك الأشياء المثيرة للاهتمام فقط هناك. ولكن في النهاية، اتضح أن قراءة RSS لا تبدو مريحة للغاية: على أي حال، للتعليق/التصويت لمقال/إضافته إلى المفضلة لديك، عليك المرور عبر المتصفح. لهذا السبب قمت بكتابة روبوت برقية يرسل لي مقالات مثيرة للاهتمام في رسالة شخصية. يقوم Telegram نفسه بعمل معاينات جميلة منها، والتي، إلى جانب المعلومات حول المؤلف/التقييم/المشاهدات، تبدو مفيدة للغاية.

يوجد أسفل القطع تفاصيل مثل ميزات العمل وعملية الكتابة والحلول التقنية.

باختصار عن البوت

مخزن: https://github.com/Kright/habrahabr_reader

البوت في التليجرام: https://t.me/HabraFilterBot

يقوم المستخدم بتعيين تصنيف إضافي للعلامات والمؤلفين. بعد ذلك، يتم تطبيق مرشح على المقالات - تتم إضافة تقييم المقالة على حبري وتقييم المستخدم للمؤلف ومتوسط ​​تقييمات المستخدم حسب العلامة. إذا كان المبلغ أكبر من الحد الذي حدده المستخدم، فستقوم المقالة بتمرير عامل التصفية.

كان الهدف الجانبي لكتابة الروبوت هو اكتساب المتعة والخبرة. بالإضافة إلى ذلك، كنت أذكّر نفسي بذلك بانتظام أنا لست جوجل، وبالتالي يتم تنفيذ العديد من الأشياء ببساطة وحتى بشكل بدائي قدر الإمكان. لكن هذا لم يمنع أن تستغرق عملية كتابة البوت ثلاثة أشهر.

كان الصيف في الخارج

كان شهر يوليو على وشك الانتهاء، وقررت أن أكتب روبوتًا. وليس وحده، بل مع صديق كان يتقن السكالا وأراد أن يكتب شيئًا عليها. بدت البداية واعدة - سيتم قص الكود بواسطة فريق، وبدت المهمة سهلة واعتقدت أن الروبوت سيكون جاهزًا في غضون أسبوعين أو شهر.

على الرغم من أنني كنت أكتب التعليمات البرمجية على الصخرة من وقت لآخر خلال السنوات القليلة الماضية، لا أحد عادة يرى أو ينظر إلى هذا الرمز: مشاريع الحيوانات الأليفة، واختبار بعض الأفكار، ومعالجة البيانات مسبقًا، وإتقان بعض المفاهيم من FP. لقد كنت مهتمًا حقًا بما تبدو عليه كتابة التعليمات البرمجية في الفريق، لأن التعليمات البرمجية على موسيقى الروك يمكن كتابتها بطرق مختلفة جدًا.

ما كان يمكن أن يذهب هكذا؟ ومع ذلك، دعونا لا نتعجل الأمور.
يمكن تتبع كل ما يحدث باستخدام سجل الالتزام.

أنشأ أحد معارفي مستودعًا في 27 يوليو، لكنه لم يفعل شيئًا آخر، لذلك بدأت في كتابة التعليمات البرمجية.

يوليو 30

باختصار: لقد كتبت تحليلًا لخلاصة RSS الخاصة بـ حبر.

• com.github.pureconfig لقراءة تكوينات typesafe مباشرة في فئات الحالة (تبين أنها مريحة للغاية)
• scala-xml لقراءة XML: منذ أن أردت في البداية أن أكتب تطبيقي الخاص لخلاصة RSS، وكانت خلاصة RSS بتنسيق XML، فقد استخدمت هذه المكتبة للتحليل. في الواقع، ظهر أيضًا تحليل RSS.
• scalatest للاختبارات. حتى بالنسبة للمشاريع الصغيرة، فإن كتابة الاختبارات توفر الوقت - على سبيل المثال، عند تصحيح أخطاء تحليل XML، يكون تنزيله إلى ملف أسهل بكثير وكتابة الاختبارات وتصحيح الأخطاء. عندما ظهر خطأ لاحقًا في تحليل بعض html الغريب بأحرف utf-8 غير الصالحة، فقد أصبح أكثر ملاءمة لوضعه في ملف وإضافة اختبار.
• ممثلين من عكا. بموضوعية، لم تكن هناك حاجة إليها على الإطلاق، لكن المشروع مكتوب من أجل المتعة، أردت تجربتها. ونتيجة لذلك، أنا على استعداد لأقول أنني أحببت ذلك. يمكن النظر إلى فكرة OOP من الجانب الآخر - فهناك ممثلون يتبادلون الرسائل. الأمر الأكثر إثارة للاهتمام هو أنه يمكنك (ويجب عليك) كتابة التعليمات البرمجية بطريقة قد لا تصل الرسالة أو قد لا تتم معالجتها (بشكل عام، عندما يتم تشغيل الحساب على جهاز كمبيوتر واحد، لا ينبغي فقدان الرسائل). في البداية كنت في حيرة من أمري وكان هناك قمامة في الكود مع الممثلين المشتركين مع بعضهم البعض، ولكن في النهاية تمكنت من التوصل إلى بنية بسيطة وأنيقة إلى حد ما. يمكن اعتبار الكود الموجود داخل كل ممثل خيطًا واحدًا؛ فعندما يتعطل أحد الممثلين، تقوم جمعية المحاسبين القانونيين المعتمدين بإعادة تشغيله - والنتيجة هي نظام متسامح مع الأخطاء إلى حد ما.

9 أغسطس

أضفت إلى المشروع scala-scrapper لتحليل صفحات html من حبر (لاستخراج معلومات مثل تصنيف المقالة وعدد الإشارات المرجعية وما إلى ذلك).

والقطط. تلك التي في الصخر.

قرأت بعد ذلك كتابًا عن قواعد البيانات الموزعة، وأعجبتني فكرة CRDT (نوع البيانات المنسوخة الخالية من النزاعات، https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, هابر)، لذلك قمت بنشر فئة من مجموعة شبه تبادلية للحصول على معلومات حول المقالة عن حبري.

في الواقع، الفكرة بسيطة للغاية - لدينا عدادات تتغير بشكل رتيب. يتزايد عدد العروض الترويجية تدريجيًا، وكذلك عدد الإيجابيات (وكذلك عدد السلبيات). إذا كان لدي نسختان من المعلومات حول مقال ما، فيمكنني "دمجهما في واحدة" - تعتبر حالة العداد الأكبر حجمًا أكثر صلة.

تعني المجموعة النصفية أنه يمكن دمج كائنين يحتويان على معلومات حول مقال في كائن واحد. التبادلية تعني أنه يمكنك دمج كل من A + B و B + A، والنتيجة لا تعتمد على الترتيب، وفي النهاية سيبقى الإصدار الأحدث. بالمناسبة، هناك أيضًا ترابط هنا.

على سبيل المثال، كما هو مخطط له، قدمت خدمة RSS بعد التحليل معلومات ضعيفة قليلاً حول المقالة - بدون مقاييس مثل عدد المشاهدات. ثم أخذ ممثل خاص معلومات حول المقالات وتوجه إلى صفحات html لتحديثها ودمجها مع الإصدار القديم.

بشكل عام، كما هو الحال في عكا، لم تكن هناك حاجة لذلك، يمكنك ببساطة تخزين تاريخ التحديث للمقالة وأخذ تاريخ أحدث دون أي دمج، لكن طريق المغامرة قادني.

12 أغسطس

بدأت أشعر بمزيد من الحرية، ومن أجل المتعة فقط، جعلت كل محادثة ممثلًا منفصلاً. من الناحية النظرية، يزن الممثل نفسه حوالي 300 بايت ويمكن إنشاؤه بالملايين، لذلك يعد هذا أسلوبًا طبيعيًا تمامًا. يبدو لي أن الحل مثير للاهتمام للغاية:

أحد الممثلين كان بمثابة جسر بين خادم التلغرام ونظام الرسائل في عكا. لقد تلقى ببساطة رسائل وأرسلها إلى ممثل الدردشة المطلوب. يمكن لممثل الدردشة أن يرسل شيئًا ما ردًا على ذلك - وسيتم إرساله مرة أخرى إلى البرقية. ما كان مريحًا للغاية هو أن هذا الممثل تبين أنه بسيط قدر الإمكان ويحتوي فقط على منطق الرد على الرسائل. بالمناسبة، وصلت معلومات حول المقالات الجديدة إلى كل دردشة، ولكن مرة أخرى لا أرى أي مشاكل في هذا.

بشكل عام، كان الروبوت يعمل بالفعل، ويستجيب للرسائل، ويخزن قائمة بالمقالات المرسلة إلى المستخدم، وكنت أعتقد بالفعل أن الروبوت جاهز تقريبًا. أضفت ببطء ميزات صغيرة مثل تطبيع أسماء المؤلفين وعلاماتهم (استبدال "sd f" بـ "s_d_f").

لم يتبق سوى شيء واحد صغيرة ولكن — لم يتم إنقاذ الدولة في أي مكان.

كل شيء سار على نحو خاطئ

ربما لاحظت أنني كتبت الروبوت في الغالب بمفردي. لذلك، شارك المشارك الثاني في التطوير، وظهرت التغييرات التالية في الكود:

• يبدو أن MongoDB يخزن الحالة. في الوقت نفسه، تعطلت السجلات الموجودة في المشروع، لأنه لسبب ما، بدأ Monga بإرسال رسائل غير مرغوب فيها وقام بعض الأشخاص بإيقاف تشغيلها على مستوى العالم.
• تحول ممثل الجسر في Telegram إلى درجة لا يمكن التعرف عليها وبدأ في تحليل الرسائل بنفسه.
• تم قطع الممثلين عن المحادثات بلا رحمة، وبدلاً من ذلك تم استبدالهم بممثل قام بإخفاء جميع المعلومات حول جميع الدردشات في وقت واحد. مقابل كل عطسة، وقع هذا الممثل في ورطة. حسنًا، نعم، كما هو الحال عند تحديث معلومات حول مقال ما، يكون إرسالها إلى جميع الجهات الفاعلة في الدردشة أمرًا صعبًا (نحن مثل Google، ينتظر ملايين المستخدمين مليون مقال في الدردشة لكل منهم)، ولكن في كل مرة يتم تحديث الدردشة، من الطبيعي الذهاب إلى مونجا. وكما أدركت لاحقًا، تم أيضًا قطع منطق عمل الدردشات تمامًا وظهر مكانه شيء لا يعمل.
• لا يوجد أي أثر متبقي لفئات النوع.
• لقد ظهر بعض المنطق غير الصحي لدى الممثلين باشتراكاتهم مع بعضهم البعض، مما أدى إلى حالة عرقية.
• هياكل البيانات مع حقول النوع Option[Int] تم تحويله إلى Int بقيم افتراضية سحرية مثل -1. أدركت لاحقًا أن mongoDB يخزن json ولا حرج في تخزينه هناك Option حسنًا، أو على الأقل قم بتحليل -1 على أنه لا شيء، ولكن في ذلك الوقت لم أكن أعرف ذلك وأخذت كلمتي على محمل الجد بأن "هكذا ينبغي أن يكون الأمر." لم أكتب هذا الرمز، ولم أزعج نفسي بتغييره في الوقت الحالي.
• اكتشفت أن عنوان IP العام الخاص بي يميل إلى التغيير، وفي كل مرة كان علي إضافته إلى القائمة البيضاء لـ Mongo. لقد أطلقت الروبوت محليًا، وكانت Monga موجودة في مكان ما على خوادم Monga كشركة.
• فجأة، اختفى تطبيع العلامات وتنسيق الرسائل للبرقيات. (هم، لماذا يكون ذلك؟)
• أعجبني أن حالة الروبوت مخزنة في قاعدة بيانات خارجية، وعند إعادة تشغيله يستمر في العمل وكأن شيئًا لم يحدث. ومع ذلك، كانت هذه الميزة الوحيدة.

لم يكن الشخص الثاني في عجلة من أمره، وظهرت كل هذه التغييرات في كومة واحدة كبيرة بالفعل في بداية سبتمبر. لم أقدر على الفور حجم الدمار الناتج وبدأت في فهم عمل قاعدة البيانات، لأن... ولم أتعامل معهم من قبل. في وقت لاحق فقط أدركت مقدار كود العمل الذي تم قطعه وعدد الأخطاء التي تمت إضافتها مكانها.

سبتمبر

في البداية اعتقدت أنه سيكون من المفيد إتقان المونجا والقيام بها بشكل جيد. ثم بدأت أفهم ببطء أن تنظيم الاتصال بقاعدة البيانات هو أيضًا فن يمكنك من خلاله إجراء الكثير من السباقات وارتكاب الأخطاء. على سبيل المثال، إذا تلقى المستخدم رسالتين مثل /subscribe - وردا على كل واحد سوف نقوم بإنشاء إدخال في الجدول، لأنه في وقت معالجة تلك الرسائل لم يكن المستخدم مشتركا. لدي شك في أن التواصل مع Monga بشكله الحالي ليس مكتوبًا بأفضل طريقة. على سبيل المثال، تم إنشاء إعدادات المستخدم في لحظة قيامه بالتسجيل. إذا حاول تغييرها قبل الاشتراك... لم يستجب الروبوت لأي شيء، لأن الكود الموجود في الممثل دخل إلى قاعدة البيانات للإعدادات، ولم يجده وتحطم. عندما سئلت عن سبب عدم إنشاء الإعدادات حسب الحاجة، تعلمت أنه ليست هناك حاجة لتغييرها إذا لم يكن المستخدم مشتركًا... تم إنشاء نظام تصفية الرسائل بطريقة غير واضحة، وحتى بعد إلقاء نظرة فاحصة على الكود، تمكنت من ذلك لا أفهم ما إذا كان المقصود بهذه الطريقة في البداية أم أن هناك خطأ هناك.

لم تكن هناك قائمة بالمقالات المقدمة إلى الدردشة، وبدلاً من ذلك، اقترح أن أكتبها بنفسي. لقد فاجأني هذا - بشكل عام، لم أكن ضد جر كل أنواع الأشياء إلى المشروع، ولكن سيكون من المنطقي بالنسبة للشخص الذي جلب هذه الأشياء وأفسدها. لكن لا، يبدو أن المشارك الثاني قد تخلى عن كل شيء، لكنه قال إن القائمة داخل الدردشة من المفترض أنها حل سيئ، وكان من الضروري عمل إشارة بأحداث مثل "تم إرسال مقال y إلى المستخدم x". ومن ثم، إذا طلب المستخدم إرسال مقالات جديدة، كان من الضروري إرسال طلب إلى قاعدة البيانات، والتي ستقوم باختيار الأحداث المتعلقة بالمستخدم من الأحداث، وكذلك الحصول على قائمة بالمقالات الجديدة، وتصفيتها، وإرسالها إلى المستخدم ورمي الأحداث المتعلقة بهذا مرة أخرى إلى قاعدة البيانات.

تم نقل المشارك الثاني بعيدًا في مكان ما نحو التجريد، عندما لا يتلقى الروبوت مقالات من حبر فقط، وسيتم إرساله ليس فقط إلى البرقية.

لقد قمت بطريقة ما بتنفيذ الأحداث على شكل علامة منفصلة للنصف الثاني من شهر سبتمبر. هذا ليس الحل الأمثل، ولكن على الأقل بدأ الروبوت في العمل وبدأ في إرسال المقالات لي مرة أخرى، واكتشفت ببطء ما كان يحدث في الكود.

يمكنك الآن العودة إلى البداية وتذكر أن المستودع لم يتم إنشاؤه بواسطتي في الأصل. ما الذي يمكن أن يحدث بهذه الطريقة؟ تم رفض طلب السحب الخاص بي. اتضح أنه كان لدي كود متخلف، ولم أكن أعرف كيفية العمل ضمن فريق، وكان علي إصلاح الأخطاء في منحنى التنفيذ الحالي، وليس تحسينه إلى حالة قابلة للاستخدام.

لقد انزعجت ونظرت إلى سجل الالتزام وكمية التعليمات البرمجية المكتوبة. نظرت إلى اللحظات التي كانت مكتوبة بشكل جيد في الأصل، ثم تم كسرها مرة أخرى...

اللعنة عليه

تذكرت المقال أنت لست جوجل.

اعتقدت أنه لا أحد يحتاج حقًا إلى فكرة دون تنفيذها. اعتقدت أنني أريد أن يكون لدي روبوت عامل، والذي سيعمل في نسخة واحدة على جهاز كمبيوتر واحد كبرنامج جافا بسيط. أعلم أن الروبوت الخاص بي سيعمل لعدة أشهر دون إعادة تشغيل، حيث أنني قمت بالفعل بكتابة مثل هذه الروبوتات في الماضي. إذا سقط فجأة ولم يرسل للمستخدم مقالًا آخر، فلن تسقط السماء على الأرض ولن يحدث شيء كارثي.

لماذا أحتاج إلى Docker وmongoDB وغيرهما من البرامج "الجادة" إذا كانت التعليمات البرمجية ببساطة لا تعمل أو تعمل بشكل ملتوي؟

لقد تشعبت المشروع وفعلت كل شيء كما أردت.

في نفس الوقت تقريبًا، قمت بتغيير وظيفتي وأصبح وقت الفراغ ناقصًا للغاية. في الصباح، استيقظت مباشرة في القطار، في المساء عدت متأخرا ولم أعد أرغب في فعل أي شيء. لم أفعل شيئًا لفترة من الوقت، ثم تغلبت علي الرغبة في إنهاء الروبوت، وبدأت في إعادة كتابة الكود ببطء بينما كنت أقود سيارتي إلى العمل في الصباح. لن أقول إن الأمر كان مثمرًا: إن الجلوس على قطار مهتز وجهاز كمبيوتر محمول على حجرك والنظر إلى تجاوز سعة المكدس من هاتفك ليس أمرًا مريحًا للغاية. ومع ذلك، فإن الوقت الذي يقضيه في كتابة التعليمات البرمجية مر دون أن يلاحظه أحد تمامًا، وبدأ المشروع في التحرك ببطء نحو حالة العمل.

في مكان ما في الجزء الخلفي من ذهني، كانت هناك دودة من الشك حول رغبتي في استخدام mongoDB، لكنني اعتقدت أنه بالإضافة إلى مزايا تخزين الحالة "الموثوق"، هناك عيوب ملحوظة:

• تصبح قاعدة البيانات نقطة فشل أخرى.
• أصبح الكود أكثر تعقيدًا، وسوف يستغرق الأمر وقتًا أطول لكتابته.
• تصبح التعليمات البرمجية بطيئة وغير فعالة؛ فبدلاً من تغيير كائن في الذاكرة، يتم إرسال التغييرات إلى قاعدة البيانات، وإذا لزم الأمر، يتم سحبها مرة أخرى.
• هناك قيود على نوع تخزين الأحداث في جدول منفصل، والتي ترتبط بخصائص قاعدة البيانات.
• يحتوي الإصدار التجريبي من Monga على بعض القيود، وإذا واجهتها، فسيتعين عليك تشغيل Monga وتكوينه على شيء ما.

لقد قمت بقطع المونجا، والآن يتم تخزين حالة الروبوت ببساطة في ذاكرة البرنامج ويتم حفظها من وقت لآخر في ملف على شكل json. ربما سيكتبون في التعليقات أنني مخطئ، وأن هذا هو المكان الذي يجب أن تستخدم فيه قاعدة البيانات، وما إلى ذلك. لكن هذا هو مشروعي، أسلوب التعامل مع الملف بسيط قدر الإمكان ويعمل بطريقة شفافة.

تخلص من القيم السحرية مثل -1 وأعاد القيم الطبيعية Optionتمت إضافة مساحة تخزين لجدول التجزئة مع المقالات المرسلة مرة أخرى إلى الكائن مع معلومات الدردشة. تمت إضافة حذف المعلومات حول المقالات الأقدم من خمسة أيام، حتى لا يتم تخزين كل شيء. لقد قمت بإحضار التسجيل إلى حالة العمل - تتم كتابة السجلات بكميات معقولة لكل من الملف ووحدة التحكم. تمت إضافة العديد من أوامر الإدارة مثل حفظ الحالة أو الحصول على إحصائيات مثل عدد المستخدمين والمقالات.

تم إصلاح مجموعة من الأشياء الصغيرة: على سبيل المثال، بالنسبة للمقالات، يتم الآن الإشارة إلى عدد المشاهدات والإعجابات وعدم الإعجاب والتعليقات في وقت تمرير مرشح المستخدم. بشكل عام، من المثير للدهشة عدد الأشياء الصغيرة التي كان لا بد من تصحيحها. لقد احتفظت بقائمة، ولاحظت جميع "المخالفات" هناك وقمت بتصحيحها قدر الإمكان.

على سبيل المثال، أضفت إمكانية ضبط كافة الإعدادات مباشرة في رسالة واحدة:

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

وفريق آخر /settings يعرضها بالضبط في هذا النموذج، يمكنك أخذ النص منه وإرسال جميع الإعدادات إلى صديق.
يبدو وكأنه شيء صغير، ولكن هناك العشرات من الفروق الدقيقة المماثلة.

تم تنفيذ تصفية المقالات في شكل نموذج خطي بسيط - يمكن للمستخدم تعيين تصنيف إضافي للمؤلفين والعلامات، بالإضافة إلى قيمة العتبة. إذا كان مجموع تقييم المؤلف ومتوسط ​​التقييم للعلامات والتقييم الفعلي للمقالة أكبر من قيمة العتبة، فسيتم عرض المقالة للمستخدم. يمكنك إما أن تطلب من الروبوت مقالات باستخدام الأمر /new، أو الاشتراك في الروبوت وسيقوم بإرسال المقالات في رسالة شخصية في أي وقت من اليوم.

بشكل عام، كانت لدي فكرة لكل مقالة لسحب المزيد من الميزات (المحاور، وعدد التعليقات، والإشارات المرجعية، وديناميكيات تغييرات التصنيف، وكمية النص، والصور والأكواد في المقالة، والكلمات الرئيسية)، وإظهار موافق/ لا بأس بالتصويت تحت كل مقالة وتدريب نموذج لكل مستخدم، لكنني كنت كسولًا جدًا.

وبالإضافة إلى ذلك، فإن منطق العمل لن يكون واضحا جدا. يمكنني الآن تعيين تصنيف +9000 يدويًا للمريض صفر ومع تصنيف عتبة +20، سأضمن تلقي جميع مقالاته (ما لم، بالطبع، قمت بتعيين -100500 لبعض العلامات).

تبين أن البنية النهائية بسيطة للغاية:

1. ممثل يقوم بتخزين حالة جميع الدردشات والمقالات. فهو يقوم بتحميل حالته من ملف موجود على القرص ويحفظها مرة أخرى من وقت لآخر، وفي كل مرة إلى ملف جديد.
2. ممثل يقوم بزيارة موجز RSS من وقت لآخر، ويتعرف على المقالات الجديدة، ويطلع على الروابط، ويحلل، ويرسل هذه المقالات إلى الممثل الأول. بالإضافة إلى ذلك، فإنه يطلب أحيانًا قائمة بالمقالات من الممثل الأول، ويختار تلك التي لا يزيد عمرها عن ثلاثة أيام، ولكن لم يتم تحديثها لفترة طويلة، ويقوم بتحديثها.
3. ممثل يتواصل بالبرقية. ما زلت أحضر تحليل الرسالة بالكامل هنا. بطريقة ودية، أود تقسيمها إلى قسمين - بحيث يقوم أحدهما بتحليل الرسائل الواردة، والثاني يتعامل مع مشاكل النقل مثل إعادة إرسال الرسائل غير المرسلة. الآن لا يوجد إعادة إرسال، والرسالة التي لم تصل بسبب خطأ سيتم فقدانها ببساطة (ما لم يتم تدوينها في السجلات)، لكن هذا لم يسبب أي مشاكل حتى الآن. ربما تنشأ مشاكل إذا اشتركت مجموعة من الأشخاص في الروبوت ووصلت إلى الحد الأقصى لإرسال الرسائل).

ما أعجبني هو أنه بفضل Akka، لا يؤثر سقوط الممثلين 2 و3 بشكل عام على أداء الروبوت. ربما لا يتم تحديث بعض المقالات في الوقت المحدد أو أن بعض الرسائل لا تصل إلى التليجرام، ولكن يتم إعادة تشغيل الحساب من قبل الممثل ويستمر كل شيء في العمل. أقوم بحفظ المعلومات التي تظهرها المقالة للمستخدم فقط عندما يرد ممثل البرقية بأنه قام بتسليم الرسالة بنجاح. أسوأ ما يهددني هو إرسال الرسالة عدة مرات (إذا تم تسليمها ولكن التأكيد مفقود بطريقة ما). من حيث المبدأ، إذا لم يقم الممثل الأول بتخزين الدولة داخل نفسه، ولكنه تواصل مع بعض قواعد البيانات، فيمكنه أيضًا أن يسقط بشكل غير محسوس ويعود إلى الحياة. يمكنني أيضًا تجربة إصرار akka لاستعادة حالة الممثلين، لكن التنفيذ الحالي يناسبني بسبب بساطته. لا يعني ذلك أن الكود الخاص بي يتعطل كثيرًا - بل على العكس من ذلك، فقد بذلت الكثير من الجهد لجعل الأمر مستحيلًا. لكن الأمور تحدث، والقدرة على تقسيم البرنامج إلى ممثلين معزولين تبدو مريحة وعملية حقًا بالنسبة لي.

لقد أضفت Circle-ci بحيث إذا انكسر الرمز، ستكتشف ذلك على الفور. كحد أدنى، فهذا يعني أن التعليمات البرمجية قد توقفت عن الترجمة. في البداية كنت أرغب في إضافة ترافيس، لكنه أظهر فقط مشاريعي بدون شوكات. بشكل عام، يمكن استخدام هذين الأمرين بحرية في المستودعات المفتوحة.

نتائج

إنه بالفعل شهر نوفمبر. البوت مكتوب، أستخدمه منذ أسبوعين وأعجبني. إذا كان لديك أفكار للتحسين، والكتابة. لا أرى فائدة من تحقيق الدخل منه - دعه يعمل فقط وأرسل مقالات مثيرة للاهتمام.

رابط البوت: https://t.me/HabraFilterBot
جيثب: https://github.com/Kright/habrahabr_reader

استنتاجات صغيرة:

• حتى المشروع الصغير يمكن أن يستغرق الكثير من الوقت.
• أنت لست جوجل. لا فائدة من إطلاق النار على العصافير من مدفع. الحل البسيط قد يعمل أيضًا.
• تعتبر مشاريع الحيوانات الأليفة جيدة جدًا لتجربة التقنيات الجديدة.
• تتم كتابة روبوتات Telegram بكل بساطة. لولا "العمل الجماعي" وتجارب التكنولوجيا، لكان الروبوت قد كتب في أسبوع أو أسبوعين.
• يعد نموذج الممثل أمرًا مثيرًا للاهتمام ويتناسب بشكل جيد مع التعليمات البرمجية متعددة الخيوط والمتسامحة مع الأخطاء.
• أعتقد أنني تعرفت على سبب حب مجتمع المصادر المفتوحة للشوكات.
• تعتبر قواعد البيانات جيدة لأن حالة التطبيق لم تعد تعتمد على تعطل التطبيق/إعادة تشغيله، ولكن العمل مع قاعدة البيانات يعقد التعليمات البرمجية ويفرض قيودًا على بنية البيانات.

المصدر: www.habr.com