บอทโทรเลขสำหรับการเลือกบทความส่วนตัวจาก Habr

สำหรับคำถามเช่น “ทำไม” มีบทความเก่ากว่า - Natural Geektimes - ทำให้พื้นที่สะอาดขึ้น.

มีบทความมากมายด้วยเหตุผลส่วนตัวบางบทความที่ฉันไม่ชอบและบางบทความก็น่าเสียดายที่ข้ามไป ฉันต้องการเพิ่มประสิทธิภาพกระบวนการนี้และประหยัดเวลา

บทความข้างต้นแนะนำแนวทางการเขียนสคริปต์ในเบราว์เซอร์ แต่ฉันไม่ชอบมันมากนัก (แม้ว่าฉันจะเคยใช้มาก่อนก็ตาม) ด้วยเหตุผลดังต่อไปนี้:

• สำหรับเบราว์เซอร์ที่แตกต่างกันบนคอมพิวเตอร์/โทรศัพท์ของคุณ คุณต้องกำหนดค่าอีกครั้ง หากเป็นไปได้
• การกรองอย่างเข้มงวดโดยผู้เขียนไม่สะดวกเสมอไป
• ปัญหาเกี่ยวกับผู้เขียนบทความที่คุณไม่อยากพลาดแม้ว่าจะตีพิมพ์ปีละครั้ง แต่ก็ยังไม่ได้รับการแก้ไข

การกรองที่สร้างไว้ในไซต์ตามการให้คะแนนบทความนั้นไม่สะดวกเสมอไป เนื่องจากบทความที่มีความเชี่ยวชาญสูง แม้จะมีคุณค่า แต่ก็สามารถได้รับคะแนนที่ค่อนข้างปานกลาง

ในตอนแรก ฉันต้องการสร้างฟีด RSS (หรือหลายรายการ) โดยเหลือเพียงสิ่งที่น่าสนใจเท่านั้น แต่สุดท้ายกลับกลายเป็นว่าการอ่าน RSS ดูเหมือนจะไม่สะดวกนัก ไม่ว่าในกรณีใด หากต้องการแสดงความคิดเห็น/โหวตบทความ/เพิ่มลงในรายการโปรด คุณจะต้องผ่านเบราว์เซอร์ นั่นเป็นเหตุผลที่ฉันเขียนบอทโทรเลขที่ส่งบทความที่น่าสนใจมาให้ฉันทางข้อความส่วนตัว ตัว Telegram เองก็แสดงตัวอย่างที่สวยงาม ซึ่งเมื่อรวมกับข้อมูลเกี่ยวกับผู้เขียน/การให้คะแนน/มุมมองแล้ว ก็ดูมีข้อมูลค่อนข้างมาก

ด้านล่างนี้เป็นรายละเอียดต่างๆ เช่น ลักษณะงาน ขั้นตอนการเขียน และแนวทางแก้ไขทางเทคนิค

สั้น ๆ เกี่ยวกับบอท

พื้นที่เก็บข้อมูล: https://github.com/Kright/habrahabr_reader

บอทในโทรเลข: https://t.me/HabraFilterBot

ผู้ใช้กำหนดคะแนนเพิ่มเติมสำหรับแท็กและผู้เขียน หลังจากนั้น ตัวกรองจะถูกนำไปใช้กับบทความ - การให้คะแนนของบทความเกี่ยวกับHabré การให้คะแนนของผู้ใช้ของผู้เขียน และคะแนนเฉลี่ยของผู้ใช้ตามแท็กจะถูกรวมเข้าด้วยกัน หากจำนวนเงินมากกว่าเกณฑ์ที่ผู้ใช้ระบุ บทความจะผ่านตัวกรอง

เป้าหมายด้านข้างของการเขียนบอทคือการได้รับความสนุกสนานและประสบการณ์ นอกจากนี้ฉันยังเตือนตัวเองอยู่เสมอว่า ฉันไม่ใช่ Googleดังนั้นหลายสิ่งหลายอย่างจึงทำอย่างเรียบง่ายและดั้งเดิมที่สุดเท่าที่จะเป็นไปได้ อย่างไรก็ตาม สิ่งนี้ไม่ได้ป้องกันกระบวนการเขียนบอทจากการใช้เวลาสามเดือน

