Telegram-ის ბოტი Habr-ის სტატიების პერსონალური შერჩევისთვის

კითხვებისთვის, როგორიცაა "რატომ?" არის უფრო ძველი სტატია - Natural Geektimes - სივრცის გამწმენდი.

ბევრი სტატიაა, სუბიექტური მიზეზების გამო ზოგი არ მომწონს, ზოგი კი პირიქით, სამწუხაროა გამოტოვება. მსურს ამ პროცესის ოპტიმიზაცია და დროის დაზოგვა.

ზემოხსენებულმა სტატიამ შემოგვთავაზა ბრაუზერის სკრიპტირების მიდგომა, მაგრამ მე ნამდვილად არ მომეწონა (მიუხედავად იმისა, რომ ადრეც ვიყენებდი) შემდეგი მიზეზების გამო:

• თქვენი კომპიუტერის/ტელეფონის სხვადასხვა ბრაუზერისთვის, თუ ეს შესაძლებელია, ხელახლა უნდა დააკონფიგურიროთ.
• ავტორის მიერ მკაცრი ფილტრაცია ყოველთვის არ არის მოსახერხებელი.
• პრობლემა იმ ავტორებთან, რომელთა სტატიების გამოტოვებაც არ გინდათ, თუნდაც წელიწადში ერთხელ გამოქვეყნდეს, არ მოგვარებულა.

საიტზე ჩაშენებული ფილტრაცია სტატიის რეიტინგების საფუძველზე ყოველთვის არ არის მოსახერხებელი, რადგან მაღალ სპეციალიზებულ სტატიებს, მიუხედავად მათი ღირებულებისა, შეუძლიათ მიიღონ საკმაოდ მოკრძალებული შეფასება.

თავიდან მინდოდა RSS feed-ის გენერირება (ან თუნდაც რამდენიმე) და იქ მხოლოდ საინტერესო რამ დავტოვე. მაგრამ საბოლოოდ, აღმოჩნდა, რომ RSS-ის წაკითხვა არც თუ ისე მოსახერხებელი ჩანდა: ნებისმიერ შემთხვევაში, სტატიისთვის კომენტარის გაკეთება/ხმის მიცემა/ფავორიტებში დამატება, ბრაუზერი უნდა გაიაროთ. სწორედ ამიტომ დავწერე ტელეგრამის ბოტი, რომელიც საინტერესო სტატიებს მიგზავნის პირად შეტყობინებაში. თავად Telegram აკეთებს მათგან ლამაზ გადახედვებს, რომლებიც ავტორის/რეიტინგის/ნახვების შესახებ ინფორმაციას შერწყმული საკმაოდ ინფორმაციულად გამოიყურება.

ჭრილის ქვემოთ მოცემულია ისეთი დეტალები, როგორიცაა ნამუშევრის მახასიათებლები, წერის პროცესი და ტექნიკური გადაწყვეტილებები.

მოკლედ ბოტის შესახებ

საცავი: https://github.com/Kright/habrahabr_reader

ბოტი ტელეგრამაში: https://t.me/HabraFilterBot

მომხმარებელი ადგენს დამატებით რეიტინგს ტეგებისა და ავტორებისთვის. ამის შემდეგ, სტატიებზე გამოიყენება ფილტრი - ემატება სტატიის რეიტინგი Habré-ზე, ავტორის მომხმარებლის რეიტინგი და მომხმარებლის რეიტინგების საშუალო ტეგების მიხედვით. თუ თანხა აღემატება მომხმარებლის მიერ მითითებულ ზღვარს, მაშინ სტატია გადის ფილტრს.

ბოტის დაწერის გვერდითი მიზანი იყო გართობის და გამოცდილების მოპოვება. ამას გარდა, რეგულარულად ვახსენებდი თავს მე არ ვარ Google, და ამიტომ ბევრი რამ კეთდება რაც შეიძლება მარტივად და თუნდაც პრიმიტიულად. თუმცა, ამან ხელი არ შეუშალა ბოტის დაწერის პროცესს სამი თვე დასჭირდეს.

