Telegram бот нь Habr-аас хувийн нийтлэлүүдийг сонгох боломжтой

"Яагаад?" гэх мэт асуултуудын хувьд. хуучин нийтлэл байна - Natural Geektimes - орон зайг цэвэрлэгч болгох.

Маш олон нийтлэл байдаг, субьектив шалтгааны улмаас зарим нь надад таалагддаггүй, зарим нь эсрэгээрээ алгасах нь харамсалтай. Би энэ үйл явцыг оновчтой болгож, цаг хугацаа хэмнэхийг хүсч байна.

Дээрх нийтлэл нь хөтөч доторх скрипт хийх аргыг санал болгосон боловч дараах шалтгааны улмаас надад үнэхээр таалагдаагүй (хэдийгээр би үүнийг өмнө нь ашиглаж байсан ч):

• Таны компьютер/утас дээрх өөр хөтчүүдийн хувьд боломжтой бол дахин тохируулах хэрэгтэй.
• Зохиогчийн хатуу шүүлтүүр нь үргэлж тохиромжтой байдаггүй.
• Жилд нэг удаа хэвлэгддэг байсан ч нийтлэлээ орхигдуулахыг хүсдэггүй зохиолчдын асуудал шийдэгдээгүй байна.

Сайт руу оруулсан нийтлэлийн үнэлгээнд үндэслэн шүүлтүүр хийх нь үргэлж тохиромжтой байдаггүй, учир нь өндөр мэргэшсэн нийтлэлүүд үнэ цэнэтэй хэдий ч бага зэрэг үнэлгээ авч чаддаг.

Эхэндээ би RSS feed (эсвэл бүр хэд хэдэн) үүсгэхийг хүссэн бөгөөд тэнд зөвхөн сонирхолтой зүйлсийг үлдээсэн. Гэвч эцэст нь RSS унших нь тийм ч тохиромжтой биш мэт санагдсан: ямар ч тохиолдолд нийтлэлд сэтгэгдэл бичих/санал өгөх/дуртай нийтлэлдээ нэмэхийн тулд та хөтөчөөр нэвтрэх хэрэгтэй. Тийм ч учраас би хувийн мессежээр надад сонирхолтой нийтлэл илгээдэг телеграм бот бичсэн. Telegram өөрөө тэднээс үзэсгэлэнтэй урьдчилан харах боломжийг олгодог бөгөөд энэ нь зохиогч/үнэлгээ/үзэлтийн талаарх мэдээлэлтэй хослуулан нэлээд мэдээлэлтэй харагдаж байна.

Зүссэн хэсгийн доор ажлын онцлог, бичих үйл явц, техникийн шийдэл зэрэг дэлгэрэнгүй мэдээлэл байна.

Ботын тухай товчхон

Хадгалах газар: https://github.com/Kright/habrahabr_reader

Telegram дахь бот: https://t.me/HabraFilterBot

Хэрэглэгч шошго болон зохиогчдод нэмэлт үнэлгээ өгдөг. Үүний дараа нийтлэлд шүүлтүүр хэрэглэнэ - Хабре дээрх нийтлэлийн үнэлгээ, зохиогчийн хэрэглэгчийн үнэлгээ, шошгон дээрх хэрэглэгчийн үнэлгээний дундажийг нэмнэ. Хэрэв дүн нь хэрэглэгчийн тодорхойлсон босго хэмжээнээс их байвал нийтлэл шүүлтүүрийг давна.

Бот бичих гол зорилго нь хөгжилтэй, туршлага хуримтлуулах явдал байв. Үүнээс гадна би үүнийг өөртөө байнга сануулдаг Би Google биш, тиймээс олон зүйлийг аль болох энгийн бөгөөд бүр анхдагч байдлаар хийдэг. Гэсэн хэдий ч энэ нь роботыг бичих үйл явцыг гурван сар болоход саад болоогүй юм.

Гадаа зун байсан