มันเป็นฤดูร้อนข้างนอก

เดือนกรกฎาคมสิ้นสุดลงแล้ว และฉันตัดสินใจเขียนบอท และไม่ใช่คนเดียว แต่กับเพื่อนคนหนึ่งที่เชี่ยวชาญเรื่องสกาล่าและอยากเขียนอะไรบางอย่างลงไป จุดเริ่มต้นดูสดใส - ทีมจะตัดโค้ด งานดูเหมือนง่ายและฉันคิดว่าในอีกไม่กี่สัปดาห์หรือหนึ่งเดือน บอทจะพร้อม

แม้ว่าตัวฉันเองจะเขียนโค้ดบนพื้นฐานเป็นครั้งคราวในช่วงไม่กี่ปีที่ผ่านมา แต่ก็ไม่มีใครเห็นหรือดูโค้ดนี้: โปรเจ็กต์สัตว์เลี้ยง, การทดสอบแนวคิดบางอย่าง, การประมวลผลข้อมูลล่วงหน้า, การเรียนรู้แนวคิดบางอย่างจาก FP ฉันสนใจจริงๆ ว่าการเขียนโค้ดในทีมจะเป็นอย่างไร เพราะโค้ดธรรมดาสามารถเขียนได้หลายวิธี

อะไรได้หายไป ดังนั้น? อย่างไรก็ตาม อย่าเพิ่งรีบร้อนไป
ทุกสิ่งที่เกิดขึ้นสามารถติดตามได้โดยใช้ประวัติการคอมมิต

คนรู้จักสร้าง repository เมื่อวันที่ 27 กรกฎาคม แต่ไม่ได้ทำอะไรเลย เลยเริ่มเขียนโค้ด

กรกฎาคม 30

โดยย่อ: ฉันเขียนการแยกวิเคราะห์ฟีด rss ของ Habr

• com.github.pureconfig สำหรับการอ่านการกำหนดค่า typesafe โดยตรงในคลาสเคส (สะดวกมาก)
• scala-xml สำหรับการอ่าน xml: เนื่องจากในตอนแรกฉันต้องการเขียนการใช้งานของตนเองสำหรับฟีด rss และฟีด rss อยู่ในรูปแบบ 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é

ในความเป็นจริง แนวคิดนี้ง่ายมาก - เรามีตัวนับที่เปลี่ยนแปลงอย่างซ้ำซากจำเจ จำนวนโปรโมชันค่อยๆ เพิ่มขึ้น เช่นเดียวกับจำนวนข้อดี (รวมถึงจำนวนข้อเสีย) หากฉันมีข้อมูลสองเวอร์ชันเกี่ยวกับบทความหนึ่ง ๆ ฉันสามารถ "รวมเป็นหนึ่งเดียว" ได้ - สถานะของตัวนับที่ใหญ่กว่าจะถือว่ามีความเกี่ยวข้องมากกว่า

กลุ่มกึ่งหมายความว่าสามารถรวมวัตถุสองรายการที่มีข้อมูลเกี่ยวกับบทความเป็นหนึ่งเดียวได้ การสับเปลี่ยนหมายความว่าคุณสามารถรวมทั้ง A + B และ B + A ได้ ผลลัพธ์ไม่ได้ขึ้นอยู่กับลำดับ และในท้ายที่สุดเวอร์ชันใหม่ล่าสุดจะยังคงอยู่ โดยวิธีการนี้ยังมีความเชื่อมโยงที่นี่

ตัวอย่างเช่น ตามที่วางแผนไว้ rss หลังจากการแยกวิเคราะห์ให้ข้อมูลที่อ่อนแอเล็กน้อยเกี่ยวกับบทความ - โดยไม่มีตัวชี้วัด เช่น จำนวนการดู จากนั้นนักแสดงพิเศษก็นำข้อมูลเกี่ยวกับบทความและวิ่งไปที่หน้า html เพื่ออัปเดตและรวมเข้ากับเวอร์ชันเก่า

