Habr-dan məqalələrin fərdi seçimi üçün Telegram botu

“Niyə?” kimi suallar üçün köhnə məqalə var - Natural Geektimes - məkanı təmizləyir.

Çoxlu məqalələr var, subyektiv səbəblərdən bəzilərini bəyənmirəm, bəzilərini isə əksinə, keçmək təəssüf doğurur. Mən bu prosesi optimallaşdırmaq və vaxta qənaət etmək istərdim.

Yuxarıdakı məqalə brauzerdaxili skript yanaşmasını təklif etdi, lakin aşağıdakı səbəblərə görə bunu (əvvəllər istifadə etdiyimə baxmayaraq) bəyənmədim:

• Kompüterinizdə/telefonunuzda müxtəlif brauzerlər üçün, mümkünsə, onu yenidən konfiqurasiya etməlisiniz.
• Müəlliflər tərəfindən ciddi filtrasiya həmişə əlverişli deyil.
• İldə bir dəfə dərc olunsa belə, məqalələrini qaçırmaq istəmədiyiniz müəlliflərlə bağlı problem həllini tapmayıb.

Məqalələrin reytinqlərinə əsasən sayta daxil edilmiş filtrləmə həmişə əlverişli deyil, çünki yüksək ixtisaslaşdırılmış məqalələr, dəyərinə baxmayaraq, olduqca təvazökar bir reytinq ala bilər.

Əvvəlcə RSS lenti (və ya hətta bir neçəsi) yaratmaq istədim, orada yalnız maraqlı şeylər buraxdım. Amma sonda məlum oldu ki, RSS-i oxumaq o qədər də rahat görünmür: istənilən halda məqaləyə şərh vermək/səs vermək/favoritlərinizə əlavə etmək üçün brauzerdən keçmək lazımdır. Ona görə də şəxsi mesajımda mənə maraqlı yazılar göndərən teleqram botu yazdım. Telegram özü onlardan gözəl önizləmələr edir ki, bu da müəllif/reytinq/baxışlar haqqında məlumatla birlikdə olduqca informativ görünür.

Kəsimin altında işin xüsusiyyətləri, yazı prosesi və texniki həllər kimi detallar var.

Bot haqqında qısaca

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

Telegramda bot: https://t.me/HabraFilterBot

İstifadəçi etiketlər və müəlliflər üçün əlavə reytinq təyin edir. Bundan sonra məqalələrə filtr tətbiq olunur - Habré-də məqalənin reytinqi, müəllifin istifadəçi reytinqi və etiket üzrə istifadəçi reytinqləri üçün ortalama əlavə olunur. Məbləğ istifadəçi tərəfindən müəyyən edilmiş hədddən böyükdürsə, məqalə filtrdən keçir.

Bot yazmağın bir yan məqsədi əyləncə və təcrübə qazanmaq idi. Bundan əlavə, mən bunu müntəzəm olaraq özümə xatırladırdım Mən Google deyiləm, və buna görə də bir çox şey mümkün qədər sadə və hətta primitiv şəkildə edilir. Ancaq bu, botun yazılması prosesinin üç ay çəkməsinə mane olmadı.

Çöldə yay idi

İyul ayı başa çatırdı və mən bot yazmağa qərar verdim. Özü də tək yox, skalanı mənimsəyən və üzərinə nəsə yazmaq istəyən dostumla. Başlanğıc ümidverici görünürdü - kod bir komanda tərəfindən kəsiləcək, tapşırıq asan görünürdü və düşündüm ki, bir neçə həftə və ya bir aya bot hazır olacaq.

Baxmayaraq ki, mən özüm də son bir neçə ildə ara-sıra qaya üzərində kod yazıram, adətən heç kim bu kodu görmür və ona baxmır: ev heyvanları layihələri, bəzi ideyaların sınaqdan keçirilməsi, məlumatların əvvəlcədən işlənməsi, FP-dən bəzi anlayışların mənimsənilməsi. Komandada kodun yazılmasının necə olduğu mənə çox maraqlı idi, çünki qaya üzərindəki kod çox müxtəlif yollarla yazıla bilər.

