Rust

いろんなライブラリを触りたい。ナナオです。 今回はPythonのHTMLテンプレートエンジンで有名なJinjaに影響を受けたTeraを使って、簡単な動的サイトを作ってみたいと思います。 プロジェクトの作成 とりあえず実験用のプロジェクトを作成します。 cargo new rust-ssr-playground 必要なライブラリをインストールしてあげます。 今回はWebサーバーとしてAxum、HTMLのテンプレートエンジンとしてTeraを使用します。 [dependencies] axum = "0.7.1" serde = { version = "1.0.193", features = ["derive"] } tera = "1.19.1" tokio = { version = "1.34.0", features = ["full"] } じゃあとりあえずaxumを起動できるところまで実装します。 use axum::{Router, routing::get}; #[tokio::main] async fn main() { let app = Router::new().route("/", get(|| async { "hello world" })); let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap(); axum::serve(listener, app).await.unwrap(); } 起動してアクセスしてみましょう。 ちゃんと起動しましたね。 次にプロジェクトにHTMLを追加してみましょう。 templatesというディレクトリを作成して、その中にindex.htmlを作成しましょう。 作成したHTMLは以下の通りです。 （Teraのテンプレート構文についてはこちらを参照してください） hello {{ name }}! nameの部分はTeraで入れるようにしました。 HTMLの準備ができたので、これをTeraで描画できるようにします。 use axum::{Router, response::Html, routing::get}; use tera::{Context, Tera}; use serde::Serialize; #[derive(Serialize)] struct Index { name: String } #[tokio::main] async fn main() { let tera = match Tera::new("templates/**/*.html") { Ok(t) => t, Err(e) => { println!("Parsing error(s): {}", e); ::std::process::exit(1); } }; let index = Index { name: String::from("test") }; let page = tera.render("index.html", &Context::from_serialize(&index).unwrap()).unwrap(); let app = Router::new().route("/", get(|| async move { Html(page.to_owned()) })); let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap(); axum::serve(listener, app).await.unwrap(); } できました。nameにはtestと描画できるようにします。 ...