გარეთ ზაფხული იყო

ივლისი იწურებოდა და გადავწყვიტე ბოტის დაწერა. და არა მარტო, არამედ მეგობართან, რომელიც ითვისებდა სკალას და მასზე რაღაცის დაწერა სურდა. დასაწყისი პერსპექტიული ჩანდა - კოდს გუნდი ამოიჭრიდა, დავალება მარტივი მეჩვენა და ვფიქრობდი, რომ რამდენიმე კვირაში ან ერთ თვეში ბოტი მზად იქნებოდა.

იმისდა მიუხედავად, რომ მე თვითონ ვწერდი კოდს კლდეზე ბოლო რამდენიმე წლის განმავლობაში, ჩვეულებრივ, არავინ ხედავს და არ უყურებს ამ კოდს: შინაური ცხოველების პროექტები, ზოგიერთი იდეის ტესტირება, მონაცემების წინასწარი დამუშავება, ზოგიერთი კონცეფციის დაუფლება FP-დან. ძალიან მაინტერესებდა როგორ გამოიყურება გუნდში კოდის წერა, რადგან როკზე კოდი შეიძლება დაიწეროს ძალიან განსხვავებული გზით.

რა შეიძლებოდა წასულიყო ასე? თუმცა საქმეებს ნუ ვიჩქარებთ.
ყველაფერი, რაც ხდება, შეგიძლიათ თვალყური ადევნოთ ჩადენის ისტორიის გამოყენებით.

ნაცნობმა 27 ივლისს შექმნა საცავი, მაგრამ სხვა არაფერი გაუკეთებია, ამიტომ კოდის წერა დავიწყე.

30 ივლისი

მოკლედ: მე დავწერე Habr-ის rss feed-ის ანალიზი.

• com.github.pureconfig typesafe კონფიგურაციების პირდაპირ ქეისების კლასებში წასაკითხად (ძალიან მოსახერხებელი აღმოჩნდა)
• scala-xml xml წასაკითხად: ვინაიდან თავიდან მინდოდა დამეწერა საკუთარი იმპლემენტაცია rss არხისთვის და rss feed არის xml ფორმატში, გამოვიყენე ეს ბიბლიოთეკა პარსინგისთვის. ფაქტობრივად, RSS პარსინგიც გამოჩნდა.
• scalatest ტესტებისთვის. პაწაწინა პროექტებისთვისაც კი, ტესტების ჩაწერა დაზოგავს დროს - მაგალითად, xml პარსინგის გამართვისას, ბევრად უფრო ადვილია მისი ფაილში ჩამოტვირთვა, ტესტების ჩაწერა და შეცდომების გამოსწორება. როდესაც მოგვიანებით გაჩნდა შეცდომა რაღაც უცნაური html-ის ანალიზისას არასწორი utf-8 სიმბოლოებით, უფრო მოსახერხებელი აღმოჩნდა მისი ფაილში ჩასმა და ტესტის დამატება.
• მსახიობები აკადან. ობიექტურად სულ არ იყო საჭირო, მაგრამ პროექტი გასართობად იყო დაწერილი, მინდოდა მეცადა. შედეგად, მე მზად ვარ ვთქვა, რომ მომეწონა. OOP-ის იდეას მეორე მხრიდანაც შეიძლება შევხედოთ - არიან მსახიობები, რომლებიც ცვლიან შეტყობინებებს. რაც უფრო საინტერესოა, შეგიძლიათ (და უნდა) დაწეროთ კოდი ისე, რომ შეტყობინება არ მოვიდეს ან არ დამუშავდეს (ზოგადად, როდესაც ანგარიში მუშაობს ერთ კომპიუტერზე, შეტყობინებები არ უნდა დაიკარგოს). თავიდან თავს ვიკაწრებდი და კოდში იყო ნაგავი, სადაც მსახიობები ერთმანეთს იწერდნენ, მაგრამ ბოლოს საკმაოდ მარტივი და ელეგანტური არქიტექტურის გამოგონება მოვახერხე. კოდი თითოეული აქტორის შიგნით შეიძლება ჩაითვალოს ერთნაკადად; როდესაც მსახიობი ავარია, acca განაახლებს მას - შედეგი არის საკმაოდ შეცდომის ტოლერანტული სისტემა.