โดยทั่วไปแล้วเช่นเดียวกับใน akka ไม่จำเป็นต้องทำเช่นนี้คุณสามารถจัดเก็บ updateDate สำหรับบทความและนำบทความใหม่มาใช้โดยไม่ต้องรวมเข้าด้วยกัน แต่ถนนแห่งการผจญภัยพาฉันไป

12 สิงหาคม

ฉันเริ่มรู้สึกมีอิสระมากขึ้น และเพื่อความสนุกสนาน ฉันจึงทำให้แต่ละแชทมีนักแสดงแยกกัน ตามทฤษฎีแล้ว ตัวนักแสดงมีน้ำหนักประมาณ 300 ไบต์และสามารถสร้างได้เป็นล้าน ดังนั้นนี่จึงเป็นเรื่องปกติ สำหรับฉันดูเหมือนว่าวิธีแก้ปัญหานั้นค่อนข้างน่าสนใจ:

นักแสดงคนหนึ่งเป็นสะพานเชื่อมระหว่างเซิร์ฟเวอร์โทรเลขและระบบข้อความในอักกะ เขาเพียงแค่ได้รับข้อความและส่งไปยังนักแสดงแชทที่ต้องการ ผู้ดำเนินการแชทสามารถส่งบางสิ่งกลับมาเพื่อเป็นการตอบกลับ และมันจะถูกส่งกลับไปยังโทรเลข สิ่งที่สะดวกมากคือนักแสดงคนนี้กลายเป็นเรื่องง่ายที่สุดเท่าที่จะเป็นไปได้และมีเพียงตรรกะในการตอบกลับข้อความเท่านั้น อย่างไรก็ตาม ทุกครั้งที่แชทมีข้อมูลเกี่ยวกับบทความใหม่ แต่ฉันไม่เห็นปัญหาใด ๆ ในเรื่องนี้

โดยทั่วไปบอทกำลังทำงานอยู่แล้ว ตอบข้อความ เก็บรายการบทความที่ส่งถึงผู้ใช้ และผมคิดว่าบอทเกือบจะพร้อมแล้ว ฉันค่อยๆ เพิ่มคุณสมบัติเล็กๆ น้อยๆ เช่น การทำให้ชื่อผู้แต่งและแท็กเป็นมาตรฐาน (แทนที่ “sd f” ด้วย “s_d_f”)

เหลือเพียงสิ่งเดียวเท่านั้น เล็กแต่ — รัฐไม่ได้รับการบันทึกไว้ที่ไหนเลย

ทุกอย่างผิดพลาดไป

คุณอาจสังเกตเห็นว่าฉันเขียนบอทโดยลำพังเป็นส่วนใหญ่ ดังนั้น ผู้เข้าร่วมคนที่สองจึงมีส่วนร่วมในการพัฒนา และการเปลี่ยนแปลงต่อไปนี้ปรากฏในโค้ด:

• MongoDB ดูเหมือนจะจัดเก็บสถานะ ในเวลาเดียวกัน บันทึกในโปรเจ็กต์เสียหาย เนื่องจาก Monga เริ่มส่งสแปมด้วยเหตุผลบางอย่าง และบางคนก็ปิดบันทึกทั่วโลก
• นักแสดงสะพานใน Telegram เปลี่ยนไปจนจำไม่ได้และเริ่มแยกวิเคราะห์ข้อความด้วยตัวเอง
• นักแสดงสำหรับการสนทนาถูกตัดออกอย่างไร้ความปราณี และถูกแทนที่ด้วยนักแสดงที่ซ่อนข้อมูลทั้งหมดเกี่ยวกับการแชททั้งหมดในคราวเดียว ทุกครั้งที่จามนักแสดงคนนี้ก็ประสบปัญหา ใช่ เช่นเดียวกับเมื่ออัปเดตข้อมูลเกี่ยวกับบทความ การส่งไปยังผู้แชททุกคนเป็นเรื่องยาก (เราก็เหมือนกับ Google ผู้ใช้หลายล้านคนกำลังรอบทความนับล้านบทความในแชทสำหรับแต่ละบทความ) แต่ทุกครั้งที่อัปเดตแชท เป็นเรื่องปกติที่จะเข้าไปใน Monga เมื่อฉันตระหนักได้ในภายหลัง ตรรกะการทำงานของการแชทก็ถูกตัดออกไปโดยสิ้นเชิงและมีบางอย่างที่ใช้งานไม่ได้ปรากฏขึ้นแทนที่
• ไม่มีร่องรอยของคลาสประเภทเหลืออยู่
• ตรรกะที่ไม่ดีต่อสุขภาพบางอย่างปรากฏขึ้นในตัวนักแสดงพร้อมกับการสมัครรับข่าวสารซึ่งกันและกัน ซึ่งนำไปสู่สภาพการแข่งขัน
• โครงสร้างข้อมูลที่มีประเภทฟิลด์ Option[Int] กลายเป็น Int ด้วยค่าเริ่มต้นที่น่าอัศจรรย์เช่น -1 ต่อมาฉันก็รู้ว่า mongoDB เก็บ json ไว้และไม่มีอะไรผิดที่จะเก็บไว้ที่นั่น Option หรืออย่างน้อยก็แยกวิเคราะห์ -1 เป็นไม่มี แต่ในเวลานั้นฉันไม่รู้เรื่องนี้และรับคำพูดของฉันว่า "มันควรจะเป็นอย่างนั้น" ฉันไม่ได้เขียนโค้ดนั้น และฉันก็ไม่อยากเปลี่ยนมันในตอนนี้
• ฉันพบว่าที่อยู่ IP สาธารณะของฉันมีแนวโน้มที่จะเปลี่ยนแปลง และทุกครั้งที่ฉันต้องเพิ่มมันเข้าไปในไวท์ลิสต์ของ Mongo ฉันเปิดตัวบอทในพื้นที่ Monga อยู่ที่ไหนสักแห่งบนเซิร์ฟเวอร์ของ Monga ในฐานะบริษัท
• ทันใดนั้นการทำให้แท็กและการจัดรูปแบบข้อความเป็นมาตรฐานสำหรับโทรเลขก็หายไป (อืม ทำไมจะเป็นเช่นนั้น?)
• ฉันชอบที่สถานะของบอทถูกจัดเก็บไว้ในฐานข้อมูลภายนอก และเมื่อรีสตาร์ท บอทจะยังคงทำงานราวกับว่าไม่มีอะไรเกิดขึ้น อย่างไรก็ตาม นี่เป็นข้อดีเพียงอย่างเดียว

คนที่สองไม่ได้รีบร้อนมากนัก และการเปลี่ยนแปลงทั้งหมดนี้ก็ปรากฏในกองใหญ่ก้อนเดียวเมื่อต้นเดือนกันยายน ฉันไม่ได้ชื่นชมขนาดของการทำลายล้างที่เกิดขึ้นในทันที และเริ่มเข้าใจการทำงานของฐานข้อมูล เพราะ... ฉันไม่เคยจัดการกับพวกเขามาก่อน หลังจากนั้นฉันก็รู้ว่าโค้ดที่ใช้งานได้ถูกตัดไปมากขนาดไหนและมีข้อบกพร่องจำนวนเท่าใดที่ถูกเพิ่มเข้ามาแทนที่

กันยายน

