ٽيليگرام بوٽ Habr کان آرٽيڪل جي ذاتي چونڊ لاءِ

سوالن لاءِ "ڇو؟" ھڪڙو پراڻو مضمون آھي - قدرتي Geektimes - خلا صاف ڪندڙ ٺاهڻ.

اتي ڪيترائي مضمون آھن، موضوعي سببن جي ڪري، انھن مان ڪجھ مون کي پسند نه آھن، ۽ ڪجھ، ان جي ابتڙ، ڇڏڻ افسوس جوڳو آھي. مان هن عمل کي بهتر ڪرڻ ۽ وقت بچائڻ چاهيان ٿو.

مٿي ڏنل آرٽيڪل تجويز ڪيل هڪ برائوزر اسڪرپٽنگ واري طريقي سان، پر مون کي واقعي پسند نه ڪيو (جيتوڻيڪ مون ان کان اڳ استعمال ڪيو آهي) هيٺين سببن لاء:

• توهان جي ڪمپيوٽر/فون تي مختلف برائوزرن لاءِ، توهان کي ان کي ٻيهر ترتيب ڏيڻو پوندو، جيڪڏهن ممڪن هجي.
• ليکڪن طرفان سخت فلٽرنگ هميشه آسان ناهي.
• ليکڪن سان مسئلو جن جا آرٽيڪل توهان کي ياد ڪرڻ نٿا چاهيو، جيتوڻيڪ اهي سال ۾ هڪ ڀيرو شايع ڪيا وڃن، حل نه ڪيو ويو آهي.

آرٽيڪل جي درجه بندي جي بنياد تي سائيٽ ۾ ٺهيل فلٽرنگ هميشه آسان ناهي، ڇو ته انتهائي خاص آرٽيڪل، انهن جي قيمت جي باوجود، هڪ معمولي درجه بندي حاصل ڪري سگھن ٿا.

شروعات ۾، مان هڪ آر ايس ايس فيڊ ٺاهڻ چاهيان ٿو (يا اڃا به ڪيترائي)، اتي رڳو دلچسپ شيون ڇڏي. پر آخر ۾، اهو ظاهر ٿيو ته آر ايس ايس پڙهڻ بلڪل آسان نه لڳي: ڪنهن به صورت ۾، هڪ مضمون لاءِ رايو/ووٽ ڪرڻ/ان کي پنهنجي پسند ۾ شامل ڪرڻ لاءِ، توهان کي برائوزر ذريعي وڃڻو پوندو. ان ڪري مون هڪ ٽيليگرام بوٽ لکيو آهي جيڪو مون کي ذاتي پيغام ۾ دلچسپ مضمون موڪلي ٿو. ٽيليگرام پاڻ انهن مان خوبصورت ڏيکاءُ ٺاهي ٿو، جيڪي ليکڪ/درجه بندي/نظريات بابت معلومات سان گڏ، ڪافي معلوماتي نظر اچن ٿا.

ڪٽ جي هيٺان تفصيل آهن جهڙوڪ ڪم جون خاصيتون، لکڻ جي عمل ۽ ٽيڪنيڪل حل.

بوٽ جي باري ۾ مختصر طور

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

ٽيليگرام ۾ بوٽ: https://t.me/HabraFilterBot

استعمال ڪندڙ ٽيگ ۽ ليکڪن لاءِ اضافي ريٽنگ مقرر ڪري ٿو. ان کان پوء، هڪ فلٽر آرٽيڪل تي لاڳو ڪيو ويو آهي - Habré تي آرٽيڪل جي درجه بندي، ليکڪ جي صارف جي درجه بندي ۽ ٽيگ ذريعي صارف جي درجه بندي لاء اوسط شامل ڪيا ويا آهن. جيڪڏهن رقم صارف جي مقرر ڪيل حد کان وڌيڪ آهي، پوء مضمون فلٽر پاس ڪري ٿو.

هڪ بوٽ لکڻ جو هڪ طرفي مقصد مزو ۽ تجربو حاصل ڪرڻ هو. ان کان علاوه، مون پاڻ کي باقاعده ياد ڏياريو مان گوگل نه آهيان، ۽ تنهن ڪري ڪيتريون ئي شيون ڪيون وينديون آهن آسان ۽ اڃا به ابتدائي طور تي ممڪن طور تي. بهرحال، اهو ٽن مهينن کان وٺي بوٽ لکڻ جي عمل کي روڪي نه سگهيو.

ٻاهر اونهاري هئي