Долдугаар сар дуусч байсан тул би бот бичихээр шийдлээ. Ганцаараа биш, скалагаар хичээллэж байсан найзтайгаа түүн дээр юм бичмээр санагдлаа. Эхлэл нь ирээдүйтэй харагдаж байв - кодыг баг нь таслах болно, даалгавар нь хялбар мэт санагдаж, хоёр долоо хоног эсвэл сарын дараа бот бэлэн болно гэж бодсон.

Би өөрөө сүүлийн хэдэн жил хадан дээр үе үе код бичиж байгаа хэдий ч энэ кодыг хэн ч харж, хардаггүй: гэрийн тэжээвэр амьтдын төслүүд, зарим санааг туршиж үзэх, өгөгдлийг урьдчилан боловсруулах, FP-ийн зарим ойлголтыг эзэмших. Чулуун дээрх кодыг маш өөр хэлбэрээр бичиж болох тул багийн код бичих ямар байдгийг би үнэхээр сонирхож байсан.

Юу явж болох байсан тэгээд? Гэсэн хэдий ч яарах хэрэггүй.
Үйлдлийн түүхийг ашиглан болж буй бүх зүйлийг хянах боломжтой.

Нэг танил маань 27-р сарын XNUMX-нд репозитор үүсгэсэн боловч өөр зүйл хийгээгүй тул код бичиж эхэлсэн.

30 долдугаар сар

Товчхондоо: Би Хабрын rss feed-ийн задлан шинжлэлийг бичсэн.

• com.github.pureconfig typesafe тохиргоог кейс ангид шууд уншихад зориулагдсан (энэ нь маш тохиромжтой болсон)
• scala-xml xml уншихад: анх rss feed-д зориулж өөрийн хэрэгжүүлэлтийг бичихийг хүсч байсан бөгөөд rss feed нь xml форматтай тул би энэ номын санг задлан шинжлэхэд ашигласан. Үнэн хэрэгтээ RSS задлан шинжлэл бас гарч ирэв.
• scalatest туршилтын хувьд. Жижиг төслүүдийн хувьд ч гэсэн тест бичих нь цаг хугацаа хэмнэдэг - жишээлбэл, xml задлан шинжилгээг дибаг хийх үед үүнийг файл руу татаж авах, тест бичих, алдаа засах нь илүү хялбар байдаг. Дараа нь хүчингүй utf-8 тэмдэгт бүхий хачирхалтай html-г задлахад алдаа гарч ирэхэд үүнийг файлд оруулаад тест нэмэх нь илүү тохиромжтой болсон.
• Аккагийн жүжигчид. Объективийн хувьд тэд огт хэрэггүй байсан ч төслийг зугаацуулах зорилгоор бичсэн тул би тэднийг туршиж үзэхийг хүссэн. Үүний үр дүнд би таалагдсан гэж хэлэхэд бэлэн байна. OOP санааг нөгөө талаас нь харж болно - мессеж солилцдог жүжигчид байдаг. Хамгийн сонирхолтой нь та мессеж ирэхгүй эсвэл боловсруулагдахгүй байхаар код бичих боломжтой (мөн хийх ёстой) (ерөнхийдөө, данс нэг компьютер дээр ажиллаж байх үед мессеж алга болохгүй). Эхлээд би толгойгоо маажиж, кодонд жүжигчид хоорондоо захиалгаа өгсөн хог байсан боловч эцэст нь би нэлээд энгийн бөгөөд гоёмсог архитектурыг гаргаж чадсан. Жүжигчин бүрийн доторх кодыг нэг урсгалтай гэж үзэж болно; жүжигчин осолдох үед acca үүнийг дахин эхлүүлдэг - үр дүн нь нэлээд алдаатай тэсвэртэй систем юм.

9

