Telegram bot për një përzgjedhje të personalizuar artikujsh nga Habr

Për pyetje të tilla si "pse?" ka një artikull më të vjetër - Natural Geektimes - duke e bërë hapësirën më të pastër.

Ka shumë artikuj, për arsye subjektive disa prej tyre nuk më pëlqejnë, dhe disa, përkundrazi, është për të ardhur keq t'i kapërcej. Do të doja ta optimizoja këtë proces dhe të kurseja kohë.

Artikulli i mësipërm sugjeroi një qasje të skriptimit në shfletues, por nuk më pëlqeu vërtet (edhe pse e kam përdorur më parë) për arsyet e mëposhtme:

• Për shfletues të ndryshëm në kompjuterin/telefonin tuaj, duhet ta konfiguroni përsëri, nëse është e mundur.
• Filtrimi i rreptë nga autorët nuk është gjithmonë i përshtatshëm.
• Problemi me autorët, artikujt e të cilëve nuk dëshironi t'i humbisni, edhe nëse botohen një herë në vit, nuk është zgjidhur.

Filtrimi i integruar në sit bazuar në vlerësimet e artikujve nuk është gjithmonë i përshtatshëm, pasi artikujt shumë të specializuar, pavarësisht nga vlera e tyre, mund të marrin një vlerësim mjaft modest.

Fillimisht, doja të gjeneroja një burim RSS (ose edhe disa), duke lënë vetëm gjëra interesante atje. Por në fund, rezultoi se leximi i RSS nuk dukej shumë i përshtatshëm: në çdo rast, për të komentuar/votuar për një artikull / për ta shtuar në të preferuarat tuaja, duhet të kaloni përmes shfletuesit. Kjo është arsyeja pse unë shkrova një bot telegram që më dërgon artikuj interesantë në një mesazh personal. Vetë Telegrami bën pamje paraprake të bukura prej tyre, të cilat, të kombinuara me informacione rreth autorit/vlerësimit/shikimeve, duken mjaft informuese.

Poshtë prerjes gjenden detaje si veçoritë e veprës, procesi i shkrimit dhe zgjidhjet teknike.

Shkurtimisht për robotin

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

Bot në telegram: https://t.me/HabraFilterBot

Përdoruesi vendos një vlerësim shtesë për etiketat dhe autorët. Pas kësaj, një filtër aplikohet në artikuj - vlerësimi i artikullit në Habré, vlerësimi i përdoruesit të autorit dhe mesatarja për vlerësimet e përdoruesve sipas etiketës janë shtuar. Nëse shuma është më e madhe se një prag i specifikuar nga përdoruesi, atëherë artikulli kalon filtrin.

Një qëllim anësor i shkrimit të një roboti ishte të fitonte argëtim dhe përvojë. Veç kësaj, ia kujtoja vetes rregullisht këtë Unë nuk jam Google, dhe për këtë arsye shumë gjëra bëhen sa më thjesht dhe madje primitive. Megjithatë, kjo nuk pengoi që procesi i shkrimit të botit të zgjasë tre muaj.

Jashtë ishte verë

Korriku po mbaronte dhe vendosa të shkruaj një bot. Dhe jo vetëm, por me një mik që po zotëronte Scalën dhe donte të shkruante diçka mbi të. Fillimi dukej premtues - kodi do të pritej nga një ekip, detyra dukej e lehtë dhe mendova se brenda disa javësh ose një muaji roboti do të ishte gati.

Përkundër faktit se unë vetë kam shkruar herë pas here kodin në shkëmb gjatë viteve të fundit, zakonisht askush nuk e sheh ose e shikon këtë kod: projekte për kafshë shtëpiake, testimi i disa ideve, përpunimi paraprak i të dhënave, zotërimi i disa koncepteve nga FP. Më interesonte vërtet se si duket shkrimi i kodit në një ekip, sepse kodi në shkëmb mund të shkruhet në mënyra shumë të ndryshme.

