YAPC::Kyoto 2023 めっちゃ最高でした。オフラインカンファレンスはやっぱり参加すると楽しいー！
YAPC::Kyoto 2023 Reject Con
YAPC::Kyoto 2023 は個人スポンサーとして参加しました。ついでに最近やっていることを話したいなと思い応募したのですが落選してしまいました。しかし、スタッフの素敵な心遣いで前日祭の Reject Con で話せることになりました。以下は当日私が話したことの要約です。
続きを読む中国企業からスカウト PR が届いた
あ…ありのまま今日、起こった事を話すぜ！
「おれは プルリクエストが送られてきたと思ったら いつのまにかスカウトメッセージを読んでいた」な… 何を言っているのか わからねーと思うが、おれも 何をされたのか わからなかった…頭がどうにかなりそうだった… Linkdinだとかスカウトメールだとかそんなチャチなもんじゃあ 断じてねえ もっと恐ろしいものの片鱗を 味わったぜ…
私の GitHub repository に中国企業からスカウト Pull Request が届いた。
送り主の contribution を見ると 1 日で 700 件以上（8/31 21:43 現在）の contribute に成功してる。
gRPC Application のエラー設計
Web アプリケーションで error code, error message を返したくなる時があるはずです。HTTP JSON API とかでたまに見るのは status code が 200 なのに error が返ってくるものです。gRPC ではどうすれば良いのでしょうか。基本をおさらいしつつ浅く考えてみます。
Status Code
成功すると response と status code OK が返ってきます。
何かしらのエラーが発生すると OK 以外のエラー status code が返ってきます。statuscodes.md にも記載されてますが、これらのコードは必ずしも server から返るわけではなく、client 自身が返す場合もあります。
基本的には gRPC アプリケーションで発生したエラーによって status code を変更するような設計にするかと思います。しかし、時には gRPC server (low level) で発生したエラーとアプリケーションのロジックで発生したエラーを分けたい & client にそのエラーの詳細を伝えたいといった事があるかと思います。そのような時は Richer error model を採用しましょう。
Error Details
Google では開発に使用しているエラーモデルが存在します。このモデルに記述されている details がどんなエラーが発生していたのかを詳しく表現できるようなフィールドになってます。Google では一般的なエラーのニーズ（リトライ情報、不正なパラメータの情報など）をカバーできるように proto が定義されてます。これらのような proto を details のフィールドへ格納することで表現することができます。
gRPC ではこのモデルに沿ってエラーを返せるようになってます。エラー詳細は response に付属される metadata 内に details というキーに対して格納されて返ってきます。
- エラーコード
- status code
- エラーメッセージ (ライブラリの実装に依存するとのこと)
- Go や Nodejs では error として手に入る
- Go (server) -> PHP (client) だと details に string として含まれて手に入る
- 例:
{"metadata":{},"code":5,"details":"sql: no rows in result set"}
- 例:
- エラー詳細: gRPC の response に付属される metadata に
detailsというキーに対して格納されて返ってくる
もちろん Google が定義した proto メッセージではなく、自前で proto を定義するのもありでしょう。
まとめ
- gRPC では
OK以外はエラーとして扱うことを推奨されてる - エラー詳細は response の metadata を使う。details というキーに対して格納していく。
お試し
gRPC の server, client の挙動の確認ができる testing-grpc というものを作りました。このプロジェクトは grpc/grpc-go を使って開発されてますが、他の言語で（例えば PHP）実装された gRPC server, client にも同様の知識を応用できるのではないかと考えてます。
（もし宜しければ github star をお待ちしてます）
xcode をインストールしてない macOS で lldb を使うまで
mac を開発端末にしたいけど xcode をインストールしたくないという場合、xcode を appstore からインストールするのではなく、command line tools のみをインストールする必要がある。
インストールするために xcode-select -- install を実行する。これをやることで mac 上で homebrew が使えるようになったりする。
私の環境には homebrew 経由でインストールした lldb (/usr/local/opt/llvm/bin/lldb) があった。最近 neovim のコードを読むことにハマってるので久しぶりにデバッグするしようとしたら次のエラーメッセージが表示された。
$ lldb -p $(pgrep nvim) (lldb) process attach --pid 35912 error: attach failed: unable to locate debugserver
今まで xcode をインストールした状態でデバッグを行ってたので、このケースに初めて遭遇した。debugserver がないとのこと。検索すると command line tools をインストールしてるなら /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver に存在するという情報を入手した。（確かにあった）
それで今度はこの debugserver を lldb に認識して貰う必要があるが、検索してもなかなかヒットせずかなり困った。
続きを読むプリエンプティブな GCE インスタンスの外部 IP を固定する
最近 iPad Pro を購入したため、これを開発環境のとしても活用できると良いなと思い、GCP でプリエンプティブな GCE インスタンスを作成した。
インスタンスに https://github.com/<username>.keys 経由で取得できる github に登録した自分の公開鍵を設定した。こうすることで秘密鍵を github に使っているものを利用することができる。
これで手元の ~/.ssh/config をこんな感じで修正すればもう使えるものだと思ってた。
Host gce Hostname <external-ip> IdentityFile ~/.ssh/github User codehex ForwardAgent yes
実際には使えていたが、暫くすると external-ip (以降、外部 IP)が突然変わってしまって毎回 config ファイルを修正していた。しかし、これではしんどいのでちゃんと固定される外部 IP を固定することにした。下記は実際にやった手順を示してる。
続きを読む