プロジェクトへの電報ボットの追加 - 「A から Z までの Java プロジェクト」

親愛なる皆さん、こんにちは。はい、はい、まさに友達です。私はすでにこのシリーズの記事にすっかり慣れているため、定期的にコメントに感謝の意を書いたり、内容を読んで理解したことを示したりする人々とはすでに親しくなっています。あなたと私は同じ目標に向かって両側から進んでいます。あなたは理解したいと思っていますが、私は説明したいと思っています。そして、私たちには同じ最終目標があります。それは、最初から最後まで理解できる書面による申請書です。この記事で説明する内容の多くについては、すでに聞いたことがあるかもしれません。私が何か新しいことや特別なことを話すつもりはありません (ただし、プロジェクトの枠組みの中でこれを知っておく/繰り返す必要があります)。 春に自分用のボットを作成したので、その「パターン」に依存します。

JRTB-2と書きます

記事でタスクJRTB-0で行ったのと同じことを行います。

1. ctrl + tの組み合わせを使用して、ローカル プロジェクトのメインブランチを更新します。
2. main ブランチに基づいて、以下を作成します。
3. ボットを追加します。
4. 実行内容の説明を含む新しいコミットを作成し、GitHub にプッシュします。
5. main ブランチのプル リクエストを作成し、再度確認します。ビルドが完了するのを待っており (github アクション)、メイン ブランチにマージされます。
6. 対応するタスクを閉じます。

電報ボットとは

私たち開発者は、次のようにテレグラム ボットを操作することを想像できます。クライアントを使用して、ボットと連携します。仕事用に既製のライブラリがあります。一連のアクションがあり、その後テレグラム ボットは自分がプログラムに関連付けられていることを認識します。そしてすでにプログラム内で、文字やコマンドを受け取り、それらを何らかの方法で処理する方法を学習します。電報ボットにはコマンドのようなものがあり、スラッシュ「/」で始まります。その後、すぐに一緒に単語を書きます。これは命令とみなされます。たとえば、誰もが知っておくべきコマンドが 2 つあります。

• /start — ボットの操作を開始します。
• /stop - ボットの作業を終了します。

残りは自分たちでやります。すぐに予約をさせてください。私が学んだとおりに、正確に何を、その方法で行います。ボットを使用すると、より良い結果が得られると確信しています。そして、誰かがこれをやりたいと思っているなら、私はただうれしいし、あらゆる方法でこの取り組みをサポートします。 ちなみに、電報のボット設定ではなく、コードを通じてコマンドの説明をプログラムする方法を誰かが私に説明してくれたら、それは素晴らしいことでしょう。これは習わなかった。 私たちのリソースには、基本的なボットの作成方法を説明した記事がいくつかあります。今日は同様のことを行います。さらに質問がある場合は、この記事をざっと読んでおくことをお勧めします。

BotFather でボットを作成する

ボットを接続するには、まずボットを作成する必要があります。Telegram には、独自の一意の名前を持つボットを作成するというアプローチがあります。また、トークン (パスワードのように機能する大きな文字列) も伴います。私はすでに JavaRush 用のボット@javarush_community_botを作成しました。このボットはまだ空で何もできません。重要なことは、名前の最後に_botが必要であるということです。これを行う方法を示すために、機能をテストするボットを作成します。実際のプロジェクトに関して言えば、これはテスト環境になります。そして、メインの環境は本番環境 (本番環境、つまりプロジェクトが実行される実際の環境) になります。もちろん、別の環境、サンドボックス環境を追加することも可能です。これは、すべての開発参加者がより変更可能でアクセス可能な共通のサンドボックスです。しかし、これではプロジェクト作成段階の状況が複雑になるだけです。ここでは、テスト用とサンドボックス環境用にさらに 2 つのボットを作成しましょう。最初のステップは、Telegram 自体にボットを作成 (登録) することです。ボット @BotFather を見つけて、コマンド /newbotを書き込む必要があります。次に、このボットに名前を付けるように求められます。これはタスクをテストするためのボットなので、その名前は適切です: [TEST] JavarushBot次に、いつでも見つけられるように一意の名前を付けます - ユーザー名: test_javarush_community上で述べたように、_bot を追加する必要があります。ユーザー名のサフィックスが必要なので、もう一度書きます: test_javarush_community_botこれで完了です。ボットが作成されました。これで、ユーザー名とトークンを使用してプロジェクトに接続できるようになりました。もちろん、テスト サーバーのスムーズな動作のため、このボットのトークン (本質的にはボットにアクセスするためのパスワード) を一般公開することはありません。

