🥇Bot telegram kanggo pilihan artikel pribadi saka Habr

Kanggo pitakonan kaya "kenapa?" ana artikel lawas - Natural Geektimes - nggawe papan luwih resik.

Ana akeh artikel, amarga alasan subyektif sawetara sing aku ora seneng, lan sawetara, ing nalisir, iku tega kanggo skip. Aku pengin ngoptimalake proses iki lan ngirit wektu.

Artikel ing ndhuwur nyaranake pendekatan skrip ing browser, nanging aku ora seneng banget (sanajan aku wis nggunakake sadurunge) amarga alasan ing ngisor iki:

Kanggo browser beda ing komputer / telpon, sampeyan kudu ngatur maneh, yen bisa.
Nyaring ketat dening penulis ora tansah trep.
Masalah karo penulis sing artikel sampeyan ora pengin kantun, sanajan diterbitake sepisan taun, durung ditanggulangi.

Nyaring sing dibangun ing situs adhedhasar rating artikel ora mesthi trep, amarga artikel sing khusus banget, sanajan regane, bisa nampa rating sing rada andhap asor.

Kaping pisanan, aku pengin nggawe feed RSS (utawa malah sawetara), mung ninggalake perkara sing menarik. Nanging ing pungkasan, ternyata maca RSS katon ora trep banget: ing kasus apa wae, kanggo menehi komentar / milih artikel / nambahake menyang favorit sampeyan, sampeyan kudu ngliwati browser. Mulane aku nulis bot telegram sing ngirim artikel menarik kanggo aku ing pesen pribadi. Telegram dhewe nggawe pratinjau sing apik, sing, digabungake karo informasi babagan penulis / rating / tampilan, katon cukup informatif.

Ing ngisor potongan kasebut ana rincian kayata fitur karya, proses nulis lan solusi teknis.

Sedhela babagan bot

Repositori: https://github.com/Kright/habrahabr_reader

Bot ing telegram: https://t.me/HabraFilterBot

Pangguna nyetel rating tambahan kanggo tag lan penulis. Sawisé iku, saringan ditrapake kanggo artikel - rating artikel ing Habré, rating pangguna penulis lan rata-rata rating pangguna miturut tag ditambahake. Yen jumlahe luwih gedhe tinimbang batesan sing ditemtokake pangguna, artikel kasebut bakal ngliwati panyaring.

Tujuan sisih nulis bot yaiku kanggo entuk kesenengan lan pengalaman. Kajaba iku, aku ajeg ngelingake aku Aku dudu Google, lan mulane akeh perkara sing ditindakake kanthi prasaja lan malah primitif sabisa. Nanging, iki ora nyegah proses nulis bot njupuk telung sasi.

Ing njaba musim panas

Juli wis rampung, lan aku mutusake kanggo nulis bot. Lan ora piyambak, nanging karo kanca sing nguwasani scala lan wanted kanggo nulis soko ing. Awal katon janjeni - kode kasebut bakal dipotong dening tim, tugas kasebut katon gampang lan aku mikir yen ing sawetara minggu utawa wulan, bot bakal siap.

Senadyan kasunyatan manawa aku dhewe wis nulis kode ing watu ing sawetara taun kepungkur, ora ana sing biasane ndeleng utawa ndeleng kode iki: proyek pet, nyoba sawetara ide, ngolah data, nguwasani sawetara konsep saka FP. Aku pancene kasengsem ing apa kode nulis ing tim katon kaya, amarga kode ing rock bisa ditulis ing cara sing beda banget.

Apa bisa lunga supaya? Nanging, aja kesusu.
Kabeh sing kedadeyan bisa dilacak nggunakake riwayat komit.

Kenal nggawe repositori tanggal 27 Juli, nanging ora nindakake apa-apa, mula aku miwiti nulis kode.

30 July

Sedhela: Aku nulis parsing saka feed rss Habr.