Nə gedə bilərdi belə? Bununla belə, hər şeyi tələsməyək.
Baş verən hər şeyi öhdəçilik tarixindən istifadə edərək izləmək olar.

Bir tanışım iyulun 27-də anbar yaratdı, amma başqa heç nə etmədi və kod yazmağa başladım.

30 iyul

Qısaca: Habrın rss lentinin təhlilini yazdım.

• com.github.pureconfig typesafe konfiqurasiyalarını birbaşa iş siniflərinə oxumaq üçün (çox rahat olduğu ortaya çıxdı)
• scala-xml xml oxumaq üçün: əvvəlcə rss lenti üçün öz tətbiqimi yazmaq istədim və rss lenti xml formatında olduğundan, mən bu kitabxananı təhlil etmək üçün istifadə etdim. Əslində, RSS təhlili də ortaya çıxdı.
• scalatest testlər üçün. Hətta kiçik layihələr üçün testlərin yazılması vaxta qənaət edir - məsələn, xml analizini sazlayarkən onu fayla yükləmək, testlər yazmaq və səhvləri düzəltmək çox asandır. Etibarsız utf-8 simvolları ilə bəzi qəribə html-nin təhlili ilə daha sonra səhv ortaya çıxanda onu fayla yerləşdirmək və test əlavə etmək daha rahat oldu.
• Akkadan olan aktyorlar. Obyektiv olaraq bunlara heç ehtiyac yoxdu, amma layihə əyləncə üçün yazılmışdı, onları sınamaq istədim. Nəticədə onu bəyəndiyimi söyləməyə hazıram. OOP ideyasına digər tərəfdən baxmaq olar - mesaj mübadiləsi edən aktyorlar var. Daha maraqlısı odur ki, kodu elə yaza bilərsiniz (və etməlisiniz) ki, mesaj gəlməyəcək və ya işlənməyəcək (ümumiyyətlə hesab bir kompüterdə işləyərkən mesajlar itirilməməlidir). Əvvəlcə başımı cızırdım və kodda aktyorların bir-birinə abunə olduğu zibil var idi, amma sonda kifayət qədər sadə və zərif bir memarlıq yaratmağı bacardım. Hər bir aktyorun içindəki kod tək yivli hesab edilə bilər; bir aktyor qəzaya uğradıqda, acca onu yenidən işə salır - nəticə kifayət qədər səhvlərə dözümlü bir sistemdir.

9 avqust

Layihəyə əlavə etdim scala-scrapper Habr-dan html səhifələrini təhlil etmək üçün (məqalə reytinqi, əlfəcinlərin sayı və s. kimi məlumatları çıxarmaq üçün).

Və Pişiklər. Qayada olanlar.

Sonra paylanmış verilənlər bazaları haqqında bir kitab oxudum, CRDT ideyasını bəyəndim (Münaqişəsiz təkrarlanan məlumat növü, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, habr), buna görə də Habré-dəki məqalə haqqında məlumat üçün kommutativ yarımqrupun növ sinfini yerləşdirdim.

Əslində, fikir çox sadədir - monoton şəkildə dəyişən sayğaclarımız var. Promosyonların sayı, artıların sayı (eləcə də mənfi cəhətlərin sayı) kimi tədricən artır. Bir məqalə haqqında məlumatın iki versiyası varsa, onları "birləşdirə bilərəm" - daha böyük olan sayğacın vəziyyəti daha uyğun hesab olunur.

Yarımqrup o deməkdir ki, məqalə haqqında məlumatı olan iki obyekt birinə birləşdirilə bilər. Kommutativ o deməkdir ki, həm A + B, həm də B + A birləşdirə bilərsiniz, nəticə sifarişdən asılı deyil və sonda ən yeni versiya qalacaq. Yeri gəlmişkən, burada da assosiativlik var.

Məsələn, planlaşdırıldığı kimi, təhlildən sonra rss məqalə haqqında bir qədər zəifləmiş məlumat verdi - baxış sayı kimi göstəricilər olmadan. Daha sonra xüsusi bir aktyor məqalələr haqqında məlumat götürdü və onu yeniləmək və köhnə versiya ilə birləşdirmək üçün html səhifələrinə qaçdı.

