「Rust」の記事 - Crieit

【Rust/Ruby】OBS Studioの録画時間をスクリプトから取得してみる

2023-09-27T12:17:24+09:00

こんにちは、しきゆらです。
連休は出かけていてブログ書けませんでした。

今回は、最近ちょっと触っているOBSをプログラムから操作したり情報を取得できるということを知ったので、サンプルを見ながら情報を取得してみようと思います。

OBSのドキュメントは以下になります。詳しく知りたい方はこの辺を参考にするとよいかなと思います。

Welcome to OBS Studio’s documentation! — OBS Studio 29.1.3 documentation https://docs.obsproject.com/

上記を見るとC系での話が主なようですが、今回はよく使う言語であるRubyと、最近ちょっと触っているRustで書けることを目的として調べてみました。
どうやらOBSはWebSocket経由で操作することができるようです。

公式のリポジトリにもOBSのWebSocketプラグインがあるようで、v28以降のバージョンに対応しています。手元の環境では、初期状態で入っていてちょっと設定してあげればすぐ使えるようになったので、初めはこの辺を触ってみるのが良いかなと思います。

GitHub - obsproject/obs-websocket: Remote-control of OBS Studio through WebSocket https://github.com/obsproject/obs-websocket

Rubyから録画時間を取得する

上記を受けてRubyから操作するgemがないかな、と思って調べてみると非公式ながらありました。

GitHub - onyx-and-iris/obsws-ruby: Ruby clients for OBS Studio WebSocket v5.0 https://github.com/onyx-and-iris/obsws-ruby

まずは、RubyからOBSを操作するためにサンプルを見たり内部のスクリプトを見ながら録画時間を取得するコードを書いてみました。

require "obsws"

client = OBSWS::Requests::Client.new(
    host: "IPアドレスなど",
    port: ポート番号,
    password: "PWの文字列"
)
loop do
    p client.get_record_status.output_timecode
    sleep 1
end

上記コードはシンプルに1秒ごとに録画時間を取得してターミナルへ表示するコードです。

IPアドレスやポート番号などは、OBSの「ツール」>「WebSocketサーバ設定」から確認・設定可能です。

実際にスクリプトを実行しつつOBSで録画すると、録画時間が表示されました。

Rustから録画時間を取得する

では、同様のことをRustでやってみます。
RustからOBSのWebSocketを操作するcrateは、obs-websocketにリンクがあったこちらを使ってみました。

GitHub - dnaka91/obws: The obws (obvious) remote control library for OBS https://github.com/dnaka91/obws

サンプルや内部コード、エラーを修正しつつできたのがこちら。

use std::{thread, time};
use anyhow::Result;
use obws::{Client, client, requests::EventSubscription};

#[tokio::main]
async fn main() -> Result<()> {
  let sleep_time = time::Duration::from_secs(1);
  let config = client::ConnectConfig {
    host: "IPアドレス",
    port: ポート番号,
    password: Some("PW文字列"),
    event_subscriptions: Some(EventSubscription::all()),
    broadcast_capacity: Some(100),
  };
  let client = Client::connect_with_config(config).await?;

  loop {
    let outputs = client.recording();
    let status = outputs.status().await?;
    println!("outputs: {}", status.timecode);

    thread::sleep(sleep_time)
  };

  Ok(())
}

サンプルコードから動かしてみたのですが、諸々エラーだったりcrateが足りなかったりと動かず悪戦苦闘しながらここまで持っていきました。
Rustのお作法をきちんと理解できていなので躓いただけかもですが、動く状態まで持っていけてよかったなと。

これにて、Rustでも同様にターミナルに録画時間を表示することができました。

まとめ

今回は、OBS Studioの操作をスクリプトからできることを知ったのでRuby/Rustで簡単なサンプルを作ってみました。
どちらもライブラリが用意されているので、そこまで難しくはありませんでした。
また、Rustの勉強にもなったのでちょっと自信が付いたかもしれません。

今回はここまで。

おわり

Rustのconst genericsの引数によって型の定義を変える(っぽいこと)

2023-05-11T12:46:43+09:00

若干釣りっぽいタイトルです

やりたいこと

Vectorのような要素型と次元数を受け取るVector型があったとして

// x, yを持つ
let v2 = Vector:: { x: 1.1, y: 2.2 };
// x, y, zを持つ
let v3 = Vector:: {
    x: 1.1,
    y: 2.2,
    z: 3.3,
};
// x, y, z, wを持つ
let v4 = Vector:: {
    x: 1.1,
    y: 2.2,
    z: 3.3,
    w: 3.3,
};
// 要素数5の配列を持つ
let v5 = Vector:: {
    elements: [1.1, 2.2, 3.3, 4.4, 5.5],
};

のようにVector::はx, yを持つ、
Vector::はx, y, zを持つ、
Vector::はx, y, z, wを持つ、
D >= 5となるVector::は配列elements: [T; D]を持つ、
というような実装にしたい。

実装

実装全文。
重要なのはVectorTypeHolderとVectorTypeResolverです。

use std::marker::PhantomData;

pub struct Vector2 {
    pub x: T,
    pub y: T,
}
pub struct Vector3 {
    pub x: T,
    pub y: T,
    pub z: T,
    pub w: T,
}
pub struct Vector4 {
    pub x: T,
    pub y: T,
    pub w: T,
}
pub struct ArrayWrapper {
    elements: [T; D],
}

pub trait VectorTypeHolder {
    type Vector;
}
pub struct VectorTypeResolver {
    _marker: PhantomData [T; D]>,
}

impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector2;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector3;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector4;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = ArrayWrapper;
}

pub type Vector =  as VectorTypeHolder>::Vector;

解説

Vector2, Vector3, Vector4と配列をラップしたArrayWrapperはそれぞれ2~4次元の時に使用する型と5次元以上のときに使用する型です。
下記のVectorTypeHolderは要素型と次元数をgenerics引数として受けとりVectorという関連型を持つtraitです。

pub trait VectorTypeHolder {
    type Vector;
}

ここからVectorTypeHolderと型を取り出すためにVectorTypeResolverという型を定義し、VectorTypeResolverに対してVectorTypeHolderを実装します。

pub struct VectorTypeResolver {
    _marker: PhantomData [T; D]>,
}

VectorTypeResolverが持つ_markerはジェネリクス引数を消費するだけのものなので無視して大丈夫です。気になる方はPhantomDataを調べてください。
traitを実装するときconst genericsの値を指定して実装することができるため以下のようにDが2のときのみの実装を行うことができます。

impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector2;
}

同様にVectorTypeHolder::VectorがDが3,4のときにVector3, Vector4を、Dが5のときはArrayWrapperとなるように実装します。

impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector2;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector3;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = Vector4;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = ArrayWrapper;
}

最後にVectorとして型を取得できるように

pub type Vector =  as VectorTypeHolder>::Vector;

と型エイリアスを定義します。

ここまででで最初のやりたいことが実現できるようになりました。

Dが5より大きい場合

実はこの実装だとD > 5の場合にコンパイルエラーになります。
それを解消するには

impl VectorTypeHolder for VectorTypeResolver {
    type Vector = ArrayWrapper;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = ArrayWrapper;
}
impl VectorTypeHolder for VectorTypeResolver {
    type Vector = ArrayWrapper;
}
//
// 以下D >= 9の実装が続く
//

というように使用する分VectorTypeHolderの実装をする必要があります。
seq_macroクレートのseqマクロを使用すると以下のようにまとめて実装できます。

// use seq_macro::seq;
seq!(N in 5..256 {
    impl VectorTypeHolder for VectorTypeResolver {
        type Vector = ArrayWrapper;
    }
});

tonicを使ってgRPCサーバーを立ててみる

2021-11-27T13:51:05+09:00

gRPCサーバー＋grpc-webをバックエンドにしてWiki的なのをつくろうという気持ちがあるので、そのための実験をしています。今回はgRPCサーバーをRustでつくれるかの調査です。

ライブラリ選定

Rustで、Hello Worldを卒業した？次は、gRPCだよね！ | by FUJITA Tomonori | nttlabs | Medium というRust教な記事があり、ここで tonic が推されています。

私は別にRust教信者ではないですが、Rustだけで完結していると環境構築が楽そうなので、とりあえずtonicを試してみることにしました。‘grpc’ search // Lib.rs でもtonicが一番人気っぽいですし、まあたぶんよくできているのでしょう。

Hello world

tonic/helloworld-tutorial.md at master · hyperium/tonicに従ってHelloWorldします。

環境準備

Rust 2021 Editionに依存しているのでRust 1.56以降が必要というのはなかなか面白いですね。

エディタにはVSCode、補完にはrust-analyzerを使います。ここで注意点なのですが、READMEには

If you're using rust-analyzer we recommend you set "rust-analyzer.cargo.loadOutDirsFromCheck": true to correctly load the generated code.

とあるものの、この通りにやると "unknown configuration setting" とVSCodeに言われてしまいます。rust-analyzerのIssueによると、この rust-analyzer.cargo.loadOutDirsFromCheck 設定は rust-analyzer.cargo.runBuildScripts に改名された上に既定でオンになるようになったらしいです。つまり、特に何の設定もしなくてもよいということですね。

proto/sinanoki.proto

protocol bufferでAPI定義を書きます。なお、このsinanokiというのは単なる（私が作ろうとしているものの）プロジェクト名なので意味は無いです。

syntax = "proto3";
package sinanoki;

service PageManager {
    rpc GetPage(GetPageRequest) returns (GetPageResponce);
}

message GetPageRequest {
    string path = 1;
}

message GetPageResponce {
    string markdown = 1;
}

cargo.toml

[package]
name = "sinanoki-backend"
version = "0.1.0"
authors = ["suzusime <***@gmail.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
tonic = "0.6"
prost = "0.9"
tokio = { version = "1.0", features = ["macros", "rt-multi-thread"] }

[build-dependencies]
tonic-build = "0.6"

言われる通りにdependenciesの設定を追加します。今回はサーバーだけ（複数の実行ファイルはいらない）なので、binまわりの設定は飛ばしてserver.rsの代わりにmain.rsに書くことにします。

build.rs

ビルドに対して特殊な処理が必要になるので、ルートフォルダにbuild.rsを置きます。

fn main() -> Result<(), Box> {
    tonic_build::compile_protos("./proto/sinanoki.proto")?;
    Ok(())
}

src/main.rs

今までの設定をしてcargo buildすると、protocol bufferに書いたものに対応したサーバー／クライアントの雛型となるRustのコードがtarget以下に生成されるようになります。これを利用してサーバーを実装します。

例えば私の場合は target/debug/build/sinanoki-backend-1664b6d9540c1c9f/out/sinanoki.rs に雛型コードが吐かれました。この雛型コードの中に

    #[async_trait]
    pub trait PageManager: Send + Sync + 'static {
        async fn get_page(
            &self,
            request: tonic::Request,
        ) -> Result, tonic::Status>;
    }

というのがあるので、これをコピペしたものを使い、以下のようなコードをsrc/main.rsに書きます。

use sinanoki::page_manager_server::{PageManager, PageManagerServer};
use sinanoki::{GetPageRequest, GetPageResponce};
use tonic::{transport::Server, Request, Response, Status};

pub mod sinanoki {
    tonic::include_proto!("sinanoki"); // The string specified here must match the proto package name
}

#[derive(Debug, Default)]
pub struct MyPageManager {}

#[tonic::async_trait]
impl PageManager for MyPageManager {
    async fn get_page(
        &self,
        request: Request,
    ) -> Result, Status> {
        println!("Got a request: {:?}", request);

        let reply = GetPageResponce {
            markdown: format!("you requested a file of {}", request.into_inner().path).into(), // We must use .into_inner() as the fields of gRPC requests and responses are private
        };

        Ok(Response::new(reply))
    }
}

#[tokio::main]
async fn main() -> Result<(), Box> {
    let addr = "[::1]:50051".parse()?;
    let manager = MyPageManager::default();

    Server::builder()
        .add_service(PageManagerServer::new(manager))
        .serve(addr)
        .await?;

    Ok(())
}

