「user そーだい」で検索することN回目
— k1LoW (@k1LoW) 2024年4月15日
よく参照するならまとめておけばいいじゃない。
ラインナップからフェーズ的なものについては察してください。
ガッチガチに「こうあるべき」というような話というよりも、モデリングやテーブル設計においての固定観念*1を崩すためのキッカケに使っていることが多い気がします。
ちなみに私は、十数年、散々失敗した挙句にこのような有益なURLを有益だと理解して参照したりしているわけで、最初から（もしくは短期間に）ここに行き着ける人ってすごいなと尊敬しています。
そーだいさんから有益情報を教えてもらったので並べておきます。
@k1LoW ここ最近のソフトウェアデザインの僕の連載見てほしいです。めちゃめちゃ頑張ってるので。
— そーだい@初代ALF (@soudai1025) 2024年4月16日
あとこれもオススメです。https://t.co/RzuDiuo8p4
*1:「（Webフレームワークの）モデルとデータベーステーブルを1:1にして終わり」とか
先日、機会をいただきましてCI/CD Test Night #7でAPIテスティングツール*1を開発している中で考えていることをお話しさせていただきました。
詳細はスライドをご覧ください。
私はAPIテストの一番の課題はこれだと思っています。
APIテストは、「APIに対してリクエストを投げてそのままテストする」というわかりやすさがあります。
また、テストあたりにおけるカバレッジの広さというメリットもあります。
なので、できればデメリットであるコストの大きさをなんとかしたいわけです。
この課題の解決には2つの方法があります。
先に、範囲を広げる方法について考えると
というような方向性、言ってみれば一石N鳥にすることによって効果を大きくするというものになります。効果が大きければコストが気にならなくなるだろうという寸法です。
では、コストを小さくするにはどのようにするかというと「テスト自体を書きやすくする（実装コストを小さくする）」などがあるのですが、結局は実行コストの大きさ、特に実行時間の長さが際立ってきてこれを解決しないといけなくなります。
まず最初に解決する手段として挙げられるのは「テストの並列実行」だと思います。
しかし、並列実行にも限界があります。
その次に取れる手段は何でしょう？
もう全てを愚直に実行するのはあきらめて、効率よく実行していく必要がありそうです。
「効率よく」というのは、例えば、
などです。
ちなみに、このようなアプローチは私が考えたわけではありません。
私は、Launchable社の方たちの発表やエントリを見て知りました。
そして、APIテストという実行時間の長いテストに向き合うようになって、このアプローチの効果に期待しはじめるようになりました。
そして、タイトル回収です。
先述した「インテリジェントなテスト実行」を実現するためにはまず何が必要か？というと、「テストケースの一意な識別」です。
それぞれのテストケースを一意に識別できなければ「どのテストが失敗したのか」がわかりません。 識別できなければ特定のテストだけを実行することもできないし、指定の順番に実行するということもできません。
テストケースに識別子=IDがあれば、特定テストの実行や、任意の順番でのテスト実行も可能になります。
インテリジェントなテストを実現するための第一歩が「ID」だと考えます。
APIテスティングツールに必要なのは（まず）テストケースごとのIDなのではないでしょうか*2。
IDによる識別や、IDを使った柔軟なテストの実行ができることで、コストを抑えたインテリジェントなテスト実行への道が開けます。
ちなみに、runnにおけるIDの利用については次のエントリをご覧ください。
実は、きっかけはこのXのポストです。
よさそう、その場合にテスト時間が長くなってしまう問題についてなにかできそうな工夫とかあったら今度教えてくださいｗ
— zoncoen (@zoncoen) 2023年11月30日
ここからテスト実行時間について意識して考えるようになり、今に至っています。
今回の発表やこのエントリは @zoncoen さんのポストへの私なりの回答となります。
考えるきっかけをくれた @zoncoen さん、発表する機会をくれた @ponkio_o さんありがとうございました。
今年も参加してきました。
聴講した発表へのフィードバックも終わり、このエントリで私のPHPerKaigi 2024はフィニッシュです。
最近恒例の廊下での会議ですが、テストランナーのシンタックスの改善の方向性についてどうしてもしめじさん（ @smeghead さん）から直接フィードバックをもらいたく、3日間「いつか会えるだろう」とフラフラしていました。 気にかけていただいた皆さんありがとうございました。無事邂逅できました！
runnのランブックの一級言語がYAML（？）なのでYAMLシンタックスをうまく使ってかつニーズを満たす構文が思いつけばいいのですが、もう一歩アイデアが降ってこない。。。というところまででした。しめじさんにも言われたのですが「一度作ってしまうとなかなか変えられない」ものなのでどうにか降りてきてほしいっ！！！
あとはカンファレンス駆動で、runnで使っているOpenAPIパーサパッケージの差し替えとか、変数展開に使っているデリミタのエスケープができるようにするなどして、とうとうv0.100.0になりました。
v1...
あーあ、minorが3桁いっちゃったよ...https://t.co/mMW7ypC077
— k1LoW (@k1LoW) 2024年3月9日
Day2のお昼は話したい人が目の前にいたので声かけた結果なかなかなさそうなメンツで行くことに。
#phperkaigi ランチ、ちょっと歩いて幸運豚人（Tsui-teru ! Porkman）まで行ってきたけどカツカレーおいしかった。 w/ @k1LoW @catatsuy @ttabtt3
— 山岡広幸｜合同会社テンマド (@hiro_y) 2024年3月9日
CSRF対策としてのOriginヘッダの話で、 @hiro_y さんの発表と全く同じことを（おそらく発表を聞いていない上で）言っている @catatsuy さんがいて、「あーこれは古来からのCSRFトークンではない対策もアリだなあ」と思ったのでした。
「そーだいさんのキャッシュ話面白かった」というところからキャッシュ全般の話になり「最近のJSフレームワークやGraphQLクライアントは勝手に（？）キャッシュをしてくるのでムズカシイ（かなり意訳）」と、なるほどと聞いていました。
お昼は豚肉を食べながらCSRFとキャッシュの話をしていました
— k1LoW (@k1LoW) 2024年3月9日
「勝手にキャッシュすんな」の話が面白かったです #phperkaigi
プロキシキャッシュの話ももう少し聞けば良かった...！
そんな話をしながら「普通に衣上下に縦に食べられない厚さのカツ」を体験できました。おいしかった。@ttabtt3 さんチョイスありがとうございました。
今回出したプロポーザルはCLIツールのデザインについての話でした。発表内容は資料や動画を見ていただくとして、多くの皆さんに質問や反応をしてもらって良かったです。
CLIツール、小さく作れるし、しっかり考えて作ると勉強になるし、Webアプリケーション開発にも通じるものが多いのでおすすめです。
時間制限をして思いつく限りを書いてみました
無事きんじょうさん（ @o0h_ さん）を拉致（？）して懇親会に行けたのは良かったです。 私はきんじょうさんを知識蓄積型、広範囲学習型とみているのですが、いつも発表の内容が明快でかつ多彩で気になっていた方でした。 今回も「多分何聞いても回答が返ってきそう」と思って、きんじょうさんに色々質問していました。 ただ、すでに私にお酒が入っていたので、質問しきれたかというとそうでもないので、次回はカンペを用意していこうと思います。
@kaz_29 + @keita__Max のお二人の話も面白かったです。どこかのカンファレンスでネタになるかもしれないのであまり話せませんが、良いシナジーだなあと思いました。 あと、これも私からは詳細は書けませんが、みなさん @keita__Max さん見かけたら話しかけてみると良いと思います。めちゃくちゃすごかったし面白かった！
すごいといえば @katzchum さんと @tyamahori さんの「あるあるですが〜」から話していた全然あるあるではない「フィーチャーフラグ Lv100（命名 きんじょうさん）」は驚愕だった。たぶんこれもいつかカンファレンスで出てくると予想しています。
@77web さんと @KentarouTakeda さんに凸って聞いた「SymfonyとLaravel」話もめちゃくちゃ興味深かったです。一部 @77web さんがブログエントリに書かれていたので是非。書けない話もありますよね。
https://77web.hatenablog.com/entry/2024/03/11/200747
そういえば、そーだいさんの近くにいるといつも良い話を聞けるので良いです。ただ、いつもそうなので、良い話をするそーだいさん「以外」がいるのか気になっています。
あと、P山さんには「謎の世界的なオヤマ」推しをされてとても困りました。
ただ、印象に残したのは私のようです。
これまたk1LoWさんとの交流によってもたらされたやつですが、「P山さんの凄さ」について聴いたのがすっっっごい心に残ってます。
こちらの凄い人を体験したい方はこちらへ。
会期中のタイムラインでも、廊下でも話題になった話なのですが、どのカンファレンスもいつも楽しいのですが、PHPerKaigiの懐の深さと楽しさは本当に素晴らしいと思います。
「PHPer」と冠していますが、もっとひろくエンジニアの人々に開かれているので、PHPerだったときからPHPerではない？ように感じる今でもとても居心地が良いです。
また来年も1年の集大成をぶつけられれば良いなあと思っています。
スタッフの皆さん、PHPerKaigiコミュニティのみなさんありがとうございました！
Goにおいてcontextはさまざまな値を伝搬させるために使用します。その1つがキャンセル信号です。
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
contextを通じてキャンセル信号を送ることによって、そのcontextが伝播した関係するある種のcontextグループでキャンセルに対応した処理を行うことができます。
このcontextのキャンセルに対応した処理を、このエントリでは「クリーンアップ処理」と呼ぶことにします。
あるミドルウェア（プロキシサーバでもデータベースサーバでもよい）があったとして、そのミドルウェアにはメインの機能以外に「ログやメトリクスを定期的にまとめて外部サーバに転送する機能（ログ転送機能）」があるとします。
ミドルウェアのプロセスを停止する際に、ログ転送機能が転送中であれば転送完了までプロセスの停止を待って欲しいですし、次の起動時のためにどこまで転送完了したかの記録するまでプロセスの停止を待って欲しいと考えます。
このような、いわゆる「Graceful shutdown」の実現に必要な後始末処理は、本エントリにおける「クリーンアップ処理」の1つの具体例になります。
キャンセル処理の伝搬は大抵 context.WithCancel() で作成した cancel() を使って行います。
cancel() を実行することでcontextや、そのcontextから派生した子contextにキャンセル信号が伝搬され、その信号は context.Done() から補足できます（実体は <-chan struct{}）。
contextを引数で受け取っている各処理は、context.Done() から信号を受け取ったときにクリーンアップ処理を行うようにする（処理を書く）のですが、このクリーンアップ処理の実行の完遂は context.WithCancel() と cancel() で実現しているキャンセル信号の伝搬の仕組みでは保証されません。
次のGo Playgroundに簡単な例を置きました。クリーンアップ処理が完了する前に main() が終了してしまい、クリーンアップ処理が完了していないことがわかると思います。
https://go.dev/play/p/F-4qnF5L9bf
少し複雑なGoのプログラムを書くと context はさまざまな箇所に渡されます。「（終了処理実現のために）関数の第一引数にcontextを渡す」という慣習もありますし、その深さ（どれくらい関数をまたいでcontextが渡されてきているか）は意図せず深くなっていきます。
また、goroutineの存在により並行処理もよく活用します。開始した並行処理は終了処理を書く必要があり、必要であればクリーンアップ処理を書く必要があります。そもそも context を渡しているのはgoroutineによる並行処理の終了処理のためでもあります。
終了処理のトリガーにはcontextのキャンセルを検知できる context.Done() を使います。
では、クリーンアップ処理はどう実装したら良いでしょう？クリーンアップ処理の完了を待つための仕組みが必要です。
ところで、testing.T.Cleanup() はテストのクリーンアップ処理を保証するための仕組みです。t.Cleanupでクリーンアップ処理を登録しておくことによって、テスト終了時にそれらのクリーンアップ処理を実行してくれます。
私はcontextの文脈でもこの testing.T.Cleanup() のような機能が欲しいと考えました。
上記のようなモチベーションで作成したパッケージが donegroup です。
donegroupはcontextのキャンセル時にtesting.T.Cleanupのようにクリーンアップ処理を実行できる仕組みを提供するパッケージです。
まず context.WithCancel() の代わりに donegroup.WithCancel() を使ってcontextとcancel()の対を作成します。
そして、cancel() 実行後にクリーンアップ処理を待つため、donegroup.Wait() を実行します。
これだけで準備は完了です。
具体的には
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
を
ctx, cancel := donegroup.WithCancel(context.Background()) defer func() { cancel() if err := donegroup.Wait(ctx); err != nil { log.Fatal(err) } }()
に書き換えるだけです。
クリーンアップ処理の登録も簡単です。任意の場所で donegroup.Cleanup() を使ってクリーンアップ処理を登録するだけです。
err := donegroup.Cleanup(ctx, func(_ context.Context) error { // 何かしらのクリーンアップ処理 fmt.Println("cleanup") return nil })
これだけで、contextのキャンセル時にクリーンアップ処理の実行をしてくれます。クリーンアップ処理はいくつでも登録できます。testing.T.Cleanup() との違いはクリーアップ処理の実行順序の保証がないということだけです。
donegroupは、次のように「実行に時間がかかる処理の実行を待つ（保証する）」こともできます。
この場合は donegroup.Awaiter() を使います。completed() が実行されるまで donegroup.Wait() は待ってくれます。
ctx, cancel := donegroup.WithCancel(context.Background()) go func() { completed, err := donegroup.Awaiter(ctx) if err != nil { log.Fatal(err) return } // 実行に時間がかかる処理 time.Sleep(100 * time.Second) fmt.Println("do something") completed() }() // メインの処理 fmt.Println("main") time.Sleep(10 * time.Millisecond) cancel() if err := donegroup.Wait(ctx); err != nil { log.Fatal(err) } fmt.Println("finish") // Output: // main // do something // finish
「この関数ブロックの実行を保証したい」というような場合は defer donegroup.Awaitable(ctx)() が使いやすいです。
go func() { defer donegroup.Awaiter(ctx)() // この関数ブロックの実行を保証する。 if err != nil { log.Fatal(err) return } // 実行に時間がかかる処理 time.Sleep(100 * time.Second) fmt.Println("do something") }()
donegroup.Wait() の代わりに donegroup.WaitWithTimeout() を使うことでクリーンアップ処理待ちにタイムアウトを設定することができます。
この場合、donegroup.Cleanup() や donegroup.Awaiter() donegroup.Awaitable() にタイムアウトが伝播します。
具体的には donegroup.Cleanup() に渡すクリーンアップ処理 func(ctx context.Context) error の ctx にキャンセル信号が届くので ctx.Done() を使って適切にキャンセル処理を書きましょう。
donegroupのメリットは、contextさえ渡しておけば関数シグネチャなどを変えずにいつでもクリーンアップ処理を追加実装できる点です。
また、クリーンアップ処理のエラーもまとめて受け取れます。
実装の深い場所でクリーンアップ処理が必要な並行処理を実装する場合も安心です。
散らばっている並行処理の後始末に是非使ってみてください。
追記
with.workdir:はwith.work-dir:に変更になっています
https://t.co/RsAqx9wVhT の v1 リリース作業をしている
— k1LoW (@k1LoW) 2024年1月24日
octocov-action v1 をリリースしました。octocov-actionはoctocovをGitHub Actionsで使う際に使用するActionです。
今回、何が変わったかを紹介します。
Actionの実装方式をDocker container actionからComposite actionに変更しました。
これにおける効果は大きく2つあります。
1つ目は octocov のバージョンを柔軟に指定できるようになったことです。
というのもDocker container actionで ghcr.io/k1low/octocov を使っている限りはActionの外部からoctocovのバージョンを指定することができませんでした。
バージョン指定ができないと何が困るかというと、最新のoctocovでバグや意図しない動作が発生した際に1つ前のバージョンに固定するというワークアラウンドがとれないことです。
そのため、従来は octocov のバージョンと octocov-action のバージョンを同期させることで、バージョン指定ができるようにしていました。
今回 Composite actionにして任意のoctocovを指定できるようになりました（ with.version: セクション ）。
2つ目の効果です。
Docker container actionの場合Docker imageのpullとコンテナの起動が必要ですが、それが必要なくなりました。
そのかわり、途中でoctocovのリリースバイナリを取得する必要があるのですがそれでも体感で速いです。
今後リリースバイナリのキャッシュなどをするようにするとより速くすることが期待できます。
with.work-dir: セクションを指定することでoctocovの実行ディレクトリを指定できるようになりました。モノレポな環境で便利だと思います。
このような新機能が追加しやすくなったのもComposite actionに変えた効果ともいえます。
octocovがv0.xである限りはDocker container action版のoctocov-actionもメンテナンスしていく予定です。従来通り uses: k1LoW/octocov-action@v0 で使用できます。
octocov-action v1 をリリースしました。 uses: k1LoW/octocov-action@v1 で何も設定を変えずにすぐに使用できますので是非ご利用ください。
今後もoctocovをどうぞよろしくお願いします*1。
*1:そういえば、もし活用している企業様がいらっしゃいましたらこそっとでいいので教えてください。単純に喜びます
2023年は私にとっていろいろ思いを巡らせる年となりました。将来とか家族とか人生とか。内容は割愛しますが、HIPHOPクラシックを1つだけ貼っておきます。
2023年の抱負は「書く」でした。はじめてZenn Bookを書いたりなどしましたが、他にはそこまで書いていない気がします。ムズカシイ。
あ、でも2023年後半に久しぶりに「描く」ことはできてとても嬉しかったです。
2023年も少なくなったかなと思います。
一方で、年初の宣言通り runn の開発を継続していました。 #runn開発者会議 もオンラインオフライン問わず何回も開催することができましたし、APIテストツールとしてイベントに呼ばれたり（runn開発者以外の）企業で使ってもらったりと、広く評価してもらえるようになりました。 一緒に開発してくれている@katzchumさんありがとうございます。
また、2manymws orgもプロダクションで使うパッケージとして鍛えてもらいました。 @pyama86さんありがとうございます。
今年の趣味OSSはどうなるんだろう？
でもrunnをもう少し良くしたい。v1にできる勇気が出ると良いなあ。
個人的には頑張ったと思います。
私は体系的に学んだことを軸に発表するというのが苦手です。その分、多少王道から外れていても、自分で考え、作り、感じたことを集めてそのエッセンスを共有できると良いなと思っています。 2023年はどれも「自分こそが発表するべき」と思える特徴というかクセのある内容になったと思っています。
今年はなんだろう...
漠然と「新しい気持ちになりたい」というのはあるんですけど、「何を」「どうやって」というのは思いついていないし、「"気持ち"ってなんだよ。それってあなたの感想ですよね™️」という気持ちです。
とりあえずブラックフライデーに購入して深圳から届いたものの今の今まで手をつけていないブツが机の後ろに鎮座したままなので、それにちゃんと手をつけたいです。新しい気持ちにはなりそう。
今年もよろしくお願いします。
このエントリは GMOペパボエンジニア Advent Calendar 2023 および、 Go Advent Calendar 2023 シリーズ3 の19 日目の記事です。
以下のエントリでも少し触れられていますが、現在プロキシサーバをGoで書くプロジェクトがあります。
主な実装をしているのは @pyama86 さんで、それはもうブルドーザーのように実装が進んでいるわけですが*1、私も少しだけですが書いています。
必要そうな機能をGoの薄いHTTPミドルウェアハンドラとしてOSSとしていくつか切り出していました。
そして、本体の実装が進むにつれて足りない機能を Pull Request ベースでもらったりしていたのですが、関連OSSを作る必要が発生したりなど個人リポジトリだとまとまらないため、それらをまとめるためだけにGitHub Org を新設しました。
既に私のリポジトリからのトランスファーは済んでおり、今後はこのOrg上で開発していく予定です。
どうぞよろしくお願いします。
ごく簡単にですが、置いてあるリポジトリについて紹介したいと思います。
レートリミットを実現するHTTPミドルウェアハンドラです。
Goにおけるレートリミット実装としては go-chi/httprate が有名だと思います。rlもgo-chi/httprateを参考に実装しています。
rlの特徴は interface を満たす実装をつくって注入するだけで
というものです。
「あるホストへのアクセスだけレートリミットを緩和したい」だとか「あるIPからのアクセスだけレートリミットをかけたい」というユースケースに対応するためのものです。
リバースプロキシサーバです。HTTPミドルウェアハンドラではないです。
rpの特徴は interface を満たす実装をつくって注入するだけで
というものです。
マルチテナントなサービスの前段などで必要になる機能を想定しています。
HTTPキャッシュミドルウェアハンドラです。
rpの特徴は interface を満たす実装をつくって注入するだけで
というものです。また、
ということも可能です。
rcのためのユーティリティパッケージです。
rc.Cacher の interface を満たしたディスクキャッシュ機能の提供などをしています。
HTTPミドルウェアハンドラを管理するHTTPミドルウェアハンドラです。
mmの特徴は interface を満たす実装をつくって注入するだけで
というものです。
動的に切り替える仕組みがないHTTPミドルウェアハンドラに動的切り替え機能を付与したいときに使うイメージです。
ちなみに、すごく短いコードなので全部貼り付けておきます。
package mm import ( "net/http" ) // Builder is a middleware builder. type Builder interface { //nostyle:ifacenames Middleware(req *http.Request) (func(next http.Handler) http.Handler, bool) } type mMw struct { builders []Builder } func newMMw(builders []Builder) *mMw { return &mMw{builders: builders} } func (mm *mMw) Handler(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { for _, b := range mm.builders { mw, ok := b.Middleware(r) if !ok { continue } next = mw(next) } next.ServeHTTP(w, r) }) } // New returns a new middleware-middleware. func New(builders ...Builder) func(next http.Handler) http.Handler { mm := newMMw(builders) return mm.Handler }
以上、と思ったら、先ほど rlutils というパッケージが誕生していました。
2manymws*2、どうぞよろしくお願いします。
*1:わかる人にはわかると思います。是非間近で見てほしいので、こちらから応募してください。https://recruit.pepabo.com/
