🥇Telegram bot para sa personalized na seleksyon ng mga artikulo mula sa Habr

Para sa mga tanong tulad ng "bakit?" mayroong isang mas lumang artikulo - Natural Geektimes - ginagawang mas malinis ang espasyo.

Mayroong maraming mga artikulo, para sa mga pansariling dahilan ang ilan sa mga ito ay hindi ko gusto, at ang ilan, sa kabaligtaran, nakakalungkot na laktawan. Gusto kong i-optimize ang prosesong ito at makatipid ng oras.

Ang artikulo sa itaas ay nagmungkahi ng isang in-browser scripting approach, ngunit hindi ko talaga ito nagustuhan (kahit nagamit ko na ito dati) para sa mga sumusunod na dahilan:

Para sa iba't ibang mga browser sa iyong computer/telepono, kailangan mong i-configure itong muli, kung posible.
Ang mahigpit na pag-filter ng mga may-akda ay hindi palaging maginhawa.
Ang problema sa mga may-akda na ang mga artikulo ay hindi mo gustong makaligtaan, kahit na sila ay nai-publish isang beses sa isang taon, ay hindi nalutas.

Ang pag-filter na binuo sa site batay sa mga rating ng artikulo ay hindi palaging maginhawa, dahil ang mga napaka-espesyal na artikulo, sa kabila ng kanilang halaga, ay maaaring makatanggap ng medyo katamtamang rating.

Sa una, gusto kong bumuo ng isang RSS feed (o kahit na marami), nag-iiwan lamang ng mga kagiliw-giliw na bagay doon. Ngunit sa huli, lumabas na ang pagbabasa ng RSS ay tila hindi masyadong maginhawa: sa anumang kaso, upang magkomento/bumoto para sa isang artikulo/idagdag ito sa iyong mga paborito, kailangan mong dumaan sa browser. Kaya naman nagsulat ako ng telegram bot na nagpapadala ng mga kawili-wiling artikulo sa akin sa isang personal na mensahe. Ang Telegram mismo ay gumagawa ng magagandang preview mula sa mga ito, na, kasama ng impormasyon tungkol sa may-akda/rating/view, ay mukhang lubos na nagbibigay-kaalaman.

Sa ibaba ng hiwa ay mga detalye tulad ng mga tampok ng trabaho, proseso ng pagsulat at mga teknikal na solusyon.

Maikling tungkol sa bot

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

Bot sa telegrama: https://t.me/HabraFilterBot

Nagtatakda ang user ng karagdagang rating para sa mga tag at may-akda. Pagkatapos nito, inilapat ang isang filter sa mga artikulo - ang rating ng artikulo sa Habré, ang rating ng user ng may-akda at ang average para sa mga rating ng user ayon sa tag ay idinaragdag. Kung ang halaga ay mas malaki kaysa sa threshold na tinukoy ng user, ang artikulo ay pumasa sa filter.

Ang isang side goal ng pagsulat ng bot ay upang makakuha ng kasiyahan at karanasan. Bilang karagdagan, palagi kong pinaalalahanan ang aking sarili na Hindi ako Google, at samakatuwid maraming bagay ang ginagawa nang simple at kahit primitively hangga't maaari. Gayunpaman, hindi nito napigilan ang proseso ng pagsulat ng bot na tumagal ng tatlong buwan.

Summer noon sa labas

Matatapos na ang Hulyo, at nagpasya akong magsulat ng bot. At hindi nag-iisa, ngunit kasama ang isang kaibigan na pinagkadalubhasaan ang scala at nais na magsulat ng isang bagay dito. Ang simula ay mukhang maaasahan - ang code ay puputulin ng isang koponan, ang gawain ay tila madali at naisip ko na sa loob ng ilang linggo o isang buwan ang bot ay magiging handa.

Sa kabila ng katotohanan na ako mismo ay nagsusulat ng code sa bato paminsan-minsan sa mga nakaraang taon, walang sinuman ang karaniwang nakakakita o tumitingin sa code na ito: mga proyekto ng alagang hayop, pagsubok ng ilang mga ideya, preprocessing data, mastering ilang mga konsepto mula sa FP. Talagang interesado ako sa kung ano ang hitsura ng pagsulat ng code sa isang koponan, dahil ang code sa bato ay maaaring isulat sa ibang paraan.

