Habr мақалаларының жеке таңдауына арналған Telegram боты

«Неге?» сияқты сұрақтарға ескі мақала бар - Natural Geektimes - кеңістікті тазарту.

Мақалалар өте көп, субъективті себептермен олардың кейбіреулері маған ұнамайды, ал кейбіреулері, керісінше, өткізіп жіберу өте өкінішті. Мен бұл процесті оңтайландыруды және уақытты үнемдеуді қалаймын.

Жоғарыдағы мақалада браузерде сценарий жасау тәсілі ұсынылды, бірақ мен оны келесі себептерге байланысты (бұрын қолдансам да) ұнатпадым:

• Компьютердегі/телефондағы әртүрлі браузерлер үшін, мүмкін болса, оны қайта конфигурациялау қажет.
• Авторлар тарапынан қатаң сүзгілеу әрқашан қолайлы бола бермейді.
• Жылына бір рет жарияланса да мақалаларын жібергіңіз келмейтін авторлардың мәселесі шешілген жоқ.

Мақала рейтингтері негізінде сайтқа енгізілген сүзгілеу әрқашан қолайлы бола бермейді, өйткені жоғары мамандандырылған мақалалар, олардың құндылығына қарамастан, өте қарапайым рейтингті ала алады.

Бастапқыда мен тек қызықты нәрселерді қалдырып, RSS арнасын (немесе бірнешеуін) жасағым келді. Бірақ соңында RSS оқу өте ыңғайлы емес болып шықты: кез келген жағдайда мақалаға түсініктеме беру/дауыс беру/оны таңдаулыларға қосу үшін браузер арқылы өту керек. Сондықтан мен жеке хабарламада маған қызықты мақалалар жіберетін телеграм бот жаздым. Telegram-дың өзі олардан әдемі алдын ала қараулар жасайды, олар автор/рейтинг/көрулер туралы ақпаратпен үйлескенде өте мазмұнды көрінеді.

Қиманың астында жұмыстың ерекшеліктері, жазу барысы және техникалық шешімдері сияқты мәліметтер берілген.

Бот туралы қысқаша

Репозиторий: https://github.com/Kright/habrahabr_reader

Телеграмдағы бот: https://t.me/HabraFilterBot

Пайдаланушы тегтер мен авторлар үшін қосымша рейтинг орнатады. Осыдан кейін мақалаларға сүзгі қолданылады - мақаланың Хабредегі рейтингі, автордың пайдаланушы рейтингі және тег бойынша пайдаланушы рейтингтерінің орташа мәні қосылады. Егер сома пайдаланушы көрсеткен шекті мәннен үлкен болса, мақала сүзгіден өтеді.

Бот жазудың жанама мақсаты көңіл көтеру және тәжірибе алу болды. Сонымен қатар, мен мұны үнемі еске түсірдім Мен Google емеспін, сондықтан көптеген нәрселер мүмкіндігінше қарапайым және тіпті қарапайым түрде жасалады. Дегенмен, бұл ботты жазу процесінің үш айға созылуына кедергі болмады.

Сыртта жаз болатын

Шілде аяқталды, мен бот жазуды шештім. Жалғыз емес, скаланы меңгеріп, оған бірдеңе жазғысы келген досыммен. Басталуы перспективалы болып көрінді - кодты команда кесіп тастайды, тапсырма оңай болып көрінді және мен бір-екі аптада немесе бір айдан кейін бот дайын болады деп ойладым.

Мен өзім соңғы бірнеше жылда оқтын-оқтын тасқа код жазып жүргеніме қарамастан, әдетте бұл кодты ешкім көрмейді немесе қарамайды: үй жануарлары жобалары, кейбір идеяларды сынау, деректерді алдын-ала өңдеу, FP-ден кейбір тұжырымдамаларды меңгеру. Мені командадағы код жазудың қандай болатыны қызықтырды, өйткені роктағы кодты әртүрлі тәсілдермен жазуға болады.