どうも、ナナオです。 結構長いこと書いていますが、今回で完成かな…？（前回も同じこと言ったような気がするけど いや、完成させます！ 期日設定によって送られるメッセージ頻度を変化させる 最初の記事で想定していたように、このBotは全員が回答するまでメッセージを送り続けるようにしたいです。 その頻度は以下のように期日からの経過時間によって変わります。 期日まで 未回答者に1日に一回催促のDMが送られる 期日経過～1日 未回答者に1時間に一回催促のDMが送られる 期日経過1日～2日 未回答者に30分に一回催促のDMが送られる 期日経過3日～ 未回答者に15分に一回催促のDMが送られる これを実装していきます。 pub struct MultipleService { router: Router, scheduler: JobScheduler, } impl MultipleService { pub async fn new(pool: PgPool) -> Result<MultipleService, shuttle_runtime::Error> { let state = AxumState { pool: pool.clone() }; let router = Router::new() .route("/webhook", post(webhook)) .route("/healthcheck", get(healthcheck)) .with_state(state); let scheduler = JobScheduler::new().await.unwrap(); // 時間ごとにバッチを追加 // 1日に一回 let pool_clone = pool.clone(); let daily_job = Job::new_async("0 0 0 * * *", move |_, _| { let inner_pool = pool_clone.clone(); Self::send_message_with_deadline(inner_pool, DailyCondition) }).expect("ジョブの作成に失敗しました"); // 1時間に一回 let pool_clone = pool.clone(); let hourly_job = Job::new_async("0 0 * * * *", move |_, _| { let inner_pool = pool_clone.clone(); Self::send_message_with_deadline(inner_pool, HourlyCondition) }).expect("ジョブの作成に失敗しました"); // 30分に一回 let pool_clone = pool.clone(); let every_thirty_minutes_job = Job::new_async("0 */30 * * * *", move |_, _| { let inner_pool = pool_clone.clone(); Self::send_message_with_deadline(inner_pool, EveryThirtyMinutesCondition) }).expect("ジョブの作成に失敗しました"); // 15分に一回 let pool_clone = pool.clone(); let every_fifteen_minutes_job = Job::new_async("0 */15 * * * *", move |_, _| { let inner_pool = pool_clone.clone(); Self::send_message_with_deadline(inner_pool, EveryFifteenMinutesCondition) }).expect("ジョブの作成に失敗しました"); scheduler.add(daily_job).await.expect("スケジューラへジョブを追加するのに失敗しました。"); scheduler.add(hourly_job).await.expect("スケジューラへジョブを追加するのに失敗しました。"); scheduler.add(every_thirty_minutes_job).await.expect("スケジューラへジョブを追加するのに失敗しました。"); scheduler.add(every_fifteen_minutes_job).await.expect("スケジューラへジョブを追加するのに失敗しました。"); Ok(Self { router, scheduler, }) } // バッチ内の処理はほぼ同じことをやっているので共通関数として定義 fn send_message_with_deadline(pool: PgPool, cond: impl JobCondition + Send + 'static) -> Pin<Box<(dyn Future<Output = ()> + Send)>> { let inner_pool = pool.clone(); let http_client = HttpClient::new(); Box::pin(async move { let line_group_repository = LineGroupRepository::new(inner_pool); let all_line_group = line_group_repository.get_all() .await .expect("全てのline_group取得に失敗しました"); for line_group in all_line_group.iter() { if let Some(chousei_id) = line_group.chousei_id.clone() { let group_count = http_client.count_group_members(line_group.id.clone()) .await .expect(format!("line_groupの人数取得に失敗しました。id: {}", line_group.id).as_str()) .try_into() .expect("グループカウントをusizeに変換できませんでした"); let res = http_client.get_chousei_csv(chousei_id) .await .expect("調整さんのCSV取得に失敗しました"); // グループ内の人数より調整さんの回答者数が少ない場合はメッセージをプッシュします if res.member_info_map.len() < group_count { if let Some(deadline_date) = line_group.deadline_date { if cond.check(deadline_date) { // 実行時間ごとに条件が異なるため、JobConditionトレイトを使用して条件を入れ替え可能にしています。 let message = "調整さんに回答してください！".to_string(); http_client.push_message(line_group.id.clone(), vec![message]) .await .expect("lineのメッセージ送信に失敗しました"); } } } } } }) } } 少しだけテクいのは、send_message_with_deadline関数でJobConditionトレイトを使用しているあたりです。 ...

会社で発表したら緊張しすぎて手汗がすごい、ナナオです。 今回でおそらく完成させたい、LineBotのヤバいさんを早速実装していきます。 line_groupテーブルに調整さんのIDを設定できるようにする まずはマイグレーションを追加します。 sqlx-cliを使用しましょう。 sqlx migrate add add_column_chousei_id 作成されたマイグレーションファイルを実装します。 PostgreSQL: Documentation: 18: ALTER TABLE 調整さんのIDは小文字の英数字32桁からなる文字列なので、そのように定義します。 -- 調整さんのイベントIDを設定できる列を追加 ALTER TABLE "line_group" ADD COLUMN "chousei_id" varchar(32); この定義だと1グループにつき一つのイベントまでしか設定できませんが、そんなに立て続けに同じグループでイベントの出欠を取ることはないと信じています。 一旦この状態でshuttleを起動して、マイグレーションが問題なく適用されるか確認します。 cargo shuttle run DBを確認してみます。 postgres=# select * from line_group; id | deadline_date | chousei_id -----------------------------------+---------------+------------ C480b2f8b56ecaf62c2033867e2ff78b2 | 2023-11-12 | (1 行) 既存データにchousei_idが追加されています！ 続けて、LineGroupのモデルにchousei_idプロパティを追加してあげましょう。 #[derive(Debug, FromRow, Serialize, Deserialize)] pub struct LineGroup { pub id: String, pub deadline_date: NaiveDate, pub chousei_id: Option<String>, } 期日設定を行うCommandの実装にLineGroupの初期化処理があるので、ここにchousei_idの初期化も追加しておきます。 impl BotSetDeadlineCommand { async fn new( pool: Arc<PgPool>, group_id: &str, deadline_date: &str, ) -> Self { let repository = LineGroupRepository::new(&pool); let id = group_id.to_string(); let line_group_option = repository.select(id.clone()) .await .expect("期日設定中のline_groupの取得に失敗しました"); let deadline_date = NaiveDate::parse_from_str(deadline_date, "%Y-%m-%d") .expect("日付型への変換に失敗しました"); let line_group = match line_group_option { Some(mut line_group) => { line_group.id = id; line_group.deadline_date = deadline_date; line_group }, _ => LineGroup { id, deadline_date, chousei_id: None, } }; Self { pool, line_group } } } 期日設定によってchousei_idがリセットされないように、line_groupの初期化処理の前に既存のline_groupを取得するようにしました。 ...

どうも、ナナオです。 今回はCSVをパースして、未回答の人が誰かを取得する処理を実装していきます。 CSVパース処理の仕様 とりあえず、調整さん側の動きについて確認するためにイベントを作ってみます。 調整さん - 簡単スケジュール調整、出欠管理ツール 作ったイベントはこんな感じです。 作成したイベントに関連するURLは以下のようになっています。 イベントページのURL https://chouseisan.com/s?h={イベントID} CSVダウンロードのURL https://chouseisan.com/schedule/List/createCsv?h={イベントID}&charset=utf-8&row=choice イベントを作成してすぐにCSVを取得すると、以下のようなフォーマットになっています。 テストイベント 日程 11/15(水) 19:00〜 11/16(木) 19:00〜 11/17(金) 19:00〜 コメント これに回答すると以下のようになります。 テストイベント 日程,nanao 11/15(水) 19:00〜,◯ 11/16(木) 19:00〜,△ 11/17(金) 19:00〜,× コメント,test 回答者が増えると以下のようになります。 テストイベント 日程,nanao,test_1,test_2 11/15(水) 19:00〜,◯,×,△ 11/16(木) 19:00〜,△,△,△ 11/17(金) 19:00〜,×,◯,△ コメント,test,test_1,test_2 名前からLineのアカウント名を推測するという方法もあるんですが、ここはシンプルに回答者の数とグループ内の人数が合わない場合に通知するという感じにしましょう。 （ここまでやってて思ったんですが、調整さんだとちょっとカスタマイズ性にかけてしまいますね。。今後の改修ポイントかも） パース処理を実装 CSVをパースするためにまずはcsvモジュールを依存関係に追加します。 csv = "1.3.0" bytes = "1.5.0" # reqwestからのレスポンスボディをバイトで取得するため 前回、line_clientモジュールという名前で実装しましたが、調整さんへのリクエストも処理させたいのでhttp_clientという名前に変更して調整さんへのリクエスト処理を実装します。 // src/http_client.rs // ...中略... // 調整さんのCSV取得エンドポイントのレスポンスを表す構造体 pub struct GetChouseiCsv { title: String, csv_text: String, } // LineClient -> HttpClientに変更 pub struct HttpClient { client: Client, } impl HttpClient { // ...中略... // 調整CSVを取得する pub async fn get_chousei_csv(&self, event_id: String) -> Result<GetChouseiCsv, reqwest::Error> { let url = format!("https://chouseisan.com/schedule/List/createCsv?h={}&charset=utf-8&row=choice", event_id); let res_body = self.client.get(url).send().await?.text().await?; let lines: Vec<&str> = res_body.lines().collect(); let title = lines[0]; let csv_text = lines[2..].join("\n"); Ok(GetChouseiCsv{ title: title.to_string(), csv_text }) } } 実装できました。 ...

もう４回目の記事になるんですね。ナナオです。 今回は設定された期日まで15分おきにメッセージを送れるようにしてみたいと思います。 実装をモジュール化 今までの実装でメインモジュールがだいぶごちゃごちゃしてきたので分離してあげます。 LineGroupの構造体はmodel.rsを作ってそちらに移動します。 use sqlx::FromRow; use chrono::NaiveDate; use serde::{Serialize, Deserialize}; #[derive(FromRow, Serialize, Deserialize)] pub struct LineGroup { pub id: String, pub deadline_date: NaiveDate, } DBのline_groupに対する処理はrepository.rsを作ってそちらに移動します。 use crate::model::LineGroup; use sqlx::PgPool; pub struct LineGroupRepository<'a> { pool: &'a PgPool } impl<'a> LineGroupRepository<'a> { pub fn new(pool: &'a PgPool) -> Self { Self { pool } } pub async fn select(&self, id: String) -> Result<Option<LineGroup>, sqlx::Error> { let line_group = sqlx::query_as(r"SELECT * FROM line_group WHERE id = $1;") .bind(id) .fetch_optional(self.pool) .await?; Ok(line_group) } pub async fn update(&self, data: &LineGroup) -> Result<(), sqlx::Error> { sqlx::query(r"UPDATE line_group SET deadline_date = $2 WHERE id = $1;") .bind(&data.id) .bind(&data.deadline_date) .execute(self.pool) .await?; Ok(()) } pub async fn insert(&self, data: &LineGroup) -> Result<(), sqlx::Error> { sqlx::query(r"INSERT INTO line_group (id, deadline_date) VALUES ($1, $2);") .bind(&data.id) .bind(&data.deadline_date) .execute(self.pool) .await?; Ok(()) } } 署名認証処理はutils.rsを作ってそちらに移動します。 ...

意外とRustってとっつきやすいなと考えを改めました。ナナオです。 今回はメッセージから期日設定などを行えるように実装を修正していきます。 ヤバいさんのコマンドを呼び出す では具体的にどうやって期日設定を行うかといえば、「グループチャット内」で「矢倍くん宛」にメッセージを送ったときに行うようにしましょう。 また、期日設定以外にも調整さんのURLを設定できる必要があります。あとヘルプコマンドもあると便利ですね。 ということで、コマンドを３つ用意します。 調整さんのURL設定 「ヤバいさん https://chouseisan.com/s?h=[調整さんのイベントID]」と送られた場合に実行される 候補日に対してどのくらい回答しているか確認するため 期日設定 「ヤバいさん 2023-01-01」と送られた場合に実行される ヘルプ 「ヤバいさん」とだけ送られる、もしくは対応していないコマンドを送られた場合に実行される 使い方、コマンドの一覧を教えてくれる コマンドといえばコマンドパターンですね。 こんな感じのtraitを実装します。 trait BotCommand { fn execute(&self, value: Value); } これを使って、３つのコマンドを実装します。 struct BotSetDeadlineCommand { pool: PgPool, line_group: LineGroup, }; impl BotSetDeadlineCommand { /// コマンドのコンストラクタ /// DBの更新に必要な値を渡します fn new( pool: PgPool, group_id: &str, deadline_date: &str, ) -> Self { let line_group = LineGroup { id: group_id.to_string(), deadline_date: NaiveDate::parse_from_str(deadline_date, "%Y-%m-%d") .expect("日付型への変換に失敗しました") }; Self { pool, line_group } } } impl BotCommand for BotSetDeadlineCommand { fn execute(&self, value: Value) {} } // それ以外のコマンドも一応用意しておく struct BotSetUrlCommand; impl BotCommand for BotSetUrlCommand { fn execute(&self, value: Value) {} } struct BotHelpCommand; impl BotCommand for BotHelpCommand { fn execute(&self, value: Value) {} } まずは期日設定を行えるようにしましょう。 ...

開発楽しい、ナナオです。 前回まででMessaging APIのwebhookとの疎通確認ができました。 今回はもう少し踏み込んで期日設定を行えるようにしていきます。 ShutleにPostgresを導入する まず、設定された期日を保存しておくためのDBを用意します。 これにはShuttleが提供しているPostgresを使用します。 Shuttle Shared Databases - Shuttle Docs また、基本的にDBクライアントとしてはSqlXを使用することが推奨されているようなので、依存関係を追加しておきます。 [dependencies] axum = "0.6.20" serde_json = "1.0.108" shuttle-axum = "0.31.0" shuttle-runtime = "0.31.0" shuttle-shared-db = { version = "0.31.0", features = ["postgres"] } sqlx = { version = "0.7.2", features = ["runtime-tokio-native-tls", "postgres"] } また、SqlX CLIもインストールしておきます。 cargo install sqlx-cli SQLX CLIでルートパッケージからマイグレーションファイルを追加しておきます。 sqlx migrate add init これでmigrationsというディレクトリがルートパッケージに作成されるはずです。 続けてマイグレーションファイルにグループテーブルを作成するSQLを実装します。 とりあえずグループIDと期日があれば十分でしょう。 -- Add migration script here CREATE TABLE line_group ( id varchar(33) primary key, deadline_date date ); ちなみにグループIDは33桁の文字列で、C[0-9a-f]{32}という正規表現で表されます。 LINEプラットフォーム用語集 - グループID ...

Shuttleはいいぞ～、ナナオです。 今回で三回目になります、Shuttleのチュートリアル記事です。 複数のサービスを動かす shuttle_runtime::Serviceを実装してあげることで、Webサービスとスケジューラを同時に動かすようなユースケースが実装可能になります。 Page Not Found こちらのチュートリアルではdiscordのBOTを動かしていますね。 以前までの実装にスケジューラを追加して、継続的にログにhello worldを出力させてみましょう。 ただactix-webでの実装がわからなかったので、axumの実装に直しました。 また、スケジューラにはtokio-cron-schedulerを使用しました。 依存関係は以下のとおりです。 [dependencies] axum = "0.6.20" shuttle-runtime = "0.31.0" tokio = "1.26.0" tokio-cron-scheduler = "0.9.4" では、以下が完成したコードです。 use axum::{routing::get, Router, response::IntoResponse}; use tokio_cron_scheduler::{Job, JobScheduler}; async fn hello_world() -> impl IntoResponse { "Hello World!" } pub struct MultipleService { router: Router, scheduler: JobScheduler, } impl MultipleService { pub async fn new() -> Result<MultipleService, shuttle_runtime::Error> { let router = Router::new() .route("/", get(hello_world)); let mut scheduler = JobScheduler::new().await.unwrap(); scheduler.add( Job::new("1/10 * * * * *", |_uuid, _l| { println!("I run every 10 seconds"); }).unwrap() ).await.unwrap(); Ok(Self { router, scheduler, }) } } #[shuttle_runtime::async_trait] impl shuttle_runtime::Service for MultipleService { async fn bind(mut self, addr: std::net::SocketAddr) -> Result<(), shuttle_runtime::Error> { let server = axum::Server::bind(&addr); let (_runner_hdl, _axum_hdl) = tokio::join!(self.scheduler.start(), server.serve(self.router.into_make_service())); Ok(()) } } #[shuttle_runtime::main] async fn main() -> Result<MultipleService, shuttle_runtime::Error> { MultipleService::new().await } 順番に説明します。 ...

タダでもうれしいのはOSSだけ、ナナオです。 前回に引き続き、Shuttleを使ってみようと思います。 ワークスペースでプロジェクトをデプロイする shuttleはワークスペースをサポートしています。 これにより、複雑なコードをカプセル化しつつ、可読性高く開発することができます。 （私の最初のイメージでは、ワークスペースのメンバーそれぞれがプロジェクトとして独立した形でデプロイされるのかと思ってたんですが、ルートパッケージが一つのプロジェクトとして扱われるようになる感じでした…） Page Not Found ただし、既存のパッケージをプロジェクトとして独立させるみたいなことをするのは少し厄介です。 というのも、どうやらそもそもローカルにあるCargoディレクトリの移動ということが想定されていないためか、既にデプロイしているディレクトリを移動するとデプロイができなくなってしまいます。 また、内部的にgitのコミットを追っているというのもあり、gitの管理をいったん外すといったことができなくなります。 つまり、新たに作成したワークスペースのメンバーに既存のCargoパッケージを追加する場合、本来はルートパッケージ側でgitを管理したいのにそれができなくなってしまうということが考えられます。 （まぁこの辺は単に私のドキュメントの読み込み不足という可能性もあるので、その辺は指摘あればコメントください） ということで、前回の記事で作成したプロジェクトは一旦リモートのプロジェクトからは削除して、新たにワークスペース単位でリソース管理ができるようにしてみましょう。 まずはベースになるルートパッケージを作成します。 cargo new shuttle-playground 次に、前回作成したプロジェクトを削除します。 # 前回作成したshuttle-playground-nanaoを削除します # 削除前にサーバーを止めておく必要がある cargo shuttle stop # 停止後に削除ができるようになる cargo shuttle project delete これできれいになりました！ 次にルートプロジェクト内に前回のshuttle-playground-nanaoを移動します。 ローカルでの名前は変えておきましょうか。 mv shuttle-playground-nanao shuttle-playground/backend backendをワークスペースのメンバーに追加してあげます。 [workspace] members = [ "backend", ] このままのパッケージ名だとありふれているため競合してしまいますが、ルートパッケージ配下にShuttle.tomlを作成することで解決できます。 ここでは以前と同じ名前にしておきましょう。 name = "shuttle-playground-nanao" この状態で、ルートパッケージのファーストコミットを行っておきます。 git add --all git commit -m "first commit" ではデプロイしていきます。 # Shuttleプロジェクトを開始 cargo shuttle project start # プロジェクトにデプロイ cargo shuttle deploy デプロイ後、アクセスした様子が以下になります。 ...

Rustで無料で建てられるサーバーがあるだって？やったー！ナナオです。 今回はそんなshuttleが気になったので使ってみます。 Installation - Shuttle Docs Shuttleとは インフラ構築なしでバックエンドをデプロイできるサービスです。 firebaseと似たような、いわゆるBaaSってやつですね。 主な使い方としては簡易なWebサーバーの構築や、Discordクライアントとして使用できるようです。 無料プランの中でデータ永続化サービスとしてPostgresも使えるので、結構充実しています。 #[shuttle_runtime::main] async fn main( // automatic db provisioning + hands you back an authenticated connection pool #[shuttle_shared_db::Postgres] pool: PgPool, ) -> ShuttleRocket<...> { // application code } 以下のライブラリをサポートしているため、これらのライブラリの使用経験があればすぐにでもデプロイができると思います。 Axum Actix Web Rocket Warp Tower Salvo Poem Tide Thruster shuttle-next 早速使ってみる まずはshuttle cliをインストールしておきます。 cargo install shuttle CLIからshuttleアプリケーションを初期化できます。 質問形式でプロジェクトをセットアップできます。 > cargo shuttle init First, let's log in to your Shuttle account. If your browser did not automatically open, go to https://console.shuttle.rs/new-project ✔ API key · ******** What do you want to name your project? It will be hosted at ${project_name}.shuttleapp.rs, so choose something unique! ✔ Project name · shuttle-playground-nanao Where should we create this project? ✔ Directory · C:\Users\Nanao\Project\study\shuttle-playground Shuttle works with a range of web frameworks. Which one do you want to use? ✔ Framework · actix-web Creating project "shuttle-playground-nanao" in "C:\Users\Nanao\Project\study\shuttle-playground" Hint: Check the examples repo for a full list of templates: https://github.com/shuttle-hq/shuttle-examples Hint: You can also use `cargo shuttle init --from` to clone templates. See https://docs.shuttle.rs/getting-started/shuttle-commands or run `cargo shuttle init --help` ✔ Claim the project name "shuttle-playground-nanao" by starting a project container on Shuttle? · yes Project "shuttle-playground-nanao" is ready Your project will sleep if it is idle for 30 minutes. To change the idle time refer to the docs: https://docs.shuttle.rs/getting-started/idle-projects Run `cargo shuttle deploy --allow-dirty` to deploy your Shuttle service. You can `cd` to the directory, then: Run `cargo shuttle run` to run the app locally. APIキーが必要なため、事前にブラウザ側でshuttleのコンソールにログインしている必要があります。 ...