Ano kaya ang nawala kaya? Gayunpaman, huwag nating madaliin ang mga bagay.
Lahat ng mangyayari ay masusubaybayan gamit ang commit history.

Gumawa ng repository ang isang kakilala noong Hulyo 27, ngunit wala nang ibang ginawa, kaya nagsimula akong magsulat ng code.

Hulyo 30

Sa madaling sabi: Sumulat ako ng pag-parse ng rss feed ni Habr.

com.github.pureconfig para sa pagbabasa ng mga typeafe config nang direkta sa mga klase ng kaso (ito ay naging napaka-maginhawa)
scala-xml para sa pagbabasa ng xml: dahil sa una ay gusto kong magsulat ng sarili kong pagpapatupad para sa rss feed, at ang rss feed ay nasa xml format, ginamit ko ang library na ito para sa pag-parse. Sa totoo lang, lumitaw din ang RSS parsing.
scalatest para sa mga pagsubok. Kahit na para sa maliliit na proyekto, ang pagsusulat ng mga pagsusulit ay nakakatipid ng oras - halimbawa, kapag nagde-debug ng xml parsing, mas madaling i-download ito sa isang file, magsulat ng mga pagsubok at itama ang mga error. Nang lumitaw ang isang bug sa ibang pagkakataon na may pag-parse ng ilang kakaibang html na may mga di-wastong utf-8 na character, naging mas maginhawang ilagay ito sa isang file at magdagdag ng pagsubok.
mga aktor mula sa Akka. Sa layunin, hindi sila kailangan, ngunit ang proyekto ay isinulat para sa kasiyahan, nais kong subukan ang mga ito. Bilang resulta, handa akong sabihin na nagustuhan ko ito. Ang ideya ng OOP ay maaaring tingnan mula sa kabilang panig - may mga aktor na nagpapalitan ng mga mensahe. Ang mas kawili-wili ay maaari kang (at dapat) magsulat ng code sa paraang ang mensahe ay maaaring hindi dumating o maaaring hindi maproseso (sa pangkalahatan, kapag ang account ay tumatakbo sa isang solong computer, ang mga mensahe ay hindi dapat mawala). Sa una ay nagkakamot ako ng ulo at may basura sa code na may mga aktor na nag-subscribe sa isa't isa, ngunit sa huli ay nakabuo ako ng isang medyo simple at eleganteng arkitektura. Ang code sa loob ng bawat aktor ay maaaring ituring na single-threaded; kapag nag-crash ang isang aktor, ini-restart ito ng acca - ang resulta ay isang medyo fault-tolerant na sistema.

9 Agosto

Idinagdag ko sa proyekto scala-scrapper para sa pag-parse ng mga pahina ng html mula sa Habr (upang maglabas ng impormasyon tulad ng rating ng artikulo, bilang ng mga bookmark, atbp.).

At Pusa. Yung nasa bato.

Pagkatapos ay nagbasa ako ng isang libro tungkol sa mga ibinahagi na database, nagustuhan ko ang ideya ng CRDT (Conflict-free replicated data type, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), kaya nag-post ako ng uri ng klase ng isang commutative semigroup para sa impormasyon tungkol sa artikulo sa Habré.

Sa katunayan, ang ideya ay napaka-simple - mayroon kaming mga counter na monotonically nagbabago. Ang bilang ng mga promosyon ay unti-unting lumalaki, pati na rin ang bilang ng mga plus (pati na rin ang bilang ng mga minus). Kung mayroon akong dalawang bersyon ng impormasyon tungkol sa isang artikulo, maaari kong "pagsamahin ang mga ito sa isa" - ang estado ng counter na mas malaki ay itinuturing na mas nauugnay.

Ang isang semigroup ay nangangahulugan na ang dalawang bagay na may impormasyon tungkol sa isang artikulo ay maaaring pagsamahin sa isa. Ang ibig sabihin ng commutative ay maaari mong pagsamahin ang parehong A + B at B + A, ang resulta ay hindi nakasalalay sa pagkakasunud-sunod, at sa huli ay mananatili ang pinakabagong bersyon. Oo nga pala, may associativity din dito.

