golang

はじめに クラウド環境でのデータベース管理において、セキュリティは日々進化する脅威への対応が求められる重要課題です。特に、以下の課題が顕在化しています： 従来の認証情報（パスワード）の漏洩リスク 認証情報のローテーション管理の煩雑さ アプリケーション展開時の認証情報受け渡しの安全性確保 これらの課題に対し、IAM認証を活用することで、より強固でかつ運用負荷の少ないセキュリティ体制を実現できます。IAM認証のメリットは以下の通りです： 一時的な認証トークンの利用による漏洩リスクの低減 クラウドプロバイダーの統合認証基盤との連携による管理の一元化 きめ細かなアクセス制御とアクセスログの監査対応 本ガイドでは、Cloud FunctionsからCloudSQL(PostgreSQL)へIAM認証で接続する実践的な手順を解説します。この設定により、セキュアかつスケーラブルなデータベースアクセス環境を構築できます。 Cloud Function から CloudSQL(PostgreSQL) へ IAM 認証で接続するために必要な手順 Cloud Function 用 Service Account に必要な権限を付与 PGUSER の作成（IAM認証用） データベースへの権限付与 Cloud Function の実装 Service Account での Cloud Function のデプロイ 具体的な設定手順 1. Cloud Function 用 Service Account に必要な権限を付与 以下の権限が必要: Cloud SQL インスタンス ユーザー Cloud SQL クライアント 今回はコンソールから設定したが、以下のコマンドで設定も可能: gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.instanceUser" gcloud projects add-iam-policy-binding example-project \ --member="serviceAccount:example-function@example-project.iam.gserviceaccount.com" \ --role="roles/cloudsql.client" 2. PGUSER の作成 IAM認証用のユーザーを作成する。...

先日バズってた Go のプロジェクトディレクトリの正式見解というか本家の推奨記事. 気になってたので、読んでみた 以下翻訳結果 ファイルやフォルダのレイアウトに関して、Go を初めて使う開発者によくある質問は「Go プロジェクトをどのように整理すればいいのか」というものです。このドキュメントの目的は、この質問に答えるためのガイドラインを提供することです。このドキュメントを最大限に活用するために、チュートリアルを読み、モジュールソースを管理することで、Goモジュールの基本に精通していることを確認してください。 Go プロジェクトには、パッケージ、コマンドライン・プログラム、またはその 2 つの組み合わせがあります。このガイドはプロジェクトの種類別に構成されています。 基本パッケージ 基本的なGoパッケージは、すべてのコードがプロジェクトのルートディレクトリにあります。プロジェクトは1つのモジュールで構成され、1つのパッケージで構成されます。パッケージ名はモジュール名の最後のパスコンポーネントと一致します。単一のGoファイルを必要とする非常に単純なパッケージの場合、プロジェクトの構造は次のようになります： project-root-directory/ go.mod modname.go modname_test.go [この文書中、ファイル名/パッケージ名は完全に任意です]。 このディレクトリが github.com/someuser/modname のGitHubリポジトリにアップロードされていると仮定すると、 go.mod ファイルのモジュール行には、 module github.com/someuser/modname と書かれているはずです。 modname.go のコードでパッケージを宣言します： package modname // ... パッケージのコードはここ ユーザーは、Goのコードでこのパッケージをインポートすることで、このパッケージに依存することができます： import "github.com/someuser/modname" Goパッケージは複数のファイルに分割することができます： project-root-directory/ go.mod modname.go modname_test.go auth.go auth_test.go hash.go hash_test.go ディレクトリ内のファイルはすべてmodnameパッケージを宣言している。 基本コマンド 基本的な実行可能プログラム（またはコマンドラインツール）は、その複雑さとコードサイズに応じて構成されます。最も単純なプログラムは、 func main が定義された1つのGoファイルで構成されます。より大きなプログラムでは、コードが複数のファイルに分割され、すべて main パッケージを宣言します： project-root-directory/ go.mod auth.go auth_test.go client.go main.go ここで main.go ファイルには func main が含まれているが、これは単なる慣例である。main ファイルは、modname.go（modnameの適切な値に対して）とか、他の名前にすることもできる。 このディレクトリが github.com/someuser/modname のGitHubリポジトリにアップロードされていると仮定すると、 go....

