د ټیلیګرام بوټ د هابر څخه د مقالو شخصي انتخاب لپاره

د پوښتنو لپاره لکه "ولې؟" یوه پخوانۍ مقاله ده - طبیعي Geektimes - د ځای پاکولو جوړول.

ډیری مقالې شتون لري، د موضوعي دلایلو لپاره چې ځینې یې زه نه خوښوم، او ځینې یې، برعکس، د پریښودلو لپاره د افسوس ځای دی. زه غواړم دا پروسه اصلاح کړم او وخت خوندي کړم.

پورتنۍ مقالې د براوزر سکریپټینګ طریقه وړاندیز کړې ، مګر ما واقعیا دا نه خوښوله (که څه هم ما دمخه دا کارولې ده) د لاندې دلایلو لپاره:

• ستاسو په کمپیوټر / تلیفون کې د مختلف براوزرونو لپاره ، تاسو باید دا بیا تنظیم کړئ ، که امکان ولري.
• د لیکوالانو لخوا سخت فلټر کول تل اسانه ندي.
• د لیکوالانو ستونزه چې تاسو یې نه غواړئ له لاسه ورکړئ، حتی که دوی په کال کې یو ځل خپاره شي، حل شوي ندي.

د مقالې درجې پراساس په سایټ کې رامینځته شوي فلټر کول تل اسانه ندي ، ځکه چې خورا ځانګړي مقالې ، د دوی ارزښت سره سره ، کولی شي خورا معمولي درجه ترلاسه کړي.

په پیل کې، ما غوښتل چې د RSS فیډ (یا حتی څو) تولید کړم، یوازې په زړه پورې شیان پریږدم. مګر په پای کې، دا معلومه شوه چې د RSS لوستل خورا اسانه نه ښکاري: په هر حالت کې، د یوې مقالې لپاره تبصره / رایه ورکول / دا ستاسو په خوښې کې اضافه کول، تاسو باید د براوزر له لارې لاړ شئ. له همدې امله ما د ټیلیګرام بوټ لیکلی چې ما ته په شخصي پیغام کې په زړه پوري مقالې لیږي. ټیلیګرام پخپله له دوی څخه ښکلي لیدونه رامینځته کوي ، کوم چې د لیکوال / درجه بندي / لیدونو په اړه معلوماتو سره یوځای خورا معلوماتي ښکاري.

د کټ لاندې توضیحات دي لکه د کار ځانګړتیاوې، د لیکلو بهیر او تخنیکي حلونه.

په لنډه توګه د بوټو په اړه

ذخیره: https://github.com/Kright/habrahabr_reader

په ټیلیګرام کې بوټ: https://t.me/HabraFilterBot

کارن د ټاګونو او لیکوالانو لپاره اضافي درجه بندي ټاکي. له هغې وروسته، یو فلټر په مقالو کې پلي کیږي - د هابری په اړه د مقالې درجه، د لیکوال کاروونکي درجه او د ټاګ لخوا د کاروونکو درجه بندي اوسط اضافه شوي. که چیرې مقدار د کارونکي لخوا ټاکل شوي حد څخه ډیر وي ، نو مقاله فلټر تیریږي.

د بوټ لیکلو یو اړخ هدف ساتیري او تجربه ترلاسه کول وو. برسېره پردې، ما په منظمه توګه خپل ځان ته یادونه وکړه زه ګوګل نه یم، او له همدې امله ډیری شیان د امکان تر حده په ساده او حتی لومړني ډول ترسره کیږي. په هرصورت، دا د بوټ لیکلو بهیر د دریو میاشتو نیولو مخه نه نیسي.

بهر اوړي وه

جولای پای ته ورسیده، او ما پریکړه وکړه چې یو بوټ ولیکم. او یوازې نه، مګر د یو ملګري سره چې د سکالا ماسټر و او غوښتل یې په دې اړه یو څه ولیکي. پیل امید لرونکی ښکاریده - کوډ به د ټیم لخوا پرې شي ، کار اسانه ښکاري او ما فکر کاوه چې په څو اونیو یا یوه میاشت کې بوټ به چمتو شي.

