Habr থেকে নিবন্ধগুলির একটি ব্যক্তিগত নির্বাচনের জন্য টেলিগ্রাম বট

"কেন?" মত প্রশ্নের জন্য একটি পুরানো নিবন্ধ আছে - প্রাকৃতিক Geektimes - স্থান ক্লিনার তৈরীর.

অনেকগুলি নিবন্ধ রয়েছে, বিষয়গত কারণে সেগুলির মধ্যে কিছু আমি পছন্দ করি না এবং কিছু, বিপরীতে, এড়িয়ে যাওয়া দুঃখজনক। আমি এই প্রক্রিয়াটি অপ্টিমাইজ করতে এবং সময় বাঁচাতে চাই।

উপরের নিবন্ধটি একটি ইন-ব্রাউজার স্ক্রিপ্টিং পদ্ধতির পরামর্শ দিয়েছে, কিন্তু নিম্নলিখিত কারণে আমি এটি সত্যিই পছন্দ করিনি (যদিও আমি এটি আগে ব্যবহার করেছি):

• আপনার কম্পিউটার/ফোনের বিভিন্ন ব্রাউজারগুলির জন্য, যদি সম্ভব হয় তবে আপনাকে এটি আবার কনফিগার করতে হবে।
• লেখকদের দ্বারা কঠোর ফিল্টারিং সবসময় সুবিধাজনক নয়।
• যে লেখকদের নিবন্ধগুলি আপনি মিস করতে চান না তাদের সমস্যা, এমনকি যদি সেগুলি বছরে একবার প্রকাশিত হয় তবে সমাধান করা হয়নি।

নিবন্ধের রেটিং-এর উপর ভিত্তি করে সাইটে তৈরি করা ফিল্টারিং সবসময় সুবিধাজনক নয়, যেহেতু অত্যন্ত বিশেষায়িত নিবন্ধগুলি, তাদের মূল্য থাকা সত্ত্বেও, একটি বরং শালীন রেটিং পেতে পারে।

প্রাথমিকভাবে, আমি একটি আরএসএস ফিড তৈরি করতে চেয়েছিলাম (বা এমনকি বেশ কয়েকটি), সেখানে শুধুমাত্র আকর্ষণীয় জিনিসগুলি রেখে। কিন্তু শেষ পর্যন্ত, দেখা গেল যে আরএসএস পড়া খুব সুবিধাজনক বলে মনে হচ্ছে না: যে কোনও ক্ষেত্রে, কোনও নিবন্ধের জন্য মন্তব্য/ভোট দিতে/এটি আপনার পছন্দের তালিকায় যুক্ত করতে, আপনাকে ব্রাউজারটি দিয়ে যেতে হবে। এই কারণেই আমি একটি টেলিগ্রাম বট লিখেছি যা আমাকে একটি ব্যক্তিগত বার্তায় আকর্ষণীয় নিবন্ধ পাঠায়। টেলিগ্রাম নিজেই তাদের থেকে সুন্দর থাম্বনেল তৈরি করে, যা লেখক/রেটিং/ভিউ সম্পর্কে তথ্যের সাথে মিলিত হয়ে বেশ তথ্যপূর্ণ দেখায়।

কাটের নীচে কাজের বৈশিষ্ট্য, লেখার প্রক্রিয়া এবং প্রযুক্তিগত সমাধানগুলির মতো বিশদ বিবরণ রয়েছে।

বট সম্পর্কে সংক্ষেপে

সংগ্রহস্থল: https://github.com/Kright/habrahabr_reader

টেলিগ্রামে বট: https://t.me/HabraFilterBot

ব্যবহারকারী ট্যাগ এবং লেখকদের জন্য একটি অতিরিক্ত রেটিং সেট করে। এর পরে, নিবন্ধগুলিতে একটি ফিল্টার প্রয়োগ করা হয় - Habré-এ নিবন্ধের রেটিং, লেখকের ব্যবহারকারীর রেটিং এবং ট্যাগ দ্বারা ব্যবহারকারীর রেটিংগুলির গড় যোগ করা হয়। যদি পরিমাণটি ব্যবহারকারী-নির্দিষ্ট থ্রেশহোল্ডের চেয়ে বেশি হয়, তাহলে নিবন্ধটি ফিল্টারটি পাস করে।

একটি বট লেখার একটি পার্শ্ব লক্ষ্য ছিল মজা এবং অভিজ্ঞতা অর্জন করা। উপরন্তু, আমি নিয়মিত নিজেকে মনে করিয়ে আমি গুগল নই, এবং তাই অনেক কিছু করা হয় যতটা সহজ এবং এমনকি আদিমভাবে সম্ভব। যাইহোক, এটি বট লেখার প্রক্রিয়াটিকে তিন মাস সময় নিতে বাধা দেয়নি।