Ümumiyyətlə, akkada olduğu kimi, buna ehtiyac yox idi, sadəcə olaraq məqalə üçün updateDate saxlaya və heç bir birləşmədən daha yenisini götürə bilərsiniz, amma macəra yolu məni apardı.

12 avqust

Özümü daha azad hiss etməyə başladım və sadəcə əylənmək üçün hər söhbəti ayrı aktyor etdim. Nəzəri olaraq, aktyorun özü təxminən 300 bayt ağırlığındadır və onlar milyonlarla yaradıla bilər, ona görə də bu, tamamilə normal yanaşmadır. Mənə elə gəlir ki, həll olduqca maraqlı oldu:

Aktyorlardan biri Akkada teleqram serveri ilə mesaj sistemi arasında körpü olub. O, sadəcə olaraq mesajlar aldı və onları istədiyiniz chat aktyoruna göndərdi. Çat aktyoru cavab olaraq bir şey göndərə bilərdi və o, teleqrama geri göndəriləcəkdi. Çox əlverişli olan o idi ki, bu aktyor mümkün qədər sadə idi və yalnız mesajlara cavab vermək məntiqini ehtiva edirdi. Yeri gəlmişkən, hər söhbətə yeni məqalələr haqqında məlumat gəldi, amma yenə də bunda heç bir problem görmürəm.

Ümumiyyətlə, bot artıq işləyir, mesajlara cavab verir, istifadəçiyə göndərilən məqalələrin siyahısını saxlayır və mən artıq botun demək olar ki, hazır olduğunu düşünürdüm. Yavaş-yavaş müəllif adlarını və etiketlərini normallaşdırmaq kimi kiçik funksiyalar əlavə etdim (“sd f” hərfini “s_d_f” ilə əvəz etdim).

Yalnız bir şey qaldı kiçik amma — dövlət heç yerdə xilas olmadı.

Hər şey səhv getdi

Siz botu əsasən tək yazdığımı görmüsünüz. Beləliklə, ikinci iştirakçı inkişafda iştirak etdi və kodda aşağıdakı dəyişikliklər meydana çıxdı:

• MongoDB vəziyyəti saxlamaq üçün göründü. Eyni zamanda, layihədəki loglar qırıldı, çünki nədənsə Monga onları spam etməyə başladı və bəzi insanlar onları qlobal olaraq sadəcə olaraq söndürdü.
• Telegram-dakı körpü aktyoru tanınmaz dərəcədə dəyişdi və özü mesajları təhlil etməyə başladı.
• Söhbət üçün aktyorlar amansızcasına kəsildi və əvəzində bütün söhbətlər haqqında bütün məlumatları bir anda gizlədən bir aktyor gəldi. Hər asqırıqda bu aktyorun başına bəla gəlirdi. Bəli, bəli, məqalə haqqında məlumatı yeniləyərkən onu bütün chat aktyorlarına göndərmək çətindir (biz Google kimiyik, milyonlarla istifadəçi hər biri üçün çatda bir milyon məqalə gözləyir), lakin hər dəfə söhbət yenilənəndə, Monqaya girmək normaldır. Çox sonra başa düşdüm ki, söhbətlərin iş məntiqi də tamamilə kəsilib və onun yerində işləməyən bir şey yaranıb.
• Tip siniflərindən əsər-əlamət qalmayıb.
• Aktyorların bir-birinə abunə olması ilə hansısa qeyri-sağlam məntiq ortaya çıxıb, yarış vəziyyətinə gətirib çıxarıb.
• Tip sahələri ilə məlumat strukturları Option[Int] -1 kimi sehrli standart dəyərlərlə Int-ə çevrildi. Sonralar anladım ki, mongoDB json-u saxlayır və onu orada saxlamağın heç bir problemi yoxdur Option yaxşı, və ya heç olmasa -1-i Yox kimi təhlil edin, amma o zaman mən bunu bilmirdim və sözümü “belə olmalıdır” kimi qəbul etdim. Mən o kodu yazmamışam və hələlik onu dəyişdirməkdən çəkinməmişəm.
• Bildim ki, mənim ictimai IP ünvanım dəyişməyə meyllidir və hər dəfə onu Monqonun ağ siyahısına əlavə etməli oldum. Mən botu yerli olaraq işə saldım, Monga bir şirkət olaraq Monga serverlərində bir yerdə idi.
• Birdən teleqramlar üçün etiketlərin və mesaj formatının normallaşdırılması yox oldu. (Hmm, niyə belə olsun?)
• Xoşuma gəldi ki, botun vəziyyəti xarici verilənlər bazasında saxlanılır və yenidən işə salındıqda heç nə olmamış kimi işləməyə davam edir. Ancaq bu, yeganə artı idi.