د دې حقیقت سره سره چې زه پخپله د تیرو څو کلونو راهیسې وخت په وخت په ډبره کې کوډ لیکم ، هیڅوک معمولا دا کوډ نه ګوري یا نه ګوري: د پالتو پروژې ، د ځینې نظرونو ازموینه ، د معلوماتو دمخه پروسس کول ، د FP څخه ځینې مفکورې ماسټر کول. زه واقعیا علاقه لرم چې په ټیم کې د لیکلو کوډ څه ډول ښکاري ، ځکه چې په راک باندې کوډ په خورا مختلف ډول لیکل کیدی شي.

هغه څه چې تللي وي نو؟ په هرصورت، راځئ چې شیان ګړندي نه کړو.
هرڅه چې پیښیږي د ژمنې تاریخ په کارولو سره تعقیب کیدی شي.

یو آشنا د جولای په 27 یو ذخیره جوړه کړه، مګر نور څه یې ونه کړل، نو ما د کوډ لیکل پیل کړل.

30 جولای

په لنډه توګه: ما د حبر د آر ایس ایس فیډ تحلیل لیکلی.

• com.github.pureconfig په مستقیم ډول د قضیې ټولګیو کې د ډول خوندي ترتیبونو لوستلو لپاره (دا خورا اسانه وګرځید)
• scala-xml د xml لوستلو لپاره: ځکه چې په پیل کې ما غوښتل د آر ایس ایس فیډ لپاره خپل تطبیق ولیکم، او د آر ایس ایس فیډ په xml بڼه کې دی، ما دا کتابتون د پارس کولو لپاره کارولی. په حقیقت کې، د RSS پارسنګ هم څرګند شو.
• scalatest د ازموینو لپاره. حتی د کوچنیو پروژو لپاره ، د لیکلو ازموینې وخت خوندي کوي - د مثال په توګه ، کله چې د xml پارسینګ ډیبګ کول ، دا خورا اسانه ده چې دا فایل ته ډاونلوډ کړئ ، ازموینې ولیکئ او غلطۍ سم کړئ. کله چې وروسته یو بګ د یو څه عجیب html د غلط utf-8 حروفونو سره پارس کولو سره څرګند شو ، نو دا خورا اسانه وګرځید چې دا په فایل کې واچول شي او ازموینه اضافه کړئ.
• د اکا څخه لوبغاړي. په معقول ډول، دوی ته اړتیا نه وه، مګر پروژه د ساتیرۍ لپاره لیکل شوې وه، زه غواړم دوی هڅه وکړم. د پایلې په توګه، زه چمتو یم چې ووایم چې ما دا خوښ کړ. د OOP مفکوره د بل اړخ څخه لیدل کیدی شي - داسې لوبغاړي شتون لري چې پیغامونه تبادله کوي. هغه څه چې ډیر په زړه پوري دي دا دي چې تاسو کولی شئ (او باید) کوډ په داسې ډول ولیکئ چې پیغام ممکن نه وي یا پروسس نشي (په عموم ډول ، کله چې حساب په یو واحد کمپیوټر کې روان وي ، پیغامونه باید ورک نشي). په لومړي سر کې ما خپل سر وخوځاوه او په کوډ کې کثافات شتون درلود چې لوبغاړو یو بل ته ګډون کړی و ، مګر په پای کې ما وکولی شوم د ساده او ښکلي جوړښت سره راشي. د هر اداکار دننه کوډ کولی شي واحد تاریډ وګڼل شي؛ کله چې یو لوبغاړی حادثه شي، اکا دا بیا پیلوي - پایله یې د کافي غلط زغم سیسټم دی.

9 اګست

ما په پروژه کې اضافه کړه scala-scrapper د هابر څخه د html مخونو د پارس کولو لپاره (د معلوماتو د ایستلو لپاره لکه د مقالې درجه بندي، د بک مارکونو شمیر، او نور).