ボットをプロジェクトに接続します

いつものようにライブラリは含めませんが、スケルトンである SpringBoot をすぐに利用します。彼はスターターのようなものを持っています。ライブラリを含めることで、それを使用してプロジェクトを正しく構成したいことを SpringBoot に知らせることができます。多くの場所で説明されている通常のルートをたどる場合は、次のような構成をどこかに作成する必要があります。

ApiContextInitializer.init();
TelegramBotsApi telegramBotsApi = new TelegramBotsApi();
try {
  telegramBotsApi.registerBot(Bot.getBot());
} catch (TelegramApiRequestException e) {
  e.printStackTrace();
}

ここでは、ボットとの接続を確立できるオブジェクトが作成されます。私たちの場合、接続したいスターターは、「内部」のどこかですべてを実行します (これは、IT で頻繁に使用されるフレーズ「内部」の翻訳でもあります)。このスターターへのリンクは次のとおりです。README.md ファイルを参照すると、それが何であるか、その理由と使用方法がすぐにわかります。これを接続するには、この依存関係をメモリに追加するだけです。これですべてです:) 必要な依存関係は次のとおりです。

<dependency>
        <groupId>org.telegram</groupId>
        <artifactId>telegrambots-spring-boot-starter</artifactId>
        <version>5.0.1</version>
    </dependency>

私たちはそれを記憶に加えます。期待どおりのバージョンをインストールし、Maven プロジェクトを更新します。説明に基づいて、新しいクラスを作成し、TelegramLongPollingBot から継承し、このクラスを SpringBoot のアプリケーション コンテキストに追加するだけです。 アプリケーション コンテキストは、プロジェクトを実行するために作成されたオブジェクトが保存される場所です。クラスを追加するには、@Component、@Service、@Repository、@Controller のいずれかのアノテーションを使用する必要があります。または、構成クラス (つまり、Configuration アノテーションでマークされたクラス) のメソッドを通じて作成された場合は @Bean アノテーション。 これらすべてがまだ理解できないように思われるかもしれないことは理解しています。しかし、それを理解し始めると、そこには何も複雑ではないことがわかります。Spring Boot をすぐに理解するには、Spring In Action 5th edition という素晴らしい本をお勧めします。ご希望があれば、この本をもとに連載記事を書くことも可能です。戻りましょう。JavarushTelegramBotApplication を含むパッケージ内で、テレグラム ボットを含むボットパッケージを作成します。その名前はJavaRushTelegramBotになります。

package com.github.javarushcommunity.jrtb.bot;

import org.telegram.telegrambots.bots.TelegramLongPollingBot;
import org.telegram.telegrambots.meta.api.objects.Update;

/**
* Telegrambot for Javarush Community from Javarush community.
*/
@Component
public class JavarushTelegramBot extends TelegramLongPollingBot {

   @Override
   public void onUpdateReceived(Update update) {

   }

   @Override
   public String getBotUsername() {
       return null;
   }

   @Override
   public String getBotToken() {
       return null;
   }
}

このクラスは抽象クラスであり、3 つのメソッドを実装する必要がありました。それらについてさらに詳しく話しましょう。

• onUpdateReceived(Update update) - これは、ユーザーからのメッセージが到着するエントリ ポイントです。新しいロジックはすべてここから生まれます。
• getBotUsername() - ここでは、接続するボットのユーザー名を追加する必要があります。
• getBotToken() - したがって、これはボット トークンです。