جولاءِ ختم ٿي رهي هئي، ۽ مون فيصلو ڪيو ته هڪ بوٽ لکڻ. ۽ اڪيلو نه، پر هڪ دوست سان جيڪو اسڪالا ۾ ماسٽر هو ۽ ان تي ڪجهه لکڻ چاهيندو هو. شروعات واعدو ڪندڙ لڳي - ڪوڊ هڪ ٽيم طرفان ڪٽيو ويندو، ڪم آسان لڳي رهيو هو ۽ مون سوچيو ته ٻن هفتن يا هڪ مهيني ۾ بوٽ تيار ٿي ويندو.

ان حقيقت جي باوجود ته مان پاڻ گذريل ڪجهه سالن کان وقت بوقت پٿر تي ڪوڊ لکندو رهيو آهيان، ڪو به عام طور تي هن ڪوڊ کي نه ٿو ڏسي يا نه ٿو ڏسي: پالتو پراجيڪٽ، ڪجهه خيالن جي جانچ ڪرڻ، ڊيٽا کي پروسيس ڪرڻ، FP کان ڪجهه تصورن تي عبور حاصل ڪرڻ. مون کي واقعي دلچسپي هئي ته ٽيم ۾ لکڻ جو ڪوڊ ڪهڙو نظر اچي ٿو، ڇاڪاڻ ته پٿر تي ڪوڊ تمام مختلف طريقن سان لکي سگهجي ٿو.

ڇا ٿي سگهي ٿو پوء؟ بهرحال، اچو ته جلدي شين کي نه ڏيو.
هر شي جيڪو ٿئي ٿو اهو تعقيب جي تاريخ استعمال ڪندي ٽريڪ ڪري سگهجي ٿو.

هڪ واقفڪار 27 جولاءِ تي هڪ مخزن ٺاهيو، پر ٻيو ڪجهه نه ڪيو، تنهنڪري مون ڪوڊ لکڻ شروع ڪيو.

30 جولاء

مختصر طور: مون حبر جي آر ايس ايس فيڊ جو هڪ تجزيو لکيو.

• com.github.pureconfig پڙهڻ لاءِ قسمون محفوظ ترتيبون سڌو سنئون ڪيس ڪلاس ۾ (اهو تمام آسان نڪتو)
• scala-xml xml پڙهڻ لاءِ: جيئن ته شروع ۾ مان rss فيڊ لاءِ پنهنجو عمل لکڻ چاهيان ٿو، ۽ rss فيڊ xml فارميٽ ۾ آهي، ان ڪري مون هن لائبريري کي پارس ڪرڻ لاءِ استعمال ڪيو. دراصل، آر ايس ايس پارسنگ پڻ ظاهر ٿيو.
• scalatest ٽيسٽ لاءِ. جيتوڻيڪ ننڍڙن منصوبن لاءِ، ٽيسٽ لکڻ وقت بچائيندو آهي - مثال طور، جڏهن ڊيبگ ڪندي xml پارسنگ، ان کي فائل ۾ ڊائونلوڊ ڪرڻ، ٽيسٽ لکڻ ۽ غلطيون درست ڪرڻ تمام آسان آهي. جڏهن هڪ بگ بعد ۾ ظاهر ٿيو ڪجهه عجيب html کي غلط utf-8 اکرن سان پارس ڪرڻ سان، ان کي فائل ۾ رکڻ ۽ ٽيسٽ شامل ڪرڻ وڌيڪ آسان ثابت ٿيو.
• اک کان اداڪار. معقول طور تي، انهن جي ڪا به ضرورت نه هئي، پر اهو منصوبو مذاق لاء لکيو ويو هو، مان انهن کي ڪوشش ڪرڻ چاهيان ٿو. نتيجي طور، مان چوڻ لاءِ تيار آهيان ته مون ان کي پسند ڪيو. OOP جو خيال ٻئي پاسي کان ڏسي سگهجي ٿو - اهڙا اداڪار آهن جيڪي پيغامن جي بدلي ۾. وڌيڪ دلچسپ ڳالهه اها آهي ته توهان ڪوڊ لکي سگهو ٿا (۽ گهرجي) انهي طريقي سان ته پيغام پهچي نه سگهي يا پروسيس نه ٿي سگهي (عام طور تي ڳالهائڻ، جڏهن اڪائونٽ هڪ واحد ڪمپيوٽر تي هلندو آهي، پيغام وڃائڻ نه گهرجي). پهرين ته آئون پنهنجو مٿو ڇڪي رهيو هوس ۽ ڪوڊ ۾ ردي جي ٽوڙي هئي جنهن ۾ اداڪار هڪ ٻئي کي سبسڪرائب ڪري رهيا هئا، پر آخر ۾ مان هڪ سادي ۽ خوبصورت فن تعمير سان گڏ اچڻ ۾ ڪامياب ٿيس. هر هڪ اداڪار جي اندر ڪوڊ کي هڪ واحد موضوع سمجهي سگهجي ٿو؛ جڏهن هڪ اداڪار حادثو ڪري ٿو، ايڪا ان کي ٻيهر شروع ڪري ٿو - نتيجو هڪ مناسب غلطي برداشت ڪرڻ وارو نظام آهي.