او بلی. هغه چې په ډبره کې دي.

ما بیا د توزیع شوي ډیټابیسونو په اړه یو کتاب ولوست، ما د CRDT نظر خوښ کړ (د شخړو څخه پاک نقل شوي ډیټا ډول، https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr)، نو ما د Habré په اړه د مقالې په اړه د معلوماتو لپاره د بدلیدونکي نیم ګروپ ډول ډول ټولګي پوسټ کړل.

په حقیقت کې، مفکوره خورا ساده ده - موږ کاونټرونه لرو چې په واحد ډول بدلوي. د ترویجونو شمیر په تدریجي ډول وده کوي ، لکه څنګه چې د پلسونو شمیر (او همدارنګه د منفيونو شمیر). که زه د یوې مقالې په اړه د معلوماتو دوه نسخې لرم، نو زه کولی شم "دوی په یوه کې ضمیمه کړم" - د کاونټر حالت چې لوی دی ډیر اړونده ګڼل کیږي.

د نیم ګروپ معنی دا ده چې دوه شیان د یوې مقالې په اړه معلومات سره یوځای کیدی شي. متقابل معنی دا ده چې تاسو کولی شئ دواړه A + B او B + A سره یوځای کړئ، پایله په ترتیب پورې اړه نلري، او په پای کې به نوې نسخه پاتې شي. په هرصورت، دلته هم ملګرتیا شتون لري.

د مثال په توګه، لکه څنګه چې پالن شوی، آر ایس ایس د تحلیل وروسته د مقالې په اړه یو څه ضعیف معلومات چمتو کړي - پرته له میټریکونو لکه د لیدونو شمیر. یو ځانګړی لوبغاړی بیا د مقالو په اړه معلومات ترلاسه کړل او د html پاڼې ته ورغی ترڅو دا تازه کړي او د زاړه نسخې سره یوځای کړي.

په عموم کې ، لکه څنګه چې په اکا کې ، دې ته اړتیا نه وه ، تاسو کولی شئ په ساده ډول د مقالې لپاره تازه نیټه ذخیره کړئ او پرته له کوم ادغام څخه یو نوی واخلئ ، مګر د ساہسک لاره ما رهبري کړه.

12 اګست

ما د آزادۍ احساس پیل کړ او یوازې د ساتیرۍ لپاره ، ما هر چیټ یو جلا لوبغاړی جوړ کړ. په تیوریکي توګه، یو لوبغاړی پخپله شاوخوا 300 بایټ وزن لري او دوی په ملیونونو کې رامینځته کیدی شي، نو دا په بشپړه توګه عادي طریقه ده. ماته داسې ښکاري چې حل خورا په زړه پورې وګرځید:

یو لوبغاړی په اکا کې د ټیلیګرام سرور او پیغام سیسټم تر منځ یو پل و. هغه په ​​ساده ډول پیغامونه ترلاسه کړل او د مطلوب چیٹ اداکار ته یې واستول. د چیٹ لوبغاړی کولی شي په ځواب کې یو څه بیرته واستوي - او دا به بیرته ټیلیګرام ته واستول شي. هغه څه چې خورا اسانه وو دا دی چې دا لوبغاړی د امکان تر حده ساده و او یوازې پیغامونو ته د ځواب ویلو منطق درلود. په هرصورت، هر چیٹ ته د نویو مقالو په اړه معلومات راغلل، مګر بیا زه پدې کې کومه ستونزه نه وینم.

په عموم کې ، بوټ لا دمخه کار کاوه ، پیغامونو ته ځواب ویل ، کارونکي ته لیږل شوي مقالو لیست ذخیره کول ، او ما دمخه فکر کاوه چې بوټ نږدې چمتو و. ما ورو ورو لږ ځانګړتیاوې اضافه کړې لکه د لیکوال نومونه او ټاګونه نورمال کول (د "s_d_f" سره د "sd f" ځای په ځای کول).

یوازې یو شی پاتې و کوچنی مګر - دولت په هیڅ ځای کې نه دی ژغورل شوی.