İkinci şəxs heç bir tələsmədi və bütün bu dəyişikliklər sentyabrın əvvəlində bir böyük yığında meydana çıxdı. Mən nəticədə olan dağıntının miqyasını dərhal qiymətləndirmədim və verilənlər bazasının işini başa düşməyə başladım, çünki... Mən əvvəllər onlarla heç vaxt məşğul olmamışam. Yalnız sonradan nə qədər iş kodunun kəsildiyini və onun yerinə nə qədər səhvlərin əlavə edildiyini başa düşdüm.

Sentyabr

Əvvəlcə düşündüm ki, Monqaya yiyələnmək və bunu yaxşı etmək faydalı olacaq. Sonra yavaş-yavaş başa düşməyə başladım ki, verilənlər bazası ilə ünsiyyətin təşkili həm də çoxlu yarışlar edib, sadəcə səhvlər edə biləcəyiniz bir sənətdir. Məsələn, istifadəçi kimi iki mesaj alırsa /subscribe - və hər birinə cavab olaraq cədvəldə bir qeyd yaradacağıq, çünki həmin mesajların işlənməsi zamanı istifadəçi abunə deyil. Monqa ilə indiki formada ünsiyyətin ən yaxşı şəkildə yazılmadığına şübhəm var. Məsələn, istifadəçi parametrləri onun qeydiyyatdan keçdiyi anda yaradılmışdır. Abunə faktından əvvəl onları dəyişdirməyə çalışsa... bot heç nə cavab vermədi, çünki aktyordakı kod parametrlər üçün verilənlər bazasına daxil oldu, tapmadı və çökdü. Niyə lazım olduğu kimi parametrləri yaratmadığımı soruşduqda, mən öyrəndim ki, istifadəçi abunə olmayıbsa, onları dəyişdirməyə ehtiyac yoxdur... Mesajların filtrasiya sistemi bir növ qeyri-açıq şəkildə edilib və hətta koda yaxından baxdıqdan sonra belə edə bildim. Başlanğıcda bu cür nəzərdə tutulub, yoxsa orada bir səhv var.

Çata göndərilən məqalələrin siyahısı yox idi, əksinə, onları özüm yazmağım təklif edildi. Bu məni təəccübləndirdi - ümumiyyətlə, mən hər cür şeyi layihənin içinə sürükləməyin əleyhinə deyildim, amma bu şeyləri gətirən və bura vuran üçün məntiqli olardı. Ancaq yox, ikinci iştirakçı sanki hər şeydən imtina etdi, ancaq söhbətin içindəki siyahının guya pis bir həll olduğunu söylədi və “x istifadəçisinə y məqaləsi göndərildi” kimi hadisələrlə işarə etmək lazım olduğunu söylədi. Daha sonra istifadəçi yeni məqalələrin göndərilməsini tələb edərsə, verilənlər bazasına sorğu göndərmək lazım idi ki, bu da hadisələrdən istifadəçi ilə bağlı hadisələri seçir, həmçinin yeni məqalələrin siyahısını alır, onları filtrləyir, istifadəçiyə göndərir. və bununla bağlı hadisələri yenidən verilənlər bazasına atın.