9 აგვისტო

პროექტს დავამატე scala-scrapper html გვერდების გაანალიზებისთვის Habr-დან (ინფორმაციის ამოსაღებად, როგორიცაა სტატიის რეიტინგი, სანიშნეების რაოდენობა და ა.შ.).

და კატები. კლდეში მყოფნი.

შემდეგ წავიკითხე წიგნი განაწილებული მონაცემთა ბაზების შესახებ, მომეწონა CRDT-ის იდეა (კონფლიქტის გარეშე რეპლიკაციური მონაცემთა ტიპი, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, ჰაბრ), ასე რომ, მე გამოვაქვეყნე კომუტაციური ნახევრად ჯგუფის ტიპის კლასი სტატიის შესახებ ინფორმაციისთვის Habré-ზე.

სინამდვილეში, იდეა ძალიან მარტივია – გვაქვს მრიცხველები, რომლებიც მონოტონურად იცვლება. აქციების რაოდენობა თანდათან იზრდება, ისევე როგორც პლიუსების რაოდენობა (ასევე მინუსების რაოდენობა). თუ მე მაქვს სტატიის შესახებ ინფორმაციის ორი ვერსია, მაშინ შემიძლია „შევერთო ისინი ერთში“ - მრიცხველის მდგომარეობა, რომელიც უფრო დიდია, უფრო აქტუალურია.

ნახევარჯგუფი ნიშნავს, რომ სტატიის შესახებ ინფორმაციის მქონე ორი ობიექტი შეიძლება გაერთიანდეს ერთში. Commutative ნიშნავს, რომ თქვენ შეგიძლიათ შეაერთოთ A + B და B + A, შედეგი არ არის დამოკიდებული შეკვეთაზე და საბოლოოდ დარჩება უახლესი ვერსია. სხვათა შორის, აქაც არის ასოციაციურობა.

მაგალითად, როგორც დაგეგმილი იყო, rss-მა გაანალიზების შემდეგ ოდნავ დასუსტებული ინფორმაცია მოგვაწოდა სტატიის შესახებ - ისეთი მეტრიკის გარეშე, როგორიცაა ნახვების რაოდენობა. შემდეგ სპეციალურმა მსახიობმა აიღო ინფორმაცია სტატიების შესახებ და გაიქცა html გვერდებზე, რათა განაახლოს იგი და შეერწყა ძველ ვერსიას.

ზოგადად, როგორც akka-ში, ამის საჭიროება არ იყო, უბრალოდ შეიძლებოდა სტატიისთვის განახლებული თარიღის შენახვა და ყოველგვარი შერწყმის გარეშე აეღო უფრო ახალი, მაგრამ თავგადასავლების გზამ მიმიყვანა.

12 აგვისტო

უფრო თავისუფლად დავიწყე და, უბრალოდ, გასართობად, თითოეული ჩატი ცალკე მსახიობად ვაქციე. თეორიულად, თავად მსახიობი დაახლოებით 300 ბაიტს იწონის და მათი შექმნა მილიონებშია შესაძლებელი, ამიტომ ეს სრულიად ნორმალური მიდგომაა. მეჩვენება, რომ გამოსავალი საკმაოდ საინტერესო აღმოჩნდა:

ერთი მსახიობი იყო ხიდი ტელეგრამის სერვერსა და შეტყობინებების სისტემას შორის აკკაში. ის უბრალოდ იღებდა შეტყობინებებს და უგზავნიდა სასურველ ჩატის მსახიობს. ჩეთის მსახიობს შეეძლო საპასუხოდ რაღაც გამოეგზავნა - და ის ისევ დეპეშაში გაეგზავნა. ძალიან მოსახერხებელი იყო ის, რომ ეს მსახიობი მაქსიმალურად მარტივი აღმოჩნდა და შეიცავდა მხოლოდ შეტყობინებებზე პასუხის ლოგიკას. სხვათა შორის, ახალი სტატიების შესახებ ინფორმაცია მოდიოდა ყველა ჩატში, მაგრამ ისევ ამაში პრობლემას ვერ ვხედავ.

