Telegram բոտ՝ Habr-ից հոդվածների անհատական ​​ընտրության համար

«Ինչու՞» նման հարցերի համար։ կա ավելի հին հոդված - Natural Geektimes - մաքրող տարածք.

Շատ հոդվածներ կան, սուբյեկտիվ պատճառներով դրանցից մի քանիսը ինձ դուր չեն գալիս, իսկ որոշները, ընդհակառակը, ափսոս եմ բաց թողնել։ Ես կցանկանայի օպտիմալացնել այս գործընթացը և խնայել ժամանակը:

Վերոնշյալ հոդվածը առաջարկում էր զննարկիչում սկրիպտավորման մոտեցում, բայց այն ինձ իսկապես դուր չեկավ (չնայած որ նախկինում օգտագործել եմ) հետևյալ պատճառներով.

• Ձեր համակարգչի/հեռախոսի տարբեր բրաուզերների համար դուք պետք է նորից կարգավորեք այն, եթե հնարավոր է:
• Հեղինակների կողմից խիստ զտումը միշտ չէ, որ հարմար է:
• Այն հեղինակների հետ կապված խնդիրը, որոնց հոդվածները չես ուզում բաց թողնել, նույնիսկ եթե դրանք հրապարակվեն տարին մեկ անգամ, չի լուծվել։

Հոդվածների վարկանիշների հիման վրա կայքում ներկառուցված զտումը միշտ չէ, որ հարմար է, քանի որ բարձր մասնագիտացված հոդվածները, չնայած իրենց արժեքին, կարող են բավականին համեստ գնահատական ​​ստանալ:

Սկզբում ես ուզում էի ստեղծել RSS հոսք (կամ նույնիսկ մի քանի)՝ այնտեղ թողնելով միայն հետաքրքիր բաներ։ Բայց վերջում պարզվեց, որ RSS կարդալն այնքան էլ հարմար չի թվացել՝ ամեն դեպքում հոդվածը մեկնաբանելու/քվեարկելու/ֆավորիտների մեջ ավելացնելու համար պետք է անցնել բրաուզերը։ Այդ իսկ պատճառով ես գրել եմ հեռագրային բոտ, որն ինձ անձնական հաղորդագրությամբ հետաքրքիր հոդվածներ է ուղարկում։ Telegram-ն ինքը դրանցից գեղեցիկ նախադիտումներ է պատրաստում, որոնք, համակցված հեղինակի/վարկանիշի/դիտումների մասին տեղեկատվության հետ, բավականին տեղեկատվական տեսք ունեն։

Կտրվածքի տակ ներկայացված են այնպիսի մանրամասներ, ինչպիսիք են աշխատանքի առանձնահատկությունները, գրելու գործընթացը և տեխնիկական լուծումները:

Համառոտ բոտի մասին

Պահեստ: https://github.com/Kright/habrahabr_reader

Բոտը հեռագրում. https://t.me/HabraFilterBot

Օգտագործողը սահմանում է լրացուցիչ վարկանիշ պիտակների և հեղինակների համար: Դրանից հետո հոդվածների վրա կիրառվում է զտիչ՝ գումարվում է հոդվածի վարկանիշը Habré-ում, հեղինակի օգտատերերի գնահատականը և օգտատերերի գնահատականների միջինը ըստ պիտակների: Եթե ​​գումարը ավելի մեծ է, քան օգտագործողի կողմից սահմանված շեմը, ապա հոդվածը անցնում է զտիչը:

Բոտ գրելու կողմնակի նպատակը զվարճանք և փորձ ձեռք բերելն էր: Բացի այդ, ես ինքս ինձ պարբերաբար հիշեցնում էի, որ Ես Google-ը չեմ, և հետևաբար շատ բաներ արվում են հնարավորինս պարզ և նույնիսկ պարզունակ։ Սակայն դա չխանգարեց, որ բոտը գրելու գործընթացը տեւի երեք ամիս։

Դրսում ամառ էր