Не кетуі мүмкін еді солай? Дегенмен, асықпай-ақ қояйық.
Орындалған барлық оқиғаларды орындау тарихы арқылы бақылауға болады.

Бір танысым 27 шілдеде репозиторий жасады, бірақ басқа ештеңе істемеді, сондықтан код жаза бастадым.

шілде 30

Қысқаша: мен Хабрдың rss арнасының талдауын жаздым.

• com.github.pureconfig typesafe конфигурацияларын тікелей кейс сыныптарына оқу үшін (бұл өте ыңғайлы болды)
• scala-xml xml оқу үшін: бастапқыда rss арнасы үшін өзімнің енгізуімді жазғым келгендіктен және rss арнасы xml пішімінде болғандықтан, мен бұл кітапхананы талдау үшін пайдаландым. Іс жүзінде RSS талдауы да пайда болды.
• scalatest сынақтар үшін. Тіпті кішкентай жобалар үшін сынақтарды жазу уақытты үнемдейді - мысалы, xml талдауын жөндеу кезінде оны файлға жүктеп алу, сынақтарды жазу және қателерді түзету оңайырақ. Кейінірек жарамсыз utf-8 таңбалары бар кейбір оғаш html талдауында қате пайда болғанда, оны файлға салып, сынақты қосу ыңғайлырақ болды.
• Аккадан шыққан актерлер. Объективті түрде олар мүлдем қажет емес еді, бірақ жоба көңіл көтеру үшін жазылған, мен оларды сынап көргім келді. Нәтижесінде, маған ұнады деп айтуға дайынмын. OOP идеясын екінші жағынан қарауға болады - хабарламалармен алмасатын актерлер бар. Ең қызығы, сіз кодты хабарлама келмейтін немесе өңделмейтін етіп жаза аласыз (және керек) (жалпы алғанда, тіркелгі бір компьютерде жұмыс істеп тұрғанда, хабарлар жоғалып кетпеуі керек). Бастапқыда мен басымды тырнап алдым және кодта актерлер бір-біріне жазылған қоқыс болды, бірақ соңында мен өте қарапайым және талғампаз архитектура ойлап таптым. Әрбір актердің ішіндегі кодты бір ағынды деп санауға болады; актер бұзылған кезде, acca оны қайта іске қосады - нәтиже ақауларға төзімді жүйе.

9 тамыз

Мен жобаға қостым scala-scrapper Habr сайтынан html беттерін талдау үшін (мақала рейтингі, бетбелгілер саны және т.б. сияқты ақпаратты шығару үшін).

Және мысықтар. Жартастағылар.

Содан кейін мен таратылған дерекқорлар туралы кітапты оқыдым, маған CRDT идеясы ұнады (Қақтығыссыз қайталанатын деректер түрі, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, хабр), сондықтан мен Хабредегі мақала туралы ақпарат алу үшін коммутативті жартылай топтың типтік класын орналастырдым.

Шын мәнінде, идея өте қарапайым - бізде монотонды түрде өзгеретін есептегіштер бар. Акциялар саны бірте-бірте өсуде, сонымен қатар плюстердің саны (сондай-ақ минустардың саны). Егер менде мақала туралы ақпараттың екі нұсқасы болса, мен оларды «бірге біріктіре аламын» - үлкенірек есептегіштің күйі маңыздырақ болып саналады.

Жартылай топ мақала туралы ақпараты бар екі нысанды бір нысанға біріктіруге болатындығын білдіреді. Коммутативтілік дегеніміз A + B және B + A екеуін біріктіруге болады, нәтиже тәртіпке байланысты емес және соңында ең жаңа нұсқа қалады. Айтпақшы, бұл жерде де ассоциация бар.