هر څه غلط شول

تاسو شاید لیدلي وي چې ما بوټان اکثرا یوازې لیکلي. نو، دویم ګډونوال په پراختیا کې ښکیل شو، او لاندې بدلونونه په کوډ کې ښکاره شول:

• MongoDB د ریاست ذخیره کولو لپاره ښکاره شو. په ورته وخت کې، په پروژه کې لاګونه مات شوي، ځکه چې د ځینو دلیلونو لپاره مونګا دوی سپیم کول پیل کړل او ځینو خلکو په ساده ډول دوی په نړیواله کچه بند کړل.
• په ټیلیګرام کې د پل لوبغاړی د پیژندلو څخه بهر بدل شوی و او پخپله یې د پیغامونو تحلیل پیل کړ.
• د چیټونو لپاره لوبغاړي په بې رحمۍ سره قطع شوي، او پرځای یې دوی د یو لوبغاړی لخوا ځای پرځای شوي چې په یوځل کې د ټولو چیټونو په اړه ټول معلومات پټ کړي. د هرې پرنجي لپاره، دا لوبغاړی له ستونزو سره مخ شو. ښه، هو، لکه کله چې د یوې مقالې په اړه معلومات تازه کړئ، د ټولو چیټ لوبغاړو ته یې لیږل ستونزمن کار دی (موږ د ګوګل په څیر یو، ملیونونه کاروونکي د هر یو لپاره په چیٹ کې یو ملیون مقالو ته انتظار باسي)، مګر هرکله چې چیٹ تازه شي، مونګا ته تلل عادي خبره ده. لکه څنګه چې زه ډیر وروسته پوه شوم ، د چیټونو کاري منطق هم په بشپړ ډول قطع شوی و او د هغې په ځای کې یو څه څرګند شو چې کار نه کوي.
• د ډول ټولګیو هیڅ نښه پاتې نه ده.
• ځینې ​​ناخوښه منطق په اداکارانو کې د دوی د ګډون سره یو بل ته څرګند شوي چې د نسل حالت ته لاره هواروي.
• د معلوماتو جوړښتونه د ډولونو ساحو سره Option[Int] د جادویی ډیفالټ ارزښتونو لکه -1 سره په Int بدل شوی. وروسته زه پوه شوم چې mongoDB json ذخیره کوي او هلته یې په ذخیره کولو کې هیڅ غلط ندي Option ښه، یا لږترلږه -1 د هیڅ په توګه پارس کړئ، مګر هغه وخت زه پدې نه پوهیدم او د دې لپاره یې زما کلمه واخیسته چې "دا باید څنګه وي." ما دا کوډ نه دی لیکلی، او ما د وخت لپاره د دې بدلولو زحمت نه دی کړی.
• ما وموندله چې زما عامه IP پته بدلیږي، او هرکله چې زه باید دا د مونګو په سپین لیست کې اضافه کړم. ما بوټ په ځایی ډول پیل کړ، مونګا د شرکت په توګه د مونګا په سرورونو کې چیرته و.
• ناڅاپه، د ټیلیګرامونو لپاره د ټاګونو او پیغام فارمیټینګ نورمال کول ورک شول. (هو، دا به ولې وي؟)
• ما خوښ کړ چې د بوټ حالت په بهرني ډیټابیس کې زیرمه شوی ، او کله چې بیا پیل شي دا کار ته دوام ورکوي لکه څنګه چې هیڅ پیښ شوي ندي. په هرصورت، دا یوازینی پلس و.

دوهم کس په ځانګړې توګه په چټکۍ کې نه و، او دا ټول بدلونونه د سپتمبر په پیل کې په یوه لوی کڅوړه کې ښکاره شول. ما سمدلاسه د پایلې ویجاړې کچې ستاینه ونه کړه او د ډیټابیس کار په پوهیدو پیل وکړ ، ځکه چې ... ما مخکې هیڅکله له دوی سره معامله نه ده کړې. یوازې وروسته زه پوه شوم چې څومره کاري کوډ پرې شوی او څومره کیګونه یې په ځای کې اضافه شوي.