com.github.pureconfig kanggo maca konfigurasi typesafe langsung menyang kelas kasus (pranyata trep banget)
scala-xml kanggo maca xml: wiwit pisanan aku wanted kanggo nulis implementasine dhewe kanggo feed rss, lan feed rss ing format xml, Aku digunakake perpustakaan iki kanggo parsing. Bener, parsing RSS uga muncul.
scalatest kanggo tes. Malah kanggo proyek cilik, tes nulis ngirit wektu - contone, nalika debugging parsing xml, luwih gampang didownload menyang file, nulis tes lan mbenerake kesalahan. Nalika bug mengko muncul karo parsing sawetara html aneh karo utf-8 karakter ora bener, iku dadi luwih trep kanggo sijine iku ing file lan nambah test.
aktor saka Akka. Objectively, padha ora needed ing kabeh, nanging project iki ditulis kanggo seneng-seneng, Aku wanted kanggo nyoba wong. Akibaté, aku siap ngomong yen aku seneng. Gagasan OOP bisa dideleng saka sisih liya - ana aktor sing ijol-ijolan pesen. Sing luwih menarik yaiku sampeyan bisa (lan kudu) nulis kode kanthi cara supaya pesen kasebut ora teka utawa ora bisa diproses (umume, nalika akun kasebut mlaku ing siji komputer, pesen kudu ora ilang). Ing kawitan aku iki scratching sirah lan ana sampah ing kode karo aktor lengganan kanggo saben liyane, nanging ing pungkasan aku ngatur kanggo teka munggah karo arsitektur rada prasaja lan elegan. Kode ing saben aktor bisa dianggep siji-threaded; nalika aktor tabrakan, acca miwiti maneh - asil sistem cukup fault-tolerant.

9 Aug

Aku ditambahake menyang proyek scala-scrapper kanggo parsing kaca html saka Habr (kanggo narik metu informasi kayata rating artikel, nomer tetenger, etc.).

Lan Kucing. Sing ana ing watu.

Aku banjur maca buku babagan basis data sing disebarake, aku seneng karo ide CRDT (Tipe data replika bebas konflik, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), mula aku ngirim kelas jinis semigroup komutatif kanggo informasi babagan artikel ing Habré.

Nyatane, ide kasebut gampang banget - kita duwe counter sing diganti kanthi monoton. Jumlah promosi saya tambah akeh, uga jumlah plus (uga jumlah minus). Yen aku duwe rong versi informasi babagan artikel, aku bisa "nggabungake dadi siji" - negara counter sing luwih gedhe dianggep luwih relevan.

Semigroup tegese rong obyek kanthi informasi babagan artikel bisa digabung dadi siji. Commutative tegese sampeyan bisa nggabungake loro A + B lan B + A, asil ora gumantung ing urutan, lan ing pungkasan versi paling anyar bakal tetep. Miturut cara, ana uga asosiasi ing kene.

Contone, kaya sing direncanakake, rss sawise parsing nyedhiyakake informasi sing rada lemah babagan artikel kasebut - tanpa metrik kayata jumlah tampilan. A aktor khusus banjur njupuk informasi babagan artikel lan mlayu menyang kaca html kanggo nganyari lan nggabungake karo versi lawas.

Umumé, kaya ing akka, ora perlu iki, sampeyan mung bisa nyimpen updateDate kanggo artikel kasebut lan njupuk sing luwih anyar tanpa gabung, nanging dalan petualangan mimpin aku.

12 Aug

Aku wiwit aran freer lan, mung kanggo seneng-seneng, Aku nggawe saben chatting aktor kapisah. Secara teoritis, aktor dhewe bobote udakara 300 bita lan bisa digawe jutaan, mula iki minangka pendekatan sing normal. Iku misale jek kanggo kula sing solusi dadi cukup menarik:

Salah sawijining aktor minangka jembatan antarane server telegram lan sistem pesen ing Akka. Dheweke mung nampa pesen lan dikirim menyang aktor chatting sing dikarepake. Aktor chatting bisa ngirim soko maneh kanggo nanggepi - lan bakal dikirim maneh menyang telegram. Sing trep banget yaiku aktor iki dadi prasaja sabisa lan mung ana logika kanggo nanggapi pesen. Miturut cara, informasi babagan artikel anyar teka ing saben obrolan, nanging maneh aku ora weruh masalah iki.