Halimbawa, gaya ng binalak, ang rss pagkatapos ng pag-parse ay nagbigay ng bahagyang humina na impormasyon tungkol sa artikulo - nang walang mga sukatan gaya ng bilang ng mga view. Ang isang espesyal na aktor pagkatapos ay kumuha ng impormasyon tungkol sa mga artikulo at tumakbo sa mga pahina ng html upang i-update ito at isama ito sa lumang bersyon.

Sa pangkalahatan, tulad ng sa akka, hindi ito kailangan, maaari mo lamang iimbak ang updateDate para sa artikulo at kumuha ng mas bago nang walang anumang pagsasanib, ngunit ang daan ng pakikipagsapalaran ay humantong sa akin.

12 Agosto

Nagsimula akong maging mas malaya at, para lamang sa kasiyahan, ginawa kong hiwalay na artista ang bawat chat. Sa teorya, ang isang aktor mismo ay tumitimbang ng humigit-kumulang 300 bytes at maaari silang malikha sa milyun-milyon, kaya ito ay isang ganap na normal na diskarte. Tila sa akin na ang solusyon ay naging medyo kawili-wili:

Ang isang aktor ay isang tulay sa pagitan ng telegram server at ng sistema ng mensahe sa Akka. Nakatanggap lang siya ng mga mensahe at ipinadala sa gustong chat actor. Ang chat actor ay maaaring magpadala ng isang bagay bilang tugon - at ito ay ipapadala pabalik sa telegrama. Ang napaka-maginhawa ay ang aktor na ito ay naging simple hangga't maaari at naglalaman lamang ng lohika para sa pagtugon sa mga mensahe. Sa pamamagitan ng paraan, ang impormasyon tungkol sa mga bagong artikulo ay dumating sa bawat chat, ngunit muli ay wala akong nakikitang anumang mga problema dito.

Sa pangkalahatan, gumagana na ang bot, tumutugon sa mga mensahe, nag-iimbak ng listahan ng mga artikulong ipinadala sa user, at iniisip ko na na halos handa na ang bot. Dahan-dahan akong nagdagdag ng maliliit na feature tulad ng pag-normalize ng mga pangalan at tag ng may-akda (pinapalitan ang "sd f" ng "s_d_f").

Isang bagay na lang ang natitira maliit pero — ang estado ay hindi nailigtas kahit saan.

Ang lahat ay naging mali

Maaaring napansin mo na isinulat ko ang bot na halos mag-isa. Kaya, ang pangalawang kalahok ay nasangkot sa pag-unlad, at ang mga sumusunod na pagbabago ay lumitaw sa code:

Lumilitaw ang MongoDB upang mag-imbak ng estado. Kasabay nito, ang mga log sa proyekto ay nasira, dahil sa ilang kadahilanan ay sinimulan ni Monga ang pag-spam sa kanila at ang ilang mga tao ay pinatay lamang ang mga ito sa buong mundo.
Ang tulay na aktor sa Telegram ay nabago nang hindi na makilala at nagsimulang mag-parse ng mga mensahe mismo.
Ang mga aktor para sa mga chat ay walang awang pinutol, at sa halip ay pinalitan sila ng isang aktor na itinago ang lahat ng impormasyon tungkol sa lahat ng mga chat nang sabay-sabay. Sa bawat pagbahing, nagkakaproblema ang aktor na ito. Well, oo, tulad ng kapag nag-a-update ng impormasyon tungkol sa isang artikulo, ang pagpapadala nito sa lahat ng mga aktor ng chat ay mahirap (kami ay tulad ng Google, milyon-milyong mga gumagamit ang naghihintay ng isang milyong mga artikulo sa chat para sa bawat isa), ngunit sa bawat oras na ang chat ay na-update, normal lang na pumunta sa Monga. Tulad ng napagtanto ko nang maglaon, ang gumaganang lohika ng mga chat ay ganap na naputol at sa lugar nito ay lumitaw ang isang bagay na hindi gumagana.
Walang natitirang bakas ng mga uri ng klase.
Ang ilang hindi malusog na lohika ay lumitaw sa mga aktor kasama ang kanilang mga subscription sa isa't isa, na humahantong sa isang kondisyon ng lahi.
Mga istruktura ng data na may mga field ng uri Option[Int] naging Int na may mga mahiwagang default na halaga tulad ng -1. Nang maglaon ay napagtanto ko na ang mongoDB ay nag-iimbak ng json at walang masama sa pag-iimbak nito doon Option well, o hindi bababa sa parse -1 bilang Wala, ngunit sa oras na iyon ay hindi ko alam ito at kinuha ang aking salita para dito na "ganyan dapat." Hindi ko isinulat ang code na iyon, at hindi ako nag-abala na baguhin ito pansamantala.
Nalaman ko na ang aking pampublikong IP address ay may posibilidad na magbago, at sa bawat oras na kailangan kong idagdag ito sa whitelist ng Mongo. Inilunsad ko ang bot nang lokal, si Monga ay nasa isang lugar sa mga server ng Monga bilang isang kumpanya.
Biglang nawala ang normalisasyon ng mga tag at pag-format ng mensahe para sa mga telegrama. (Hmm, bakit naman?)
Nagustuhan ko na ang estado ng bot ay naka-imbak sa isang panlabas na database, at kapag na-restart ay patuloy itong gagana na parang walang nangyari. Gayunpaman, ito ang tanging plus.

