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

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

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

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

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

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

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

تحت الخفض ، تفاصيل مثل ميزات العمل ، عملية الكتابة والحلول التقنية.

لفترة وجيزة عن الروبوت

المستودع: https://github.com/Kright/habrahabr_reader

بوت برقية: https://t.me/HabraFilterBot

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

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

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

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

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

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

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

30 يوليو

باختصار: كتبت تحليل موجزات rss لـ Habr.

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

9 أغسطس

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

والقطط. تلك الموجودة في الصخر.

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

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

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

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

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

12 أغسطس

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

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

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

لم يكن هناك سوى صغير واحد ولكن - الدولة لم تستمر في أي مكان.

كل شيء حدث خطأ

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

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

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

سبتمبر

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

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

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

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

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

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

F * RK ذلك

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

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

لماذا أحتاج إلى عامل إرساء و mongoDB وغيرها من برامج الشحن "الخطيرة" ، إذا كان الرمز لا يعمل بغباء أو يعمل بطريقة ملتوية؟

لقد تفرعت من المشروع وفعلت كل ما أردت.

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

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

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

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

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

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

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

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

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

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

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

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

كانت البنية الناتجة بسيطة للغاية:

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

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

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

النتائج

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

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

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

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