Umumé, bot wis kerja, nanggapi pesen, nyimpen dhaptar artikel sing dikirim menyang pangguna, lan aku wis mikir yen bot wis meh siap. Aku alon-alon nambah fitur cilik kaya normalisasi jeneng penulis lan tag (ngganti "sd f" karo "s_d_f").

Mung kari siji cilik nanging - negara iki ora disimpen ing ngendi wae.

Kabeh dadi salah

Sampeyan bisa uga wis ngeweruhi sing aku nulis bot biasane piyambak. Dadi, peserta kapindho melu pembangunan, lan owah-owahan ing ngisor iki katon ing kode:

MongoDB katon kanggo nyimpen negara. Ing wektu sing padha, log ing proyek kasebut rusak, amarga sakperangan alesan Monga miwiti spamming lan sawetara wong mung mateni global.
Aktor jembatan ing Telegram diowahi ora bisa dingerteni lan wiwit ngurai pesen dhewe.
Aktor kanggo chatting padha mercilessly Cut metu, lan tinimbang padha diganti dening aktor sing ndhelikake kabeh informasi bab kabeh chats bebarengan. Kanggo saben wahing, aktor iki ngalami alangan. Ya, kaya nalika nganyari informasi babagan artikel, ngirim menyang kabeh aktor chatting iku angel (kita kaya Google, mayuta-yuta pangguna nunggu siji yuta artikel ing obrolan kanggo saben), nanging saben chatting dianyari, iku lumrah kanggo pindhah menyang Monga. Nalika aku ngerti mengko, logika kerja chatting uga rampung dipotong lan ing panggonane ana sing ora bisa ditindakake.
Ora ana tilak saka kelas jinis.
Sawetara logika sing ora sehat wis muncul ing para aktor kanthi langganan saben liyane, sing nyebabake kondisi balapan.
Struktur data kanthi jinis kolom Option[Int] diowahi dadi Int kanthi nilai gawan magis kaya -1. Mengko aku nyadari yen mongoDB nyimpen json lan ora ana sing salah karo nyimpen ing kono Option uga, utawa paling ora parse -1 minangka Ora Ana, nanging ing wektu iku aku ora ngerti iki lan njupuk sandi tembung kanggo iku "iku kudune." Aku ora nulis kode sing, lan aku ora keganggu ngganti kanggo wektu.
Aku ngerteni manawa alamat IP umumku cenderung ganti, lan saben-saben aku kudu nambahake menyang dhaptar putih Mongo. Aku dibukak bot lokal, Monga nang endi wae ing server Monga minangka perusahaan.
Dumadakan, normalisasi tag lan format pesen kanggo telegram ilang. (Hmm, kenapa bisa?)
Aku seneng yen negara bot disimpen ing database eksternal, lan nalika diwiwiti maneh, kaya-kaya ora ana apa-apa. Nanging, iki mung plus.

Wong liya ora cepet-cepet, lan kabeh owah-owahan kasebut katon ing siji tumpukan gedhe ing awal September. Aku ora langsung ngapresiasi skala karusakan sing diasilake lan wiwit ngerti karya database, amarga ... Aku wis tau urusan karo wong-wong mau sadurunge. Mung mengko aku ngerti carane akeh kode digunakake Cut lan carane akeh kewan omo ditambahake ing panggonan.

September

