“Nima uchun?” kabi savollar uchun eski maqola bor - .
Maqolalar juda ko'p, sub'ektiv sabablarga ko'ra ulardan ba'zilari menga yoqmaydi, ba'zilari esa, aksincha, o'tkazib yuborish juda achinarli. Men bu jarayonni optimallashtirish va vaqtni tejashni xohlayman.
Yuqoridagi maqola brauzerda skript yaratish yondashuvini taklif qildi, lekin menga quyidagi sabablarga ko'ra u (ilgari foydalangan bo'lsam ham) unchalik yoqmadi:
- Kompyuteringiz/telefoningizdagi turli brauzerlar uchun, agar iloji bo'lsa, uni qayta sozlashingiz kerak.
- Mualliflar tomonidan qattiq filtrlash har doim ham qulay emas.
- Maqolalarini o'tkazib yuborishni istamaydigan mualliflar bilan bog'liq muammo, hatto ular yiliga bir marta nashr etilsa ham, hal qilinmagan.
Maqola reytinglari asosida saytga o'rnatilgan filtrlash har doim ham qulay emas, chunki yuqori ixtisoslashgan maqolalar, ularning qiymatiga qaramay, juda kamtarona baho olishlari mumkin.
Dastlab, men u erda faqat qiziqarli narsalarni qoldirib, RSS tasmasi (yoki hatto bir nechta) yaratmoqchi edim. Biroq, oxir-oqibat, RSS-ni o'qish unchalik qulay bo'lmagani ma'lum bo'ldi: har qanday holatda ham, maqolaga sharh berish/ovoz berish/uni sevimlilaringizga qo'shish uchun siz brauzer orqali o'tishingiz kerak. Shuning uchun men shaxsiy xabarda menga qiziqarli maqolalar yuboradigan telegram botini yozdim. Telegramning o'zi ulardan chiroyli oldindan ko'rishlarni yaratadi, ular muallif/reyting/ko'rishlar haqidagi ma'lumotlar bilan birgalikda juda ma'lumotli ko'rinadi.
Kesim ostida ishning xususiyatlari, yozish jarayoni va texnik echimlar kabi tafsilotlar mavjud.
Bot haqida qisqacha
Repozitoriy:
Telegramdagi bot:
Foydalanuvchi teglar va mualliflar uchun qo'shimcha reyting o'rnatadi. Shundan so'ng, maqolalarga filtr qo'llaniladi - Habré-dagi maqolaning reytingi, muallifning foydalanuvchi reytingi va teg bo'yicha foydalanuvchi reytinglari uchun o'rtacha ko'rsatkich qo'shiladi. Agar miqdor foydalanuvchi tomonidan belgilangan chegaradan katta bo'lsa, maqola filtrdan o'tadi.
Bot yozishdan maqsad qiziqarli va tajriba orttirish edi. Bundan tashqari, men buni muntazam ravishda o'zimga eslatib turdim , va shuning uchun ko'p narsalar imkon qadar sodda va hatto ibtidoiy tarzda amalga oshiriladi. Biroq, bu botni yozish jarayonining uch oy davom etishiga to'sqinlik qilmadi.
Tashqarida yoz edi
Iyul tugayapti va men bot yozishga qaror qildim. Va yolg'iz emas, balki skalani o'zlashtirgan va unga nimadir yozmoqchi bo'lgan do'stim bilan. Boshlanishi istiqbolli ko'rindi - kodni jamoa kesib tashlaydi, vazifa oson tuyuldi va men bir necha hafta yoki bir oy ichida bot tayyor bo'ladi deb o'yladim.
So'nggi bir necha yil ichida men o'zim vaqti-vaqti bilan toshga kod yozgan bo'lsam ham, odatda hech kim bu kodni ko'rmaydi yoki ko'rmaydi: uy hayvonlari loyihalari, ba'zi g'oyalarni sinab ko'rish, ma'lumotlarni oldindan qayta ishlash, FPdan ba'zi tushunchalarni o'zlashtirish. Meni jamoada kod yozish qanday bo'lishi qiziqtirdi, chunki toshdagi kod juda boshqacha tarzda yozilishi mumkin.
Nima ketishi mumkin edi shunday? Biroq, keling, shoshilmaylik.
Voqea sodir bo'lgan hamma narsani topshirish tarixi yordamida kuzatish mumkin.
27 iyul kuni bir tanishim ombor yaratdi, lekin boshqa hech narsa qilmadi, shuning uchun men kod yozishni boshladim.
Iyul 30
Qisqacha: Men Habrning rss tasmasi tahlilini yozdim.
com.github.pureconfigtypesafe konfiguratsiyasini to'g'ridan-to'g'ri case sinflarida o'qish uchun (bu juda qulay bo'lib chiqdi)scala-xmlxml o'qish uchun: dastlab rss tasmasi uchun o'z dasturimni yozmoqchi bo'lganim uchun va rss tasmasi xml formatida bo'lgani uchun men ushbu kutubxonadan tahlil qilish uchun foydalandim. Aslida, RSS tahlili ham paydo bo'ldi.scalatesttestlar uchun. Hatto kichik loyihalar uchun ham testlarni yozish vaqtni tejaydi - masalan, xml tahlilini tuzatishda uni faylga yuklab olish, testlarni yozish va xatolarni tuzatish ancha osonlashadi. Keyinchalik noto'g'ri utf-8 belgilar bilan g'alati html-ni tahlil qilishda xatolik paydo bo'lganda, uni faylga qo'yish va test qo'shish qulayroq bo'lib chiqdi.- Akka aktyorlari. Ob'ektiv ravishda ular umuman kerak emas edi, lekin loyiha o'yin-kulgi uchun yozilgan, men ularni sinab ko'rmoqchi edim. Natijada, men buni yoqtirganimni aytishga tayyorman. OOP g'oyasiga boshqa tomondan qarash mumkin - xabar almashadigan aktyorlar bor. Qizig'i shundaki, siz kodni shunday yozishingiz mumkin (va kerak) shundayki, xabar kelmasligi yoki qayta ishlanmasligi mumkin (umuman olganda, hisob bitta kompyuterda ishlayotgan bo'lsa, xabarlar yo'qolmasligi kerak). Avvaliga men boshimni tirnadim va kodda aktyorlar bir-biriga obuna bo'lgan axlat bor edi, lekin oxirida men juda oddiy va oqlangan arxitekturani o'ylab topdim. Har bir aktyor ichidagi kodni bitta torli deb hisoblash mumkin; aktyor halokatga uchraganda, acca uni qayta ishga tushiradi - natijada nosozliklarga chidamli tizim paydo bo'ladi.
9 avgust
Men loyihaga qo'shdim scala-scrapper Habr-dan html sahifalarini tahlil qilish uchun (maqola reytingi, xatcho'plar soni va boshqalar kabi ma'lumotlarni olish uchun).
Va Mushuklar. Toshdagilar.
Keyin men tarqatilgan ma'lumotlar bazalari haqidagi kitobni o'qidim, menga CRDT g'oyasi yoqdi. , ), shuning uchun men Habré-dagi maqola haqida ma'lumot olish uchun kommutativ yarim guruhning turdagi sinfini joylashtirdim.
Aslida, g'oya juda oddiy - bizda monoton ravishda o'zgarib turadigan hisoblagichlar mavjud. Aktsiyalar soni asta-sekin o'sib bormoqda, shuningdek, ortiqchalar soni (shuningdek, minuslar soni). Agar menda maqola haqida ma'lumotning ikkita versiyasi bo'lsa, men ularni "bittaga birlashtira olaman" - hisoblagichning kattaroq holati ko'proq mos keladi.
Yarim guruh deganda maqola haqidagi ma'lumotlarga ega bo'lgan ikkita ob'ektni bitta ob'ektga birlashtirish mumkin degan ma'noni anglatadi. Kommutativ, siz A + B va B + A ikkalasini birlashtirishingiz mumkinligini anglatadi, natija buyurtmaga bog'liq emas va oxirida eng yangi versiya qoladi. Aytgancha, bu erda ham assotsiativlik mavjud.
Masalan, rejalashtirilganidek, tahlildan so'ng rss maqola haqida biroz zaiflashtirilgan ma'lumotni taqdim etdi - ko'rishlar soni kabi ko'rsatkichlarsiz. Keyin maxsus aktyor maqolalar haqida ma'lumot oldi va uni yangilash va eski versiya bilan birlashtirish uchun html sahifalariga yugurdi.
Umuman olganda, akkada bo'lgani kabi, bunga hojat yo'q edi, siz shunchaki maqola uchun yangilangan sanani saqlashingiz va hech qanday birlashtirmasdan yangisini olishingiz mumkin edi, lekin sarguzashtlar yo'li meni olib keldi.
12 avgust
Men o'zimni erkinroq his qila boshladim va shunchaki zavqlanish uchun har bir suhbatni alohida aktyor qildim. Nazariy jihatdan, aktyorning o'zi taxminan 300 baytni tashkil qiladi va ular millionlab yaratilishi mumkin, shuning uchun bu mutlaqo normal yondashuv. Menimcha, yechim juda qiziq bo'lib chiqdi:
Bir aktyor Akkada telegram serveri va xabarlar tizimi o'rtasida ko'prik bo'lgan. U shunchaki xabarlarni oldi va ularni kerakli chat aktyoriga yubordi. Chat aktyori javoban biror narsa yuborishi mumkin edi - va u telegrammaga qaytariladi. Juda qulay bo'lgan narsa shundaki, bu aktyor imkon qadar sodda bo'lib chiqdi va faqat xabarlarga javob berish mantiqini o'z ichiga oladi. Aytgancha, har bir chatga yangi maqolalar haqida ma'lumot keldi, lekin yana men bu borada hech qanday muammo ko'rmayapman.
Umuman olganda, bot allaqachon ishlayotgan, xabarlarga javob berayotgan, foydalanuvchiga yuborilgan maqolalar ro'yxatini saqlagan va men allaqachon bot deyarli tayyor deb o'ylardim. Men asta-sekin muallif nomlari va teglarini normallashtirish kabi kichik xususiyatlarni qo'shdim ("sd f" ni "s_d_f" bilan almashtirish).
Faqat bitta narsa qolgan edi kichik lekin — davlat hech qayerda saqlanmadi.
Hammasi noto'g'ri ketdi
Botni asosan yolg'iz yozganimni sezgandirsiz. Shunday qilib, ikkinchi ishtirokchi ishlab chiqishda ishtirok etdi va kodda quyidagi o'zgarishlar paydo bo'ldi:
- MongoDB holatini saqlash uchun paydo bo'ldi. Shu bilan birga, loyihadagi jurnallar buzildi, chunki negadir Monga ularni spam qila boshladi va ba'zi odamlar ularni global miqyosda o'chirib qo'yishdi.
- Telegram’dagi ko‘prik aktyori tanib bo‘lmas darajada o‘zgardi va o‘zi xabarlarni tahlil qila boshladi.
- Suhbatlar uchun aktyorlar shafqatsizlarcha kesib tashlandi va ularning o'rniga bir vaqtning o'zida barcha chatlar haqidagi barcha ma'lumotlarni yashiradigan aktyor almashtirildi. Har bir aksirish uchun bu aktyor muammoga duch keldi. Xo'sh, ha, maqola haqidagi ma'lumotni yangilashda, uni barcha chat ishtirokchilariga yuborish qiyin (biz Google kabimiz, millionlab foydalanuvchilar har biri uchun chatda millionlab maqolalarni kutishadi), lekin har safar chat yangilanganda, Mongaga kirish odatiy hol. Keyinchalik tushunganimdek, chatlarning ish mantig'i ham butunlay kesilgan va uning o'rnida ishlamayotgan narsa paydo bo'lgan.
- Tur sinflaridan hech qanday iz qolmagan.
- Aktyorlarda bir-biriga obuna bo'lgan ba'zi nosog'lom mantiq paydo bo'lib, poyga holatiga olib keldi.
- Tur maydonlari bilan ma'lumotlar tuzilmalari
Option[Int]-1 kabi sehrli standart qiymatlar bilan Int ga aylandi. Keyinchalik tushundimki, mongoDB json-ni saqlaydi va u erda saqlashda hech qanday yomon narsa yo'qOptionyaxshi, yoki hech bo'lmaganda -1 ni Yo'q deb tahlil qiling, lekin o'sha paytda men buni bilmasdim va "shunday bo'lishi kerak" deb o'z so'zimni qabul qildim. Men bu kodni yozmadim va hozircha uni o'zgartirishni bezovta qilmadim. - Mening umumiy IP manzilim o'zgarib turishini bilib oldim va har safar uni Mongo oq ro'yxatiga qo'shishim kerak edi. Men botni mahalliy ishga tushirdim, Monga kompaniya sifatida Monga serverlarida bir joyda edi.
- To'satdan telegrammalar uchun teglarni normallashtirish va xabarlarni formatlash yo'qoldi. (Hmm, nega bunday bo'lardi?)
- Menga botning holati tashqi ma'lumotlar bazasida saqlanishi yoqdi va qayta ishga tushirilganda u hech narsa bo'lmagandek ishlashda davom etadi. Biroq, bu yagona ortiqcha narsa edi.
Ikkinchi odam shoshilmadi va bu o'zgarishlarning barchasi sentyabr oyining boshida bitta katta uyumda paydo bo'ldi. Men sodir bo'lgan halokat ko'lamini darhol qadrlamadim va ma'lumotlar bazasi ishini tushuna boshladim, chunki... Men ular bilan hech qachon muomala qilmaganman. Faqat keyinroq men qancha ish kodi kesilganini va uning o'rniga qancha xatolar qo'shilganini angladim.
Sentyabr
Avvaliga men Monga o'zlashtirib, uni yaxshi bajarish foydali bo'ladi deb o'yladim. Keyin men asta-sekin ma'lumotlar bazasi bilan aloqani tashkil qilish ham ko'p poygalar qilish va shunchaki xato qilish mumkin bo'lgan san'at ekanligini tushuna boshladim. Misol uchun, agar foydalanuvchi kabi ikkita xabar olsa /subscribe - va har biriga javoban biz jadvalga yozuv yaratamiz, chunki bu xabarlarni qayta ishlash vaqtida foydalanuvchi obuna bo'lmagan. Monga bilan hozirgi shaklda muloqot eng yaxshi tarzda yozilmaganiga shubha qilaman. Misol uchun, foydalanuvchining sozlamalari u ro'yxatdan o'tgan paytda yaratilgan. Agar u obuna bo'lishidan oldin ularni o'zgartirishga harakat qilsa ... bot hech narsaga javob bermadi, chunki aktyordagi kod sozlamalar uchun ma'lumotlar bazasiga kirib, uni topa olmadi va qulab tushdi. Nega kerak bo'lganda sozlamalarni yaratmaslik kerakligi so'ralganda, men foydalanuvchi obuna bo'lmagan bo'lsa, ularni o'zgartirishning hojati yo'qligini bilib oldim... Xabarlarni filtrlash tizimi qandaydir tarzda aniq bo'lmagan tarzda yaratilgan va hatto kodni diqqat bilan ko'rib chiqqandan keyin ham men buni qila oldim. dastlab shunday mo'ljallanganmi yoki xatolik bormi, tushunmayapman.
Chatga yuborilgan maqolalar ro'yxati yo'q edi, aksincha, ularni o'zim yozishim taklif qilindi. Bu meni hayratda qoldirdi - umuman olganda, men har xil narsalarni loyihaga tortishga qarshi emas edim, lekin bu narsalarni olib kelgan va ularni burab qo'ygan kishi uchun mantiqiy bo'lar edi. Ammo yo'q, ikkinchi ishtirokchi hamma narsadan voz kechganday tuyuldi, lekin chat ichidagi ro'yxat go'yoki yomon yechim ekanligini va "x foydalanuvchisiga y maqolasi yuborildi" kabi voqealar bilan ishora qilish kerakligini aytdi. Keyin, agar foydalanuvchi yangi maqolalar yuborishni so'rasa, ma'lumotlar bazasiga so'rov yuborish kerak edi, u voqealardan foydalanuvchi bilan bog'liq voqealarni tanlaydi, shuningdek, yangi maqolalar ro'yxatini oladi, ularni filtrlaydi va foydalanuvchiga yuboradi. va bu haqdagi voqealarni ma'lumotlar bazasiga qaytaring.
Ikkinchi ishtirokchini mavhumliklar tomon olib ketishdi, bunda bot nafaqat Xabrdan maqolalarni oladi va nafaqat telegrammaga yuboriladi.
Men qandaydir tarzda voqealarni sentyabr oyining ikkinchi yarmi uchun alohida belgi shaklida amalga oshirdim. Bu optimal emas, lekin hech bo'lmaganda bot ishlay boshladi va menga yana maqolalar yuborishni boshladi va men asta-sekin kodda nima sodir bo'layotganini tushundim.
Endi siz boshiga qaytishingiz mumkin va esda tutingki, ombor dastlab men tomonidan yaratilmagan. Bu nima bo'lishi mumkin edi? Mening talabim rad etildi. Ma'lum bo'lishicha, menda noaniq kod bor edi, men jamoada qanday ishlashni bilmasdim va joriy amalga oshirish egri chizig'idagi xatolarni tuzatishim kerak edi va uni foydali holatga keltirmaslik kerak edi.
Men xafa bo'ldim va topshiriq tarixiga va yozilgan kod miqdoriga qaradim. Men dastlab yaxshi yozilgan, keyin esa sindirilgan lahzalarga qaradim...
Qani
Maqolani esladim .
Amalga oshirilmasdan turib g‘oya hech kimga kerak emas deb o‘yladim. Men oddiy java dasturi sifatida bitta kompyuterda bitta nusxada ishlaydigan ishlaydigan botga ega bo'lishni xohlayman deb o'yladim. Bilaman, mening botim bir necha oy davomida qayta ishga tushirilmasdan ishlaydi, chunki men o'tmishda bunday botlarni yozganman. Agar u to'satdan tushib qolsa va foydalanuvchiga boshqa maqola yubormasa, osmon erga tushmaydi va hech qanday halokatli narsa bo'lmaydi.
Nega menga Docker, mongoDB va boshqa "jiddiy" dasturiy ta'minot yuk kulti kerak, agar kod oddiygina ishlamasa yoki egri ishlasa?
Men loyihani vilka qildim va hamma narsani xohlaganimdek qildim.
Taxminan bir vaqtning o'zida men ish joyini o'zgartirdim va bo'sh vaqtim juda kam bo'lib qoldi. Ertalab men poezdda uyg'onib ketdim, kechqurun men kech qaytdim va endi hech narsa qilishni xohlamadim. Men bir muncha vaqt hech narsa qilmadim, keyin botni tugatish istagi meni bosib oldi va ertalab ishga ketayotganimda kodni asta-sekin qayta yozishni boshladim. Bu unumli bo'ldi deb aytmayman: tizzangizda tizza kompyuter bilan tebranayotgan poezdda o'tirish va telefoningizdan stek to'lib ketishiga qarash unchalik qulay emas. Biroq, kod yozish uchun sarflangan vaqt umuman sezilmay o'tdi va loyiha asta-sekin ishlaydigan holatga o'ta boshladi.
Xayolimda qayerdadir mongoDB dan foydalanmoqchi bo‘lgan shubhali qurt bor edi, lekin men “ishonchli” holatni saqlashning afzalliklaridan tashqari, sezilarli kamchiliklar ham bor deb o‘yladim:
- Ma'lumotlar bazasi muvaffaqiyatsizlikning yana bir nuqtasiga aylanadi.
- Kod murakkablashib bormoqda va uni yozish menga ko'proq vaqt oladi.
- Kod sekin va samarasiz bo'lib qoladi; xotiradagi ob'ektni o'zgartirish o'rniga, o'zgarishlar ma'lumotlar bazasiga yuboriladi va agar kerak bo'lsa, orqaga tortiladi.
- Voqealarni alohida jadvalda saqlash turi bo'yicha cheklovlar mavjud bo'lib, ular ma'lumotlar bazasining o'ziga xos xususiyatlari bilan bog'liq.
- Monga-ning sinov versiyasida ba'zi cheklovlar mavjud va agar siz ularga duch kelsangiz, Monga-ni biror narsada ishga tushirishingiz va sozlashingiz kerak bo'ladi.
Men mongani kesib tashladim, endi botning holati shunchaki dastur xotirasida saqlanadi va vaqti-vaqti bilan json ko'rinishidagi faylga saqlanadi. Ehtimol, sharhlarda ular men noto'g'ri ekanligimni, ma'lumotlar bazasidan foydalanish kerakligini va hokazolarni yozishlari mumkin. Lekin bu mening loyiham, faylga yondashish imkon qadar sodda va u shaffof tarzda ishlaydi.
-1 kabi sehrli qiymatlarni chiqarib tashladi va normal qiymatlarni qaytardi Option, chat ma'lumotlari bilan ob'ektga yuborilgan maqolalar bilan xash-jadvalning qo'shilgan xotirasi. Hamma narsani saqlamaslik uchun besh kundan eski maqolalar haqidagi ma'lumotlarni o'chirish qo'shildi. Men jurnalni ish holatiga keltirdim - jurnallar faylga ham, konsolga ham tegishli miqdorda yoziladi. Holatni saqlash yoki foydalanuvchilar va maqolalar soni kabi statistikani olish kabi bir nechta administrator buyruqlari qo'shildi.
Bir qator kichik narsalar tuzatildi: masalan, maqolalar uchun foydalanuvchi filtridan o'tish vaqtidagi ko'rishlar, yoqtirishlar, yoqtirmasliklar va sharhlar soni ko'rsatilgan. Umuman olganda, qancha kichik narsalarni tuzatish kerakligi ajablanarli. Men ro'yxatni yuritdim, u erdagi barcha "qoidabuzarliklar" ni qayd etdim va imkon qadar ularni tuzatdim.
Masalan, men barcha sozlamalarni to'g'ridan-to'g'ri bitta xabarda o'rnatish imkoniyatini qo'shdim:
/subscribe
/rating +20
/author a -30
/author s -20
/author p +9000
/tag scala 20
/tag akka 50Va boshqa jamoa /settings ularni aynan shu shaklda ko'rsatadi, siz undan matnni olishingiz va barcha sozlamalarni do'stingizga yuborishingiz mumkin.
Bu kichik narsa kabi ko'rinadi, lekin shunga o'xshash o'nlab nuanslar mavjud.
Oddiy chiziqli model ko'rinishida maqolani filtrlash amalga oshirildi - foydalanuvchi mualliflar va teglar uchun qo'shimcha reytingni, shuningdek chegara qiymatini o'rnatishi mumkin. Agar muallifning reytingi, teglar uchun o'rtacha reyting va maqolaning haqiqiy reytingi chegara qiymatidan katta bo'lsa, maqola foydalanuvchiga ko'rsatiladi. Siz /new buyrug'i bilan botdan maqolalarni so'rashingiz yoki botga obuna bo'lishingiz mumkin va u kunning istalgan vaqtida maqolalarni shaxsiy xabar orqali yuboradi.
Umuman olganda, men har bir maqoladan ko'proq xususiyatlarni (markazlar, sharhlar soni, xatcho'plar, reyting o'zgarishlar dinamikasi, maqoladagi matn, rasmlar va kodlar miqdori, kalit so'zlar) ajratib olish va foydalanuvchiga OK/ har bir maqola ostida ovoz bermang va har bir foydalanuvchi uchun modelni o'rgating, lekin men juda dangasa edim.
Bundan tashqari, ishning mantig'i unchalik aniq bo'lmaydi. Endi men PatentZero uchun +9000 reytingini qo'lda o'rnatishim mumkin va chegara reytingi +20 bo'lsa, men uning barcha maqolalarini olishimga kafolat beraman (agar, albatta, ba'zi teglar uchun -100500 belgilamasam).
Yakuniy arxitektura juda oddiy bo'lib chiqdi:
- Barcha suhbatlar va maqolalar holatini saqlaydigan aktyor. U o'z holatini diskdagi fayldan yuklaydi va vaqti-vaqti bilan uni har safar yangi faylga saqlaydi.
- Vaqti-vaqti bilan RSS tasmasiga tashrif buyuradigan, yangi maqolalar bilan tanishadigan, havolalarni ko'rib chiqadigan, tahlil qiladigan va ushbu maqolalarni birinchi aktyorga yuboradigan aktyor. Bundan tashqari, ba'zan birinchi aktyordan maqolalar ro'yxatini so'raydi, uch kundan ortiq bo'lmagan, lekin uzoq vaqt davomida yangilanmaganlarini tanlaydi va ularni yangilaydi.
- Telegram orqali muloqot qiladigan aktyor. Men hali ham bu yerga to'liq tahlil qilish xabarini olib keldim. Do'stona tarzda, men uni ikkiga bo'lishni xohlayman - biri kiruvchi xabarlarni tahlil qiladi, ikkinchisi esa yuborilmagan xabarlarni qayta yuborish kabi transport muammolari bilan shug'ullanadi. Endi qayta yuborish yo'q va xatolik tufayli kelmagan xabar shunchaki yo'qoladi (agar u jurnallarda qayd etilmagan bo'lsa), lekin hozirgacha bu hech qanday muammo tug'dirmadi. Ehtimol, agar bir guruh odamlar botga obuna bo'lsalar va men xabarlarni yuborish chegarasiga erishsam, muammolar paydo bo'ladi).
Menga yoqqan tomoni shundaki, akka tufayli 2 va 3-aktyorlarning qulashi umuman botning ishlashiga ta'sir qilmaydi. Ehtimol, ba'zi maqolalar o'z vaqtida yangilanmaydi yoki ba'zi xabarlar telegramga etib bormaydi, lekin akkaunt aktyorni qayta ishga tushiradi va hamma narsa ishlashda davom etadi. Maqola foydalanuvchiga ko'rsatiladigan ma'lumotni telegram aktyori xabarni muvaffaqiyatli yetkazganligi haqida javob berganida saqlayman. Menga tahdid soladigan eng yomon narsa - bu xabarni bir necha marta yuborish (agar u etkazib berilsa, lekin tasdiqlash qandaydir tarzda yo'qolgan bo'lsa). Aslida, agar birinchi aktyor davlatni o'zida saqlamasa, balki ba'zi ma'lumotlar bazasi bilan bog'langan bo'lsa, u ham sezilmaydigan tarzda tushib, hayotga qaytishi mumkin edi. Men aktyorlarning holatini tiklash uchun akka qat'iyatni ham sinab ko'rishim mumkin edi, ammo hozirgi dastur menga soddaligi bilan mos keladi. Bu mening kodim tez-tez ishdan chiqqani emas - aksincha, men buni imkonsiz qilish uchun juda ko'p kuch sarfladim. Ammo g'alati narsa sodir bo'ladi va dasturni alohida qismlarga ajratish qobiliyati men uchun juda qulay va amaliy bo'lib tuyuldi.
Men doira-ci qo'shdim, shunda kod buzilgan bo'lsa, bu haqda darhol bilib olasiz. Hech bo'lmaganda, bu kod kompilyatsiya qilishni to'xtatganligini anglatadi. Dastlab men travisni qo'shmoqchi edim, lekin u mening loyihalarimni vilkalarsiz ko'rsatdi. Umuman olganda, bu ikkala narsa ochiq omborlarda erkin ishlatilishi mumkin.
natijalar
Allaqachon noyabr. Bot yozilgan, men uni oxirgi ikki haftadan beri ishlataman va menga yoqdi. Agar sizda takomillashtirish bo'yicha fikrlaringiz bo'lsa, yozing. Men uni monetizatsiya qilishning ma'nosini ko'rmayapman - shunchaki ishlasin va qiziqarli maqolalar yuborsin.
Bot havolasi:
Github:
Kichik xulosalar:
- Hatto kichik loyiha ham ko'p vaqt talab qilishi mumkin.
- Siz Google emassiz. To'pdan chumchuq otishdan foyda yo'q. Oddiy yechim ham ish berishi mumkin.
- Uy hayvonlari loyihalari yangi texnologiyalar bilan tajriba o'tkazish uchun juda yaxshi.
- Telegram botlari juda oddiy yozilgan. Agar "jamoada ishlash" va texnologiya bilan tajribalar bo'lmaganida, bot bir yoki ikki hafta ichida yozilgan bo'lardi.
- Aktyor modeli - bu ko'p tarmoqli va xatoga chidamli kod bilan yaxshi ketadigan qiziqarli narsa.
- O'ylaymanki, men ochiq kodli hamjamiyat nega vilkalarni yaxshi ko'rishini tushundim.
- Ma'lumotlar bazalari yaxshi, chunki dastur holati endi dasturning ishdan chiqishi/qayta ishga tushirilishiga bog'liq emas, lekin ma'lumotlar bazasi bilan ishlash kodni murakkablashtiradi va ma'lumotlar tuzilishiga cheklovlar qo'yadi.
Manba: www.habr.com