Հուլիսն ավարտվում էր, և ես որոշեցի բոտ գրել։ Եվ ոչ միայնակ, այլ ընկերոջ հետ, ով տիրապետում էր սկալային և ցանկանում էր դրա վրա ինչ-որ բան գրել: Սկիզբը խոստումնալից թվաց. կոդը կկտրվի թիմով, առաջադրանքը հեշտ էր թվում, և ես մտածեցի, որ մի քանի շաբաթից կամ մեկ ամսից բոտը պատրաստ կլինի:

Չնայած այն հանգամանքին, որ ես ինքս ժամանակ առ ժամանակ գրում եմ կոդ ժայռի վրա վերջին մի քանի տարիների ընթացքում, ոչ ոք սովորաբար չի տեսնում կամ չի նայում այս ծածկագիրը. կենդանիների նախագծեր, որոշ գաղափարների փորձարկում, տվյալների նախնական մշակում, որոշ հասկացությունների յուրացում FP-ից: Ինձ իսկապես հետաքրքրում էր, թե ինչ տեսք ունի թիմում կոդ գրելը, քանի որ ռոքի վրա ծածկագիրը կարող է շատ տարբեր ձևերով գրվել:

Ինչ կարող էր գնալ այնքան? Այնուամենայնիվ, եկեք չշտապենք գործերը։
Այն ամենը, ինչ տեղի է ունենում, կարելի է հետևել՝ օգտագործելով պարտավորությունների պատմությունը:

Ծանոթներից մեկը հուլիսի 27-ին շտեմարան ստեղծեց, բայց ուրիշ ոչինչ չարեց, ուստի ես սկսեցի կոդ գրել։

30 Հուլիս

Համառոտ. Ես գրել եմ Habr-ի rss հոսքի վերլուծություն:

• com.github.pureconfig typesafe-ի կոնֆիգուրացիաները ուղղակիորեն case դասերի մեջ կարդալու համար (պարզվեց, որ շատ հարմար է)
• scala-xml xml կարդալու համար. քանի որ սկզբում ես ցանկանում էի գրել իմ սեփական կատարումը rss հոսքի համար, իսկ rss հոսքը xml ձևաչափով է, ես օգտագործեցի այս գրադարանը վերլուծության համար: Իրականում հայտնվել է նաև RSS վերլուծություն։
• scalatest թեստերի համար։ Նույնիսկ փոքր նախագծերի համար, թեստեր գրելը խնայում է ժամանակը, օրինակ, xml վերլուծությունը վրիպազերծելիս շատ ավելի հեշտ է այն ներբեռնել ֆայլ, գրել թեստեր և ուղղել սխալները: Երբ ավելի ուշ հայտնվեց սխալ՝ անվավեր utf-8 նիշերով ինչ-որ տարօրինակ html վերլուծելով, պարզվեց, որ ավելի հարմար է այն տեղադրել ֆայլի մեջ և ավելացնել թեստ։
• դերասաններ Աքքայից. Օբյեկտիվորեն դրանք ընդհանրապես պետք չէին, բայց նախագիծը գրված էր զվարճանալու համար, ես ուզում էի փորձել։ Արդյունքում ես պատրաստ եմ ասել, որ ինձ դուր եկավ: OOP-ի գաղափարը կարելի է դիտարկել մյուս կողմից. կան դերասաններ, ովքեր փոխանակվում են հաղորդագրություններով: Առավել հետաքրքիրն այն է, որ դուք կարող եք (և պետք է) գրել կոդ այնպես, որ հաղորդագրությունը չհասնի կամ չմշակվի (ընդհանուր առմամբ, երբ հաշիվն աշխատում է մեկ համակարգչի վրա, հաղորդագրությունները չպետք է կորչեն): Սկզբում ես գլուխս քորում էի, և կոդի մեջ աղբ կար՝ միմյանց բաժանորդագրվող դերասաններով, բայց վերջում ինձ հաջողվեց ստեղծել բավականին պարզ և էլեգանտ ճարտարապետություն։ Յուրաքանչյուր դերակատարի ներսում ծածկագիրը կարելի է համարել մեկ շղթայական, երբ դերասանը խափանում է, acca-ն վերագործարկում է այն, արդյունքը բավականին սխալ հանդուրժող համակարգ է:

9 Օգոստոս

Նախագծին ավելացրի scala-scrapper html էջերը Habr-ից վերլուծելու համար (օրինակ՝ հոդվածի վարկանիշը, էջանիշների քանակը և այլն) տեղեկություններ հանելու համար։

Եվ Կատուներ. Ժայռի մեջ գտնվողները։

Այնուհետև ես կարդացի գիրք բաշխված տվյալների շտեմարանների մասին, ինձ դուր եկավ CRDT-ի գաղափարը (Conflict-free replicated data type, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, հաբր), այնպես որ ես տեղադրեցի կոմուտատիվ կիսախմբի տիպի դաս՝ Habré-ի հոդվածի մասին տեղեկությունների համար։

Իրականում գաղափարը շատ պարզ է՝ մենք ունենք հաշվիչներ, որոնք միապաղաղ փոխվում են։ Ակցիաների թիվը աստիճանաբար աճում է, ինչպես նաև պլյուսների թիվը (նաև մինուսների թիվը): Եթե ​​ես հոդվածի մասին տեղեկատվության երկու տարբերակ ունեմ, ապա ես կարող եմ դրանք «միավորել մեկի մեջ». հաշվիչի վիճակը, որն ավելի մեծ է, համարվում է ավելի համապատասխան:

Կիսախումբը նշանակում է, որ հոդվածի մասին տեղեկություններ ունեցող երկու օբյեկտ կարող են միավորվել մեկի մեջ: Կոմուտատիվ նշանակում է, որ դուք կարող եք միաձուլել և՛ A + B, և՛ B + A, արդյունքը կախված չէ պատվերից, և վերջում կմնա նորագույն տարբերակը։ Ի դեպ, այստեղ կա նաև ասոցիատիվություն.

Օրինակ, ինչպես նախատեսվում էր, rss-ը վերլուծելուց հետո տրամադրեց մի փոքր թուլացած տեղեկատվություն հոդվածի մասին՝ առանց չափումների, ինչպիսին է դիտումների քանակը: Այնուհետև հատուկ դերասանը վերցրեց տեղեկություններ հոդվածների մասին և վազեց դեպի html էջեր՝ թարմացնելու այն և միացնելու այն հին տարբերակին:

Ընդհանրապես, ինչպես akka-ում, դրա կարիքը չկար, դուք կարող եք պարզապես պահել թարմացված ամսաթիվը հոդվածի համար և վերցնել ավելի նորը առանց որևէ միաձուլման, բայց արկածների ճանապարհն ինձ առաջնորդեց:

12 Օգոստոս

Ես սկսեցի ինձ ավելի ազատ զգալ և, պարզապես զվարճանալու համար, յուրաքանչյուր չաթում առանձին դերասան դարձրի: Տեսականորեն, դերասանն ինքնին կշռում է մոտ 300 բայթ, և դրանք կարող են ստեղծվել միլիոններով, այնպես որ սա լիովին նորմալ մոտեցում է: Ինձ թվում է, որ լուծումը բավականին հետաքրքիր է ստացվել.

Դերասաններից մեկը կամուրջ էր Telegram սերվերի և հաղորդագրությունների համակարգի միջև Աքքայում: Նա պարզապես հաղորդագրություններ էր ստանում և ուղարկում ցանկալի չաթի դերասանին: Չաթի դերասանը կարող էր ի պատասխան ինչ-որ բան ուղարկել, և այն հետ կուղարկվեր հեռագրին: Շատ հարմարն այն է, որ այս դերասանը հնարավորինս պարզ է ստացվել և պարունակում է միայն հաղորդագրություններին պատասխանելու տրամաբանություն։ Ի դեպ, նոր հոդվածների մասին տեղեկատվությունը գալիս էր յուրաքանչյուր զրույցի, բայց կրկին ես դրանում որևէ խնդիր չեմ տեսնում:

Ընդհանուր առմամբ, բոտն արդեն աշխատում էր, պատասխանում էր հաղորդագրություններին, պահպանում էր օգտատերին ուղարկված հոդվածների ցանկը, և ես արդեն մտածում էի, որ բոտը գրեթե պատրաստ է։ Ես կամաց-կամաց ավելացրի փոքրիկ առանձնահատկություններ, ինչպիսիք են հեղինակների անունների և պիտակների նորմալացումը («sd f»-ը փոխարինելով «s_d_f»-ով):

Միայն մի բան էր մնացել փոքր բայց — պետությունը ոչ մի տեղ չփրկվեց։

Ամեն ինչ սխալ ստացվեց

Երևի նկատել եք, որ բոտը հիմնականում մենակ եմ գրել։ Այսպիսով, մշակման մեջ ներգրավվեց երկրորդ մասնակիցը, և կոդում հայտնվեցին հետևյալ փոփոխությունները.

• MongoDB-ն, կարծես, պահում էր վիճակը: Միևնույն ժամանակ, նախագծի տեղեկամատյանները կոտրվեցին, քանի որ ինչ-ինչ պատճառներով Մոնգան սկսեց դրանք սպամ ուղարկել, և որոշ մարդիկ պարզապես անջատեցին դրանք ամբողջ աշխարհում:
• Telegram-ի կամուրջի դերասանը անճանաչելիորեն կերպարանափոխվեց և ինքն սկսեց վերլուծել հաղորդագրությունները:
• Չաթերի դերասանները անխնա հեռացվեցին, իսկ փոխարենը նրանց փոխարինեց մի դերասան, ով միանգամից թաքցրեց բոլոր զրույցների մասին բոլոր տեղեկությունները: Ամեն փռշտոցի համար այս դերասանը փորձանքի մեջ էր ընկնում։ Դե, այո, ինչպես հոդվածի մասին տեղեկատվությունը թարմացնելիս, այն ուղարկելը չաթի բոլոր դերակատարներին դժվար է (մենք նման ենք Google-ին, միլիոնավոր օգտատերեր յուրաքանչյուրի համար սպասում են մեկ միլիոն հոդվածի չաթում), բայց ամեն անգամ, երբ չաթը թարմացվում է, նորմալ է Մոնգա մտնելը: Ինչպես հասկացա շատ ավելի ուշ, չաթերի աշխատանքային տրամաբանությունը նույնպես ամբողջությամբ կտրվեց և իր տեղում հայտնվեց մի բան, որը չէր աշխատում։
• Տիպի դասերից ոչ մի հետք չի մնացել։
• Ինչ-որ անառողջ տրամաբանություն է հայտնվել դերասանների մեջ՝ միմյանց բաժանորդագրություններով, ինչը հանգեցնում է ռասայական վիճակի։
• Տվյալների կառուցվածքներ տիպի դաշտերով Option[Int] վերածվեց Int-ի՝ կախարդական լռելյայն արժեքներով, ինչպիսիք են -1: Հետագայում ես հասկացա, որ mongoDB-ն պահում է json-ը և այն այնտեղ պահելու մեջ վատ բան չկա Option լավ, կամ գոնե վերլուծել -1-ը որպես None, բայց այն ժամանակ ես չգիտեի սա և ընդունեցի իմ խոսքն այն մասին, որ «այդպես պետք է լիներ»: Ես չեմ գրել այդ կոդը, և առայժմ չեմ անհանգստացել այն փոխել:
• Ես պարզեցի, որ իմ հանրային IP հասցեն հակված է փոխվելու, և ամեն անգամ ստիպված էի այն ավելացնել Mongo-ի սպիտակ ցուցակում: Ես գործարկեցի բոտը տեղական մակարդակում, Մոնգան ինչ-որ տեղ Մոնգայի սերվերների վրա էր որպես ընկերություն:
• Հանկարծ անհետացավ պիտակների և հեռագրերի հաղորդագրությունների ձևաչափման կարգավորումը: (Հմմ, ինչու՞ դա կլիներ:)
• Ինձ դուր եկավ, որ բոտի վիճակը պահվում է արտաքին տվյալների բազայում, և երբ վերագործարկվում է, այն շարունակում է աշխատել այնպես, կարծես ոչինչ չի եղել: Այնուամենայնիվ, սա միակ պլյուսն էր:

Երկրորդ մարդն առանձնապես չէր շտապում, և այս բոլոր փոփոխությունները մեկ մեծ կույտի մեջ հայտնվեցին արդեն սեպտեմբերի սկզբին։ Ես անմիջապես չգնահատեցի արդյունքում առաջացած ոչնչացման մասշտաբները և սկսեցի հասկանալ տվյալների բազայի աշխատանքը, քանի որ... Ես նրանց հետ նախկինում երբեք չեմ առնչվել։ Միայն ավելի ուշ հասկացա, թե որքան աշխատանքային կոդ է կրճատվել և որքան սխալներ են ավելացվել դրա փոխարեն:

Սեպտեմբեր

Սկզբում մտածեցի, որ օգտակար կլինի տիրապետել Մոնգային և լավ անել: Հետո ես կամաց-կամաց սկսեցի հասկանալ, որ տվյալների բազայի հետ շփումը կազմակերպելը նույնպես արվեստ է, որտեղ կարելի է շատ վազքներ կատարել և պարզապես սխալվել։ Օրինակ, եթե օգտվողը ստանում է երկու հաղորդագրություն, ինչպես /subscribe - և ի պատասխան յուրաքանչյուրի մենք կստեղծենք գրառում աղյուսակում, քանի որ այդ հաղորդագրությունների մշակման պահին օգտատերը բաժանորդագրված չէ։ Ես կասկած ունեմ, որ Մոնգայի հետ հաղորդակցությունն իր ներկայիս տեսքով ամենալավ ձևով չի գրված։ Օրինակ, օգտատիրոջ կարգավորումները ստեղծվել են այն պահին, երբ նա գրանցվել է: Եթե ​​մինչ բաժանորդագրության փաստը փորձեր փոխել... բոտը ոչինչ չէր արձագանքում, քանի որ դերասանի կոդը մտել է կարգավորումների տվյալների բազա, չի գտել ու խափանվել է։ Երբ ինձ հարցրին, թե ինչու չստեղծել կարգավորումներ ըստ անհրաժեշտության, ես իմացա, որ կարիք չկա դրանք փոխելու, եթե օգտատերը բաժանորդագրված չէ... Հաղորդագրությունների զտման համակարգը ստեղծվել է ինչ-որ կերպ ոչ ակնհայտորեն, և նույնիսկ ծածկագիրը ուշադիր նայելուց հետո ես կարողացա չեմ հասկանում՝ սկզբում այդպես էր նախատեսված, թե սխալ կա:

Չաթին ներկայացված հոդվածների ցանկ չկար, փոխարենը առաջարկվեց ինքս գրել դրանք։ Սա ինձ զարմացրեց. ընդհանրապես ես դեմ չէի ամենատարբեր բաները նախագծի մեջ քաշելուն, բայց տրամաբանական կլիներ, ով այս բաները մտցրեց ու պտտեց: Բայց ոչ, երկրորդ մասնակիցը կարծես թե հրաժարվեց ամեն ինչից, բայց ասաց, որ չաթի ներսում ցուցակը, իբր, վատ լուծում է, և անհրաժեշտ է նշան անել այնպիսի իրադարձություններով, ինչպիսին է «y հոդվածը ուղարկվել է x օգտվողին»: Այնուհետև, եթե օգտատերը խնդրել էր ուղարկել նոր հոդվածներ, անհրաժեշտ էր հարցում ուղարկել տվյալների շտեմարան, որը իրադարձություններից կընտրեր օգտատիրոջ հետ կապված իրադարձությունները, կստանար նաև նոր հոդվածների ցանկ, զտեր դրանք, ուղարկեր օգտատիրոջը։ և այս մասին իրադարձությունները հետ գցեք տվյալների բազա:

Երկրորդ մասնակիցը տարվել է ինչ-որ տեղ դեպի աբստրակցիաներ, երբ բոտը կստանա ոչ միայն հոդվածներ Habr-ից և կուղարկվի ոչ միայն հեռագրում։

Սեպտեմբերի երկրորդ կեսի առանձին նշանի տեսքով միջոցառումները մի կերպ իրականացրեցի։ Դա օպտիմալ չէ, բայց համենայն դեպս, բոտը սկսեց աշխատել և նորից սկսեց ինձ հոդվածներ ուղարկել, և ես կամաց-կամաց հասկացա, թե ինչ է կատարվում կոդում:

Այժմ կարող եք վերադառնալ սկզբին և հիշել, որ պահոցն ի սկզբանե իմ կողմից չի ստեղծվել: Ի՞նչը կարող էր այսպես լինել: Իմ ձգման խնդրանքը մերժվեց: Պարզվեց, որ ես ունեի redneck կոդը, որ ես չգիտեի, թե ինչպես աշխատել թիմում, և ես ստիպված էի շտկել սխալները ընթացիկ կատարման կորի մեջ և չմշակել այն օգտագործելի վիճակում:

Ես վրդովվեցի և նայեցի կատարման պատմությանը և գրված կոդի քանակին: Ես նայեցի այն պահերին, որոնք ի սկզբանե լավ էին գրված, իսկ հետո կոտրվեցին…

F*rk it

Հիշեցի հոդվածը Դուք 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/ ոչ լավ քվեարկեք յուրաքանչյուր հոդվածի տակ և պատրաստեք մոդել յուրաքանչյուր օգտագործողի համար, բայց ես չափազանց ծույլ էի:

Բացի այդ, աշխատանքի տրամաբանությունն այնքան էլ ակնհայտ չի լինի։ Այժմ ես կարող եմ ձեռքով սահմանել +9000 վարկանիշ հիվանդի համար, իսկ +20 շեմային գնահատականով ես երաշխավորված կստանամ նրա բոլոր հոդվածները (եթե, իհարկե, որոշ պիտակների համար չեմ սահմանել -100500):

Վերջնական ճարտարապետությունը պարզվեց, որ բավականին պարզ է.

1. Դերասան, որը պահպանում է բոլոր չաթերի և հոդվածների վիճակը: Այն բեռնում է իր վիճակը սկավառակի վրա գտնվող ֆայլից և պահում է այն ժամանակ առ ժամանակ, ամեն անգամ նոր ֆայլում:
2. Դերասան, ով ժամանակ առ ժամանակ այցելում է RSS հոսք, իմանում է նոր հոդվածների մասին, նայում հղումները, վերլուծում և ուղարկում այդ հոդվածները առաջին դերասանին։ Բացի այդ, երբեմն առաջին դերասանից պահանջում է հոդվածների ցանկ, ընտրում է երեք օրից ոչ հին, բայց երկար ժամանակ չթարմացված հոդվածները և թարմացնում։
3. Հեռագրով շփվող դերասան. Ես դեռ ամբողջությամբ այստեղ եմ բերել հաղորդագրությունների վերլուծությունը: Բարեկամաբար, ես կցանկանայի այն բաժանել երկու մասի, որպեսզի մեկը վերլուծի մուտքային հաղորդագրությունները, իսկ երկրորդը զբաղվի տրանսպորտի խնդիրներով, ինչպիսիք են չուղարկված հաղորդագրությունները նորից ուղարկելը: Այժմ կրկին ուղարկում չկա, և սխալի պատճառով չհասած հաղորդագրությունը պարզապես կկորչի (եթե դա նշված չէ տեղեկամատյաններում), բայց մինչ այժմ դա որևէ խնդիր չի առաջացրել: Միգուցե խնդիրներ առաջանան, եթե մի խումբ մարդիկ բաժանորդագրվեն բոտին, և ես հասնեմ հաղորդագրություններ ուղարկելու սահմանաչափին):

