Đối với những câu hỏi như “tại sao?” có một bài viết cũ hơn - .
Có rất nhiều bài, vì lý do chủ quan, có bài tôi không thích, có bài ngược lại, bỏ qua thật đáng tiếc. Tôi muốn tối ưu hóa quá trình này và tiết kiệm thời gian.
Bài viết trên đề xuất một cách tiếp cận viết kịch bản trên trình duyệt, nhưng tôi không thực sự thích nó (mặc dù tôi đã từng sử dụng nó trước đây) vì những lý do sau:
- Đối với các trình duyệt khác nhau trên máy tính/điện thoại của bạn, bạn phải định cấu hình lại trình duyệt đó, nếu có thể.
- Việc lọc nghiêm ngặt theo tác giả không phải lúc nào cũng thuận tiện.
- Vấn đề với những tác giả có bài viết mà bạn không muốn bỏ lỡ, dù chúng được xuất bản mỗi năm một lần, vẫn chưa được giải quyết.
Tính năng lọc được tích hợp vào trang web dựa trên xếp hạng bài viết không phải lúc nào cũng thuận tiện, vì các bài viết có tính chuyên môn cao, mặc dù có giá trị nhưng có thể nhận được xếp hạng khá khiêm tốn.
Ban đầu, tôi muốn tạo một nguồn cấp dữ liệu RSS (hoặc thậm chí một vài nguồn), chỉ để lại những điều thú vị ở đó. Nhưng cuối cùng, hóa ra việc đọc RSS có vẻ không thuận tiện lắm: trong mọi trường hợp, để bình luận/bình chọn cho một bài viết/thêm nó vào mục yêu thích, bạn phải thông qua trình duyệt. Đó là lý do tại sao tôi đã viết một bot điện tín gửi những bài viết thú vị cho tôi qua tin nhắn cá nhân. Bản thân Telegram tạo ra những bản xem trước đẹp mắt về chúng, kết hợp với thông tin về tác giả/xếp hạng/lượt xem, trông khá nhiều thông tin.
Bên dưới phần cắt là các chi tiết như đặc điểm tác phẩm, quy trình viết và giải pháp kỹ thuật.
Nói ngắn gọn về bot
Kho:
Bot trong điện tín:
Người dùng đặt xếp hạng bổ sung cho thẻ và tác giả. Sau đó, một bộ lọc được áp dụng cho các bài viết - xếp hạng của bài viết trên Habré, xếp hạng người dùng của tác giả và xếp hạng trung bình của người dùng theo thẻ được cộng lại. Nếu số lượng lớn hơn ngưỡng do người dùng chỉ định thì bài viết sẽ vượt qua bộ lọc.
Mục tiêu phụ của việc viết bot là để có được niềm vui và trải nghiệm. Ngoài ra, tôi thường xuyên nhắc nhở bản thân rằng , và do đó nhiều việc được thực hiện một cách đơn giản và thậm chí nguyên thủy nhất có thể. Tuy nhiên, điều này không ngăn cản quá trình viết bot kéo dài ba tháng.
Bên ngoài đang là mùa hè
Tháng 7 sắp kết thúc và tôi quyết định viết bot. Và không phải một mình, mà với một người bạn đang thành thạo scala và muốn viết điều gì đó trên đó. Sự khởi đầu có vẻ đầy hứa hẹn - một nhóm sẽ cắt mã, nhiệm vụ có vẻ dễ dàng và tôi nghĩ rằng trong vài tuần hoặc một tháng nữa bot sẽ sẵn sàng.
Mặc dù thực tế là bản thân tôi thỉnh thoảng đã viết mã trên đá trong vài năm qua, nhưng không ai thường nhìn thấy hoặc xem xét mã này: các dự án thú cưng, thử nghiệm một số ý tưởng, xử lý trước dữ liệu, nắm vững một số khái niệm từ FP. Tôi thực sự quan tâm đến việc viết mã trong một nhóm sẽ như thế nào, bởi vì mã trên rock có thể được viết theo những cách rất khác nhau.
Điều gì có thể đã xảy ra để? Tuy nhiên, chúng ta đừng vội vàng.
Mọi thứ xảy ra đều có thể được theo dõi bằng lịch sử cam kết.
Một người quen đã tạo một kho lưu trữ vào ngày 27 tháng XNUMX, nhưng không làm gì khác nên tôi bắt đầu viết mã.
30 tháng bảy
Tóm lại: Tôi đã viết một bản phân tích nguồn cấp dữ liệu rss của Habr.
com.github.pureconfigđể đọc các cấu hình an toàn kiểu trực tiếp vào các lớp trường hợp (hóa ra nó rất thuận tiện)scala-xmlđể đọc xml: vì ban đầu tôi muốn viết phần triển khai của riêng mình cho nguồn cấp dữ liệu rss và nguồn cấp dữ liệu rss có định dạng xml nên tôi đã sử dụng thư viện này để phân tích cú pháp. Trên thực tế, tính năng phân tích RSS cũng đã xuất hiện.scalatestcho các bài kiểm tra. Ngay cả đối với các dự án nhỏ, việc viết bài kiểm tra sẽ tiết kiệm thời gian - ví dụ: khi gỡ lỗi phân tích cú pháp xml, việc tải nó xuống một tệp, viết bài kiểm tra và sửa lỗi sẽ dễ dàng hơn nhiều. Sau đó, khi một lỗi xuất hiện với việc phân tích cú pháp một số html lạ với các ký tự utf-8 không hợp lệ, hóa ra sẽ thuận tiện hơn nếu đặt nó vào một tệp và thêm một bài kiểm tra.- diễn viên từ Akka. Về mặt khách quan, chúng không cần thiết chút nào, nhưng dự án được viết cho vui, tôi muốn thử chúng. Kết quả là tôi sẵn sàng nói rằng tôi thích nó. Ý tưởng về OOP có thể được nhìn từ phía bên kia - có những tác nhân trao đổi tin nhắn. Điều thú vị hơn là bạn có thể (và nên) viết mã theo cách sao cho tin nhắn có thể không đến hoặc không được xử lý (nói chung, khi tài khoản đang chạy trên một máy tính, tin nhắn sẽ không bị mất). Lúc đầu, tôi gãi đầu và thấy có một đoạn mã rác rưởi với các diễn viên đăng ký với nhau, nhưng cuối cùng tôi đã nghĩ ra được một kiến trúc khá đơn giản và trang nhã. Mã bên trong mỗi tác nhân có thể được coi là một luồng; khi một tác nhân gặp sự cố, acca sẽ khởi động lại nó - kết quả là một hệ thống có khả năng chịu lỗi khá tốt.
9 Tháng Tám
Tôi đã thêm vào dự án scala-scrapper để phân tích các trang html từ Habr (để lấy ra thông tin như xếp hạng bài viết, số lượng dấu trang, v.v.).
Và Mèo. Những cái ở trong đá.
Sau đó tôi đọc một cuốn sách về cơ sở dữ liệu phân tán, tôi thích ý tưởng về CRDT (Loại dữ liệu được sao chép không xung đột, , ), nên tôi đã đăng một lớp kiểu của nửa nhóm giao hoán để biết thông tin về bài viết trên Habré.
Trên thực tế, ý tưởng rất đơn giản - chúng ta có các bộ đếm thay đổi đơn điệu. Số lượng khuyến mãi đang dần tăng lên, cũng như số điểm cộng (cũng như số điểm trừ). Nếu tôi có hai phiên bản thông tin về một bài viết, thì tôi có thể “hợp nhất chúng thành một” - trạng thái của bộ đếm lớn hơn được coi là phù hợp hơn.
Nửa nhóm có nghĩa là hai đối tượng có thông tin về một bài viết có thể được hợp nhất thành một. Giao hoán có nghĩa là bạn có thể hợp nhất cả A + B và B + A, kết quả không phụ thuộc vào thứ tự và cuối cùng phiên bản mới nhất sẽ vẫn còn. Nhân tiện, ở đây cũng có sự liên tưởng.
Ví dụ: theo kế hoạch, rss sau khi phân tích cú pháp đã cung cấp thông tin hơi yếu về bài viết - không có số liệu như số lượt xem. Sau đó, một diễn viên đặc biệt lấy thông tin về các bài viết và chạy đến các trang html để cập nhật và hợp nhất với phiên bản cũ.
Nói chung, như trong akka, không cần điều này, bạn có thể chỉ cần lưu trữ updateDate cho bài viết và lấy một bài viết mới hơn mà không cần hợp nhất, nhưng con đường phiêu lưu đã dẫn tôi đến.
12 Tháng Tám
Tôi bắt đầu cảm thấy tự do hơn và chỉ để cho vui, tôi biến mỗi cuộc trò chuyện thành một diễn viên riêng. Về mặt lý thuyết, bản thân một diễn viên nặng khoảng 300 byte và chúng có thể được tạo ra hàng triệu byte, vì vậy đây là một cách tiếp cận hoàn toàn bình thường. Đối với tôi, có vẻ như giải pháp này khá thú vị:
Một diễn viên là cầu nối giữa máy chủ điện tín và hệ thống tin nhắn ở Akka. Anh ấy chỉ đơn giản nhận tin nhắn và gửi chúng đến diễn viên trò chuyện mong muốn. Tác nhân trò chuyện có thể gửi lại thứ gì đó để phản hồi - và nó sẽ được gửi lại vào bức điện. Điều rất thuận tiện là diễn viên này hóa ra đơn giản nhất có thể và chỉ chứa logic để trả lời tin nhắn. Nhân tiện, thông tin về các bài viết mới đều xuất hiện trong mỗi cuộc trò chuyện, nhưng một lần nữa tôi không thấy bất kỳ vấn đề nào trong việc này.
Nói chung, bot đã hoạt động, trả lời tin nhắn, lưu trữ danh sách các bài báo được gửi cho người dùng và tôi đã nghĩ rằng bot gần như đã sẵn sàng. Tôi dần dần thêm các tính năng nhỏ như bình thường hóa tên tác giả và thẻ (thay thế “s.d f” bằng “s_d_f”).
Chỉ còn lại một điều nhỏ nhưng — trạng thái không được lưu ở bất cứ đâu.
Mọi thứ đều không ổn
Bạn có thể nhận thấy rằng tôi chủ yếu viết bot một mình. Vì vậy, người tham gia thứ hai đã tham gia vào quá trình phát triển và những thay đổi sau đã xuất hiện trong mã:
- MongoDB xuất hiện để lưu trữ trạng thái. Đồng thời, nhật ký trong dự án đã bị hỏng, vì lý do nào đó Monga bắt đầu gửi thư rác cho chúng và một số người chỉ đơn giản là tắt chúng trên toàn cầu.
- Diễn viên cầu nối trong Telegram đã bị biến đổi đến mức không thể nhận ra và bắt đầu tự mình phân tích tin nhắn.
- Diễn viên cho các cuộc trò chuyện đã bị cắt bỏ không thương tiếc, thay vào đó họ được thay thế bằng một diễn viên đã che giấu tất cả thông tin về tất cả các cuộc trò chuyện cùng một lúc. Cứ mỗi lần hắt hơi, nam diễn viên này lại gặp rắc rối. Vâng, vâng, giống như khi cập nhật thông tin về một bài viết, việc gửi nó đến tất cả các diễn viên trò chuyện là điều khó khăn (chúng tôi giống như Google, hàng triệu người dùng đang chờ đợi hàng triệu bài viết trong cuộc trò chuyện cho mỗi người), nhưng mỗi khi cuộc trò chuyện được cập nhật, việc vào Monga là chuyện bình thường. Sau này tôi mới nhận ra, logic hoạt động của các cuộc trò chuyện cũng bị cắt bỏ hoàn toàn và thay vào đó là một thứ gì đó không hoạt động đã xuất hiện.
- Không còn dấu vết nào của các lớp loại.
- Một số logic không lành mạnh đã xuất hiện ở các tác nhân khi họ đăng ký với nhau, dẫn đến tình trạng chạy đua.
- Cấu trúc dữ liệu với các trường kiểu
Option[Int]biến thành Int với các giá trị mặc định kỳ diệu như -1. Sau này tôi nhận ra rằng mongoDB lưu trữ json và không có gì sai khi lưu trữ nó ở đóOptionchà, hoặc ít nhất là phân tích -1 là Không, nhưng vào thời điểm đó tôi không biết điều này và tin rằng "nó phải như vậy". Tôi không viết mã đó và cũng không buồn thay đổi nó vào lúc này. - Tôi phát hiện ra rằng địa chỉ IP công cộng của mình có xu hướng thay đổi và lần nào tôi cũng phải thêm nó vào danh sách trắng của Mongo. Tôi đã khởi chạy bot tại địa phương, Monga ở đâu đó trên máy chủ của Monga với tư cách là một công ty.
- Đột nhiên, việc chuẩn hóa thẻ và định dạng tin nhắn cho điện tín biến mất. (Hmm, tại sao lại như vậy?)
- Tôi thích trạng thái của bot được lưu trữ trong cơ sở dữ liệu bên ngoài và khi khởi động lại, nó tiếp tục hoạt động như không có chuyện gì xảy ra. Tuy nhiên, đây là điểm cộng duy nhất.
Người thứ hai không hề vội vàng, và tất cả những thay đổi này đã xuất hiện thành một đống lớn vào đầu tháng Chín. Tôi không ngay lập tức đánh giá cao quy mô của vụ phá hủy và bắt đầu hiểu hoạt động của cơ sở dữ liệu, bởi vì... Tôi chưa bao giờ xử lý chúng trước đây. Mãi sau này tôi mới nhận ra có bao nhiêu mã hoạt động đã bị cắt và bao nhiêu lỗi đã được thêm vào.
Tháng Chín
Lúc đầu tôi nghĩ sẽ rất hữu ích nếu thành thạo Monga và làm tốt nó. Sau đó, tôi dần dần hiểu rằng việc tổ chức giao tiếp với cơ sở dữ liệu cũng là một nghệ thuật trong đó bạn có thể thực hiện rất nhiều cuộc đua và chỉ mắc sai lầm. Ví dụ: nếu người dùng nhận được hai tin nhắn như /subscribe - và để đáp lại từng tin nhắn, chúng tôi sẽ tạo một mục trong bảng, vì tại thời điểm xử lý những tin nhắn đó, người dùng chưa đăng ký. Tôi nghi ngờ rằng giao tiếp với Monga ở dạng hiện tại không được viết theo cách tốt nhất. Ví dụ: cài đặt của người dùng đã được tạo tại thời điểm anh ấy đăng ký. Nếu anh ta cố gắng thay đổi chúng trước khi đăng ký... bot sẽ không phản hồi bất cứ điều gì, vì mã trong diễn viên đã đi vào cơ sở dữ liệu để cài đặt, không tìm thấy và bị lỗi. Khi được hỏi tại sao không tạo cài đặt khi cần, tôi được biết rằng không cần thay đổi chúng nếu người dùng chưa đăng ký... Hệ thống lọc tin nhắn được thực hiện bằng cách nào đó không rõ ràng và ngay cả sau khi xem kỹ mã, tôi vẫn có thể không hiểu ban đầu nó được dự định theo cách này hay có lỗi ở đó.
Không có danh sách các bài viết được gửi đến cuộc trò chuyện; thay vào đó, người ta gợi ý rằng tôi nên tự viết chúng. Điều này làm tôi ngạc nhiên - nói chung, tôi không phản đối việc lôi kéo đủ thứ vào dự án, nhưng sẽ hợp lý nếu người mang những thứ này vào và vặn vẹo chúng. Nhưng không, người tham gia thứ hai dường như từ bỏ mọi thứ mà nói rằng danh sách bên trong cuộc trò chuyện được cho là một giải pháp tồi và cần phải tạo một dấu hiệu với các sự kiện như “một bài báo y đã được gửi cho người dùng x”. Sau đó, nếu người dùng yêu cầu gửi bài viết mới thì cần phải gửi yêu cầu đến cơ sở dữ liệu, cơ sở dữ liệu sẽ chọn các sự kiện liên quan đến người dùng trong các sự kiện, đồng thời lấy danh sách các bài viết mới, lọc chúng, gửi cho người dùng. và ném các sự kiện về điều này trở lại cơ sở dữ liệu.
Người tham gia thứ hai bị cuốn đi đâu đó theo hướng trừu tượng, khi bot sẽ không chỉ nhận được các bài báo từ Habr và không chỉ được gửi tới điện tín.
Bằng cách nào đó, tôi đã triển khai các sự kiện dưới dạng một dấu hiệu riêng cho nửa cuối tháng 9. Nó không tối ưu, nhưng ít nhất bot đã bắt đầu hoạt động và bắt đầu gửi lại các bài viết cho tôi, và tôi dần dần hiểu ra điều gì đang xảy ra trong mã.
Bây giờ bạn có thể quay lại từ đầu và nhớ rằng kho lưu trữ ban đầu không phải do tôi tạo ra. Điều gì có thể đã xảy ra như thế này? Yêu cầu kéo của tôi đã bị từ chối. Hóa ra là tôi có mã lỗi, tôi không biết cách làm việc theo nhóm và tôi phải sửa các lỗi trong quá trình triển khai hiện tại chứ không phải tinh chỉnh nó đến trạng thái có thể sử dụng được.
Tôi cảm thấy khó chịu và nhìn vào lịch sử cam kết cũng như số lượng mã được viết. Tôi nhìn lại những khoảnh khắc ban đầu được viết rất hay nhưng sau đó lại bị ngắt quãng…
Đ*t nó
Tôi nhớ tới bài viết .
Tôi nghĩ rằng không ai thực sự cần một ý tưởng nếu không thực hiện. Tôi nghĩ rằng tôi muốn có một bot hoạt động được, nó sẽ hoạt động trong một bản sao duy nhất trên một máy tính như một chương trình java đơn giản. Tôi biết rằng bot của tôi sẽ hoạt động trong nhiều tháng mà không cần khởi động lại, vì trước đây tôi đã từng viết những bot như vậy. Nếu nó bất ngờ rơi xuống và không gửi cho người dùng một bài viết khác thì bầu trời sẽ không sụp đổ và sẽ không có thảm họa nào xảy ra.
Tại sao tôi cần Docker, mongoDB và các phần mềm “nghiêm túc” khác nếu mã đơn giản là không hoạt động hoặc hoạt động không ổn định?
Tôi đã rẽ nhánh dự án và làm mọi thứ như tôi muốn.
Cùng lúc đó, tôi thay đổi công việc và thời gian rảnh rỗi trở nên vô cùng thiếu thốn. Buổi sáng tôi thức dậy ngay trên tàu, buổi tối tôi về muộn và không còn muốn làm gì nữa. Tôi không làm gì trong một thời gian, sau đó mong muốn hoàn thành con bot đã lấn át tôi và tôi bắt đầu từ từ viết lại mã trong khi lái xe đi làm vào buổi sáng. Tôi sẽ không nói rằng nó hiệu quả: ngồi trên một chuyến tàu rung chuyển với một chiếc máy tính xách tay trên đùi và nhìn vào tình trạng tràn ngăn xếp từ điện thoại của bạn không phải là điều thuận tiện cho lắm. Tuy nhiên, thời gian viết mã trôi qua hoàn toàn không được chú ý và dự án bắt đầu dần dần chuyển sang trạng thái hoạt động.
Đâu đó trong tâm trí tôi có một mối nghi ngờ muốn sử dụng mongoDB, nhưng tôi nghĩ rằng ngoài những ưu điểm của lưu trữ trạng thái “đáng tin cậy”, còn có những nhược điểm dễ nhận thấy:
- Cơ sở dữ liệu trở thành một điểm lỗi khác.
- Mã ngày càng phức tạp hơn và tôi sẽ mất nhiều thời gian hơn để viết nó.
- Mã trở nên chậm và kém hiệu quả; thay vì thay đổi một đối tượng trong bộ nhớ, các thay đổi sẽ được gửi đến cơ sở dữ liệu và nếu cần sẽ được kéo trở lại.
- Có những hạn chế về kiểu lưu trữ các sự kiện trong một bảng riêng biệt, có liên quan đến đặc thù của cơ sở dữ liệu.
- Phiên bản dùng thử của Monga có một số hạn chế và nếu gặp phải chúng, bạn sẽ phải khởi chạy và định cấu hình Monga trên một thứ gì đó.
Tôi đã cắt bỏ monga, bây giờ trạng thái của bot chỉ được lưu trữ trong bộ nhớ của chương trình và đôi khi được lưu vào một tệp ở dạng json. Có lẽ trong phần bình luận họ sẽ viết rằng tôi đã sai, rằng đây là nơi nên sử dụng cơ sở dữ liệu, v.v. Nhưng đây là dự án của tôi, cách tiếp cận tệp càng đơn giản càng tốt và nó hoạt động một cách minh bạch.
Loại bỏ các giá trị ma thuật như -1 và trả về các giá trị bình thường Option, đã thêm bộ nhớ bảng băm chứa các bài viết đã gửi trở lại đối tượng cùng với thông tin trò chuyện. Đã thêm tính năng xóa thông tin về các bài viết cũ hơn năm ngày để không lưu trữ mọi thứ. Tôi đã đưa tính năng ghi nhật ký về trạng thái hoạt động - nhật ký được ghi với số lượng hợp lý vào cả tệp và bảng điều khiển. Đã thêm một số lệnh quản trị như lưu trạng thái hoặc lấy số liệu thống kê như số lượng người dùng và bài viết.
Đã sửa một số lỗi nhỏ: ví dụ: đối với các bài viết, số lượt xem, lượt thích, lượt không thích và nhận xét tại thời điểm người dùng vượt qua bộ lọc hiện đã được chỉ định. Nói chung, thật đáng ngạc nhiên khi có rất nhiều điều nhỏ nhặt phải được sửa chữa. Tôi lập một danh sách, ghi lại tất cả những “điểm bất thường” ở đó và sửa chúng trong khả năng có thể.
Ví dụ: tôi đã thêm khả năng đặt tất cả cài đặt trực tiếp trong một tin nhắn:
/subscribe
/rating +20
/author a -30
/author s -20
/author p +9000
/tag scala 20
/tag akka 50Và một đội khác /settings hiển thị chúng chính xác ở dạng này, bạn có thể lấy văn bản từ đó và gửi tất cả cài đặt cho bạn bè.
Chuyện tưởng chừng như nhỏ nhưng lại có hàng tá sắc thái tương tự.
Đã triển khai lọc bài viết dưới dạng mô hình tuyến tính đơn giản - người dùng có thể đặt xếp hạng bổ sung cho tác giả và thẻ, cũng như giá trị ngưỡng. Nếu tổng đánh giá của tác giả, đánh giá trung bình của thẻ và đánh giá thực tế của bài viết lớn hơn giá trị ngưỡng thì bài viết sẽ được hiển thị cho người dùng. Bạn có thể yêu cầu bot cung cấp các bài viết bằng lệnh /mới hoặc đăng ký bot và nó sẽ gửi các bài viết dưới dạng tin nhắn cá nhân bất kỳ lúc nào trong ngày.
Nói chung, tôi có ý tưởng để mỗi bài viết đưa ra nhiều tính năng hơn (trung tâm, số lượng nhận xét, dấu trang, động lực thay đổi xếp hạng, số lượng văn bản, hình ảnh và mã trong bài viết, từ khóa) và hiển thị cho người dùng thấy/ chưa ok vote theo từng bài và đào tạo model cho từng user, nhưng mình lười quá.
Ngoài ra, tính logic của công việc sẽ không quá rõ ràng. Bây giờ tôi có thể đặt xếp hạng +9000 cho bệnh nhânZero theo cách thủ công và với ngưỡng xếp hạng +20, tôi sẽ đảm bảo nhận được tất cả các bài viết của anh ấy (tất nhiên trừ khi tôi đặt -100500 cho một số thẻ).
Kiến trúc cuối cùng hóa ra khá đơn giản:
- Tác nhân lưu trữ trạng thái của tất cả các cuộc trò chuyện và bài viết. Nó tải trạng thái của nó từ một tệp trên đĩa và thỉnh thoảng lưu lại trạng thái đó vào một tệp mới.
- Một tác nhân thỉnh thoảng truy cập nguồn cấp dữ liệu RSS, tìm hiểu về các bài viết mới, xem các liên kết, phân tích cú pháp và gửi những bài viết này cho tác nhân đầu tiên. Ngoài ra, đôi khi nó yêu cầu danh sách các bài viết từ tác nhân đầu tiên, chọn những bài viết không quá ba ngày nhưng chưa được cập nhật trong một thời gian dài và cập nhật chúng.
- Một diễn viên giao tiếp bằng điện tín. Tôi vẫn mang tin nhắn phân tích cú pháp hoàn toàn ở đây. Nói một cách thân thiện, tôi muốn chia nó thành hai - để một phân tích các tin nhắn đến và phần thứ hai giải quyết các vấn đề vận chuyển như gửi lại các tin nhắn chưa gửi. Bây giờ không thể gửi lại và một tin nhắn không đến do lỗi sẽ bị mất (trừ khi nó được ghi vào nhật ký), nhưng cho đến nay điều này vẫn chưa gây ra bất kỳ vấn đề nào. Có lẽ vấn đề sẽ phát sinh nếu một nhóm người đăng ký bot và tôi đạt đến giới hạn gửi tin nhắn).
Điều tôi thích là nhờ akka, việc ngã của diễn viên 2 và 3 nhìn chung không ảnh hưởng đến hiệu suất của bot. Có lẽ một số bài viết không được cập nhật kịp thời hoặc một số tin nhắn không đến được điện tín, nhưng diễn viên khởi động lại tài khoản và mọi thứ vẫn tiếp tục hoạt động. Tôi lưu thông tin rằng bài viết chỉ được hiển thị cho người dùng khi người gửi điện tín phản hồi rằng anh ta đã gửi tin nhắn thành công. Điều tồi tệ nhất đe dọa tôi là gửi tin nhắn nhiều lần (nếu nó đã được gửi nhưng bằng cách nào đó xác nhận bị mất). Về nguyên tắc, nếu tác nhân đầu tiên không lưu trữ trạng thái trong mình mà giao tiếp với một số cơ sở dữ liệu, thì anh ta cũng có thể rơi vào trạng thái không thể nhận ra và sống lại. Tôi cũng có thể thử tính kiên trì của akka để khôi phục trạng thái của các diễn viên, nhưng cách triển khai hiện tại phù hợp với tôi vì tính đơn giản của nó. Không phải là mã của tôi thường xuyên bị lỗi - ngược lại, tôi đã nỗ lực rất nhiều để biến điều đó thành không thể. Nhưng điều tồi tệ đã xảy ra và khả năng chia chương trình thành các phần riêng biệt - các diễn viên dường như thực sự tiện lợi và thiết thực đối với tôi.
Tôi đã thêm Circle-ci để nếu mã bị hỏng, bạn sẽ biết ngay về nó. Ở mức tối thiểu, điều đó có nghĩa là mã đã ngừng biên dịch. Ban đầu tôi muốn thêm travis, nhưng nó chỉ hiển thị các dự án của tôi mà không có fork. Nói chung, cả hai thứ này đều có thể được sử dụng miễn phí trong các kho mở.
Kết quả
Bây giờ đã là tháng 11 rồi. Bot đã được viết, tôi đã sử dụng nó được hai tuần qua và tôi thích nó. Nếu bạn có ý tưởng để cải thiện, hãy viết. Tôi không thấy việc kiếm tiền từ nó có ích gì - hãy để nó hoạt động và gửi những bài viết thú vị.
Liên kết bot:
Github:
Kết luận nhỏ:
- Ngay cả một dự án nhỏ cũng có thể mất rất nhiều thời gian.
- Bạn không phải là Google. Chẳng ích gì khi bắn chim sẻ từ súng đại bác. Một giải pháp đơn giản cũng có thể có tác dụng.
- Các dự án thú cưng rất tốt để thử nghiệm các công nghệ mới.
- Các bot Telegram được viết khá đơn giản. Nếu không có “làm việc nhóm” và thử nghiệm công nghệ, bot có lẽ đã được viết trong một hoặc hai tuần.
- Mô hình tác nhân là một điều thú vị phù hợp với mã đa luồng và có khả năng chịu lỗi.
- Tôi nghĩ tôi đã hiểu tại sao cộng đồng nguồn mở lại yêu thích fork.
- Cơ sở dữ liệu tốt vì trạng thái ứng dụng không còn phụ thuộc vào sự cố/khởi động lại ứng dụng, nhưng làm việc với cơ sở dữ liệu sẽ làm phức tạp mã và áp đặt các hạn chế đối với cấu trúc dữ liệu.
Nguồn: www.habr.com