依存ライブラリのLICENSE同梱のためのgocreditsというツールを作った | おそらくはそれさえも平凡な日々
https://github.com/Songmu/gocredits Goのプロジェクトの依存ライブラリのLICENSEを抽出して、CREDITSという単一ファイルに書き出してくれるツールを作りました。もともとのアイデアは同僚の id:tarao によるものです。Go Modulesを使っているプロジェクトで以下のようにすれば、CREDITSファイルを書き出してくれます。出力されたCREDITSファイルは実行バイナリを配布する時に有用でしょう。 % gocredits -w . Goは実行バイナリを簡単に配布できるので便利ですが、ソフトウェアを配布するときは、依存ライブラリのLICENSEを考慮する必要があります。具体的には恐らく依存ライブラリのライセンスのコピーを同梱する必要がありそうです。リンクだけではだめでコピーを含めた方が良さそうです。 例えば、MITライセンスには以下の記述があ
ECSとGoで構築したシステムにDatadogを導入する | おそらくはそれさえも平凡な日々
追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい
smartcache ~ プリフェッチするインメモリキャッシュ | おそらくはそれさえも平凡な日々
https://github.com/Songmu/smartcache smartcacheというGoのインメモリキャッシュライブラリを書いた。 一般的に、キャッシュを実装する場合以下のような問題が起こりがちです。 キャッシュ更新時にリクエストが殺到してしまう(いわゆるThundering Herd問題) キャッシュ生成に時間がかかる場合、キャッシュ更新時に処理がブロックしてしまう smartcacheは上記の問題を以下のアプローチで解決しています。 キャッシュ更新処理を一本化する Goの場合 golang.org/x/sync/singleflight を使えば簡単! キャッシュ期限切れ前に内部的に更新処理をおこなう いわゆるプリフェッチ的な処理 使い方 コンストラクタにキャッシュの実際の有効期限、softな有効期限、そしてキャッシュ生成関数を渡します。 // コンストラクタ ca :
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
GoConでGoによるコマンド起動と停止について話してきました | おそらくはそれさえも平凡な日々
嬉しいことに、Go Conference 2019 Springのプロポーザルが通ったので、自作のtimeoutパッケージを例にしながらGoからコマンドを起動して停止させる方法について話してきました。 https://junkyard.song.mu/slides/gocon2019-spring/#0 コマンド起動と停止というと簡単な話に聞こえるかも知れませんが、実はちゃんとやるためには考慮すべき事柄があります。そのあたり、GNU timeoutのソースコードも交えながら説明しました。結構面白い話ができたんじゃないかと思います。 github.com/Songmu/timeoutは単にコマンドをタイムアウトさせる目的だけではなく、contextでコマンドを正しく停止させるのにも有用なので是非お使いください。 プロセス停止に関しては大体以下のようなことをお話しました。 Go標準のexec.
最近のGo Modulesプラクティス ~ ghqユーザーの場合も添えて | おそらくはそれさえも平凡な日々
最近Go Modulesを使っていて、だいたいプラクティスが定まってきたのでまとめてみる。 個人的な結論 Go Modulesは積極的に使っていけばいい 幾つか課題はある $GOPATH から出る必要もない $GO111MODULE を適宜設定すればよい どうせ次のGo 1.13からはどこに置こうが関係なくなる 2つのモード $GOPATH/src にプロジェクトを置いていると、今(Go 1.12)の標準動作はGOPATHモードになる。これは、$GOPATH/src 以下からサードパーティパッケージを読み込むこれまでのGoと同様の動作になるということ。 それ以外の場所では go mod コマンドを使ってGo Modulesを利用することができる。これをmodule-awareモードという。go.mod と go.sum を使って依存ライブラリを管理する方式になる。これらのファイルはgo m
Goのバイナリへのファイル同梱はstatikで決まり | おそらくはそれさえも平凡な日々
https://github.com/rakyll/statik Goのバイナリにファイルを同梱するという誰もが欲しいはずのものがなかなか決定版がなく、go-bindataがメンテを終了し、go-assetsもいまいちメンテが滞っているので、statikを使うことにしました。作者のrakyllさんも実績のある方なので大丈夫でしょう。 statikも少しpull requestの取り込みが滞っていたのですが、試しにpull requestを送ってみたらちゃんと取り込まれたので大丈夫そう。 https://github.com/rakyll/statik/pull/61 元々、ファイル単体を取得する分には問題なかったのですが、ファイルシステムとして走査しようとするとうまく辿れない問題があり、このpull requestで修正しました。ですのでより安心して使えるでしょう。 http.FileSy
Goツールのリリースエンジニアリング | おそらくはそれさえも平凡な日々
前回: Goツールのリリースにおけるバージョニングについて 前回挙げた以下のリリース5段階の中で、バージョニングだけで1エントリになりましたが、今回は、2,3について。 versionをbumpする CHANGELOGを更新する 1,2での変更をgitに反映してタグを打つ ビルドする ビルドをアップロードする 具体的には、リリースに纏わるファイル更新をgitに反映さえてタグを打つところまで。ビルドする直前までとも言えます。 CHANGELOG.mdを自動更新する CHANGELOGは ghch で自動生成させている。規定の CHANGELOG.md をリポジトリに配置して、 % ghch -w -N $next_tag とすれば、魔法のように CHANGELOG.md を更新してくれる。生成された CHANGELOG.md はこんな感じ。 https://github.com/Songmu
Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
Mac上にGoの開発環境を構築する〜下準備編 | おそらくはそれさえも平凡な日々
同僚がGoを始める上で、案外まとまった資料が無さそうだったので書いてみることにしました。 Macでhomebrewが入っていることが前提です。事前に brew update をおこない formula を最新のものにしておくと躓くことが少ないでしょう。 Goのインストール % brew install go エントリ執筆時点では、1.6.2 が入ります。Goはメジャーバージョンが同じ場合は、後方互換が保たれているので、基本的に新しいやつを入れて問題ありません。 環境変数の設定 $GOPATH だけを決めればOKです。$GOPATH はどこでも良いのですが、ここでは $HOME/dev を $GOPATH に設定します。また、 $GOPATH/bin に $PATH も通しておきます。 export GOPATH=$HOME/dev export PATH=$GOPATH/bin:$PATH
POSIX sh準拠のシェルスクリプトを書くときに checkbashisms が便利。 | おそらくはそれさえも平凡な日々
http://sourceforge.net/projects/checkbaskisms/ 「#!/bin/sh なのにbashでしか動かないシェルスクリプトを書くな！」みたいなことはよく言われるわけですが、僕はゆとりなので正直どうでもええやろとか思ったりもしてました。実際、CentOSだと、/bin/sh は /bin/bash へのリンクだし、OSXでも /bin/sh の実態はbashだしね。 しかしそこで立ちふさがるのがUbuntu。Ubuntuだとデフォルトで /bin/sh は /bin/dash だったりするわけです。dashはPOSIX準拠のsh実装で、bash独自の記述があると見事に動かない。 とはいえ、それで困るのだったら、デフォルトシェルをbashにしたVMテンプレートを作ればいいんじゃないかって思うやろ。僕もそう思う。 しかしそこで立ちふさがるのがTravisで、
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
golintをCIする | おそらくはそれさえも平凡な日々
go vetは失敗時に終了ステータスがnon zeroなんだけど、golintは指摘項目があっても終了ステータスが0なのでエラー扱いにならない。golintはコーディング規約的な推奨事項なのでエラー扱いじゃないのは妥当そう。 ただ、細かい指摘し合いで消耗したくないのでgolintで警告が出たらCIがコケるようにしたかった。以下のようにして無理やりエラーを出すようにした。 #/bin/sh golint ./... | tee .golint.txt test ! -s .golint.txt 標準出力になんか出てたら失敗になるようにという感じ。出力ちゃんと見たいからteeかましてる。 更にいうと、golintは$GOOSを見てくれているので$GOOSを切り替えながら回せばビルド対象毎の警告も網羅できる。 #/bin/sh rm -f .golint.txt for os in "linux
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
株式会社はてなに入社しました | おそらくはそれさえも平凡な日々
本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか！」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう
退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
Carton考2014 | おそらくはそれさえも平凡な日々
こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 本番環境と同じアーキテクチャ 本番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull
おそらくはそれさえも平凡な日々: Test::mysqldのcopy_data_fromでテストが更に捗る話
少し前ですがTest::mysqld 0.17からは copy_data_fromというオプションが加わっています。 これは、Test::mysqld起動時にコピー元のdataディレクトリを指定できるもので MySQLの起動時間を節約することができます。テスト開始時にDBに大量のデータを 入れておきたい場合に特に有効です。 特にゲームなどの場合は、大量のマスタデータもコードの一部と言えるので、ちゃんと 全部流し込んでからテストを実施したいという要件があるので重宝します。 さて、そのdataディレクトリをどうやって作ればよいかという話になるのですが、 それも、Test::mysqldに事前に作らせてどこかに配置しておけば良いでしょう。 手順としては例えば以下のようになります。 ‘tmp/test_mysqld_data’ をdatadirにしてTest::mysqldを起動 DDLとマスタデ
おそらくはそれさえも平凡な日々: Redis::LeaderBoardっての書いてた
https://github.com/Songmu/p5-Redis-LeaderBoard https://metacpan.org/module/Redis::LeaderBoard RedisのSorted Setがランキング作るのとかに便利だよーってのは今や多くの人に知られるところですが、 同率問題とかがめんどくさかったりするので、その辺解決したやつを書いてみました。 というか、このへんみなさん個別に書いてると思うんですけど、色々めんどくさくなってカッと なってCPANに上げました。Synopsis丸コピですが、以下のような感じで使います。 use Redis; use Redis::LeaderBoard; my $redis = Redis->new; my $lb = Redis::LeaderBoard->new( redis => $redis, key => 'lead
おそらくはそれさえも平凡な日々: サーバーマシンのコア数に応じてworker数を調整する方法
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ 便乗ポスト。最近は、上記内の「シェルスクリプトでラップする方法」で運用していることが多いです。その場合のone more tips. appサーバーごとにマシンスペックが違う場合がたまにあって、その場合マシンごとに worker数を調整したいけど、deployの都合上サーバー起動スクリプトは同じやつを使いた いってことがあります。 そこでおすすめなのが、CPUコア数に応じてworker数を計算する方法です。 シェルスクリプトの場合、 % cat app.sh #/bin/sh NCPU=`getconf _NPROCESSORS_ONLN` WORKERS=$(expr $NCPU \* 5) exec plackup -E production -s Starlet --max-workers=$WORKERS と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