سپتمبر

په لومړي سر کې ما فکر کاوه چې دا به ګټور وي چې د مونګا ماسټر کړئ او ښه یې ترسره کړئ. بیا زه ورو ورو پوه شوم چې د ډیټابیس سره د اړیکو تنظیم کول هم یو هنر دی چې تاسو کولی شئ ډیری ریسونه وکړئ او یوازې غلطي وکړئ. د مثال په توګه، که کاروونکي دوه پیغامونه ترلاسه کړي لکه /subscribe - او د هر یو په ځواب کې به موږ په جدول کې ننوتل رامینځته کړو ، ځکه چې د دې پیغامونو پروسس کولو په وخت کې کارونکي ګډون نه کوي. زه شک لرم چې د مونګا سره په خپل اوسني شکل کې اړیکه په غوره طریقه نه ده لیکل شوې. د مثال په توګه، د کارونکي تنظیمات په هغه وخت کې رامینځته شوي چې هغه لاسلیک کړی. که هغه د ګډون کولو حقیقت څخه دمخه د دوی د بدلولو هڅه وکړه ... بوټ هیڅ ځواب ورنکړل ، ځکه چې په اداکار کې کوډ د تنظیماتو لپاره ډیټابیس ته لاړ ، ونه موند او خراب شو. کله چې وپوښتل شول چې ولې د اړتیا سره سم تنظیمات نه رامینځته کوئ ، ما زده کړل چې د دوی بدلولو ته اړتیا نشته که چیرې کارونکي ګډون نه وي کړی ... د پیغام فلټر کولو سیسټم یو څه په غیر څرګند ډول رامینځته شوی و ، او حتی کوډ ته له نږدې لید وروسته زه کولی شم نه پوهیږم چې ایا دا په پیل کې دا ډول اراده وه یا هلته کومه تېروتنه شتون لري.

چیټ ته د سپارل شوي مقالو کوم لیست نه و؛ پرځای یې، وړاندیز شوی و چې زه یې پخپله ولیکم. دې ما حیران کړ - په عموم کې، زه په پروژه کې د هر ډول شیانو د راښکته کولو مخالف نه وم، مګر دا به د هغه چا لپاره منطقي وي چې دا شیان راوړي او دوی یې خراب کړي. مګر نه ، دوهم ګډون کونکي داسې بریښي چې هرڅه یې پریږدي ، مګر وویل چې د چیٹ دننه لیست انګیرل یو خراب حل و ، او دا اړینه وه چې د پیښو سره نښه جوړه کړئ لکه "یوه مقاله y کارن x ته لیږل شوې وه." بیا ، که چیرې کارونکي د نوي مقالو لیږلو غوښتنه وکړي ، نو اړینه وه چې ډیټابیس ته غوښتنه واستول شي ، کوم چې به د پیښو څخه د کارونکي پورې اړوند پیښې غوره کړي ، د نوي مقالو لیست هم ترلاسه کړي ، فلټر یې کړي ، کارونکي ته یې واستوي. او د دې په اړه پیښې بیرته ډیټابیس ته وغورځوئ.

دوهم ګډون کونکی د خلاصون په لور یو ځای لیږدول شوی و ، کله چې بوټ به نه یوازې د هابر څخه مقالې ترلاسه کړي او نه یوازې ټیلیګرام ته لیږل کیږي.

ما یو څه د سپتمبر د دوهمې نیمایي لپاره د جلا نښې په توګه پیښې پلي کړې. دا غوره نه دی، مګر لږترلږه بوټ کار پیل کړ او ما ته یې بیا مقالې لیږل پیل کړل، او ما ورو ورو معلومه کړه چې په کوډ کې څه پیښیږي.