Би төсөлд нэмсэн scala-scrapper Habr-аас 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] -1 гэх мэт ид шидийн анхдагч утгуудтай Int болж хувирав. Дараа нь би mongoDB json-г хадгалдаг бөгөөд тэнд хадгалахад буруудах зүйлгүй гэдгийг ойлгосон Option сайн, эсвэл ядаж -1-ийг None гэж задлан шинжилнэ үү, гэхдээ тэр үед би үүнийг мэдэхгүй байсан бөгөөд "ийм байх ёстой" гэсэн үгтэй байсан. Би энэ кодыг бичээгүй бөгөөд одоохондоо үүнийг өөрчлөх гэж санаа зовоогүй.
• Миний нийтийн IP хаяг өөрчлөгдөх хандлагатай байдгийг олж мэдсэн бөгөөд тэр болгондоо үүнийг Mongo-ийн цагаан жагсаалтад оруулах шаардлагатай болдог. Би ботыг дотооддоо ажиллуулсан, Monga компани Monga-гийн сервер дээр хаа нэгтээ байсан.
• Гэнэт телеграмд ​​зориулсан шошго, мессежийн форматыг хэвийн болгох нь алга болов. (Хмм, яагаад ийм байх болов?)
• Ботын төлөв нь гадаад мэдээллийн санд хадгалагдаж, дахин асаахад юу ч болоогүй юм шиг ажиллаж байгаа нь надад таалагдсан. Гэсэн хэдий ч энэ нь цорын ганц давуу тал байсан.

Хоёр дахь хүн яарах зүйлгүй байсан бөгөөд эдгээр бүх өөрчлөлтүүд XNUMX-р сарын эхээр нэг том бөөгнөрөл дээр гарч ирэв. Үүний үр дүнд үүссэн сүйрлийн цар хүрээг би тэр даруй үнэлээгүй бөгөөд мэдээллийн сангийн ажлыг ойлгож эхэлсэн, учир нь ... Би өмнө нь тэдэнтэй харьцаж байгаагүй. Хэр их ажлын кодыг хасч, оронд нь хичнээн алдаа нэмсэнийг би сүүлд л ойлгосон.

Есдүгээр сар

Анх Монгааг эзэмшиж, сайн хийвэл хэрэг болно гэж бодсон. Дараа нь би мэдээллийн сантай харилцах харилцааг зохион байгуулах нь маш их уралддаг, зүгээр л алдаа гаргадаг урлаг гэдгийг аажмаар ойлгож эхэлсэн. Жишээлбэл, хэрэв хэрэглэгч гэх мэт хоёр мессеж хүлээн авбал /subscribe - мөн тус бүрийн хариуд бид хүснэгтэд оруулга үүсгэх болно, учир нь эдгээр мессежийг боловсруулах үед хэрэглэгч бүртгүүлээгүй болно. Монгатай одоогийн байдлаар харилцах нь тийм ч сайн бичигдээгүй байна гэсэн хардлага төрж байна. Жишээлбэл, хэрэглэгчийн тохиргоог бүртгүүлэх үед үүсгэсэн. Хэрэв тэр бүртгүүлэхээс өмнө тэдгээрийг өөрчлөхийг оролдсон бол ... бот юу ч хариулсангүй, учир нь жүжигчний код нь тохиргооны мэдээллийн санд орж, түүнийг олоогүй бөгөөд гацсан. Яагаад шаардлагатай бол тохиргоог үүсгэж болохгүй гэж асуухад хэрэглэгч захиалаагүй бол өөрчлөх шаардлагагүй гэдгийг би мэдсэн... Мессеж шүүлтүүрийн систем нь ямар нэгэн байдлаар тодорхой бус байдлаар хийгдсэн бөгөөд кодыг сайтар ажигласны дараа ч би үүнийг хийх боломжтой болсон. Энэ нь анхнаасаа ийм зорилготой байсан уу, эсвэл энд алдаа байна уу гэдгийг ойлгохгүй байна.

