Habr からのパーソナライズされた記事セレクションの Telegram ボット

「なぜ？」といった質問に対しては、 古い記事があります - Natural Geektimes - 空間をよりクリーンに.

記事はたくさんありますが、主観的な理由で気に入らない記事もあれば、逆にスキップするのが残念な記事もあります。 このプロセスを最適化して時間を節約したいと考えています。

上記の記事ではブラウザ内スクリプトのアプローチを提案しましたが、私は次の理由から (以前に使用したことはありますが) それがあまり好きではありませんでした。

• コンピュータ/携帯電話上の異なるブラウザについては、可能であれば再度設定する必要があります。
• 著者による厳密なフィルタリングは必ずしも便利であるとは限りません。
• たとえ年に一度出版される記事であっても、見逃したくない著者の問題は解決されていません。

記事の評価に基づいてサイトに組み込まれたフィルタリングは、必ずしも便利であるとは限りません。高度に専門化された記事は、その価値にもかかわらず、かなり控えめな評価を受ける可能性があるためです。

当初、私は RSS フィード (または複数) を生成して、興味深いものだけをそこに残したいと考えていました。 しかし、最終的には、RSS を読むのはあまり便利ではないことがわかりました。いずれにせよ、記事にコメントしたり、記事に投票したり、お気に入りに追加したりするには、ブラウザを経由する必要があります。 そこで、興味深い記事を個人メッセージで送信する電報ボットを作成しました。 Telegram 自体はそれらから美しいプレビューを作成し、作成者/評価/ビューに関する情報と組み合わせると、非常に有益に見えます。

カットの下には、作品の特徴、執筆プロセス、技術的ソリューションなどの詳細が表示されます。

ボットについて簡単に説明すると、

リポジトリ: https://github.com/Kright/habrahabr_reader

電報内のボット: https://t.me/HabraFilterBot

ユーザーはタグと作成者に対して追加の評価を設定します。 その後、記事にフィルタが適用されます。ハブレに関する記事の評価、著者のユーザー評価、タグ別のユーザー評価の平均が合計されます。 その量がユーザー指定のしきい値より大きい場合、記事はフィルターを通過します。

ボットを作成する副次的な目標は、楽しみと経験を積むことでした。 さらに、私は定期的に次のことを自分自身に思い出させました 私はGoogleではありません、したがって、多くのことはできるだけ簡単に、さらには原始的に行われます。 ただし、それでもボットの作成プロセスに XNUMX か月かかることは避けられませんでした。

外は夏でした

XNUMX月も終わりだったので、botを書くことにしました。 それも一人ではなく、Scala をマスターしていて、それについて何か書きたいと思っていた友人と一緒に。 初めは有望に見えました。コードはチームによってカットされ、タスクは簡単に思えたので、数週間か XNUMX か月以内にボットが完成するだろうと考えていました。

私自身、ここ数年、時々、思いつきでコードを書いているにもかかわらず、通常、このコードを見たり見たりする人は誰もいません。ペットのプロジェクト、いくつかのアイデアのテスト、データの前処理、FP からのいくつかの概念の習得などです。 ロック上のコードはまったく異なる方法で記述できるため、チームでコードを書くことがどのようなものなのかに非常に興味がありました。

何がなくなったかもしれない そう? ただし、物事を急がないようにしましょう。
発生したことはすべてコミット履歴を使用して追跡できます。

知人が 27 月 XNUMX 日にリポジトリを作成しましたが、それ以外は何もしなかったので、コードを書き始めました。

30 7月

簡単に言うと、Habr の RSS フィードの解析を書きました。

• com.github.pureconfig タイプセーフな設定を case クラスに直接読み取るため (非常に便利であることが判明しました)
• scala-xml XML の読み取り用: 最初は RSS フィード用に独自の実装を書きたかったのですが、RSS フィードは XML 形式なので、解析にこのライブラリを使用しました。 実はRSS解析も登場しました。
• scalatest テスト用。 小さなプロジェクトであっても、テストを作成すると時間を節約できます。たとえば、XML 解析をデバッグする場合、ファイルにダウンロードしてテストを作成し、エラーを修正する方がはるかに簡単です。 その後、無効な utf-8 文字を含む奇妙な html の解析でバグが発生したとき、それをファイルに入れてテストを追加する方が便利であることが判明しました。
• アッカ出身の俳優。 客観的にはそれらはまったく必要ありませんでしたが、このプロジェクトは楽しむために書かれたものでしたので、試してみたかったのです。 結果として、気に入ったと言えるようになりました。 OOP のアイデアは、メッセージを交換するアクターがいるという反対側から見ることができます。 さらに興味深いのは、メッセージが到着しない、または処理されないようなコードを作成できる (またそうすべきである) ことです (一般的に、アカウントが XNUMX 台のコンピューターで実行されている場合、メッセージは失われるべきではありません)。 最初は頭を悩ませ、アクターが相互にサブスクライブするコード内にゴミが含まれていましたが、最終的にはかなりシンプルでエレガントなアーキテクチャを思いつくことができました。 各アクター内のコードはシングルスレッドであると考えることができ、アクターがクラッシュすると、acca がアクターを再起動します。その結果、かなりフォールト トレラントなシステムが実現します。