Ինձ դուր եկավ այն, որ akka-ի շնորհիվ 2-րդ և 3-րդ դերասանների անկումները հիմնականում չեն ազդում բոտի կատարման վրա: Միգուցե որոշ հոդվածներ ժամանակին չեն թարմացվում կամ որոշ հաղորդագրություններ չեն հասնում հեռագրին, բայց հաշիվը վերագործարկում է դերասանին, և ամեն ինչ շարունակում է աշխատել։ Ես պահպանում եմ այն ​​տեղեկատվությունը, որ հոդվածը ցուցադրվում է օգտատիրոջը միայն այն ժամանակ, երբ հեռագրային դերասանը պատասխանում է, որ նա հաջողությամբ փոխանցել է հաղորդագրությունը: Ամենավատ բանը, որ սպառնում է ինձ, հաղորդագրությունը մի քանի անգամ ուղարկելն է (եթե այն առաքվում է, բայց հաստատումն ինչ-որ կերպ կորել է): Սկզբունքորեն, եթե առաջին դերասանը պետությունը չպահեր իր մեջ, այլ շփվեր ինչ-որ տվյալների բազայի հետ, ապա նա նույնպես կարող էր աննկատ ընկնել ու կյանք վերադառնալ։ Ես կարող էի նաև փորձել akka persistance-ը դերասանների վիճակը վերականգնելու համար, բայց ներկայիս իրականացումն ինձ հարմար է իր պարզությամբ: Այնպես չէ, որ իմ կոդը հաճախ խափանում էր, ընդհակառակը, ես բավականին մեծ ջանք գործադրեցի դա անհնարին դարձնելու համար: Բայց հիմարությունը տեղի է ունենում, և ծրագիրը առանձին հատվածների՝ դերասանների բաժանելու ունակությունն ինձ իսկապես հարմար և գործնական թվաց:

Ես ավելացրել եմ circle-ci-ն, որպեսզի եթե կոդը կոտրվի, դուք անմիջապես իմանաք դրա մասին։ Նվազագույնը նշանակում է, որ կոդը դադարել է կազմել։ Ի սկզբանե ես ուզում էի ավելացնել travis, բայց այն ցույց տվեց իմ նախագծերը միայն առանց պատառաքաղների: Ընդհանուր առմամբ, այս երկու բաներն էլ կարող են ազատորեն օգտագործվել բաց պահեստներում:

Արդյունքները

Արդեն նոյեմբեր է։ Բոտը գրված է, վերջին երկու շաբաթն եմ օգտագործում ու հավանեցի։ Եթե ​​բարելավման գաղափարներ ունեք, գրեք։ Ես դրա դրամայնացման իմաստ չեմ տեսնում. թող այն աշխատի և հետաքրքիր հոդվածներ ուղարկի:

Բոտի հղում. https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

Փոքր եզրակացություններ.

• Նույնիսկ փոքր նախագիծը կարող է շատ ժամանակ խլել:
• Դուք Google-ը չեք: Թնդանոթից ճնճղուկներին կրակելն իմաստ չունի։ Պարզ լուծումը կարող է նույնքան լավ աշխատել:
• Կենդանիների հետ կապված նախագծերը շատ լավն են նոր տեխնոլոգիաների փորձարկումների համար:
• Telegram բոտերը գրված են բավականին պարզ: Եթե ​​չլինեին «թիմային աշխատանքը» և տեխնոլոգիայի հետ փորձերը, բոտը կգրվեր մեկ-երկու շաբաթից:
• Դերասանի մոդելը հետաքրքիր բան է, որը լավ համադրվում է բազմաշերտ և սխալ հանդուրժող կոդի հետ:
• Կարծում եմ, ես հասկացա, թե ինչու է բաց կոդով համայնքը սիրում պատառաքաղներ:
• Տվյալների բազաները լավն են, քանի որ հավելվածի վիճակն այլևս կախված չէ հավելվածի խափանումներից/վերագործարկումներից, սակայն տվյալների բազայի հետ աշխատելը բարդացնում է կոդը և սահմանափակումներ է դնում տվյալների կառուցվածքի վրա:

Source: www.habr.com