Çfarë mund të kishte shkuar kështu? Megjithatë, le të mos nxitojmë gjërat.
Çdo gjë që ndodh mund të gjurmohet duke përdorur historikun e kryerjes.

Një i njohur krijoi një depo më 27 korrik, por nuk bëri asgjë tjetër, kështu që fillova të shkruaj kodin.

30 korrik

Shkurtimisht: Kam shkruar një analizë të burimit rss të Habrit.

• com.github.pureconfig për leximin e konfigurimeve typesafe direkt në klasat e rasteve (doli të ishte shumë i përshtatshëm)
• scala-xml për të lexuar xml: meqenëse fillimisht doja të shkruaja implementimin tim për rss feed, dhe rss feed është në formatin xml, e përdora këtë bibliotekë për analizë. Në fakt, u shfaq edhe analiza RSS.
• scalatest për teste. Edhe për projekte të vogla, shkrimi i testeve kursen kohë - për shembull, kur korrigjoni analizën e xml, është shumë më e lehtë ta shkarkoni në një skedar, të shkruani teste dhe të korrigjoni gabimet. Kur më vonë u shfaq një gabim me analizimin e disa html të çuditshëm me karaktere të pavlefshme utf-8, doli të ishte më i përshtatshëm për ta vendosur atë në një skedar dhe për të shtuar një test.
• aktorë nga Akka. Objektivisht nuk duheshin fare, por projekti ishte shkruar për qejf, doja t'i provoja. Si rezultat, jam gati të them se më pëlqeu. Ideja e OOP mund të shihet nga ana tjetër - ka aktorë që shkëmbejnë mesazhe. Ajo që është më interesante është se ju mund (dhe duhet) të shkruani kodin në atë mënyrë që mesazhi të mos arrijë ose të mos përpunohet (në përgjithësi, kur llogaria funksionon në një kompjuter të vetëm, mesazhet nuk duhet të humbasin). Në fillim po kruajtja kokën dhe në kod kishte mbeturina me aktorë të abonuar me njëri-tjetrin, por në fund arrita të krijoj një arkitekturë mjaft të thjeshtë dhe elegante. Kodi brenda secilit aktor mund të konsiderohet i vetëm; kur një aktor rrëzohet, acca e rinis atë - rezultati është një sistem mjaft tolerant ndaj gabimeve.

9 gusht

I shtova projektit scala-scrapper për analizimin e faqeve html nga Habr (për të nxjerrë informacione të tilla si vlerësimi i artikujve, numri i faqeshënuesve, etj.).

Dhe Macet. Ato në shkëmb.

Më pas lexova një libër për bazat e të dhënave të shpërndara, më pëlqeu ideja e CRDT (lloji i të dhënave të përsëritura pa konflikte, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), kështu që unë postova një klasë tipi të një gjysmëgrupi komutativ për informacion rreth artikullit në Habré.

Në fakt, ideja është shumë e thjeshtë - kemi numërues që ndryshojnë në mënyrë monotonike. Numri i promovimeve po rritet gradualisht, si dhe numri i pluseve (si dhe numri i minuseve). Nëse kam dy versione informacioni për një artikull, atëherë mund t'i "bashkoj ato në një" - gjendja e numëruesit që është më e madhe konsiderohet më e rëndësishme.

Një gjysmëgrup do të thotë që dy objekte me informacion rreth një artikulli mund të bashkohen në një. Komutativ do të thotë që ju mund të bashkoni të dyja A + B dhe B + A, rezultati nuk varet nga rendi, dhe në fund versioni më i ri do të mbetet. Meqë ra fjala, këtu ka edhe shoqërim.

Për shembull, siç ishte planifikuar, rss pas analizimit dha informacion paksa të dobësuar për artikullin - pa metrikë të tillë si numri i shikimeve. Një aktor special më pas mori informacione rreth artikujve dhe vrapoi në faqet html për ta përditësuar dhe bashkuar me versionin e vjetër.