বাইরে তখন গ্রীষ্মকাল

জুলাই শেষ হচ্ছিল, এবং আমি একটি বট লেখার সিদ্ধান্ত নিয়েছি। এবং একা নয়, তবে একজন বন্ধুর সাথে যিনি স্কেলা আয়ত্ত করেছিলেন এবং এটিতে কিছু লিখতে চেয়েছিলেন। শুরুটি প্রতিশ্রুতিশীল লাগছিল - কোডটি একটি দল দ্বারা কাটা হবে, কাজটি সহজ বলে মনে হয়েছিল এবং আমি ভেবেছিলাম যে কয়েক সপ্তাহ বা এক মাসের মধ্যে বটটি প্রস্তুত হবে।

আমি নিজেও গত কয়েক বছর ধরে সময়ে সময়ে রকের উপর কোড লিখছি তা সত্ত্বেও, কেউ সাধারণত এই কোডটি দেখে না বা দেখে না: পোষা প্রকল্প, কিছু ধারণা পরীক্ষা করা, ডেটা প্রিপ্রসেস করা, FP থেকে কিছু ধারণা আয়ত্ত করা। আমি সত্যিই আগ্রহী ছিলাম একটি দলে লেখার কোডটি কেমন দেখায়, কারণ রকের কোড খুব ভিন্ন উপায়ে লেখা যেতে পারে।

কি চলে যেত সুতরাং? যাইহোক, আসুন জিনিস তাড়াহুড়ো না.
যা ঘটে তা প্রতিশ্রুতি ইতিহাস ব্যবহার করে ট্র্যাক করা যেতে পারে।

একজন পরিচিত ব্যক্তি 27 জুলাই একটি সংগ্রহস্থল তৈরি করেছিলেন, কিন্তু আর কিছুই করেননি, তাই আমি কোড লিখতে শুরু করি।

30 জুলাই

সংক্ষেপে: আমি হাবরের আরএসএস ফিডের একটি পার্সিং লিখেছি।

• com.github.pureconfig টাইপসেফ কনফিগারগুলি সরাসরি কেস ক্লাসে পড়ার জন্য (এটি খুব সুবিধাজনক বলে প্রমাণিত হয়েছে)
• scala-xml এক্সএমএল পড়ার জন্য: যেহেতু প্রাথমিকভাবে আমি আরএসএস ফিডের জন্য আমার নিজস্ব বাস্তবায়ন লিখতে চেয়েছিলাম এবং আরএসএস ফিডটি এক্সএমএল ফর্ম্যাটে রয়েছে, আমি পার্সিংয়ের জন্য এই লাইব্রেরিটি ব্যবহার করেছি। আসলে, আরএসএস পার্সিংও হাজির।
• scalatest পরীক্ষার জন্য এমনকি ছোট প্রকল্পের জন্য, লেখার পরীক্ষা সময় বাঁচায় - উদাহরণস্বরূপ, xml পার্সিং ডিবাগ করার সময়, এটি একটি ফাইলে ডাউনলোড করা, পরীক্ষা লিখতে এবং ত্রুটিগুলি সংশোধন করা অনেক সহজ। ভুল utf-8 অক্ষর সহ কিছু অদ্ভুত html পার্স করার সাথে পরে একটি বাগ উপস্থিত হলে, এটি একটি ফাইলে রাখা এবং একটি পরীক্ষা যোগ করা আরও সুবিধাজনক বলে প্রমাণিত হয়েছিল।
• আক্কা থেকে অভিনেতা। উদ্দেশ্যমূলকভাবে, তাদের মোটেই প্রয়োজন ছিল না, তবে প্রকল্পটি মজা করার জন্য লেখা হয়েছিল, আমি সেগুলি চেষ্টা করতে চেয়েছিলাম। ফলস্বরূপ, আমি বলতে প্রস্তুত যে আমি এটি পছন্দ করেছি। ওওপির ধারণাটি অন্য দিক থেকে দেখা যেতে পারে - সেখানে অভিনেতারা বার্তা বিনিময় করেন। আরও মজার বিষয় হল আপনি এমনভাবে কোড লিখতে পারেন (এবং উচিত) যাতে বার্তাটি না আসতে পারে বা প্রক্রিয়া নাও হতে পারে (সাধারণত বলতে গেলে, যখন অ্যাকাউন্টটি একটি একক কম্পিউটারে চলছে, বার্তাগুলি হারিয়ে যাবে না)। প্রথমে আমি আমার মাথা ঘামাচ্ছিলাম এবং অভিনেতাদের একে অপরের সাথে সাবস্ক্রাইব করার সাথে কোডে ট্র্যাশ ছিল, কিন্তু শেষ পর্যন্ত আমি একটি বরং সহজ এবং মার্জিত আর্কিটেকচার নিয়ে আসতে পেরেছি। প্রতিটি অভিনেতার ভিতরের কোডটিকে একক-থ্রেডেড হিসাবে বিবেচনা করা যেতে পারে; যখন একজন অভিনেতা ক্র্যাশ হয়, তখন acca এটি পুনরায় চালু করে - ফলাফলটি একটি মোটামুটি ত্রুটি-সহনশীল সিস্টেম।