9 وڳي

مون منصوبي ۾ شامل ڪيو scala-scrapper حبر مان html صفحن کي پارس ڪرڻ لاءِ (معلومات ڪڍڻ لاءِ جيئن آرٽيڪل جي درجه بندي، بک مارڪس جو تعداد، وغيره).

۽ ٻليون. پٿر ۾ جيڪي.

مون پوءِ ورهايل ڊيٽابيس جي باري ۾ هڪ ڪتاب پڙهيو، مون کي CRDT جو خيال پسند آيو (تصادم کان پاڪ نقل ٿيل ڊيٽا جو قسم، https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, هبر)، تنهنڪري مون Habré تي مضمون بابت معلومات لاءِ هڪ قسم جي ڪلاسيڪل سيميگروپ پوسٽ ڪئي.

حقيقت ۾، خيال تمام سادو آهي - اسان وٽ شمار ڪندڙ آهن جيڪي هڪجهڙائي سان تبديل ڪندا آهن. پروموشنز جو تعداد بتدريج وڌي رھيو آھي، جيئن پلس جو تعداد (۽ گڏوگڏ مائنس جو تعداد). جيڪڏهن مون وٽ هڪ مضمون بابت معلومات جا ٻه نسخا آهن، ته پوءِ مان ”انهن کي هڪ ۾ ضم ڪري سگهان ٿو“ - ڪائونٽر جي حالت جيڪا وڏي آهي وڌيڪ لاڳاپيل سمجهي ويندي آهي.

هڪ نيم گروپ جو مطلب آهي ته هڪ مضمون بابت معلومات سان ٻه شيون هڪ ۾ ضم ٿي سگهن ٿيون. Commutative جو مطلب آھي توھان ٻئي A + B ۽ B + A کي ضم ڪري سگھو ٿا، نتيجو آرڊر تي منحصر نه آھي، ۽ آخر ۾ نئون نسخو رھندو. رستي جي ذريعي، هتي پڻ ايسوسيئيشن آهي.

مثال طور، جيئن منصوبابندي ڪئي وئي، rss parsing کان پوءِ مضمون جي باري ۾ ٿورڙي ڪمزور معلومات مهيا ڪئي - بغير ميٽرڪس جهڙوڪ نظرن جو تعداد. هڪ خاص اداڪار پوءِ مضمونن جي باري ۾ معلومات ورتي ۽ ان کي اپڊيٽ ڪرڻ لاءِ html صفحن ڏانهن ڊوڙيو ۽ ان کي پراڻي ورزن سان ملايو.

عام طور تي ڳالهائڻ، جيئن اک ۾، ان جي ڪا ضرورت نه هئي، توهان صرف آرٽيڪل لاء تازه ڪاري جمع ڪري سگهو ٿا ۽ بغير ڪنهن ضم جي هڪ نئون وٺي سگهو ٿا، پر جرئت جي رستي مون کي هدايت ڪئي.

12 وڳي

مون آزاد محسوس ڪرڻ شروع ڪيو ۽، صرف مذاق لاء، مون هر چيٽ کي هڪ الڳ اداڪار بڻائي ڇڏيو. نظرياتي طور تي، هڪ اداڪار پاڻ تقريبا 300 بائيٽ وزن آهي ۽ اهي لکين ۾ ٺاهي سگھجن ٿيون، تنهنڪري اهو هڪ مڪمل طور تي عام طريقو آهي. اهو مون کي لڳي ٿو ته حل ڪافي دلچسپ ٿي ويو آهي:

هڪ اداڪار ٽيليگرام سرور ۽ اک ۾ پيغام سسٽم جي وچ ۾ هڪ پل هو. هن صرف پيغام وصول ڪيا ۽ انهن کي گهربل چيٽ اداڪار ڏانهن موڪليو. چيٽ اداڪار جواب ۾ ڪجهه واپس موڪلي سگهي ٿو - ۽ اهو واپس ٽيليگرام ڏانهن موڪليو ويندو. جيڪو تمام آسان هو اهو آهي ته هي اداڪار ممڪن طور تي آسان ٿي ويو ۽ پيغامن جي جواب ڏيڻ لاء صرف منطق شامل آهي. رستي ۾، هر چيٽ تي نون مضمونن جي معلومات ايندي هئي، پر ٻيهر مون کي ان ۾ ڪو مسئلو نظر نٿو اچي.