Në përgjithësi, si në akka, nuk kishte nevojë për këtë, thjesht mund të ruash updateDate për artikullin dhe të marrësh një më të re pa asnjë shkrirje, por rruga e aventurës më çoi.

12 gusht

Fillova të ndihesha më i lirë dhe, vetëm për argëtim, e bëra çdo bisedë një aktor më vete. Teorikisht, vetë një aktor peshon rreth 300 bajt dhe ato mund të krijohen në miliona, kështu që kjo është një qasje krejtësisht normale. Më duket se zgjidhja doli të jetë mjaft interesante:

Një aktor ishte një urë lidhëse midis serverit të telegramit dhe sistemit të mesazheve në Akka. Ai thjesht merrte mesazhe dhe ia dërgoi aktorit të dëshiruar të bisedës. Aktori i bisedës mund të dërgonte diçka si përgjigje - dhe do të dërgohej përsëri në telegram. Ajo që ishte shumë e leverdishme është se ky aktor doli të ishte sa më i thjeshtë dhe përmbante vetëm logjikën për t'iu përgjigjur mesazheve. Nga rruga, informacionet rreth artikujve të rinj erdhën në çdo bisedë, por përsëri nuk shoh ndonjë problem në këtë.

Në përgjithësi, roboti tashmë po funksiononte, duke iu përgjigjur mesazheve, duke ruajtur një listë artikujsh të dërguar te përdoruesi, dhe unë tashmë po mendoja se roboti ishte pothuajse gati. Shtova ngadalë veçori të vogla si normalizimi i emrave dhe etiketave të autorëve (duke zëvendësuar "sd f" me "s_d_f").

Kishte mbetur vetëm një gjë i vogël por — shteti nuk u shpëtua gjëkundi.

Gjithçka shkoi keq

Ju mund të keni vënë re që e kam shkruar botin kryesisht vetëm. Pra, pjesëmarrësi i dytë u përfshi në zhvillim dhe ndryshimet e mëposhtme u shfaqën në kod:

• MongoDB dukej se ruante gjendjen. Në të njëjtën kohë, regjistrat në projekt u prishën, sepse për disa arsye Monga filloi t'i dërgonte ato me spamming dhe disa njerëz thjesht i çaktivizuan globalisht.
• Aktori i urës në Telegram u transformua përtej njohjes dhe filloi të analizonte mesazhet vetë.
• Aktorët për biseda u ndërprenë pa mëshirë, dhe në vend të kësaj ata u zëvendësuan nga një aktor që fshehu të gjitha informacionet për të gjitha bisedat menjëherë. Për çdo teshtitje ky aktor hynte në telashe. Epo, po, si kur përditësoni informacionin për një artikull, dërgimi i tij tek të gjithë aktorët e bisedës është i vështirë (ne jemi si Google, miliona përdorues presin një milion artikuj në bisedë për secilin), por sa herë që biseda përditësohet, është normale të shkosh në Monga. Siç e kuptova shumë më vonë, edhe logjika e punës së bisedave u shkëput plotësisht dhe në vend të saj u shfaq diçka që nuk funksiononte.
• Nuk ka mbetur asnjë gjurmë nga klasat e tipit.
• Një logjikë e pashëndetshme është shfaqur tek aktorët me abonimet e tyre me njëri-tjetrin, duke çuar në një gjendje gare.
• Strukturat e të dhënave me fushat e tipit Option[Int] shndërrohet në Int me vlera të paracaktuara magjike si -1. Më vonë kuptova se mongoDB ruan json dhe nuk ka asgjë të keqe ta ruash atje Option mirë, ose të paktën analizoje -1 si Asnjë, por në atë kohë unë nuk e dija këtë dhe e mora fjalën që "kështu duhet të jetë". Unë nuk e shkrova atë kod dhe nuk u mërzita ta ndryshoja për momentin.
• Zbulova se adresa ime IP publike ka tendencë të ndryshojë dhe sa herë më duhej ta shtoja në listën e bardhë të Mongo. Unë e nisa bot-in lokalisht, Monga ishte diku në serverët e Monga si kompani.
• Papritur, normalizimi i etiketave dhe formatimit të mesazheve për telegramet u zhduk. (Hmm, pse do të ishte kjo?)
• Më pëlqeu që gjendja e robotit ruhet në një bazë të dhënash të jashtme dhe kur rifillohet ai vazhdon të funksionojë sikur asgjë të mos kishte ndodhur. Megjithatë, ky ishte plusi i vetëm.