slices.Contains を使用しようとして、コンパイルエラーになったので、少し中身を追ってみた 以下が、実際の実装部分 slices.go func Contains[S ~[]E, E comparable](s S, v E) bool { return Index(s, v) >= 0 } Genericsを使用していて、E は comparable で S はその E の Sliceかー。 では、S ~[]E の ~ とはなんだろうか？ 以下 ChatGPT さんの回答 S ~[]E の表記は、Goの新しいジェネリクス機能において、型Sが型Eのスライスであるという制約を示します。この制約は、ジェネリクス関数やジェネリクス型を定義する際に使用されます。 ~ 演算子は、“型の等価性"を示すために使用されます。具体的には、S が []E という具体的な型であるか、それに等価な型（例えば、型エイリアスなど）である必要があります。 例えば、以下のような型があるとします： type MyInt int type MySlice []MyInt この場合、Contains[MySlice, MyInt] のように関数を呼び出すことができます。なぜなら、MySlice は []MyInt に等価であり、MyInt は int に等価だからです。 この ~ 演算子と型制約は、Goのジェネリクスが提供する強力な型安全性を維持する一方で、柔軟性も提供します。それによって、コンパイル時に型の不一致や他の型関連のエラーを防ぐことができます。 ~ は それに等価な型という制約 comparable な 型の Slice のようなものは許す みたいな感じか...

手っ取り早くリポジトリの WorkFlow つかって Go の リリースを実装する為の設定をメモしておく v0.0.1 みたいな形式のタグを打てばリリースされる こんな感じのヤツ 1. goreleaser init で .goreleaser.yaml を生成する デフォルトでこんな感じで生成される # This is an example .goreleaser.yml file with some sensible defaults. # Make sure to check the documentation at https://goreleaser.com before: hooks: # You may remove this if you don't use go modules. - go mod tidy # # you may remove this if you don't need go generate - go generate ./... builds: - env: - CGO_ENABLED=0 goos: - linux - windows - darwin archives: - format: tar....

最終的にはこれ func IsEmpty(name string) (bool, error) { f, err := os.Open(name) if err != nil { return false, err } defer f.Close() _, err = f.Readdirnames(1) // Or f.Readdir(1) if err == io.EOF { return true, nil } return false, err // Either not empty or error, suits both cases } つまり システムにはディレクトリが空かどうかの情報は無いからディレクトリの子があるかどうかで判断するしか無い File.Readdirnames() が最速 以下日本語要約 ディレクトリが空であるか否かは、その名前、作成時間、またはそのサイズ（ファイルの場合）のようなファイルシステムレベルのプロパティとして保存されていません。 つまり、os.FileInfoからこの情報を直接取得することはできません。最も簡単な方法は、ディレクトリの子（内容）をクエリすることです。 ioutil.ReadDir()はあまり良い選択ではありません。なぜなら、これはまず指定されたディレクトリのすべての内容を読み取り、それらを名前でソートし、その後スライスを返すからです。最も速い方法はDave Cが言及したように、File.Readdir()または（好ましくは）File.Readdirnames()を使用してディレクトリの子をクエリすることです。 File.Readdir()とFile.Readdirnames()の両方は、返される値の数を制限するために使用されるパラメータを取ります。1つの子をクエリするだけで十分です。Readdirnames()は名前のみを返すので、FileInfo構造体を取得（および構築）するためのさらなる呼び出しが必要ないため、速度が速くなります。 ディレクトリが空の場合、io.EOFがエラーとして返され（空のスライスやnilのスライスではない）ため、返された名前のスライスは必要ありません。 以下抜粋 Whether a directory is empty or not is not stored in the file-system level as properties like its name, creation time or its size (in case of files)....