Don't Repeat Yourself

Don't Repeat Yourself (DRY) is a principle of software development aimed at reducing repetition of all kinds. -- wikipedia

『詳解Rustプログラミング』(Rust in Action)を読みました

先日発売になった『詳解Rustプログラミング』という本をひとまず一通り軽く読んでみました。実は原著の Rust in Action をすでに読んでしまっていたので、内容の流れは把握していたのですが、私は一応日本語ネイティブなので日本語の書籍は非常に嬉しいですね。

Rust in Action

Rust in Action

Amazon

本書をまず読んで最初に思い出したのは、私も大好きな『低レベルプログラミング』という本でした。この本は C とアセンブラで書かれているのですが、これを Rust でやり直す感覚を覚えました。コンピュータサイエンスやコンピュータアーキテクチャの話題が豊富で、大学のコンピュータサイエンスの講義を受けているような印象を持ちました。

あるいは、『Go ならわかるシステムプログラミング』の Rust 版と言ってもよいかもしれません。

従来はこの分野の入門書は C あるいは C++ で書かれていることが多かったと思いますが、ついに Rust による書籍が出たと、原著を読んだ当初に思いました。最近はこうした CS の基礎の本は Python で出ることも増えたように思いますが、Rust での解説はこれから市民権を得ていくでしょうか。もしそうなるとすると、自分が一番馴染みがある言語で学べることになりとてもワクワクします。

本書が一番特徴的なのはやはり、幅広い分野にまたがる適切な題材が豊富に用意されているという点だと思います。4章ではまずまずの規模の状態の書き換えが発生する人工衛星と地上の通信を模したアプリケーションを作ります。5章では関数呼び出しくらいまでを行える CPU エミュレータを実装しますし、6章ではメモリの動きを見るためのグラフィカルアプリケーションを実装します。7章では実用的なキーバリューストア、8章では OSI 参照モデルを徐々に掘っていくようなアプリケーションを実装します。最後は簡単な OS までを実装します*1。著者の知見と知識の幅広さ、そして実装力がすごいです。

Rust の文法や機能の解説書としての側面からですと、他の言語から Rust に入門するユーザー*2がつまづきやすいポイントを丁寧に押さえています。本書はまず2、3、4章で軽く Rust の基本的な文法について説明したあと、5章以降でさらに Rust の踏み込んだ機能について解説されます。この踏み込んだ機能の解説が白眉でした。Copy トレイトや Clone の説明、スマートポインタの説明やトレイトオブジェクトの説明は、私が以前共著で書いた本では載せなかった記憶がありますが、本書は適切な題材とともにそれらをよく解説しています。

本書で取り扱っていない話題があるとすれば、Rust アプリケーションの本番運用にまつわるものでしょうか。たとえばパフォーマンスチューニングを Rust ではどのように行っていくかという話題や、Rust アプリケーションの CI/CD に関する現場に近い実務的な話題は載っていません。また、マクロやテストに関する細かめの話も載ってはいません。本書の主題はあくまで Rust を使ってシステムプログラミングに入門することだからです。この点をもし学びたいようであれば、別の記事や書籍を参照する必要はありそうでした。

ただそうした「取り扱っていない話題」については重々承知のようです。カバーには次のようなコメントが付されており、本書の性格をよく表しています。

本書は包括的な教科書や参考書ではない。Rust とその標準ライブラリに関して、専門的で特別な扱いが必要な部分は略している。本書の目標は、十分な基礎知識を提供し、必要に応じて特殊なトピックを学べる自信を与えるということだ。

翻訳については、正直サラッと読み流した程度なのでコメントするには適切ではない精読量かもしれませんが、私は違和感ない水準でよく訳されていると感じました。読みやすかったです。技術書だと、正直言って翻訳された結果日本語の文章がよくわからなくなっている本が多々あるといえばあるのですが、本書の翻訳は非常によかったと思います。

本書の主題であるシステムプログラミング(やコンピュータアーキテクチャコンピュータサイエンスの基礎)を学ぶことは、ソフトウェアエンジニア自身の足腰を強化する第一歩だと思います。Rust で足腰を鍛えたい方にはおすすめの一冊だと思います。私も引き続き、日本語で楽しみたいです。

*1:ソースコードが公開されています

*2:ちなみに著者は Rust コミュニティの運営にも携わっており、私自身も RustFest Global の運営で交流があったりします。コミュニティ運営でユーザーと接する機会が多いからでしょうか、よくポイントを押さえていると思います。

複数のテストケースをまとめたい際に使える test_case クレート

test_case というクレートを使用すると、複数のパターンのテストを1つのコードでまとめて記述できるようになります。実際に私もこのクレートを使用して、いくつかのテストをまとめて書いてみました。メリットは、重複コードを減らしつつ、テストがどこで失敗したかをひと目でわかるようにできるという点です。デメリットは、テストケースの入力値のコードが多いと、アトリビュートの可読性が下がりそうに見えるという点です。ただ、テストケースの可読性はそこまで重視されない傾向にはあると思うので、あまり気にするほどのことでもないかもしれません。

下記がクレートの GitHub あるいは crates.io のページです。

github.com

https://crates.io/crates/test-case

私が実際に test_case クレートを使ってみた例は下記です。

github.com

できること

複数のテストケースを1つの関数にまとめて assertion できるようになります。専用のマクロが用意されているので、そのマクロに入力の値と期待値を記述し、テストケースに名前をつければ実装できます。正常系のテストはもちろんのこと、専用の構文を利用すると異常系(panic するケース)にも対応できるように作られています。

正常系のテスト

下記のように、いくつかの入力パターンに対して加算のテストを行い、期待値をそれぞれのパターンに対して用意しておくというテストを書くものとします。10+20, 10+0, 0+10 など複数のパターンが考えられます。それぞれに対して assertion を行います。

通常の Rust のテストコードであれば、こうした複数入力パターンのテストについては、関数を別々に用意してテストケースをそれぞれ書くか、あるいは assertion を1つの関数内に複数個用意して対応します。下記の例では複数関数に分けることによって、テストの名前空間を分けるという意図で実装しています。関数を1つにして assertion を複数書く場合は、名前空間は分かれませんが関数がひとつで済みます。

    #[test]
    fn test_10_plus_20_should_work() {
        let e = add(integer(10), integer(20));
        assert_eq!(30, interpreter().interpret(e).unwrap());
    }

    #[test]
    fn test_10_plus_0_should_work() {
        let e = add(integer(10), integer(0));
        assert_eq!(10, interpreter().interpret(e).unwrap());
    }

    #[test]
    fn test_0_plus_10_should_work() {
        let e = add(integer(0), integer(10));
        assert_eq!(10, interpreter().interpret(e).unwrap());
    }

test_case クレートを使用すると、一つの関数にまとめつつ名前空間を分けてテストケースを用意できます。専用のマクロに入力値と期待値、テストケース名を記述することでそれを実現できます。

    use test_case::test_case;

    #[test_case(10, 20 => 30; "10_plus_20")]
    #[test_case(10, 0 => 10; "10_plus_0")]
    #[test_case(0, 10 => 10; "0_plus_10")]
    fn test_plus_should_work(lhs: i32, rhs: i32) -> i32 {
        let e = add(integer(lhs), integer(rhs));
        interpreter().interpret(e).unwrap()
    }