9 আগস্ট

আমি প্রকল্পে যোগ করেছি scala-scrapper হাবর থেকে এইচটিএমএল পেজ পার্স করার জন্য (প্রবন্ধের রেটিং, বুকমার্কের সংখ্যা ইত্যাদির মতো তথ্য বের করতে)।

এবং বিড়াল. শিলা মধ্যে বেশী.

আমি তখন বিতরণকৃত ডাটাবেস সম্পর্কে একটি বই পড়ি, আমি CRDT (সংঘাত-মুক্ত প্রতিলিপিকৃত ডেটা টাইপ, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, হাবর), তাই আমি Habré নিবন্ধ সম্পর্কে তথ্যের জন্য একটি পরিবর্তনমূলক সেমিগ্রুপের একটি টাইপ ক্লাস পোস্ট করেছি।

আসলে, ধারণাটি খুব সহজ - আমাদের কাউন্টার রয়েছে যা একঘেয়ে পরিবর্তন করে। প্রচারের সংখ্যা ধীরে ধীরে বৃদ্ধি পাচ্ছে, যেমন প্লাসের সংখ্যা (পাশাপাশি বিয়োগের সংখ্যা)। যদি আমার কাছে একটি নিবন্ধ সম্পর্কে তথ্যের দুটি সংস্করণ থাকে, তবে আমি "এগুলিকে একটিতে একত্রিত করতে পারি" - যে কাউন্টারটি বড় তা আরও প্রাসঙ্গিক বলে বিবেচিত হয়৷

একটি সেমিগ্রুপের অর্থ হল একটি নিবন্ধ সম্পর্কে তথ্য সহ দুটি বস্তুকে একটিতে একত্রিত করা যেতে পারে। কম্যুটেটিভ মানে হল যে আপনি A + B এবং B + A উভয়ই মার্জ করতে পারেন, ফলাফলটি অর্ডারের উপর নির্ভর করে না এবং শেষ পর্যন্ত নতুন সংস্করণটি থাকবে। যাইহোক, এখানে সহযোগীতাও রয়েছে।

উদাহরণ স্বরূপ, পরিকল্পনা অনুযায়ী, পার্সিংয়ের পরে rss নিবন্ধটি সম্পর্কে সামান্য দুর্বল তথ্য প্রদান করেছে - মেট্রিক্স ছাড়া যেমন ভিউ সংখ্যা। তারপরে একজন বিশেষ অভিনেতা নিবন্ধগুলি সম্পর্কে তথ্য নিয়েছিলেন এবং এটি আপডেট করতে এবং এটিকে পুরানো সংস্করণের সাথে একত্রিত করতে এইচটিএমএল পৃষ্ঠাগুলিতে ছুটে যান৷

সাধারণভাবে বলতে গেলে, আক্কার মতো, এটির কোনও প্রয়োজন ছিল না, আপনি নিবন্ধটির জন্য আপডেট তারিখ সংরক্ষণ করতে পারেন এবং কোনও মার্জ ছাড়াই একটি নতুন নিতে পারেন, তবে অ্যাডভেঞ্চারের রাস্তা আমাকে নেতৃত্ব দিয়েছে।

12 আগস্ট

আমি মুক্ত বোধ করতে শুরু করেছি এবং, শুধুমাত্র মজার জন্য, আমি প্রতিটি চ্যাটকে আলাদা অভিনেতা বানিয়েছি। তাত্ত্বিকভাবে, একজন অভিনেতা নিজেই প্রায় 300 বাইট ওজনের হয় এবং সেগুলি লক্ষ লক্ষ তৈরি করা যেতে পারে, তাই এটি একটি সম্পূর্ণ স্বাভাবিক পদ্ধতি। আমার কাছে মনে হচ্ছে সমাধানটি বেশ আকর্ষণীয় হয়ে উঠেছে:

একজন অভিনেতা ছিলেন টেলিগ্রাম সার্ভার এবং আক্কার মেসেজ সিস্টেমের মধ্যে সেতুবন্ধন। তিনি কেবল বার্তা পেয়েছেন এবং পছন্দসই চ্যাট অভিনেতার কাছে পাঠিয়েছেন। চ্যাট অভিনেতা প্রতিক্রিয়া হিসাবে কিছু ফেরত পাঠাতে পারে - এবং এটি টেলিগ্রামে ফেরত পাঠানো হবে। যা খুব সুবিধাজনক ছিল তা হল এই অভিনেতা যতটা সম্ভব সহজ হয়ে উঠল এবং বার্তাগুলিতে প্রতিক্রিয়া জানানোর জন্য শুধুমাত্র যুক্তি ছিল। যাইহোক, প্রতিটি চ্যাটে নতুন নিবন্ধ সম্পর্কে তথ্য এসেছে, তবে আবার আমি এতে কোনও সমস্যা দেখতে পাচ্ছি না।

সাধারণভাবে, বটটি ইতিমধ্যে কাজ করছিল, বার্তাগুলির প্রতিক্রিয়া জানাচ্ছিল, ব্যবহারকারীকে পাঠানো নিবন্ধগুলির একটি তালিকা সংরক্ষণ করছিল এবং আমি ইতিমধ্যে ভাবছিলাম যে বটটি প্রায় প্রস্তুত। আমি ধীরে ধীরে লেখকের নাম এবং ট্যাগগুলি স্বাভাবিক করার মতো সামান্য বৈশিষ্ট্য যুক্ত করেছি ("s_d_f" এর সাথে "sd f" প্রতিস্থাপন করা)।

শুধু একটা জিনিস বাকি ছিল ছোট কিন্তু রাষ্ট্র কোথাও রক্ষা পায়নি।

সবকিছু ভুল হয়ে গেছে

আপনি হয়তো লক্ষ্য করেছেন যে আমি বটটি বেশিরভাগ একাই লিখেছি। সুতরাং, দ্বিতীয় অংশগ্রহণকারী বিকাশে জড়িত হয়েছিলেন এবং কোডে নিম্নলিখিত পরিবর্তনগুলি উপস্থিত হয়েছিল:

• MongoDB রাজ্য সঞ্চয় হাজির. একই সময়ে, প্রকল্পের লগগুলি ভেঙ্গে গেছে, কারণ কিছু কারণে মঙ্গা সেগুলিকে স্প্যাম করা শুরু করেছে এবং কিছু লোক কেবল বিশ্বব্যাপী সেগুলি বন্ধ করে দিয়েছে৷
• টেলিগ্রামের সেতু অভিনেতা স্বীকৃতির বাইরে রূপান্তরিত হয়েছিলেন এবং নিজেই বার্তাগুলি পার্স করতে শুরু করেছিলেন।
• চ্যাটের জন্য অভিনেতাদের নির্দয়ভাবে কেটে দেওয়া হয়েছিল, এবং পরিবর্তে তাদের প্রতিস্থাপিত হয়েছিল একজন অভিনেতা যিনি একবারে সমস্ত চ্যাটের সমস্ত তথ্য গোপন করেছিলেন। প্রতিটি হাঁচির জন্যই বিপাকে পড়েন এই অভিনেতা। ভাল, হ্যাঁ, যেমন একটি নিবন্ধ সম্পর্কে তথ্য আপডেট করার সময়, সমস্ত চ্যাট অভিনেতাদের কাছে এটি পাঠানো কঠিন (আমরা গুগলের মতো, মিলিয়ন ব্যবহারকারী প্রতিটির জন্য চ্যাটে এক মিলিয়ন নিবন্ধের জন্য অপেক্ষা করছে), কিন্তু প্রতিবার চ্যাট আপডেট করা হয়, মঙ্গায় যাওয়া স্বাভাবিক। যেহেতু আমি অনেক পরে বুঝতে পেরেছি, চ্যাটের কার্যকরী যুক্তিও সম্পূর্ণভাবে কেটে গেছে এবং এর জায়গায় এমন কিছু দেখা গেছে যা কাজ করেনি।
• টাইপ ক্লাসের কোন চিহ্ন অবশিষ্ট নেই।
• কিছু অস্বাস্থ্যকর যুক্তি অভিনেতাদের একে অপরের সাথে সাবস্ক্রিপশন নিয়ে হাজির হয়েছে, যা একটি রেসের অবস্থার দিকে নিয়ে গেছে।
• টাইপের ক্ষেত্র সহ ডেটা স্ট্রাকচার Option[Int] -1 এর মত যাদুকর ডিফল্ট মান সহ Int-এ পরিণত হয়েছে। পরে আমি বুঝতে পেরেছিলাম যে mongoDB json সঞ্চয় করে এবং সেখানে এটি সংরক্ষণ করার সাথে কোনও ভুল নেই Option ভাল, বা অন্তত পার্স -1 যেমন None, কিন্তু সেই সময়ে আমি এটি জানতাম না এবং এর জন্য আমার শব্দটি নিয়েছিলাম যে "এরকমই হওয়া উচিত।" আমি সেই কোডটি লিখিনি, এবং আমি আপাতত এটি পরিবর্তন করতে বিরক্ত করিনি।
• আমি খুঁজে পেয়েছি যে আমার সর্বজনীন আইপি ঠিকানা পরিবর্তন হতে থাকে, এবং প্রতিবার আমাকে এটি মঙ্গোর সাদা তালিকায় যোগ করতে হয়েছিল। আমি স্থানীয়ভাবে বটটি চালু করেছি, মঙ্গা একটি কোম্পানি হিসাবে মঙ্গার সার্ভারে কোথাও ছিল।
• হঠাৎ, টেলিগ্রামের জন্য ট্যাগ এবং বার্তা বিন্যাসের স্বাভাবিকীকরণ অদৃশ্য হয়ে গেল। (হুম, কেন এমন হবে?)
• আমি পছন্দ করেছি যে বটটির অবস্থা একটি বাহ্যিক ডাটাবেসে সংরক্ষিত আছে এবং পুনরায় চালু হলে এটি এমনভাবে কাজ করতে থাকে যেন কিছুই ঘটেনি। যাইহোক, এটি একমাত্র প্লাস ছিল।