اوس تاسو بیرته پیل ته لاړ شئ او په یاد ولرئ چې ذخیره په اصل کې زما لخوا نه وه رامینځته شوې. په دې ډول به څه تېر شوي وي؟ زما د وتلو غوښتنه رد شوه. دا معلومه شوه چې ما د ریډ نیک کوډ درلود، چې زه نه پوهیدم چې څنګه په ټیم کې کار وکړم، او ما باید د اوسني پلي کولو منحل کې کیګونه حل کړم، او دا د کارونې وړ حالت ته نه اصالح کړم.

زه خپه شوم او د ژمنې تاریخ او د لیکل شوي کوډ مقدار ته یې وکتل. ما هغه شیبو ته وکتل چې په اصل کې ښه لیکل شوي وو، او بیا بیرته مات شوي ...

F*رک یې کړئ

ما مقاله یاد کړه تاسو ګوګل نه یاست.

ما فکر کاوه چې هیڅ څوک واقعیا پرته له پلي کیدو څخه مفکورې ته اړتیا نلري. ما فکر کاوه چې زه غواړم یو کاري بوټ ولرم، کوم چې به په یو واحد کمپیوټر کې د ساده جاوا پروګرام په توګه کار وکړي. زه پوهیږم چې زما بوټ به د میاشتو لپاره کار وکړي پرته لدې چې بیا پیل شي ، ځکه چې ما دمخه دا ډول بوټونه لیکلي دي. که دا ناڅاپه راښکته شي او کارونکي ته بله مقاله ونه لیږي ، اسمان به ځمکې ته راښکته نشي او هیڅ ناورین به پیښ نشي.

زه ولې د "جدي" سافټویر ډاکر ، مونګو ډی بی او نورو کارګو کلټ ته اړتیا لرم که چیرې کوډ په ساده ډول کار نه کوي یا په کره توګه کار کوي؟

ما پروژه جوړه کړه او هرڅه یې وکړل لکه څنګه چې ما غوښتل.

په ورته وخت کې، ما دندې بدلې کړې او وړیا وخت خورا کم شو. سهار زه په ریل ګاډي کې له خوبه پاڅیدم، ماښام ناوخته راستون شوم او نور نه غوښتل چې څه وکړم. ما د یو څه وخت لپاره هیڅ ونه کړل، بیا د بوټ پای ته رسولو لیوالتیا په ما باندې غالبه شوه، او ما په ورو ورو د کوډ لیکل پیل کړل پداسې حال کې چې زه سهار کار ته روان وم. زه به ونه وایم چې دا ګټور و: ستاسو په غیږ کې د لپ ټاپ سره په ټوپ وهونکي ریل کې ناست او ستاسو د تلیفون څخه د سټیک اوور فلو ته کتل خورا اسانه ندي. په هرصورت، د کوډ لیکلو وخت په بشپړه توګه د پام وړ نه و، او پروژه ورو ورو د کاري حالت په لور حرکت پیل کړ.

زما د ذهن په شا کې یو ځای د شک یو کیم و چې غوښتل یې مونګو ډی بی وکاروي ، مګر ما فکر کاوه چې د "معتبر" دولتي ذخیره کولو ګټو سربیره ، د پام وړ زیانونه هم شتون لري:

• ډیټابیس د ناکامۍ بل ټکی کیږي.
• کوډ ډیر پیچلی کیږي، او دا به زما د لیکلو لپاره ډیر وخت ونیسي.
• کوډ ورو او غیر موثر کیږي؛ د دې پرځای چې په حافظه کې یو څیز بدل کړي، بدلونونه ډیټابیس ته لیږل کیږي او که اړتیا وي، بیرته راګرځول کیږي.
• په جلا جدول کې د پیښو د ذخیره کولو ډول محدودیتونه شتون لري، کوم چې د ډیټابیس ځانګړتیاوو سره تړاو لري.
• د مونګا آزموینې نسخه ځینې محدودیتونه لري، او که تاسو دوی ته ورشئ، نو تاسو به مونګ په یو څه پیل او تنظیم کړئ.