ზოგადად, ბოტი უკვე მუშაობდა, პასუხობდა შეტყობინებებს, ინახავდა მომხმარებლისთვის გაგზავნილი სტატიების სიას და მე უკვე ვფიქრობდი, რომ ბოტი თითქმის მზად იყო. მე ნელ-ნელა დავამატე პატარა ფუნქციები, როგორიცაა ავტორის სახელებისა და ტეგების ნორმალიზება („s.d f“-ის „s_d_f“-ით ჩანაცვლება).

დარჩა მხოლოდ ერთი რამ პატარა მაგრამ — სახელმწიფო ვერსად გადაარჩინა.

ყველაფერი არასწორად წავიდა

ალბათ შეგიმჩნევიათ, რომ ბოტი ძირითადად მარტო დავწერე. ასე რომ, მეორე მონაწილე ჩაერთო განვითარებაში და შემდეგი ცვლილებები გამოჩნდა კოდში:

• როგორც ჩანს, MongoDB ინახავს მდგომარეობას. ამავდროულად, პროექტში ჟურნალები დაირღვა, რადგან რატომღაც მონგამ დაიწყო მათი სპამი და ზოგიერთმა უბრალოდ გამორთო ისინი გლობალურად.
• ხიდის მსახიობი Telegram-ში გარდაიქმნა აღიარების მიღმა და თავად დაიწყო შეტყობინებების გარჩევა.
• ჩატებისთვის მსახიობები უმოწყალოდ ამოწყვიტეს და მათ ნაცვლად ისინი ჩაანაცვლეს მსახიობმა, რომელიც ერთდროულად მალავდა ყველა ინფორმაციას ყველა ჩატის შესახებ. ყოველი დაცემინებისას ამ მსახიობს უჭირდა. დიახ, ისევე, როგორც სტატიის შესახებ ინფორმაციის განახლებისას, მისი გაგზავნა ჩეთის ყველა მონაწილესთვის რთულია (ჩვენ ვართ Google-ის მსგავსი, მილიონობით მომხმარებელი ელოდება მილიონ სტატიას ჩატში თითოეულისთვის), მაგრამ ყოველ ჯერზე, როცა ჩატი განახლდება, ნორმალურია მონგაში წასვლა. როგორც მოგვიანებით მივხვდი, ჩეთების სამუშაო ლოგიკაც მთლიანად ამოიჭრა და მის ადგილას გამოჩნდა რაღაც, რაც არ მუშაობდა.
• ტიპების კლასებიდან კვალი არ დარჩა.
• რაღაც არაჯანსაღი ლოგიკა გაჩნდა მსახიობებში ერთმანეთის გამოწერებით, რასაც რასის მდგომარეობამდე მივყავართ.
• მონაცემთა სტრუქტურები ტიპის ველებით Option[Int] გადაიქცა Int-ად მაგიური ნაგულისხმევი მნიშვნელობებით, როგორიცაა -1. მოგვიანებით მივხვდი, რომ mongoDB ინახავს json-ს და იქ მის შენახვაში ცუდი არაფერია Option კარგად, ან თუნდაც -1 გააანალიზე, როგორც None, მაგრამ იმ დროს მე არ ვიცოდი ეს და ჩემი სიტყვა მივიღე, რომ "ასე უნდა იყოს". მე არ დამიწერია ეს კოდი და ამ დროისთვის არც შევცვალე თავი.
• გავარკვიე, რომ ჩემი საჯარო IP მისამართი იცვლება და ყოველ ჯერზე მიწევდა მისი დამატება Mongo-ს თეთრ სიაში. ბოტი ადგილობრივად გავუშვი, Monga იყო სადღაც Monga-ს სერვერებზე, როგორც კომპანია.
• მოულოდნელად, ტელეგრამებისთვის ტეგების ნორმალიზება და შეტყობინებების ფორმატირება გაქრა. (ჰმ, რატომ იქნებოდა ეს?)
• მომეწონა, რომ ბოტის მდგომარეობა ინახება გარე მონაცემთა ბაზაში და გადატვირთვისას ის აგრძელებს მუშაობას ისე, თითქოს არაფერი მომხდარა. თუმცა, ეს იყო ერთადერთი პლიუსი.