実行

あとは

$ cargo run

して、

$ grpcurl -plaintext -import-path ./proto -proto ./proto/sinanoki.proto -d '{"path": "/index.md"}' localhost:50051 sinanoki.PageManager/GetPage
{
  "markdown": "you requested a file of /index.md"
}

で動作が確認できました。

所感

どうせ何かハマるだろうと思っていましたが、すんなり動きました。

困ったところを挙げるならば、（tonicに限らず）Rustの補完があまり気持ちよく動いてくれないことでしょうか。単にバグっぽいところ（implしようとしたときに勝手に出してくれるコードが明らかにおかしい）を除いても適切な補完候補がなかなか出てくれなくて、少し厳しいです。おそらく私の設定が悪いんだろうなと思っているのですが……。

M1 Mac上のRustでクロスコンパイルする

2021-05-16T21:45:14+09:00

（自ブログの転載です）

最近RustでCGIを書くなんてことをしていたのですが、諸事情でサーバー側にRustのコンパイラを入れられず、別のマシンでビルドしたバイナリをコピーして動かしました。その時はLinuxの別マシンでビルドしたのですが、開発機であるM1 Macでビルドできた方が楽なので、その方法を調べました。

クロスコンパイラをインストールする

まずは別のCPUを対象としてコンパイルするためのコンパイラ（クロスコンパイラ）をインストールする必要があります。今回は messense/homebrew-macos-cross-toolchains を使わせてもらいます。Homebrewでもインストールできるようですが、Release にあるビルド済みバイナリを用いるとお手軽です¹。

Releaseのページにはたくさんのtar.gzが並んでいるので、目的にあったバイナリをダウンロードします。私の場合は「M1 Mac (aarch64-darwin)上で」「x86_64のLinuxで動く、CライブラリとしてMUSLを使ったバイナリ(x86_64-unknown-linux-musl)を作る」ため、x86_64-unknown-linux-musl-aarch64-darwin.tar.gzをダウンロードしました²。

そして、これを解凍し、中のbinディレクトリにパスを通します。

現時点(2021/05/16)での最新版(v10.3.0)を使う場合、以上のことをするコマンドは次の通りです。

$ mkdir -p $HOME/tools && cd $HOME/tools # 適当なディレクトリ
$ wget https://github.com/messense/homebrew-macos-cross-toolchains/releases/download/v10.3.0/x86_64-unknown-linux-musl-aarch64-darwin.tar.gz
$ tar xf x86_64-unknown-linux-musl-aarch64-darwin.tar.gz # 解凍
$ export PATH="$HOME/tools/x86_64-unknown-linux-musl/bin:$PATH" # パスを通す
$ x86_64-unknown-linux-musl-gcc # パスが通っているか確かめる
x86_64-unknown-linux-musl-gcc: fatal error: no input files
compilation terminated.

なお、永続的に設定したい場合はexportは.zshrcなりのシェル設定ファイルに書いて下さい（以下同じ）。

Rustでクロスコンパイルできるようにする

まず、Rust側でターゲットを追加します。

$ rustup target add x86_64-unknown-linux-musl

これだけではRustがクロスコンパイラを見つけてくれないため、messense/homebrew-macos-cross-toolchainsのREADMEに従って次のように環境変数を設定します。

$ export CC_x86_64_unknown_linux_musl=x86_64-unknown-linux-musl-gcc
$ export CXX_x86_64_unknown_linux_musl=x86_64-unknown-linux-musl-g++
$ export AR_x86_64_unknown_linux_musl=x86_64-unknown-linux-musl-ar
$ export CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=x86_64-unknown-linux-musl-gcc

クロスコンパイルしてみる

以上で設定ができたはずなので、Hello worldプロジェクトで確かめてみます。

$ cargo new etude-cross
$ cd etude-cross
$ cargo build --target x86_64-unknown-linux-musl --release # クロスコンパイル
$ file target/x86_64-unknown-linux-musl/release/etude-cross # ファイル形式を確かめる
target/x86_64-unknown-linux-musl/release/etude-cross: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped

確かにELF 64-bitのバイナリができあがりました。

参考文献