Чатанд оруулсан нийтлэлийн жагсаалт байхгүй, харин би өөрөө бичихийг санал болгосон. Энэ нь намайг гайхшруулсан - ерөнхийдөө би бүх төрлийн зүйлийг төсөлд чирэхийн эсрэг биш байсан, гэхдээ эдгээр зүйлийг авчирч, эргүүлсэн хүний ​​хувьд энэ нь логик байх болно. Гэхдээ үгүй, хоёр дахь оролцогч бүх зүйлд бууж өгсөн мэт боловч чат доторх жагсаалт нь муу шийдэл байсан тул "х хэрэглэгч рүү y нийтлэл илгээгдсэн" гэх мэт үйл явдлуудтай тэмдэг тавих шаардлагатай гэж хэлсэн. Дараа нь хэрэглэгч шинэ нийтлэл илгээхийг хүссэн тохиолдолд тухайн үйл явдлуудаас хэрэглэгчтэй холбоотой үйл явдлуудыг сонгож, шинэ нийтлэлүүдийн жагсаалтыг авч, шүүж, хэрэглэгч рүү илгээх хүсэлтийг мэдээллийн санд илгээх шаардлагатай байв. мөн энэ талаарх үйл явдлуудыг мэдээллийн санд буцааж шидэх.

Хоёр дахь оролцогчийг хийсвэрлэл рүү аваачсан бөгөөд тэр үед бот нь зөвхөн Хабраас нийтлэл хүлээн авах төдийгүй телеграм руу илгээгдэх болно.

Би ямар нэгэн байдлаар XNUMX-р сарын хоёрдугаар хагаст тусдаа тэмдэг хэлбэрээр үйл явдлуудыг хэрэгжүүлсэн. Энэ нь тийм ч оновчтой биш, гэхдээ ядаж бот ажиллаж, надад дахин нийтлэл илгээж эхэлсэн бөгөөд би кодонд юу болж байгааг аажмаар ойлгов.

Одоо та эхлэл рүүгээ буцаж очоод уг санг анх би үүсгээгүй гэдгийг санаж болно. Юу ингэж явж болох байсан бэ? Миний татах хүсэлтийг татгалзсан. Би улаавтар кодтой, багаар хэрхэн ажиллахаа мэддэггүй байсан тул одоогийн хэрэгжүүлэх муруй дахь алдааг засч, ашиглах боломжтой байдалд оруулахгүй байх шаардлагатай болсон.

Би бухимдаж, үйл ажиллагааны түүх, бичсэн кодын хэмжээг харав. Анхандаа сайхан бичигдсэн, дараа нь эвдэрсэн мөчүүдийг харлаа...

Үгүй ээ

Би нийтлэлийг санаж байна Та Google биш.

Хэрэгжихгүй бол санаа хэнд ч хэрэггүй гэж бодсон. Би энгийн java програм шиг нэг компьютер дээр нэг хуулбараар ажиллах боломжтой роботтой болмоор байна гэж бодсон. Өмнө нь ийм ботуудыг бичиж байсан болохоор миний бот дахин эхлүүлэхгүйгээр хэдэн сар ажиллах болно гэдгийг би мэднэ. Хэрэв гэнэт унаж, хэрэглэгчдэд өөр нийтлэл илгээхгүй бол тэнгэр газар унахгүй бөгөөд сүйрлийн зүйл тохиолдохгүй.

Хэрэв код нь зүгээр л ажиллахгүй эсвэл муруй байвал надад яагаад Docker, mongoDB болон бусад ачааны "ноцтой" программ хэрэгтэй байна вэ?

Би төслийг сэрээгээд бүх зүйлийг хүссэнээрээ хийсэн.

Ойролцоогоор би ажлаа сольж, чөлөөт цаг маш их хомсдсон. Өглөө нь би галт тэргэнд босоод орой нь оройтож буцаж ирээд юу ч хийх хүсэлгүй болсон. Хэсэг хугацаанд юу ч хийгээгүй, дараа нь ботыг дуусгах хүсэл намайг дарж, өглөө ажил руугаа явж байхдаа кодыг аажмаар дахин бичиж эхлэв. Энэ нь үр дүнтэй байсан гэж би хэлэхгүй: чичирч буй галт тэргэнд өвөр дээрээ зөөврийн компьютертэй суугаад утаснаасаа стек халихыг харах нь тийм ч тохиромжтой биш юм. Гэсэн хэдий ч код бичихэд зарцуулсан цаг хугацаа огт анзаарагдамгүй өнгөрч, төсөл аажмаар ажиллаж эхэлсэн.