Ang pangalawang tao ay hindi partikular na nagmamadali, at ang lahat ng mga pagbabagong ito ay lumitaw sa isang malaking bunton na sa simula ng Setyembre. Hindi ko agad pinahahalagahan ang laki ng nagresultang pagkawasak at nagsimulang maunawaan ang gawain ng database, dahil... Hindi pa ako nakaharap sa kanila noon. Nang maglaon ay napagtanto ko kung gaano karaming gumaganang code ang pinutol at kung gaano karaming mga bug ang naidagdag sa lugar nito.

Setyembre

Noong una, naisip ko na magiging kapaki-pakinabang ang pag-master ng Monga at gawin ito nang maayos. Pagkatapos ay dahan-dahan kong naunawaan na ang pag-aayos ng komunikasyon sa database ay isa ring sining kung saan maaari kang gumawa ng maraming karera at magkamali lang. Halimbawa, kung nakatanggap ang user ng dalawang mensahe tulad ng /subscribe - at bilang tugon sa bawat isa ay gagawa kami ng isang entry sa talahanayan, dahil sa oras ng pagproseso ng mga mensaheng iyon ang user ay hindi naka-subscribe. May hinala ako na ang komunikasyon kay Monga sa kasalukuyang anyo nito ay hindi nakasulat sa pinakamahusay na paraan. Halimbawa, ginawa ang mga setting ng user sa sandaling nag-sign up siya. Kung sinubukan niyang baguhin ang mga ito bago ang katotohanan ng subscription ... ang bot ay hindi tumugon ng anuman, dahil ang code sa aktor ay pumasok sa database para sa mga setting, hindi ito nakita at nag-crash. Nang tanungin kung bakit hindi lumikha ng mga setting kung kinakailangan, nalaman ko na hindi na kailangang baguhin ang mga ito kung ang gumagamit ay hindi nag-subscribe... Ang sistema ng pag-filter ng mensahe ay ginawa kahit papaano nang hindi malinaw, at kahit na matapos ang isang malapit na pagtingin sa code ay magagawa ko. hindi maintindihan kung ito ay inilaan sa paraang ito sa simula o mayroong isang error doon.

Walang listahan ng mga artikulong isinumite sa chat; sa halip, iminungkahi na ako mismo ang sumulat ng mga ito. Nagulat ako nito - sa pangkalahatan, hindi ako tutol sa pag-drag ng lahat ng uri ng mga bagay sa proyekto, ngunit magiging lohikal para sa isa na nagdala ng mga bagay na ito at nasira ang mga ito. Ngunit hindi, ang pangalawang kalahok ay tila sumuko sa lahat, ngunit sinabi na ang listahan sa loob ng chat ay diumano'y isang masamang solusyon, at kinakailangang gumawa ng isang senyas na may mga kaganapan tulad ng "isang artikulo y ay ipinadala sa user x." Pagkatapos, kung hiniling ng user na magpadala ng mga bagong artikulo, kinakailangang magpadala ng kahilingan sa database, na pipili ng mga kaganapang nauugnay sa user mula sa mga kaganapan, makakakuha din ng listahan ng mga bagong artikulo, i-filter ang mga ito, ipadala ang mga ito sa user at itapon ang mga kaganapan tungkol dito pabalik sa database.

Ang pangalawang kalahok ay dinala sa isang lugar patungo sa mga abstraction, kapag ang bot ay makakatanggap ng hindi lamang mga artikulo mula kay Habr at ipapadala hindi lamang sa telegrama.