Мысалы, жоспарланғандай, талдаудан кейін rss мақала туралы аздап әлсіреген ақпаратты берді - көру саны сияқты көрсеткіштерсіз. Арнайы актер мақалалар туралы ақпаратты алып, оны жаңарту және оны ескі нұсқамен біріктіру үшін html беттеріне жүгірді.

Жалпы айтқанда, аккадағыдай, мұның қажеті жоқ еді, сіз жай ғана мақаланың жаңартылған күнін сақтай аласыз және ешқандай біріктірусіз жаңасын ала аласыз, бірақ мені шытырман оқиғалы жол алып келді.

12 тамыз

Мен өзімді еркін сезіне бастадым және көңіл көтеру үшін әр чатты бөлек актер еттім. Теориялық тұрғыдан алғанда, актердің өзі шамамен 300 байтты құрайды және олар миллиондап жасалуы мүмкін, сондықтан бұл мүлдем қалыпты көзқарас. Менің ойымша, шешім өте қызықты болды:

Бір актер Аккадағы телеграм сервері мен хабарлама жүйесі арасындағы көпір болды. Ол жай ғана хабарламаларды алып, оларды қалаған чат актерына жіберді. Чат актері жауап ретінде бірдеңе жібере алады - және ол телеграммаға қайтарылады. Өте ыңғайлы болғаны, бұл актер мүмкіндігінше қарапайым болып шықты және хабарламаларға жауап беру логикасын ғана қамтиды. Айтпақшы, әр чатта жаңа мақалалар туралы ақпарат келді, бірақ мен бұл мәселеде тағы да проблемаларды көрмеймін.

Жалпы, бот қазірдің өзінде жұмыс істеп, хабарламаларға жауап беріп, пайдаланушыға жіберілген мақалалар тізімін сақтайтын болды, мен бот дерлік дайын деп ойладым. Мен автор аттары мен тегтерін қалыпқа келтіру («s.d f» сөзін «s_d_f» дегенге ауыстыру) сияқты кішкене мүмкіндіктерді баяу қостым.

Бір ғана нәрсе қалды кішкентай бірақ — мемлекет еш жерде сақталмады.

Бәрі дұрыс болмады

Мен ботты негізінен жалғыз жазғанымды байқаған боларсыз. Осылайша, екінші қатысушы әзірлеуге қатысты және кодта келесі өзгерістер пайда болды:

• MongoDB күйді сақтау үшін пайда болды. Сонымен қатар, жобадағы журналдар бұзылды, өйткені қандай да бір себептермен Монга оларды спаммен жібере бастады, ал кейбір адамдар оларды ғаламдық түрде өшірді.
• Telegram-дағы көпір актері адам танымастай өзгерді және хабарламаларды өзі талдауға кірісті.
• Чаттарға арналған актерлер аяусыз кесілді, оның орнына олардың орнына барлық чаттар туралы барлық ақпаратты бірден жасыратын актер келді. Әрбір түшкірген сайын бұл актер қиындыққа тап болды. Иә, мақала туралы ақпаратты жаңарту кезінде оны барлық чат қатысушыларына жіберу қиын (біз Google сияқтымыз, миллиондаған пайдаланушылар әрқайсысы үшін чатта миллионнан мақала күтеді), бірақ чат жаңартылған сайын, Монгаға кіру қалыпты жағдай. Кейінірек түсінгенімдей, чаттардың жұмыс логикасы да толығымен жойылып, оның орнына жұмыс істемейтін нәрсе пайда болды.
• Тип класстарынан із қалмайды.
• Актерлердің бір-біріне жазылуымен кейбір дұрыс емес логика пайда болды, бұл жарыс жағдайына әкелді.
• Тип өрістері бар деректер құрылымдары Option[Int] -1 сияқты сиқырлы әдепкі мәндері бар Int-ге айналды. Кейінірек мен mongoDB json сақтайтынын және оны сақтаудың ешбір қатесі жоқ екенін түсіндім Option жақсы, немесе кем дегенде -1-ді Жоқ деп талдаңыз, бірақ ол кезде мен мұны білмедім және «осылай болуы керек» деп өз сөзімді қабылдадым. Мен бұл кодты жазған жоқпын және әзірге оны өзгертуге алаңдамадым.
• Мен жалпыға ортақ IP мекенжайымның өзгеретінін білдім және әр жолы оны Mongo ақ тізіміне қосуға тура келді. Мен ботты жергілікті түрде іске қостым, Монга компания ретінде Monga серверлерінде болды.
• Кенеттен телеграммалар үшін тегтерді қалыпқа келтіру және хабарды пішімдеу жоғалып кетті. (Хмм, бұл неге болады?)
• Маған бот күйінің сыртқы дерекқорда сақталатыны ұнады, қайта іске қосылғанда ол ештеңе болмағандай жұмысын жалғастырады. Дегенмен, бұл жалғыз плюс болды.