Ing kawitan aku panginten iku bakal migunani kanggo master Monga lan nindakaken uga. Banjur aku alon-alon ngerti yen ngatur komunikasi karo database uga minangka seni sing bisa nggawe akeh balapan lan mung nggawe kesalahan. Contone, yen pangguna nampa rong pesen kaya /subscribe - lan kanggo nanggepi saben siji, kita bakal nggawe entri ing tabel, amarga nalika ngolah pesen kasebut pangguna ora langganan. Aku duwe anggepan manawa komunikasi karo Monga ing wangun saiki ora ditulis kanthi cara sing paling apik. Contone, setelan pangguna digawe nalika dheweke ndhaptar. Yen dheweke nyoba ngganti sadurunge kasunyatan langganan ... bot ora nanggapi apa-apa, amarga kode ing aktor tindak menyang database kanggo setelan, ora ketemu lan tabrakan. Nalika ditakoni kenapa ora nggawe setelan kaya sing dibutuhake, aku ngerti yen ora perlu ngganti yen pangguna durung langganan ... Sistem panyaring pesen digawe kanthi ora jelas, lan sanajan sawise mriksa kode kasebut aku bisa. ora ngerti apa iki dimaksudake ing wiwitan utawa ana kesalahan.

Ora ana dhaptar artikel sing dikirim menyang obrolan, nanging disaranake supaya aku nulis dhewe. Iki kaget kula - ing umum, aku ora nglawan nyeret kabeh limo iku menyang project, nanging bakal logis kanggo wong sing nggawa iki lan ngaco. Nanging ora, peserta nomer loro katon nyerah kabeh, nanging ujar manawa dhaptar ing obrolan kasebut mesthine minangka solusi sing ala, lan kudu nggawe tandha karo acara kaya "artikel y dikirim menyang pangguna x." Banjur, yen pangguna njaluk ngirim artikel anyar, kudu ngirim panjalukan menyang database, sing bakal milih acara sing ana gandhengane karo pangguna saka acara kasebut, uga entuk dhaptar artikel anyar, nyaring, dikirim menyang pangguna. lan uncalan acara bab iki bali menyang database.

Peserta kapindho digawa menyang endi wae menyang abstraksi, nalika bot bakal nampa ora mung artikel saka Habr lan dikirim ora mung menyang telegram.

Aku piye wae dileksanakake acara ing wangun tandha kapisah kanggo separo kapindho September. Ora optimal, nanging paling ora bot wiwit kerja lan wiwit ngirim artikel maneh, lan aku alon-alon ngerteni apa sing kedadeyan ing kode kasebut.

Saiki sampeyan bisa bali menyang wiwitan lan elinga yen repositori kasebut ora digawe dening aku. Apa bisa dadi kaya iki? Panjalukku ditarik ditolak. Iku nguripake metu sing aku kode redneck, aku ora ngerti carane bisa ing tim, lan aku kudu ndandani kewan omo ing kurva implementasine saiki, lan ora nyaring menyang negara iso digunakke.

Aku kaget lan ndeleng riwayat komit lan jumlah kode sing ditulis. Aku ndeleng momen sing asline ditulis kanthi apik, banjur dirusak maneh ...

F*rk iku

Aku kelingan artikel kasebut Sampeyan dudu Google.

Aku panginten sing ora ana siji tenan perlu idea tanpa implementasine. Aku panginten sing aku pengin duwe bot digunakake, kang bakal bisa ing siji salinan siji ing siji komputer minangka program java prasaja. Aku ngerti yen botku bakal bisa digunakake nganti pirang-pirang wulan tanpa miwiti maneh, amarga aku wis nulis bot kasebut ing jaman kepungkur. Yen tiba-tiba tiba lan ora ngirim pangguna artikel liyane, langit ora bakal tiba ing lemah lan ora ana bencana sing bakal kedadeyan.

Napa aku butuh Docker, mongoDB lan kultus kargo piranti lunak "serius" liyane yen kode kasebut ora bisa digunakake utawa ora bisa digunakake?

Aku forked project lan nindakake kabeh kaya aku wanted.

Ing wektu sing padha, aku ganti kerja lan wektu luang dadi kurang. Esuk-esuk aku langsung tangi ing sepur, sore aku bali telat lan ora gelem apa-apa maneh. Aku ora nindakake apa-apa kanggo sawetara wektu, banjur kepinginan kanggo rampung bot overpowered kula, lan aku wiwit alon-alon nulis kode nalika aku nyopir kanggo bisa ing esuk. Aku ora bakal ujar manawa produktif: lungguh ing sepur goyang karo laptop ing puteran lan ndeleng tumpukan tumpukan saka telpon sampeyan ora trep. Nanging, wektu ngginakaken nulis kode miber dening rampung unnoticed, lan project wiwit alon pindhah menyang negara apa.