İkinci iştirakçı, bot nəinki Habr-dan məqalələr alacaq və nəinki Telegram-a göndəriləcəyi zaman abstraksiyalara doğru getdi.

Sentyabrın ikinci yarısı üçün tədbirləri birtəhər ayrıca işarə şəklində həyata keçirdim. Bu optimal deyil, amma heç olmasa bot işləməyə başladı və mənə yenidən məqalələr göndərməyə başladı və mən yavaş-yavaş kodda nə baş verdiyini anladım.

İndi başlanğıca qayıda bilərsiniz və anbarın əvvəlcə mənim tərəfimdən yaradılmadığını xatırlaya bilərsiniz. Nə belə gedə bilərdi? Mənim çəkmə tələbim rədd edildi. Məlum oldu ki, mənim redneck kodum var, komandada necə işləyəcəyimi bilmirdim və cari tətbiq əyrisindəki səhvləri düzəltməli və onu istifadəyə yararlı vəziyyətə gətirməməliydim.

Mən əsəbləşdim və öhdəliyin tarixinə və yazılan kodun miqdarına baxdım. Başlanğıcda yaxşı yazılan, sonra isə qırılan anlara baxdım...

F*rk bunu

Məqaləni xatırladım Siz Google deyilsiniz.

Fikirləşdim ki, reallaşdırmadan ideya heç kimə lazım deyil. Düşündüm ki, sadə java proqramı kimi bir kompüterdə bir nüsxədə işləyəcək işləyən bir bota sahib olmaq istəyirəm. Bilirəm ki, botum aylarla yenidən başlamadan işləyəcək, çünki əvvəllər belə botları yazmışam. Birdən düşsə və istifadəçiyə başqa məqalə göndərməsə, səma yerə düşməyəcək və fəlakətli bir şey olmayacaq.

Əgər kod sadəcə işləmirsə və ya əyri işləyirsə, niyə mənə Docker, mongoDB və digər “ciddi” proqram yük kultu lazımdır?

Layihəni çəngəllədim və hər şeyi istədiyim kimi etdim.

Təxminən eyni vaxtda iş yerimi dəyişdim və boş vaxtım çox az oldu. Səhər düz qatarda oyandım, axşam gec qayıtdım və artıq heç nə etmək istəmirdim. Bir müddət heç nə etmədim, sonra botu bitirmək istəyi məni alt-üst etdi və səhər işə gedərkən yavaş-yavaş kodu yenidən yazmağa başladım. Bunun məhsuldar olduğunu söyləməyəcəyəm: dizinizdə dizüstü kompüterlə silkələnən qatarda oturmaq və telefonunuzdan yığın daşmasına baxmaq çox rahat deyil. Bununla belə, kod yazmağa sərf olunan vaxt tamamilə nəzərə çarpmadan keçdi və layihə yavaş-yavaş işlək vəziyyətə doğru irəliləməyə başladı.

Fikrimin arxasında mongoDB-dən istifadə etmək istəyən bir şübhə qurdu var idi, lakin mən düşündüm ki, “etibarlı” dövlət yaddaşının üstünlükləri ilə yanaşı, nəzərəçarpacaq çatışmazlıqlar da var:

• Verilənlər bazası başqa bir uğursuzluq nöqtəsinə çevrilir.
• Kod getdikcə mürəkkəbləşir və onu yazmağım daha çox vaxt aparacaq.
• Kod yavaş və səmərəsiz olur; yaddaşdakı obyekti dəyişdirmək əvəzinə dəyişikliklər verilənlər bazasına göndərilir və lazım olduqda geri çəkilir.
• Hadisələrin ayrı bir cədvəldə saxlanma növü ilə bağlı məhdudiyyətlər var, bunlar verilənlər bazasının xüsusiyyətləri ilə bağlıdır.
• Monga-nın sınaq versiyasında bəzi məhdudiyyətlər var və onlara rast gəlsəniz, Monga-nı nə isə işə salmalı və konfiqurasiya etməli olacaqsınız.