Екінші адам ерекше асықпады және бұл өзгерістердің бәрі қыркүйектің басында бір үлкен үйіндіде пайда болды. Мен нәтижесінде жойылудың ауқымын бірден бағаламадым және деректер қорының жұмысын түсіне бастадым, өйткені... Мен олармен бұрын ешқашан айналысқан емеспін. Тек кейінірек мен қанша жұмыс коды қысқартылғанын және оның орнына қанша қате қосылғанын түсіндім.

Қыркүйек

Алғашында Монганы меңгеріп, оны жақсы орындау пайдалы болар деп ойладым. Содан кейін мен базамен байланысты ұйымдастыру да көп жарыстар жасап, қателесуге болатын өнер екенін ақырын түсіне бастадым. Мысалы, егер пайдаланушы сияқты екі хабарлама алса /subscribe - және әрқайсысына жауап ретінде кестеде жазба жасаймыз, өйткені бұл хабарламаларды өңдеу кезінде пайдаланушы жазылмайды. Мен Монгамен қазіргі күйінде сөйлесу жақсы жазылмаған деген күдік бар. Мысалы, пайдаланушының параметрлері ол тіркелген сәтте жасалған. Егер ол жазылу фактісіне дейін оларды өзгертуге әрекеттенсе... бот ештеңе жауап бермеді, себебі актердегі код параметрлерге арналған дерекқорға кіріп, оны таппады және бұзылды. Неліктен қажет болған жағдайда параметрлерді жасамасқа деп сұрағанда, мен пайдаланушы жазылмаған болса, оларды өзгертудің қажеті жоқ екенін білдім... Хабарламаларды сүзу жүйесі қандай да бір түрде анық емес жасалды, тіпті кодты мұқият қарап шыққаннан кейін де мүмкін болды. ол бастапқыда осылай ойластырылды ма, әлде қате бар ма, түсінбеймін.

Чатқа жіберілген мақалалар тізімі болмады, оның орнына оларды өзім жазуды ұсындым. Бұл мені таң қалдырды - жалпы, мен жобаға әртүрлі нәрселерді тартуға қарсы емес едім, бірақ бұл заттарды әкеліп, бұрап жіберген адамға қисынды болар еді. Бірақ жоқ, екінші қатысушы бәрінен бас тартқандай болды, бірақ чат ішіндегі тізім мыс жаман шешім екенін айтты және «x пайдаланушысына y мақаласы жіберілді» сияқты оқиғалармен белгі қою керек екенін айтты. Содан кейін, егер пайдаланушы жаңа мақалаларды жіберуді сұраса, деректер базасына сұрау жіберу қажет болды, ол оқиғалардан пайдаланушыға қатысты оқиғаларды таңдайды, сонымен қатар жаңа мақалалар тізімін алады, оларды сүзеді, пайдаланушыға жібереді. және бұл туралы оқиғаларды дерекқорға қайта тастаңыз.

Екінші қатысушыны абстракцияға апарды, бұл кезде бот тек Хабрдан мақалалар алып қана қоймайды және тек телеграммаға жіберілмейді.