عام طور تي، بوٽ اڳ ۾ ئي ڪم ڪري رهيو هو، پيغامن جو جواب ڏيڻ، صارف ڏانهن موڪليل مضمونن جي فهرست کي محفوظ ڪرڻ، ۽ مان اڳ ۾ ئي سوچي رهيو هو ته بوٽ تقريبا تيار آهي. مون آهستي آهستي ٿوريون خاصيتون شامل ڪيون جهڙوڪ ليکڪ جا نالا ۽ ٽيگ عام ڪرڻ ("sd f" کي "s_d_f" سان تبديل ڪرڻ).

رڳو هڪ شيءِ رهي هئي ننڍو پر - رياست ڪٿي به محفوظ نه هئي.

سڀ ڪجهه غلط ٿي ويو

توهان شايد محسوس ڪيو آهي ته مون بوٽ گهڻو ڪري اڪيلو لکيو آهي. تنهن ڪري، ٻيو حصو وٺندڙ ترقي ۾ شامل ٿيو، ۽ هيٺيون تبديليون ڪوڊ ۾ ظاهر ٿيو:

• MongoDB رياست کي ذخيرو ڪرڻ لاء ظاهر ٿيو. ساڳئي وقت، پروجيڪٽ ۾ لاگز ڀڄي ويا، ڇاڪاڻ ته ڪجهه سببن لاء مونگا انهن کي اسپام ڪرڻ شروع ڪيو ۽ ڪجهه ماڻهن انهن کي صرف عالمي سطح تي بند ڪري ڇڏيو.
• ٽيليگرام ۾ پل اداڪار جي سڃاڻپ کان ٻاهر ٿي ويو ۽ پاڻ کي پيغامن کي پارس ڪرڻ شروع ڪيو.
• چيٽس لاءِ اداڪارن کي بي رحميءَ سان ڪٽيو ويو، ۽ ان جي بدران انهن کي هڪ اداڪار طرفان تبديل ڪيو ويو، جيڪو هڪ ئي وقت ۾ سڀني چيٽ بابت سڀني معلومات کي لڪائيندو هو. هر ڇڪ لاء، هي اداڪار مصيبت ۾ ويو. خير، ها، جيئن ته مضمون جي باري ۾ معلومات تازه ڪاري ڪرڻ وقت، ان کي سڀني چيٽ اداڪارن ڏانهن موڪلڻ ڏکيو آهي (اسان گوگل وانگر آهيون، لکين صارف هر هڪ لاءِ چيٽ ۾ لکين مضمونن جو انتظار ڪري رهيا آهن)، پر هر دفعي چيٽ کي اپڊيٽ ڪيو ويندو آهي، مونگا ۾ وڃڻ معمول آهي. جيئن ته مون گهڻو پوءِ محسوس ڪيو، چيٽ جي ڪم ڪندڙ منطق به مڪمل طور تي ڪٽيل هئي ۽ ان جي جاءِ تي ڪجهه ظاهر ٿيو جيڪو ڪم نه ڪيو.
• قسم جي طبقن جو ڪو به نشان باقي نه آهي.
• ڪجهه غير صحت مند منطق اداڪارين ۾ ظاهر ٿيو آهي انهن جي رڪنيتن سان هڪ ٻئي ڏانهن، هڪ نسل جي حالت جي ڪري.
• قسم جي شعبن سان ڊيٽا جي جوڙجڪ Option[Int] Int ۾ تبديل ٿي ويو جادوئي ڊفالٽ قدرن جهڙوڪ -1. بعد ۾ مون محسوس ڪيو ته مونگو ڊي بي json کي اسٽور ڪري ٿو ۽ اتي ان کي محفوظ ڪرڻ ۾ ڪجھ به غلط ناهي Option خير، يا گهٽ ۾ گهٽ پارس -1 جيئن ڪو به نه، پر ان وقت مون کي اها خبر نه هئي ۽ ان لاءِ منهنجو لفظ ورتو ويو ته ”اهڙيءَ طرح ٿيڻ گهرجي. مون اهو ڪوڊ نه لکيو آهي، ۽ مون ان کي تبديل ڪرڻ جي تڪليف نه ڪئي هئي.
• مون کي معلوم ٿيو ته منهنجو عوامي IP پتو بدلجي ٿو، ۽ هر ڀيري مون کي ان کي مونگو جي وائيٽ لسٽ ۾ شامل ڪرڻو پيو. مون بوٽ کي مقامي طور تي لانچ ڪيو، مونگا هڪ ڪمپني جي طور تي مونگا جي سرور تي ڪٿي هو.
• اوچتو، ٽيليگرام لاء ٽيگ ۽ پيغام جي فارميٽنگ جي معمولي غائب ٿي وئي. (ها، ائين ڇو ٿيندو؟)
• مون پسند ڪيو ته بوٽ جي رياست هڪ خارجي ڊيٽابيس ۾ ذخيرو ٿيل آهي، ۽ جڏهن ٻيهر شروع ٿئي ٿي ته اهو ڪم جاري رکي ٿو ڄڻ ته ڪجهه به نه ٿيو هجي. بهرحال، اهو صرف هڪ پلس هو.