দ্বিতীয় ব্যক্তির কোন বিশেষ তাড়া ছিল না, এবং এই সমস্ত পরিবর্তনগুলি সেপ্টেম্বরের শুরুতে ইতিমধ্যে একটি বড় স্তূপে উপস্থিত হয়েছিল। আমি অবিলম্বে ফলস্বরূপ ধ্বংসের মাত্রার প্রশংসা করিনি এবং ডাটাবেসের কাজ বুঝতে শুরু করেছি, কারণ ... আমি তাদের সাথে আগে কখনও ডিল করিনি। শুধুমাত্র পরে আমি বুঝতে পেরেছি যে কত কাজের কোড কাটা হয়েছে এবং তার জায়গায় কতগুলি বাগ যোগ করা হয়েছে।

সেপ্টেম্বর

প্রথমে আমি ভেবেছিলাম মঙ্গাকে আয়ত্ত করতে এবং এটি ভাল করতে কাজে লাগবে। তারপরে আমি ধীরে ধীরে বুঝতে শুরু করেছি যে ডাটাবেসের সাথে যোগাযোগ সংগঠিত করাও একটি শিল্প যেখানে আপনি অনেক দৌড়াদৌড়ি করতে পারেন এবং কেবল ভুল করতে পারেন। উদাহরণস্বরূপ, যদি ব্যবহারকারী দুটি বার্তা লাইক পায় /subscribe - এবং প্রতিটির প্রতিক্রিয়া হিসাবে আমরা টেবিলে একটি এন্ট্রি তৈরি করব, কারণ সেই বার্তাগুলি প্রক্রিয়া করার সময় ব্যবহারকারী সাবস্ক্রাইব করেননি। আমার একটি সন্দেহ আছে যে মঙ্গার সাথে বর্তমান আকারে যোগাযোগটি সর্বোত্তম উপায়ে লেখা হয়নি। উদাহরণস্বরূপ, ব্যবহারকারীর সেটিংস সে সাইন আপ করার মুহূর্তে তৈরি হয়েছিল। যদি তিনি সাবস্ক্রিপশনের সত্যতার আগে সেগুলি পরিবর্তন করার চেষ্টা করেন... বট কিছুই সাড়া দেয়নি, কারণ অভিনেতার কোড সেটিংসের জন্য ডাটাবেসে গিয়েছিল, এটি খুঁজে পায়নি এবং ক্র্যাশ হয়ে গেছে। যখন জিজ্ঞাসা করা হয়েছিল যে কেন প্রয়োজন অনুসারে সেটিংস তৈরি করবেন না, আমি শিখেছি যে ব্যবহারকারী সাবস্ক্রাইব না করলে সেগুলি পরিবর্তন করার দরকার নেই... বার্তা ফিল্টারিং সিস্টেমটি কোনওভাবে অ-স্পষ্টভাবে তৈরি করা হয়েছিল, এবং কোডটি ঘনিষ্ঠভাবে দেখার পরেও আমি পারি বুঝতে পারছি না যে এটি প্রাথমিকভাবে এইভাবে করা হয়েছিল নাকি সেখানে একটি ত্রুটি আছে।