ตอนแรกฉันคิดว่ามันจะเป็นประโยชน์กับนาย Monga และทำมันให้ดี จากนั้นฉันก็เริ่มเข้าใจอย่างช้าๆ ว่าการจัดการสื่อสารกับฐานข้อมูลก็เป็นศิลปะที่คุณสามารถลงแข่งได้มากมายแต่ก็ทำผิดพลาดได้ เช่น หากผู้ใช้ได้รับข้อความสองข้อความดังกล่าว /subscribe - และเพื่อตอบสนองต่อแต่ละรายการ เราจะสร้างรายการในตาราง เนื่องจากในขณะที่ประมวลผลข้อความเหล่านั้น ผู้ใช้ไม่ได้สมัครรับข้อมูล ฉันสงสัยว่าการสื่อสารกับ Monga ในรูปแบบปัจจุบันนั้นไม่ได้เขียนด้วยวิธีที่ดีที่สุด ตัวอย่างเช่น การตั้งค่าของผู้ใช้ถูกสร้างขึ้นในขณะที่เขาสมัครใช้งาน หากเขาพยายามเปลี่ยนก่อนที่จะสมัครสมาชิก... บอทไม่ตอบสนองอะไรเลย เนื่องจากโค้ดในนักแสดงเข้าไปในฐานข้อมูลสำหรับการตั้งค่า ไม่พบมันและล้มเหลว เมื่อถูกถามว่าทำไมไม่สร้างการตั้งค่าตามที่จำเป็น ฉันได้เรียนรู้ว่าไม่จำเป็นต้องเปลี่ยนการตั้งค่าเหล่านี้หากผู้ใช้ไม่ได้สมัครรับข้อมูล... ระบบกรองข้อความถูกสร้างขึ้นมาอย่างไม่ชัดเจน และแม้กระทั่งหลังจากดูโค้ดอย่างใกล้ชิดแล้ว ฉันก็ทำได้ ไม่เข้าใจว่ามันตั้งใจแบบนี้ตั้งแต่แรกหรือมีข้อผิดพลาดเกิดขึ้น

ไม่มีรายการบทความที่ส่งไปยังแชท แต่แนะนำให้ฉันเขียนเอง สิ่งนี้ทำให้ฉันประหลาดใจ - โดยทั่วไปแล้วฉันไม่ได้ต่อต้านการลากสิ่งต่าง ๆ เข้ามาในโปรเจ็กต์ แต่มันจะสมเหตุสมผลสำหรับผู้ที่นำสิ่งเหล่านี้เข้ามาและทำมันพัง แต่ไม่ ผู้เข้าร่วมคนที่สองดูเหมือนจะยอมแพ้กับทุกสิ่ง แต่บอกว่ารายการภายในแชทน่าจะเป็นวิธีแก้ปัญหาที่ไม่ดี และจำเป็นต้องทำเครื่องหมายด้วยเหตุการณ์เช่น “บทความ y ถูกส่งไปยังผู้ใช้ x” จากนั้นหากผู้ใช้ขอส่งบทความใหม่ก็จำเป็นต้องส่งคำขอไปยังฐานข้อมูลซึ่งจะเลือกเหตุการณ์ที่เกี่ยวข้องกับผู้ใช้จากเหตุการณ์นั้นด้วย รับรายการบทความใหม่ กรอง ส่งให้กับผู้ใช้ และโยนเหตุการณ์เกี่ยวกับเรื่องนี้กลับเข้าไปในฐานข้อมูล

ผู้เข้าร่วมคนที่สองถูกพาไปยังจุดที่เป็นนามธรรม เมื่อบอทไม่เพียงได้รับบทความจาก Habr และไม่เพียงแต่ส่งไปยังโทรเลขเท่านั้น

ฉันจัดกิจกรรมในรูปแบบป้ายแยกต่างหากในช่วงครึ่งหลังของเดือนกันยายน มันไม่เหมาะสม แต่อย่างน้อยบอทก็เริ่มทำงานและเริ่มส่งบทความมาให้ฉันอีกครั้ง และฉันก็ค่อยๆ คิดออกว่าเกิดอะไรขึ้นในโค้ด

ตอนนี้คุณสามารถกลับไปที่จุดเริ่มต้นและจำไว้ว่าฉันไม่ได้สร้างพื้นที่เก็บข้อมูลตั้งแต่แรก อะไรจะผ่านไปได้ขนาดนี้? คำขอดึงของฉันถูกปฏิเสธ ปรากฎว่าฉันมีโค้ดใจแคบ ฉันไม่รู้วิธีการทำงานเป็นทีม และฉันต้องแก้ไขข้อบกพร่องในเส้นโค้งการใช้งานปัจจุบัน และไม่ปรับแต่งให้เป็นสถานะที่ใช้งานได้

