[Golang]`errors.Is()` `errors.As()` 完全ガイド〜使い方と違いをしっかり調査しました〜

はじめに errors.As()を雰囲気で使っていたらハマったので、errors.Is()も含めて、しっかりと調査してドキュメントとコードを読んだ上でまとめてみました。 ハマったところ、ハマりそうなところを重点的にまとめてみたので、お役に立てれば幸いです。 何をするメソッドなのか 簡単に errorを比較してboolを返してくれます。 使いみちとしては、アプリケーションのエラーを外部のエラー(例:gRPCのエラー)に変換したり、ライブラリで使用されているエラーをハンドリングして、アプリケーションのエラーに変換したりするときがあると思います。 errors.Is() 比較対象が保持している値と比較します。 値が同じならtrueを返します。 値が異なるならfalseを返します。 interfaceなど比較できない者同士だと必ずfalseになります。 errors.As() 比較対象を型レベルで比較します。 型が同じならtrueを返します。 型が異なるならfalseを返します。 値は違ってもtrueを返します。 引数target(第2引数)には、nilではないポインタ型を渡しましょう。 詳しく errors.Is()のGoDocとコードを読みました Is reports whether any error in err’s chain matches target. The chain consists of err itself followed by the sequence of errors obtained by repeatedly calling Unwrap.

[Dockerfile]RUN, CMD, ENTRYPOINT, Shell, Exec形式の違いと使いみちをまとめました

RUN イメージをビルドするときに使います。 ビルドされる環境(Google Cloud Build とか)で行いたい処理を記述しましょう。 例えば、アプリケーションをビルドするために必要なパッケージを取得する、アプリケーションをビルドするとかです。 1 2 3 4 5 6 RUN apk update && apk add gcc g++WORKDIR/go/src/appCOPY . .RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o /go/bin/app -ldflags="-s -w" . CMD, ENTRYPOINT コンテナが起動するときに実行されます。 コンテナが動作する環境(K8s, Cloud Run とか)で行いたい処理を記述しましょう。

[超便利]Go ORMライブラリのSQL Boilerを使った感想

はじめに Go ORM ライブラリ SQL Boilerを見つけて、コードを自動生成してくれたり、gorm xorm よりもパフォーマンスが優れているということを聞いたので使ってみました。 具体的な使い方は、サンプルアプリケーションを作ったので、そのソースコードを見てください。 https://github.com/kskumgk63/sqlboiler-example もしくは、こちらのブログが非常に参考になりましたので参照ください。 https://note.crohaco.net/2020/golang-sqlboiler/ SQL Boiler の説明 SQL Boiler とは、データベーススキーマに合わせたGo ORMを生成してくれるライブラリです。 「データベーススキーマに合わせた」とある通り「データベース優先」のORMなので、まず初めにデータベーススキーマを作成して、それからsqlboilerコマンドでコードを生成します。 コード優先であるgorm xorm とは、大きく違いますね。 パフォーマンスは、他の有名ORMライブラリに比べて圧倒的に良いです。 https://github.com/volatiletech/sqlboiler#benchmarks SQL Boiler のコンセプト we set out with these goals: Work with existing databases: Don’t be the tool to define the schema, that’s better left to other tools.

[実装不要で超手軽]gRPCサーバーの動作確認ができるGUI BloomRPC の紹介

はじめに 本記事は、gRPCのサーバーを実装していた筆者が動作確認めんどくさいなー、gRPCクライアント実装しなくてもサーバーの動作確認ができるツール無いかなーと探していたら見つけたGUI BloomRPC の紹介です。 BloomRPC の説明 https://github.com/uw-labs/bloomrpc 先述通り、gRPCのクライアントの実装をしなくてもgRPCサーバーの動作確認が行える便利なGUIです。APIのテストで有名なPostmanやFacebookが開発したWeb API規格GraphQLの動作確認に使われるGraphQL Playground に影響を受けているようです。 特徴 READMEを翻訳しただけです。 ネイティブgRPC呼び出し UnaryCallとServer Side Streamingのサポート クライアント側と双方向ストリーミング 自動入力認識 マルチタブの操作 メタデータのサポート 永続的なワークスペース キャンセルのリクエスト インストール方法 mac だと homebrew でインストールできます。 brew cask install bloomrpc また homebrew が無い環境だと、クローンしてyarn installしてnpm runすれば起動します。 詳しくは、こちらを参照してください。 使い方 gRPCサーバーを起動して希望のポート番号で待ち受ける。 BloomRPCを起動する。 GUIの画面左上にある+ボタンから.

Goの変数名はなぜ短いのか

Goの変数名は短い方が好まれます。例えば、memberだったらm、userだったらuにするといった具合です。僕は、「エディタが保管してくれるし、変数名は長い方が具体的でわかりやすいからいいのでは?」とずっと疑問に思っていました。 公式も変数名を短くしろとは書いているけど、その理由まではわからず放置していましたが、「Goに入ればGoに従え」という言葉もありますので、今回ついに短い変数名が推奨される理由を調査してみました。 公式:CodeReviewCommentsというGoのコードをレビューするポイントをまとめたWikiのことです。 下記は、Wikiに変数名について記載されている部分の翻訳と原文です。 Goの変数名は長いものより短いものにするべきです。特にスコープが限定されたローカル変数に当てはまります。lineCountよりもcが、i は sliceIndex よりも優先されます。 基本的なルール: 名前が使用される宣言から離れているほど、その名前はより説明的でなければなりません。メソッドのレシーバの場合は、1文字か2文字で十分です。ループインデックスやリーダのような一般的な変数は、1文字i, rで構いません。より珍しいものやグローバル変数は、より説明的な名前を必要とします。 Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex. The basic rule: the further from its declaration that a name is used, the more descriptive the name must be.