Nagpatupad ako ng mga kaganapan sa anyo ng isang hiwalay na tanda para sa ikalawang kalahati ng Setyembre. Hindi ito pinakamainam, ngunit hindi bababa sa nagsimula ang bot at nagsimulang magpadala sa akin ng mga artikulo muli, at dahan-dahan kong nalaman kung ano ang nangyayari sa code.

Ngayon ay maaari kang bumalik sa simula at tandaan na ang repositoryo ay hindi ko orihinal na nilikha. Ano kaya ang naging ganito? Tinanggihan ang aking kahilingan sa paghila. Ito ay lumabas na mayroon akong redneck code, na hindi ko alam kung paano magtrabaho sa isang koponan, at kailangan kong ayusin ang mga bug sa kasalukuyang curve ng pagpapatupad, at hindi pinuhin ito sa isang magagamit na estado.

Nagalit ako at tiningnan ang commit history at ang dami ng nakasulat na code. Tiningnan ko ang mga sandali na orihinal na isinulat nang maayos, at pagkatapos ay binasag...

F*rk ito

Naalala ko ang artikulo Hindi ka Google.

Naisip ko na wala talagang nangangailangan ng ideya nang walang pagpapatupad. Naisip ko na gusto kong magkaroon ng gumaganang bot, na gagana sa isang solong kopya sa isang computer bilang isang simpleng java program. Alam kong gagana ang aking bot nang ilang buwan nang hindi nagre-restart, dahil naisulat ko na ang mga naturang bot sa nakaraan. Kung bigla itong bumagsak at hindi magpadala sa gumagamit ng isa pang artikulo, ang langit ay hindi babagsak sa lupa at walang sakuna ang mangyayari.

Bakit ko kailangan ang Docker, mongoDB at iba pang kulto ng kargamento ng "seryosong" software kung ang code ay hindi gumagana o gumagana nang baluktot?

Pinutol ko ang proyekto at ginawa ang lahat ayon sa gusto ko.

Sa parehong oras, nagpalit ako ng trabaho at ang libreng oras ay naging lubhang kulang. Sa umaga ay nagising ako sa mismong tren, sa gabi ay huli akong bumalik at wala na akong gustong gawin. Wala akong ginawa saglit, pagkatapos ay nanaig sa akin ang pagnanais na tapusin ang bot, at sinimulan kong dahan-dahang muling isulat ang code habang nagmamaneho ako papunta sa trabaho sa umaga. Hindi ko sasabihin na ito ay produktibo: ang pag-upo sa isang nanginginig na tren na may laptop sa iyong kandungan at ang pagtingin sa stack overflow mula sa iyong telepono ay hindi masyadong maginhawa. Gayunpaman, ang oras na ginugol sa pagsulat ng code ay lumipad nang ganap na hindi napapansin, at ang proyekto ay nagsimulang dahan-dahang lumipat patungo sa isang gumaganang estado.

Sa isang lugar sa likod ng aking isip ay mayroong isang uod ng pagdududa na gustong gumamit ng mongoDB, ngunit naisip ko na bilang karagdagan sa mga pakinabang ng "maaasahang" imbakan ng estado, may mga kapansin-pansin na kawalan:

Ang database ay nagiging isa pang punto ng pagkabigo.
Ang code ay nagiging mas kumplikado, at mas matagal ko itong isulat.
Ang code ay nagiging mabagal at hindi epektibo; sa halip na baguhin ang isang bagay sa memorya, ang mga pagbabago ay ipinadala sa database at hinila pabalik kung kinakailangan.
May mga paghihigpit sa uri ng pag-iimbak ng mga kaganapan sa isang hiwalay na talahanayan, na nauugnay sa mga kakaibang katangian ng database.
Ang pagsubok na bersyon ng Monga ay may ilang mga limitasyon, at kung maranasan mo ang mga ito, kakailanganin mong ilunsad at i-configure ang Monga sa isang bagay.

Pinutol ko ang monga, ngayon ang estado ng bot ay nakaimbak lamang sa memorya ng programa at pana-panahong nai-save sa isang file sa anyo ng json. Marahil sa mga komento ay isusulat nila na ako ay mali, na dito dapat gamitin ang database, atbp. Ngunit ito ang aking proyekto, ang diskarte sa file ay kasing simple hangga't maaari at ito ay gumagana sa isang transparent na paraan.