9 8月

プロジェクトに追加しました scala-scrapper Habr からの HTML ページを解析するため (記事の評価、ブックマークの数などの情報を引き出すため)。

そして猫たち。 岩の中のもの。

その後、分散データベースに関する本を読み、CRDT (競合のない複製されたデータ型、 https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type, ハーバー) ということで、Habré の記事に関する情報として、可換半群の型クラスを投稿しました。

実際、アイデアは非常に単純です。単調に変化するカウンターがあります。 昇進の数は徐々に増加しており、プラスの数も (マイナスの数も同様に) 増加しています。 記事に関して XNUMX つのバージョンの情報がある場合、それらを「XNUMX つにマージ」することができます。カウンタの状態が大きいほど、関連性が高いと考えられます。

セミグループとは、記事に関する情報を含む XNUMX つのオブジェクトを XNUMX つにマージできることを意味します。 可換とは、A + B と B + A の両方をマージでき、結果は順序に依存せず、最終的には最新のバージョンが残ることを意味します。 ちなみに、ここにも連想があります。

たとえば、計画通り、解析後の RSS は、閲覧数などの指標を含まず、記事に関する情報をわずかに弱めました。 その後、特別な攻撃者が記事に関する情報を取得し、HTML ページにアクセスして更新し、古いバージョンとマージしました。

一般的に言えば、akka と同様に、この必要はなく、単に記事の updateDate を保存し、マージせずに新しい記事を取得するだけで済みましたが、冒険の道が私を導いてくれました。

12 8月

私はより自由に感じるようになり、楽しみのために、各チャットを別のアクターとして作成しました。 理論的には、アクター自体の重さは約 300 バイトであり、数百万バイトで作成できるため、これは完全に通常のアプローチです。 この解決策は非常に興味深いことが判明したように思えます。

XNUMX 人の攻撃者は、電報サーバーと Akka のメッセージ システムの間の橋渡しをしました。 彼はメッセージを受信し、目的のチャット アクターに送信するだけでした。 チャットアクターは応答として何かを送り返すことができ、それが電報に送り返されることになります。 非常に便利だったのは、このアクターが可能な限り単純で、メッセージに応答するためのロジックのみを含んでいることが判明したことです。 ちなみに、各チャットに新着記事の情報が入ってきましたが、こちらも特に問題はありませんでした。

一般的に、ボットはすでに動作しており、メッセージに応答し、ユーザーに送信された記事のリストを保存しており、ボットの準備はほぼ完了していると私は考えていました。 著者名やタグの正規化 (「sd f」を「s_d_f」に置き換える) など、小さな機能を少しずつ追加していきました。

一つだけ残ってた 小さいけど — 状態はどこにも保存されませんでした。

すべてがうまくいかなかった

お気づきかもしれませんが、私はほとんど XNUMX 人でボットを作成しました。 そこで、XNUMX 人目の参加者が開発に参加し、コードに次の変更が加えられました。