Cross-Compiling Rust from macOS To Linux
- この記事では FiloSottile/homebrew-musl-cross を使っていますが、これはM1 Macでは動かなかったので(Apple silicon support? · Issue #23)、代わりに messense/homebrew-macos-cross-toolchains を使いました。
Cross-compilation - The rustup book

変なバイナリである可能性を排除できないのでセキュリティ的にはよろしくないかもしれませんが。 ↩︎
例えばラズパイで動かすバイナリが欲しいなど、別のアーキテクチャ用のバイナリが欲しい場合は以下の文章のx86_64-unknown-linux-muslの部分を適宜読み替えてください。 ↩︎

素朴な自作言語のコンパイラをRustに移植した

2021-04-10T06:46:21+09:00

移植一覧に戻る

やっつけなので汚いです。ライフゲームのコンパイルが通ったのでヨシ、というレベルの雑なものです。

https://github.com/sonota88/vm2gol-v2-rust

移植元

ベースになっているバージョン: tag:56 のあたり

メモ

理解は後回しにして、かっこ悪い書き方でもいいのでとにかく完成まで持って行く……といういつも通りの方針で、時間をかけすぎないように。理解は後でゆっくり。まずは手を動かして慣れる。
Tour of Rust
- 情報量が多すぎずよく整理されていて、一番最初にこれを読めばよかった
借用とかムーブとか
- このくらいのプログラムを書いて動かせる程度には分かってきた、はず。
  でもけっこう怪しい。
ライフタイム
- まだよく分かっていなくて、コンパイルが通らなかったらライフタイムが絡まない書き方にして回避したりしている
連結リストが難しそうだったので
Vec で管理する方式にしてとりあえず回避
レキサの入力文字列は最初に Vec にして使い回し
- C版や Zig版のように単純なバイト列として扱ってもよかったが、
  せっかくなので UTF-8 文字列として扱ってみた

TODO

気が向いたらあとで

List にノードID ではなくノードを直接持たせる
List のイテレータ対応

AWS Lightsail Containers に Actix web をデプロイする

2021-01-23T21:12:04+09:00

はじめに

Actix web で Web アプリケーションを作ったのですが、技術勉強も兼ねていたので、デプロイ先も今まで試したことがないものを試そうとしていました。そこで、日頃業務でも AWS を利用しているということもあり、去年末に発表された AWS Lightsail Containers をデプロイ先に採用しました。

AWS Lightsail Containers へのデプロイ自体は非常に簡単でした。また、デプロイにあたり Rust の Docker イメージ作成のやり方も学べました。今回はそのあたりの手順をまとめる形で記事として書き残しておくことにしました。

Actix web の Docker イメージを作成する

開発したアプリケーションでは React でフロントエンド開発をしていて、ビルドしたものを Actix web の public フォルダに配置する形で公開しています。そのため、下記の Dockerfile ではマルチステージビルドを利用しておりますが、本質的には FROM rust:1.49 以降の記述が Actix web に関するものとなります。

# React ビルド用のイメージ
FROM node:14.15.4-alpine3.10 as client_builder

ARG REACT_APP_API_URL
ARG REACT_APP_GYAZO_AUTH_URL
ARG REACT_APP_GA_UNIVERSAL_ID

WORKDIR /client
COPY ./client/package*.json .
RUN yarn install

ADD ./client .
RUN yarn build

# Actix web ビルド用のイメージ
FROM rust:1.49

# Actix web にアクセスするためのポートを公開する
EXPOSE 8080

# Actix web プロジェクトのフォルダをイメージに追加する
WORKDIR /server
ADD ./server .

# プロジェクトフォルダ内で `cargo install` してビルドを生成する
RUN cargo install --path .

# 不要になったファイル群を削除する
RUN ls | grep -v -E 'templates' | xargs rm -r

# React ビルド用のイメージでビルドした内容を Actix web ビルド用イメージに追加する
COPY --from=client_builder /client/build ./build
RUN mkdir tmp

# `cargo install` コマンドで生成したビルドを実行して Actix web を起動する
# 下記のコマンド名称は Cargo.toml 内の [package.name] に準ずる
CMD ["bloggimg-server"]

また、Docker ビルド時のオプション管理を楽にするため、Docker Compose を利用しました。単一の Docker イメージをビルドする際にも利用しておくことで、後々コンテナを追加して連携させたいときにも即座に対応できたりでオススメです。

# docker-compose.yml

# context に Actix web プロジェクトのパスを指定する
# args に Docker ビルド時に利用したい ARGS の値を環境変数で設定する
# image に Docker の <イメージ名:タグ名> を指定する (今回は Docker Hub にデプロイする想定)
# env_file に開発/動作検証時に利用したい dotenv ファイルを指定する
# ports にポートマッピングの設定を書く

version: '3.8'
services:
  app:
    build:
      context: ./
      args:
        - REACT_APP_API_URL=${REACT_APP_API_URL}
        - REACT_APP_GYAZO_AUTH_URL=${REACT_APP_GYAZO_AUTH_URL}
        - REACT_APP_GA_UNIVERSAL_ID=${REACT_APP_GA_UNIVERSAL_ID}
    image: n1kaera/bloggimg:v1.0.0
    env_file:
      - ./server/.env
    ports:
      - 8080:8080

上記を自分の Actix web プロジェクトに応じて改変し docker-compose up して動作検証します。動作検証ができ次第、docker-compose build を実行して Docker イメージをビルドします。ビルドに成功したら次は Docker Hub にイメージを push します。

Docker Hub にビルドしたイメージを push する

今回は AWS Lightsail Containers で使用するイメージの管理に Docker Hub を利用します。Docker Hub へ push する前に docker login --username= コマンドで Docker Hub へのログインを済ませておきます。

その後 docker-compose push コマンドで Docker イメージを Docker Hub に push します。

Docker Hub のページから、正常に Docker イメージが push できていそうか確認する

Docker イメージの push が成功していることを確認できたら、残りは AWS Console 上での作業になります。

AWS Console から Lightsail Containers Service を作成する

AWS Console にログイン後、Lightsail サービスを選択して Lightsail サービスのトップページへ遷移します。遷移したら Containers タブを選択し、Create container services ボタンから Container Service を作成します。

AWS Console へログイン後 Lightsail のページに遷移して、Containers タブを選択する

Containers タブを選択すると出てくる、Create container services ボタンをクリックする

Create container services ボタンをクリックした遷移先の画面で、リージョンやキャパシティ (Micro であれば 3ヶ月間のみ無料で利用可能) 等を選択して、名称を入力します。今回は最初にデプロイのための準備をすでに済ませているので、Container Service を作成するついでにデプロイ設定も行います。

デプロイ設定は Set up your first deployment の項目から行うことが可能です。

Set up deployment の部分をクリックして、デプロイの設定項目を表示する

Docker Hub イメージを利用してデプロイする際に必要な設定項目を入力する

コンテナのヘルスチェックのための情報を入力する

すべての情報入力が完了したら Create container services ボタンをクリックする

遷移後の画面下部の Deployment versions からデプロイ状況の確認が行える

正常にデプロイできていれば Deployment versions の項目が Active になる

デプロイが完了したら Public domain が発行されているはずなので、正常にアクセスして Web アプリケーションが利用できそうか確認します。Public domain は該当する Container Service のトップページから確認できます。

AWS Lightsail Containers のトップページにある Public domain から動作検証する

一通りの動作検証を行い、正常にデプロイできていそうか確認する

これで作業は完了です。新しい Docker イメージでデプロイし直したい場合は、Deployments タブの Modify your deployment リンクをクリックすれば可能です。

(おまけ) 独自ドメインで Container Service へアクセス可能にする

AWS Lightsail Containers では独自ドメインの紐付け及び、HTTPS 化も簡単に設定できます。Custom domains タブを選択した後、画面下部にある Create certificate リンクをクリックすることで設定画面を表示します。

Custom domain タブをクリックしてから、Create certificate リンクをクリックする

各種設定項目の入力が完了したら Create ボタンをクリックする

ドメイン検証のために、CNAME レコードの設定を求められるので各自で設定作業を行う

正常に CNAME レコードを設定した後、しばらく経つと Status が Valid になる

上記まで確認したら、Create certificate で設定したドメインの CNAME レコードに Public domain の値を設定しておきます。設定内容が反映され次第、独自ドメインへアクセスすることで HTTPS 経由で Container Service へアクセスできるようになります。

Custom domains で Container Service で起動しているサービスにアクセスできることを確認する

おわりに

AWS Lightsail Containers を利用して Actix web プロジェクトをデプロイする手順について簡単にまとめてみました。便利ではあるものの、個人開発で利用する分には価格面及び性能面で Lightsail Instance のほうが良いなと現時点では感じてしまいました。

しかし、日本リージョンが用意されていたりロードバランサーを備えていたり、簡単にスケールさせやすくかつ定額で利用可能なサービスであるというメリットを活かせる場面があれば有効活用できそうだなと感じました。

参考リンク

Actix web で HttpOnly な Cookie を設定する

2021-01-23T14:33:35+09:00

はじめに

最近 Rust を勉強するため、Actix web で Bloggimg という Web アプリケーションを作りました。その際、セッション管理のために Cookie を利用したのですが、その際の手順及び設定方法についてまとめておきます。

本記事では Rust や Actix web のインストール方法については説明しません。Mac であれば brew install rustup して rustup-init した後、PATH に $HOME/.cargo/bin を追加するだけで大丈夫なはずです。詳細なインストール手順については公式サイトをご参照ください。

開発環境については VSCode の Rust Plugin がオススメです。Rustup で Rust をインストールしている場合、設定から Rustup の PATH を $HOME/.cargo/bin/rustup にするだけで利用可能です。設定手順の詳細はこちらをご参照ください。

動作環境

Mac mini (M1, 2020)
- Rust 1.49
- Actix web 3

サーバー側で Cookie を設定するため、HTTP レスポンスヘッダーに Set-Cookie を含める形でセッション情報をクライアントへ渡します。その際、最低でも Cookie の属性に HttpOnly と Secure、SameSite=Strict は設定します。実際の Cookie を設定するための Actix web でのサンプルコードは下記になります。

use std::env;
use actix_web::{App, HttpServer};
use actix_web::cookie::{Cookie, SameSite};
use actix_web::{get, web, Error, HttpRequest, HttpResponse};

use serde::{Deserialize};

/// Cookie に設定するキー
/// 今回は cookie_test をキーとして使用する
/// 
const KEY: &str = "cookie_test";

/// 存在していれば、HTTP Request ヘッダーから Cookie 文字列を取得する関数
/// 
/// # Arguments
/// * `req` - actix_web::HttpRequest
/// 
/// # Return value
/// * Option - key=value; key1=value1;~ のような Cookie の文字列
/// 
fn get_cookie_string_from_header(req: HttpRequest) -> Option {
    let cookie_header = req.headers().get("cookie");
    if let Some(v) = cookie_header {
        let cookie_string = v.to_str().unwrap();
        return Some(String::from(cookie_string));
    }
    return None;
}

/// 存在していれば、特定のキーで Cookie に設定された値を取得するための関数
/// 
/// # Arguments
/// * `key` - Cookie から取り出したい値のキー
/// * `cookie_string` - get_cookie_string_from_header 関数で取得した Cookie の文字列
/// 
/// # Return value
/// * Option - Cookie に設定されている値を取得する
/// 
fn get_cookie_value(key: &str, cookie_string: String) -> Option {
    // 取得した Cookie 文字列を ; で分割してループで回す
    let kv: Vec<&str> = cookie_string.split(';').collect();
    for c in kv {
        // Cookie 文字列をパースして key で指定した値とマッチしたキーが存在するかチェックする
        match Cookie::parse(c) {
            Ok(kv) => {
                if key == kv.name() {
                    // key で指定した値とマッチしたキーが存在していたら、その値を取得する
                    return Some(String::from(kv.value()));
                }
            }
            Err(e) => {
                println!("cookie parse error. -> {}", e);
            }
        }
    }
    return None;
}

/// 特定のキーで環境変数から値を取得するための関数
/// 
/// # Arguments
/// * `key` - 環境変数から取り出したい値のキー
/// 
/// # Return value
/// * String - 環境変数の値を文字列として取得する
/// 
fn get_env(key: &str) -> String {
    match env::var(key) {
        Ok(value) => return value,
        Err(e) => println!("ENV: ERR {:?}", e),
    }
    return String::new();
}

/// 環境変数に設定された HTTPS の値が 1 か判定する
/// Cookie の属性に Secure を付与するか判定するのに使用する
/// 
/// # Return value
/// * bool - Secure 属性を付与するか判定するための真偽値
/// 
fn is_https() -> bool {
    return get_env("HTTPS") == "1";
}

/// Cookie に設定する値を扱う HTTP Query の定義
#[derive(Deserialize)]
pub struct CookieQuery {
    pub value: String,
}

/// Cookie を設定するために用意したルート
/// 
/// # Example
/// 
/// 例えば GET /cookie?value=test にアクセスした場合、
/// Cookie に cookie_test=test が設定されるようになる
/// 
#[get("/cookie")]
async fn set_cookie(query: web::Query) -> Result {
    // 設定したい Cookie を作成する
    // その際に Secure, HttpOnly, SameSite=Strict 属性を付与する
    let cookie = Cookie::build(KEY, &query.value)
            .secure(is_https())
            .http_only(true)
            .same_site(SameSite::Strict)
            .finish();

    // 作成した Cookie を HTTP Response の Set-Cookie ヘッダーに含めることで、
    // HTTP Response を受け取ったクライアントに Cookie をセットさせる
    return Ok(HttpResponse::Ok()
        .header("Set-Cookie", cookie.to_string())
        .body(""));
}

/// KEY で指定した Cookie が存在すれば、その値を返却する
/// KEY で指定した Cookie が存在しなければ、空の文字列を返却する
#[get("/")]
async fn index(req: HttpRequest) -> Result {
    let cookie_string = get_cookie_string_from_header(req);
    if let Some(s) = cookie_string {
        if let Some(v) = get_cookie_value(KEY, s) {
            return Ok(HttpResponse::Ok().body(v));
        }
    }
    return Ok(HttpResponse::Ok().body(""));
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .service(set_cookie)
            .service(index)
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

ザッとインラインコメントで説明していますが、
最も重要な set_cookie 関数について簡単に説明します。

Actix web には Cookie クラスが存在します。この Cookie クラスは Cookie 文字列を生成したり、パースしたりするのに役立ちます。set_cookie 関数では、Cookie を生成するための関数 Cookie::build を利用しています。

Cookie::build 関数を利用することで、メソッドチェインで Cookie の値や属性を設定できます。作成した Cookie は to_string 関数を使用することで文字列として出力できます。出力した Cookie 文字列を HTTP レスポンスヘッダーに Set-Cookie として設定すれば Cookie を設定できます。

動作検証

今回用意した Actix web のサンプルコードには 2つのエンドポイントを用意しました。

URI	説明
`GET /cookie`	`value` クエリで HttpOnly な Cookie を設定する
`GET /`	`GET /cookie` で設定した Cookie を確認する

cargo run で Actix web のサンプルを起動した後に、ブラウザで http://localhost:8080/cookie?value=sample にアクセスしてみます。またその際に HTTP レスポンスヘッダーを確認したいため、開発者ツールを開いておきます。

HTTP レスポンスヘッダーに Set-Cookie が含まれていることを確認する

Set-Cookie が含まれていることが確認できたら正常に Cookie が設定されているか確認します。

HTTP リクエストヘッダーの Cookie に cookie_test=sample が存在していることを確認する

実際にブラウザーにも Cookie が正しく設定されているか、開発者ツールで確認する

正常に Cookie がセットされていることが確認できれば作業完了です。Cookie の属性に Secure を設定した場合の動作検証は、環境変数に HTTPS=1 をセットして cargo run で可能です。

おわりに

Actix web で割と汎用的に使えそうな知識として Cookie の設定方法について、メモ的な記事を書いてみました。引き続き、Rust への理解を深めるために Bloggimg の開発を進めながら学習を進めていきます 🧑‍🎓

本記事の内容がセキュリティの観点から適切でない場合等はコメントでご指摘いただけますと幸いです。

参考リンク

📔 ブログを書く用途に特化した Gyazo のツールを開発してみた

2021-01-18T02:08:16+09:00

Gyazo を技術記事を書く用途で使っているので専用の便利ツールを作ってみた

はじめに

いつもブログ記事に載せるキャプチャ画像の編集 & アップロード先として Gyazo を利用させていただいているのですが、日々使っている中で不満に感じる点もちょくちょく出てくるようになってきました。

そのため、3連休を用いて Rust の勉強がてら Bloggimg というウェブアプリケーションを作ってみました。ソースコードは MIT ライセンスで GitHub のリポジトリにアップしております。ちなみに最初は Gyazo for Blog という名称で開発をしていたため、本記事内のスクショには Gyazo for Blog という文字列が出てきますが、現在は Bloggimg という名称になっております。。

Bloggimg を開発したのは、ブログ記事を書く際に利用する画像のアップロードから加工、マークダウンとして利用するまでのフローを最適化したかったからです。ブログ記事を書く際に、記事内で用いるスクショ画像の加工や、そのアップロードにすごく時間を取られてしまうなーと日頃から感じていたのでそれを解決したかったのです。✅

開発中に得た知見等については別途技術記事として書いて残す予定です。

考えていたこと

今回 Bloggimg の開発を行うに当たり、考えていた点は下記になります。

画像の編集ツールは引き続き Gyazo に用意されているものを使う
- 既に最高に使いやすい 👑
キャプチャ画像をアップロードする際に、自動的に特定のコレクションに紐付けるようにする
- 技術記事毎にコレクションを分けて管理しているため、技術記事を書いている最中にアップするキャプチャ画像は全て特定のコレクションにまとまっていて欲しい
ワークスペースのようなツールを目指し、ブログを書く時だけに使える機能を開発する
- 例えば、ワンクリックで画像マークダウンの記述がコピーできたり、画像のアップロードをし直しやすくするため画像削除がお手軽に出来るよう削除ボタンに即アクセス出来るようにしたり...

特にアップした画像を 自動的に特定のコレクションに紐付けるようにする については本記事で紹介しているウェブアプリケーションを作成するキッカケとなった点なので外せない点でした。

使い方

Bloggimg の使い方についてご紹介いたします。

ログインする

Bloggimg を利用するためには、まず Gyazo アカウントでログインして頂く必要がございます。トップページの右上にあるログインボタンから Gyazo アカウントでログインします。

1. トップページ右上に配置されたログインボタンから Gyazo アカウント認証を行う

2. Gyazo アカウント認証が正常に完了したら、再度トップページを開く

3. トップページを開いた時に Gyazo にアップした直近の画像が確認できるはずです

ログアウトする

ウェブアプリケーションからログアウトするには、ログイン後にトップページ右上に表示される ログアウト ボタンをクリックすることでログアウトできます。

ログイン後にトップページ右上に表示される ログアウト ボタンをクリックしてログアウトする

画像ファイルをアップロードする

画像は一枚でも複数枚でもアップロードすることが可能です。画像アップロードの方法としてドラッグ & ドロップとファイル選択ダイアログを用意しております。

画面中央の点線枠内に画像ファイルをドラッグ & ドロップするか、点線枠内をクリックしてファイル選択ダイアログから選択することで画像をアップロードできる

画像ファイルをアップロードする際に自動でコレクションを紐付ける

Gyazo トップページ左端にコレクションリストが表示されているので、画像を紐づけたいコレクションを選択します。新たにコレクションを作成する場合はコレクションリスト上部にある コレクションを作成 ボタンをクリックします。

1. コレクションリストの中から画像を紐づけたいコレクションを選択する

2. コレクションを選択後に遷移した先の URL 末尾のコレクション ID をコピーする

3. トップページの最上部に 2. で控えていたコレクション ID をペーストする

上記までのステップが完了し、正しくコレクション ID が入力できていれば、次回以降のファイルアップロード時に自動で指定したコレクションに画像が紐づくようになります。

アップロードした画像ファイルを編集する

画像ファイルのアップロード時や 画像の再読み込み ボタンをクリックすることで、最新 20件の画像リストを画面最下部にロードされます。画像リストの各項目ではプレビュー、編集、削除、マークダウンのコピーを行うことが可能です。

画像リストの各項目の機能概要図

プレビュー

サムネ画像をクリックすることで、Gyazo にアップした元画像をプレビューすることが可能です。サムネ画像では画像の判別がしにくい場合に詳細を確認するための機能となります。

アップした画像の詳細を確認するためにプレビュー機能を利用する

編集

編集は該当画像の Gyazo ページにて行えるように、タイトルをクリックすることで Gyazo ページを別タブで開きます。

別タブで開いた Gyazo ページから画像の編集作業を行う

削除

画像の削除は 画像の削除 ボタンをクリックすることで、削除を行うための画面に遷移します。削除しようとしている画像で間違いないか確認後、削除を行うという手順になっております。

Gyazo から選択した画像を削除する

マークダウンのコピー

マークダウンをコピー ボタンをクリックすることで、クリップボードにマークダウン形式で該当画像を表示するための記述をコピーすることができます。具体的には下記のような記述がコピーされます。

ブログを書く先がマークダウン形式での記述に対応していれば、そのままペーストするだけで画像を表示することが可能です。

![スクリーンショット 2021-01-11 17.10.11.png](https://i.gyazo.com/a3e219b5efb8494103432b369ee99534.png)

おわりに

この記事を書くのにも実際に Bloggimg を用いましたが、個人的に今までよりも Gyazo でブログ記事内で利用する画像に関する作業効率は上がったように感じました。ブログを書くという用途に Gyazo を利用されている方のお役に立てれば幸いです。

また、今後は下記の機能実装を進めていく予定です。

画像アップ時に自動でアスペクト比を維持した状態で画像のリサイズを自動で行う機能
画像アップ時のタイトルの接頭辞が指定できるようにする機能
編集した画像が自動的にコレクションに紐づく機能
- 心残りな点として編集した画像をコレクションに紐付ける機能は API でできなかったため、現在手動で行う必要があります。。Gyazo の API がコレクションの紐づけにも対応したら対応したいと考えています ✅

Serde入門 (1) Derive属性の裏側をちょっと覗く

2020-05-08T23:54:31+09:00

Serde入門

趣旨

Bayardという全文検索エンジンがあり保存されているドキュメントはJSON形式で取得できる. serde_jsonを使えば良いのだが, serde_jsonではhierarchical_facetというデータが上手く変換できない.

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
enum Episode {
    Jo,
    Ha,
    Q,
}

#[derive(Debug, Serialize, Deserialize)]
struct Human {
    id: String,
    name: String,
    appears_in: Vec,
}

fn main() {
    let ikari_shinji = Human {
        id: "1".to_owned(),
        name: "Ikari Shinji".to_owned(),
        appears_in: vec![Episode::Jo, Episode::Ha, Episode::Q],
    };
    let ikari_shinji_str =
        serde_json::to_string(&ikari_shinji).expect("cant't convert into string");

    println!("{}", ikari_shinji_str); // {"id":"1","name":"Ikari Shinji","appears_in":["Jo","Ha","Q"]}

    let ayanami_rei_str = "
    {
        \"id\": \"2\",
        \"name\": \"Ayanami Rei\",
        \"appears_in\": [\"/episode/Jo\", \"/episode/Ha\", \"/episode/Q\"]
    }";
    let anayami_rei: Human = serde_json::from_str(&ayanami_rei_str).unwrap();
    println!("{:?}", anayami_rei);
}

のayanami_rei_strをdeserializeしたい. 実行するとパニックが起きる.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("unknown variant `/episode/Jo`, expected one of `Jo`, `Ha`, `Q`", line: 5, column: 36)', src/main.rs:34:30

実はすごく簡単にこのエラーを消せるのですが, 今回はとりあえずserdeを概観し, Derive属性の裏側を覗き見てみましょう.

Serdeとは?

Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.

Serde - Docs.rs

シリアライズとは?

直列化とか訳されたりします. 一般にデータの直列化とはバイト列や文字列への変換を指します. 通常Rustの構造体などはメモリ上に散らばって存在し, これらを参照することで一つの実体のように見せています. 対してバイト列や文字列はメモリ上に直線的な列を作って保存されています. また文字列にしておけばファイルに保存することができます. デシリアライズはその逆に直列化したデータを復元する作業です. こうすることで特定のデータをRustで読み込んで操作できるようになります.

ここではRustのデータ構造を別のより一般的なデータ形式に変換する操作をシリアライズと定義することにします. デシリアライズはその逆です.

登場人物

Rustデータ構造 (以下データ構造)
Serdeデータ・モデル (以下データ・モデル)
データ形式

データ構造をデータ形式へと変換するのがSerdeの目的でした. 両者を仲介するAPIをデータ・モデルと呼んでいます.

The Serde data model is the API by which data structures and data formats interact.

つまりSerdeは二段階の処理を踏むわけです.

データ構造 ↔️ データ・モデル ↔️ データ形式

こんな感じで説明されるわけですがよく分かりませんよね.

データ形式

現在対応しているデータ形式はData formats -Docs.rsを参照してください.

Serdeの基本

Derive属性

基本的な使い方は簡単です. Derive属性の引数にトレイト指定することでSerialize/Deserializeトレイトをコンパイル時に実装してくれます.

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, Debug)]
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let point = Point { x: 1, y: 2 };

    let serialized = serde_json::to_string(&point).unwrap();
    println!("serialized = {}", serialized);

    let deserialized: Point = serde_json::from_str(&serialized).unwrap();
    println!("deserialized = {:?}", deserialized);
}