ٻئي شخص کي ڪا خاص تڪڙ نه هئي، ۽ اهي سڀ تبديليون سيپٽمبر جي شروعات ۾ ئي هڪ وڏي ڍير ۾ ظاهر ٿيون. مون فوري طور تي تباهي جي پيماني تي قدر نه ڪيو ۽ ڊيٽابيس جي ڪم کي سمجهڻ شروع ڪيو، ڇاڪاڻ ته ... مون ان کان اڳ ڪڏهن به نه ڪيو آهي. صرف بعد ۾ مون محسوس ڪيو ته ڪيترو ڪم ڪندڙ ڪوڊ ڪٽيو ويو ۽ ان جي جاءِ تي ڪيترا بگ شامل ڪيا ويا.

سيپٽمبر

پهرين ۾ مون سوچيو ته اهو ڪارائتو هوندو مونگا کي ماسٽر ڪرڻ ۽ ان کي چڱي طرح ڪرڻ. پوءِ مان آهستي آهستي سمجهڻ لڳس ته ڊيٽابيس سان ڪميونيڪيشن کي منظم ڪرڻ به هڪ فن آهي جنهن ۾ توهان تمام گهڻيون ڊوڙون ۽ صرف غلطيون ڪري سگهو ٿا. مثال طور، جيڪڏهن صارف ٻه پيغام وصول ڪري ٿو جهڙوڪ /subscribe - ۽ هر هڪ جي جواب ۾ اسان ٽيبل ۾ هڪ داخلا ٺاهينداسين، ڇاڪاڻ ته انهن پيغامن جي پروسيسنگ وقت صارف رڪنيت حاصل نه ڪئي آهي. مون کي هڪ شڪ آهي ته مونگا سان ان جي موجوده شڪل ۾ رابطي کي بهترين طريقي سان نه لکيو ويو آهي. مثال طور، صارف جي سيٽنگون ٺاھيو ويو ھو ان وقت سائن اپ ڪيو. جيڪڏهن هن انهن کي سبسڪرپشن جي حقيقت کان پهريان تبديل ڪرڻ جي ڪوشش ڪئي ... بوٽ ڪجهه به جواب نه ڏنو، ڇو ته اداڪار ۾ ڪوڊ سيٽنگون لاء ڊيٽابيس ۾ ويو، اهو نه مليو ۽ تباهه ٿي ويو. جڏهن پڇيو ويو ته ضرورت مطابق سيٽنگون ڇو نه ٺاهيون، مون سکيو ته انهن کي تبديل ڪرڻ جي ڪا ضرورت ناهي جيڪڏهن صارف رڪنيت حاصل نه ڪئي آهي... ميسيج فلٽرنگ سسٽم ڪنهن به طرح غير واضح طور تي ٺاهيو ويو هو، ۽ ڪوڊ تي ويجهي نظر کان پوء به آئون ڪري سگهان ٿو. سمجهه ۾ نه ٿو اچي ته ڇا اهو مقصد هن طريقي سان شروع ڪيو ويو آهي يا اتي هڪ غلطي آهي.

چيٽ ۾ جمع ڪيل مضمونن جي ڪا به فهرست نه هئي؛ ان جي بدران، اهو تجويز ڪيو ويو ته آئون انهن کي پاڻ لکان. هن مون کي حيران ڪيو - عام طور تي، مان هر قسم جي شين کي پروجيڪٽ ۾ ڇڪڻ جي خلاف نه هو، پر اهو ان لاء منطقي هوندو جيڪو انهن شين کي اندر آندو ۽ انهن کي خراب ڪيو. پر نه، ٻيو حصو وٺندڙ هر شيءِ کي ڇڏي ڏيڻ لڳي، پر چيو ته چيٽ جي اندر لسٽ سمجهيو وڃي ته هڪ خراب حل هو، ۽ اهو ضروري هو ته واقعن سان هڪ نشاني ٺاهڻ جهڙوڪ "هڪ آرٽيڪل y صارف x ڏانهن موڪليو ويو." ان کان پوء، جيڪڏهن صارف نوان آرٽيڪل موڪلڻ جي درخواست ڪئي، ته ڊيٽابيس ڏانهن هڪ درخواست موڪلڻ ضروري هئي، جيڪو ايونٽس مان صارف سان لاڳاپيل واقعا چونڊيندو، نون مضمونن جي فهرست پڻ حاصل ڪري، انهن کي فلٽر ڪري، انهن کي صارف ڏانهن موڪليو. ۽ ان بابت واقعن کي واپس ڊيٽابيس ۾ اڇلايو.