Monqanı kəsdim, indi botun vəziyyəti sadəcə proqramın yaddaşında saxlanılır və vaxtaşırı json şəklində faylda saxlanılır. Ola bilsin ki, şərhlərdə yazırlar ki, mən səhv edirəm, verilənlər bazası burada istifadə olunmalıdır və s. Amma bu mənim layihəmdir, faylla yanaşma mümkün qədər sadədir və şəffaf şəkildə işləyir.

-1 kimi sehrli dəyərləri atdı və normal olanları qaytardı Option, söhbət məlumatı ilə obyektə göndərilən məqalələrlə hash cədvəlinin əlavə saxlanması. Hər şeyi saxlamamaq üçün beş gündən çox köhnə məqalələr haqqında məlumatların silinməsi əlavə edildi. Girişi işlək vəziyyətə gətirdim - qeydlər həm fayla, həm də konsola ağlabatan miqdarda yazılır. Vəziyyəti saxlamaq və ya istifadəçilərin və məqalələrin sayı kimi statistikanın əldə edilməsi kimi bir neçə admin əmrləri əlavə edildi.

Bir sıra xırda şeylər düzəldildi: məsələn, məqalələr üçün istifadəçi filtrindən keçərkən baxışların, bəyənmələrin, bəyənməmələrin və şərhlərin sayı indi göstərilir. Ümumiyyətlə, nə qədər kiçik şeylərin düzəldilməli olduğu təəccüblüdür. Siyahı tutdum, oradakı bütün “qanunsuzluqları” qeyd etdim və mümkün qədər düzəltdim.

Məsələn, bütün parametrləri birbaşa bir mesajda qurmaq imkanı əlavə etdim:

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

Və başqa komanda /settings onları tam olaraq bu formada göstərir, ondan mətn götürüb bütün parametrləri dostunuza göndərə bilərsiniz.
Kiçik bir şey kimi görünür, lakin onlarla oxşar nüanslar var.

Sadə xətti model şəklində məqalə süzgəcini həyata keçirdi - istifadəçi müəlliflər və teqlər üçün əlavə reytinq, habelə hədd dəyəri təyin edə bilər. Müəllifin reytinqi, teqlər üçün orta reytinq və məqalənin faktiki reytinqinin cəmi hədd dəyərindən böyükdürsə, məqalə istifadəçiyə göstərilir. Siz ya /new əmri ilə botdan məqalələr istəyə bilərsiniz, ya da bota abunə ola bilərsiniz və o, günün istənilən vaxtı məqalələri şəxsi mesajla göndərəcək.

Ümumiyyətlə, hər bir məqalə üçün daha çox funksiya (hublar, şərhlərin sayı, əlfəcinlər, reytinq dəyişikliklərinin dinamikası, məqalədəki mətnin miqdarı, şəkillər və kodlar, açar sözlər) çıxarmaq və istifadəçiyə ok/ işarəsi göstərmək fikrim var idi. hər məqalənin altında səs vermək və hər istifadəçi üçün bir model hazırlamaq deyil, amma çox tənbəl idim.

Bundan əlavə, işin məntiqi o qədər də açıq olmayacaq. İndi mən pasientZero üçün əl ilə +9000 reytinqini təyin edə bilərəm və həddi +20 ilə onun bütün məqalələrini almağa zəmanət veriləcək (əlbəttə ki, bəzi teqlər üçün -100500 təyin etməsəm).

Son memarlıq olduqca sadə oldu:

1. Bütün söhbətlərin və məqalələrin vəziyyətini saxlayan aktyor. O, vəziyyətini diskdəki fayldan yükləyir və onu zaman-zaman, hər dəfə yeni faylda saxlayır.
2. Zaman-zaman RSS lentinə baş çəkən, yeni məqalələrlə tanış olan, keçidlərə baxan, təhlil edən və bu məqalələri ilk aktyora göndərən aktyor. Bundan əlavə, bəzən birinci aktyordan məqalələrin siyahısını tələb edir, üç gündən çox olmayan, lakin uzun müddətdir yenilənməmiş məqalələri seçir və onları yeniləyir.
3. Teleqramla ünsiyyət quran aktyor. Mən hələ də mesajın təhlilini tamamilə buraya gətirdim. Dostcasına, mən onu ikiyə bölmək istərdim ki, biri gələn mesajları təhlil etsin, ikincisi isə göndərilməmiş mesajların yenidən göndərilməsi kimi nəqliyyat problemləri ilə məşğul olsun. İndi təkrar göndərmə yoxdur və xəta səbəbindən gəlməmiş mesaj sadəcə itiriləcək (bu, qeydlərdə qeyd edilmədiyi təqdirdə), lakin bu günə qədər heç bir problem yaratmayıb. Yəqin ki, bir dəstə insan bota abunə olsa və mesaj göndərmək limitinə çatsam, problemlər yaranacaq).