この際Cargo.tomlでは,

[dependencies]
serde = { version = "1.0", features = ["derive"] }

のようにserdeの追加とfeaturesでderiveを指定しておきます.

Serialize/Deserializeトレイト

Using Derive - Serde

Serialize/Deserializeトレイトで実装すべき振る舞いはserializeとdeserializeだけです.

pub trait Serialize {
    fn serialize(&self, serializer: S) -> Result
    where
        S: Serializer;
}

pub trait Deserialize<'de>: Sized {
    fn deserialize(deserializer: D) -> Result
    where
        D: Deserializer<'de>;
}

SerializeとDeserializeでは微妙にシグニチャが違いますが, 引数にSerializer/Deserializerという如何にもな名前の型を取ります.

どうやら具体的な変換方法はこれらに委譲されるようです. また具体的な変換処理はデータ形式で違ってきますので, Serializer/Deserializerトレイトを実装した型が必要になるわけです.

プリミティブ型には全てデフォルトのSerialize/Deserialize実装が存在します.

Serde provides such impls for all of Rust's primitive types so you are not responsible for implementing them yourself, ...

Serializing a primitive - Serde
Implementations on Foreign Types - Serialize
Implementations on Foreign Types - Deserialize

例えばstr型に対しては以下のようなトレイト実装が与えられます.