ٻيو حصو وٺندڙ ڪنهن جاءِ تي تجريد جي طرف هليو ويو، جڏهن بوٽ نه صرف هيبر کان آرٽيڪل وصول ڪندو ۽ نه رڳو ٽيليگرام ڏانهن موڪليو ويندو.

مون سيپٽمبر جي ٻئي اڌ لاء هڪ الڳ نشاني جي صورت ۾ واقعن تي عمل ڪيو. اهو بهتر ناهي، پر گهٽ ۾ گهٽ بوٽ ڪم ڪرڻ شروع ڪيو ۽ مون کي ٻيهر آرٽيڪل موڪلڻ شروع ڪيو، ۽ مون کي آهستي آهستي معلوم ٿيو ته ڪوڊ ۾ ڇا ٿي رهيو آهي.

ھاڻي توھان شروعات ڏانھن واپس وڃو ۽ ياد رکو ته مخزن اصل ۾ مون پاران پيدا نه ڪيو ويو آھي. اهڙو ڇا ٿي سگهي ٿو؟ منهنجي موڪل جي درخواست رد ڪئي وئي. اهو ظاهر ٿيو ته مون وٽ ريڊنيڪ ڪوڊ هو، ته مون کي خبر ناهي ته هڪ ٽيم ۾ ڪيئن ڪم ڪجي، ۽ مون کي موجوده عمل درآمد واري وکر ۾ ڪيچ کي درست ڪرڻو هو، ۽ ان کي استعمال ڪرڻ جي قابل حالت کي بهتر نه ڪيو.

مان پريشان ٿي ويس ۽ ڪمٽ جي تاريخ ۽ لکيل ڪوڊ جي مقدار کي ڏٺو. مون انهن لمحن کي ڏٺو جيڪي اصل ۾ لکيا ويا هئا، ۽ پوءِ ڀڄي ويا ...

F*rk it

مون کي مضمون ياد آيو توهان گوگل نه آهيو.

مون سوچيو ته ڪنهن کي به حقيقت ۾ عمل ڪرڻ کان سواء هڪ خيال جي ضرورت آهي. مون سوچيو ته مان هڪ ڪم ڪندڙ بوٽ چاهيان ٿو، جيڪو هڪ ئي ڪمپيوٽر تي هڪ ئي ڪاپي ۾ ڪم ڪندو هڪ سادي جاوا پروگرام وانگر. مون کي خبر آهي ته منهنجو بوٽ مهينن تائين ڪم ڪندو بغير ٻيهر شروع ڪرڻ، ڇاڪاڻ ته مون اڳ ۾ ئي اهڙا بوٽ لکيا آهن. جيڪڏهن اهو اوچتو ڪري پوي ٿو ۽ صارف کي ٻيو مضمون نه موڪليندو، آسمان زمين تي نه ڪندو ۽ ڪجھ به تباهي نه ٿيندي.

مون کي ڇو ضرورت آهي Docker، mongoDB ۽ ٻين ڪارگو ڪلٽ جي ”سنگين“ سافٽ ويئر جيڪڏهن ڪوڊ صرف ڪم نٿو ڪري يا ڪڙي ڪم ڪري ٿو؟

مون پروجيڪٽ کي ٺهرايو ۽ سڀ ڪجهه ڪيو جيئن مون چاهيو.

ساڳئي وقت، مون نوڪريون بدلائي ڇڏيون ۽ مفت وقت تمام گهڻو گهٽجي ويو. صبح جو سمهي اٿم ٽرين تي، شام جو دير سان موٽيس ۽ هاڻي ڪجهه ڪرڻ نه پئي چاهيو. مون ٿوري دير لاءِ ڪجهه به نه ڪيو، پوءِ بوٽ کي ختم ڪرڻ جي خواهش مون تي غالب ٿي وئي، ۽ صبح جو ڪم ڪرڻ لاءِ ڊرائيونگ ڪندي مون آهستي آهستي ڪوڊ ٻيهر لکڻ شروع ڪيو. مان اهو نه چوندس ته اهو پيداواري هو: توهان جي گود تي هڪ ليپ ٽاپ سان گڏ هلندي ٽرين تي ويهڻ ۽ توهان جي فون مان اسٽيڪ اوور فلو ڏسڻ بلڪل آسان ناهي. بهرحال، ڪوڊ لکڻ جو وقت مڪمل طور تي اڻڄاتل طور تي اڏامي ويو، ۽ پروجيڪٽ آهستي آهستي ڪم ڪندڙ رياست ڏانهن وڌڻ لڳو.

