Goでモンキーパッチするライブラリを作った - Plan 9とGo言語のブログ
Goで単体テストを実装する場合、動的な言語のように「テスト実行中に外部への依存を置き換える」といったことはできません。代わりに、 外部への依存を引数で渡す 外部への依存をインターフェイスで渡す のように、テスト対象をテスト可能な実装に変更しておき、テストの時は外部への依存をモック等に置き換えて実行する場合が多いのではないかと思います。 個人的な体験でいえば、テスト可能な実装に置き換えていく過程で設計が洗練されていく*1ことは度々あるので、面倒を強制されているというよりは設計を整理するための道具といった捉え方をしているのですが、そうは言っても動的な言語に比べると面倒だなと感じるときは少なからずあります。既存の実装がテスト可能になっておらず、変更するコストが高い場合は特にそうですね。 そんなとき、気軽にモンキーパッチできると嬉しいんじゃないかと思って、テストの時だけ関数を置き換えられるようなラ
Goの標準のutf8.RuneStart関数がエレガントすぎる
先日以下の記事を書きました。 ここでUTF-8の最初の文字かどうかの判定を以下の自作した関数で実装していました。 const ( t1 = 0b00000000 tx = 0b10000000 t2 = 0b00000110 t3 = 0b00001110 t4 = 0b00011110 ) func isUTF8LeadByte(tmp byte) bool { if tmp&tx == t1 { return true } tmp >>= 3 if tmp == t4 { return true } tmp >>= 1 if tmp == t3 { return true } tmp >>= 1 if tmp == t2 { return true } return false }
GitHub Actions 上での Go の Docker ビルドを高速化する
どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM
Go製バイナリを配布するためのGitHubワークフロー - Plan 9とGo言語のブログ
前置き 以前、BuildInfoからバージョンを取得する方法を紹介しました。 blog.lufia.org go installで正規の公開されたバージョンをインストールした場合は、以下の出力においてmodの行が示すように、sum.golang.orgでチェックサム等が検証されてバイナリのメタデータに埋め込まれます。 $ go version -m dotsync dotsync: go1.22.2 path github.com/lufia/dotsync mod github.com/lufia/dotsync v0.0.2 h1:JWm92Aw8pSKJ4eHiQZIsE/4rgwk3h5CjEbJ/S30wiOU= build -buildmode=exe build -compiler=gc build -trimpath=true build DefaultGODEBUG=ht
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話
既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく、手動計装を選んだ理由を説明します。 GoアプリケーションへのOpenTelemetry計装手段 Goにおいては、OpenTelemetryの自動計装が公式で用意されていません。公式サイトにAutomaticの章がないことからわかります。おそらく、ランタイムの制約で実行時にアプリケーションの挙動を変えることが難しいのでしょう。 トレースに十分なスパンを含めるために、現状では以下の2つの計装手段があります。既存のGoアプリケーションに導入する手間や影響範囲をイメージいただくために、概要に絞って解説します。 手動計装 eBPFによる自動計装（Work In Progres） 1. 手動計装 まず、OpenTelemetryのSDKをインストールし、セットアップをします。 func main
リトライ処理を追加するとバッチが安定することがあることもそこそこあるので「avast/retry-go」を使ってみる - じゃあ、おうちで学べる
はじめに インフラエンジニアは日々の業務でプログラムを書く機会が多く、その中で処理の実行やHTTPの通信などでリトライ処理を実装する必要があることが少なくありません。リトライ処理を実装する必要は必ずしもなくても、実装することでバッチが安定することがあります。もっと言っておくとリトライ処理を実装することで、一時的なエラーによる処理の失敗を回避し、バッチ処理の安定性が向上する可能性があります。実行基盤によってジョブの再試行の自動化、最大再試行回数を設定するやPod失敗のバックオフポリシーなどとの兼ね合いを考える必要もあると思います。あとはマジでガー不のバグを引き寄せることもあるので注意が必要です。 はじめに シンプルな例 最大リトライ回数の指定 次のリトライまでの待ち時間の設定 特定の例外のみリトライするケース さいごに 今回はGolangには「retry-go」というリトライ処理を簡潔に実装
GitHub - microsoft/go: The Microsoft build of the Go toolset
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. This repository, microsoft/go, contains the infrastructure Microsoft uses to build Go. The submodule named go contains the Go source code. By default, the submodule's remote URL is the official GitHub mirror of Go, golang/go. The canonical Git repository for Go source code is located at
GoでgRPCのAPIテスト環境を構築する - enechain Tech Blog
はじめに JCEXで実践しているAPIテストについて 単体テスト 負荷テスト なぜAPIの単体テストを行っているのか API単体テストで使用するパッケージ 実例によるAPI単体テストの環境構築 前提 ステップ１: テストしたいAPIの定義 ステップ２: テストの作成 ステップ３: APIの実装 ステップ４: DBを使ったテスト ステップ５: ヘルパー関数化 ステップ６: テーブル駆動テストに変える ステップ７: フィクスチャを使ったテスト まとめ おわりに はじめに こんにちは、enechainのGXデスクでエンジニアをしている@ejiです。 GXデスクは、『日本気候取引所 - Japan Climate Exchange』 (以下 JCEX) のサービス開発を担当しており、 私は主にBFFとバックエンドのAPIをGoで開発しています。バックエンドのAPIは gRPC を使用しています。
ぼくのかんがえたさいきょうのGo HTTPサーバー起動方法
これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ？本当に正しく Server.Shutdown 使えている？」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os
UbieにおけるGo言語のエラーハンドリング
背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に本番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました
Building an interactive shell in Golang
Go is great for building command-line applications. We built one: Dolt, the world's first version-controlled SQL database. We wrote our own command line parser for handling all of Dolt's subcommands and arguments, but maybe we shouldn't have. There are lots of great ones out there that if we might have used instead if we were starting the project today: spf13/cobra has great support for code gener
内部エラーと外部エラー、それからGoのerrorがスタックトレースを含まない理由の考察
TL;DR Goのerrorは外部エラーを表現するもので、利用者（ライブラリならアプリケーション開発者、アプリケーションならユーザー）に入力値や環境の不備を伝える目的で存在している 一方で、開発中のソフトウェアが思っていたのと違う挙動を示した場合、その調査にはソフトウェアの特性によって異なるツールを使い分ける必要があり、一筋縄では行かない 両者を分けて考えることで、よりよいエラーハンドリングへの議論が初めて進められると考える 背景 Goのerrorがスタックトレースを含まないことは度々Goの欠点として挙げられます。たしかに、一度作ってどこかにデプロイしたソフトウェアがバグっており、スタックトレースがないせいでその原因調査に手間取ったことは筆者も一度のみならず体験しています。 一方で、（しばしばベテランのプログラマから）エラーはノイズを含むべきではないと主張されることも少なくありません。 ２
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
bpftraceによるGoアプリケーションのトレース｜hayajo
はじめにシステムの状態を的確に捉え、運用に必要なインサイトを継続的に得るための特性は「オブザーバビリティ」と呼ばれます。オブザーバビリティを実現することで、パフォーマンスのモニタリングやトラブルシューティングを効果的に行い、システムの信頼性を高めることができます。 この重要な特性を実現する上で、eBPFやbpftraceは強力なツールとなります。 本記事では、Goアプリケーションにおけるオブザーバビリティを実現するための一つの方法として、bpftraceを用いたトレースの手法を紹介します。 内容が多いため、目次を活用して段階的に読み進めることをお勧めします。 eBPFとbpftraceはじめに、eBPFとbpftraceについて簡単に説明します。 eBPFとはeBPF(Extended Berkeley Packet Filter)はLinuxカーネル内で動作する柔軟なプログラミングフレー
More powerful Go execution traces - The Go Programming Language
The Go Blog More powerful Go execution traces Michael Knyszek 14 March 2024 The runtime/trace package contains a powerful tool for understanding and troubleshooting Go programs. The functionality within allows one to produce a trace of each goroutine’s execution over some time period. With the go tool trace command (or the excellent open source gotraceui tool), one may then visualize and explore t
【Golang】1日でGoのcobraでサクッとCLIが作れちゃった話
作ったもの リポジトリ 初めに 作った背景 技育博という学生のIT団体が交流するイベントがありまして、 その前日に「イベント用に何か作ろう！」ということで作り始めたというのが開発の背景といなります。 まさかのイベント前日に「1日ハッカソン」が開催されたというわけです、（笑） ちなみに自分は今回紹介するGoでCLIを作る訳になったんですけど、この段階でGo言語を使った経験がバリバリにあるわけでもなく、 チュートリアルを少し触った程度であり、直近の自分のGoのリポジトリを見てみたら最後の更新が昨年の10月だったということもあり約8ヶ月ぶりにGoを触るという、、 このことから伝えたいことは、俺すごいだろ！ではなく、思ったより楽に見栄えがいい制作物が作れるよ！であり、LTなど発表する機会がある時に、時間も発表する材料もないという時にオススメじゃん！ということが伝わればいいなと思ってます！ GoでC
Go ロギングライブラリ - Qiita
[2023/8/21 追記] 2023年8月にリリースされた Go1.21 から公式の準標準ライブラリに slog というライブラリが追加されました。 これが構造化ログに対応しているため、サードパーティライブラリを使わずとも json フォーマットでログを出力することが可能になりました。これから新規にプロジェクトを作る場合はまず slog から始めるのが良いと思います。 [参考] https://go.dev/blog/slog https://zenn.dev/88888888_kota/articles/7e97ff874083cf https://future-architect.github.io/articles/20230731a/ 標準ライブラリ https://golang.org/pkg/log/ 一番サクッとやるならこれ print 関数で palin text 出力な
Prometheus で独自メトリクスを用意する - Carpe Diem
概要 Metric types | Prometheus で定義されているようにPrometheusでは大きく４つのメトリクスタイプがあります。 Counter Gauge Summary Histogram 今回はGoのPrometheusクライアントライブラリを用いて各メトリクスを独自で用意する方法を説明します。 環境 Prometheus 2.11.1 Golang 1.12.7 prometheus/client_golang 1.0.0 expose まずはPrometheusが監視対象のメトリクスをPullできるよう/metricsのエンドポイントを用意します。 公式クライアントとしてpromhttpというライブラリが提供されているのでそれを使います。 package main import ( "log" "net/http" "github.com/prometheus/c
Prometheus でカスタムコレクタを用意する - Carpe Diem
概要 以前↓の独自メトリクスを作る方法を紹介しました。 christina04.hatenablog.com これはdirect instrumentation（直接計装）というやり方で、アプリケーションサーバ自体がstatsを持ちprometheusにデータを渡すやり方です。 今回はそうではなく別プロセスや別サーバ、ホストOSのstatsを取り込んでコレクタとして登録する方法を紹介します。 イメージ的には各stats情報をprometheusフォーマットに変換するproxyを作る感じです。 環境 prometheus/client_golang 1.5.0 Collectorインタフェース GoではCollector interfaceを実装することでCustom Collectorを作れます。 Collector interfaceは以下の2つのメソッドを持っています。 Describ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