impl Serialize for str { #[inline] fn serialize(&self, serializer: S) -> Result where S: Serializer, { serializer.serialize_str(self) } }

要するに以下のようなコードがあった時に,

#[derive(Serialize)] struct Human { name: String, age: u8, appears_in: Vec, }

次のように展開されることになります.

use serde::ser::{Serialize, SerializeStruct, Serializer}; struct Human { name: String, age: u8, appears_in: Vec, } // This is what #[derive(Serialize)] would generate. impl Serialize for Human { fn serialize(&self, serializer: S) -> Result where S: Serializer, { let mut s = serializer.serialize_struct("Person", 3)?; s.serialize_field("name", &self.name)?; s.serialize_field("age", &self.age)?; s.serialize_field("phones", &self.appears_in)?; s.end() } }

これを実際にシリアライズすること考えてみましょう. Human構造体はSerializeトレイトを実装しているのでserializeメソッドが自動導出されています.

fn main() { let JO = String::from("Jo"); let HA = String::from("Ha"); let Q = String::from("Q"); let ikari_shinji = Human { name: "Ikari Shinji".to_owned(), age: 14, appears_in: vec![JO, HA, Q], }; // ikari_shinji.serialize(??); }

これでシリアライズはできるようになりましたが, 具体的な方法はserializerに委ねられます. この時点ではどのようなフォーマットで出力するのか定まっていないので当然と言えば当然ですが, 適切なSerializer型を定義することでikari_shinjiインスタンスをシリアライズできます.

Required methods - serde::ser::Serialize

Serializerトレイト

serializerはシリアライズ用のデータ・モデルでデータのシリアライズ用のAPIを提供します. 型に応じてメソッドが宣言されています. 例えば構造体ならserialize_structというメソッドをシリアライズの時に呼び出しています.

use serde::ser::{Serialize, SerializeStruct, Serializer}; struct Person { name: String, age: u8, phones: Vec, } // This is what #[derive(Serialize)] would generate. impl Serialize for Person { fn serialize(&self, serializer: S) -> Result where S: Serializer, { let mut s: SerializeStruct = serializer.serialize_struct("Person", 3)?; s.serialize_field("name", &self.name)?; s.serialize_field("age", &self.age)?; s.serialize_field("phones", &self.phones)?; s.end() } }

名前はSerde型の前に慣例的にserialize_というプレフィックスがつけられます.

Deserializerトレイト/Visitorトレイト

DeserializeプロセスはSerializeとは少し違います. 単純にいろんな入力が想定される点が違います. そのためDeserializerは更に処理をVisitorに委譲します.

serde::de::Visitor

説明が難しいので具体例としてTomlの場合は見てみましょう. toml::de::from_strには以下のような例が載っています.

use serde_derive::Deserialize; #[derive(Deserialize)] struct Config { title: String, owner: Owner, } #[derive(Deserialize)] struct Owner { name: String, } fn main() { let config: Config = toml::from_str(r#" title = 'TOML Example' [owner] name = 'Lisa' "#).unwrap(); assert_eq!(config.title, "TOML Example"); assert_eq!(config.owner.name, "Lisa"); }

from_strはこの入力文字列をDeserializerに渡して, deserialize関数内部で処理を実行します.

pub fn from_str<'de, T>(s: &'de str) -> Result where T: de::Deserialize<'de>, { let mut d = Deserializer::new(s); let ret = T::deserialize(&mut d)?; d.end()?; Ok(ret) }

さて元の例をcargo-expandで展開してみましょう. いろいろコードが増えますが, 実際の呼び出し場所は以下のようになります.

_serde::Deserializer::deserialize_struct( __deserializer, "Config", FIELDS, __Visitor { marker: _serde::export::PhantomData::, lifetime: _serde::export::PhantomData, }, )

Config構造体に対応してdeserialize_structが呼び出されています. __Visitorというマクロ展開によって生成されたインスタンスも渡されています. このインスタンスが実際の処理担うわけです. ここからが実際には大変なところで, 興味がある人は処理を追ってみてください.

まとめ

だいぶ内容がSerializerに偏ってしまいました. Serializeは比較的分かりやすいです. 例えばRustのコードをJSON化する場合どのような対応関係なのかはある程度予想がつきます. 少なくともRust側データ構造は決まっているからです. しかしDeserializeは比較的自由なJSONを型のきっちり決まったRustのデータ構造に仕立て直す必要があり, 自然と複雑化します. 例外はserde_jsonでシリアライズした者を復元する場合だけです.

いずれにしても特殊なデータ形式に対応したいという開発者以外が独自にSerializeとかDeserializeは不要です. 多くの場合は属性を付与することでSerialize/Deserializeの挙動をカスタマイズできます. 次はそれを

課題

BayardのJSONのデータをDeserializeする

[Need help with #serde(deserialize_with)

補足

補足では本論とは関係ないけど気になったことをメモしておきます. 良かったら読んでみてください.

Serdeの設計とSOLID原則

SOLID原則とは,

Single Responsibility Principle (SRP)

Open Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

の5つの原則の頭文字をとったものです.

LSPにつてはRustには継承を言語レベルで採用していません. ただこの原則が型の互換性(多態性)に関する原則だと見るとトレイト境界で強制できます. serializeメソッドはトレイト境界でSerializerトレイトを実装したSerializer型を引数に取るという条件を課すことでLSPを満たしているとも言えます. そもそも継承だけでインターフェースとかがない頃にメソッドのシグニチャを揃えようというような話だったのかなと想像します. 多態性を実現する手段が継承しかない場合はこのような原則で縛りを設ける必要はありそうです. Rustの場合

(あらゆる型の)スーパークラスであるTと境界を設定したサブクラスは代替可能である

と表現すればそのまま当てはまりそうです.

さてserializeメソッドはシリアライズの実行だけを担い, データの変換はSerializer型が提供するAPIが担いました. 一見すると分けすぎな気もしますが, 様々なデータ形式に対応する時にserialzierを別にしておくことで拡張性が保たれることが分かります. 社会でも指示を出す人と実行する人の役割は違うようにserializeの指示を出すのと実際のデータの変換という役割を適切に分離していると考えることもできます.

ここでSerializerは依存性として外側から引数として渡されるような設計になっています. いわゆる依存性注入(DI)です. すでに述べましたがこの依存性はSerializerトレイトを実装している型であれば互換性があります. そもそもSerialize自体もトレイトであり抽象に依存する良い設計と言えそうです(DIP). Serde可能なデータ形式を追加したい開発者はこの関係に従って(縛られて?)ひたすら実装を行うだけです.

逆にISPは満たしていないように見えます. Implementing a Serializerにも

The Serializer trait has a lot of methods ...

とあります. トレイトの粒度としては荒いと言えます. これは不要なメソッドの実装も取り敢えずしなくてはいけないことになります. ~~ser.rsの実装を見ると萎えます~~ ではカスタマイズが必要な場合独自のSerializer型を実装する必要があるのかというとserde属性を使うことで特定の要素だけをカスタマイズできるようになっています. 例えばデシリアライズでデフォルト値を設定したい場合は

#[serde(default)]

を付与することで可能です.

最後はOCPです. この原則は少し分かりにくいですが以下のように表現されます.

the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"

Open–closed principle - Wikipedia

(機能の追加自体がmodificationじゃないのかという感じはしますが)要するに他のコードへの変更なしに新しい機能を追加できるかということです. Implementing a Serializerのser.rsを見てみましょう. データ構造, Serialize/Serializerトレイトがエンティティで機能の呼び出し側はto_stringという関数です.

pub fn to_string(value: &T) -> Result where T: Serialize, { let mut serializer = Serializer { output: String::new(), }; value.serialize(&mut serializer)?; Ok(serializer.output) }

OCPに適うということは, ある機能を拡張した場合に, このロジックに変更がなければ良いわけです. 今オレオレデータ形式がserde可能だとして考えましょう(oreクレートとでも呼びましょうか). ここでserializerに新しい型が対応したとしましょう. 例えばRustがxxx型に対応したとします(例えばf128型とか?あるいはクラスが追加されたとか?). 慣例に倣ってserialize_xxxが必要になりますが, to_stringのロジックに変更は必要ありません. OCPも満たしているようです.

Sedeの面白いところは, Derive属性やserde属性を使うことでエンド・ユーザーはこうした実装を何も考慮しなくてもデータの変換が行えるようにしていることです. 反面黒魔術を多用しているためコードを読むのは難しいですが.

Required methodsとProvided methods

Docs.rsにはこのような分類があるのですがRustでメソッドや関数に実装をオプションにするような構文があるという話は知りません. 私の勉強不足かとも思いましたが, 単純にデフォルトの実装の有無で見分けているようです.

How does Rust know which trait methods are required or provided?

実際にserde::de::Visitorを見てみるとexpectingメソッドはシグニチャの宣言だけです.

fn expecting(&self, formatter: &mut fmt::Formatter) -> fmt::Result;

一方visit_boolメソッドはエラーを返すような仕様になっています.

fn visit_bool(self, v: bool) -> Result whereE: Error, { Err(Error::invalid_type(Unexpected::Bool(v), &self)) }

matchガード

Derive属性で自動導出した場合どのようなSerializeトレイトが実装されるのでしょうか.

use serde::{Deserialize, Serialize}; #[derive(Serialize)] struct Human { name: String, age: u8, appears_in: Vec, } fn main() { println!("cargo expand") }

これをcargo-expandで展開すると以下のようなSerializeトレイトが実装されます.

let mut __serde_state = match _serde::Serializer::serialize_struct( __serializer, "Human", false as usize + 1 + 1 + 1, ) { _serde::export::Ok(__val) => __val, _serde::export::Err(__err) => { return _serde::export::Err(__err); } };

適切なSerializerメソッドが呼び出されているのが分かります. Match式は式を後置できるのでmathから波括弧までの間が式で, その戻り値でOkかErrかで判断されます. こういうのはMatch guardsというらしいです. 何らかの形でMatch式が使われていることは予想していたのですが実際のコードを見てみると面白いですね.

triマクロ

例でserde_jsonではなくtomlを使ったのはsede_jsonはserialize/deserializeを呼び出さないことと, triマクロを使っているので説明に適さないと思ったからです.

macro_rules! tri { ($e:expr) => { match $e { crate::lib::Result::Ok(val) => val, crate::lib::Result::Err(err) => return crate::lib::Result::Err(err), } }; }

lib.rs - serde-rs /json

参考

The Serde Book
serde - Docs.rs
toml - Docs.rs

cargo-makeによるプロジェクト・ビルド入門

2020-04-26T21:58:35+09:00

cargo-makeによるプロジェクト・ビルド

モチベーション

cargoはrustのパッケージ管理ツール兼ビルドツールである.これい自体非常に便利なのだが, Web標準は無視できない. 特にSeedのようなWebフロントエンド・フレームワークによる開発ではWeb標準に合わせる必要も出てくる. 単純なケースではQuickstartに従ってindex.htmlに直接wasmモジュールを導入すれば良いのですが, 複雑なアプリなどはwebpackなどが使えた方が便利だと思います. 今回のケースではTailwindの導入などがそれに当たります.

目標

CSSフレームワークであるtailwindcssをSeedプロジェクトで利用する.

前提条件

rustupの導入

とりあえずこれを導入しておけば諸々の開発環境の導入・管理が行えるようになります.

NPM vs Cargo

機能 NPM Cargo 備考

パッケージ管理 ⭕️ ⭕️ パッケージのインスタール・公開などができる

依存性管理 ⭕️ ⭕️ lockファイルがある点など共通点が多い

タスク・ランナー ⭕️ ❌ Cargoではカスタム・コマンドが開発できる(はず)

ビルド ❌ ⭕️ NPMでは代わりにタスク・ランナーを使う

コマンド拡張 ❌ ⭕️ タスク・ランナーから呼び出せば良い

Cargoにはnpm-scriptsのようなタスク・ランナーがありませんが, カスタム・コマンドで機能を拡張することができます. その一つがcargo-makeです.

cargo-makeによるプロジェクト管理

seed-quickstartのMakefile.toml内容を解説する感じです. wachモードなどはEvaQL/ui/Makefile.tomlを参照してください.

cargo-makeの導入

cargo-makeの実行にはcargo-makeバイナリが必要になるのでインストールしておきます.

cargo install --force cargo-make

次にプロジェクトを作成します. これもコマンド一つでできます. 今回はwasmモジュールとして読み込まれるので--libオプションをつけます.

cargo new --lib project-name

できたらプロジェクト・ルートに移動し実行してみましょう.

cago make

この時点ではデフォルトのtomファイルが参照されます. 次にMakefile.tomlファイルを作成します.

cd project-name touch Makefile.toml

同様に実行すると今度はMakefile.tomlをもとに実行が行われます. 任意のmakefileを指定するには--makefileオプションを使います.

cargo make --makefile ./my_build.toml test

Makefile.tomlの書き方

seed-quickstart/Makefile.tomlの解説です. 必要ない方は飛ばしましょう.

タスク

実行するコマンドはタスクという単位で管理します. 何もしないタスクは以下のようになります.

[tasks.do_nothing] # do nothing

基本

cargoのbuildサブコマンドを呼び出してみましょう.

# cargo make compile [tasks.compile] description = "Build" workspace = false command = "cargo" args = ["build"]

それぞれの意味は以下のようになります.

セクション意味

description このタスクの内容

workspace workspaceでタスクを実行するかどうか

command 実行するメイン・コマンド

args 引数の指定

依存タスク

dependencies属性を指定するとコマンドの依存性を指定できます. 要するに呼び出し順序です.

# cargo make start [tasks.start] description = "Combine the build and serve tasks" workspace = false dependencies = ["build"]

これでcargo startを実行するとbuildタスクが実行されます.

開発サーバーと環境変数

開発サーバーとしてmicroserverというクレートを使います. 簡単なWeb UIの開発には便利そうなのとクレート導入の例として紹介しておきます. 開発の趣旨を開発者の人がブログに書いています.

Microserver: local http server with SPA support

今回のようにあるタスクの前提となるバイナリ・クレートのインストールも記述できます.

[tasks.serve] description = "Start server" install_crate = { crate_name = "microserver", binary = "microserver", test_arg = "-h" } workspace = false command = "microserver" args = ["--port", "${PORT}"]

サーバーということでポートの指定もしています. 環境変数もenvセクションで指定できます.

[env] PORT = "8000"

別ファイルに指定して読み込むこともできます.

[env] env_files = [ "./my_env.env", ]

conditionによる条件設

ある条件を満たすときにタスクを実行することもできます. 環境変数がきちんと指定されている場合だけ実行するという条件ならconditionセクションをタスクに追加します.

[tasks.start] condition = { env_set = [ "PORT" ] }

あるいは特定の環境変数を条件にして新しい変数を定義することができる.

[env] PORT_EXISTING = { value = "true", condtion = { env_set = ["PORT"] } } PORT = { value = "8000", condition = { env_not_set = ["PORT"] } }

条件によって読みやすい環境変数に変換したり, 環境変数が定義されていない場合に設定したりということができそうです.

profileによるモードの切り替え

webpackのモードの指定ののようなこともできます.

[env] env_files = [ { path = "./development.env", profile = development }, { path = "./production.env", profile = "production } ]

cargo make --profile production some_task

developmentはデフォルト値なので指定する必要はないです.

タスクの拡張とリリース・ビルド

タスク名をextend属性で指定するとタスクを拡張できます. 例えばcompileタスクをリリース・モードでビルドするように拡張すると以下のようになります.

[tasks.compile_release] description = "Release Build " extend = "compile" args = ["build", "--release"]

プラットフォームごとの拡張も簡単にできます.

[tasks.hello-world] script = [ "echo \"Hello World From Unknown\"" ] [tasks.hello-world.linux] script = [ "echo \"Hello World From Linux\"" ] [tasks.hello-world.mac] script = [ "echo \"Hello World From macOS\"" ]

スクリプティング

シェルスクリプトを指定して実行することもできます.

[tasks.echo] script = [ "echo hello world" ]

script_runner属性を指定することでpythonなどスクリプトのランナーを指定できます.

[tasks.python] script_runner = "python" script_extension = "py" script = [ ''' print("Hello, World!") ''' ]

またファイルを指定して実行することもできます.

[tasks.run_from_script] script = { file = "hello.py" }

@rustの指定でRustを実行することもできます.

run_tasks

実行するタスクを指定します. dependenciesで指定したタスクは事前に実行されますが, run_task属性で指定したタスクは事後に実行されます.

[tasks.pre_task] script = [ "echo pre task"] [tasks.post_task] script = [ "echo post task"] [tasks.do_something] dependencies = ["pre_task"] run_task = "post_task"

この例の場合pre_task -> do_something -> post_taskの順で実行されます. 並列実行やフォークなど細かいタスクのフローを設定することできます. 詳しくはSub Taskを参照してください.

エイリアス

タスクを別名で参照できます.

[tasks.build] alias = "default_build"

Seedのexamplesフォルダは複数のクレートが含まれており, そこにはMakefile.tomlが存在します. それぞれのクレートではプロジェクト・ルートのMakefile.tomlを拡張する形でルートのタスクを参照しています. つまり実行する処理は同じといことです.

条件付き実行

条件を満たした場合にタスクが実行されます.

[tasks.test-condition] condition = { platforms = ["windows", "linux"], channels = ["beta", "nightly"], profiles = ["development", "production"], rust_version = { min = "1.39.0", max = "1.42.0" } } script = [ "echo \"condition was met\"" ]

このタスクはmacでstableチャネルを利用している人は実行されません. またscriptの代わりにrun_taskで他のタスクを条件を満たした時だけ実行するということもできます.

watchモード

watch属性をつけるとwatchモードで実行できます.

[tasks.run_from_script] script = { file = "hello.py" } watch = true

監視対象からの除外のような設定もできます.

[tasks.watch] description = "Start building project in watch mode" workspace = false dependencies = ["build", "build_wasm"] watch = { ignore_pattern="pkg/*" }

watchモードでサーバーを起動することはできません. この場合run_taskのparallelを使うとファイルの変更を監視しながら配信もで可能です.

[tasks.dev] description = "Build in watch mode while serving file" run_task = [ { name = ["watch", "serve"], parallel = true } ]

tailwindcssの導入

npmを使います.

npm init # if needed npm install tailwindcss

これでtailwindというコマンドがパッケージ上で使えるようになります. cssフォルダを作成して以下の内容をstyle.cssファイルを新規作成します.

@tailwind base; @tailwind components; @tailwind utilities;

これをビルドして利用します. publicフォルダを同じ階層に作っておいて, css用のフォルダを作ります. carg-makeのタスクを追加しましょう.

# cargo make tailwind [tasks.tailwind] script = [ "npx tailwind build ./css/style.css -o ./public/css/style.css", ]

style.cssからstyle.cssが出力されますが中身を見ると見れ慣れたCSSファイルです. 出力されたファイルをpublic/index.htmlに読み込めばtailwindが提供するユーティリティ・クラスを利用できます.

Seedでtailwindを使ってみましょう. Seedの説明はしませんがRustのマクロを使って要素を記述できます. 注目するのはclassマクロです. ここに指定された文字列がtailwindcssのユーティリティ・クラス名です.

fn view(model: &Model) -> impl View { let button_class = class!["bg-gray-400", "px-8", "py-4"]; div![ class![ "flex", "flex-col", "justify-center", "items-center", "h-screen", "text-gray-600" ], button![ button_class, simple_ev(Ev::Click, Msg::Increment), format!("Click Me!") ], div![ class!["w-56", "text-center", "mt-2"], format!("Click {} times", model.counter) ] ] }

こんな感じの表示になりちゃんと表示されました(クリック時にカウント数を表示するラベルが動くバグがありますが・・・)

まとめ

もうちょっとまとまりがあれば良いと思ったのですが, 意外と機能が多く詳細は公式のREADME.mdを読むのがいいと思います. examplesフォルダに例が豊富なので参考になると思います.

tailwindcssはかなり使いやすいですしSeedもいい感じです(ただビルドが遅いですが・・・).

補足

WorkspaceとWorkspace Flow

タスクにworkspace属性を指定できました. Workspaceとは何でしょうか?

A workspace is a set of packages that share the same Cargo.lock and output directory.

Cargo Workspaces - The Rust Programming Language

要するに複数のパッケージを一つにまとめたものです. ただし単一のプロジェクトとして管理される前提なので最終生成物やCargo.lockなどで全体のクレートのバージョンなどは共通化されています. 実態は以下のような内容のCargo.tomlとmembers属性で指定されたメンバーとなるパッケージが存在するフォルダです.

[workspace] members = [ "client", "server", ]

こうした構成はSeedのserver_integrationという例が参考になると思います. 例えば適当なウォークスペースにmakefileを作りworkspace属性を指定します.

[tasks.do_something] workspace = false

なぜこのような設定が必要なのでしょうか. 通常cargo-makeのタスクはworkspace直下では実行されません. タスクの要求はメンバー・クレートで実行されます(workspace flow). このおかげでウォークスペースで実行したビルド処理が各クレートで実行されることになり, 共通の処理をウォークスペースにまとめられるので構成ファイルを小さくできます.

しかしウォークスペースで実行したい場合もあるでしょう. その場合にこの機能をオフにするのがworkspace属性の意味です. この値はデフォルトでtrueになっています.

[config] default_to_workspace = false

のようにも指定するとデフォルト値をfalseに上書きできます.

あるいはコマンド実行時にオプションとして渡すこともできます.

cargo make --no-workspace mytask

CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILEフラグ

CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILEフラグはウォークスペース直下のmakefileに指定します. そうすると自動的に個々のメンバー・クーレトが持つmakefileはルートのmakefileをextendで読み込み参照できるようになるようです.

WASM in A Nutshell

WebAssemblyという技術の略称がWASMでコードの拡張子にもなっている. 通常ブラウザはJavaScriptのランタイムを備えており(V8やスパイダーモンキー)JavaScriptのみを実行できる. JIT(Just In Time)コンパイラによる最適化など高速化されたが, 原理的にはランタイムはJavaScriptを逐次解釈してマシンコードに翻訳しそれを実行するために遅い. このプロセスを飛ばせれば, ネットーワークにるRTT(Round-Trip Time)を無視すればネイティブ並みに高速化できるわけです. これはPythonやRubyなどのインタプリタ言語がC/C＋＋やRustなどの言語より遅い事と基本的には同じ関係と言えそうです.

そこでWeb版のアセンブラを導入しようという話になるわけです. 通常アセンブリ言語はマシン語と1対1に対応するニーモニックを用いて表現されますが, WASMがターゲットとするのは複数のマシンを抽象化したマシンになります.

So WebAssembly is a little bit different than other kinds of assembly. It’s a machine language for a conceptual machine, not an actual, physical machine.

Creating and working with WebAssembly modules

この説明を聞くとJavaに近い感じを受ける. 実際に(この比較はおかしいけど)WASIとJavaの類似性を指摘した記事なんかもある.

MozillaがWASIイニシアティブを発表、WebAssemblyをすべてのデバイス、コンピュータ、オペレーティングシステムで動作可能に

また公式ではWASMを以下のように定義している.

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.

WebAssembly

スタック・マシンは良くわからないけどWikipediaによるとJava仮想マシンも似たような定義で紹介されている.

Java仮想マシン (Java virtual machine、Java VM、JVM) は、Javaバイトコードとして定義された命令セットを実行するスタック型の仮想マシン。

Reference

The Cargo Book

cargo-make

Makefile.toml - seed-quickstart

View - Seed

Installation - tailwindcss

例題

タスクの依存関係, watchモードやcrateの導入などcargo-makeの基本的な使い方を学べる.

seed-quickstart

examplesフォルダからルート・フォルダにあるMakefile.tomlの参照法などが参考になりました.

examples -seed

課題

SeedのようなWebフロントエンドの開発では, プロジェクトをcargoパッケージとしてマインに構成するのかnpmパッケージとしてメインに構成するのかが問題になる. cargo-makeがない場合はnpmパッケージ以下にcargoパッケージを作らないとビルド・プロセスが自動にできない. seed-quickstart-webpackもwebpackを使ってrustライブラリのビルドからwasmモジュールの読み込みなどを行なっている. これをcargo-makeベースに置き換えたい. npm-scriptでコマンド化しておけば, cargo-makeから呼び出せる.

seed-quickstart-webpack

Further Reading

A crash course in assembly
A cartoon intro to WebAssembly
What makes WebAssembly fast?

依存先のcrateのfeatureを指定する方法

2019-11-01T20:31:16+09:00

依存先のcrateのfeatureを有効にする方法

結論

cargo build --features="grpcio/openssl"でgrpcioのopensslを有効にできる。

Cargo.tomlが下記のようになっていれば
cargo build --features="openssl"で同じことができる。

[features] openssl = ["grpcio/openssl"] [dependencies] grpcio = "0.4.4"

やりたかったこと

grpcioというcrateでfeatueres = ["openssl"] を指定してやることができる。

cargo buildのようにfeaturesを指定しなかったときはgrpcioのfeaturesを有効にしたくない。
cargo build --features=opensslなどしたときだけgrpcioのopensslを有効にしたい。

ドキュメントに書いてあった

https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section

以下引用

# Features can be used to reexport features of other packages. The `session` # feature of package `awesome` will ensure that the `session` feature of the # package `cookie` is also enabled. session = ["cookie/session"]

ここに気づかずに数時間無駄にした。

コンピューター囲碁を作ろうぜ☆（＾～＾）？＜書きかけ＞

2019-09-12T20:14:47+09:00

「　コンピューター囲碁を作るかだぜ☆
↓ググれば　なんでも載ってるだろ……☆」

Rust で TCP/IP ソケット通信をする際のモデル

「　コンピューター囲碁のポート番号は 9696 だったかだぜ☆？」

C:\Users\むずでょ\source\repos\kifuwarabe-air2019

「　↑ソース・レポジトリ作っておくわよ」

kifuwarabe-air2019

「　↑ギットハブも用意しておいたぜ☆」

Rust

「　↑近年 Rustは仕様が変わったみたいだし見ておくかだぜ☆」

book

「　↑説明書はこれかだぜ☆」

installation

「　↑Rustのインストールには rustup を使えと書いてあるぜ☆
わたしは既に古いのが入っているから　アップグレードだな☆」

「　↑Visual Studio Code には Terminal も付いている☆ Powershell でやってしまおうぜ☆」

rustc --version

「　↑よし、最新版になったぜ☆」

Hello, Cargo!

cargo --version

「　↑まあ　基本 cargo を使うんだけど☆」

「　きふわらべちゃんのプロジェクトを作りましょう！」

cargo new kifuwarabe-air2019

「　↑はい☆」

「　↑ Cargo.toml の内容は何もいじらなくても書かれていたぜ☆　完璧だぜ☆」

cargo build

「　↑ .exe ファイルも作られているな☆」

cargo run

「　↑ ちゃんと実行もされるぜ☆」

「　Visual Studio Code で十分だな☆」

「　↑ しかし　ソース・レポジトリのコードを　GitHub の　ローカル・レポジトリにコピーするのは　めんどくさいよな☆」

go-to-git.ps1

# + # | UTF-8 with BOM (Powershell) # | # | Folder copy. # + # + # | フォルダをゴミ箱に移動する # + function Remove-FolderToRecycleBin($dir) { if (Test-Path $dir -PathType Container) { $fullpath = (Get-Item $dir).FullName # + # | こんな変なパスぜったい間違う☆（＾～＾）チェックだぜ☆（＾～＾） # + if ($fullpath -cmatch ".*\\kifuwarabe-air2019\\kifuwarabe-air2019") { Write-Host "Remove | [$fullpath] directory." Remove-Item $fullpath -Recurse } else { Write-Host "Ignore | [$fullpath] directory." } } else { Write-Host "Ignore | [$dir] is not directory or not found." } } $sr = "C:\Users\むずでょ\source\repos\kifuwarabe-air2019\kifuwarabe-air2019" $ds = "C:\Users\むずでょ\Documents\GitHub\kifuwarabe-air2019\kifuwarabe-air2019" Remove-FolderToRecycleBin($ds) Write-Host "Copy | [$sr] --to--> [$ds]." Copy-Item $sr -destination $ds -recurse

「　↑ 必死こいて Powershell 書く☆」

「　powershell ./go-to-git.ps1 と打鍵するのが　うんこ　じゃないか☆？」

「　Visual studio code の Explorer で右クリックして File explorer 開いて .ps1 ファイルをダブルクリックするからＯＫ☆」

「　↑ あとは Git hub desktop でなんとかする☆」

cargo check

「　↑ コーディングのチェックをしてくれたりするのだろうか☆？　あとで使おう☆」

cargo build --release

「　↑ デバッグを外して .exe を作るには --release を付ければいいらしい☆　これ１つ忘れるだけで大会では　クソとノーマルの差が分かれる☆」

ロガーを用意しろだぜ☆（＾～＾）

「　ロギングできるかどうかで　プログラマーは　クソとノーマルに大きく分かれるのに　公式のマニュアルに書いてないな☆」

Rust：logでログ出力を行う
 Rustでのロギング
 Crate log
Configure Logging

「　ここらへんの連中は　ログをファイルに書き込まないのだろうか☆？
stderr へのストリーム出力からファイルへリダイレクトが基本かだぜ☆？」

「　遅～いロガーを掴んだらコンピューターは弱くなるわよ？」

env_logger

「　じゃあ env_logger 一択な気がするな……☆ 使ってみるかだぜ☆？」

「　こんな風に真似して Cargo.toml を書いていけばいい☆
１９９０年代のジャパンなら　友だちの友だちをたどっていけば　パソコンオタクの眼鏡のお兄さんがどこかに居て
家までやってきて　パソコンのコマンドの叩き方とか教えてくれたが、
２０１９年頃のジャパンでは　学校のパソコン部に入ったのに何もせずに卒業して　ブログのエントリを書いて
いいね！　が付くのが流行りみたいだぜ☆」

「　何も　いいね！　ではないわよね。　何が　いいの　かしら？」

「　承認欲求が満たされたのだろう☆」

main.rs

#[macro_use] extern crate log; extern crate env_logger; fn main() { env_logger::init(); println!("Hello, println!"); trace!("Hello, trace!"); debug!("Hello, debug!"); info!("Hello, info!"); warn!("Hello, warn!"); error!("Hello, error!"); }

「　↑こういうコードがあるとして……☆」

「　↑環境変数を使って　これだけ使い分けれれば十分だろう……☆
なんか Hello, println! の出るタイミングがバラバラだな……、非同期か☆」

「　で、 PowerShell って　どうやって　ストリームをリダイレクトするんだぜ☆？」

PowerShellでのエラーハンドリングについて

command 2>&1 >> ./kifuwarabe-air2019.log

「　↑で　いいのでは☆？」

「　ほんとか☆？」

「　↑コマンドの一覧がログ・ファイルに書き出された……☆　ということは☆」

cargo run 2>&1 >> ./kifuwarabe-air2019.log

「　↑こうかだぜ☆？」

「　それだと cargo の引数になるんじゃない？」

「　一応 >> が利いたのかファイルに追加書き込みされているが、標準出力に何もでなくなったぜ☆」

cargo run 2>> ./kifuwarabe-air2019.log

「　だったら単に標準エラーの2 を追加書き込みのリダイレクト >> でファイルに送る指定だけする☆
これで平和だぜ☆」

「　それだと　標準出力にエラーが出てこない☆」

「　リダイレクト先を２つに増やすことはできないんじゃないか☆？
とりあえず　ログを取るときは　しばらくこれで☆」

「　コマンドの打鍵がめんどくさくない？」

/* # - Log level. #$env:RUST_LOG = "trace" #$env:RUST_LOG = "debug" $env:RUST_LOG = "info" #$env:RUST_LOG = "warn" #$env:RUST_LOG = "error" # - Log redirect. cargo run 2>> ./kifuwarabe-air2019.log */

「　main.rs の冒頭にコメントを書いておいて　これを貼り付ければいいだろ……☆」

TCP/IP 通信

「　次は通信書くか……☆」

Rust のお試しコードを実行する: cargo run --example

「　↑rust にはサンプル・プログラムの書き方がある☆」

「　examples ディレクトリの下にあるファイルは cargo run --example を使って実行できる☆」

Rust で TCP/IP ソケット通信をする際のモデル
 Rustにっき/8日目・TCPサーバ

「　接続に失敗するな……、ポート番号調べてみるか☆」

### Linux lsof -i:3000 ### Windows netstat -aon | findstr 3000

「　何も出てこないな☆　3000番ポートは空いてるはず☆」

「　接続される側で　待ち受けているサーバーが無いのだから、接続できるわけないんじゃないの？」

「　だったら　そういうサンプルだと説明が欲しいぜ☆
サーバー書くか……☆」

クライアントとサーバー

「　接続するだけなら　次のように書けばいい☆」

examples/server.rs

/* # Current directory # cd ./kifuwarabe-air2019 cd C:\Users\むずでょ\source\repos\kifuwarabe-air2019\kifuwarabe-air2019 cargo run --example server */ use std::net::{TcpListener, TcpStream, ToSocketAddrs}; use std::io::{BufRead, BufReader, BufWriter, Error, Read, Write}; use std::thread; /** * See: [Rustにっき/8日目・TCPサーバ](https://cha-shu00.hatenablog.com/entry/2019/03/02/174532) */ fn main(){ let host = "localhost"; let port = 9696; let url = format!("{}:{}", host, port); let mut addrs = url.to_socket_addrs().unwrap(); // Change to ip v4. if let Some(addr) = addrs.find(|x| (*x).is_ipv4()) { // Success addr:127.0.0.1:9696 println!("Success sever-addr:{}", addr); // Wait for connection. let listener = TcpListener::bind(addr).expect("Error. failed to bind."); for streams in listener.incoming() { match streams { Err(e) => { eprintln!("error: {}", e)}, Ok(stream) => { println!("Create the thread.") /* // TODO: Create the thread. thread::spawn(move || { handler(stream).unwrap_or_else(|error| eprintln!("{:?}", error)); }); */ } } } } else { eprintln!("Invalid Host:Port Number"); } }

examples/client.rs

/* # Current directory # cd ./kifuwarabe-air2019 cd C:\Users\むずでょ\source\repos\kifuwarabe-air2019\kifuwarabe-air2019 cargo run --example client */ use std::net::{TcpStream, ToSocketAddrs}; use std::io::{BufRead, BufReader, BufWriter, Write}; /** * See: [Rust で TCP/IP ソケット通信をする際のモデル](https://qiita.com/7ma7X/items/479ad9025a3368c2348f) */ fn main(){ let host = "localhost"; let port = 9696; let url = format!("{}:{}", host, port); let mut addrs = url.to_socket_addrs().unwrap(); // Change to ip v4. if let Some(addr) = addrs.find(|x| (*x).is_ipv4()) { // Success addr:127.0.0.1:3000 println!("Success client-addr:{}", addr); match TcpStream::connect(addr) { Err(_) => { println!("Connection NG."); } Ok(stream) => { println!("Connection Ok."); // Buffering. let mut reader = BufReader::new(&stream); let mut writer = BufWriter::new(&stream); read_something(&mut reader); write_something(&mut writer, "hoge"); } } } else { eprintln!("Invalid Host:Port Number"); } } fn read_something (reader: &mut BufReader<&TcpStream>) { let mut msg = String::new(); reader.read_line(&mut msg).expect("RECEIVE FAILURE!!!"); // read_line は改行文字まで読む。 // 他のread系のメソッドもある（https://doc.rust-lang.org/std/io/trait.BufRead.html） println!("{}", msg); } fn write_something (writer: &mut BufWriter<&TcpStream>, comment: &str) { let msg = format!("MESSAGE: {}\n", comment); // 送る側もたぶん改行文字を付けたほうがよいでしょう。 writer.write(msg.as_bytes()).expect("SEND FAILURE!!!"); writer.flush().unwrap(); }

「　で、使うには server.rs を実行して待機させておいてから、 client.rs で接続する☆
Visual studio code は Terminal ビューを１つしか出せないかもしれないので、
Visual studio code の２つ目を起動して Terminal ビューを使う☆」

「　そんな使い方で　何かが　混線しないか　知らんけどな☆」

「　コンピューター囲碁の通信プログラムって　どんなもんだぜ☆？」

GTPではなく、nngs通信プロトコル

通信対局規約
 19. The Go Text Protocol
GTP - Go Text Protocol
Go Text Protocol

「　Go text protocol だろう☆　大会で使うコマンドは６つしかない☆」

CgfGoBan and Nngs_try
ASCIIコード表

「　↑例えば Cgf Go Ban の cgf_pipe.cpp というファイルに実装が書いてあるぜ☆
ASCIIコード表は助けになるだろう☆」

コマンドは Ascii文字。

コマンドは 2048文字未満。これを超えたらエラー。

コマンドは \n （Asciiコード 10）で終了。

\n を除く 32未満のAsciiコードはすべて無視。例えば \r (Asciiコード 13) などを無視。

\t (水平タブ; Asciiコード 9) を半角スペース (Asciiコード 32) に置換しているコードがあるが、これは働いてないと思う。

コマンド先頭が # ならコメント行だから無視。まだコマンドは送られてくる。

空行（\n だけの行）は無視。まだコマンドは送られてくる。

「　あと、プロトコルの通信ログを見ないと分からないところだが☆、」

19. The Go Text Protocol

virihaure 462% ./gnugo --mode gtp 1 boardsize 7 =1 2 clear_board =2 3 play black D5 =3 4 genmove white =4 C3 5 play black C3 ?5 illegal move 6 play black E3 =6 7 showboard =7 A B C D E F G 7 . . . . . . . 7 6 . . . . . . . 6 5 . . + X + . . 5 4 . . . + . . . 4 3 . . O . X . . 3 2 . . . . . . . 2 WHITE (O) has captured 0 stones 1 . . . . . . . 1 BLACK (X) has captured 0 stones A B C D E F G 8 quit =8

「　サーバーは　イコールを付けて　ひと桁の数を返してくる☆
イコールと数の２文字だけが飛んで来たら無視しろだぜ☆　３文字以上なら何か命令かもしれない☆」

4文字目以降を move とする。例えば =4 C3 なら C3 が move。

パスは move が pass。 GnuGoは"PASS"と送ってくるから大文字・小文字を区別しないようにする。

投了は move が resign。 SGMPは非対応。nngsは相手が落ちるかも？

move の1文字目はアルファベット。筋（列）に対応。I は無いから詰めること。

move の2文字目以降は段（行）数。

「　Go text protocol はいろいろコマンドがあるんだが　大会では　５つのコマンドしか送んな、ということだし
それだけ　実装すればいいんだが、一応　Cgp Go Ban にあるコマンドを見ておこう☆」

boardsize %d\n - ban_size 何路盤。

clear_board\n - 盤面を初期化

komi %.1f\n - komi, - コミを設定

name\n - 名前を要求。

version\n - バージョンを要求。

genmove black\n - GnuGo に黒番打たせる。

genmove white\n - GnuGo に白番打たせる。

play black %s\n - GnuGo の盤面に黒石を置く。符号は Q4 みたいなやつ。

play white %s\n - GnuGo の盤面に白石を置く。

final_status %s\n - GnuGo に死活判定を聞く。符号は Q4 みたいなやつ。結果は次の６つ。

alive

dead

seki

white_territory

black_territory

dame

「　どれも大会で使わなさそう☆」

「　こっちから　通信で送るのは cgf_win.cpp の SendUpdateSetKifu 関数から辿っていけば　見つかるだろう……☆」

「　cgf_term.cpp にいろいろ書いてあるが、 SGMP 使ってそう☆」

「　大会は NNGS 1.1.22 を拡張したプロトコル だから、 NNGS 1.1.22 が何を使ってるか調べるか……☆」

通信対戦について

「　GTP とは　また違うのか☆　うーむ☆」

「　cgf_wsk.cpp に、nngs への接続プログラムが書かれているぜ☆」

playera側の記録

「　通信ログが上記のようなものだとして……☆」

Send:

telnet nngs.computer-go.jp 9696

「　テルネットで接続すればいいらしい☆」

Send:

playera

「　そのあと有無を言わさず　自分の名前を送るらしい☆」

Receive:

No Name Go Server (NNGS) version 1.1.14

「　次はこんな行が送られてくるから、
No Name Go Server (NNGS) version という文字列を当てに行く☆　当たれば☆、」

Send:

set client TRUE\n

「　こんな文字列を　有無を言わさず送る☆
大会では "set client FALSE" と書いてあって　どうすればいいのか☆」

Receive:

Set client to be True

「　よく分からんが client モードが True になった、と受信すれば……☆」

match %s B %d %d 0\n",nngs_player_name[1-fTurn],ban_size,nngs_minutes

「　matchコマンドで黒番に対局を申し込むのか☆　わたしは白番か☆」

「　対局を申し込まれた playerb の方は☆、」

Match [19x19] in 40 minutes requested with playera as Black.

「　↑みたいな文字列を受け取る☆
"Match [%dx%d]",ban_size,ban_size みたいな感じで当てに行く☆」

match playerb B 19 40 0

「　そして
"match %s W %d %d 0\n",nngs_player_name[1-fTurn],ban_size,nngs_minutes
みたいな感じの文字列を　有無を言わさず送る☆
わたしのプレイヤー名は playerb、黒番で 19路、持ち時間は 40分とか　そんな感じだろうか☆」

Received:

accepted.

「　黒番のときは accepted. を受信するとのことだぜ☆　この直後から初手を送れるとのことだぜ☆」

Illegal

「　エラーがあった場合、 illegal という文字が含まれているらしいぜ☆　こうなりゃ終了☆」

sprintf(tmp,"(%s): ",stone_str[1-fTurn]);

「　これはただの表示かだぜ☆」

Pass

「　これを受け取ったら、相手はパス☆
送るのは pass なのに、受け取るのは Pass なのか☆」

T10

「　よく分からんが　指し手　は　そのまんま飛んでくるのか？　よく分からん☆」

14 |. # # O O # # . # O # # O O O # O O #| 14 13 |# # O # # # . # O O O # # # O O O . O| 13 Last Move: J1 12 |# O O # O . . # # O . O O O O . O O .| 12 #216 O (White)

「　盤の右横に指し手が書いてるんじゃないか☆？」

「　なんで　そんなところに……☆　よく誤検知しないものだぜ☆ A1 とか B10 とか☆」

Received:

You can check your score

「　自分が pass したあとに相手が pass すると、 Pass は受信せず上のメッセージを受信するみたいだぜ☆」

「　これはプロトコルなのかだぜ☆？！」

Send:

done

「　地を計算するんだがめんどくさいんで done\n を送る☆　すると☆、」

Received:

resigns.

「　というメッセージを受信して　通信完了だぜ☆　棋譜はサーバーに保存されているはずだぜ☆」

Received:

9 {Game 1: test2 vs test1 : Black resigns. W 10.5 B 6.0}

「　対局が終わると上記のようなメッセージを受信するので……☆」

strstr(str,"9 {Game") && strstr(str,"resigns.")

「　9 {Game と resigns. を含む行を当てに行き……☆」

sprintf(tmp,"%s vs %s",nngs_player_name[1],nngs_player_name[0]);

「　playera vs playerb みたいな文字列を作って　また当てに行き、当たったら　対局終了だぜ☆」

「　JSONでプロトコルを書き直しましょうよ！」

「　大会のサーバーと通信することが優先だぜ☆」

Received:

{%s has disconnected}

「　対戦相手が接続を切ったときは　上のメッセージが飛んでくる☆ %s は相手プレイヤー名だぜ☆」

Received:

forfeits on time

「　どちらかの持ち時間が切れた場合は、上のメッセージと同じ行に　両プレイヤー名が載っているはずだぜ☆」

「　こんなけ分かれば　疑似サーバー　を作れるだろ☆」

「　要点を　まとめないとな☆」

「　ユーザー名と　パスワードの送信って　どうやんの？」

WINGの歩き方　Ver 1.10

「　もっと古い時代に NNGS を使っていた Wing のサイトも見てみるかだぜ☆」

「　パスワードを変える方法はあっても、パスワードを入力する説明は見当たらないな☆」

「　CgfGoBan でパスワードを入れたことは無いだろ☆　パスワード無しでやろうぜ☆」

Send: telnet nngs.computer-go.jp 9696

Send: playera

Received: No Name Go Server (NNGS) version

Send: set client TRUE

Received: Set client to be True

Send: match %s B %d %d 0\n",nngs_player_name[1-fTurn],ban_size,nngs_minutes

Received: Match [19x19]

Send: match %s W %d %d 0\n",nngs_player_name[1-fTurn],ban_size,nngs_minutes

Received: accepted.

Received: Illegal

Received: Pass

Send: T10

Send: pass

Received: You can check your score

Send: done

Received: 9 {Game 1: test2 vs test1 : Black resigns. W 10.5 B 6.0}

Received: {%s has disconnected}

Received: forfeits on time

「　まだ　マッチングのところが　よく分からんな……☆」

マッチング

通信対戦について

「　↑説明を１つ１つ読んでいくかだぜ☆」

プレイヤがサーバにログイン

Send:

telnet nngs.computer-go.jp 9696

「　ログインは通信プロトコルと関係ないよな☆　接続を確立するまでは TCP/IP だぜ☆」

「　ここから先は　とにかく２人以上が　サーバーにぶら下がっているという前提みたいだぜ☆」

一方(例えばplayeraという名前でログインしている)が相手に「match」コマンドで対局を申し込む。playerbという名前のプレイヤに、19路盤、自分が黒番、持ち時間は40分、秒読みなしという条件で申し込む場合には、「match playerb B 19 40 0」というコマンドをサーバに送信する。

Send:

match playerb B 19 40 0

「　相手のプレイヤー名も知っているという前提だな☆　大会でなら知ってるしな☆」

「　少しずつ　分かってきた感じがするな☆」

相手が同じく「match」コマンドで対局を受けたら対局開始(match playera W 19 40 0)

Send (Opponent):

match playera W 19 40 0

「　サーバー側でシェイクハンドを監視しないといけないな☆」

対局開始

「　具体的なことが分からん☆」

互いに自分の手を送信していく(「d3」というような座標を送信する)

Send:

d3

「　どっちの手番か分かるのかだぜ☆？」

一方のプレイヤが「pass」を送信

もう一方のプレイヤが「pass」を送信

Send (Self/Opponent):

pass

Send (Opponent/Self):

pass

「　これは棋譜の上で２者が続けて pass を送信するということだな☆」

双方が「done」コマンドを送信(死に石の情報を送信する必要はありません。また、サーバからのメッセージは無視してください)

Send (Self/Opponent):

done

Send (Opponent/Self):

done

「　これは本当は　郵便囲碁でお互いが　地計算して　どれが生き石、どれが死に石　と言い合うところなんだが、
大会では　めんどくさいんで　スキップしようぜ、という意味合いだぜ☆」

それぞれのプログラムはそのコンピュータのモニタ上に、盤面情報、死に石の情報、地の計算結果を表示します

プログラムの操作者がお互いに双方のプログラムの表示している結果を比較してください(これまでのRS232C接続の際の終局時と同様です)

双方のプログラムの結果が一致しない時には、審判が不一致部分の判定を行ない、結果を確定します

「　これだけ実装すれば　疑似サーバーは作れそうだな☆」

「　しかし、白番が先にログインして　黒番は後から入れ、とか　何か　しきたり　がなかったかだぜ☆？」

「　Cgf Go Ban のしきたりなんじゃないか☆？」

「　２人しか接続してこないという前提で　プログラム書けば　早くできるんじゃないの？」

「　そのあたりの仕様を　もう少し詰めようぜ☆」

TCP/IP通信その２

// Create the thread. thread::spawn(move || { handler(stream).unwrap_or_else(|error| eprintln!("{:?}", error)); });

「　スポーンしたあとは　どうすんだぜ☆？」

「　Rust でどう書けばいいのか分からん☆　とりあえず quit を送ったらループから抜けるようにするかだぜ☆」

Struct std::io::BufStream
bufstream 0.1.4

「　↑Read も Write もしたいバッファー・ストリームは　どう書けばいいんだぜ☆？」

bufstream = "0.1.4"

「　↑これを Cargo.toml に書いて☆、」

extern crate bufstream;

「　↑これを main.rs の冒頭に書いておくかだぜ☆」

// Buffering. let mut reader = BufReader::new(&stream); let mut writer = BufWriter::new(&stream);

「　↑いや、そんなことをしなくても　これでいけたのか……☆？」

「　↑ \n を末尾に付けておかないと read_line が　いつまで経っても終わらないぜ☆」

ソケット間で共有するスコープとかない

「　そうか、クライアントのスレッド　と　サーバーのスレッド　との間は　グローバル変数でやりとりするのではなく、
通信して　やりとりするのかだぜ☆」

「　Rust で Postgresql データベースを使えたりしないの？」

＜書きかけ＞

T: Fromのときimpl From> for Wrapperができない

2019-03-28T16:09:17+09:00

T: Fromのときimpl From> for Wrapperができない

これができない。

struct Wrapper(T); impl From> for Wrapper where T: From, { fn from(p: Wrapper) -> Wrapper { Wrapper(p.0.into()) } } fn main() { let a = Wrapper::(42); let _: Wrapper = a.into(); }

エラー内容

Compiling playground v0.0.1 (/playground) error[E0119]: conflicting implementations of trait `std::convert::From>` for type `Wrapper<_>`: --> src/main.rs:3:1 | 3 | / impl From> for Wrapper 4 | | where 5 | | T: From, 6 | | { ... | 9 | | } 10 | | } | |_^ | = note: conflicting implementation in crate `core`: - impl std::convert::From for T; error: aborting due to previous error For more information about this error, try `rustc --explain E0119`. error: Could not compile `playground`. To learn more, run the command again with --verbose.

実行できるコード

おそらく同じ型同士のFrom(impl From for T)と衝突している。

ユーザー定義型 * Tは実装できるがT * ユーザー定義型は実装できない

2018-12-27T18:27:22+09:00

ユーザー定義型 * Tは実装できるがT * ユーザー定義型は実装できない

例

任意の型の要素を持つVector1を定義してT * Tが可能であればVector1 * TとT * Vector1ができるようにしたいとします。

struct Vector1 { x: T } // T * Tが可能であれば // Vector1 * Tと // T * Vector1を可能にしたい

しかしVector1 * Tは実装できるのですがT * Vector1は実装できません。

とりあえず実装してみる

use std::ops; struct Vector1 { x: T, } impl ops::Mul for Vector1 where T: ops::Mul, { type Output = Vector1; fn mul(self, rhs: T) -> Vector1 { Vector1 { x: self.x * rhs } } } impl ops::Mul> for T where T: ops::Mul, { type Output = Vector1; fn mul(self, rhs: Vector1) -> Vector1 { Vector1 { x: self * rhs.x } } } fn main() {}

エラーが出ました。

| 18 | / impl ops::Mul> for T 19 | | where 20 | | T: ops::Mul, 21 | | { ... | 26 | | } 27 | | } | |_^ type parameter `T` must be used as the type parameter for some local type | = note: only traits defined in the current crate can be implemented for a type parameter

Rust Playgroundでエラーを確認できます。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7d83e5369d7c227e28e27f408d7d45b7

機能	NPM	Cargo	備考
パッケージ管理	⭕️	⭕️	パッケージのインスタール・公開などができる
依存性管理	⭕️	⭕️	lockファイルがある点など共通点が多い
タスク・ランナー	⭕️	❌	Cargoではカスタム・コマンドが開発できる(はず)
ビルド	❌	⭕️	NPMでは代わりにタスク・ランナーを使う
コマンド拡張	❌	⭕️	タスク・ランナーから呼び出せば良い

セクション	意味
description	このタスクの内容
workspace	workspaceでタスクを実行するかどうか
command	実行するメイン・コマンド
args	引数の指定