منهنجي ذهن جي پٺڀرائي ۾ ڪٿي به شڪ جو هڪ ڪيڙو هو جيڪو مونگو ڊي بي کي استعمال ڪرڻ چاهيندو هو، پر مون سوچيو ته "قابل اعتماد" رياستي اسٽوريج جي فائدن کان علاوه، قابل ذڪر نقصان هئا:

• ڊيٽابيس ناڪامي جو هڪ ٻيو نقطو بڻجي ويندو آهي.
• ڪوڊ وڌيڪ پيچيده ٿي رهيو آهي، ۽ اهو مون کي ان کي لکڻ ۾ وڌيڪ وقت وٺندو.
• ڪوڊ سست ۽ غير موثر ٿي وڃي ٿو؛ ميموري ۾ هڪ اعتراض کي تبديل ڪرڻ جي بدران، تبديليون ڊيٽابيس ڏانهن موڪليا ويا آهن ۽، جيڪڏهن ضروري هجي ته، واپس کڄي وڃي.
• هڪ الڳ جدول ۾ واقعن جي اسٽوريج جي قسم تي پابنديون آهن، جيڪي ڊيٽابيس جي خاصيتن سان لاڳاپيل آهن.
• مونگا جي آزمائشي ورزن ۾ ڪجھ حدون آھن، ۽ جيڪڏھن توھان انھن ۾ ھلندا، توھان کي لانچ ڪرڻو پوندو ۽ مونگا کي ھڪڙي شيء تي ترتيب ڏيڻو پوندو.

مون مونگا کي ڪٽي ڇڏيو، هاڻي بوٽ جي حالت صرف پروگرام جي ميموري ۾ محفوظ ڪئي وئي آهي ۽ وقت بوقت 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. هڪ اداڪار جيڪو وقت بوقت آر ايس ايس فيڊ جو دورو ڪري ٿو، نون مضمونن جي باري ۾ سکي ٿو، لنڪس ڏسي ٿو، پارس ڪري ٿو، ۽ اهي آرٽيڪل پهرين اداڪار ڏانهن موڪلي ٿو. ان کان علاوه، اهو ڪڏهن ڪڏهن پهرين اداڪار کان آرٽيڪل جي هڪ فهرست جي درخواست ڪري ٿو، انهن کي چونڊيندو آهي جيڪي ٽن ڏينهن کان پراڻا نه آهن، پر گهڻو وقت تائين اپڊيٽ نه ڪيا ويا آهن، ۽ انهن کي تازه ڪاري ڪري ٿو.
3. هڪ اداڪار جيڪو ٽيليگرام سان رابطو ڪري ٿو. مون اڃا تائين پيغام مڪمل طور تي هتي آندو آهي. دوستانه انداز ۾، مان ان کي ٻن حصن ۾ ورهائڻ چاهيان ٿو - ته جيئن هڪ ايندڙ پيغامن کي پارس ڪري، ۽ ٻيو ٽرانسپورٽ جي مسئلن جهڙوڪ اڻ موڪليل پيغامن کي ٻيهر موڪلڻ سان. هاڻي ڪو به ٻيهر موڪلڻ وارو ناهي، ۽ هڪ پيغام جيڪو ڪنهن غلطي جي ڪري نه آيو آهي بس گم ٿي ويندو (جيستائين اهو لاگ ان ۾ نوٽ نه ڪيو ويو آهي)، پر هن وقت تائين اهو ڪو مسئلو ناهي. ٿي سگهي ٿو مسئلا پيدا ٿين جيڪڏهن ماڻهن جو هڪ گروپ بوٽ جي رڪنيت حاصل ڪري ۽ آئون پيغام موڪلڻ جي حد تائين پهچي وڃي).