চ্যাটে জমা দেওয়া নিবন্ধগুলির কোনও তালিকা ছিল না; পরিবর্তে, আমি সেগুলি নিজে লিখতে পরামর্শ দেওয়া হয়েছিল। এটি আমাকে বিস্মিত করেছে - সাধারণভাবে, আমি প্রকল্পে সমস্ত ধরণের জিনিস টেনে আনার বিরুদ্ধে ছিলাম না, তবে যে এই জিনিসগুলি এনেছে এবং সেগুলিকে স্ক্রু করেছে তার পক্ষে এটি যৌক্তিক হবে৷ কিন্তু না, দ্বিতীয় অংশগ্রহণকারী সবকিছু ছেড়ে দিয়েছে বলে মনে হয়েছিল, কিন্তু বলেছিল যে চ্যাটের ভিতরে থাকা তালিকাটি অনুমিতভাবে একটি খারাপ সমাধান ছিল, এবং "একটি নিবন্ধ y ব্যবহারকারী x-এ পাঠানো হয়েছিল" এর মতো ইভেন্টগুলির সাথে একটি চিহ্ন তৈরি করা প্রয়োজন৷ তারপরে, ব্যবহারকারী যদি নতুন নিবন্ধ পাঠানোর জন্য অনুরোধ করেন, তবে ডাটাবেসে একটি অনুরোধ পাঠানোর প্রয়োজন ছিল, যা ইভেন্টগুলি থেকে ব্যবহারকারীর সাথে সম্পর্কিত ইভেন্টগুলি নির্বাচন করবে, নতুন নিবন্ধগুলির একটি তালিকাও পাবে, সেগুলি ফিল্টার করবে, ব্যবহারকারীকে পাঠাবে। এবং এই সম্পর্কে ইভেন্টগুলিকে ডাটাবেসে ফেলে দিন।

দ্বিতীয় অংশগ্রহণকারীকে বিমূর্ততার দিকে কোথাও নিয়ে যাওয়া হয়েছিল, যখন বট কেবল হাবর থেকে নিবন্ধগুলি পাবে না এবং কেবল টেলিগ্রামেও পাঠানো হবে না।

আমি একরকম সেপ্টেম্বরের দ্বিতীয়ার্ধের জন্য একটি পৃথক চিহ্নের আকারে ইভেন্টগুলি বাস্তবায়ন করেছি। এটি সর্বোত্তম নয়, তবে অন্তত বটটি কাজ শুরু করেছে এবং আমাকে আবার নিবন্ধগুলি পাঠাতে শুরু করেছে এবং আমি ধীরে ধীরে বুঝতে পেরেছি যে কোডটিতে কী ঘটছে।

এখন আপনি শুরুতে ফিরে যেতে পারেন এবং মনে রাখতে পারেন যে সংগ্রহস্থলটি মূলত আমার দ্বারা তৈরি করা হয়নি। কি এভাবে যেতে পারে? আমার টান অনুরোধ প্রত্যাখ্যান করা হয়েছে. দেখা গেল যে আমার কাছে রেডনেক কোড ছিল, যে আমি কীভাবে একটি দলে কাজ করতে জানি না, এবং আমাকে বর্তমান বাস্তবায়ন বক্ররেখায় বাগগুলি ঠিক করতে হয়েছিল, এবং এটিকে ব্যবহারযোগ্য অবস্থায় পরিমার্জন করতে হবে না।

আমি বিচলিত হয়েছিলাম এবং কমিট ইতিহাস এবং লেখা কোডের পরিমাণ দেখেছিলাম। আমি এমন মুহূর্তগুলি দেখেছিলাম যা মূলত ভাল লেখা হয়েছিল, এবং তারপরে ভেঙে পড়েছিল...

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 এগুলিকে ঠিক এই ফর্মে প্রদর্শন করে, আপনি এটি থেকে পাঠ্যটি নিতে পারেন এবং সমস্ত সেটিংস বন্ধুকে পাঠাতে পারেন।
এটি একটি ছোট জিনিস মত মনে হচ্ছে, কিন্তু অনুরূপ nuances কয়েক ডজন আছে.

একটি সাধারণ রৈখিক মডেল আকারে নিবন্ধ ফিল্টারিং বাস্তবায়িত - ব্যবহারকারী লেখক এবং ট্যাগের জন্য একটি অতিরিক্ত রেটিং সেট করতে পারেন, সেইসাথে একটি থ্রেশহোল্ড মান। যদি লেখকের রেটিং, ট্যাগের গড় রেটিং এবং নিবন্ধের প্রকৃত রেটিং থ্রেশহোল্ড মানের থেকে বেশি হয়, তাহলে নিবন্ধটি ব্যবহারকারীকে দেখানো হয়। আপনি হয় বটকে /নতুন কমান্ড সহ নিবন্ধগুলির জন্য জিজ্ঞাসা করতে পারেন বা বটটিতে সদস্যতা নিতে পারেন এবং এটি দিনের যে কোনও সময় একটি ব্যক্তিগত বার্তায় নিবন্ধগুলি পাঠাবে৷