მეორე ადამიანს არ ჩქარობდა და ყველა ეს ცვლილება ერთ დიდ გროვაში გამოჩნდა უკვე სექტემბრის დასაწყისში. მაშინვე არ ვაფასებდი შედეგად განადგურების მასშტაბებს და დავიწყე მონაცემთა ბაზის მუშაობის გაგება, რადგან... აქამდე არასდროს მქონია მათთან შეხება. მხოლოდ მოგვიანებით მივხვდი, რამდენი სამუშაო კოდი იყო ამოჭრილი და რამდენი ხარვეზი დაემატა მის ადგილას.

სექტემბერი

თავიდან ვფიქრობდი, რომ სასარგებლო იქნებოდა მონგას დაუფლება და კარგად გაკეთება. შემდეგ ნელ-ნელა დავიწყე იმის გაგება, რომ მონაცემთა ბაზასთან კომუნიკაციის ორგანიზება ასევე ხელოვნებაა, რომელშიც შეგიძლიათ ბევრი რბოლა და უბრალოდ შეცდომის დაშვება. მაგალითად, თუ მომხმარებელი მიიღებს ორ შეტყობინებას, როგორიცაა /subscribe - და თითოეულის პასუხად შევქმნით ჩანაწერს ცხრილში, რადგან ამ შეტყობინებების დამუშავების დროს მომხმარებელი არ არის გამოწერილი. მე მაქვს ეჭვი, რომ მონგასთან ურთიერთობა მისი ამჟამინდელი ფორმით არ არის დაწერილი საუკეთესოდ. მაგალითად, მომხმარებლის პარამეტრები შეიქმნა იმ მომენტში, როდესაც ის დარეგისტრირდა. თუ გამოწერის ფაქტამდე ცდილობდა მათ შეცვლას... ბოტმა არაფერი უპასუხა, რადგან აქტორის კოდი პარამეტრების მონაცემთა ბაზაში შევიდა, ვერ იპოვა და გაფუჭდა. როდესაც მკითხეს, რატომ არ შექმენით პარამეტრები საჭიროებისამებრ, გავიგე, რომ არ არის საჭირო მათი შეცვლა, თუ მომხმარებელი არ არის გამოწერილი... შეტყობინებების ფილტრაციის სისტემა გაკეთდა რატომღაც არა ცხადად და კოდის დათვალიერების შემდეგაც კი შემეძლო. არ მესმის, თავდაპირველად ასე იყო გამიზნული თუ არის შეცდომა.

ჩატში არ იყო წარმოდგენილი სტატიების სია, სამაგიეროდ, შემომთავაზეს, რომ მე თვითონ დამეწერა ისინი. ამან გამაკვირვა - ზოგადად, პროექტში ყველანაირი ნივთის ჩათრევის წინააღმდეგი არ ვიყავი, მაგრამ ლოგიკური იქნებოდა ის, ვინც ეს ნივთები შემოიტანა და გააფუჭა. მაგრამ არა, მეორე მონაწილემ, როგორც ჩანს, უარი თქვა ყველაფერზე, მაგრამ თქვა, რომ ჩატის შიგნით არსებული სია, სავარაუდოდ, ცუდი გამოსავალი იყო და საჭირო იყო ნიშნის გაკეთება ისეთი მოვლენებით, როგორიცაა "სტატია y გაეგზავნა x მომხმარებელს". შემდეგ, თუ მომხმარებელმა მოითხოვა ახალი სტატიების გაგზავნა, საჭირო იყო მოთხოვნის გაგზავნა მონაცემთა ბაზაში, რომელიც ირჩევდა მომხმარებელთან დაკავშირებულ მოვლენებს მოვლენებიდან, ასევე მიიღებდა ახალი სტატიების სიას, გაფილტრავდა მათ, გაუგზავნიდა მომხმარებელს. და გადაყარეთ მოვლენები ამის შესახებ მონაცემთა ბაზაში.