Personi i dytë nuk kishte ndonjë nxitim të veçantë dhe të gjitha këto ndryshime u shfaqën në një grumbull të madh tashmë në fillim të shtatorit. Nuk e vlerësova menjëherë shkallën e shkatërrimit që rezultoi dhe fillova të kuptoj punën e bazës së të dhënave, sepse ... Nuk jam marrë kurrë më parë me ta. Vetëm më vonë kuptova se sa kod pune ishte prerë dhe sa gabime u shtuan në vend të tij.

Shtator

Në fillim mendova se do të ishte e dobishme të zotëroja Monga dhe ta bëja mirë. Më pas fillova ngadalë të kuptoj se organizimi i komunikimit me bazën e të dhënave është gjithashtu një art në të cilin mund të bësh shumë gara dhe thjesht të bësh gabime. Për shembull, nëse përdoruesi merr dy mesazhe si /subscribe - dhe në përgjigje të secilit do të krijojmë një hyrje në tabelë, sepse në momentin e përpunimit të atyre mesazheve përdoruesi nuk është i abonuar. Kam dyshimin se komunikimi me Mongën në formën aktuale nuk është i shkruar në mënyrën më të mirë. Për shembull, cilësimet e përdoruesit u krijuan në momentin që ai u regjistrua. Nëse ai u përpoq t'i ndryshonte ato para faktit të abonimit ... roboti nuk u përgjigj asgjë, sepse kodi në aktor hyri në bazën e të dhënave për cilësimet, nuk e gjeti dhe u rrëzua. Kur më pyetën pse të mos krijoni cilësime sipas nevojës, mësova se nuk ka nevojë t'i ndryshoj nëse përdoruesi nuk është abonuar... Sistemi i filtrimit të mesazheve është bërë disi jo-qartësisht, dhe madje pas një vështrimi nga afër të kodit munda nuk e kuptoj nëse fillimisht ishte menduar në këtë mënyrë apo ka një gabim atje.

Nuk kishte asnjë listë të artikujve të dorëzuar në chat; përkundrazi, u sugjerua që t'i shkruaj vetë. Kjo më befasoi - në përgjithësi, nuk isha kundër zvarritjes së të gjitha llojeve të gjërave në projekt, por do të ishte logjike për atë që i futi këto gjëra dhe i vidhte. Por jo, pjesëmarrësi i dytë dukej se hoqi dorë nga gjithçka, por tha se lista brenda bisedës ishte gjoja një zgjidhje e keqe dhe ishte e nevojshme të bëhej një shenjë me ngjarje si "një artikull y iu dërgua përdoruesit x". Më pas, nëse përdoruesi kërkonte të dërgonte artikuj të rinj, ishte e nevojshme të dërgohej një kërkesë në bazën e të dhënave, e cila do të zgjidhte ngjarjet që lidhen me përdoruesin nga ngjarjet, gjithashtu do të merrte një listë të artikujve të rinj, do t'i filtronte, do t'i dërgonte përdoruesit. dhe hidhni ngjarjet në lidhje me këtë përsëri në bazën e të dhënave.