実装の内訳としては、

  • 10, 20 で入力の数値を記述しています。これが、関数の lhsrhs という仮引数に与えられます。
  • => 30 は期待値です。
  • ; の横の "10_plus_20" は、生成する関数名です。このマクロは interpreter::test::test_plus_should_work::_10_plus_20 という名前空間を裏で自動生成します。

となっています。

このテストは単純な数値以外にも、String などの別の組み込み型や、自身で用意した独自のデータ構造あるいは関数であっても適用できます。裏ではマクロによって各テストケースに対するコード生成が走っているだけなようなので、use してインポートしているモジュールについては、通常のコードを書くかのように使用できます。

下記は、別のモジュールにあるデータ構造と関数を使用したテストを記述している例です。add, integer, Expressionast というモジュールの配下にいるものとします。

    use crate::ast::*;

    #[test_case("idnta", add(integer(10), integer(20)) => 30; "assign_addition")]
    fn test_assignment_should_work(name: impl Into<String>, expression: Expression) -> i32 {
        let e = assignment(name, expression);
        let mut interpreter = interpreter();
        interpreter.interpret(e).unwrap())
    }

パニック時のテスト

通常の Rust のパニック時のテストの場合、正常時と同様に複数関数に分けつつ、#[should_panic] というアトリビュートをつけて実行します。このアトリビュートを使用すると裏でパニックが起きることを期待値としてテストが処理され、パニックに関するテストが実行可能です。

   #[test]
    #[should_panic]
    fn test_function_call_check_disable_while() {
        let mut parser = super::function_call();
        let actual = parser.parse("add(while (i > 0) { i; })");
        actual.unwrap();
    }

    #[test]
    #[should_panic]
    fn test_function_call_check_disable_if() {
        let mut parser = super::function_call();
        let actual = parser.parse("add(if (n > 1) { 1; } else { 0; })");
        actual.unwrap();
    }

    #[test]
    #[should_panic]
    fn test_function_call_check_disable_assignment() {
        let mut parser = super::function_call();
        let actual = parser.parse("add(n = 1)");
        actual.unwrap();
    }

このタイプのテストについても、test_case クレートの panics オプションを用いることで、正常系と同じように複数のテストケースをまとめて記述できるようになります。=> panics という記述を入力値の後ろに付け加えることで、実質裏で #[should_panic] による検知を行ってくれるという仕組みになっています。

また、panic の後ろには、パニック時に出力される文字列を記述し、その期待値を照合することもできます。この機能を使うと、いくつかパニックする可能性があるけれど、それらのうちのひとつを検出するテストを書きたい、というユースケースに対応することができます。

    #[test_case("add(while (i > 0) { i; })" => panics)]
    #[test_case("add(if (n > 1) { 1; } else { 0; })" => panics)]
    #[test_case("add(n = 1)" => panics)]
    fn test_function_call_disability<'a>(source: &'a str) {
        let mut parser = crate::parser::function_call();
        let actual = parser.parse(source);
        actual.unwrap();
    }

ユースケース、デメリット

今回私は言語処理系の入力値の検査に使用しました。言語処理系は、ちょっと形が違うだけの複数入力をいくつかテストするというケースがあるのですが、それらを効率よくまとめるのに大きく役立ちました。デメリットが強いてあるとすれば、アトリビュートに記述する入力値のコード量が増えると、その分アトリビュートのコード上に占める領域が広がり、認知負荷が上がりそうだという点でした。

ユースケース

言語処理系では、入力値に対する期待値をいくつかまとめてテストしたいというケースが発生します。具体的には先ほどのような足し算であったり、あるいは文字列の長さが違うだけのケースをそれぞれ通るか確かめたい、といったニーズが考えられます。

その際通常の Rust のテスト機能では、関数を複数分けるか、1つの関数の中に複数 assertion を設置するかという選択を取ることになります。関数を複数分けた場合には、コードの重複が多く発生することになり、若干メンテナンスコストが発生します。また、1つの関数の中に複数 assertion を設置すると、どこでテストが失敗したかが瞬時にはわかりにくいというデメリットがあると思います。

今回紹介した test_case クレートは、関数を複数に分けつつもコードの重複を発生させないテストケースの記述を可能にしてくれます。これを利用することにより、コードの量が増えてメンテナンスコストがかさむことと、テスト失敗時にどこで落ちたかわかりにくいという問題の両方をよい形で解決できるようになります。

感じたデメリットと回避方法

ただ注意点は可読性を高く保つのが困難だということです。test_case のアトリビュートの入力時の記述に通常の Rust コードを使用するのですが、1行に収まらない構造体の生成のようなコードを書いてしまうと、アトリビュートの記述が複数行に渡ってしまうことになるため、少し読みづらくなりそうだなと思いました。

もちろん、可読性の担保のためにテスト用の独自関数を用意して、可能な限りアトリビュートの記述を1行で済ませられるように頑張るという方法も考えられます。たとえば構造体の生成には new 関数をテスト用に特別に用意するなどです。が、テストコードのために通常のコードを増やすのは考える余地はありそうに見えます。一方で、テストコードの可読性は現場ではそこまで重視されない傾向にはあると思うので、そこまでがんばる必要はないという意見も十分ありえます。

使い所を選んで使う必要はありますが、全般的には記述量を減らせてよいクレートだと思いました。

RustConfメモ

さすがに時差の関係で全部は見られませんでしたが、出席していたのとアーカイブが残っていたので、いくつか気になったものを見てみました。ただ、家事などの合間に聞き流ししていた内容を思い出して書いているので、記憶が曖昧なところがあります。ご了承ください。すべてのセッションの動画リストはこちらにあります。

字幕はいくつか見てみましたが、自動生成でしょうか。second が segment 、toml が thermal になっていたりと少し間違っている箇所はありました。ただ、だいたいあってるので大丈夫そうです。もしよかったら、動画も見てみてください。

Whoops! I Rewrote It in Rust by Brian Martin

Twitter 社の方が Rust について語っているセッションでした。Pelikan という Twitter のキャッシングフレームワークに関する話をしています。元が C 実装だったコンポーネントを、Rust で書き直してみたというセッションです。個人的には1番おもしろくて、こういう仕事したいなと思うセッションでした。

github.com

特徴としては下記でしょうか。

  • Memcached コンパチ
  • tokio をネットワーキングに使用
  • C のストレージライブラリを使用

C をもともと使用していたようですが、Rust で書き直した際に 10%-15% のスループットの低下が観測されました。また、レイテンシーも C と比べると少し劣るというベンチマーク結果が出たようです。キャッシュ機構でのパフォーマンスの低下は、そのまま必要なクラスタの追加が必要ということにつながってくるため、そう簡単には許容できません。

C 実装では epoll を使用していたので mio を使用して epoll を使い C 側と揃えるようにし、C 実装と同じように簡潔なイベントループにしました。C のコンポーネントを Rust でほぼ書き直すなどの対応を取りました。要するに C 側の実装に揃うように Rust 側のコードを書き直したのです。すると、C と Rust のスループットレイテンシーはほとんど同じになりました。

その他、Rust で書き直した際に感じたよさに関して、いくつか語られていました。

最終的には Memcached よりもレイテンシの低いキャッシュサーバーが作れてしまったとのこと。これはテンション上がりますね。

Supercharging Your Code With Five Little-Known Attributes by Jackson Lewis

Rust のコードを眺めていると登場するアトリビュートについて、とくに便利なものを紹介しています。紹介されていたものは下記でしょうか。

個人的には readonly というアトリビュートは今すぐ使ってみようと思いました。

Fuzz Driven Development

略して FDD 。Fuzzing を使った開発の進め方について紹介しているセッションです。JSON パーサーを例にどのように Fuzzing 駆動開発を進めていくかについて解説されています。

最初の方に FDD の流れが説明されます。下記のような手順で FDD を行うことができます。

  1. Invariant: 不変条件を決定すること。
  2. Fuzzing Target: Fuzzing するターゲットを決定すること。
  3. Run until failure: 失敗するまで Fuzzing テストを実行すること。
  4. Reflect: なぜ失敗したか考えること。
  5. Develop/Unit tests: ユニットテストを書き、コードを追加して失敗したケースを通るようにすること。
  6. Iterate: 2に戻って、以下繰り返し。

JSON パーサーを例に取ると、

  1. パニックしないケースを考える。
  2. Fuzzer を使ってパーサーに値を入れられるコードを書く。
  3. Fuzzing Target を実行する。
  4. 結果を振り返る。
  5. 落ちたケースに関してユニットテストを書いて、対応する実装を追加する。
  6. 書いたケースが落ちないかの確認と、また別のケースでパニックするまで実行する。

といった流れになるようです。

実際に FDD をしながら開発を進めていく様子が話されていました。加えて、Rust のファジングについては Rust Fuzz Book が詳しいです。

Project Update: Libs Team by Mara Bos

Rust にコントリビューションしているとよく見る方ですね。

Mutex をめぐって、 Rust の標準ライブラリに parking_lot を入れるかどうか検討され、結果300以上のコメントがついたが力尽きてしまったという話が紹介されていました。議論が紛糾したのは非常に大きなインパクトを多方面に与える変更だったからです。

github.com

詳細は追いきれていませんが、Mara さんがその後いくつか修正を加えてこの修正を前に進めました。そのときの経験談について語られています。

こんなことがあったんだなあ、を知ることができたのでおもしろかったです。あと futex というシステムコールを知りました。

手元のアイスティー?がほとんどないのにまだ飲むか!みたいなツッコミを画面の前で入れてしまいました。

Hacking rustc: Contributing to the Compiler by Esteban Kuber

この方も Rust にコントリビューションしているとよく見る方ですね。

rustc へのコントリビューションを開始する人向けに、どうやってコントリビューションをしていくか、流れなどを説明してくれています。x.py などのツールから、Rust Compiler Dev Guide、RFC に関する話など網羅的に話してくれています。

Identifying Pokémon Cards by Hugo Peixoto

自分のポケモンカードのコレクションの整理に Rust を使ったという話。どのようにカードを画像認識させ、どのような Rust のクレートを使ったのかを説明しています。ホログラムの入ったカードの認識は難しいみたいです。

Rust.Tokyo 2021 を開催しました

9/18 に Rust.Tokyo 2021 を開催しました。2020年はコロナの影響が読みきれずキャンセルとしたので、2019年以来2度目の開催です。この2年間で Rust そのものやコミュニティイベントに関してさまざまなことがあったような気がしますが、それは後ほど書くことにします。

今年は2020年に引き続き世の中ができるだけ対面を避けよう、という状況の中行われたカンファレンスとなりました。したがって Rust.Tokyo そのものもオンラインで行いましたし、今やカンファレンスでよく見かけるようになった YouTube Live を使ったよくある形式を採用しました。もうかれこれこうした世の中になって1年半以上経つわけですが、オンラインカンファレンスは市民権を得ているように感じます。

今振り返ってみると、実はオーガナイザー側も一度も対面で会うことなく開催したカンファレンスとなりました。結局今年のミーティングは、キックオフから開催に至るまで、一度も対面で会っていません。なんだか不思議な感じがします。

この記事の免責事項ですが、私の意見を多く含みます。私の意見は必ずしも他の Rust.Tokyo チームメンバーの意見を代表するとは限りません。

今年のカンファレンス

  • 1トラック6セッション
  • 字幕を入れてみた
  • ほぼ事前録画のセッションに

少ない・短いと感じた方も多かったかもしれませんが、1トラック6セッション(スポンサー含め8セッション)としました。単純に運営のリソースと体力の制約です。RustFest Global で初のオンラインカンファレンスを経験したのですが、そのとき5時間1トラックではあったものの、疲労感があったように思いました。私は表にはほぼ出ないので、どらやきさんや同時通訳役をする chiko さんほどではないとは思いますが、それでも疲れました。

今年の試みとして、日本語発表には英語字幕を、英語発表には日本語字幕を入れました。翻訳は我々が行ったわけではなく、プロの翻訳業者を通しています。動画の字幕テロップ編集はどらやきさんが行いました。

字幕をつけたのには理由があります。英語セッションになるとリアクションがとても少なくなるというのを RustFest Global で思っていたのと、オンラインカンファレンスの時代になったので、時差の問題さえなんとかなれば世界中から参加者が来るためです。

英語セッションになるとリアクションが少なくなる問題は前から気になっていて、なので字幕を入れる提案しました。というのも、日本語話者は英語の発表の聞き取りが難しいことが多く*1リアクションを残せず、発表者はがんばって発表したもののなんだかリアクションが少ないぞ、という状況が発生するのは、お互いにとって不幸なのではと思っていたためです。結果はどうだったでしょうか?

Rust.Tokyo をはじめた2019年とは時代が大きく変わり、今やオンラインカンファレンスということで海外からも気軽に日本のカンファレンスに参加できるようになりました。私自身も先日の RustConf に少し参加していたのですが、現地に行かずとも発表を聞ける時代になりました。なので、できる限りそうした参加者のアクセシビリティを確保するためにも、英語の字幕はとくに必要です。

字幕や海外からも参加者を募る関係で、動画はできる限り事前録画を推奨することにしました。発表者の方の負担は正直なところ増えてしまったとは思いますが、結果字幕を埋め込むことができました。みなさんありがとうございました。

今年の担当

今年は下記を担当しました。

今年は新しくデザイナーさんが参加した初めてのカンファレンスとなりました。実は去年の1月か2月くらいに対面で一度お会いし、「今年もがんばるぞ」なんて話をしていたと思うのですが、2020年の Rust.Tokyo はキャンセルになり、RustFest Global には参加されなかったので、今年初めて彼女が参加したカンファレンスとなりました。

2019年はデザインを担当していたのですが、以前 Web デザイナーとして少し仕事をしていたことがあったとはいえ、さすがに私はもうソフトウェアエンジニアです。とくに意識的にデザインについてインプットしているとは言えず(デザインを見るのは好きなんですが)、実際いろいろデザインしてみて、引き出しの量にもちょっと限界があるなと思っていました。新しく入ってきていただいて非常に幅が広がりました。

今年できあがったロゴは下記のようになりました。当初の案ではお正月のようなベージュと赤の組み合わせのものもあったのですが、遠くから見た際の視認性の関係で今年は紫と赤の対比を選びました。デザインはできるだけ中性的になるように以前よりこだわってはいて、masculine *2になりすぎないように日本語を使った柔らかい表現を追加して調整してもらいました。

Rust.Tokyo 2021のロゴ
Rust.Tokyo 2021のロゴ。
中央の東京タワーは認知が取れていそうだったので残しつつ、
これまでとは少しバランスを変えました。

Twitter の広報の文章は(半ば勝手に)英訳を担当しました。まず英語でバーっと書いて、それを日本語で考え直してもう一度書く、というスタイルで書きました*3。ただたまにどらやきさんが英語を書いてくれるときもありました。セッションの広報用ツイートが主な仕事です。

Twitter の広報については、Rust.Tokyo は、最初から登壇者や参加者を日本語話者に限らないために日英両方を用意するようにしています。これには理由があり、今回のように中国や、韓国、そしてたとえばインドネシアベトナム、オーストラリアなどの地域からも参加できるようにするためです。Rust.Tokyo は RustFest のチームからは、どうやら APAC で連絡が取りやすいチームとして認識されているところがあり、そうした役割も少しだけ担っていると思っています。

私の個人的なカンファレンスの感想

私の感想は下記です。

  • 懇親会をしたかった
  • Web サービスのサーバーサイドのセッションなかった

懇親会がしたかったですね。oVice や remo など、懇親会をしやすいツールはいくつか存在しており、他のカンファレンスや学会では懇親会をそうしたツールを使って行うことがあります。頭の中からだいぶ抜けていて、Rust.Tokyo 開催の1週間前くらいからそうしたものをやりたいなと思い始めていました。時はすでに遅しですが。

最近の Rust コミュニティはほぼオンラインで LT 会などが開催される上に、1時間以上ある雑談がメインの懇親会がセットなものは少なく(ないんじゃ?)、Rust コミュニティにいる人の顔をほぼ知らないという寂しい状態になっています。私自身は、2018年〜2019年頃は登壇していたので、その際に多くの方と交流できてとても楽しかったのですが、最近はそうした機会がなくなってしまいました*4

Web アプリケーション開発に関連するセッションは今年は選出できませんでした。スポンサーセッションの Node.js 関連の発表がその一つだったかもしれません。が、Web サービスの Rust によるサーバーサイド開発のセッションがなかったのは、正直な気持ちを言うと少し寂しかったです。記憶では、CFP の時点でもなかったように思います。来年以降に期待です。

日本の Rust の流行について

せっかくですので、Rust のはやりについて少し言及しておこうと思います。私の観測範囲ですので、一般的な話にはできませんが。

  • 個人で触っている方は増えているように感じる
  • SNS での言及は増えているように感じる
  • ただ、企業での採用は増えてそうでしょうか?ちょっとわかりません

いつの間にか Rust のコミュニティに参加するようになって、もう3年〜4年くらい経ちます。2018年の頃と比べると、Rust への関心の高まりは非常に大きくなってきていると思います。私自身も Rust に関する講演を依頼されることが増えましたし、そうした講演が行われているのを見る機会も増えました。

また、私は実はよく新卒面接に出席し面接を行うのですが、学生さんが「Rust を書いています」と言っている確率がとても高くなってきているように感じます。3, 4年前は、それは Go でした。それが今は Rust に変わってきているように見受けられます。

数年前と比べると、明らかに認知度は高まってきています。

一方で SNS だけを見ていると感覚がおかしくなるのですが、とくに私のいる Web 系の会社に限っていうと、 Rust はまだ「これ、(どこで)使えるの?」というフェーズかと思っています。よく聞かれる質問は、「Go と Rust の違いは?」「Go のメリット/ Rust のメリット」といったところでしょうか*5。関心はあるが、導入には及び腰/ユースケースを思いつかないというのが現状かなと思っています。

そういった意味で、今回 PingCAP 社がスポンサーセッションで発表されたような、実際に会社の主軸となるプロダクトに Rust を使用した事例や Tips といった話はとくに貴重です。利用を迷っている方には、実際に入れた話が一番よい特効薬になるからです。

Rust.Tokyo では引き続き、そのような企業での導入事例もたくさん取り上げていきたいと思っています。普段の LT 会ではなかなか難しい話も、カンファレンスであれば可能なはずです。普段の LT では少し尺が足りない話を、ぜひ積極的にカンファレンスの場に出してもらえるととても嬉しいです。

最後に

カンファレンスやコミュニティは、プログラミング言語の「よさ」を支える柱の一つだと思っています。友好的で初心者にも親切なコミュニティには、多くの人が集まってくるはずです。Rust は、言語が主戦場とするフィールドは高度で、コンパイラは鬼教官でありながらも、豊富な機能でユーザーに力を与える (empowerment) 言語だと思っています*6。Rust の友好的なコミュニティは、今のところユーザーの empowerment に一役買っていると思います。

みなさんは Rust のどんなところが好きですか?

私は Rust コミュニティが友好的であり、多様な人の意見をそう簡単には排除しないというのはとても重要で好きだなと思っています。たとえば機能追加に関して言えば、Rust は RFC などを通じて、ユーザーが提案したものを一旦ディスカッションの対象としてくれる傾向にあると思います。「言語の機能がなぜこうなのか?」といった疑問をフォーラム等に書くと、RFC なり経緯を含む GitHub 上の URL なりが必ず返ってきて、理由を説明してくれます。「道を外れるな」「やめろ」といったパターナリスティックなコミュニケーションではなく、そもそも議論がオープンなところが好きです*7

Rust.Tokyo 2019 で、 Florian という元 Rust コアチーム(当時はそうだった?)の人がキーノートで言っていましたが、「『Rust が好きです』ということを発信することも立派なコントリビューションのひとつだ」と言っていたのを思い出しました。Rust を好きと言っていくだけで、あなたはもうコントリビュータなのです。好きをたくさん発信していきましょう。Rust.Tokyo をはじめとするカンファレンスをそのためにぜひ、今後ともご利用ください 🙋🏻‍♀️

*1:日本国内で英語を使う機会はほぼありませんから、こればかりはどうしようもありません。

*2:適切な日本語を思いつかず…

*3:英語を使っている時と日本語を使っている時で別の思考回路になってしまうのです…

*4:登壇していないというのもある。オンラインでの発表はどうも好きではなく、収まるのを待っています。ただ、懇親会のある LT 会がほぼなくなったのは事実だと思います。

*5:ちなみに私はこの手の質問には、「まずは実際に作ろうと思っているアプリケーションを作って動かしてみましょう」と答えます。たとえば、よくある Web アプリケーションのサーバーサイドで、よほどどちらかを積極的に採用できる理由がない限りは、書いてみて好きな方を使ったらよいと思うからです。「どちらを採用しても大して実利に差はない」局面において、両者を区別する大きな差異は書き味と、プログラミングという行為そのものに対する哲学だからです。これはもはや言ってしまえば好き嫌いの問題に換言されると思います。ただ現状だと Rust を使うとエコシステムが未成熟で適切なものがない可能性はありますが。

*6:Rust の根本哲学は empowerment です。公式ガイドにも言及があるくらいには、この言葉を大切にしています。

*7:他には、変数宣言が let で始まるとか、コンパイルさえ通れば書いたとおりに動く(そして書いた以上のことはしない)とか、強く型付けできるし強く型付けしたほうが静的ディスパッチになって速度的にもよいとか、あとはそもそも言語仕様からちょっと小難しく、そこに知的好奇心がくすぐられるところも含めて好きです。

Swift で filter や map 、flatMap などのコンビネータを実装してみる

今年の言語として Swift を選んで最近練習しています。Swift は iOS を作るために使用されることが多いですが、言語としての表現力が非常に豊かで、たとえば Web アプリケーションのサーバーサイド開発に利用できるのではないかと思っています。まだ Swift を学び始めでランタイムなどには詳しくないので、どこまでいけるのかはわかっていません。が、可能性を感じます。

新しい言語を学ぶ際にやることはいくつかあるのですが、型の表現が豊かそうな言語であればまっさきにやるのは「連結リストを作ってモナドっぽいものを足してみる」です。Swift にはジェネリクスがあるほか、言語に組み込みで Optional などの型が存在しており、それなりに型の表現力があるのではないかと感じました。なので、試してみました。

結論としては、

  • 連結リストは結構気持ちよく書ける上に、言語特有のおもしろい機能があるようです。
  • Swift には高カインド型(HKT)がサポートされていないのでモナドは実装できません。
  • Swift には検査例外があるので、それを考慮した実装にする必要がありそうです。

といったところでしょうか。

この記事は Swift を書き始めてまだ24時間経った程度の超初心者が書く記事です。したがって、各所に誤りを含む可能性があります。その点を留意してご覧ください。

実際に書いてみる

連結リストを作る

まずは連結リストを作ってみましょう。連結リストの概観がわからない方はこちらをご覧ください。

Swift では enum を使って次のように書くことができます。これは他の Rust や Scala 3 などとほぼ同じような記法で、後ほどパターンマッチングで中身を取り出せる点も同じです。

enum List<T: Equatable> {
    indirect case cons(head: T, tail: List<T>)
    case `nil`
}

Swift では nil予約語です。なので、バッククオートで囲む必要があります。

注目すべきなのは indirect で、これは再帰的な enum (Recursive Enumerations)を作る際に使用するキーワードです。このキーワードを付与すると、ヒープ領域が確保され値がそこにコピーされるという動作が行われるようです*1。このケースの場合、cons が確保する必要のあるメモリサイズがわからないため、残念ながらスタック領域を使用したメモリの確保が難しくなります。そのため、ヒープ領域に値を確保することにしているといったところでしょうか*2

Swift のメモリ管理

indirect キーワードの裏側を理解するためには、Swift における値型と参照型の違いの理解を必要とします。Swift には enumstruct といったキーワードを代表とする値型と呼ばれる概念と、class といったキーワードを代表とする参照型という概念があります。この2つの理解は、Swift のメモリモデルの理解につながってきます。

値型は、変数の値が参照ではなく直接値をもつ型のことをいいます。変数や定数に値を代入されたときや、引数として渡された際に値のコピーが裏で走り、新たにメモリ領域が確保されます。値型には structenum が該当しますが、これらの所有者は常に1つであることが保証されている型です。値型は再帰的なデータ構造をもつことは、コピー時に確保すべきメモリ領域が不明であることからできません。

参照型は、変数の値への参照をもつ型のことをいいます。値型とは異なり、変数や定数に値を代入された際や、引数として渡された際には、既存のインスタンスへの参照が渡されます。参照型には class が該当します。

値型は、使用されなくなるとすぐに確保されていたメモリ領域が解放されます。これは値型を使用するひとつのメリットになりえます。

参照型の方については、メモリ管理に ARC という仕組みが利用されます。要するに参照カウンタが後ろにいて、ある参照型への参照がどの程度残っているかをチェックしています。カウントがゼロになれば、その参照型が確保していたメモリ領域は解放されるという仕組みです。参照カウンタを利用している以上、循環参照によるメモリリークのリスクと隣り合わせであり、要するに注意して使う必要がありそうということがわかります。

値型は都度コピーコストが発生しますが、Swift はコレクションに対しては Copy on Write という最適化を適用するようです。これにより、評価が必要になるまでコピーを行わないという方式をとっているようです。*3

値型と参照型の使い分けは、調べた限りではケースバイケースの微妙な使い分けをはらんでいるようです。他の言語でもそうですが、局所的に参照をもたせてスコープを狭めながら使うのがよさそうです。Swift の標準ライブラリを読むと struct を基本にデータ構造を設計していることから、基本は struct 中心に構築していくものだと思います。使い分けについてはこちらの資料がわかりやすいです。

最後に、この enum は下記のようにして呼び出すことができます。

let list = List.cons(1, List.cons(2, List.cons(3, List.cons(4, List.`nil`))))

便利プロパティを生やす

プロパティをいくつか生やしていきます。プロパティとは、型に紐付いた値のことです。空判定や先頭の取り出しなどを定義していきます。

extension List {
    var isEmpty: Bool {
        return self == .`nil`
    }
    
    var head: T? {
        switch self {
        case .`nil`:
            return nil
        case .cons(let h, _):
            return h
        }
    }
    
    var tail: List<T>? {
        switch self{
        case .`nil`:
            return nil
        case .cons(_, let t):
            return t
        }
    }
    
    var len: Int {
        switch self {
        case .`nil`:
            return 0
        case .cons(_, let t):
            return 1 + t.len
        }
    }
    
    var first: T? {
        return self.head
    }
    
    var last: T? {
        switch self {
        case .`nil`:
            return nil
        case .cons(let h, .`nil`):
            return h
        case .cons(_, let t):
            return t.last
        }
    }

実装内容そのものは他の言語と変わりありませんが、いくつか注目すべきポイントがあります。 extension キーワード switch、そして Computed Property です。

extension キーワードは、すでに存在する型に対してプロパティやメソッド、イニシャライザなどの型を構成する要素をあとから追加できる機能です。型を拡張することができます。Scala などでは enrich my library という技法で親しまれていたほか、Scala 3 では extension キーワードが同じく使えるようになっています。内実はああいった機能と似ています。今回 enum への実装は extension を使って追加しています。

switch 文は Java や C などにある同等の機能とよく似ています。違いとしては、パターンマッチングができる点だと思います。switch 文を使いながら enum のヴァリアントに応じて処理を記述できます。なお、Swift では switch は文であることに注意が必要です。

Computed Property はアクセスがあるたびに毎回計算が走るプロパティです。計算元との値の整合が常に取れるという特徴があります。Swift に数あるプロパティのひとつです。Swift にはこの他にも Stored Property というものがあります。上の例では、isEmptylen などが Computed Property として定義されています。

高階関数を書く

まだ関数の話もしていませんが、飛び石して高階関数を書いていきます。高階関数を書くためには、まず関数定義とクロージャーが必要です。Swift では、関数定義は func というキーワードで定義できます。クロージャーも言語機能として提供されています。

filter, map, flatMap などのコンビネータは、foldr という関数を使うことですべて実装可能です。foldr 関数を実装した後に各コンビネータを実装するという流れで実装していきます。

// extension の続き
    func foldr<U>(acc: U, f: (T, U) -> U) -> U {
        switch self {
        case .`nil`:
            return acc
        case .cons(let h, let t):
            return f(h, t.foldr(acc: acc, f: f))
        }
    }
    
    func map<U>(f: (T) -> U) -> List<U> {
        return self.foldr(acc: List<U>.`nil`, f: { acc, list in
            return List<U>.cons(head: f(acc), tail: list)
        })
    }
    
    func flatMap<U>(f: (T) -> List<U>) -> List<U> {
        return foldr(acc: List<U>.`nil`, f: { acc, list in
            return f(acc).append(another: list)
        })
    }
    
    func filter(p: (T) -> Bool) -> List<T> {
        return foldr(acc: List<T>.`nil`, f: { acc, list in
            if p(acc) {
                return List.cons(head: acc, tail: list)
            }
            return list
        })
    }

クロージャーの記法ですが、仮引数の際は (遷移元型) -> 遷移先型 で書くことができます。実引数として渡す場合には記法が変わり、{ 一時変数名 in 処理内容 } となるようです。他の言語では仮引数でも実引数でも記法がだいたい一致していると思いますが、Swift は異なるので注意が必要そうです。

ソースコードは下記にあります。

github.com

Swift 本体のコードを少し読んでみる

モナドにするのは厳しそうなことはわかったのですが、今度は Swift 本体がどのように Functor 等を構築しているのかが気になってきました。少し読んでみたのでそのことについて書きます。ただ、今回目を通したのは Optional 型だけなので、もしかすると見落としているかもしれません。

github.com

検査例外の存在

たとえば Optional の Map の実装は次のようになっています。

  @inlinable
  public func map<U>(
    _ transform: (Wrapped) throws -> U
  ) rethrows -> U? {
    switch self {
    case .some(let y):
      return .some(try transform(y))
    case .none:
      return .none
    }
  }

完全に見落としていたのですが、Swift には検査例外があります。throwsrethrows は検査例外があるがゆえの記述です。今回作ったリスト構造と付随するコンビネータを本番で使えるコードにするためには、高階関数であってもエラーの可能性を考慮した実装にする必要があるようですね。

throws はエラーを送出する可能性があることを示すキーワードです。Java につける同等のキーワードと同じ役割を果たしています。

rethrows は、引数のクロージャーが発生させるエラーを呼び出し元へ伝播させるためのキーワードです。これは Java にはなく、Javaラムダ式を実装した際には、例外をハンドリングできる自前のインタフェースを用意して対処した記憶があります。便利なキーワードです。

最後に try キーワードですが、これはエラーを発生させる可能性がある処理を実行するために使用します。つまりこの場合は、transform という関数はエラーを発生させる可能性がある処理だ、ということがわかります。実際、transform の型シグネチャtransform: (Wrapped) throws -> U ですから、これはエラーを発生させる可能性がある関数です。

Swift における2種類のエラーハンドリング

Swift はこれまで検査例外一筋だったようです。ただ、Swift の検査例外は Java のそれと比較するとかなり改善されているようです。実際、私も map 関数のコードを読んで各キーワードを軽く調べてみましたが、Java のそれと比べると使い心地も安全性も向上しているように思われます。

Swift には他にも、Swift 5.0 以降から利用できる Result 型が入ってきているようです。Rust の Result 型と使い方にほぼ差はありません。ただ、既存の検査例外との共存や使い分けが少々難しそうに見えました。Swift の Result 型は、現在のところ非同期的な処理のエラーハンドリングに利用されることが想定されているようです

あまり抽象化はされていない

map 関数やその他の関数も読んでみましたが、どうやら Functor のような型を新たに作ってそちらに処理を集約させるといったことはしていないように思われました。

他にも配列の map や flatMap の実装も読んでみましたが、個別実装されています。

Swift を触った感想

  • 言語仕様はかなり野心的である一方、そうした野心的な機能を快適に利用できるようにする実用性も兼ね備えていると思いました。また、暗黙的に裏で言語のランタイムが気を利かせて何かをやらないようにしている感じがしており、明示的にキーワードを指定する必要があるのもよかったです。加えてたとえば、Int + Double の演算は暗黙的にはできません。どちらかを明示的にキャストする必要があります。
  • 触って24時間程度ですが、今のところびっくりするような挙動はありません。書いたら書いたとおりに動きますし、書いた以上のことはしません。これは極めて重要だと思います。資料を読んでいると参照型のあたりが少しびっくりするかもしれない予感がしていますが…。
  • iOS 開発に関連する Swift の情報はかなり充実している一方で、私のような道を外れた Swift の使い方をするための情報はなかなか Google さんが上に出してくれず、苦戦しました。最初 Xcode でどうやって素の Swift コードを動かすか、やり方がわからずまとめました…→Swift で iOS や MacOS アプリではない開発をはじめる
  • メモリの確保の仕方を厳密に定義しようと思えば、それなりにできそうなところはよいところだと思います。
  • mutability / immutability を明示的に管理できそうなところもよいポイントだと思います。
  • キーワードがとにかく多いです。もちろん特定の状況下でのみ有効になるキーワードもあるから一概には言えませんが、予約語が多くて、普段使っている変数名や関数名が不意にキーワードになってコンパイルエラーになったりします。ただこれは、ユーザーにとっては嬉しいかも。特定の機能を呼び出すために型パズルを作るか、増えたキーワードを覚えるかは言語のスタンスによりそうです。
  • 型推論はそこまで強くないように思いました。Scala 2 と同じくらいの強さかなと言う感じがします。サンプルで載せたコードをご覧いただいてもわかるとおり、比較的型注釈を必要とする傾向にあると思います。

*1:余談ですが、古い Swift のスナップショットでは Rust と同じように Box を使ってヒープ領域を確保していたように見受けられます。Swift をはじめて触った感想は「とにかく特殊な場面向けのキーワードが多いな」といったでした。Box 型も、言語のアップデートによって indirect キーワードに変わっていったようです。特殊な用途ごとに型ではなくキーワードを用意する――これはある種の Swift の設計思想なのでしょうか。参考: https://airspeedvelocity.net/2015/07/22/a-persistent-tree-using-indirect-enums-in-swift/

*2:このあたりを説明している資料を相当数探してみたが、見つけられませんでした。どこかにあるのだろうか。

*3:具体的な動きは下記の記事がわかりやすいです: https://medium.com/@lucianoalmeida1/understanding-swift-copy-on-write-mechanisms-52ac31d68f2f

Rustで型を強めにつけ、バリデーション情報を型に落とす方法

Rust を読んでいると、さまざまなものに型付けをするコードをよく見かけます。強めに(厳密に)型付けをする文化があるプログラミング言語、と言えるかもれません。

バリデーションチェックに対してもこうした強めの型付けが適用できます。具体的なバリデーションの情報を型情報として落としておくことで、コードを読むだけでバリデーション情報を把握できたり、あるいは誤った値の代入をコンパイルタイムで弾くことができるようになるというメリットを享受できるようになります。

一方で、型情報があまりに複雑化すると、あまりそうした型付け手法に慣れていないプログラマがキャッチアップするのに少し時間がかかったり、あるいはとんでもなく複雑になってそもそもその型を作り切るのが大変というデメリットも生じることになります。

今日紹介する手法は、さまざまなトレードオフの上に成り立つものであり、もし導入の結果、そのプロジェクトにとって得られるものが最適であると判断できるならば利用するとよいと思います。

それでは、実際にどのように型付けできるのかを見ていきましょう。Web アプリケーションではバリデーションチェックはまずまず大きな比重を占める実装であり、今回は Web アプリケーションで使用することを前提としています。

今回の要件

今回は、所定の長さ以下の文字列かどうかを判定するバリデーションを実装したいものとします。8文字以下の判定と、4文字以下の判定を実装することにします。また、文字列は空であってはならないものとします。

バリデーションを通過できなかった場合は、下記のエラーを表現する enum を返すものとします。

#[derive(Debug)]
pub enum ValidationError {
    NotAllowedEmpty,
    InvalidFormat(String),
}

Rust で愚直に実装するとしたら、「特定の条件を満たすかどうかを if 文で判定し、満たさなければエラーにして返す」のような実装が考えられるかもしれません。下記は文字列が空でないか、ならびに8文字以下かをチェックする関数です。

fn maybe_fail(source: String) -> Result<String, ValidationError> {
    if source.is_empty() {
        return Err(ValidationError::NotAllowedEmpty);
    }

    if source.len() > 8 {
        return Err(ValidationError::InvalidFormat("文字列は8文字以下にしてください".to_string()));
    }

    Ok(source)
}

このような実装を、型駆動のプログラミングではどのように実装していくかについて、今回の記事では議論を進めることにします。

デザイン

どういう結果が得られるのか

最終的な使い心地は、たとえば次のようになるようにしたいものとします。

pub struct MyUserId(NonEmptyString<LessThanEqualEight>);

impl MyUserId {
    pub fn new(raw: NonEmptyString<LessThanEqualEight>) -> Result<Self, ValidationError> {
        Ok(MyUserId(raw))
    }
}

fn create_user_id_with_validate() -> Result<MyUserId, ValidationError> {
    let raw_words = "myuseridisover8words".parse()?; // これはエラーになるが
    MyUserId::new(raw_words)
}
  • &str に対する parse を呼び出すと、裏で自動でバリデーションチェックをかけてくれる。内容は、可能ならば後続の処理から型推論される。
  • バリデーションチェックを通った値のみが MyUserId::new に入ってくることになる。どういう値が入っているかは、new 関数の引数の型を見るとわかる。

このコードを実行すると、結果エラーになります。parse の時点で、「文字列が空でないか&8文字以下か」というバリデーションチェックが走るように実装しているためです。

では、どのようにそうした仕組みを実現しているのかについて、これから見ていきます。

実装する

基本的な登場人物

今回主役となる型は NonEmptyString とその型引数に使用されている LessThanEqualEight です。これらは実際にどのようになっているのでしょうか。

NonEmptyString

NonEmptyString は非常に単純な実装で、型引数として V を受け取り、内部には String 型なフィールドと PhantomData を持っているだけの構造体です。PhantomData が必要なのは、 V を実際には使用していないものの、Rust では使用しない型引数を構造体に残したままにするとコンパイルエラーになるためです。それを回避するために、_marker というフィールドが必要になります。

pub struct NonEmptyString<V>
where
    V: ValidateStrategy,
{
    pub value: String,
    _marker: PhantomData<fn() -> V>,
}

V にはさらに ValidationStrategy が必要というトレイト境界が付与されています。この ValidationStrategy が、「どのようなバリデーション規則を適用するか」を型で表現するために重要になります。次はこの ValidationStrategy と、その活用方法について見ていきましょう。

ValidationStrategy

ValidationStrategy はトレイトです。関数に validate をもっています。

pub trait ValidationStrategy {
    fn validate(target: &str) -> Result<String, ValidationError>;
}

先ほど LessThanEqualEight という型引数が少し登場してきました。この型は ValidationStrategy を実装しています。この validate の実装内容は、後々別の箇所で呼び出されることになります。

8文字以下であることのバリデーションチェックの実装内容は、具体的には下記のようになっています。

    pub struct LessThanEqualEight;
    impl ValidationStrategy for LessThanEqualEight {
        fn validate(target: &str) -> Result<String, ValidationError> {
            if target.len() <= 8 {
                Ok(target.to_string())
            } else {
                Err(ValidationError::InvalidFormat(format!(
                    "{} must be less than equal 8",
                    &target
                )))
            }
        }
    }

もし、他のバリデーション規則を追加したいとなった場合には、ValidationStrategy を実装した新しい構造体を用意することで追加できます。今回のサンプルコードでは、rules というモジュールを新たに切り、その中に別のバリデーション規則を用意しています。下記は、たとえば4文字以下となるような文字列かどうかをバリデーションするという規則を追加する例です。

pub mod rules {
    use super::ValidationStrategy;
    use crate::types::error::ValidationError;

    pub struct LessThanEqualFour;
    impl ValidationStrategy for LessThanEqualFour {
        fn validate(target: &str) -> Result<String, ValidationError> {
            if target.len() <= 4 {
                Ok(target.to_string())
            } else {
                Err(ValidationError::InvalidFormat(format!(
                    "{} must be less than equal 4",
                    &target
                )))
            }
        }
    }

    pub struct LessThanEqualEight;
    impl ValidationStrategy for LessThanEqualEight {
        fn validate(target: &str) -> Result<String, ValidationError> {
            if target.len() <= 8 {
                Ok(target.to_string())
            } else {
                Err(ValidationError::InvalidFormat(format!(
                    "{} must be less than equal 8",
                    &target
                )))
            }
        }
    }
}

ここまでで準備は整いました。

// 8文字以下のバリデーションチェックを含む文字列型であると示す型
NonEmptyString<LessThanEqualEight>

// 4文字以下のバリデーションチェックを含む文字列型であると示す型
NonEmptyString<LessThanEqualFour>

使いやすくする

ただ、都度 validate のような関数を呼び出していると、そもそも呼び出し忘れが起きたり、あるいは面倒に感じたりするなど厄介です。この型を生成するタイミングでバリデーションチェックが走ってくれると、非常に使い勝手のよいものになるかもしれません。

今回はたとえば、&str 型から変換するタイミングでバリデーションチェックを起こせるとよいかもしれないというユースケースにあたっているものとします。Rust では、&str 型から任意の型に変換する際の作業を統一的に扱えるようにしてくれる便利な機能があります。FromStr トレイトです。今回は、これを NonEmptyString で実装するようにします。

NonEmptyString には V という「どのようなバリデーション規則を用いるか」を示す型引数がありました。これは ValidationStrategy というトレイトをトレイト境界としてもっています。なので、validate 関数を呼び出すと、あとは解決された具象実装側の validate が実行されることになります。LessThanEqualEight 型なら、8文字以下かどうかのチェックが走りますし、LessThanEqualFour 型なら、4文字以下のチェックが走ります。

impl<T> FromStr for NonEmptyString<T>
where
    T: ValidationStrategy,
{
    type Err = ValidationError;

    fn from_str(s: &str) -> Result<Self, Self::Err> {
        if s.is_empty() {
            return Err(ValidationError::NotAllowedEmpty);
        }
        let validated = T::validate(s)?;
        Ok(NonEmptyString {
            value: validated,
            _marker: PhantomData,
        })
    }
}

あとは、文字列をパースする関数を呼び出します。型推論が難しい箇所では次のように Turbofish による型の明示が必要になりますが

let _ = "is this less than eight?".parse::<NonEmptyString<LessThanEqualEight>>()?;

後続処理に関数がありそこから型推論が可能な場合には、単に parse 関数を呼び出すだけでよくなります。

let source = "is this less than eight?".parse()?;
// new 関数で NonEmptyString<LessThanEqualEight> を受け取ることがわかっているので、parse の型がここから逆算されて判明する
let user_id = MyUserId::new(source); 

あるいは、NonEmptyString::new のような関数を生やして、そこに FromStr に記述したのと同等の内容を実装してもよいかもしれません。これはどうこの型を使いたいかによると思います。

工夫の余地