მეორე მონაწილე სადღაც გაიტაცა აბსტრაქციებისკენ, როდესაც ბოტი მიიღებს არამარტო სტატიებს ჰაბრისგან და გაიგზავნება არა მხოლოდ ტელეგრამაში.

სექტემბრის მეორე ნახევრის ცალკეული ნიშნის სახით რაღაცნაირად განვახორციელე ღონისძიებები. არ არის ოპტიმალური, მაგრამ მაინც ბოტმა დაიწყო მუშაობა და ისევ დამიწყო სტატიების გაგზავნა და ნელ-ნელა მივხვდი რა ხდებოდა კოდში.

ახლა შეგიძლიათ დაუბრუნდეთ საწყისს და გახსოვდეთ, რომ საცავი თავდაპირველად არ შექმნილა ჩემს მიერ. რა შეიძლებოდა ასე მომხდარიყო? ჩემი მოზიდვის მოთხოვნა უარყოფილი იქნა. აღმოჩნდა, რომ მე მქონდა redneck კოდი, რომ არ ვიცოდი გუნდში მუშაობა და უნდა გამომესწორებინა შეცდომები მიმდინარე იმპლემენტაციის მრუდში და არა მისი დახვეწა გამოსაყენებელ მდგომარეობაში.

გავბრაზდი და შევხედე ჩადენის ისტორიას და დაწერილი კოდის რაოდენობას. მე ვუყურე მომენტებს, რომლებიც თავიდან კარგად იყო დაწერილი, შემდეგ კი გატეხილი...

გაიგეთ

სტატია გამახსენდა თქვენ არ ხართ Google.

მე ვფიქრობდი, რომ არავის ნამდვილად არ სჭირდება იდეა განხორციელების გარეშე. ვიფიქრე, რომ მინდა მქონდეს სამუშაო ბოტი, რომელიც იმუშავებს ერთ ეგზემპლარად ერთ კომპიუტერზე, როგორც მარტივი Java პროგრამა. ვიცი, რომ ჩემი ბოტი თვეების განმავლობაში იმუშავებს გადატვირთვის გარეშე, რადგან წარსულში უკვე დავწერე ასეთი ბოტები. თუ მოულოდნელად დაეცემა და მომხმარებელს სხვა სტატიას არ გაუგზავნის, ცა მიწაზე არ დაეცემა და არაფერი კატასტროფული არ მოხდება.

რატომ მჭირდება Docker, mongoDB და „სერიოზული“ პროგრამული უზრუნველყოფის სხვა სატვირთო კულტი, თუ კოდი უბრალოდ არ მუშაობს ან არასწორად მუშაობს?

პროექტი გავანადგურე და ყველაფერი ისე გავაკეთე, როგორც მინდოდა.

დაახლოებით იმავე პერიოდში შევცვალე სამსახური და თავისუფალი დრო ძალიან მაკლდა. დილით სწორედ მატარებელში გამეღვიძა, საღამოს გვიან დავბრუნდი და აღარ მინდოდა არაფრის გაკეთება. ცოტა ხანს არაფერი გამიკეთებია, მერე ბოტის დამთავრების სურვილმა დამამარცხა და დილაობით სამსახურში რომ მივდიოდი, კოდის ნელ-ნელა გადაწერა დავიწყე. მე არ ვიტყვი, რომ ეს იყო პროდუქტიული: რყევაზე მატარებელზე ჯდომა ლეპტოპით კალთაზე და ტელეფონზე დასტას ჭარბად ყურება არ არის ძალიან მოსახერხებელი. თუმცა, კოდის წერაზე დახარჯული დრო სრულიად შეუმჩნევლად გაფრინდა და პროექტმა ნელ-ნელა დაიწყო მუშაობა სამუშაო მდგომარეობისკენ.