Itinapon ang mga magic value tulad ng -1 at ibinalik ang mga normal Option, nagdagdag ng storage ng hash table na may ipinadalang mga artikulo pabalik sa object na may impormasyon sa chat. Idinagdag ang pagtanggal ng impormasyon tungkol sa mga artikulong mas matanda sa limang araw, upang hindi maimbak ang lahat. Dinala ko ang pag-log sa isang gumaganang estado - ang mga log ay nakasulat sa makatwirang dami sa parehong file at console. Nagdagdag ng ilang utos ng admin gaya ng pag-save ng estado o pagkuha ng mga istatistika gaya ng bilang ng mga user at artikulo.

Inayos ang isang grupo ng maliliit na bagay: halimbawa, para sa mga artikulo ang bilang ng mga view, likes, dislikes at komento sa oras ng pagpasa sa filter ng user ay ipinahiwatig na ngayon. Sa pangkalahatan, nakakagulat kung gaano karaming maliliit na bagay ang kailangang itama. Nag-iingat ako ng isang listahan, binanggit ang lahat ng "mga iregularidad" doon at itinuwid ang mga ito hangga't maaari.

Halimbawa, idinagdag ko ang kakayahang itakda ang lahat ng mga setting nang direkta sa isang mensahe:

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

At isa pang team /settings ipinapakita ang mga ito nang eksakto sa form na ito, maaari mong kunin ang teksto mula dito at ipadala ang lahat ng mga setting sa isang kaibigan.
Tila isang maliit na bagay, ngunit mayroong dose-dosenang mga katulad na nuances.

Ipinatupad ang pag-filter ng artikulo sa anyo ng isang simpleng linear na modelo - maaaring magtakda ang user ng karagdagang rating para sa mga may-akda at tag, pati na rin ang halaga ng threshold. Kung ang kabuuan ng rating ng may-akda, ang average na rating para sa mga tag at ang aktwal na rating ng artikulo ay mas malaki kaysa sa halaga ng threshold, ipapakita ang artikulo sa user. Maaari mong hilingin sa bot ang mga artikulo na may command /bago, o mag-subscribe sa bot at magpapadala ito ng mga artikulo sa isang personal na mensahe anumang oras ng araw.

Sa pangkalahatan, nagkaroon ako ng ideya para sa bawat artikulo na maglabas ng higit pang mga tampok (mga hub, bilang ng mga komento, mga bookmark, dynamics ng mga pagbabago sa rating, dami ng teksto, mga larawan at code sa artikulo, mga keyword), at ipakita sa user ang isang ok/ hindi ok bumoto sa ilalim ng bawat artikulo at sanayin ang isang modelo para sa bawat gumagamit, ngunit ako ay masyadong tamad.

Bilang karagdagan, ang lohika ng trabaho ay hindi masyadong halata. Ngayon ay maaari na akong manu-manong magtakda ng rating na +9000 para sa patientZero at may threshold na rating na +20 ay magagarantiyahan akong matatanggap ang lahat ng kanyang mga artikulo (maliban kung, siyempre, nagtakda ako ng -100500 para sa ilang mga tag).

Ang huling arkitektura ay naging medyo simple:

Isang aktor na nag-iimbak ng estado ng lahat ng mga chat at artikulo. Nilo-load nito ang estado nito mula sa isang file sa disk at ini-save ito pabalik sa pana-panahon, bawat oras sa isang bagong file.
Isang aktor na bumibisita sa RSS feed paminsan-minsan, natututo tungkol sa mga bagong artikulo, tumitingin sa mga link, nag-parse, at nagpapadala ng mga artikulong ito sa unang aktor. Bilang karagdagan, kung minsan ay humihiling ng isang listahan ng mga artikulo mula sa unang aktor, pinipili ang mga hindi mas matanda sa tatlong araw, ngunit hindi pa na-update nang mahabang panahon, at ina-update ang mga ito.
Isang aktor na nakikipag-usap sa isang telegrama. Dinala ko pa rin ang buong pag-parse ng mensahe dito. Sa isang mapayapang paraan, gusto kong hatiin ito sa dalawa - para ma-parse ng isa ang mga papasok na mensahe, at ang pangalawa ay matugunan ang mga problema sa transportasyon gaya ng muling pagpapadala ng mga hindi naipadalang mensahe. Ngayon ay walang muling pagpapadala, at ang isang mensahe na hindi dumating dahil sa isang error ay mawawala lamang (maliban kung ito ay nabanggit sa mga log), ngunit sa ngayon ay hindi ito nagdulot ng anumang mga problema. Marahil ay magkakaroon ng mga problema kung ang isang grupo ng mga tao ay mag-subscribe sa bot at maabot ko ang limitasyon para sa pagpapadala ng mga mensahe).