• MongoDB は状態を保存するようです。 同時に、何らかの理由で Monga がログをスパム送信し始め、一部の人々が単純にグローバルにログをオフにしたため、プロジェクトのログが破損しました。
• Telegram のブリッジ アクターは、認識を超えて変貌し、自らメッセージを解析し始めました。
• チャットのアクターは容赦なく削減され、代わりにすべてのチャットに関するすべての情報を一度に隠すアクターに置き換えられました。 くしゃみをするたびに、この俳優はトラブルに見舞われた。 そうです、記事に関する情報を更新するときと同様に、すべてのチャット アクターに情報を送信するのは困難です (私たちは Google のようなもので、何百万ものユーザーがそれぞれのチャットで XNUMX 万件の記事を待っています)。しかし、チャットが更新されるたびに、モンガに入るのが普通です。 かなり後になってから気づいたのですが、チャットの動作ロジックも完全に切り取られ、その代わりに動作しないものが現れました。
• 型クラスの痕跡は残りません。
• 相互にサブスクリプションを行うアクターに不健全なロジックが発生し、競合状態が発生しました。
• タイプのフィールドを含むデータ構造 Option[Int] -1 のような魔法のデフォルト値を持つ Int に変換されます。 後で、mongoDB に json が保存されていることに気づきましたが、そこに保存することに何も問題はありません。 Option そうですね、少なくとも -1 を None として解析しますが、当時の私はこれを知らず、「そうあるべきだ」という言葉をそのまま信じていました。 そのコードは私が書いたものではありませんし、当面は変更する必要もありませんでした。
• 私のパブリック IP アドレスは変更される傾向があり、そのたびに Mongo のホワイトリストに追加する必要があることがわかりました。 私はボットをローカルで起動しました。Monga は会社として Monga のサーバーのどこかにありました。
• 突然、電報のタグとメッセージ形式の正規化がなくなりました。 （うーん、それはなぜでしょうか？）
• ボットの状態が外部データベースに保存され、再起動すると何事もなかったかのように動作し続けることが気に入りました。 ただし、これが唯一のプラスでした。

XNUMX 人目の人は特に急いでいたわけではなく、これらすべての変更は XNUMX 月の初めにすでに XNUMX つの大きな山として現れていました。 私は結果として生じる破壊の規模をすぐには理解できませんでしたが、データベースの働きを理解し始めました。 私はこれまで彼らと取引したことがありません。 後になって初めて、どれだけの動作コードが削除され、その代わりにどれだけのバグが追加されたかに気づきました。

9月

最初はモンガをマスターしてうまくやれば役に立つだろうと思いました。 その後、データベースとの通信を整理することは、多くのレースを行っても間違いを犯す可能性がある技術でもあることを徐々に理解し始めました。 たとえば、ユーザーが次のような XNUMX つのメッセージを受信した場合、 /subscribe - そして、それらのメッセージを処理する時点ではユーザーは購読されていないため、それぞれに応答してテーブルにエントリを作成します。 現在の形式のモンガとのコミュニケーションは最良の方法で書かれていないのではないかという疑念があります。 たとえば、ユーザーの設定はサインアップした時点で作成されます。 サブスクリプションを行う前に変更しようとした場合、ボットは何も応答しませんでした。アクターのコードが設定のためにデータベースに入り、見つからずクラッシュしたためです。 なぜ必要に応じて設定を作成しないのかと尋ねられたとき、ユーザーが購読していない場合は変更する必要がないことが分かりました。メッセージ フィルタリング システムは、どういうわけか非明白に作成されており、コードを詳しく調べた後でも、最初からこのように意図されていたのか、それともそこにエラーがあるのか​​はわかりません。

チャットに送信された記事のリストはなく、代わりに自分で書くように勧められました。 これには私は驚きました。一般的に、私はプロジェクトにあらゆる種類のものを持ち込むことに反対しませんでしたが、これらのものを持ち込んでねじ込んだ人にとっては当然のことでしょう。 しかし、いいえ、XNUMX 番目の参加者はすべてを諦めたようで、チャット内のリストはおそらく悪い解決策であり、「記事 y がユーザー x に送信された」などのイベントを伴うサインを作成する必要があると言いました。 次に、ユーザーが新しい記事の送信をリクエストした場合、データベースにリクエストを送信する必要がありました。データベースは、イベントの中からユーザーに関連するイベントを選択し、新しい記事のリストを取得してフィルターし、ユーザーに送信します。そして、これに関するイベントをデータベースにスローします。

XNUMX 番目の参加者は、ボットがハブから記事だけを受信するだけでなく、電報に送信されるだけでなく、抽象化に向かってどこかに運ばれました。

XNUMX月後半はなんとか別看板という形でイベントを実施しました。 最適とは言えませんが、少なくともボットが動作し始めて記事を再び送信し始めたので、コード内で何が起こっているのかが徐々に理解できました。