ฉันอารมณ์เสียและได้ดูประวัติการคอมมิตและจำนวนโค้ดที่เขียน ฉันดูช่วงเวลาที่เดิมเขียนได้ดีแล้วจึงพังทลายลง...

ไอ้นี่มัน

ฉันจำบทความได้ คุณไม่ใช่ Google.

ฉันคิดว่าไม่มีใครต้องการแนวคิดจริงๆ หากไม่มีการปฏิบัติ ฉันคิดว่าฉันต้องการมีบอทที่ใช้งานได้ซึ่งจะทำงานในสำเนาเดียวบนคอมพิวเตอร์เครื่องเดียวในรูปแบบโปรแกรมจาวาธรรมดา ฉันรู้ว่าบอทของฉันจะทำงานเป็นเวลาหลายเดือนโดยไม่ต้องรีสตาร์ท เนื่องจากฉันเคยเขียนบอทประเภทนี้มาก่อน หากจู่ๆ ตกลงมาและไม่ส่งสิ่งของให้ผู้ใช้อีก ท้องฟ้าก็จะไม่ตกลงสู่พื้นและจะไม่มีภัยพิบัติใดเกิดขึ้น

เหตุใดฉันจึงต้องมี Docker, mongoDB และลัทธิการขนส่งสินค้าอื่น ๆ ที่เป็นซอฟต์แวร์ "ร้ายแรง" หากโค้ดใช้งานไม่ได้หรือทำงานคดโกง

ฉันแยกโครงการและทำทุกอย่างตามที่ฉันต้องการ

ในช่วงเวลาเดียวกัน ฉันเปลี่ยนงานและเวลาว่างก็ลดลงอย่างมาก ในตอนเช้าฉันตื่นขึ้นมาบนรถไฟ ตอนเย็นฉันกลับมาสายและไม่อยากทำอะไรอีกต่อไป ฉันไม่ได้ทำอะไรเลยสักระยะหนึ่ง จากนั้นความปรารถนาที่จะทำให้บอทเสร็จสิ้นก็ครอบงำฉัน และฉันก็เริ่มเขียนโค้ดใหม่อย่างช้าๆ ในขณะที่ฉันกำลังขับรถไปทำงานในตอนเช้า ฉันจะไม่บอกว่ามันได้ผล: การนั่งบนรถไฟที่กำลังสั่นโดยมีแล็ปท็อปอยู่บนตักและการดูกองซ้อนจากโทรศัพท์ของคุณนั้นไม่สะดวก อย่างไรก็ตาม เวลาที่ใช้ในการเขียนโค้ดผ่านไปอย่างรวดเร็วโดยไม่มีใครสังเกตเห็น และโปรเจ็กต์ก็เริ่มค่อยๆ เคลื่อนไปสู่สถานะการทำงาน

มีหนอนแห่งความสงสัยอยู่ในใจฉันว่าต้องการใช้ mongoDB แต่ฉันคิดว่านอกเหนือจากข้อดีของการจัดเก็บสถานะ "เชื่อถือได้" แล้ว ยังมีข้อเสียที่เห็นได้ชัดเจนอีกด้วย:

• ฐานข้อมูลกลายเป็นอีกจุดหนึ่งของความล้มเหลว
• โค้ดมีความซับซ้อนมากขึ้น และฉันจะใช้เวลาเขียนนานขึ้น
• รหัสทำงานช้าและไม่มีประสิทธิภาพ แทนที่จะเปลี่ยนวัตถุในหน่วยความจำ การเปลี่ยนแปลงจะถูกส่งไปยังฐานข้อมูล และหากจำเป็น จะถูกดึงกลับ
• มีข้อจำกัดเกี่ยวกับประเภทของการจัดเก็บเหตุการณ์ในตารางแยกต่างหากซึ่งเกี่ยวข้องกับลักษณะเฉพาะของฐานข้อมูล
• Monga เวอร์ชันทดลองมีข้อจำกัดบางประการ และหากคุณพบปัญหาดังกล่าว คุณจะต้องเปิดและกำหนดค่า 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 หรือสมัครรับข้อมูลจากบอท จากนั้นบอทจะส่งบทความเป็นข้อความส่วนตัวได้ตลอดเวลาของวัน

