元エントリは↓で、これが全てです。 dev.to 最高じゃんhttps://t.co/c1hfSYhgx2— k1LoW (@k1LoW) 2023年8月26日 Goでツールではなくライブラリ（パッケージ）を作っているとき、テストにしか使わないパッケージがgo.modに入って依存関係ができてしまうのが、いつも気になっていました。 ただ、「まあ別にいいかな」と思っていたのですが、ちょうど標準パッケージだけで機能が実現できるパッケージができたので、どうしてもgo.modを綺麗にしたくなりました。 そして、えいっと調べてみたらすぐに解決方法が見つかったのでした。 テストでしか使わないパッケージをgo.modに含めない方法 方法は次の通りです*1。 テスト用に go_test.mod ファイルを用意して -modfile オプションを使って go_test.mod ファイルを指定して go tes

みなさんはdeb/RPMパッケージを作ったことはありますか？ 私はtcpdpのパッケージ作成ではじめて作りました。具体的にはここらへんです。 tcpdpはlibpcapに依存していることもあり、DockerでUbuntu/CentOSの環境を作ってその上でコンパイルして、合わせてdeb/RPMパッケージ化までするようにしています。 本来Goはクロスコンパイルができるので、コンパイルしてできたバイナリをdeb/RPMパッケージにできればいいわけです。 ただ、意外にdeb/RPMパッケージをするための前準備が面倒です。 debパッケージであればcontrolファイルを書かないといけないですし、RPMパッケージであればspecファイルを書く必要があります。それぞれ覚えているほど書く機会はないので毎回ググるはめに。 ビルド方法にもお作法があります。これもあまり覚えていませんがディレクトリ構成などい

やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ

AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon