
## 概要

高階関数を作るときに、functionの型をどう定義するべきか。Rustだと色々なやり方がありそうなので試してみる。

## 結論

- ただ単に function の型が欲しい時は type と fn で定義する
- このfunctionを持った struct を引数に取りたい場合は trait を使って trait 境界を設定した方がいい
	-  self を引数に取らないメソッドは trait 境界を用いて利用することはできないので注意

## type で  function の型定義をする

```rust
type AddNumber = fn(usize, usize) -> usize;
type Square = fn(usize) -> usize;

pub fn add_then_square(add: AddNumber, square: Square, left: usize, right: usize) -> usize {
    square(add(left, right))
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() {
        let add: AddNumber = |x, y| x + y;
        let square: Square = |x| x * x;
        let result = add_then_square(add, square, 2, 2);
        assert_eq!(result, 16);
    }
}
```


## trait を使う

```rust
pub trait Adder {
    fn add(&self, left: usize, right: usize) -> usize;
}

pub trait Squarer {
    fn square(&self, x: usize) -> usize;
}

struct Math {}

impl Adder for Math {
    fn add(&self, left: usize, right: usize) -> usize {
        left + right
    }
}

impl Squarer for Math {
    fn square(&self, x: usize) -> usize {
        x * x
    }
}

pub fn add_then_square(
    adder: &impl Adder,
    squarer: &impl Squarer,
    left: usize,
    right: usize,
) -> usize {
    squarer.square(adder.add(left, right))
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() {
        let math = Math {};
        let result = add_then_square(&math, &math, 2, 2);
        assert_eq!(result, 16);
    }
}
```


注意しないといけないことが一つあって、trait に self を引数に取らないメソッドを定義する場合、そのメソッドを struct に実装することはできるが trait境界 を定義して受け取った側のメソッドではそのメソッドを利用できない。

以下はエラーになるパターン

```rust
pub trait Adder {
    fn add(left: usize, right: usize) -> usize;
}

pub trait Squarer {
    fn square(x: usize) -> usize;
}

struct Math {}

impl Adder for Math {
    fn add(left: usize, right: usize) -> usize {
        left + right
    }
}

impl Squarer for Math {
    fn square(x: usize) -> usize {
        x * x
    }
}

pub fn add_then_square(
    adder: &impl Adder,
    squarer: &impl Squarer,
    left: usize,
    right: usize,
) -> usize {
	// square と add が method name not found になる
    squarer.square(adder.add(left, right))
}
```

[Rust] 高階関数用のfunctionの型定義を試す


## 動機

```rust
use chrono::{DateTime, Local};  
  
fn get_unix_time_in_local() -> i64 {  
    let local_datetime: DateTime<Local> = Local::now();  
    local_datetime.timestamp()  
}  
  
#[cfg(test)]  
mod tests {  
    use super::*;  
  
    #[test]  
    fn can_get_unix_time() {  
        let actual = get_unix_time_in_local();  
        assert_eq!(actual, 0); // エラーになる。現在時刻に依存するからどうやってテストする????  
    }  
}
```

雑だがこんなふうに、別のメソッドに依存したロジックをrustでどうテストするのか。TypeScriptとかNode.jsに飼い慣らされた私の脳だとmockしてしまえばいいじゃんと思うが、rust だと overload / override どちらもできないので単純に mock するのは難しい

## 解決策

```rust
use chrono::{DateTime, Local};  
  
fn get_unix_time(get_now: impl Fn() -> DateTime<Local>) -> i64 {  
    let local_datetime: DateTime<Local> = get_now();  
    local_datetime.timestamp()  
}  
  
fn get_unix_time_in_local() -> i64 {  
    let get_now = || Local::now();  
    get_unix_time(get_now)  
}  
  
#[cfg(test)]  
mod tests {  
    use super::*;  
    use chrono::{FixedOffset, NaiveDate, NaiveDateTime, NaiveTime};  
  
    #[test]  
    fn can_get_unix_time() {  
        let dummy_date: DateTime<Local> = DateTime::from_utc(  
            NaiveDateTime::new(  
                NaiveDate::from_ymd(2023, 4, 1),  
                NaiveTime::from_hms(12, 59, 0),  
            ),  
            FixedOffset::east(9 * 3600),  
        );  
  
        let mock_fn = || dummy_date;  
        let actual = get_unix_time(mock_fn); // I/F を変更して現在時刻を取得する関数を渡せるようにする  
        assert_eq!(actual, dummy_date.timestamp());   
}  
}
```

関数型的な考え方だと元の実装だと現在時刻を取得する処理に依存しているという部分が、表現できてないからテストが難しいのだと思う。そのため、現在時刻を取得する処理を外から注入できるようにする。
testではそのメソッドにダミーで作ったメソッドを注入することでテストできるようにする

多分だが課題としては、mockすることに固執しすぎてなぜテストしづらいのかを考えなかったことだと思う。mockしづらいのではなくて、依存関係を適切なI/Fとして表現できていないことがテストのしづらさにつながっているのではないかと思う。

[Rust] test時に依存するメソッドをmockする方法を考える


## 概要

Property-based testing という概念を最近やっと知ったので、Rustで試してみる

Property-based testing に関してはこの辺りを読むと良さげ
[Property Based Testing で ドメインロジックをテストする](https://gakuzzzz.github.io/slides/property_based_testing_for_domain/)

rust には [proptest](https://crates.io/crates/proptest) いうcrateがあるようなのでこれを導入して試してみる

## 導入方法

Cargo.toml に以下を書く
```toml
[dev-dependencies]  
proptest = "1.1.0"
```

## テスト書いてみる

`&[String] -> HashMap<String, String>` に変換するコードのテストをproptest

```rust
use std::collections::HashMap;  
  
pub fn from(attr: &[String]) -> HashMap<String, String> {  
    attr.chunks(2)  
        .filter_map(|chunk| {  
            let key = chunk.get(0)?;  
            let val = chunk.get(1)?;  
            Some((key.to_string(), val.to_string()))  
        })  
        .collect::<HashMap<String, String>>()  
}  
  
#[cfg(test)]  
mod tests {  
    use super::*;  
    use proptest::prelude::*;  
  
    proptest! {  
        #[test]  
        fn doesnt_crash(attr: Vec<String>) {  
            from(&attr);  
        }  
    }  
}
```

ざっくり清浄系とおすテストはこれで良さそう。
このコードだと失敗するパターンはほぼないが、特定のパターンのときにErrorを返すようなfunctionだとテストしやすそう。

どちらにせよ宣言的に書いておけば書いておくほど、proptestで吸収しやすくなるので本当に必要なところだけテスト書けばよくなるので良い。

[Rust] Property-based testing やってみる


## 概要

Rust で test coverage ってどうするんだっけを毎回調べるので備忘録

## 手順

cargo-llvm-cov の install

```console
$ cargo install cargo-llvm-cov
```

以下のコマンドで coverage をブラウザで閲覧できる
```console
cargo llvm-cov --open
```

cargo make 使っている場合は以下を Makefile.toml に書いておくと ` makers test_cov` で起動できるので便利

```toml
[tasks.test_cov]  
description = "make test coverage report"  
workspace = false  
command = "cargo"  
args = ["llvm-cov", "--open"]
```

## 参考

[https://gist.github.com/buzztaiki/6579a14cbf18dcfebec550ebe531c5cf](https://gist.github.com/buzztaiki/6579a14cbf18dcfebec550ebe531c5cf)

[https://github.com/taiki-e/cargo-llvm-cov](https://github.com/taiki-e/cargo-llvm-cov)

[https://github.com/sagiegurari/cargo-make](https://github.com/sagiegurari/cargo-make)

[Rust] test coverage を測る

読書メモ：Domain Modeling Made Functional (Part 2, Chapter 4~7)


## 概要

[https://www.amazon.co.jp/dp/B07B44BPFB](https://www.amazon.co.jp/dp/B07B44BPFB)

↑を読んだメモ

サンプルコードをRustに置き換えて遊んでたリポジトリは以下
[https://github.com/homura10059/DomainModelingMadeFunctional_in_Rust](https://github.com/homura10059/DomainModelingMadeFunctional_in_Rust)

Domain Modeling Made Functional の読書メモシリーズ は [こちら](../series/bd9f5f797461f1f04bd00051b6f878d6)

## Part 1 Understanding the Domain

### Chapter 1 Introducing Domain-Driven Design

- shared mental model を作ることが DDD の中心 
- Domain を見つけるためには Event Storming をやってみるといい
	- 関係者と Event Storming をやってみると "私たち" vs "彼ら" という対立思考を避けられる
- Scenario
	- ユーザーが目的を達成するために求めているもの
	- アジャイルでいうstoryに近い
	- usecase はそれを詳細にしたもの（インタラクションの一つとか）
- Business Process
	- ビジネス(1ユーザーではなく大きい単位)が目的を達成するために求めているもの
	- ユーザー目線ではなくビジネス目線のSenario
- Workflow
	- Business Processの一部
	- 従業員やシステムが実行するstepをリストにしたもの
	- Business Process は Workflow のリストに分けられる
* *command* (DDD用語)
	* OOPのCommandパターンとは関係ない
	* domain event を発生させるもととなるリクエスト
	* Workflowを開始する
		* Woekflowが実行された結果としてEventが生まれることも多い
* `問題あるDomainは小さいsubdomainsに分割する`
	* 困難は分割せよ
* bounded contexts
	* 現実世界のドメインをドメインモデルに落とし込むときに作られたもの
	* 実装の中でいうサブシステム
	* 現実世界のドメインと bounded contexts が一対一対応する場合ばかりではない
		* 複数に分かれることもあるし、複数のドメインをまとめて一つになることもある
* 最も重要な Counded Contextsを見つける
	* core domain はビジネス的に重要なもの(金を稼げるもの)
	* それ以外は supportive domain や generic domain
* ユビキタス言語を作る
	* ドメインエキスパートと同じ言葉でmodelを表す

### Chapter 2 Understanding the Domain

- 具体をどう設計していくかという例が主
- database-driven や class-driven と比較しながらDDDの利点を説明
- class-driven の説明で FooBase みたいな基底作るけどこれは何も現実を表せてないだろみたいなこと言われててちょっと笑った
	- ネイティブでもFooBaseみたいな命名するんだ
	- なんの現実も表せてなくて抽象化できてない共通化はあるある


### Chapter3 A Functional Architecture

"C4" approach
- "system context"
	- システム全体のトップレベルを表す表現
- "containers"
	- "system context"はこれを複数含む
	- deployableな単位(web siteだったりweb serviceだったり)
- "components"
	- "container" は複数のこれで構成される
	- コードの中の主な構造物
- "classes"
	- "component" は複数のこれで構成される
	- 関数型アーキテクチャだと"modules"とも呼ばれる
	- 低レベルのメソッドや関数

変更コストを最小にするを目指す

"bounede context"をコード上でどう扱うか
- モノリスなら "component" として分ける
- マイクロサービスなら "container" として分けるとか

最初はモノリスにしておいて必要が出てきたら分けるのをお勧めする

"bounede context" 間でのデータ転送
* 境界ではDTOに詰め替える
* input gate
	* 信頼のおける "bounede context" の中では validation 必要ない
	* しかし外からやってくるデータには必要
* output gate
	* 外に出すデータには必要のないデータがleakしないようにする

"bounede context" 間の契約
- Shared Kernel
	- 複数の "bounede context" に共通した部分を、共通モジュールにするパターン
- Customer/Supplier or Consumer Driven Contract
	- downstream側の Consumer が必要な情報を定義する(契約として)
	- upstream側はその形式を提供する
- Conformist
	- upstream側が力を持っているなどの場合で、契約を定義せずそのまま使うパターン

Anti-Corruption Layers
- 外部システムがドメインモデルと合わない場合などに設ける

読書メモ：Domain Modeling Made Functional (Part 1, Chapter 1~3)

  
## 概要

最近clippy(rustのいわゆる静的解析ツール)から教えられたことまとめ

参考:  [付録D - 便利な開発ツール](https://doc.rust-jp.rs/book-ja/appendix-04-useful-development-tools.html#%E4%BB%98%E9%8C%B2d---%E4%BE%BF%E5%88%A9%E3%81%AA%E9%96%8B%E7%99%BA%E3%83%84%E3%83%BC%E3%83%AB)

## flat-map

```rust
.map(|some|some.parse::<f64>().ok())
.flatten();
```

みたいなやつは

```rust
.and_then(|some|some.parse::<f64>().ok());
```

で置き換えられる。flat_map が rust では and_then らしい

## Optional に対する clone 


```rust
.map(|x| x.clone())
```

は
```rust
.cloned()
```

で置き換えられる




[Rust] clippyに指摘されたことmemo

  
## 概要

Rustでカリー化(currying)と部分適用(partial application)ができるのか試してみた。結論としては可能。

## ところでカリー化(currying)/部分適用(partial application)って何？

[カリー化(Wikipedia)](https://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96)では以下のように説明されています

>カリー化 (currying, カリー化された=curried) とは、複数の引数をとる関数を、引数が「もとの関数の最初の引数」で戻り値が「もとの関数の残りの引数を取り結果を返す関数」であるような関数にすること（あるいはその関数のこと）である。

>部分適用とは、複数の引数をとる関数の一部の引数に実引数を適用する操作のこと

詳しくは関数型プログラミングの基礎的なところを勉強すると出てくると思います。自分は以下の本で学びましたがすごく良い本でした。(絶版になったのかkindle版がなくなったっぽいです...)

[https://www.amazon.co.jp/dp/4295001139](https://www.amazon.co.jp/dp/4295001139)

## Rust で試す

### 元になる実装

以後の例で使うコード例を示す。
ただ足し算するだけの関数addを対象にします。

```rust
fn main() {
    let r = add(1, 2);
    println!("{}", r); // 3
}

fn add(x: i32, y: i32) -> i32 {
  x + y
}
```

### カリー化(currying)

```rust
fn main() {
    let c_add = curry_add(1);
    let r1 = c_add(4); 
    let r2 = c_add(5);
    println!("{}", r1); // 5
    println!("{}", r2); // 6
}

fn curry_add(n: i32) -> impl Fn(i32) -> i32 {
  move |x| x + n
}
```

closure に引数を move することで新たな関数を生成することで、カリー化(currying) できる

### 部分適用(partial application)

```rust
fn main() {
    let c_add = move |x| add(1, x);
    let r1 = c_add(4); 
    let r2 = c_add(5);
    println!("{}", r1); // 5
    println!("{}", r2); // 6
}

fn add(x: i32, y: i32) -> i32 {
  x + y
}
```

こっちも closure に引数を move することで部分適用できる。個人的にはこっちの方が使い所多そう。

## 参考

- [【TS】今さら聞けない高階関数・カリー化](https://zenn.dev/nekoniki/articles/5b7980fac91048775931)
- [Currying in Rust](https://hashnode.com/post/currying-in-rust-cjpfb0i2z00cm56s2aideuo4z)
- [Idiom #37 Currying](https://programming-idioms.org/idiom/37/currying/2218/rust)

[Rust] カリー化(currying)と部分適用(partial application) 

  
## 概要

Rustの?演算子(question mark operator)がとても便利なのでメモしておく

## Option 型に対して使う

例：function `get` は、Option 型を返すfunction  `get_opt` の戻り値がNoneならそのままNoneを返してSomeなら加工して返却する。
```rust
fn get_opt() -> Option<()> {  
    None  
}  
  
fn get() -> Option<()> {  
    let val = get_opt();  
    if val.is_none() {  
        return None;  
    }  
    let unwrapped = val.unwrap();  
    // 何かしらの加工処理  
    Some(unwrapped)  
}
```

上記のよくある処理を?演算子(question mark operator)を使うとこう書ける

```rust
fn get_opt() -> Option<()> {  
    None  
}  
  
fn get() -> Option<()> {  
    let val = get_opt()?;  
    // 何かしらの加工処理  
    Some(val)  
}
```

めっちゃ楽だし意図がわかりやすい。

## Result 型に対して使う

さっきと似たような例。Option部分がResultだったとしても同様な処理になる。
(Error型を定義するのが面倒なのでanyhowを使ってるのは見逃して欲しい)

```rust
use anyhow::{anyhow, Result};

fn get_result() -> Result<()> {  
    Err(anyhow!("missing value"))  
}  
  
fn get() -> Result<()> {  
    let val = get_result();  
    if val.is_err() {  
        return Err(anyhow!("some value"));  
    }  
    let unwrapped = val.unwrap();  
    // 何かしらの加工処理  
    Ok(unwrapped)  
}
```

これも?演算子(question mark operator)を使うことで簡単にできる。

```rust
use anyhow::{anyhow, Result};

fn get_result() -> Result<()> {  
    Err(anyhow!("missing value"))  
}  

fn get() -> Result<()> {  
    let val = get_result()?;  
  
    // 何かしらの加工処理  
    Ok(val)  
}
```


## Option 型 と Result 型 の混合パターン

```rust
use anyhow::{anyhow, Result};

fn get_opt() -> Option<()> {  
    None  
}  
  
fn get() -> Result<()> {  
    let val = get_opt().ok_or(anyhow!("some value"))?;  
    // 何かしらの加工処理  
    Ok(val)  
}
```

`ok_or` と ?演算子(question mark operator)を使うことでかなり簡潔に書ける。
これに気づいてしまって便利すぎると思ってこの記事を書いた。

[Rust] OptionやResultと組み合わせて使える?演算子

  
## 概要

 [prisma-client-rust](https://github.com/Brendonovich/prisma-client-rust) の 0.6.1 を試していたら、`Undefined symbols for architecture arm64` で build が失敗した。解決方法をメモしておく。(こういうやつに限ってまた引っかかるし思い出せなくて詰むのでメモしておく)

## 発生した事象


buildしたら `Undefined symbols for architecture arm64`  とうエラーが出た。
対象はどうやらこれ↓

```
/var/folders/gx/vpnqx7ln6cd0gtd8rt32fdj80000gn/T/rustcTP444Y/symbols.o
```

ただ調べてみたところ、そもそもこんなファイルは存在しなかった

## 解決方法

```bash
$ rustup update
```

で toolchain を update したら解決した。
原因はわからないが、ライブラリが求める version とあってないものがあったとか?

### 解決しなかった方法

- ライブラリのバーションをいじってみる
- コードを変更してみる
- build周りの設定を変えてみる

などなど


[Rust] `Undefined symbols for architecture arm64` で build が失敗したときにやったこと

  
## 概要

Rust で DB 接続を試してみる。DBスキーマの管理とかは prisma 使いたいので、探してみたところ 非公式だが [prisma-client-rust](https://github.com/Brendonovich/prisma-client-rust) を見つけたので試してみる。

余談だが、 2022/08/24 に `0.5.3` が出るまでまともに動かなかった。

これはタイミング悪く 2022/08/22 に  `0.5.2`  を試してしまった時の嘆き
[https://twitter.com/homura10059/status/1561687326564417537](https://twitter.com/homura10059/status/1561687326564417537)

## 検証結果

- 最低限動かすことはできる
- 少し複雑な schemaだとclientの生成に失敗するのでまだ趣味で使うにしても早そう。
- 2022/08 末に `0.6.0` を出すらしいので待つ


## 検証メモ

### 最終的なフォルダ構成

```text
|---- .cargo
|      `---- config.toml
|
|---- prisma
|      `---- schema.prisma
|
|---- prisma-cli  
|     |---- src
|     |     `---- main.rs
|     `---- Cargo.toml
|
|---- repositories
|     |---- src
|     |     `---- lib.rs
|     `---- Cargo.toml
|
|---- .env
`---- Cargo.toml
```

cargo workspaces を使った構成で最終的にはこのような構成を作る。
ここからは [ドキュメント](https://github.com/Brendonovich/prisma-client-rust/tree/main/docs) に沿ってやっていく

### 01-Installation

[https://github.com/Brendonovich/prisma-client-rust/blob/main/docs/01-installation.md](https://github.com/Brendonovich/prisma-client-rust/blob/main/docs/01-installation.md)

まず Rust 用の prisma-cli  を binary-crate としてを作る
```sh
$ cargo new prisma-cli 
```

作成完了したら Cargo.toml に以下のような dependencies を設定する

```toml
############################
# ./prisma-cli/Cargo.toml
############################

[package]  
name = "prisma-cli"  
version = "0.1.0"  
edition = "2021"  
  
  
[dependencies]  
prisma-client-rust = { git = "https://github.com/Brendonovich/prisma-client-rust", tag = "0.5.3" }  
prisma-client-rust-cli = { git = "https://github.com/Brendonovich/prisma-client-rust", tag = "0.5.3" }
```

設定終わったら main.rs を以下のように書き換える

```rust
//
// ./prisma-cli/src/main.rs
//

fn main() {  
    prisma_client_rust_cli::run();  
}
```

これで準備は完了。
作成した crate を root にある Cargo.toml に追加しておく

```toml
############################
# ./Cargo.toml
############################

[workspace]  
  
members = [  
    "prisma-cli",  
]
```

この状態で、一旦作った prisma-cli が動作するか確認してみる
```sh 
$ cargo run --bin prisma-cli -- -h
```
で cli の help が表示されれば問題なし。

このままだと使いづらいので、aliasを設定しておく
```toml
############################
# ./cargo/config.toml
############################

[alias]  
prisma = "run --bin prisma-cli --"
```
設定が終わったら以下を実行してみる。 help が表示されれば問題なし。

```sh
$ cargo prisma -h
```

### 02-Setup

[https://github.com/Brendonovich/prisma-client-rust/blob/main/docs/02-setup.md](https://github.com/Brendonovich/prisma-client-rust/blob/main/docs/02-setup.md)

prisma の schema ファイルを作成しておく
```
//
// ./prisma/schema.prisma
//

generator client {  
  provider = "cargo prisma"  
  output   = "../repositories/src/prisma.rs"  
}  
  
datasource db {  
  provider = "postgresql"  
  url      = env("DATABASE_URL")  
}  
  
model User {  
  id          String   @id @default(cuid())  
  displayName String  
  email       String?  
}
```

generate 先の lib-crate を作っておく
```sh
$ cargo new --lib repositories 
```

prisma-client を generate しておく
```sh
$ cargo prisma generate
```
`./repositories/src/prisma.rs` に client が生成されるので確認しておく。

ついでに接続先の設定を書いておく。[supabase](https://supabase.com/) などで postgresql を作っておいくとよい。
```
############################
# .env
############################
  
DATABASE_URL="TODO:ここにURLを入れる"
```

DB も migrate しておく
```sh
$ cargo prisma migrate dev --name init 
```

### 03-Overview


lib.rs の方に cliet を読み込めるか試してみる。その前に tokio への依存を追加しておく
```toml
############################
# ./repositories/Cargo.toml
############################

[dependencies]  
tokio = { version = "1.20.1", features = ["full"] }
prisma-client-rust = { git = "https://github.com/Brendonovich/prisma-client-rust", tag = "0.5.3" }  
prisma-client-rust-cli = { git = "https://github.com/Brendonovich/prisma-client-rust", tag = "0.5.3" }
```

こんな感じで、client を生成して、クエリが実行できる
```rust
mod prisma;  
  
use prisma::user;  
  
#[tokio::main]  
async fn main() {  
    let client= prisma::new_client().await?;  
    let users = client.user()  
        .find_many(vec![user::display_name::equals("homura".to_string())])  
        .exec().await?;  
}
```

あとは必要に応じて実装していけばいい。
このあと色々試したが、少し複雑な schemaだとclientの生成に失敗するのでまだ趣味で使うにしても早そう。2022/08 末に `0.6.0` を出すらしいのでそれに期待。

prisma-client-rust を試してみる

  
## 概要
Rust で作ったものをAWS Lambda で動かしてみようと思う。aws-lambda-rust-runtime を使えばできそうだったので試してみる。
Rust自体を書けるようになることが先じゃないかという考え方もある気がするが、実際に動く環境を先に作っておくと後々ハマったりしないので先に動く環境を整える

## やったことメモ

[https://github.com/awslabs/aws-lambda-rust-runtime](https://github.com/awslabs/aws-lambda-rust-runtime) のREADMEに沿ってやっていく

### サンプルコードの生成

まずは cargo-lambda を install する
```bash
$ brew tap cargo-lambda/cargo-lambda
$ brew install cargo-lambda
$ cargo install cargo-lambda
```

インストールが終わったらサンプルプロジェクトを作成する

```bash
$ cargo lambda new aws-lambda-sample
? Is this function an HTTP function? No
? AWS Event type that this function receives cloudwatch_events::CloudWatchEvent
```

とりあえず `CloudWatchEvent` で作っておく。作っただけで動くサンプルができているので lambda 用にビルドしてみる

```bash 
$ cargo lambda build --release --arm64 --bins
```

これで lambda にデプロイできる形に build できた

### AWS-lambda へのデプロイ方法の選定

1. cargo-lambda を使ってデプロイ
2. AWS CLI を使ってデプロイ
3. AWS Serverless Application Model (SAM) を使ってデプロイ
4. Serverless Framework を使ってデプロイ
5. Docker を使ってデプロイ

READMEを読む限り、方法としては上記の5種類があるっぽい。
ここで慣れてない方法を選択すると目的外のことでハマって時間を食うので、慣れてるSAMでやることにする。


### local から `sam deploy`

SAM CLI などのセットアップは終わっている前提。
終わってない場合は、[公式のドキュメント](https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html) を参考に導入しておく。

以下のように `template.yaml` を準備しておく

```yaml
# template.yaml
AWSTemplateFormatVersion: '2010-09-09'  
Transform: AWS::Serverless-2016-10-31  
  
Resources:  
  SampleRustFunction:  
    Type: AWS::Serverless::Function  
    Properties:  
      MemorySize: 128  
      Architectures: ["arm64"]  
      Handler: bootstrap  
      Runtime: provided.al2  
      Timeout: 5  
      CodeUri: ./target/lambda/aws-lambda-sample/bootstrap 
  
Outputs:  
  FunctionName:  
    Value: !Ref SampleRustFunction  
    Description: sample
```

SAMでデプロイするための設定ファイルを生成する。最近は `sam deploy --guided` で出来るようになったらしい。

```bash
$ sam deploy --guided

Configuring SAM deploy
======================

        Looking for config file [samconfig.toml] :  Not found

        Setting default arguments for 'sam deploy'
        =========================================
        Stack Name [sam-app]: aws-lambda-sample
        AWS Region [us-east-1]: ap-northeast-1
        #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
        Confirm changes before deploy [y/N]: 
        #SAM needs permission to be able to create roles to connect to the resources in your template
        Allow SAM CLI IAM role creation [Y/n]: y
        #Preserves the state of previously provisioned resources when an operation fails
        Disable rollback [y/N]: 
        Save arguments to configuration file [Y/n]: Y
        SAM configuration file [samconfig.toml]: 
        SAM configuration environment [default]: 

        Looking for resources needed for deployment:
         Managed S3 bucket: aws-sam-cli-managed-default-samclisourcebucket-1943pn3c3rsgk
         A different default S3 bucket can be set in samconfig.toml

        Saved arguments to config file
        Running 'sam deploy' for future deployments will use the parameters saved above.
        The above parameters can be changed by modifying samconfig.toml
        Learn more about samconfig.toml syntax at 
        https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html

Error: Unable to upload artifact ../target/aarch64-unknown-linux-gnu/release/aws-lambda-sample referenced by CodeUri parameter of SampleRustFunction resource.

S3 Bucket does not exist.
```

このままではS3バケットがなくてデプロイできないので `samconfig.toml` を書き換える。
S3バケットは事前に作っておく。

```yaml
# samconfig.toml 
version = 0.1  
[default]  
[default.deploy]  
[default.deploy.parameters]  
stack_name = "aws-lambda-sample"  
s3_bucket = "TODO:ここを準備したバケットに書き換える"  
s3_prefix = "aws-lambda-sample"  
region = "ap-northeast-1"  
capabilities = "CAPABILITY_IAM"  
image_repositories = []

```

ここまで来ればデプロイできるはずなので、以下のコマンドでデプロイする

```bash
$ sam deploy
```

CloudWatchEvent のテンプレートを使ってテストしてみる。
動いたのでこれで問題なし。

![](https://i.imgur.com/36GwbUc.webp)


[Rust] AWS Lambda へデプロイしてみる

  
## 概要

Rust は簡単に monorepo が試せて良い。
ただ、GitHub Actions で CI 環境を構築する上で Rust かつ monorepo 用のCI環境構築経験がないので素振りしておく。


## ディレクトリ構成

Rustの monorepo に関しては [Cargoのワークスペース](https://doc.rust-jp.rs/book-ja/ch14-03-cargo-workspaces.html) が詳しいので説明を省くとして、sample-a/b 二つの repo がある状態で sample-a に対してCI を設定する

```bash
├── Cargo.lock
├── Cargo.toml
├── ./.github/workflows
├── ./sample-a
└── ./sample-b
```

## やること
以下のように GitHub Actions 用の設定ファイルを用意する

```yaml
# .github/workflows/sample-a.yml
on:  
  push:  
    branches:  
      - main  
    paths:  
      - 'sample-a/**'
      - '.github/workflows/sample-a.yml'  
  
defaults:  
  run:  
    working-directory: './sample-a'  
  
jobs:  
  build-test:  
    runs-on: ubuntu-latest  
    steps:  
      - uses: actions/checkout@v2  
      - uses: actions-rs/toolchain@v1  
        with:  
          profile: minimal  
          toolchain: stable  
          components: rustfmt, clippy  
      - name: build  
        run: 'cargo build'  
      - name: test  
        run: 'cargo test'
```

- `sample-a` ディレクトリの中に変更があるか、この設定ファイル自体に変更があった場合に実行する
- デフォルトで  `sample-a`  ディレクトリ内でactionを実行する
- Rust の CI 環境は [actions-rs/toolchain@v1](https://actions-rs.github.io/#toolchain) を使う
- `cargo build` と `cargo test` を実行する

## 参考
- [Mono Repo のための GitHub Actions の Tips 集](https://gist.github.com/yuya-takeyama/47fb261625e67c8efabadcf8c6f237ef)

[https://www.amazon.co.jp/dp/4297125625](https://www.amazon.co.jp/dp/4297125625)


[Rust] GitHub Actions で monorepo の CI 環境を整える

  
## 概要
Rustの勉強をしているが、npm-scripts 的なタスクランナーが欲しくなったので cargo-xtaskを試してみる。

## 前準備

ワークスペースが使える状態で導入するのが良いらしいので、チュートリアルの [Cargoのワークスペース](https://doc.rust-jp.rs/book-ja/ch14-03-cargo-workspaces.html) を終わらせておく

## cargo-xtask の導入

[https://github.com/matklad/cargo-xtask](https://github.com/matklad/cargo-xtask) 通りにやってみる

### workspace に xtask を追加
```diff
# Cargo.toml

[workspace]  
  
members = [  
    "adder",  
    "add-one",  
+    "xtask",  
]
```
Cargo.tomlに追加した後、`cargo new` する
```shell
$ cargo new --bin xtask
```

### xtask を alias に追加

```toml
# .cargo/config
[alias]
xtask = "run --package xtask --"
```

### xtask 用のコードを作る
[https://github.com/matklad/cargo-xtask/blob/master/examples/hello-world/xtask/src/main.rs](https://github.com/matklad/cargo-xtask/blob/master/examples/hello-world/xtask/src/main.rs)
を参考に、今回は reformatとlintをいっぺんに動かすようなtaskを作る
簡単にいうと以下の3つのコマンドを順に実行していくだけ
```shell
$ cargo fmt
$ cargo fix
$ cargo clippy
```

実際のコードは以下
```rust
# xtask/src/main.rs
use std::{  
    env,  
    path::{Path, PathBuf},  
    process::Command,  
};  
  
type DynError = Box<dyn std::error::Error>;  
  
fn main() {  
    if let Err(e) = try_main() {  
        eprintln!("{}", e);  
        std::process::exit(-1);  
    }  
}  
  
fn try_main() -> Result<(), DynError> {  
    let task = env::args().nth(1);  
    match task.as_ref().map(|it| it.as_str()) {  
        Some("lint") => lint()?,  
        _ => print_help(),  
    }  
    Ok(())  
}  
  
fn print_help() {  
    eprintln!(  
        "Tasks:  
lint            fmt & fix & clippy  
"  
    )  
}  
  
fn format() -> Result<(), DynError> {  
    let cargo = env::var("CARGO").unwrap_or_else(|_| "cargo".to_string());  
    let status = Command::new(cargo)  
        .current_dir(project_root())  
        .arg("fmt")  
        .status()?;  
  
    if !status.success() {  
        Err("cargo fmt failed")?;  
    }  
  
    Ok(())  
}  
  
fn fix() -> Result<(), DynError> {  
    let cargo = env::var("CARGO").unwrap_or_else(|_| "cargo".to_string());  
    let status = Command::new(cargo)  
        .current_dir(project_root())  
        .args(&["fix", "--allow-dirty", "--allow-staged"])  
        .status()?;  
  
    if !status.success() {  
        Err("cargo fix failed")?;  
    }  
  
    Ok(())  
}  
  
fn clippy() -> Result<(), DynError> {  
    let cargo = env::var("CARGO").unwrap_or_else(|_| "cargo".to_string());  
    let status = Command::new(cargo)  
        .current_dir(project_root())  
        .arg("clippy")  
        .status()?;  
  
    if !status.success() {  
        Err("cargo clippy failed")?;  
    }  
  
    Ok(())  
}  
  
fn lint() -> Result<(), DynError> {  
    format()?;  
    fix()?;  
    clippy()?;  
  
    Ok(())  
}  
  
fn project_root() -> PathBuf {  
    Path::new(&env!("CARGO_MANIFEST_DIR"))  
        .ancestors()  
        .nth(1)  
        .unwrap()  
        .to_path_buf()  
}
```

このファイルを追加した後以下のコマンドで実行できる

```shell
$ cargo xtask lint
```

## 参考
- [cargo で npm-scripts 的なことをする](https://ubnt-intrepid.netlify.app/introduce-cargo-xtask/)

[https://www.amazon.co.jp/dp/4297125625](https://www.amazon.co.jp/dp/4297125625)