Pjesëmarrësi i dytë u largua diku drejt abstraksioneve, kur boti do të marrë jo vetëm artikuj nga Habr dhe do të dërgohet jo vetëm në telegram.

I zbatova disi ngjarjet në formën e një shenje të veçantë për gjysmën e dytë të shtatorit. Nuk është optimale, por të paktën roboti filloi të funksiononte dhe filloi të më dërgonte artikuj përsëri, dhe ngadalë kuptova se çfarë po ndodhte në kod.

Tani mund të ktheheni në fillim dhe të mbani mend se depoja nuk u krijua fillimisht nga unë. Çfarë mund të kishte shkuar kështu? Kërkesa ime për tërheqje u refuzua. Doli që kisha një kod redneck, se nuk dija të punoja në një ekip dhe më duhej të rregulloja gabimet në kurbën aktuale të zbatimit dhe jo ta përsosi atë në një gjendje të përdorshme.

U mërzita dhe shikova historinë e kryerjes dhe sasinë e kodit të shkruar. Shikova momente që fillimisht ishin shkruar mirë dhe më pas ishin thyer...

F*rk it

M'u kujtua artikulli Ju nuk jeni Google.

Mendova se askush nuk ka nevojë për një ide pa zbatim. Mendova se dua të kem një bot që funksionon, i cili do të funksionojë në një kopje të vetme në një kompjuter të vetëm si një program i thjeshtë java. E di që roboti im do të funksionojë me muaj pa rinisje, pasi kam shkruar tashmë robotë të tillë në të kaluarën. Nëse papritmas bie dhe nuk i dërgon përdoruesit një artikull tjetër, qielli nuk do të bjerë në tokë dhe asgjë katastrofike nuk do të ndodhë.

Pse më duhet Docker, mongoDB dhe kultet të tjera të ngarkesave të softuerit "serioz" nëse kodi thjesht nuk funksionon ose funksionon shtrembër?

E mbylla projektin dhe bëra gjithçka siç doja.

Në të njëjtën kohë, ndryshova punë dhe koha e lirë mungoi shumë. Në mëngjes u zgjova pikërisht në tren, në mbrëmje u ktheva vonë dhe nuk doja më të bëja asgjë. Nuk bëra asgjë për një kohë, më pas dëshira për të përfunduar bot-in më pushtoi dhe fillova të rishkruaj ngadalë kodin ndërsa po udhëtoja për në punë në mëngjes. Nuk do të them se ishte produktiv: të ulesh në një tren që dridhej me një laptop në prehër dhe të shikosh tejmbushjen e pirgut nga telefoni yt nuk është shumë i përshtatshëm. Sidoqoftë, koha e kaluar për të shkruar kodin kaloi plotësisht pa u vënë re dhe projekti filloi të lëvizte ngadalë drejt një gjendje pune.

Diku në fund të mendjes sime kishte një krimb dyshimi që donte të përdorte mongoDB, por mendova se përveç avantazheve të ruajtjes së shtetit "të besueshëm", kishte edhe disavantazhe të dukshme:

• Baza e të dhënave bëhet një tjetër pikë dështimi.
• Kodi po bëhet më kompleks dhe do të më duhet më shumë kohë për ta shkruar atë.
• Kodi bëhet i ngadalshëm dhe joefikas; në vend që të ndryshojë një objekt në memorie, ndryshimet dërgohen në bazën e të dhënave dhe, nëse është e nevojshme, tërhiqen.
• Ekzistojnë kufizime në llojin e ruajtjes së ngjarjeve në një tabelë të veçantë, të cilat shoqërohen me veçoritë e bazës së të dhënave.
• Versioni i provës i Monga ka disa kufizime, dhe nëse i hasni, do t'ju duhet të nisni dhe konfiguroni Monga në diçka.