ここで、最初に戻って、リポジトリが最初に私によって作成されたものではないことを思い出してください。 一体何がこうなってしまったのでしょうか？ 私のプルリクエストは拒否されました。 田舎者のコードがあり、チームで作業する方法がわからず、現在の実装曲線のバグを修正する必要があり、使用可能な状態に改善する必要がなかったことが判明しました。

腹が立ってコミット履歴と書かれたコードの量を見てみました。 もともとうまく書かれていたのに、その後崩れてしまった瞬間を観察してみました...

くたばれ

記事思い出した あなたは Google ではありません.

実装がなければアイデアは誰も必要としないと思いました。 私は、XNUMX 台のコンピュータ上で XNUMX つのコピーで単純な Java プログラムとして動作する、動作するボットが欲しいと考えました。 過去にそのようなボットを作成したことがあるので、私のボットは数か月間再起動せずに動作することがわかっています。 突然落下し、ユーザーに別の記事を送信しなかったとしても、空は地面に落ちることはなく、壊滅的な事態は何も起こりません。

コードが単に機能しない、または不正に動作する場合、なぜ Docker や mongoDB などの「本格的な」ソフトウェアのカルトが必要なのでしょうか?

私はプロジェクトをフォークして、すべてやりたいようにやりました。

同じ頃、私も転職し、自由な時間が極端になくなってしまいました。 朝は電車の中ですぐに目が覚め、夕方には遅く帰ってきて何もしたくなくなりました。 しばらく何もしませんでしたが、ボットを完成させたいという欲求が勝って、朝の通勤中にゆっくりとコードを書き直し始めました。 それが生産的だったとは言えません。揺れる電車の中でラップトップを膝の上に置き、携帯電話からスタックのオーバーフローを見るのはあまり便利ではありません。 しかし、コードの作成に費やされる時間はまったく気付かないうちに過ぎ、プロジェクトはゆっくりと稼働状態に向けて動き始めました。

心のどこかで、mongoDB を使用したいという疑いの虫がいたのですが、「信頼性の高い」状態ストレージの利点に加えて、顕著な欠点があると考えました。

• データベースが別の障害点になります。
• コードはますます複雑になり、書くのにさらに時間がかかります。
• コードは遅くなり非効率になり、メモリ内のオブジェクトを変更する代わりに、変更がデータベースに送信され、必要に応じてプルバックされます。
• 別のテーブルにイベントを保存するタイプには制限があり、これはデータベースの特性に関連しています。
• Monga の試用版にはいくつかの制限があり、制限に遭遇した場合は、何かで Monga を起動して設定する必要があります。

モンガを切り取ったので、ボットの状態は単にプログラムのメモリに保存され、時々 json 形式でファイルに保存されます。 おそらくコメントには、私が間違っている、ここはデータベースを使用すべきである、などと書かれるでしょう。 しかし、これは私のプロジェクトであり、ファイルを使用したアプローチは可能な限りシンプルであり、透過的な方法で機能します。

-1 のような魔法の値を捨てて、通常の値を返します Option、チャット情報を含むオブジェクトに送信された記事を含むハッシュ テーブルのストレージが追加されました。 すべてを保存しないように、XNUMX 日以上経過した記事に関する情報の削除を追加しました。 ログを動作状態にしました。ログはファイルとコンソールの両方に適切な量で書き込まれます。 状態の保存や、ユーザーや記事の数などの統計の取得など、いくつかの管理コマンドが追加されました。

細かい点を多数修正しました。たとえば、記事の場合、ユーザーのフィルターを通過した時点のビュー、いいね、嫌い、コメントの数が表示されるようになりました。 一般的に、修正しなければならない小さな点がどれほど多かったかに驚くでしょう。 私はリストを作成し、そこにあるすべての「不規則性」に注目し、可能な限り修正しました。

たとえば、すべての設定を XNUMX つのメッセージで直接設定する機能を追加しました。

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

そして別のチーム /settings このフォームで正確に表示されるので、そこからテキストを取得して、すべての設定を友人に送信できます。
小さなことのように思えますが、似たようなニュアンスがたくさんあります。

シンプルな線形モデルの形式で記事のフィルタリングを実装しました。ユーザーは、著者とタグの追加の評価、およびしきい値を設定できます。 著者の評価、タグの平均評価、および記事の実際の評価の合計がしきい値より大きい場合、記事がユーザーに表示されます。 コマンド /new を使用してボットに記事を要求するか、ボットを購読すると、一日中いつでも個人メッセージで記事が送信されます。