本質的には、サイトのログイン名とパスワードのようなものです。今のところ、この値を明示的に書きません。これは「ハードコーディング」と呼ばれます（つまり、特定の値をバインドします。通常のように、英語のハードコードからトレーシングペーパーを作成します）。そんなことはすべきではありません。私たちは逆の方法で、このデータをapplication.propertiesクラスに書き込み、ここから読み取ります。なぜこれが必要なのでしょうか? 次に、アプリケーションの起動時にこれらの値を外部から設定できるようにします。柔軟です、そうです。ファイル src/main/resources/application.properties に移動します。そこでこれらの変数の名前を考え出します。拡張子 .properties を持つファイルは、「=」で区切られたキーと値の構造として読み取られ、各ペアは個別の行になります。そこで、次の変数を考え出しました。

• ボット.ユーザー名;
• ボットトークン。

これは次のようになります。SpringBoot には @Value という優れたアノテーションがあります。正しく使用すると、application.properties ファイルから値が取得されます。これでプロジェクトを更新します。

package com.github.javarushcommunity.jrtb.bot;

import org.springframework.beans.factory.annotation.Value;
import org.telegram.telegrambots.bots.TelegramLongPollingBot;
import org.telegram.telegrambots.meta.api.objects.Update;

/**
* Telegram bot for Javarush Community from Javarush community.
*/
@Component
public class JavarushTelegramBot extends TelegramLongPollingBot {

   @Value("${bot.username}")
   private String username;

   @Value("${bot.token}")
   private String token;

   @Override
   public void onUpdateReceived(Update update) {

   }

   @Override
   public String getBotUsername() {
       return username;
   }

   @Override
   public String getBotToken() {
       return token;
   }
}

変数の値をアノテーションに渡していることがわかります。SpringBoot がボット オブジェクトを作成するとき、値はプロパティ (繰り返しますが、英語のトレーシングペーパー - プロパティ) から取得されます。もうすぐだ。ボットに何かを応答させる必要があります。したがって、onUpdateReceivedメソッドを更新しましょう。ボットに届いたメッセージを取得して返す必要があります。こうすることで、ボットが動作していることがわかります。これを行うために、必要なことを大まかかつ手早く書きます。

@Override
public void onUpdateReceived(Update update) {
   if(update.hasMessage() && update.getMessage().hasText()) {
       String message = update.getMessage().getText().trim();
       String chatId = update.getMessage().getChatId().toString();

       SendMessage sm = new SendMessage();
       sm.setChatId(chatId);
       sm.setText(message);

       try {
           execute(sm);
       } catch (TelegramApiException e) {
           //todo add logging to the project.
           e.printStackTrace();
       }
   }
}

ここでの処理はすべて非常に単純です。メッセージが実際に存在することを確認するため、メッセージ自体 ( message ) と通信が行われているチャット ID ( chatId ) を抽出します。次に、メッセージSendMessage を送信するためのオブジェクトを作成し、メッセージ自体とチャット ID (つまり、ボットに何をどこに送信するか) を渡します。もうこれで十分です。次に、 JavarushTelegramBotApplicationクラスの main メソッドを実行し、Telegram でボットを探します。ログから、ボットが開始されたことがわかります。それで、Telegram に行ってボットに書き込む時が来ました:開始をクリックするとすぐに答えが届きます:チェックするためにもっとくだらないことを書いてみましょう:以上です。この時点で、JRTB-2 タスクは完了したと言えます。 。ここではまだ実際にテストを書くことはできないので、すべてをそのままにしておきます。次に、新しいコミットを作成する必要があります。コミットの名前に注意してください。ここでも注意を促します。コミットには最初にタスクの名前が含まれ、次に実行された内容の詳細な説明が含まれます。[コミットしてプッシュ...]をクリックし、再度[プッシュ]をクリックして確認します。プロジェクトに移動します。以前と同様に、GitHub はすでに新しいブランチを認識しており、メインのプル リクエストの作成を提案しています。私たちは抵抗せずにそれを作成します。いつものように、私たちはすでにレーベルとプロジェクトを選択し、それを私に割り当てました。最後に、「プルリクエストの作成」をクリックします。ビルドが完了するまで少し待ちましょう。これで、プル リクエストをマージする準備が整います。