Unë preva monga, tani gjendja e botit thjesht ruhet në kujtesën e programit dhe herë pas here ruhet në një skedar në formën e json. Ndoshta në komente do të shkruajnë se e kam gabim, se këtu duhet përdorur databaza etj. Por ky është projekti im, qasja me dosjen është sa më e thjeshtë dhe funksionon në mënyrë transparente.

Hodhi vlerat magjike si -1 dhe ktheu ato normale Option, shtoi ruajtjen e një tabele hash me artikuj të dërguar përsëri në objekt me informacione bisede. U shtua fshirja e informacionit për artikujt më të vjetër se pesë ditë, në mënyrë që të mos ruheshin gjithçka. E solla regjistrimin në një gjendje pune - regjistrat shkruhen në sasi të arsyeshme si në skedar ashtu edhe në tastierë. U shtuan disa komanda administratori si ruajtja e gjendjes ose marrja e statistikave si numri i përdoruesve dhe artikujve.

Rregulloi një mori gjërash të vogla: për shembull, për artikujt tregohet numri i shikimeve, pëlqimeve, mospëlqimeve dhe komenteve në momentin e kalimit të filtrit të përdoruesit. Në përgjithësi, është e habitshme se sa gjëra të vogla duheshin korrigjuar. Mbajta një listë, vura re të gjitha "parregullsitë" atje dhe i korrigjova sa më shumë që të ishte e mundur.

Për shembull, unë shtova mundësinë për të vendosur të gjitha cilësimet drejtpërdrejt në një mesazh:

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

Dhe një ekip tjetër /settings i shfaq ato saktësisht në këtë formë, mund të merrni tekstin prej tij dhe t'i dërgoni të gjitha cilësimet një miku.
Duket si një gjë e vogël, por ka dhjetëra nuanca të ngjashme.

Filtrimi i artikujve të zbatuar në formën e një modeli të thjeshtë linear - përdoruesi mund të vendosë një vlerësim shtesë për autorët dhe etiketat, si dhe një vlerë pragu. Nëse shuma e vlerësimit të autorit, vlerësimi mesatar për etiketat dhe vlerësimi aktual i artikullit është më i madh se vlera e pragut, atëherë artikulli i shfaqet përdoruesit. Ju ose mund t'i kërkoni botit artikuj me komandën /new, ose abonoheni në bot dhe ai do të dërgojë artikuj në një mesazh personal në çdo kohë të ditës.

Në përgjithësi, kisha një ide që çdo artikull të nxirrte më shumë veçori (qendër, numrin e komenteve, faqerojtësit, dinamikën e ndryshimeve të vlerësimit, sasinë e tekstit, fotografitë dhe kodin në artikull, fjalë kyçe) dhe t'i tregonte përdoruesit një ok/ jo ok votoni nën çdo artikull dhe trajnoni një model për çdo përdorues, por unë isha shumë dembel.

Për më tepër, logjika e punës nuk do të jetë aq e dukshme. Tani mund të vendos manualisht një vlerësim prej +9000 për pacientinZero dhe me një vlerësim pragu prej +20 do të jem i garantuar të marr të gjithë artikujt e tij (përveç nëse, sigurisht, vendos -100500 për disa etiketa).

Arkitektura përfundimtare doli të ishte mjaft e thjeshtë:

1. Një aktor që ruan gjendjen e të gjitha bisedave dhe artikujve. Ai ngarkon gjendjen e tij nga një skedar në disk dhe e ruan atë herë pas here, çdo herë në një skedar të ri.
2. Një aktor që viziton burimin RSS herë pas here, mëson për artikuj të rinj, shikon lidhjet, analizon dhe ia dërgon këta artikuj aktorit të parë. Përveç kësaj, ndonjëherë kërkon një listë artikujsh nga aktori i parë, zgjedh ata që nuk janë më të vjetër se tre ditë, por nuk janë përditësuar për një kohë të gjatë dhe i përditëson.
3. Një aktor që komunikon me një telegram. Unë ende e solla analizimin e mesazhit plotësisht këtu. Në mënyrë miqësore, unë do të doja ta ndaja në dy - në mënyrë që njëra të analizojë mesazhet hyrëse dhe e dyta të merret me problemet e transportit si ridërgimi i mesazheve të padërguara. Tani nuk ka ri-dërgim dhe një mesazh që nuk ka mbërritur për shkak të një gabimi thjesht do të humbet (përveç nëse shënohet në regjistrat), por deri më tani kjo nuk ka shkaktuar ndonjë problem. Ndoshta do të lindin probleme nëse një grup njerëzish abonohen në bot dhe unë arrij kufirin për dërgimin e mesazheve).