  • バリデーション規則の impl の実装が少々面倒くさい: これは専用のマクロを実装することで解消できます。今回は書いていませんが、具象型、バリデーション規則、エラーとして何を返すかを引数として取るマクロを用意し、そのマクロの内部で impl ValidationStrategy for {具象型} のようなコードの生成を行えます。
  • 文字列型以外にも適用したい: FromStr は使えなくなりますが、文字列型以外でも当然実装可能です。ただ、ValidationStrategy はもう少し一般化が可能で、そうした方が便利だと思います。

最終的な実装

gist.github.com

まとめ

  • バリデーション情報を型に落とし込む方法を紹介しました。
  • 型引数を用いることでそれが実現できることを学びました。
  • トレイトを上手に使うと、実装を自動でいくつか導出でき、結果使いやすい形におさめることができることも学びました。

『Amazon Web Services 基礎からのネットワーク&サーバー構築』を Terraform でチャレンジする

アプリケーションエンジニアではあるものの、AWS はかなり触る機会が多いです。アプリケーションエンジニアといえど、AWS に関してある程度知見をもっていないとよりよいアプリケーションを作ることができない時代になってきました。それだけ、AWS に依存した設計が増えてきています。

AWS には以前から苦手意識がありましたが、近年では EKS を新規事業に参画した際に導入してみたり、また Lambda と Kinesis Streams をつないでハイパフォーマンスなアプリケーションを実装してみたり、DynamoDB のパフォーマンスチューニングを考案したりと、AWS のいわゆるミドルウェアレイヤーには結構強くなってきたんじゃないかと思っています。

しかし、どうしても苦手な領域があります。ネットワークです。ネットワークだけはほんとに興味が出なくて、今までずっと避けてきました。ただ、そろそろ食わず嫌いしていられないなと思い、今回本書を手にとってチュートリアルをこなしてみることにしました。

ただ、普通に GUI の画面を操作しながらやってもさすがにおもしろくないと思い、Terraform を使って構築するというのをお題にしてみました。

Terraform には以前チャレンジしていましたが、あれから月日が立ち、お手伝い先で Terraform をいじる機会やプロダクトで Terraform をいじる機会が増えてきました。もはや自分がどこにアイデンティティがあるのかわかりにくくなってきており、スペシャリスト指向ではあるもののジェネラリストなのでは…という悩みと日々戦っていますが、よりよいアプリケーションを作るためには手段を選ばないポリシーのもと、そういった仕事にも取り組んでいます。

一方で、Terraform についてはすでに動いているものの上で作業することが多く、1からの構築というのはやったことがありませんでした。なので、チャレンジしがいがある取り組みだと思い、やってみることにしました。

というわけで、今回はそのやってみたです。

github.com

Terraform 自体や各 tf ファイルの詳しい解説は不要だと思うので、簡単にリポジトリ内でのポリシーを書き留めておきたいと思います。

設計

基本はリソース単位でわけています。

  • ami
  • ec2
  • key_pair
  • sg (セキュリティグループ)
  • vpc (この中に、VPC やサブネット、NAT やルートテーブルの設定が含まれます)

また、下記はプロジェクト全体の設定ファイルです。

  • provider (terraform 自体のいろいろな設定が記載さています)
  • variables (terraform.tfvars から読み込んで変数をセットし、各 tf ファイル内で参照できるようにしています)

ちょっと試行錯誤したポイント

Apache をインストールする章があるのですが、それを remote-exec で実行できるようにしています。

  provisioner "remote-exec" {
    connection {
      host        = self.public_ip
      type        = "ssh"
      user        = "ec2-user"
      private_key = file(var.private_key_path)
    }
    inline = [
      "sudo yum -y install httpd",
      "sudo systemctl start httpd.service",
      "sudo systemctl enable httpd.service"
    ]
  }

ただここには結局反映していませんが、DB サーバー側では MariaDB をセットアップしたり、以降 WordPress を設定したりといろいろ追加事項が多かったです。

このあたりは Ansible を使って管理するのが筋だと思いますが、Terraform と Ansible は両方を組み合わせることができないというか、ライフサイクルを別にする必要があるような気がしています。

Terraform は Packer と相性がいいようで、Packer で作った AMI を Terraform に読み込ませるという手順ならば、Terraform のライフサイクル下でインスタンスの状態を管理できそうで、便利そうだなと思っています。これは時間を見つけて取り組んでおこうと思っています。

本の感想

本書は 1 から VPCインスタンスを構築し、その上で Maria DB や WordPress を動かしてみるという内容になっています。章ごとにステップアップしながら成果物が完成していきます。説明も、簡潔ではあるもののポイントを抑えながら進んでいきます。とくに、新しく登場した用語について必ず何かしらの補足説明がなされるのが、丁寧で好印象でした。

また、AWS の知識だけにとどまらず、たとえば業界未経験の方や新卒の方でも読めるくらい基本的な内容から取り扱っているのが好印象でした。たとえば HTTP のリクエストの中身を覗いてみたり、TCP/IP に関して詳しめの解説があったりするなどです。運用に関して必要になるツールも付録に掲載されています。

私のような、キャリアが最初からアプリケーションエンジニアでネットワーク周りは一切触れてきませんでした、という人であってもしっかり理解しきれる内容に仕上がっていると思います。私は本書の内容は実はほとんど既知でしたが(断片は業務でよく使ってた)、Terraform で構築してみるという別の楽しみ方ができてよかったと思いました。CDK や Terraform を試してみたい際の題材としても利用できると思います。

次の一手

この本で「VPC が何」「サブネットが何」「NAT が何」といった知識は一通り抑えられたと思います。次はどういった本がいいでしょうか?

この先の話は、インターネット上に無料で資料が公開されており、かつそういった資料のクオリティが高いのでそちらを読むといいと思います。

AWS の各サービスについてより応用的な話を知りたいと思ったときは、私はよく「サービス名 Black Belt」で検索して資料を読んでみるようにしています。

今回の VPC 周りの話ももれなく Black Belt の資料があります。この資料では、VPC の運用周りについてさらに詳しく深ぼっています。たとえば、VPC Flow Logs を使ったアクセス周りのモニタリングや、Guard Duty を使ったセキュリティの担保に関する話などが載っています。

www.slideshare.net

次にやってみたいこと

自宅で、あるいは友だちや同僚と結構マイクラをやるんですが、せっかくなのでマイクラのサーバーを Realms ではなく自分で立ててみたいなと思っています。Bedrock エディションのサーバーを ECS 上に構築してみたいです。それを Terraform で管理するようにしたらおもしろそうだなーと思っています。チャレンジしてみよう。