Миний оюун ухааны хаа нэгтээ mongoDB-г ашиглах гэсэн эргэлзээ төрж байсан ч "найдвартай" төрийн хадгалалтын давуу талуудаас гадна мэдэгдэхүйц сул талууд байдаг гэж би бодсон.

• Өгөгдлийн сан нь бүтэлгүйтлийн өөр нэг цэг болдог.
• Код нь илүү төвөгтэй болж байгаа бөгөөд үүнийг бичихэд илүү хугацаа шаардагдах болно.
• Код нь удаан бөгөөд үр ашиггүй болж, санах ой дахь объектыг өөрчлөхийн оронд өөрчлөлтийг мэдээллийн сан руу илгээж, шаардлагатай бол буцааж татдаг.
• Мэдээллийн сангийн онцлогтой холбоотой үйл явдлыг тусдаа хүснэгтэд хадгалах төрлийн хязгаарлалтууд байдаг.
• Monga-ийн туршилтын хувилбар нь зарим хязгаарлалттай бөгөөд хэрэв та тэдгээртэй тулгарвал та 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 командтай нийтлэлүүдийг ботоос асууж болно, эсвэл bot-д бүртгүүлж, өдрийн аль ч цагт нийтлэлээ хувийн мессежээр илгээх болно.

Ерөнхийдөө нийтлэл бүрээс илүү олон функцуудыг (төв, сэтгэгдлийн тоо, хавчуурга, үнэлгээний өөрчлөлтийн динамик, нийтлэл дэх текст, зураг, код, түлхүүр үгс) гаргаж, хэрэглэгчдэд ok/ гэж харуулах санаа төрсөн. Өгүүллэг бүрийн доор санал өгч, хэрэглэгч бүрд зориулж загвар сургаж болохгүй, гэхдээ би хэтэрхий залхуу байсан.

Үүнээс гадна, ажлын логик нь тийм ч тодорхой биш байх болно. Одоо би pasientZero-д +9000 үнэлгээг гараар тохируулах боломжтой бөгөөд босго үнэлгээ нь +20 байвал би түүний бүх нийтлэлийг хүлээн авах баталгаатай байх болно (мэдээжийн хэрэг, би зарим шошгонд -100500 гэж тохируулаагүй бол).

Эцсийн архитектур нь маш энгийн болсон:

1. Бүх чат, нийтлэлийн төлөвийг хадгалдаг жүжигчин. Энэ нь дискэн дээрх файлаас төлөвөө ачаалж, үе үе шинэ файл руу хадгалдаг.
2. RSS feed-д үе үе зочилж, шинэ нийтлэлүүдийн талаар суралцаж, холбоосыг үзэж, задлан шинжилж, эдгээр нийтлэлийг эхний жүжигчин рүү илгээдэг жүжигчин. Нэмж дурдахад, заримдаа эхний жүжигчнээс нийтлэлийн жагсаалтыг хүсч, гурав хоногоос илүүгүй, удаан хугацаанд шинэчлэгдээгүй нийтлэлүүдийг сонгон авч, шинэчилдэг.
3. Телеграмаар харилцдаг жүжигчин. Би мессежийг бүрэн задлан шинжилж энд авчирсан хэвээр байна. Нөхөрсөг байдлаар би үүнийг хоёр хуваахыг хүсч байна - нэг нь ирж буй мессежийг задлан шинжилж, хоёр дахь нь илгээгээгүй мессежийг дахин илгээх гэх мэт тээврийн асуудлыг шийддэг. Одоо дахин илгээгээгүй бөгөөд алдааны улмаас ирээгүй мессеж зүгээр л алга болно (энэ нь бүртгэлд тэмдэглэгдээгүй бол), гэхдээ энэ нь ямар ч асуудал үүсгээгүй байна. Хэрэв олон хүмүүс ботыг захиалж, би мессеж илгээх хязгаарт хүрсэн бол асуудал үүсч магадгүй юм).