جيڪو مون پسند ڪيو اهو آهي ته اڪا جي مهرباني، اداڪار 2 ۽ 3 جو زوال عام طور تي بوٽ جي ڪارڪردگي تي اثر انداز نٿو ڪري. شايد ڪجهه آرٽيڪل وقت تي اپڊيٽ نه ڪيا ويا آهن يا ڪجهه پيغام ٽيليگرام تائين نه پهچندا آهن، پر اڪائونٽ اداڪار ٻيهر شروع ڪري ٿو ۽ هر شي ڪم جاري رکي ٿي. مان معلومات محفوظ ڪريان ٿو ته مضمون صرف صارف کي ڏيکاريو ويو آهي جڏهن ٽيليگرام اداڪار جواب ڏئي ٿو ته هن ڪاميابيء سان پيغام پهچايو آهي. بدترين شيء جيڪا مون کي خطرو آهي اهو پيغام موڪلڻ لاء ڪيترائي ڀيرا آهي (جيڪڏهن اهو پهچايو ويو آهي، پر تصديق ڪنهن به طرح گم ٿي وئي آهي). اصول ۾، جيڪڏهن پهرين اداڪار پنهنجي اندر رياست کي ذخيرو نه ڪيو، پر ڪجهه ڊيٽابيس سان رابطو ڪيو، پوء هو ناقابل برداشت طور تي گر ٿي سگهي ٿو ۽ زندگي ڏانهن واپس اچي سگهي ٿو. مان اداڪارن جي حالت کي بحال ڪرڻ لاءِ اڪا ثابت قدمي جي ڪوشش پڻ ڪري سگهان ٿو، پر موجوده عمل مون کي ان جي سادگي سان مناسب آهي. اهو نه آهي ته منهنجو ڪوڊ اڪثر ڪري تباهه ٿي ويو آهي - ان جي برعڪس، مون ان کي ناممڪن بڻائڻ ۾ تمام گهڻي ڪوشش ڪئي. پر گندو ٿئي ٿو، ۽ پروگرام کي الڳ الڳ ٽڪرن ۾ ٽوڙڻ جي صلاحيت-اداڪار مون لاء واقعي آسان ۽ عملي لڳي.

مون دائرو-سي شامل ڪيو ته جيئن ڪوڊ ڀڃي، توهان کي فوري طور تي ان بابت معلوم ٿيندو. گهٽ ۾ گهٽ، ان جو مطلب اهو آهي ته ڪوڊ گڏ ڪرڻ بند ڪري ڇڏيو آهي. شروعات ۾ مون ٽريوس کي شامل ڪرڻ چاهيو، پر اهو صرف منهنجي منصوبن کي بغير ڪانٽو ڏيکاريو. عام طور تي، اهي ٻئي شيون آزاد طور تي کليل ذخيرو ۾ استعمال ڪري سگھجن ٿيون.

نتيجو

اهو اڳ ۾ ئي نومبر آهي. بوٽ لکيو ويو آهي، مان ان کي گذريل ٻن هفتن کان استعمال ڪري رهيو آهيان ۽ مون کي پسند ڪيو. جيڪڏهن توهان وٽ بهتري لاءِ خيال آهن، لکو. مان ان کي مانيٽائيز ڪرڻ ۾ نقطو نه ٿو ڏسان - ان کي صرف ڪم ڪرڻ ڏيو ۽ دلچسپ مضمون موڪليو.

بوٽ لنڪ: https://t.me/HabraFilterBot
گيتب: https://github.com/Kright/habrahabr_reader

ننڍا نتيجا:

• جيتوڻيڪ هڪ ننڍڙو منصوبو تمام گهڻو وقت وٺي سگھي ٿو.
• توهان گوگل نه آهيو. تپ مان چنگرين کي مارڻ جو ڪو به فائدو ناهي. ھڪڙو سادو حل شايد ڪم ڪري سگھي ٿو.
• پالتو پراجيڪٽ نون ٽيڪنالاجي سان تجربو ڪرڻ لاء تمام سٺو آهن.
• ٽيليگرام بوٽ بلڪل سادو لکيل آهن. جيڪڏهن اهو ”ٽيم ورڪ“ ۽ ٽيڪنالاجي سان تجربن لاءِ نه هجي ها ته بوٽ هڪ يا ٻن هفتن ۾ لکيو وڃي ها.
• اداڪار ماڊل هڪ دلچسپ شيء آهي جيڪا چڱي طرح سان گڏ ملٽي ٿريڊنگ ۽ غلطي برداشت ڪندڙ ڪوڊ سان گڏ آهي.
• مان سمجهان ٿو ته مون کي مزو مليو آهي ڇو ته اوپن سورس ڪميونٽي فورڪ سان پيار ڪندي آهي.
• ڊيٽابيس سٺا آهن ڇو ته ايپليڪيشن اسٽيٽ هاڻي ايپليڪيشن حادثن / ٻيهر شروع ٿيڻ تي منحصر ناهي، پر ڊيٽابيس سان ڪم ڪرڻ ڪوڊ کي پيچيده ڪري ٿو ۽ ڊيٽا جي جوڙجڪ تي پابنديون لاڳو ڪري ٿو.

جو ذريعو: www.habr.com