Sevdiyim odur ki, akka sayəsində 2 və 3-cü aktyorların düşməsi ümumiyyətlə botun performansına təsir etmir. Bəlkə də bəzi məqalələr vaxtında yenilənmir və ya bəzi mesajlar teleqrama çatmır, amma hesab aktyoru yenidən işə salır və hər şey işləməyə davam edir. Məqalənin istifadəçiyə göstərildiyi barədə məlumatı yalnız teleqram aktyoru mesajı uğurla çatdırdığını cavablandırdıqda saxlayıram. Məni təhdid edən ən pis şey mesajı bir neçə dəfə göndərməkdir (əgər çatdırılırsa, lakin təsdiq bir şəkildə itirilirsə). Prinsipcə, əgər birinci aktyor dövləti öz daxilində saxlamasa, hansısa məlumat bazası ilə əlaqə saxlasa, o zaman o da hiss olunmadan yıxılıb həyata qayıda bilərdi. Aktyorların vəziyyətini bərpa etmək üçün akka əzmkarlığı da sınaya bilərdim, lakin indiki tətbiq sadəliyi ilə mənə uyğun gəlir. Bu kodumun tez-tez qəzaya uğraması deyil - əksinə, bunu qeyri-mümkün etmək üçün çox səy göstərdim. Amma bok baş verir və proqramı ayrı-ayrı parçalara-aktyorlara bölmək bacarığı mənə həqiqətən rahat və praktik görünürdü.

Mən dairə-ci əlavə etdim ki, kod pozulsa, dərhal bundan xəbər tutasınız. Ən azı kodun tərtibini dayandırdığını bildirir. Əvvəlcə travis əlavə etmək istədim, lakin o, yalnız layihələrimi çəngəlsiz göstərdi. Ümumiyyətlə, bunların hər ikisi açıq depolarda sərbəst şəkildə istifadə edilə bilər.

Nəticələri

Artıq noyabrdır. Bot yazılıb, son iki həftədir istifadə edirəm və xoşuma gəldi. Təkmilləşdirmək üçün fikirləriniz varsa, yazın. Mən ondan pul qazanmağın mənasını görmürəm - qoy iş görsün və maraqlı məqalələr göndərsin.

Bot linki: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Kiçik nəticələr:

• Hətta kiçik bir layihə çox vaxt apara bilər.
• Siz Google deyilsiniz. Topdan sərçə atmağın mənası yoxdur. Sadə bir həll də işləyə bilər.
• Heyvan layihələri yeni texnologiyalarla təcrübə aparmaq üçün çox yaxşıdır.
• Telegram botları olduqca sadə yazılıb. Əgər “komanda işi” və texnologiya ilə təcrübələr olmasaydı, bot bir-iki həftəyə yazılacaqdı.
• Aktyor modeli çox iş parçacığı və xətaya dözümlü kodla yaxşı gedən maraqlı bir şeydir.
• Düşünürəm ki, açıq mənbə cəmiyyətinin çəngəlləri niyə sevdiyini anladım.
• Verilənlər bazaları yaxşıdır, çünki tətbiqin vəziyyəti artıq tətbiqin çökməsi/yenidən işə salınmasından asılı deyil, lakin verilənlər bazası ilə işləmək kodu çətinləşdirir və məlumat strukturuna məhdudiyyətlər qoyur.

Mənbə: www.habr.com