バージョン管理

どういうわけか、バージョン管理を行う必要があるという点を見逃していました。これを行うために、ブランチにさらにいくつかの変更を加えます。IDEA に戻り、メモリ内のプロジェクトのバージョンを確認します。バージョンは0.0.1-SNAPSHOTです。こちらは義務バージョンです。そして、解決された新しい問題ごとにプロジェクトのバージョンを更新することから始めます。MVP に達するまで、バージョンには接尾辞 -SNAPSHOT が付きます。バージョン管理スキームはどうなりますか? XYZ-スナップショット ここで:

• X - メジャー バージョン アップデート。多くの場合、以前のバージョンとの下位互換性に関する問題が含まれます。
• Y - それほど大きな変更はなく、以前のバージョンと完全に互換性があります。
• Z は、当社が発見して修復した欠陥のカウンターです。

これに基づいて、最初のバージョン - 0.1.0-SNAPSHOTが作成されます。つまり、メジャーなアップデートはまだ行われておらず、すべてが少しだけ更新されており、まだ MVP に達していないため、接尾辞 -SNAPSHOT が付いています。 。これをメモリ内で変更しましょう。RELEASE_NOTES ファイルに移動します。ここで、新しいバージョンごとにプロジェクトへの変更を説明します。最初のエントリです。さて、その後のバージョン更新ごとに、正確に何が起こったのかをここで説明します。このケースをコミットし、説明を書きます。 JRTB-2: プロジェクトのバージョンを更新し、RELEASE_NOTES に追加しました。 すべては以前とまったく同じです。ビルドが完了し、変更をマージできるのを待っています。ここだけは少し異なります。メイン ブランチの各タスクが個別のコミットであることを確認したいので、単純にMerge プル リクエストをプッシュするだけでは機能しません。Git には、すべてのコミットを 1 つに収集してマージする git squash オプションがあります。このオプションを選択します。[スカッシュしてマージ] をクリックすると、メッセージを編集するよう提案されます。最終的には、非常に便利で、最も重要なのは、何が需要されているかというメッセージです。ちなみに、bitbucket ではそのような機能は見たことがありません =/ マージを確認します。残っている唯一のことは、ボードでタスクのステータスを完了に変更し、プル リクエストへのリンクを含むコメントを書いてボードを閉じることです。ボードは次のようになります。

結論

今日、私たちは電報ボットを段階的に作成し、SpringBoot プロジェクトに実装しました。ボットが動作して回答を返します。すぐにプロパティを通じてボット データにアクセスしました。さらに今後: JRTB-3を実行し、プロジェクトにコマンド パターンを追加するという大きな作業を行う予定です。ああ、もう一つ… 使われないようにトークンは公開しないと言いました。しかし、私がこの記事を書いていたのは真夜中近くで、仕事が終わった後でしたので、私がリポジトリに有効なトークンを投稿していたことが判明し、GitGuardian から手紙でこのことについて私に告げられました。今何をする？このトークンなしで新しいコミットをアップロードしても古いコミットが残ったままになるため、git から削除することはできなくなります。しかし、コミットを削除してロールバックしたくありません。そこで私は、すでに述べた BotFather からトークンを非アクティブ化しました。トークンは存在しますが、もう有効ではありません。記事を公開する前に、私の GitHub アカウントを購読して、そのすべてのコードを確認してください。読んでいただきありがとうございます。またお会いしましょう。

シリーズのすべてのマテリアルのリストは、この記事の冒頭にあります。