Надад таалагдсан зүйл бол аккагийн ачаар 2, 3-р жүжигчдийн уналт нь ерөнхийдөө ботын гүйцэтгэлд нөлөөлдөггүй. Магадгүй зарим нийтлэлүүд цаг тухайд нь шинэчлэгдээгүй эсвэл зарим мессежүүд телеграмд ​​хүрэхгүй байж магадгүй, гэхдээ данс нь жүжигчнийг дахин эхлүүлж, бүх зүйл үргэлжлүүлэн ажиллаж байна. Телеграмын жүжигчин мессежийг амжилттай хүргэсэн гэж хариулах үед л нийтлэлийг хэрэглэгчдэд үзүүлэх мэдээллийг би хадгалдаг. Намайг заналхийлж буй хамгийн муу зүйл бол мессежийг хэд хэдэн удаа илгээх явдал юм (хэрэв энэ нь хүргэгдсэн боловч баталгаажуулалт ямар нэгэн байдлаар алдагдсан). Зарчмын хувьд, хэрэв анхны жүжигчин төрийг өөртөө хадгалаагүй, харин ямар нэгэн мэдээллийн сантай харилцаж байсан бол тэр мөн мэдэгдэхүйц унаж, амьдралд буцаж ирж магадгүй юм. Би жүжигчдийн төлөв байдлыг сэргээхийн тулд ака шаргуу оролдлого хийж болох ч одоогийн хэрэгжилт нь энгийн байдлаараа надад тохирсон. Энэ нь миний код байнга унадаг гэсэн үг биш, харин ч эсрэгээр, би үүнийг боломжгүй болгохын тулд маш их хүчин чармайлт гаргасан. Гэхдээ новш юм болж, хөтөлбөрийг тусгаарлагдсан жүжигчид болгон хуваах чадвар надад үнэхээр тохиромжтой, практик мэт санагдсан.

Хэрэв код эвдэрвэл та энэ тухай шууд мэдэх болно гэж би тойрог-ci нэмсэн. Наад зах нь кодыг эмхэтгэхээ больсон гэсэн үг. Эхэндээ би Травис нэмэхийг хүссэн боловч энэ нь зөвхөн сэрээгүйгээр миний төслүүдийг харуулсан. Ерөнхийдөө эдгээр хоёр зүйлийг хоёуланг нь нээлттэй хадгалах газарт чөлөөтэй ашиглаж болно.

Үр дүн

Аль хэдийн арваннэгдүгээр сар боллоо. Бот бичигдсэн байна, би үүнийг сүүлийн хоёр долоо хоног ашиглаж байна, надад таалагдсан. Хэрэв танд сайжруулах санаа байвал бичээрэй. Би үүнийг мөнгө олох утгагүй гэдгийг олж харахгүй байна - үүнийг зүгээр л ажиллуулж, сонирхолтой нийтлэлүүдийг илгээгээрэй.

Бот холбоос: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Жижиг дүгнэлтүүд:

• Жижиг төсөл ч гэсэн маш их цаг зарцуулдаг.
• Та Google биш. Их буугаар бор шувуу харвах нь утгагүй. Энгийн шийдэл нь бас үр дүнтэй байх болно.
• Гэрийн тэжээмэл амьтдын төслүүд шинэ технологиудыг туршиж үзэхэд маш сайн байдаг.
• Telegram роботуудыг маш энгийнээр бичсэн байдаг. Хэрэв "багаар ажиллах" болон технологийн туршилтууд байгаагүй бол ботыг нэг юмуу хоёр долоо хоногийн дотор бичих байсан.
• Жүжигчин загвар нь олон урсгалтай, алдаатай кодтой сайн зохицдог сонирхолтой зүйл юм.
• Нээлттэй эхийн нийгэмлэг яагаад сэрээнд дуртай байдгийг би мэдэрсэн гэж бодож байна.
• Өгөгдлийн сан нь сайн, учир нь програмын төлөв нь програмын уналт/дахин ачааллаас хамаарахаа больсон ч мэдээллийн сантай ажиллах нь кодыг төвөгтэй болгож, өгөгдлийн бүтцэд хязгаарлалт тавьдаг.

Эх сурвалж: www.habr.com