Rust on blog.kyu08.com

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだ

Mon, 22 Dec 2025 00:13:06 +0900

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだので感じたことをメモしておく。

『ＲｕｓｔによるＷｅｂアプリケーション開発　設計からリリース・運用まで』（豊田　優貴,松本　健太郎,吉川　哲史）　製品詳細　講談社

★Rustによるアプリケーション開発のベストプラクティス！　Rustを現場で使うときがきた！ Rust経験豊富な筆者が、貴重な知識とテクニックを惜しみなく伝授。「蔵書管理アプリケーション」の実装を通じて、Rustによる設計、開発、保守、運用までをハンズオンで学ぶ！コードも丁寧に解説。【目次】第1章　本書で開発するもの第2章　開発環境の構築第3章　最小構成アプリケーションの実装第4章　蔵書管理サーバーアプリケーションの設計第5章　蔵書管理サーバーの実装第6章　システムの結合とテスト第7章　アプリケーションの運用第8章　エコシステムの紹介

https://www.kodansha.co.jp/book/products/0000398182

モチベーション

Rustという言語の開発体験がかなり好きでRustでサーバーサイドを書くのがどんな感じなのか純粋に気になっていたので読んでみた。（筆者がサーバーサイドの開発でガッツリ書いたことがあるのはほぼGoのみで、RustはCLIやTUIの開発にしか使ったことがないというバックグラウンド）

本書の概要

本書はRustで蔵書管理アプリケーションのサーバーサイドを実装しながらRustでのWebアプリケーション開発の仕方を学ぶことができる本。

ただ動くものを作る、というよりは業務の実際のサーバーサイドの開発でよく出くわす課題をRustではどう実装するのかが豊富に紹介されている。(DIやエラーハンドリングなど)

設計面ではレイヤードアーキテクチャを採用しており、レイヤー間の責務などが考慮された設計になっている。その意味でも実務での開発に近い内容になっていると言える。

あとはステップごとのコード差分が丁寧に書かれているので、本書に従って実装を進めるとWeb Serverの実装が出来上がる（はず）。¹

学び

コンパイル時間短縮の工夫
- アプリケーションを複数のクレートに分割することで変更があったクレートだけ再コンパイルすればよくなるためコンパイル時間が短縮できる。
- たとえば本書ではレイヤードアーキテクチャのレイヤーごとにクレートを分割していた。
Web開発で有用なクレート
- derive_new: new関数を実装してくれる。デフォルト値の設定などもできる模様。
- serde: 言わずと知れたシリアライズ/デシリアライズのためのクレート。
- sqlx: SQLを型安全に扱うことができる。
エラーハンドリングの方法
- クライアントに返すエラーはthiserrorで定義し、それ以外のエラーはanyhowを使って表現する。
RustでどうDIを実装すべきか
- ジェネリクスを用いてDIするパターン（静的ディスパッチ）
  - 動的ディスパッチと比較すると記述量が増える
  - 動的ディスパッチと比較するとパフォーマンスが高い
- トレイトオブジェクト（dyn <トレイト名>）を利用するパターン（動的ディスパッチ）
  - 静的ディスパッチと比較すると記述量が減る
  - 静的ディスパッチと比較するとパフォーマンス面で不利
  - 本書ではWeb開発において動的ディスパッチのコストが問題になることは少ないことを理由にこちらを採用していた。

実際にRustでWeb Serverを書いてみた感想（主にGoとの比較）

※なお、筆者のRustスキルは趣味レベルなのでRustを深く理解したうえでの感想ではありません。間違っている点や他の重要な観点などがある可能性があります。また、主には個人的な考えのスナップショットを自分用に残す目的で書いているので説明を端折っている箇所がある可能性があります。

ポジ

enumやパターンマッチ等を使って仕様をスマートに書ける。
null安全なので他の言語のnull相当の概念を型安全に扱うことができる。
if式を始めとした関数型ライクな言語機能のおかげで開発体験が良い。
変数がデフォルトでimmutableなので、mutableな変数を目立たせやすいし、自然とimmutableなコードが書きやすい。
あらゆるシンボルがデフォルトでprivateなのでカプセル化するようなコードが若干書きやすい。（意識的にpubを付けなければprivateになってくれる点で強い理由がなければprivateになりやすくなる、と考えている）

ネガ

コンパイル時間が長い。
コンパイル時間短縮のためにcrate分割が推奨されているが、依存関係の増減があるたびにCargo.tomlを手書きで編集しないといけないのが若干面倒。
- もしかしたらコードアクション等、エディタの支援が得られるのかもしれないがそこまで調べられていない。

Goに慣れているとRustのマクロやアトリビュートが若干黒魔術的に感じる。これらに慣れるまでは認知負荷が高そう。例えば以下。（『RustによるWebアプリケーション開発設計からリリース・運用まで』より引用）