სადღაც ჩემს გონებაში იყო ეჭვის ჭია, რომელსაც სურდა გამოეყენებინა mongoDB, მაგრამ მე ვფიქრობდი, რომ "სანდო" სახელმწიფო შენახვის უპირატესობების გარდა, იყო შესამჩნევი უარყოფითი მხარეები:

• მონაცემთა ბაზა ხდება წარუმატებლობის კიდევ ერთი წერტილი.
• კოდი უფრო რთული ხდება და მის დაწერას უფრო მეტი დრო დამჭირდება.
• კოდი ხდება ნელი და არაეფექტური; იმის ნაცვლად, რომ შეიცვალოს ობიექტი მეხსიერებაში, ცვლილებები იგზავნება მონაცემთა ბაზაში და საჭიროების შემთხვევაში უკან იხევს.
• არსებობს შეზღუდვები ცალკეულ ცხრილში მოვლენების შენახვის ტიპზე, რომლებიც დაკავშირებულია მონაცემთა ბაზის თავისებურებებთან.
• 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 მსახიობების მდგომარეობის აღსადგენად, მაგრამ ამჟამინდელი განხორციელება მაწყობს თავისი სიმარტივით. ეს არ არის ის, რომ ჩემი კოდი ხშირად იშლებოდა - პირიქით, საკმაოდ დიდ ძალისხმევას ვდებდი, რომ ეს შეუძლებელი ყოფილიყო. მაგრამ სისულელე ხდება და პროგრამის იზოლირებულ ნაწილებად-მსახიობებად დაყოფის შესაძლებლობა ჩემთვის ძალიან მოსახერხებელი და პრაქტიკული მეჩვენა.

წრე-ci დავამატე, რომ თუ კოდი გატყდა, მაშინვე გაიგოთ ამის შესახებ. მინიმუმ, ეს ნიშნავს, რომ კოდის შედგენა შეწყდა. თავდაპირველად მინდოდა ტრევისის დამატება, მაგრამ ის მხოლოდ ჩემს პროექტებს აჩვენებდა ჩანგლების გარეშე. ზოგადად, ორივე ამ ნივთის თავისუფლად გამოყენება შესაძლებელია ღია საცავებში.

შედეგები

უკვე ნოემბერია. ბოტი წერია, ბოლო ორი კვირაა ვიყენებ და მომეწონა. თუ გაუმჯობესების იდეა გაქვთ, დაწერეთ. მე ვერ ვხედავ აზრს მის მონეტიზაციაში - დაე, უბრალოდ იმუშაოს და გააგზავნე საინტერესო სტატიები.

ბოტის ლინკი: https://t.me/HabraFilterBot
Github: https://github.com/Kright/habrahabr_reader

მცირე დასკვნები:

• მცირე პროექტსაც კი შეიძლება დიდი დრო დასჭირდეს.
• თქვენ არ ხართ Google. ქვემეხიდან ბეღურების სროლას აზრი არ აქვს. მარტივი გამოსავალი შეიძლება ასევე იმუშაოს.
• შინაური ცხოველების პროექტები ძალიან კარგია ახალი ტექნოლოგიების ექსპერიმენტებისთვის.
• Telegram ბოტები იწერება საკმაოდ მარტივად. რომ არა "გუნდური მუშაობა" და ტექნოლოგიების ექსპერიმენტები, ბოტი ერთ-ორ კვირაში დაიწერებოდა.
• მსახიობის მოდელი არის საინტერესო რამ, რომელიც კარგად ეხამება მრავალ ნაკადს და შეცდომის შემწყნარებელ კოდს.
• ვფიქრობ, გავიგე, რატომ უყვარს ღია კოდის საზოგადოებას ჩანგლები.
• მონაცემთა ბაზები კარგია, რადგან განაცხადის მდგომარეობა აღარ არის დამოკიდებული აპლიკაციის ავარიაზე/გადატვირთვაზე, მაგრამ მონაცემთა ბაზასთან მუშაობა ართულებს კოდს და აწესებს შეზღუდვებს მონაცემთა სტრუქტურაზე.

წყარო: www.habr.com