一般的に言えば、各記事でより多くの機能 (ハブ、コメント数、ブックマーク、評価変化のダイナミクス、テキストの量、記事内の画像とコード、キーワード) を引き出し、ユーザーに OK/ を表示するというアイデアがありました。各記事で投票し、ユーザーごとにモデルをトレーニングするのは問題ありませんが、私は怠け者でした。

さらに、作品のロジックはそれほど明白ではありません。 これで、patientZero の評価を手動で +9000 に設定できるようになり、しきい値評価を +20 に設定すると、彼のすべての記事を確実に受信できるようになります (もちろん、一部のタグに -100500 を設定した場合を除く)。

最終的なアーキテクチャは非常にシンプルであることが判明しました。

1. すべてのチャットと記事の状態を保存するアクター。 ディスク上のファイルから状態をロードし、その状態を随時新しいファイルに保存します。
2. RSS フィードに時々アクセスし、新しい記事について学習し、リンクを見て解析し、これらの記事を最初のアクターに送信するアクター。 さらに、最初のアクターから記事のリストを要求し、XNUMX 日以内で長期間更新されていない記事を選択して更新する場合もあります。
3. 電報で通信する俳優。 私はまだ完全にメッセージ解析をここに持ってきました。 友好的な方法で、これを XNUMX つに分割したいと思います。XNUMX つは受信メッセージを解析し、XNUMX つ目は未送信メッセージの再送信などのトランスポートの問題に対処します。 現在は再送信は行われず、エラーにより到着しなかったメッセージは (ログに記録されない限り) 単純に失われますが、これまでのところ問題は発生していません。 おそらく、大勢の人がボットを購読し、メッセージ送信の制限に達すると問題が発生するでしょう)。

私が気に入ったのは、akka のおかげで、アクター 2 と 3 の転倒が通常、ボットのパフォーマンスに影響を与えないことです。 おそらく、一部の記事が時間通りに更新されなかったり、一部のメッセージが電報に届かなかったりする可能性がありますが、アカウントはアクターを再起動し、すべてが機能し続けます。 電報アクターがメッセージを正常に配信したと応答した場合にのみ記事がユーザーに表示されるという情報を保存します。 私を脅す最悪のことは、メッセージを数回送信することです (メッセージは配信されたものの、何らかの理由で確認が失われた場合)。 原則として、最初の行為者が自分自身の中に状態を保存せず、何らかのデータベースと通信した場合、彼は気づかれないうちに倒れて生き返ることもできます。 アクターの状態を復元するために akka 永続性を試すこともできますが、現在の実装はそのシンプルさの点で私には合っています。 コードが頻繁にクラッシュするというわけではありません。むしろ、それを不可能にするためにかなりの努力を費やしました。 しかし、とんでもないことは起こります。プログラムを個別の部分に分割する機能、つまりアクターは、私にとって非常に便利で実用的であるように思えました。

コードが壊れた場合にすぐにわかるように、circle-ci を追加しました。 少なくとも、コードのコンパイルが停止したことを意味します。 最初は travis を追加したかったのですが、フォークなしでプロジェクトが表示されるだけでした。 一般に、これらはどちらもオープン リポジトリで自由に使用できます。

結果

もうXNUMX月ですね。 このボットは書かれており、ここ XNUMX 週間使用していますが、とても気に入りました。 改善のアイデアがある場合は、書き込んでください。 それを収益化することに意味がありません。ただ機能させて、興味深い記事を送信してください。

ボットリンク: https://t.me/HabraFilterBot
ギットハブ: https://github.com/Kright/habrahabr_reader

小さな結論:

• たとえ小さなプロジェクトであっても、多くの時間がかかることがあります。
• あなたは Google ではありません。 大砲でスズメを撃っても意味がありません。 単純な解決策でも同様に機能する場合があります。
• ペット プロジェクトは、新しいテクノロジーを実験するのに非常に適しています。
• Telegram ボットは非常に単純に書かれています。 「チームワーク」とテクノロジーの実験がなければ、ボットは XNUMX ～ XNUMX 週間で作成されたでしょう。
• アクター モデルは、マルチスレッドおよびフォールト トレラント コードとうまく連携する興味深いものです。
• オープンソース コミュニティがフォークを好む理由がわかった気がします。
• データベースはアプリケーションの状態がアプリケーションのクラッシュ/再起動に依存しないため優れていますが、データベースを操作するとコードが複雑になり、データ構造に制限が課せられます。

出所： habr.com