Nang endi wae ing mburi pikiranku ana cacing keraguan sing pengin nggunakake mongoDB, nanging aku mikir manawa saliyane kaluwihan panyimpenan negara sing "dipercaya", ana kekurangan sing katon:

Database dadi titik kegagalan liyane.
Kode dadi luwih rumit, lan aku bakal njupuk maneh kanggo nulis.
Kode dadi alon lan ora efisien; tinimbang ngganti obyek ing memori, owah-owahan dikirim menyang database lan ditarik maneh yen perlu.
Ana watesan babagan jinis panyimpenan acara ing tabel sing kapisah, sing ana gandhengane karo kekhasan database.
Versi nyoba Monga wis sawetara watesan, lan yen sampeyan mbukak menyang, sampeyan kudu miwiti lan ngatur Monga ing soko.

Aku Cut metu monga, saiki negara bot mung disimpen ing memori program lan saka wektu kanggo wektu disimpen menyang file ing wangun json. Mbok menawa ing komentar, dheweke bakal nulis yen aku salah, yen ing kene database kudu digunakake, lsp. Nanging iki proyekku, pendekatan karo file kasebut gampang banget lan bisa digunakake kanthi transparan.

Mbuwang nilai sihir kaya -1 lan bali sing normal Option, nambah panyimpenan saka tabel hash karo dikirim artikel bali menyang obyek karo informasi chatting. Nambahake pambusakan informasi babagan artikel sing luwih lawas tinimbang limang dina, supaya ora nyimpen kabeh. Aku nggawa log menyang negara kerja - log ditulis kanthi jumlah sing cukup kanggo file lan konsol. Nambahake sawetara prentah admin kayata nyimpen negara utawa entuk statistik kayata jumlah pangguna lan artikel.

Ndandani sawetara perkara cilik: contone, kanggo artikel, jumlah tampilan, seneng, ora seneng lan komentar nalika ngliwati panyaring pangguna saiki dituduhake. Umumé, nggumunake pirang-pirang perkara cilik sing kudu didandani. Aku terus dhaftar, nyatet kabeh "irregularities" ana lan didandani minangka adoh sabisa.

Contone, aku nambahake kemampuan kanggo nyetel kabeh setelan langsung ing siji pesen:

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

Lan tim liyane /settings nampilake persis ing wangun iki, sampeyan bisa njupuk teks saka lan ngirim kabeh setelan kanggo kanca.
Katon kaya cilik, nanging ana puluhan nuansa sing padha.

Nyaring artikel sing dileksanakake ing wangun model linear sing prasaja - pangguna bisa nyetel rating tambahan kanggo penulis lan tag, uga nilai ambang. Yen jumlah rating penulis, rating rata-rata kanggo tag lan rating nyata artikel luwih gedhe tinimbang nilai ambang, banjur artikel kasebut ditampilake menyang pangguna. Sampeyan bisa njaluk bot kanggo artikel karo printah / anyar, utawa langganan bot lan bakal ngirim artikel ing pesen pribadi ing sembarang wektu dina.

Umumé, aku duwe ide kanggo saben artikel kanggo narik luwih akeh fitur (hub, jumlah komentar, tetenger, dinamika owah-owahan rating, jumlah teks, gambar lan kode ing artikel, tembung kunci), lan nuduhake pangguna ok / ora ok milih ing saben artikel lan olahraga model kanggo saben pangguna, nanging aku kesed.

Kajaba iku, logika karya ora bakal ketok. Saiki aku bisa kanthi manual nyetel rating +9000 kanggo patientZero lan kanthi rating ambang +20 aku bakal dijamin nampa kabeh artikel (kajaba, mesthi, aku nyetel -100500 kanggo sawetara tag).

Arsitèktur pungkasan dadi cukup prasaja:

Aktor sing nyimpen kahanan kabeh obrolan lan artikel. Iki mbukak status saka file ing disk lan nyimpen maneh saka wektu kanggo wektu, saben wektu kanggo file anyar.
Aktor sing ngunjungi feed RSS saka wektu kanggo wektu, sinau babagan artikel anyar, ndeleng pranala, parses, lan ngirim artikel iki menyang aktor pisanan. Kajaba iku, kadhangkala njaluk dhaptar artikel saka aktor pisanan, milih sing ora luwih saka telung dina, nanging wis suwe ora dianyari, lan nganyari.
Aktor sing komunikasi karo telegram. Aku isih nggawa pesen parsing rampung kene. Kanthi cara sing ramah, aku pengin dibagi dadi loro - supaya siji ngurai pesen sing mlebu, lan sing nomer loro ngatasi masalah transportasi kayata ngirim maneh pesen sing ora dikirim. Saiki ora dikirim maneh, lan pesen sing ora teka amarga kesalahan mung bakal ilang (kajaba dicathet ing log), nanging nganti saiki iki ora nyebabake masalah. Mungkin masalah bakal muncul yen akeh wong sing langganan bot lan aku tekan watesan kanggo ngirim pesen).

Apa aku disenengi iku thanks kanggo akka, tumiba aktor 2 lan 3 umume ora mengaruhi kinerja bot. Mungkin sawetara artikel ora dianyari ing wektu utawa sawetara pesen ora tekan telegram, nanging akun miwiti maneh aktor lan kabeh terus bisa. Aku nyimpen informasi sing artikel ditampilake kanggo pangguna mung nalika aktor telegram nanggapi sing wis kasil dikirim pesen. Wangsulan: Bab ingkang paling awon sing ngancam kula kanggo ngirim pesen kaping pirang-pirang (yen wis dikirim, nanging konfirmasi piye wae ilang). Ing asas, yen aktor pisanan ora nyimpen negara ing dhewe, nanging komunikasi karo sawetara database, banjur bisa tiba imperceptibly lan bali menyang urip. Aku uga bisa nyoba akka kegigihan kanggo mulihake negara aktor, nanging implementasine saiki cocog kula karo gamblang. Ora kode sandi asring tabrakan - ing nalisir, aku sijine cukup akèh gaweyan kanggo nggawe iku mokal. Nanging telek kedadeyan, lan kemampuan kanggo ngilangi program kasebut dadi aktor-aktor sing terisolasi katon trep lan praktis kanggo aku.

Aku nambah bunder-ci supaya yen kode rusak, sampeyan bakal langsung ngerti. Minimal, tegese kode wis mandheg kompilasi. Wiwitane aku pengin nambah travis, nanging mung nuduhake proyekku tanpa garpu. Umumé, loro kasebut bisa digunakake kanthi bebas ing repositori sing mbukak.

Hasil

Wis November. Bot kasebut ditulis, aku wis nggunakake rong minggu kepungkur lan aku seneng. Yen sampeyan duwe gagasan kanggo perbaikan, nulis. Aku ora weruh titik kanggo monetisasi - ayo kerjane lan ngirim artikel sing menarik.

Link bot: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Kesimpulan cilik:

Malah proyek cilik bisa njupuk wektu suwe.
Sampeyan dudu Google. Ora ana gunane njupuk manuk pipit saka meriam. Solusi sing prasaja bisa uga bisa digunakake.
Proyèk pet apik banget kanggo eksperimen karo teknologi anyar.
Bot Telegram ditulis kanthi gampang. Yen ora kanggo "kerja tim" lan eksperimen karo teknologi, bot kasebut bakal ditulis sajrone seminggu utawa rong minggu.
Model aktor minangka perkara sing menarik sing cocog karo kode multi-threading lan fault-tolerant.
Aku rumangsa ngerti kenapa komunitas open source seneng garpu.
Basis data apik amarga negara aplikasi ora gumantung maneh ing kacilakan aplikasi / diwiwiti maneh, nanging nggarap database nggawe rumit kode lan ngetrapake watesan ing struktur data.

Source: www.habr.com

Bot Telegram kanggo pilihan artikel pribadi saka Habr