โดยทั่วไปแล้ว ฉันมีแนวคิดสำหรับแต่ละบทความที่จะดึงคุณสมบัติเพิ่มเติมออกมา (ฮับ จำนวนความคิดเห็น บุ๊กมาร์ก การเปลี่ยนแปลงการให้คะแนนแบบไดนามิก จำนวนข้อความ รูปภาพและรหัสในบทความ คำสำคัญ) และแสดงให้ผู้ใช้เห็นว่าตกลง/ ไม่โอเค โหวตในแต่ละบทความและฝึกโมเดลสำหรับผู้ใช้แต่ละคน แต่ฉันขี้เกียจเกินไป

นอกจากนี้ตรรกะของงานจะไม่ชัดเจนนัก ตอนนี้ฉันสามารถตั้งค่าเรตติ้งเป็น +9000 สำหรับ PatientZero ด้วยตนเองได้ และด้วยเรตติ้งตามเกณฑ์ +20 ฉันรับประกันว่าจะได้รับบทความทั้งหมดของเขา (เว้นแต่ฉันจะตั้งค่า -100500 สำหรับบางแท็ก)

สถาปัตยกรรมขั้นสุดท้ายกลายเป็นเรื่องง่าย:

1. นักแสดงที่เก็บสถานะของการสนทนาและบทความทั้งหมด โดยจะโหลดสถานะจากไฟล์บนดิสก์และบันทึกกลับเป็นไฟล์ใหม่เป็นครั้งคราว
2. นักแสดงที่เข้าชมฟีด RSS เป็นครั้งคราว เรียนรู้เกี่ยวกับบทความใหม่ ดูลิงก์ แยกวิเคราะห์ และส่งบทความเหล่านี้ไปยังนักแสดงคนแรก นอกจากนี้บางครั้งยังขอรายชื่อบทความจากนักแสดงคนแรก เลือกบทความที่อายุไม่เกิน XNUMX วัน แต่ไม่ได้อัพเดตมานานและอัพเดตอีกด้วย
3. นักแสดงที่สื่อสารด้วยโทรเลข ฉันยังคงนำข้อความแยกวิเคราะห์อย่างสมบูรณ์มาที่นี่ ด้วยวิธีที่เป็นมิตร ฉันอยากจะแบ่งออกเป็นสองส่วน - เพื่อให้อันหนึ่งแยกวิเคราะห์ข้อความขาเข้า และอันที่สองจัดการกับปัญหาการขนส่ง เช่น การส่งข้อความที่ยังไม่ได้ส่งซ้ำ ขณะนี้ไม่มีการส่งซ้ำและข้อความที่ไม่ได้รับเนื่องจากข้อผิดพลาดจะหายไป (เว้นแต่จะระบุไว้ในบันทึก) แต่จนถึงขณะนี้ยังไม่ทำให้เกิดปัญหาใดๆ บางทีปัญหาจะเกิดขึ้นหากมีคนจำนวนมากสมัครใช้งานบอทและฉันถึงขีดจำกัดในการส่งข้อความ)