Қыркүйектің екінші жартысы үшін іс-шараларды бөлек белгі түрінде жүзеге асырдым. Бұл оңтайлы емес, бірақ кем дегенде бот жұмыс істей бастады және маған қайтадан мақалалар жібере бастады, мен кодта не болып жатқанын баяу түсіндім.

Енді сіз басына орала аласыз және репозиторийді бастапқыда мен жасамағанын есте сақтаңыз. Бұлай не болуы мүмкін еді? Менің сұрауым қабылданбады. Менде қызыл мойынсұнғыш коды бар екен, мен командада қалай жұмыс істеу керектігін білмеймін және ағымдағы іске асыру қисығындағы қателерді түзетіп, оны жарамды күйге келтірмеу керек болды.

Мен ренжідім және жазылу тарихына және жазылған кодтың мөлшеріне қарадым. Басында жақсы жазылған, кейін үзілген сәттерге қарадым...

Қиындық

Мақаланы есіме түсірдім Сіз Google емессіз.

Іске асырусыз идея ешкімге керек емес деп ойладым. Мен қарапайым java бағдарламасы ретінде бір компьютерде бір көшірмеде жұмыс істейтін жұмыс істейтін ботқа ие болғым келеді деп ойладым. Менің ботым айлар бойы қайта іске қосылмай жұмыс істейтінін білемін, өйткені мен мұндай боттарды бұрын жазғанмын. Егер ол кенеттен құлап, пайдаланушыға басқа мақаланы жібермесе, аспан жерге құлап кетпейді және апатты ештеңе болмайды.

Неліктен маған Docker, mongoDB және басқа «байыпты» бағдарламалық жасақтама жүк табыну керек, егер код жай жұмыс істемесе немесе қисық жұмыс істесе?

Мен жобаны айырдым және бәрін өзім қалағандай жасадым.

Шамамен сол уақытта мен жұмысты ауыстырдым және бос уақыт өте тапшы болды. Таңертең мен пойызда тұрдым, кешке кеш қайтып келдім, енді ештеңе істегім келмеді. Мен біраз уақыт ештеңе істемедім, содан кейін ботты аяқтауға деген құштарлық басым болды, мен таңертең жұмысқа бара жатқанда кодты баяу қайта жаза бастадым. Мен бұл нәтижелі болды деп айтпаймын: тізеңізде ноутбукпен шайқалған пойызда отыру және телефоныңыздан стектің толып кетуіне қарау өте ыңғайлы емес. Дегенмен, кодты жазуға жұмсалған уақыт мүлдем байқалмай өтіп, жоба жұмыс күйіне баяу жылжи бастады.

Менің ойымның бір жерінде mongoDB пайдаланғысы келетін күмән құрты болды, бірақ мен «сенімді» күйді сақтаудың артықшылықтарынан басқа, елеулі кемшіліктер бар деп ойладым:

• Деректер базасы тағы бір сәтсіздікке айналады.
• Код күрделене түсуде және оны жазу маған ұзағырақ болады.
• Код баяу және тиімсіз болады; жадтағы нысанды өзгертудің орнына өзгертулер дерекқорға жіберіледі және қажет болған жағдайда кері қайтарылады.
• Оқиғаларды жеке кестеде сақтау түріне шектеулер бар, олар деректер қорының ерекшеліктерімен байланысты.
• Monga-ның сынақ нұсқасында кейбір шектеулер бар, егер сіз оларға тап болсаңыз, Monga-ны бір нәрседе іске қосып, конфигурациялауға тура келеді.

Мен монганы кесіп тастадым, енді бот күйі жай ғана бағдарлама жадында сақталады және мезгіл-мезгіл json түріндегі файлға сақталады. Түсініктемелерде олар менің қателескенімді, дерекқорды осы жерде пайдалану керектігін және т.б. деп жазатын шығар. Бірақ бұл менің жобам, файлмен жұмыс істеу мүмкіндігінше қарапайым және ол ашық түрде жұмыс істейді.