#[derive(Error, Debug)]
pub enum AppError {
    #[error("{0}")]
    UnprocessableEntity(String),
    #[error("{0}")]
    EntityNotFound(String),
    #[error("{0}")]
    ValidationError(#[from] garde::Report),
    #[error("トランザクションを実行できませんでした。")]
    TransactionError(#[source] sqlx::Error),
    #[error("データベース処理実行中にエラーが発生しました。")]
    SpecificOperationError(#[source] sqlx::Error),
    #[error("No rows affected: {0}")]
    NoRowsAffectedError(String),
    #[error("{0}")]
    KeyValueStoreError(#[from] redis::RedisError),
    #[error("{0}")]
    BcryptError(#[from] bcrypt::BcryptError),
    #[error("{0}")]
    ConvertToUuidError(#[from] uuid::Error),
    #[error("ログインに失敗しました")]
    UnauthenticatedError,
    #[error("認可情報が誤っています")]
    UnauthorizedError,
    #[error("許可されていない操作です")]
    ForbiddenOperation,
    #[error("{0}")]
    ConversionEntityError(String),
}

DIが若干複雑
- Goならinterface使うだけなので考えることが少なくて済む。
非同期処理
- これもRustの非同期処理の仕組みへの理解²が大変浅いのであまり具体的に書けないが、自分の現状のRustスキルだとGoに比べて意図通りに動く非同期処理を書くのに数倍時間がかかる。

まとめ

本書を読むまではRustがWebサーバーサイド開発の銀の弾丸、とまでは言わないもののかなりいい選択肢の1つのように思えていた。主に型の表現力のおかげでドメインがうまく表現できたり、所有権などの言語機能や発達したリンターによって内部品質を高く保つことができ、その結果開発生産性が高まると考えていた。

しかし実際に本書でRustでサーバーを書いてみると上記のメリットはありつつも意外とRustでの実装でも手間や複雑なポイントがあり、Goのシンプルさや手軽さの良さを改めて認識した。

結果はともあれ実際にRustでサーバーを書くのがどんな感じなのかを知ることが本書を読んだ目的だったので解像度を高めることができてよかった。³

5章の途中までしかやっていないので「はず」と書いている。 ↩︎
あるいは単にコンピュータの仕組みへの理解が浅いとも言えるのかもしれない。 ↩︎
もちろんもっとDeep Diveしたら違う感想を持つかも知れないが、あくまで今時点の自分の感想としては上記のような感じ。 ↩︎

『コンセプトから理解するRust』を読んだ

Mon, 15 Dec 2025 19:21:35 +0900

Rustのことをもっと理解りたくて『コンセプトから理解するRust』を読んだ。

コンセプトから理解するRust | 技術評論社

Rustはメモリ安全、スレッド安全を保ちつつ、高パフォーマンスなプログラムを開発できるプログラミング言語です。また、手続き型、オブジェクト指向型、関数型でのプログラミングに対応できるマルチパラダイムの言語でもあります。ただ、そういったRustのポテンシャルを引き出すには、所有権やライフタイム、ジェネリクスやトレイトといった特徴的な仕様の理解が求められ、これらは初学者の壁にもなっています。本書ではそれら難解な仕様をピックアップし、他のプログラミング言語とコードレベルで比較しながら、「なぜそのような仕様になっているか」という言語のコンセプトからRustの理解を試みます。加えて、Rustのこまやかなエラーメッセージを読みつつ、Rustをうまく書くための知識もお伝えします。

https://gihyo.jp/book/2022/978-4-297-12562-2

前提

筆者のRustの知識はTour of RustやThe Rust Programming Languageを読んだり簡単なツール¹を作ったことがある程度で、非同期処理をスラスラ書けたり、スムーズに人に教えたりできるレベルではない。

過去にThe Rust Programming Languageを読んだときもスマートポインターまわりなどは飛ばしつつ読んでいたので本書での学びは多かった。

学び

Boxについて理解した。
Rc, RefCell, Weak周りをなんとなく理解した。たぶん空では書けないが、エラーになったら調べて解決できるくらいの理解にはなったはず。
トレイト境界についてちょっとわかった。
クロージャ, Fn, FnMut, FnOnceについて理解できた。
簡単な非同期処理の仕組みがわかった。

今まで全然わかっていなかったこれらの概念が少しだけわかった。やはりコードを書き散らかすだけでなく体系的なインプットも大事…。（それはそう）²

おそらく今後Rustを書いたりコンパイラと対話したりしていくともう少し深く理解していけると思う。³

全体を通してコード例が豊富だったので手元で動かしながら理解しやすくてとてもありがたかった。

まとめ

Rustの力がまた少しついた。

Rustを学ぶとRust自体への理解が深まるだけでなく、少なからずコンピュータの仕組みに近い低レイヤな部分の理解も一緒に深まるので勉強になる感覚があって楽しめた。

非同期処理周りはあまりちゃんと勉強したことがないので次はこの本を読んでみようと思う。（サンプルコードが主にRustで書かれているらしいのでこの本での学びも活かせそう）⁴

並行プログラミング入門

複数のプログラムを同時に実行する「並行プログラミング」は、処理速度を飛躍的に向上させる手法で、タスク管理、プロセス管理、スレッド管理をはじめ、複雑な仕組みについての幅広い知識とテクニックが必要となります。本書はRustとアセンブリ、そして一部Cを用い、CPUのアトミック命令、グリーンスレッド、アクターモデル、π計算、ソフトウェア・トランザクショナルメモリ、async/awaitなど、並行プログラミングに関する理論的な背景から実装までをカバー。さらに、アセンブリ実装の理解を深めるため、AArch64とx86-64アーキテクチャの説明も付録として収録。一歩一歩、着実に理解できるように、その仕組みから順を追って詳しく説明します。GitHub上で公開されているソースコードを実際に動かしながら、並行プログラミングの知識と理解を深めることができます。

https://www.oreilly.co.jp/books/9784873119595/

おまけ

The name “Tokio” is derived from Tokyo and mio, and the Tokio logo vaguely resembles the city emblem of Tokyo.

https://en.wikipedia.org/wiki/Tokio_(software)

Rustの非同期ランタイムのtokioの名前の由来の一部は東京らしい。

あとロゴも東京都の紋章を彷彿とさせるデザインになっているらしい。（実際調べてみたら似ているというかほぼ同じだったw）

fzf-makeというTUIツールを書いている。あとそういえばnand2tetrisもRustで書いていた。 ↩︎
趣味のプログラミングなのでRustを覚え始めた頃は楽しさ優先でまあ動けばOKという気持ちで書いていたが最近になってちゃんと理解したくなってきたので学んでいる。 ↩︎
あるいは各種概念を自作するという選択肢もあるかもしれない。Arcとか非同期ランタイムとか…。 ↩︎
他には詳解 Rustアトミック操作とロック、Async Rust 、RustによるWebアプリケーション開発　設計からリリース・運用まであたりもとても気になっている。 ↩︎

関数型まつり2025に参加した

Sun, 15 Jun 2025 05:00:00 +0000

2025/06/14(土)、2025/06/15(日)に中野セントラルパークで行われた関数型まつり2025に参加した。

筆者はElmやRustの開発体験を気に入っており、Webアプリケーションのサーバーサイドを関数型言語で書くことに興味があったので参加してみた。

関数型言語テイスティング: Haskell, Scala, Clojure, Elixirを比べて味わう関数型プログラミングの旨さ - lagénorhynque/カマイルカさん

lagénorhynque/カマイルカさんによるHaskell, Scala, Clojure, Elixirの紹介と比較を行う発表。

部分適用や関数合成やパイプ演算子などElmで便利だった言語機能を思い出しながら聞いていた。

文法を見ていると、Elmの文法はかなりHaskellに近いようだった。(ML系と呼ばれるらしい)

あとは関数型かつ動的型付け言語の実際のアプリケーション開発での書き味が全然想像がつかないのでちょっとElixirやClojureを書いてみたくなった。質疑応答でも触れられていたが、実際にML系の言語とlispなどの動的型付け言語の関数型言語ではメンタルモデルが違うらしい。

発表の最後に関数型プログラマのメンタルモデルとして以下のようなことを紹介されていて、自分が関数型言語から得た学びと重なる部分が多かった。

適切な制約が解放をもたらす
- 純粋関数を基本にしてコードを組み立てていく
- いつでもどこでも破壊的に更新できるデータ構造は怖いため不変/永続データを基本に
- 適切な型を定義することで不正値を表現不能にしてより型安全に
単純で安定したブロックを基礎に全体を構成したい
- 式思考、宣言的、合成可能

関数型言語を採用し、維持し、継続する - 松澤有さん

Siiibo証券株式会社のCTOである松澤さんによる自社プロダクトのフロントエンド、バックエンドの開発言語として関数型言語(Elm, Elixir)をなぜ採用したのか、そしていかにして維持し、継続しているかについての発表。実は主にこの発表を聞くために関数型まつりに参加したので良い発表を聞けてよかった。

関数型言語を採用し、維持し、継続する

https://zenn.dev/siiibo_tech/articles/adopting-fp-languages

結局はラストマンシップを持って自分がなんとかするという気概が重要だという話が一番印象的だった。これは関数型言語を業務で書いているわけではない自分にも大いに参考になる話だと思っていて、結局どんな技術を採用したかやCTOかメンバーかなどにかかわらず、このラストマンシップを持っているエンジニアが多ければ多いほど開発組織は強固になるんだろうなと思った。

また「アウトリーチを怠らなければ意外と世の中にちゃんと仲間はいる」ということをおっしゃっていて、使用言語がメインストリームであろうとなかろうと外部発信を通してコミュニティに貢献したり認知を獲得することの重要性を改めて感じた。やっていき。

総じて松澤さんのエンジニアとしてのマインドセット的な部分がとても参考になった。

技術的な内容に関しては、コードレビューの話とUpkeepの話が参考になった。

コードレビューに関しては以下のようなことをおっしゃっていて、とても参考になった。特に2番目に関しては、前提としてコード品質を重要視するマインドがチームに装備されている必要があると思っていて、それをどう実現しているのか気になった。

自分がいいと思う技術であっても、それを伝道できなければあとが続かない
チームにとって良いコードとはどのようなものか、ということを感覚、信念として共有できる状態に持っていくことを目指している
人は忘れるし、一度言っただけで身につくことは誰であれないので繰り返し伝えていくことが重要

Upkeepとは維持費の意味で、ここでは依存ライブラリや言語自体のバージョンアップなどのことを指す。こまめにバージョンアップ作業をやっておくことでいざというときに言語やライブラリの新機能をすぐ取り込めたり、巨大なバージョンアップのせいでデグレするリスクを低減できたりと良いこと尽くめだと改めて感じた。（もちろん簡単ではないが）

あとはバージョンを最新に保つという行為に名前をつけたことがなかったのでUpkeepという語で表現するのはいいなーと思った。

以下発表を聞きながら取ったメモ。(発表を聞きつつスライドを見ながら書いたメモなので誤りが含まれる場合があります🙇)

技術選定の方針

CTO, Founding Engineerが技術構成を選ぶにあたっての観点
- まともなモノを継続的に提供するに足る機能があるか
- それを実際につくるヒトを継続的に集められるか
（スタートアップなら）
- （上記2点を説得材料として）カネを集められるか

非メインストリーム言語でどうやっていくか

ElixirやElmはメインストリームと目されているとは言えず、モノ・ヒト・カネの要素を自信を持って揃えるには弱い
とはいえ、良いと感じた技術があって、良いものを作れると検証できたのであればあとは自分がやるかどうかでしかない
- 勝手に機会は降ってこない
勇気と周りを巻き込んで走り続ける力が重要

コードレビューの技術

自分がいいと思う技術であっても、それを伝道できなければあとが続かない
健全で有意義なコードレビューのやり取りがどのようなものか？という経験とその内面化が重要
どういうコードがチームにとって良いコードかを伝道する
- 感覚、信念として共有できる状態に持っていきたい
以下の理由でコードレビューで繰り返し伝えていくことが重要
- 人は忘れる
- 新しい人は入る
- 一度言っただけで身につくことは誰であれ、ない

Upkeep

Upkeepとは維持費の意味で、ここでは依存ライブラリや言語自体のバージョンアップなどのことを指す。
Upkeep恐怖症にならずにこまめにやれる環境をつくる。
(バージョンアップ作業がやりやすいのは言語の大きな加点項目)
Elixirで静的型検査の導入が2022年に発表された
- Upkeepしておくと、こういった新機能もすぐに取り込める

情報収集

言語公式フォーラム, ML, Slack, Discordのウォッチ
- そもそもコミュニティがデカすぎないので最新動向をすべて追うのがそこまで大変ではない
コンパイラ、主要ライブラリのissue trackerも購読する
- チーム内で抱えてる課題と似たような話題も出たりする
Twitter

コミュニティ還元

フォーラムでの質問を見るだけでなく回答もする
- 小さいコミュニティなので自分が第一人者、Front Runnerである可能性もある
国内外の勉強会参加、主催協力も積極的に行う

採用

やれることをやり、アウトリーチもすることが採用に直結する
非メインストリーム言語だとその言語を業務で書くにはそもそも会社の選択肢が少なかったりするので、意外とマッチングしやすかったりもする

続けていく気概

結局大事なのは言いだしっぺがケツを持つ気概があるかどうか
アウトリーチを怠らなければ意外と世の中にちゃんと仲間はいる

産業機械をElixirで制御する - 菊池豊さん

菊池豊さんによる複数の水力発電の制御ソフトウェアをElixirで書いた経験を紹介する発表。

Elixirは書きやすく、コミュニティも盛り上がっているという話を聞いてちょっと書いてみたくなった。

以下メモ。

課題

Python
- 並行プログラミングができなかった
- コンパイラでの支援が期待できなかった
リプレイス先の候補はGo, Rust, Haskell, Erlang, Elm
- Elixir を使うようになった経緯〜電力システム制御の現場から〜

Why Elixir

世俗型関数型言語
- 関数型であることにこだわりすぎず使いやすさがある
- コミュニティも楽しかった
並行性
- アクターモデル
パイプ演算子
パターンマッチ

Elixirにないもの

型
- 静的型解析がほしい

Lean言語は新世代の純粋関数型言語になれるか？ - 井上亜星さん

井上亜星さんによるLean言語の紹介の発表。

この発表でLean言語という言語の存在を知った。純粋関数型言語でありながらforループやwhileループを書けるのはユニークだなーと思った。

What I have learned from 15 years of functional programming - Scott Wlaschinさん

Scott Wlaschinさんによる関数型プログラミングでの学びを共有する発表。

「直和型とレコード型を駆使しドメインモデリングを正確に表現することで保守性が向上するだけでなく動作可能なドキュメントとしても機能する」という話が印象に残った。

前者のメリットは以前から感じていたが、後者の観点はなかったので面白かった。（言われてみればそれはそうという感じだが）

以下メモ。

パイプライン指向で書くことで保守性の高いコードを書くことができる
- 以前はSOLID原則を満たすことを意識しすぎてしまいうまくいかなかったが、パイプライン的な志向でコードを書くことで自然と綺麗なコードを書くことができ、SOLID原則も自然と満たすことができるようになったとのこと
ドメインモデリング
- 直和型をうまく使ってドメインモデルを正確に表現する
  - 保守性が高くなり、バグが減る
  - 実行可能なドキュメントとしても機能する
Railway Oriented Programmingを使うことでエラー処理を伴う処理を保守性高く書くことができる¹

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股健太郎さん

猪股健太郎さんによるF#の言語設計の特徴、設計意図を紹介する発表。

純粋関数型言語なのかと思っていたが、命令形っぽい書き方もできることは知らなかった。他の.NET言語との相互運用性があるのも便利そう。

以下メモ。

概要

OCamlに大きな影響を受けている
金融工学、データサイエンス、科学計算、Webアプリなどで活用されている
F#をJavaScriptにトランスパイルするコンパイラもあり、フロントエンドも書ける

F#の特徴

静的型付けの非純粋関数型言語である。
- デフォルトはイミュータブルだがmutableにもできる
- .NETランタイムは仮想マシン型
  - C#, F#など複数言語を.NETランタイム上で動かす前提で設計されており共通中間言語、共通型システム、共通言語仕様を備える
ホスト環境との相互運用性
- F#で書かれたコードは他の.NET言語から自然かつ安全に利用可能
マルチパラダイム言語
- 関数型プログラミングのパラダイムを核に、オブジェクト指向プログラミングの要素も備える
- クラスや構造体も書ける

言語設計の意図

プログラマーが命令的なコーディングから関数型のコーディングへ移行する際のハードルを下げることを意識した設計になっているらしい。

マイクロサービス内で動くAPIをF#で書いている - ayato-pさん

ayato-pさんによるマイクロサービスの1サービスをF#で書く際の設計や悩みどころを紹介する発表。

ドメイン設計の際に容易にOptionを使わずにenumの別のvariantとして表現する、という考え方はRustなどでも活かせそうだと思った。別の概念であれば別の型として表現するのが大事そう。

以下メモ。

どんなチームで採用したのか
- ペアプログラミングを中心に100人超の組織で開発している
- モノリス -> マイクロサービスの移行をやっている
- マイクロサービスの各APIは多種多様な言語で書かれている
F#導入以前のプロダクトチーム
- JVM系、Elixir, Go, Rust, OCaml, Haskellなども採用
- .NET系の言語は採用されていなかった
どう導入したのか
- システムのコアにいきなり採用するのはリスキーだったのでなにかあってもまずは影響が少ないサブシステムで採用
なぜF#か
- 静的型付け
- シンタックスが簡素
- .NETの資産を活用できる

F#らしさを活かした設計

Optionなどを入れずに判別共用体を使って設計する

e.g. 上場企業と非上場企業を表現するときにisListed: bool, listedAt: Option<DateTime>のように表現するのではなく…

type Company = 
  { id: CompanyId
    name: string
    isListed: bool
    listedAt: Option<DateTime> }

そもそも別のvariantとして表現する

type Listed = Listed of listedAt: DateTime

type CompanyProfile = 
  { id: CompanyId
    name: string }

[<RequireQualifiedAccess>]
type Company = 
  | Listed of CompanyProfile * Listed
  | UnListed of CompanyProfile

スポンサーブース

Jane Streetのエンジニアの方にお聞きしたがJane StreetではフロントエンドとサーバーサイドをOCamlで書いているらしい（！）ブースでお話した方も関数型言語が書きたくて入社したそうで、関数型言語への愛を感じた。

ブースでいただいたノベルティのTシャツもめっちゃOCamlだった。

ノベルティ

入場時にロゴ入りのトートバッグがもらえた。

Nulabさんのノベルティのマイクロファイバークロス。実用的でありがたい。

まとめ

今は業務で関数型言語を使うことはないが、関数型言語の考え方を取り入れることで非関数型言語でもより良いコードを書けるようになると改めて感じた。

個人で初めてオフラインの勉強会/カンファレンスに参加したが普通に楽しかったのでまた行ってみようと思う。

つけ麺情報

二代目えん寺がとても美味しかった。

Elm Patternsでも紹介されていたのを思い出した。改めて読み直してみよう。 ↩︎

cargoプロジェクトで依存関係を継続的に管理する

Tue, 20 May 2025 15:00:00 +0000

OSSに依存するプロジェクトでは依存しているライブラリのライセンス表記が必要になることがある。（体感的にはほとんどのライブラリはライセンス表記を求めているように思う）

そのため、依存ライブラリが増えた場合にはライセンス表記を更新する必要があるが、依存ライブラリの依存ライブラリに対しても再帰的にライセンス表記を見に行って自リポジトリの依存ライセンス表記ファイルを更新して…という作業を行うのは現実的ではない。

他にもうっかりコピーレフトなライブラリに依存してしまうとプロジェクトのライセンスを変更しなければならなかったりと案外注意すべきポイントが多い。

cargoプロジェクトにおいてこれらの労力を削減してくれるツールがいくつか存在している。

筆者は趣味プロジェクトとしてfzf-makeというmake targetやpnpm script, yarn script, just recipeをfuzzy finder形式で選択、実行できるCLIツール¹をRustで開発しており、このプロジェクトで最近それらのツールを導入したので使い方とともに紹介する。

tl;dr

以下のチェックをCIで実行することでcargoプロジェクトの依存関係を継続的に省力で管理できる。

cargo-machete: 不要な依存関係がないか
cargo-deny: 依存ライブラリに許容しないライセンスが含まれていないか
cargo-about: リポジトリのライセンス表記ファイルに更新漏れがないか

それぞれ紹介する。なお、コード例はそれぞれ以下のランナーを想定している。

環境	ランナー
ローカル	make
CI	GitHub Actions

`cargo-machete`で不要な依存関係を検出する

why

ある程度の期間開発を続けていると以前追加した依存関係が不要になったことに気付かずにcargo.tomlのdependenciesやdev-dependenciesに残ったままになることがある。不要な依存関係が残ったままになっているとrenovateやdependabotによるバージョン更新の手間が不必要に増えてしまうのでPRの時点で気付けるようにしたい。

what

cargo-macheteを使ってcargo.tomlに記述されている依存関係のうち、プロジェクトが実際には依存していない依存関係を検出する。

how(ローカル)

以下のようなmake targetを定義しておくとmake detect-unused-dependenciesで不要な依存関係を検出できる。

.PHONY: tool-detect-unused-dependencies
tool-detect-unused-dependencies:
	@if ! which cargo-machete > /dev/null; then \
		cargo install --locked cargo-machete; \
	fi

.PHONY: detect-unused-dependencies
detect-unused-dependencies: tool-detect-unused-dependencies
	cargo machete

以下は不必要な依存関係としてtempfileが検出されている様子。

how(CI)

以下のようなyamlを定義しておくと不要な依存関係がある場合にCIが落ちてくれる。

name: Detect unused dependencies
on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  detect-unused-dependencies:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Machete
        uses: bnjbvr/cargo-machete@v0.8.0

`cargo-deny`で依存ライブラリに許容しないライセンスが含まれていないか検証する

why

筆者はfzf-makeをより自由に利用してほしいと考えているためMITライセンスでプロジェクトを公開したい。コピーレフトのライセンスに依存してしまうとライセンス変更を余儀なくされるため、コピーレフトのライブラリに依存することを避けたい。

what

cargo-denyは依存関係のlint機能を提供する。fzf-makeでは、cargo deny check licensesを用いてホワイトリストに登録したライセンス以外のライセンスが依存ライブラリに含まれていないか検証している。

# deny.toml
[licenses]
allow = [
    "MIT",
    "ISC",
    "Apache-2.0",
    "MPL-2.0",
    "BSD-2-Clause",
    "BSD-3-Clause",
    "Unicode-DFS-2016",
    "OpenSSL",
]
confidence-threshold = 0.8
exceptions = []

[[licenses.clarify]]
name = "ring"
expression = "MIT AND ISC AND OpenSSL"
license-files = [
    { path = "LICENSE", hash = 0xbd0eed23 }
]

how(ローカル)

以下のようなmake targetを定義しておくとmake check-licensesで依存ライブラリに許容しないライセンスが含まれていないかを検証できる。

.PHONY: tool-check-licenses
tool-check-licenses:
	@if ! which cargo-deny > /dev/null; then \
		cargo install --locked cargo-deny; \
	fi

.PHONY: check-licenses
check-licenses: tool-check-licenses
	cargo deny check licenses

許可していないライセンスのライブラリに依存していることがわかると以下のようなエラーが出力される。

how(CI)

以下のようなyamlを定義しておくと不要な依存関係があるとCIが落ちてくれる。

name: Check licenses
on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: EmbarkStudios/cargo-deny-action@v2
      with:
        command: check licenses

`cargo-about`でリポジトリのライセンス表記が最新か検証する

why

冒頭でも触れた通り、多くのOSSでは依存ライブラリのライセンス表記を求めている。

fzf-makeではCREDITS.htmlというファイルを用意しておりそこに依存ライブラリのライセンス表記を記載している。

これまでは依存ライブラリを追加/削除した際に手作業でライセンス表記ファイルを更新していたが、漏れがちになっていた。

また、本来は依存ライブラリの依存ライブラリを再帰的にチェックしてすべてのライセンス表記をすべきなのだと思うが、手作業でそれをする気にはなれなかったので直接依存しているライブラリのライセンスしか表記できていなかった。

これらの課題をcargo-aboutを用いることで解決できそうだったので導入してみた。

what

cargo-aboutは依存ライブラリのライセンス表記ファイルを自動生成する機能を提供する。

以下のようなテンプレートを用意し、cargo about generate about.hbs > CREDITS.htmlを実行するとCREDITS.htmlにライセンス表記を出力してくれる。

<html>
    <head>
        <style>
            @media (prefers-color-scheme: dark) {
                body {
                    background: #333;
                    color: white;
                }
                a {
                    color: skyblue;
                }
            }
            .container {
                font-family: sans-serif;
                max-width: 800px;
                margin: 0 auto;
            }
            .intro {
                text-align: center;
            }
            .licenses-list {
                list-style-type: none;
                margin: 0;
                padding: 0;
            }
            .license-used-by {
                margin-top: -10px;
            }
            .license-text {
                max-height: 200px;
                overflow-y: scroll;
                white-space: pre-wrap;
            }
        </style>
    </head>
    <body>
        <main class="container">
            <div class="intro">
                <h1>Third Party Licenses</h1>
                <p>This page lists the licenses of the projects used in fzf-make.</p>
            </div>
        
            <h2>Overview of licenses:</h2>
            <ul class="licenses-overview">
                {{#each overview}}
                <li><a href="#{{id}}">{{name}}</a> ({{count}})</li>
                {{/each}}
            </ul>

            <h2>All license text:</h2>
            <ul class="licenses-list">
                {{#each licenses}}
                <li class="license">
                    <h3 id="{{id}}">{{name}}</h3>
                    <h4>Used by:</h4>
                    <ul class="license-used-by">
                        {{#each used_by}}
                        <li><a href="{{#if crate.repository}} {{crate.repository}} {{else}} https://crates.io/crates/{{crate.name}} {{/if}}">{{crate.name}} {{crate.version}}</a></li>
                        {{/each}}
                    </ul>
                    <pre class="license-text">{{text}}</pre>
                </li>
                {{/each}}
            </ul>
        </main>
    </body>
</html>

how(ローカル)

以下のようなmake targetを定義しておくとmake update-license-fileで依存ライブラリのライセンス表記が最新か検証できる。

.PHONY: tool-update-license-file
tool-update-license-file:
	@if ! which cargo-about > /dev/null; then \
		cargo install --locked cargo-about; \
	fi

.PHONY: update-license-file
update-license-file: tool-update-license-file
	cargo about generate about.hbs > CREDITS.html

how(CI)

以下のようなyamlを定義しておくと依存ライブラリのライセンス表記が最新でないとCIが落ちてくれる。

name: Check license file
on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  check-license-file:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Check
        run: make update-license-file
      - name: Check diff
        run: |
          git add .
          git diff --cached --exit-code

なお、デフォルトだと以下の部分のThis page...fzf-makeの部分がThis page lists the licenses of the projects used in cargo-about.として出力される。そのため、そのまま利用すると「cargo-aboutプロジェクトでは以下のライセンスに依存しています」という意味の表示になってしまうためユーザーが忘れずにcargo-aboutの部分をプロジェクト名に変更する必要があるという問題がある。²

<div class="intro">
    <h1>Third Party Licenses</h1>
    <p>This page lists the licenses of the projects used in fzf-make.</p>
</div>

これに関しては以下のissueを立ててみたのでcargo-about側と意見が一致したら修正するPRを送ってみようと思う。

[Feature request] change cargo about init to generate the statement including user’s project name.

おわりに

繰り返しの定型タスクをCIに任せることができたので開発により集中できるようになった。（趣味開発だと数ヶ月ぶりにコミットするとかもザラにあり、開発に必要なタスクを忘れがちなのでそういった意味でも自動化の範囲を増やすことができてよかった）

便利ツールをOSSとして公開してくれている人/企業に感謝しつつ利用するだけでなく自分にできる貢献はやっていきたい。

fzf-makeの紹介記事: [make,pnpm,yarn,justに対応]コマンドをfuzzy finder形式で選択できるCLIツール fzf-makeの紹介 ↩︎
そして実際に90件近くのプロジェクトでcargo-aboutのままになっている。 ↩︎

GitHub Sponsorsの寄付先にratatuiを追加した

Mon, 23 Sep 2024 15:02:46 +0000

OSSへの寄付の月予算を$10にした - laiso

こちらの記事で寄付するOSSプロジェクトの選び方として次のような基準が紹介されていた。

寄付するプロジェクトはこういう基準で選んでる

自分が使っていてなくなったら困る

マイナーであまり寄付されていない

今まで前者の基準に則ってneovimに寄付していたが、後者の観点を持てていなかったことに気付いた。そこで自分もOSSへの寄付を見直してみようと思った。

というわけで

タイトルの通りだが、GitHub Sponsorsの寄付先にratatuiを追加した。

ratatuiとは、手軽にTUIアプリケーションを作成できるRust用のライブラリで、筆者が個人開発しているOSSであるfzf-makeでも利用している。¹

ratatuiのおかげでこんな感じのUIを手軽に実装できている。

Rust製のTUIツールでは非常に幅広く利用されている印象だが、現在のスポンサー数が9人と少なかったので少しでも力になれればということで寄付先に追加した。長期間メンテされる状態が続いてくれると嬉しい。自分にもできそうなバグ修正があれば挑戦してみようと思う。

10番目のスポンサーになった様子。

これで現在の寄付額は$10/月で、neovimとratatuiにそれぞれ$5ずつ寄付していることになる。

他にも寄付したいプロジェクトは山ほどあるので山ほど稼いでいきたい。(あと円高頼む…)

まとめ

今後ともOSSコミュニティの持続可能性を高めていきたい。

make targetをプレビューウィンドウ付きであいまい検索によって選択&実行できるツール。brewやcargoでインストールできるのでぜひ。

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.
A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make
https://github.com/kyu08/fzf-make

↩︎

Makefileに定義されたtargetをfzfで選択して実行するCLIツールをRustでつくった

Fri, 31 Mar 2023 01:15:48 +0900

(2024/12/14追記) 内容を更新した紹介記事をZennに投稿しました。

[make,pnpm,yarnに対応]タスクランナーのコマンドをfuzzy finder形式で選択できるCLIツール fzf-makeの紹介

Makefileに定義されたtargetをfzfで選択して実行するCLIツールをRustでつくった。

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

こんな感じで動く。

fzf-makeがやっていること

Makefileからtargetを正規表現で抜き出す
skim(※)に実行オプションとtargetたちを渡す
skimがプレビューウィンドウ付きのfuzzy-finderを表示
skimから選択されたtargetが返ってくるのでmake ${target}を実行

基本的な動作はすべてskim任せになっていてRust側でやっているのはskimとのやりとりくらいになっている。

※lotabout/skim…Rust製のfuzzy-finder。Rustのライブラリとして利用することもできる。

(makeの文法が思ったより多彩っぽかったので自分が必要とするごく簡単なユースケース以外をカバーするのは早々に諦めた。(makeで1冊本が書けるぐらいだしそれはそうという感じではある))

brewコマンドでインストールできるので気になる方はぜひ。

brew tap kyu08/tap
brew install kyu08/tap/fzf-make

ソースも公開しているので、「こう書くといいよ」とかバグとかありましたらぜひissueやPRで教えてください。

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

実装

上述の通り処理の大部分はskim任せになっている。(書いたコードはテストを含めても200行程度)

ただskimをライブラリとして利用する実装サンプルがあまりなかったのがちょっと大変だった。特にプレビューウィンドウの表示にfzfの候補文字列を変数としたシェルコマンドの形で渡すことができることに気づくまでに時間がかかった

↓の{}にtarget名が入るイメージ。

let preview_command = r"line=$(bat Makefile | grep -nE '^{}\s*:' | sed -e 's/:.*//g'); bat --style=numbers --color=always --line-range $line: --highlight-line $line Makefile";

fzf-make/src/misc.rs at 3a627d0a1aa75b1bf1ff87f3443f63393afbcf10 · kyu08/fzf-make

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make/blob/3a627d0a1aa75b1bf1ff87f3443f63393afbcf10/src/misc.rs#L18

あとはgoでいつもやっている感じでテーブル駆動テストっぽくテストを書いてみた。可読性も保守性も高いので割と気に入っている。

fzf-make/src/misc.rs at 3a627d0a1aa75b1bf1ff87f3443f63393afbcf10 · kyu08/fzf-make

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make/blob/3a627d0a1aa75b1bf1ff87f3443f63393afbcf10/src/misc.rs#L145

動機

Rustが書きたかった。(以上)

最近Rustのやっていきが高まっており、The Rust Programming Language を1周したので何か作ってみるぞーという機運とMakefileのターゲットをfuzzy-finderで絞り込めたら便利そうだなーという気持ちが重なったのでRustでfzf-makeを作ってみた。 (あとはskimの存在を知っていたのも大きい。)

自分が欲しいCLIツールを手に入れつつRustの経験が積めたのでよかった。

ちなみにRustに入門した直接的(?)なきっかけとしてはこのスライドを目にして、「Elmっぽい！楽しそう！」と思ったのが発端だった。Rustに興味を持っている人はぜひ読んでみて欲しい。

満を持して始める Rust

Rustを触ってみて感じたこと

Rustを触る前に持っていた印象は「コンパイルが通りずらく、安全性が高い」「関数型っぽい」という感じだった。

実際に学んでみた印象は次のような感じ。

関数型っぽい書き心地
- 特にenumとパターンマッチング,Option型 ,Result型, 式指向な考え方などの関数型っぽい言語機能や極力データをイミュータブルに扱う思想などが心地よかった。筆者が大好きな言語であるElm(ウェブブラウザベースのGUIを作成するための純粋関数型)の好きな部分をほとんど含んでたのでElmに近い感覚で書くことができた。(もちろん慣れてないこともあってElmよりも全然難しかったけど)
- (Elmが気になる方はElm Guideがおすすめです)
↑に近いがNull安全なことに加えて所有権などの概念のおかげでコンパイルが通りさえすればちゃんと動いてくれるという安心感がある。
- リファクタもやりやすそう。(enumにバリアントを追加したとき、パターンマッチの全箇所を修正しないとコンパイルが通らなかったりすると思うので)
開発体験が良い
- エラーメッセージがとても丁寧。「ここがこう悪いで〜」とか「ここをこう直すとええで〜」みたいなことまでエラーメッセージに書いてくれてあるホスピタリティに感動した。こういったところもRustが生産性が高いと言われる所以なのかもしれない。
コミュニティの初学者をサポートする姿勢がすごい
- RustのOSSプロジェクトへのcontributionについては rust-lang/rustへのcode contributionをはじめからていねいにが詳しいが、Rust製のOSSプロジェクトにはE-mentorというタグがありissueを進めるに当たってメンターが指針を記してくれているらしい。（https://github.com/rust-lang/rust/issues/109099 これとかすごい。）
- いつかRustのOSSプロジェクトにもcontributionしてみたい
他の言語と比べて動くものをつくるまでに必要な学習コストは高いとは思うがRustをちゃんと書けるようになれば生産性高く安全なコードが書けると思うので必ずしも学習コストが高いとは言えないのかもしれない。（他の言語でも安全なコードを書くためには一定の学習や経験が必要だろうし）（※想像で喋っています）

総じて開発体験は良かったのでこれからもゆるゆるとRustの学習は続けていきたい。

余談

テスト実行に https://github.com/nextest-rs/nextest を使ってみたがテスト結果が見やすくて便利だった。

cargo runの結果

cargo nextest runの結果

カラフルで見やすい。

Rust on blog.kyu08.com

『RustによるWebアプリケーション開発 設計からリリース・運用まで』を読んだ

モチベーション

本書の概要

学び

実際にRustでWeb Serverを書いてみた感想（主にGoとの比較）

ポジ

ネガ

まとめ

『コンセプトから理解するRust』を読んだ

前提

学び

まとめ

おまけ

関数型まつり2025に参加した

関数型言語テイスティング: Haskell, Scala, Clojure, Elixirを比べて味わう関数型プログラミングの旨さ - lagénorhynque/カマイルカさん

関数型言語を採用し、維持し、継続する - 松澤 有さん

技術選定の方針

非メインストリーム言語でどうやっていくか

コードレビューの技術

Upkeep

情報収集

コミュニティ還元

採用

続けていく気概

産業機械をElixirで制御する - 菊池 豊さん

課題

Why Elixir

Elixirにないもの

Lean言語は新世代の純粋関数型言語になれるか？ - 井上亜星さん

What I have learned from 15 years of functional programming - Scott Wlaschinさん

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股 健太郎さん

概要

F#の特徴

言語設計の意図

マイクロサービス内で動くAPIをF#で書いている - ayato-pさん

スポンサーブース

ノベルティ

まとめ

つけ麺情報

cargoプロジェクトで依存関係を継続的に管理する

tl;dr

cargo-macheteで不要な依存関係を検出する

why

what

how(ローカル)

how(CI)

cargo-denyで依存ライブラリに許容しないライセンスが含まれていないか検証する

why

what

how(ローカル)

how(CI)

cargo-aboutでリポジトリのライセンス表記が最新か検証する

why

what

how(ローカル)

how(CI)

おわりに

GitHub Sponsorsの寄付先にratatuiを追加した

というわけで

まとめ

Makefileに定義されたtargetをfzfで選択して実行するCLIツールをRustでつくった

(2024/12/14追記) 内容を更新した紹介記事をZennに投稿しました。

fzf-makeがやっていること

実装

動機

Rustを触ってみて感じたこと

余談

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだ

関数型言語を採用し、維持し、継続する - 松澤有さん

産業機械をElixirで制御する - 菊池豊さん

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股健太郎さん

`cargo-machete`で不要な依存関係を検出する

`cargo-deny`で依存ライブラリに許容しないライセンスが含まれていないか検証する

`cargo-about`でリポジトリのライセンス表記が最新か検証する