Ajo që më pëlqeu është se falë akka-s, rëniet e aktorëve 2 dhe 3 përgjithësisht nuk ndikojnë në performancën e botit. Ndoshta disa artikuj nuk përditësohen në kohë ose disa mesazhe nuk arrijnë në telegram, por llogaria rinis aktorin dhe gjithçka vazhdon të funksionojë. Unë ruaj informacionin që artikulli i shfaqet përdoruesit vetëm kur aktori i telegramit përgjigjet se e ka dërguar me sukses mesazhin. Gjëja më e keqe që më kërcënon është të dërgoj mesazhin disa herë (nëse dërgohet, por konfirmimi humbet disi). Në parim, nëse aktori i parë nuk e ruante gjendjen brenda vetes, por komunikonte me ndonjë bazë të dhënash, atëherë edhe ai mund të binte në mënyrë të padukshme dhe të kthehej në jetë. Mund të provoja edhe akka persistance për të rivendosur gjendjen e aktorëve, por zbatimi aktual më përshtatet me thjeshtësinë e tij. Nuk është se kodi im rrëzohej shpesh - përkundrazi, kam bërë shumë përpjekje për ta bërë të pamundur. Por mut ndodhin dhe aftësia për ta ndarë programin në pjesë të izoluara-aktorë më dukej vërtet e përshtatshme dhe praktike.

Unë shtova rrethin-ci në mënyrë që nëse kodi prishet, menjëherë do të mësoni për të. Së paku, kjo do të thotë që kodi ka ndaluar përpilimin. Fillimisht doja të shtoja travis, por ai tregonte vetëm projektet e mia pa pirunë. Në përgjithësi, të dyja këto gjëra mund të përdoren lirisht në depo të hapura.

Rezultatet e

Tashmë është nëntor. Boti eshte i shkruar, e kam perdor dy javet e fundit dhe me pelqeu. Nëse keni ide për përmirësim, shkruani. Unë nuk e shoh kuptimin në fitimin e parave - le të funksionojë dhe dërgoni artikuj interesantë.

Lidhja e robotit: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Përfundime të vogla:

• Edhe një projekt i vogël mund të marrë shumë kohë.
• Ju nuk jeni Google. Nuk ka kuptim të gjuash harabela nga një top. Një zgjidhje e thjeshtë mund të funksionojë po aq mirë.
• Projektet e kafshëve shtëpiake janë shumë të mira për të eksperimentuar me teknologji të reja.
• Botet e telegramit janë shkruar mjaft thjesht. Nëse nuk do të ishte për "punë ekipore" dhe eksperimente me teknologjinë, roboti do të ishte shkruar brenda një ose dy javësh.
• Modeli i aktorit është një gjë interesante që shkon mirë me kodin shumëfijesh dhe tolerant ndaj gabimeve.
• Unë mendoj se kam marrë një shije se pse komuniteti me burim të hapur i pëlqen pirunët.
• Bazat e të dhënave janë të mira sepse gjendja e aplikacionit nuk varet më nga dështimet/rifillimet e aplikacionit, por puna me një bazë të dhënash e ndërlikon kodin dhe imponon kufizime në strukturën e të dhënave.

Burimi: www.habr.com