সাধারণভাবে বলতে গেলে, আমার কাছে প্রতিটি নিবন্ধের জন্য আরও বৈশিষ্ট্য (হাব, মন্তব্যের সংখ্যা, বুকমার্ক, রেটিং পরিবর্তনের গতিশীলতা, নিবন্ধের পাঠ্যের পরিমাণ, ছবি এবং কোড, কীওয়ার্ড) বের করার জন্য একটি ধারণা ছিল এবং ব্যবহারকারীকে একটি ঠিক আছে/ দেখান। ঠিক আছে প্রতিটি নিবন্ধের অধীনে ভোট এবং প্রতিটি ব্যবহারকারীর জন্য একটি মডেল প্রশিক্ষণ না, কিন্তু আমি খুব অলস ছিল.

উপরন্তু, কাজের যুক্তি এত সুস্পষ্ট হবে না। এখন আমি পেশেন্টজিরোর জন্য ম্যানুয়ালি +9000 রেটিং সেট করতে পারি এবং +20 এর থ্রেশহোল্ড রেটিং সহ আমি তার সমস্ত নিবন্ধ পাওয়ার নিশ্চয়তা পাব (যদি না, আমি কিছু ট্যাগের জন্য -100500 সেট করি)।

চূড়ান্ত স্থাপত্য বেশ সহজ হতে পরিণত:

1. একজন অভিনেতা যে সমস্ত চ্যাট এবং নিবন্ধের অবস্থা সংরক্ষণ করে। এটি ডিস্কের একটি ফাইল থেকে তার অবস্থা লোড করে এবং সময়ে সময়ে এটিকে সংরক্ষণ করে, প্রতিবার একটি নতুন ফাইলে।
2. একজন অভিনেতা যিনি সময়ে সময়ে RSS ফিড দেখেন, নতুন নিবন্ধগুলি সম্পর্কে শিখেন, লিঙ্কগুলি দেখেন, পার্স করেন এবং এই নিবন্ধগুলি প্রথম অভিনেতাকে পাঠান৷ উপরন্তু, এটি কখনও কখনও প্রথম অভিনেতার নিবন্ধগুলির একটি তালিকার অনুরোধ করে, সেগুলিকে নির্বাচন করে যেগুলি তিন দিনের বেশি পুরানো নয়, কিন্তু দীর্ঘদিন ধরে আপডেট করা হয়নি এবং সেগুলিকে আপডেট করে৷
3. একজন অভিনেতা যিনি টেলিগ্রামের মাধ্যমে যোগাযোগ করেন। আমি এখনও সম্পূর্ণরূপে এখানে বার্তা পার্সিং আনা. একটি বন্ধুত্বপূর্ণ উপায়ে, আমি এটিকে দুটি ভাগে ভাগ করতে চাই - যাতে একটি ইনকামিং বার্তাগুলিকে পার্স করে এবং দ্বিতীয়টি অপ্রেরিত বার্তাগুলি পুনরায় পাঠানোর মতো পরিবহন সমস্যাগুলির সাথে ডিল করে৷ এখন কোনও পুনঃপ্রেরণ নেই, এবং একটি বার্তা যা একটি ত্রুটির কারণে পৌঁছায়নি তা কেবল হারিয়ে যাবে (যদি না এটি লগগুলিতে উল্লেখ করা হয়), তবে এখনও পর্যন্ত এটি কোনও সমস্যা সৃষ্টি করেনি৷ সম্ভবত সমস্যা দেখা দেবে যদি একগুচ্ছ লোক বট সাবস্ক্রাইব করে এবং আমি বার্তা পাঠানোর সীমাতে পৌঁছে যাই)।