-1 сияқты сиқырлы мәндерді тастап, қалыпты мәндерді қайтарды Option, чат ақпараты бар нысанға кері жіберілген мақалалары бар хэш кестесінің қоймасы қосылды. Барлығын сақтамау үшін бес күннен асқан мақалалар туралы ақпаратты жою қосылды. Мен журналды жұмыс күйіне келтірдім - журналдар файлға да, консольге де қолайлы мөлшерде жазылады. Күйді сақтау немесе пайдаланушылар мен мақалалар саны сияқты статистиканы алу сияқты бірнеше әкімші пәрмендері қосылды.

Көптеген ұсақ-түйектер түзетілді: мысалы, мақалалар үшін пайдаланушы сүзгісінен өткен кездегі көрулер, ұнатулар, ұнатпаулар және пікірлер саны енді көрсетіледі. Жалпы, қаншама ұсақ-түйектерді түзетуге тура келгені таң қалдырады. Мен тізімді жүргіздім, ондағы барлық «бұзушылықтарды» атап өттім және оларды мүмкіндігінше түзеттім.

Мысалы, мен барлық параметрлерді тікелей бір хабарламада орнату мүмкіндігін қостым:

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

Және басқа команда /settings оларды дәл осы пішінде көрсетеді, сіз одан мәтінді алып, барлық параметрлерді досыңызға жібере аласыз.
Бұл кішкентай нәрсе сияқты көрінеді, бірақ ондаған ұқсас нюанстар бар.

Қарапайым сызықтық модель түріндегі мақаланы сүзу жүзеге асырылды - пайдаланушы авторлар мен тегтер үшін қосымша рейтингті, сондай-ақ шекті мәнді орната алады. Егер автор рейтингінің қосындысы, тегтердің орташа рейтингі және мақаланың нақты рейтингі шекті мәннен жоғары болса, онда мақала пайдаланушыға көрсетіледі. Сіз боттан /new пәрменімен мақалалар сұрай аласыз немесе ботқа жазыла аласыз және ол мақалаларды тәуліктің кез келген уақытында жеке хабарламаға жібереді.

Жалпы айтқанда, менде әр мақаланың қосымша мүмкіндіктерін (хабтар, пікірлер саны, бетбелгілер, рейтингті өзгерту динамикасы, мақаладағы мәтін, суреттер мен код, кілт сөздер) шығару және пайдаланушыға OK/ көрсету идеясы болды. әр мақалаға дауыс беруге және әр пайдаланушыға үлгіні үйретуге болмайды, бірақ мен тым жалқау болдым.

Сонымен қатар, жұмыстың логикасы соншалықты айқын болмайды. Енді мен пациентZero үшін +9000 рейтингін қолмен орната аламын және шекті рейтингі +20 болса, мен оның барлық мақалаларын алуға кепілдік беремін (әрине, кейбір тегтер үшін -100500 орнатпасам).

Соңғы архитектура өте қарапайым болып шықты:

1. Барлық чаттар мен мақалалардың күйін сақтайтын актер. Ол дискідегі файлдан күйін жүктейді және оны мезгіл-мезгіл, әр жолы жаңа файлға сақтайды.
2. RSS арнасына анда-санда кіріп, жаңа мақалалар туралы біліп, сілтемелерді қарап, талдау жасап, осы мақалаларды бірінші актерге жіберетін актер. Сонымен қатар, ол кейде бірінші актердан мақалалар тізімін сұрайды, үш күннен аспайтын, бірақ ұзақ уақыт бойы жаңартылмағандарын таңдап, оларды жаңартады.
3. Жеделхатпен сөйлесетін актер. Мен әлі де толық талдауды осында әкелдім. Ықтимал жолмен мен оны екіге бөлгім келеді - біреуі кіріс хабарламаларды талдайды, ал екіншісі жіберілмеген хабарламаларды қайта жіберу сияқты көлік мәселелерімен айналысады. Енді қайта жіберу жоқ және қатеге байланысты келмеген хабарлама жай жоғалады (егер ол журналдарда көрсетілмесе), бірақ әзірге бұл ешқандай қиындық тудырған жоқ. Көптеген адамдар ботқа жазылса және мен хабарлама жіберу шегіне жетсем, проблемалар туындауы мүмкін).