สิ่งที่ฉันชอบคือต้องขอบคุณ Akka โดยทั่วไปแล้วการล่มสลายของนักแสดง 2 และ 3 จะไม่ส่งผลกระทบต่อประสิทธิภาพของบอท บางทีบทความบางบทความอาจไม่ได้รับการอัปเดตตรงเวลาหรือบางข้อความไปไม่ถึงโทรเลข แต่บัญชีจะรีสตาร์ทนักแสดงและทุกอย่างยังคงทำงานต่อไป ฉันบันทึกข้อมูลที่บทความนี้แสดงต่อผู้ใช้เฉพาะเมื่อนักแสดงโทรเลขตอบกลับว่าเขาส่งข้อความสำเร็จแล้วเท่านั้น สิ่งที่แย่ที่สุดที่คุกคามฉันคือการส่งข้อความหลายครั้ง (หากถูกส่งไปแล้ว แต่การยืนยันสูญหายไป) โดยหลักการแล้ว หากนักแสดงคนแรกไม่ได้เก็บสถานะไว้ในตัวเขาเอง แต่สื่อสารกับฐานข้อมูลบางอย่าง เขาก็จะล้มลงและกลับมามีชีวิตอีกครั้งโดยไม่รู้สึกตัว ฉันยังสามารถลองใช้ความพากเพียรของ Akka เพื่อฟื้นฟูสถานะของนักแสดงได้ แต่การใช้งานในปัจจุบันเหมาะกับฉันด้วยความเรียบง่าย ไม่ใช่ว่าโค้ดของฉันขัดข้องบ่อยครั้ง - ในทางกลับกัน ฉันใช้ความพยายามอย่างมากในการทำให้มันเป็นไปไม่ได้ แต่เรื่องไร้สาระเกิดขึ้น และความสามารถในการแบ่งรายการออกเป็นนักแสดงแยกส่วนก็ดูสะดวกและใช้งานได้จริงสำหรับฉัน

ฉันได้เพิ่มวงกลม-ci เพื่อที่ว่าถ้าโค้ดแตก คุณจะพบมันทันที อย่างน้อยก็หมายความว่าโค้ดได้หยุดการคอมไพล์แล้ว ตอนแรกฉันต้องการเพิ่ม Travis แต่มันแสดงเฉพาะโปรเจ็กต์ของฉันที่ไม่มีส้อม โดยทั่วไป ทั้งสองสิ่งนี้สามารถนำไปใช้ได้อย่างอิสระในที่เก็บข้อมูลแบบเปิด

ผลของการ

เดือนพฤศจิกายนแล้ว บอทเขียนขึ้น ฉันใช้มันมาสองสัปดาห์ที่ผ่านมาและฉันชอบมัน หากคุณมีแนวคิดในการปรับปรุงให้เขียน ฉันไม่เห็นประเด็นในการสร้างรายได้ ปล่อยให้มันใช้งานได้และส่งบทความที่น่าสนใจ

ลิงค์บอท: https://t.me/HabraFilterBot
GitHub: https://github.com/Kright/habrahabr_reader

ข้อสรุปเล็กๆ น้อยๆ:

• แม้แต่โครงการขนาดเล็กก็สามารถใช้เวลานานได้
• คุณไม่ใช่ Google ไม่มีประโยชน์ที่จะยิงนกกระจอกจากปืนใหญ่ วิธีแก้ปัญหาง่ายๆ ก็อาจใช้ได้ผลเช่นกัน
• โครงการสัตว์เลี้ยงเป็นสิ่งที่ดีมากสำหรับการทดลองเทคโนโลยีใหม่ ๆ
• บอทโทรเลขเขียนค่อนข้างง่าย ถ้าไม่ใช่เพราะ "การทำงานเป็นทีม" และการทดลองใช้เทคโนโลยี บอทคงจะเขียนเสร็จภายในหนึ่งหรือสองสัปดาห์
• โมเดลนักแสดงเป็นสิ่งที่น่าสนใจซึ่งเข้ากันได้ดีกับโค้ดแบบมัลติเธรดและทนต่อข้อผิดพลาด
• ฉันคิดว่าฉันเข้าใจแล้วว่าเหตุใดชุมชนโอเพ่นซอร์สจึงชอบส้อม
• ฐานข้อมูลนั้นดีเพราะสถานะของแอปพลิเคชันไม่ขึ้นอยู่กับการหยุดทำงาน/การรีสตาร์ทของแอปพลิเคชันอีกต่อไป แต่การทำงานกับฐานข้อมูลจะทำให้โค้ดซับซ้อนและกำหนดข้อจำกัดในโครงสร้างข้อมูล

ที่มา: will.com