ما مونګا پرې کړه ، اوس د بوټ حالت په ساده ډول د برنامه حافظه کې زیرمه شوی او وخت په وخت د 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 زوال عموما د بوټ فعالیت اغیزه نه کوي. شاید ځینې مقالې په خپل وخت تازه نه وي یا ځینې پیغامونه ټیلیګرام ته نه رسیږي، مګر اکاونټ لوبغاړی بیا پیلوي او هرڅه کار ته دوام ورکوي. زه هغه معلومات خوندي کوم چې مقاله یوازې هغه وخت کارونکي ته ښودل کیږي کله چې د ټیلیګرام لوبغاړی ځواب ووایی چې هغه په ​​​​بریالیتوب سره پیغام رسولی دی. ترټولو بد شی چې ما ته ګواښ کوي دا دی چې پیغام څو ځله واستول شي (که چیرې دا ورکړل شي، مګر تایید یو څه ورک شوی وي). په اصولو کې، که لومړی لوبغاړی دولت په خپل ځان کې ذخیره نه کړي، مګر د ځینې ډیټابیس سره اړیکه ونیسي، نو هغه هم په ناڅاپي توګه راوتلی شي او ژوند ته راستون شي. زه هم کولی شم د اکا ثابته هڅه وکړم چې د لوبغاړو حالت بیرته راولي، مګر اوسنی تطبیق زما د سادګۍ سره مناسب دی. دا نده چې زما کوډ ډیری وختونه ټکر شوی - برعکس ، ما د دې ناممکن کولو لپاره خورا ډیرې هڅې وکړې. مګر شیټ پیښیږي ، او د برنامه په جلا جلا برخو کې د لوبغاړو د ماتولو وړتیا زما لپاره واقعیا اسانه او عملي ښکاري.

ما حلقه-ci اضافه کړه نو که کوډ مات شي، تاسو به سمدلاسه د هغې په اړه ومومئ. لږترلږه، دا پدې مانا ده چې کوډ تالیف بند کړی دی. په پیل کې ما غوښتل ټراوس اضافه کړم، مګر دا یوازې زما پروژې پرته له فورکس ښودلې. په عموم کې، دا دواړه شیان په آزاده توګه په خلاص ذخیره کې کارول کیدی شي.

پایلې

دا لا دمخه نومبر دی. بوټ لیکل شوی، زه دا د تیرو دوو اونیو راهیسې کاروم او ما خوښ کړ. که تاسو د پرمختګ لپاره نظرونه لرئ، ولیکئ. زه د دې د پیسو مینځلو کې نقطه نه ګورم - اجازه راکړئ یوازې کار وکړئ او په زړه پوري مقالې واستوئ.

د بوټ لینک: https://t.me/HabraFilterBot
ګیتوب: https://github.com/Kright/habrahabr_reader

کوچنۍ پایلې:

• حتی یوه کوچنۍ پروژه کولی شي ډیر وخت ونیسي.
• تاسو ګوګل نه یاست. له توپ څخه د چرګانو ډزې کول هیڅ معنی نلري. یو ساده حل ممکن هم کار وکړي.
• د پالتو پروژې د نوي ټیکنالوژیو تجربه کولو لپاره خورا ښه دي.
• د ټیلیګرام بوټونه په ساده ډول لیکل شوي. که دا د "ټیم ورک" لپاره نه و او د ټیکنالوژۍ سره تجربې، بوټ به په یوه یا دوو اونیو کې لیکل شوي وای.
• د اداکار ماډل یو په زړه پوری شی دی چې د څو-تریډینګ او غلطۍ زغم کوډ سره ښه پرمخ ځي.
• زه فکر کوم چې ما یو خوند ترلاسه کړ چې ولې د خلاصې سرچینې ټولنه فورکس خوښوي.
• ډیټابیسونه ښه دي ځکه چې د غوښتنلیک حالت نور د غوښتنلیک په کریش / بیا پیل کیدو پورې اړه نلري ، مګر د ډیټابیس سره کار کول کوډ پیچلی کوي او د ډیټا جوړښت باندې محدودیتونه وضع کوي.

سرچینه: www.habr.com