Маған ұнағаны, акканың арқасында 2 және 3 актерлердің құлауы әдетте боттың жұмысына әсер етпейді. Мүмкін, кейбір мақалалар уақытында жаңартылмайды немесе кейбір хабарламалар телеграммаға жетпейді, бірақ аккаунт актерді қайта іске қосады және бәрі жұмысын жалғастырады. Мен мақаланың пайдаланушыға көрсетілетіні туралы ақпаратты телеграмма актері хабарламаны сәтті жеткізді деп жауап бергенде ғана сақтаймын. Маған қауіп төндіретін ең нашар нәрсе - хабарламаны бірнеше рет жіберу (егер ол жеткізілсе, бірақ растау қандай да бір түрде жоғалып кетсе). Негізінде, егер бірінші актер күйді өз ішінде сақтамай, кейбір деректер базасымен байланысса, онда ол да байқалмай құлап, өмірге оралуы мүмкін. Мен сондай-ақ актерлердің жағдайын қалпына келтіру үшін ака табандылықты қолдана аламын, бірақ қазіргі іске асыру маған қарапайымдылығымен сәйкес келеді. Менің кодым жиі бұзылып тұрған жоқ - керісінше, мен оны мүмкін емес ету үшін көп күш жұмсадым. Бірақ бір нәрсе болады, және бағдарламаны оқшауланған актерлерге бөлу мүмкіндігі маған өте ыңғайлы және практикалық болып көрінді.

Мен шеңбер-ci қостым, егер код бұзылса, сіз бұл туралы бірден біле аласыз. Кем дегенде, бұл кодтың құрастырылуын тоқтатқанын білдіреді. Бастапқыда мен трависті қосқым келді, бірақ ол менің жобаларымды шанышқысыз ғана көрсетті. Жалпы, бұл екеуін де ашық репозиторийлерде еркін пайдалануға болады.

Нәтижелері

Қазірдің өзінде қараша. Бот жазылған, мен оны соңғы екі аптадан бері пайдаланып жүрмін, маған ұнады. Егер сізде жақсарту туралы идеяларыңыз болса, жазыңыз. Мен оны монетизациялаудың мәнін көрмеймін - ол жұмыс істеп, қызықты мақалалар жіберсін.

Бот сілтемесі: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Шағын қорытындылар:

• Тіпті шағын жобаның өзі көп уақытты алуы мүмкін.
• Сіз Google емессіз. Торғайларды зеңбіректен атудың мәні жоқ. Қарапайым шешім де жұмыс істей алады.
• Үй жануарлары жобалары жаңа технологиялармен тәжірибе жасау үшін өте жақсы.
• Telegram боттары өте қарапайым жазылған. Егер бұл «топтық жұмыс» және технологиямен тәжірибелер болмаса, бот бір-екі аптада жазылар еді.
• Актер моделі - бұл көп ағынды және қатеге төзімді кодпен жақсы үйлесетін қызықты нәрсе.
• Менің ойымша, мен ашық бастапқы қауымдастық шанышқыларды неге жақсы көретінін түсіндім.
• Дерекқорлар жақсы, себебі қолданба күйі енді қолданбаның бұзылуына/қайта іске қосылуына байланысты емес, бірақ дерекқормен жұмыс кодты қиындатады және деректер құрылымына шектеулер қояды.

Ақпарат көзі: www.habr.com