আমি যা পছন্দ করেছি তা হল আক্কাকে ধন্যবাদ, অভিনেতা 2 এবং 3 এর ফলস সাধারণত বটটির পারফরম্যান্সকে প্রভাবিত করে না। সম্ভবত কিছু নিবন্ধ সময়মতো আপডেট করা হয় না বা কিছু বার্তা টেলিগ্রামে পৌঁছায় না, তবে অ্যাকাউন্টটি অভিনেতা পুনরায় চালু করে এবং সবকিছু কাজ চালিয়ে যায়। আমি তথ্য সংরক্ষণ করি যে নিবন্ধটি শুধুমাত্র ব্যবহারকারীকে দেখানো হয় যখন টেলিগ্রাম অভিনেতা প্রতিক্রিয়া জানায় যে তিনি সফলভাবে বার্তাটি প্রদান করেছেন। সবচেয়ে খারাপ জিনিস যা আমাকে হুমকি দেয় তা হল বার্তাটি কয়েকবার প্রেরণ করা (যদি এটি বিতরণ করা হয় তবে নিশ্চিতকরণটি কোনওভাবে হারিয়ে যায়)। নীতিগতভাবে, যদি প্রথম অভিনেতা রাষ্ট্রকে নিজের মধ্যে সঞ্চয় না করেন, তবে কিছু ডাটাবেসের সাথে যোগাযোগ করেন, তবে তিনি অজ্ঞানভাবে পড়ে যেতে পারেন এবং জীবনে ফিরে আসতে পারেন। আমি অভিনেতাদের অবস্থা পুনরুদ্ধার করার জন্য আক্কা অধ্যবসায় চেষ্টা করতে পারি, কিন্তু বর্তমান বাস্তবায়ন তার সরলতার সাথে আমার জন্য উপযুক্ত। এটি এমন নয় যে আমার কোডটি প্রায়শই ক্র্যাশ হয় - বিপরীতভাবে, আমি এটিকে অসম্ভব করার জন্য অনেক প্রচেষ্টা করেছি। কিন্তু বিষ্ঠা ঘটে, এবং বিচ্ছিন্ন টুকরা-অভিনেতাদের মধ্যে প্রোগ্রাম ভাঙার ক্ষমতা আমার কাছে সত্যিই সুবিধাজনক এবং ব্যবহারিক বলে মনে হয়েছিল।

আমি সার্কেল-সিআই যুক্ত করেছি যাতে কোডটি ভাঙলে আপনি অবিলম্বে এটি সম্পর্কে জানতে পারবেন। সর্বনিম্ন, এর মানে হল যে কোডটি কম্পাইল করা বন্ধ করে দিয়েছে। প্রাথমিকভাবে আমি ট্র্যাভিস যোগ করতে চেয়েছিলাম, কিন্তু এটি শুধুমাত্র কাঁটা ছাড়াই আমার প্রকল্পগুলি দেখায়। সাধারণভাবে, এই দুটি জিনিসই খোলা সংগ্রহস্থলে অবাধে ব্যবহার করা যেতে পারে।

ফলাফল

ইতিমধ্যেই নভেম্বর। বটটিতে লেখা আছে, আমি গত দুই সপ্তাহ ধরে এটি ব্যবহার করছি এবং আমি এটি পছন্দ করেছি। আপনার যদি উন্নতির জন্য ধারণা থাকে তবে লিখুন। আমি এটিকে নগদীকরণের বিন্দু দেখতে পাচ্ছি না - এটিকে কাজ করতে দিন এবং আকর্ষণীয় নিবন্ধ পাঠান৷

বট লিঙ্ক: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

ছোট উপসংহার:

• এমনকি একটি ছোট প্রকল্প অনেক সময় নিতে পারে।
• আপনি Google নন। কামান থেকে চড়ুই গুলি করার কোন মানে হয় না। একটি সহজ সমাধান ঠিক পাশাপাশি কাজ করতে পারে।
• পোষা প্রকল্পগুলি নতুন প্রযুক্তির সাথে পরীক্ষা করার জন্য খুব ভাল।
• টেলিগ্রাম বটগুলি বেশ সহজভাবে লেখা হয়। যদি এটি "টিমওয়ার্ক" এবং প্রযুক্তি নিয়ে পরীক্ষা-নিরীক্ষার জন্য না হতো, বটটি এক বা দুই সপ্তাহের মধ্যে লেখা হয়ে যেত।
• অভিনেতা মডেল একটি আকর্ষণীয় জিনিস যা মাল্টি-থ্রেডিং এবং ফল্ট-সহনশীল কোডের সাথে ভাল যায়।
• আমি মনে করি আমি একটি স্বাদ পেয়েছি কেন ওপেন সোর্স সম্প্রদায় কাঁটাচামচ পছন্দ করে।
• ডেটাবেসগুলি ভাল কারণ অ্যাপ্লিকেশনের অবস্থা আর অ্যাপ্লিকেশন ক্র্যাশ/পুনরারম্ভের উপর নির্ভর করে না, তবে একটি ডাটাবেসের সাথে কাজ করা কোডটিকে জটিল করে এবং ডেটা কাঠামোর উপর বিধিনিষেধ আরোপ করে।

উত্স: www.habr.com