Ang nagustuhan ko ay salamat sa akka, ang pagbagsak ng mga aktor 2 at 3 sa pangkalahatan ay hindi nakakaapekto sa pagganap ng bot. Marahil ang ilang mga artikulo ay hindi na-update sa oras o ang ilang mga mensahe ay hindi nakarating sa telegrama, ngunit ang account ay nag-restart ng aktor at ang lahat ay patuloy na gumagana. Ise-save ko ang impormasyon na ang artikulo ay ipinapakita sa gumagamit lamang kapag tumugon ang aktor ng telegrama na matagumpay niyang naihatid ang mensahe. Ang pinakamasamang bagay na nagbabanta sa akin ay ipadala ang mensahe nang maraming beses (kung ito ay naihatid, ngunit ang kumpirmasyon ay nawala sa anumang paraan). Sa prinsipyo, kung ang unang aktor ay hindi nag-imbak ng estado sa loob ng kanyang sarili, ngunit nakipag-usap sa ilang database, maaari rin siyang mahulog nang hindi mahahalata at bumalik sa buhay. Maaari ko ring subukan ang akka persistance upang maibalik ang estado ng mga aktor, ngunit ang kasalukuyang pagpapatupad ay nababagay sa akin sa pagiging simple nito. Hindi sa madalas na nag-crash ang aking code - sa kabaligtaran, naglagay ako ng maraming pagsisikap upang gawin itong imposible. Ngunit shit ang mangyayari, at ang kakayahang hatiin ang programa sa ilang mga piraso-aktor ay tila talagang maginhawa at praktikal sa akin.

Nagdagdag ako ng circle-ci para kung masira ang code, malalaman mo agad ang tungkol dito. Sa pinakamababa, nangangahulugan ito na ang code ay tumigil sa pag-compile. Sa una gusto kong magdagdag ng travis, ngunit ipinakita lamang nito ang aking mga proyekto na walang tinidor. Sa pangkalahatan, ang parehong mga bagay na ito ay malayang magagamit sa mga bukas na repositoryo.

Mga resulta ng

November na pala. Ang bot ay nakasulat, ginamit ko ito sa huling dalawang linggo at nagustuhan ko ito. Kung mayroon kang mga ideya para sa pagpapabuti, sumulat. Hindi ko nakikita ang punto sa pagkakitaan ito - hayaan itong gumana at magpadala ng mga kawili-wiling artikulo.

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

Maliit na konklusyon:

Kahit na ang isang maliit na proyekto ay maaaring tumagal ng maraming oras.
Hindi ka Google. Walang kwenta ang pagbaril ng mga maya mula sa kanyon. Ang isang simpleng solusyon ay maaaring gumana rin.
Napakahusay ng mga proyekto ng alagang hayop para sa pag-eksperimento sa mga bagong teknolohiya.
Ang mga bot ng Telegram ay nakasulat nang simple. Kung hindi dahil sa "pagtutulungan ng magkakasama" at mga eksperimento sa teknolohiya, naisulat na sana ang bot sa loob ng isang linggo o dalawa.
Ang modelo ng aktor ay isang kawili-wiling bagay na napupunta nang maayos sa multi-threading at fault-tolerant code.
Sa palagay ko natikman ko kung bakit mahilig ang open source na komunidad sa mga tinidor.
Ang mga database ay mabuti dahil ang estado ng aplikasyon ay hindi na nakasalalay sa mga pag-crash/pag-restart ng application, ngunit ang pagtatrabaho sa isang database ay nagpapalubha sa code at nagpapataw ng mga paghihigpit sa istraktura ng data.

Pinagmulan: www.habr.com

Telegram bot para sa personalized na seleksyon ng mga artikulo mula kay Habr