おそらくはそれさえも平凡な日々

怒涛の2016年を振り返る

早めに振り返っておく。今年はとにかく怒涛だった。完全にキャパオーバーしてたし、色々遅くなったりして各方面に迷惑もかけたりもして、申し訳なかった。

Mackerel 好調

おかげさまでMackerelが好調である。このフェーズのプロダクトのディレクターをさせてもらえているのはめちゃくちゃ幸せなことだと思う。

なので忙しいのはかまわないし、寧ろ良いことなのだが、やりたいことが無限にあってとにかく手が足りない。その割には僕自身はあまり手が動かせてない。チームメンバーも増えたのでマネージメント的な仕事も増えている。

なんか、完全に管理職のジレンマに陥ってきているのだが、とは言え慣れてない仕事をするのは楽しい。パフォーマンスもっと出せるやろ、って自分を叱咤しながら「ピーターの法則に負けない」って思って生きている。

Mackerelを開発していて思うのは「世の中の変化の速度よりも早い開発スピードを出さないと終わる」ということ。Mackerelは特に変化の早いインフラ界隈に纏わるソフトウェアなので、特にそう感じるのだけど、別に他の業界でも世の中の変化速度以上の開発スピードを出せなくなったところから淘汰されていくんだろうな、と思う。

ちなみに、今Mackerelチームで働くのはものすごく楽しいので、興味のある人は是非応募してください。エンジニア全職種お待ちしております。応募前に話聞きたいとかでも僕に連絡くれれば話の機会を作ります。

http://hatenacorp.jp/recruit/

子供

子供は可愛い。去年の6月に生まれたので、もう1歳半だ。どんどん成長する。赤子だったのがもう子供という感じになった。

同僚の id:mtakano さんの以下のエントリを見て、これは素晴らしいと思って真似した。妻が実家から戻ってきた翌日から今でもほぼ欠かさず毎朝子供を風呂に入れている。

最近はたまに一緒に近所の公園めぐりをしたりしている。普段は動きたがるのだが、抱っこ紐で僕に抱っこされるのは快適らしく、特に文句も言わずおさまってくれている。

子供はかなり発育がよく既に12kgを超えている。抱っこしながら散歩するといい運動になってよいのだが、ちょ氏のサイトに以下のようなことが書いてあって震えている。

ところでみなさん、エルゴの耐荷重の最大値は「おんぶ」状態のものであることはご存知でしたか? 前抱きの場合は 12.2kg が最大なんですよ。

エルゴが壊れた - 氾濫原

ISUCON6

とにかくしんどかった。今年一番の頭痛の種はこれでした。「仕事忙しいのにISUCONとかやってる場合じゃない」とか言ったりしていた。

やるからには、ちゃんとはてなでやってますアピールをするべきだったんだけどあまりできなかったことも悔いが残る。ISUCON6に関するエントリは別途書きます。

マンション購入

買ってしまった。割りと勢いで買った。ローンの審査を出したのがはてな上場承認の一週間前で、知ってはいたがもちろん口には出せず「来週だったらまた状況違うのかもなー、ストックオプションもあるしなー」とか内心思ったりしていた。これも後日別途エントリ書ければ。

はてな上場

そういや上場しました。IRチームがめちゃくちゃ優秀で、はてなの文化を理解して維持したままできれいに上場したのはすごい。上場前後で嫌な変化は全くない。

僕ははてなが好きだし、良いことをやっている会社だと思っているので、それを小さな世界でやってるのではなく、ちゃんと公器として成長させていこうという点で、株式公開は喜ばしいことだと思っている。

みんなのGo言語

執筆に参加しました

この話はもらったときは、案件が降ってきすぎで「完全にフィーバーだな」とか思ったけど、それを面白がる余裕がまだあった。

JPA参画

はてなとしてJPA(Japan Perl Association)の新体制に関わっている。会合に出席したりはしているがあまりコミットできていない。本当はもっとコミットしたいと思っているのだが…。

Perl Hackers Hub執筆者探し

実は去年の7月から技術評論社のWEB+DB Press誌のPerl Hackers Hubの執筆者探しを担当しているのだけど、毎回執筆者探しは難航している。もう少し早めに声かければ良いのだが毎回ギリギリになってしまっていて良くない。

Perl Hackerの皆様は、声をかけると大体前向きに返事をしてくださるので助かっております。

1000ブクマ

以下のエントリが1000ブクマ行った。1000ブクマ超えは初めてのことだったので嬉しかった。

読み返してみると、チグハグな部分もあって書き直したいところもある。これでも休みを丸一日潰して書いたくらいなので、文章書くの早くなりたい…。

ハッカーズチャンプルー

ハッカーズチャンプルー2016 にお招きいただいて「Mackerelは至る道」というトークをしてきた。

こういうお声がかかることはありがたいことだし、沖縄行けたのも良かった。ハッカソン合宿からの参加で、仕事関連のコードをぼちぼち書いた。数日オフィスの外で仕事するとだいぶはかどりますね。MTGが無いのが良いし考え事もできる。来年もそういう機会を作りたい。

CTO交代

まさかの id:stanaka さん退職からの id:motemen CTO就任。所感はこちら → はてなに入って2年くらい経ちました。CTOとかMackerelとか

僕もチーフエンジニアとして motemen CTOをもっと盛り立てていかないとなーとか思いつつ、できていないので頑張りたい。

そして二人目の子供

なんと、二人目の子供が妻のお腹の中にいて、予定日は12月30日です。まさしく今年の怒涛を締めくくるにふさわしい行事ですね。

「みんなのGo言語」の執筆に参加しました

みんなのGo言語【現場で使える実践テクニック】

「みんなのGo言語【現場で使える実践テクニック】」の執筆に参加させてもらいました。僕は第1章の「Goによるチーム開発のはじめ方とコードを書く上での心得」を担当しました。

主に、Goを始めたばかりの人に向けてのお約束や普遍的な考え方について個人のアレンジも加えながら書きました。このあたりはネット上には雑多な情報が混在しており、独自のやり方で回り道をしてしまっている人も多く見受けられることに課題意識があったので、このあたりの「レールを敷く」ことを意識しました。Goは思想的なところの説明も含めて公式ドキュメントが充実しており、そちらに同じようなことが書いていることも多いのですが、そこから一歩踏み込んだ実践的な内容になるようにしました。

雑誌以外の書籍執筆は初めてで良い経験をさせてもらいました。自分の名前がついた本が書店に平積みされているのを見るのは感無量です。改めてこの素晴らしい執筆陣の中で本を書けたのは幸せなことだと感じています。

豪華執筆陣によるバランスの取れた構成の本になっています。ちょっと興味のある方にも、一歩踏み込んだことを知りたい方にも有用な内容が含まれているかと思います。Go言語に興味のある方は是非お手にとってお買い求めください。

メールや、執筆に利用したGitHubリポジトリのログを見ると以下のようなスケジュールでした。

すごい人達との共著ということで、各種締切には緊張感がありました。単著ではこの締切は守れなかったと思うので、単著書ける人はつくづくすごいですね。

相互レビューが楽しく刺激的でした。他の人の担当分を読むことも、自分の担当分への的確なフィードバックも学びが多かったです。

話題の表紙ですが、そのラフが上がってきたときには、その奇抜なデザインに正直ちょっと驚いたのですが、その後配色されたものが共有されたときには、当たり前ですが「プロはさすがだな」と驚嘆したことを覚えています。

個人的にも貴重な経験をさせてもらいましたし、良い本に仕上がっていると思いますので、再度となりますが、ぜひお買い求めください!

みんなのGo言語【現場で使える実践テクニック】

はてなに入って2年くらい経ちました。CTOとかMackerelとか

この度はてなのCTOが id:stanaka から id:motemen に交代しました。僕はチーフエンジニアとして引き続き頑張っていく所存です。

stanakaとMackerel

stanaka にはチーフエンジニアやMackerelチームのディレクターを務める中で様々な指導をいただきました。

そのエンジニアリング能力、ビジネスも含めた視野の広さ、Mackerelに立ち上げたことに代表されるようなビジョンにはただただ圧倒される日々でした。

思い起こせば2年前、stanakaにMackerel事業の魅力やはてな東京オフィスでのエンジニアリングチームの立ち上げについて話をしていただきました。僕はそれらに魅力を感じはてなに入社しました。その後は、チーフエンジニア、Mackerelのディレクターなどの立場も与えてもらい、引き上げてもらったと感じています。

Mackerel事業にディレクターとして関わりながら、stanakaと仕事ができたのは刺激的な日々でした。「ああ、stanakaにはMackerel立ち上げの時に既にこういう景色が見えていたのか」と、多くの気付きを与えてもらい、そのビジョンに驚かされっぱなしでした。

ようやくMackerelの思想を理解できてきたかな、と感じつつあったところで、退職されてしまうのは非常に寂しく残念です。

ただ、一緒にやっているとどうしても甘えが出てしまう、stakanaの後ろを走ろうとしてしまう部分があります。ですので、ここでstanakaが離れることは、独り立ちをして、Mackerelを含めてもっと大きな成長ができるチャンスでもあると捉えています。

なんであれ大きな変化はチャンスです。チャンスに変えるべきものです。Mackerelを頑張って引き継ぎ、より多くのユーザーに満足してもらえるようなサービスにしていく所存です。

Mackerelも一年前から、事業責任者として id:sugiyama88 が参画しています。製造系の大企業にいただけあり、エンジニアでありながら、そのビジネス力、アカウンタビリティの高さには学ぶところが多く、Mackerelのビジネス面の整備、強化に大きく貢献されています。そういう背景もあり、Mackerelはより成長していく地盤が固まったところでもあります。

stanakaにも引き続き定期的にアドバイザリーという形で関わっていただきます。

なにより、stanakaが40歳を超え、今の立場を捨てても、チャレンジができるということは、一エンジニアとして、改めて尊敬の念を禁じえません。僕としてもかくありたいと思うところです。(もちろん、僕自身ははてなにまだまだ10年以上のスパンで関わりたいとは思っています。)

motemenとCTO

id:motemen がCTOを引き継ぐことはとにかく楽しみです。

2年前、motemenがいなかったら、いくら、stanaka さんや id:onishi さんに誘われても、僕ははてなに入らなかっただろうな、と思ってます。

僕がはてなに入る時に、次の会社の条件として大前提で考えていたのは、自分より「若く」「優秀な」エンジニアがいるというところでした。なので「はてなにはmotemenがいるから大丈夫だな」と思ったのを覚えています。僕にとってmotemenははてな入社前からスターエンジニアでした。

入社直後はmotemenがMackerelのディレクターをしていたので、半年ほど運良く一緒に働くことができました。

そこで驚いたのは、motemenの全方位への能力の高さです。単にコード書く能力が自分より上なのは仕方ないにせよ、それ以外のスペックでかなり負けてることが衝撃でした。

当時は彼はディレクターだったので、コードを書く仕事自体は少なかったのですが、スクラムを通したチーム作りとか、仕組みづくりなどを申し分なくこなしていて、しかもその合間にScalaやGoのコードを書いたりしていて、根本的な能力が高いことに舌を巻きました。

「本当に優秀な人は何でもできるんだな」と改めて感じさせられたものでした。

人格的にも申し分なく、チーフエンジニアとして、気配りが効く良いお兄さん的な存在であり、エンジニアの面々からの信頼も篤いです。

今、ISUCON6の問題作成を一緒にしていますが、改めて「は〜、motemenの書くコードはかっこいいなー」とか感じさせられています。彼のコードを見ていると、エンジニアリングには後天的には身に付けるのが難しいセンスとしか言い様がない物が存在するな、と痛感させられます。

そんなmotemenがCTOになることは本当に楽しみです。

hakobe932とチーフエンジニア

motemenがCTOになったことに伴い、京都側のチーフエンジニアとして、 id:hakobe932 が新たに就任しています。hakobe932も僕にとっては、入社前から憧れの、はてなの中の若手スターエンジニア的な存在でした。

YAPC::Asia 2010でのLT「ページャー実装マニアックス」は今でも心に残っています。当時の僕は単にYAPCを単に見る側で登壇なんて考えられないような何者でもないエンジニアだったのですが、今、彼と一緒にチーフエンジニアとして働けることは本当に嬉しく思っています。

僕自身とはてな

僕自身もチーフエンジニアとしてもMackerelの開発責任者としても引き続き頑張っていきます。

僕はチーフエンジニア陣の中で唯一の中途入社であり、いわゆる「日本の会社」で働いた経験があります。はてなで新卒で入ったエンジニアがちゃんと適切な立場が与えられることは好ましいことなので、僕は引き続きその下支えをしていこうと思っています。

はてなもMackerelもまだまだこれから成長していくので、一緒に働きたい方がいましたら、是非採用にご応募ください。

今後共はてなとMackerelをよろしくお願いします。

LTSVをGoのstructにマッピングするやつ書いた

はてなで標準的に使われているログフォーマットである LTSV ですが、Goのstructにマッピングしてくれるやつを書いてみた。

https://github.com/Songmu/go-ltsv

ltsv.Unmarshal(b, &t)

とかやって使う感じです。詳しくは以下のExampleをごらんください。example test便利。

https://godoc.org/github.com/Songmu/go-ltsv#Unmarshal

かなり見よう見まねで書いたこともあり、ピヨピヨしている部分もありそうなので、ご指摘いただけると嬉しいです。

`ghg` で GitHub Releasesから適切な実行ファイルを統一的に取得する

https://github.com/Songmu/ghg

tl;dr

% ghg get motemen/ghq

とかやれば、GitHub Releasesに上がった最新の実行ファイルを取得できる。

% $(ghg bin)/ghq

とかで実行可能。 $(ghg bin)$PATH に追加してもよい。

% ghg get Songmu/ghch@v0.0.1

とかでバージョン指定も可能。

本文

Goで書いたツールを提供する場合、クロスビルドしたものを GitHub Releasesに上げるのが定番となっています。

なぜ、 go get ではないのかというと go get の場合以下のような問題があるからです。

ただし、GitHub Releasesに上げるアーカイブのルールはまちまちであるため、それを統一的に取得する方法が無いのが困り者でした。

そこで作成したのが ghgghqghr リスペクトで gh + 1文字命名になっています。

例えば motemen/ghq から ghq を取得したい場合には以下のように使います。

% ghg get motemen/ghq
fetch the GitHub release for motemen/ghq
install motemen/ghq version: v0.7.4
download https://github.com/motemen/ghq/releases/download/v0.7.4/ghq_darwin_amd64.zip
[======================================] 1.34 MB/1.34 MB
extract ghq_darwin_amd64.zip
install ghq
done!

ghg bin がインストールディレクトリを返すので、あとは $(ghg bin)/ghq などとすれば ghq を実行可能です。 ghg bin$PATH に追加しても良いでしょう。僕はそうしています。

仕組みとしては以下のようになっています。

  1. GitHub上の最新もしくは指定されたリリース情報を取得
  2. リリース情報内のアセットリストを舐めて、OSとARCHが含まれるようなアーカイブ(例えば ghq_darwin_amd64.zip) のURLを取得
  3. 2.で対象URLが見つかった場合それをダウンロードして展開
  4. アーカイブ内部の実行可能ファイルを ~/.ghg/bin に配置

なので、アーカイブ名のルールさえ合っていれば、Goのツールにかぎらずお使いいただけます。

割と雑で強引な作りなのですが、何気にちゃんと動いているので皆様是非ご利用ください。

Makefileを自己文書化する `make2help`

近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。

新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。

タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp も本質的にはビルドツールですし。

Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使ってみると、案外これはこれで悪くないな、と思うようになりました。大体の環境に入っていますし、実は基本のルールもシンプルで素朴に使う分にはそれほど難しくありません。

ただ、 rake -T のようにタスク一覧を出してくれる機能は make にはないため、それと同等の機能が欲しいと常々思っていました。

そんなところに、 Makefileを自己文書化する という記事があり、感銘を受けました。それと同時に、2016年にもなって結局こういう泥臭い方法しかないことに軽くショックを受けました。

ということで、これにインスパイアされて、Goでツールを作ってみました。その名も make2help です。

https://github.com/Songmu/make2help

インストール

https://github.com/Songmu/make2help/releases からバイナリをダウンロードできます。go get も可能です。

% go get github.com/Songmu/make2help/cmd/make2help

使い方

Makefileが配置してあるディレクトリで make2help -allタスクの一覧が、ターゲットの一覧が表示されます。-all を付けない場合は、説明が書かれているターゲットのみがリストアップされます。説明は、ターゲット定義の直前に ## から始まるコメントの形で記述します。

折角なので、 make help を実行するとヘルプを表示するようにしてみましょう。以下の様な Makefile を用意します。

.DEFAULT_GOAL := help

## Run tests
test: deps
    go test ./...

## Install dependencies
deps:
    go get -d -v -t ./...

## Show help
help:
    @make2help $(MAKEFILE_LIST)

.PHONY: test deps help

helpターゲットで make2help を実行するように定義してあります。また、 .DEFAULT_GOAL に helpを代入して、これが標準のターゲットになるようにもしてあります。これで make を実行すると make help を実行したのと同じ効果が得られるようになります。実行結果は以下のとおりです。

ということで非常に便利なので是非ご利用ください。

ghchを利用してGoツールのリリースを自動化する

ghch v0.0.2 をリリース しました

CHANGELOG.md を見るとわかりますが、以下の様な変更が入っています。もちろんこの CHANGELOG.md はghchで生成しています。

このバージョンから、リリーススクリプトを整備して、スクリプト一発で以下のことができるようになりました。

実際のスクリプトはこれ → https://github.com/Songmu/ghch/blob/master/_tools/releng

ちなみに、Goのプロジェクトでこういうスクリプトってどこに置くのがいいのだろうか。go toolが無視してくれたほうが良さそうなので、一応アンダースコアをつけた _tools に配置をしているのですが。

ということで、今後Goツールのリリースはこういう感じでやっていこうと思います。

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

今後Goの開発は全て $GOPATH 配下でおこなうことになります。

go getしてREPLを入れてみる

$GOPATH を設定すると go get ができるようになります。試しにGoのREPLである、gore を入れてみましょう。

% go get github.com/motemen/gore

ついでに gore の真価を発揮させるために、以下のパッケージも併せて入れましょう。

% go get github.com/nsf/gocode
% go get github.com/k0kubun/pp
% go get golang.org/x/tools/cmd/godoc

ちなみに、 go get には -u というオプションがあります。このオプションをつけないと、手元のパッケージが古くても更新をしてくれません。最新の状態にしたい場合には go get -u を使うようにしましょう。

さて、これでおもむろに gore とターミナルに打ち込んで起動すれば go get 成功です。

% gore
gore version 0.2.5  :help for help
gore>

Ctrl+dで終了します。

gore は非常に便利で、特にGoに慣れないうちは、挙動の確認のために欠かせないツールです。

詳しくは作者のエントリをごらんください。 → コード補完もできる Go の REPL「gore」を作った

$GOPATH の中を覗いてみる

さて、go get をしたら $GOPATH がどうなったかを見てみましょう。

% ls $GOPATH
bin/    pkg/    src/

$GOPATH 直下を見てみると、3つのディレクトリがあります。bin/ にはGo製ツールの実行ファイルが、src/ にはソースコードが配置されます。

src/ 以下を掘り下げて見てみましょう。

% tree -L 3 $GOPATH/src
$GOPATH/src
├── github.com
│   ├── k0kubun
│   │   └── pp
│   ├── mattn
│   │   └── go-colorable
│   ├── mitchellh
│   │   └── go-homedir
│   ├── motemen
│   │   ├── go-quickfix
│   │   └── gore
│   ├── nsf
│   │   └── gocode
│   └── peterh
│       └── liner
└── golang.org
    └── x
        └── tools

{{vcs_domain}}/{{repositry_path}} というような形で配置されていることがわかります。

Goは、GitやMercurialなどのリポジトリがパッケージになるという面白い特徴があります。また、 go get で取得したソースコードには、GitやMercurialの履歴も含まれています。そのため、開発もその中でおこなうことができるのです。

ghq を使いリポジトリ管理をより簡単にする

$GOPATH/src のリポジトリ配置ルールは、最初は慣れないが、実は理に適った配置です。

僕は、Go言語以外の全てのプロジェクトリポジトリも $GOPATH/src 配下に配置するようにしています。そこで役立つのが ghq です。

ghqgo get と同様のルールでソースコードリポジトリを取得するためのツールです。homebrewでインストールできます。

% brew install ghq

インストールが終わったら、 ghq でソースを取得してくるディレクトリを以下のように指定します。

% git config --global ghq.root '~/dev/src'

これで準備は完了です。ここで ghq list と打つとリポジトリ一覧を取得してくれます。また、ghq get <target> とすることで、リモートリポジトリのソースコードを取得できます。

はかなり柔軟に指定ができて賢い振る舞いをします。例えば、以下のように、各種URLやGitHubのパスなどを指定しても、柔軟に解釈して、ダウンロードしてくれます。

# 例
% ghq get git://hogehoge.git
% ghq get https://github.com/mackerelio/mackerel-agent
% ghq get mackerelio/mkr

これで、手元のソースコードリポジトリの管理を簡単におこなうことができるようになりました。

ghq についても作者のエントリを参照してみてください。 → ghq: リモートリポジトリのローカルクローンをシンプルに管理する (ちなみに、リンク先で言及されている ghq import は現在は削除されています)

peco でより便利にリポジトリの移動を行う

さて、これで統一感の取れたリポジトリ管理ができるようになりましたが、$GOPATH/src 配下の階層が非常に深くなってしまい、そのままだと移動が面倒です。そこで peco を使います。

peco はターミナル上で標準入力を行ベースでインクリメンタルにフィルタするUIを提供する、汎用性の高いツールです。これもまたhomebrewでインストールが可能です。

% brew install peco

peco がインストールされたら、早速 ghq と組み合わせて使ってみましょう。お使いのシェルがzshの場合、以下の様な設定を、.zshrc などに書いてみてください。

bindkey '^F' peco-src

function peco-src () {
    local selected_dir=$(ghq list | peco --query "$LBUFFER")                                        if [ -n "$selected_dir" ]; then
        selected_dir="$GOPATH/src/$selected_dir"
        BUFFER="cd ${selected_dir}"
        zle accept-line
    fi
    zle clear-screen
}
zle -N peco-src

peco-src という関数を定義し、それを Ctrl+fで呼び出せるようにしてあります。

この設定を読み込んだ後に、ターミナル上で、Ctrl+fを入力するとpecoのUIが現れます。そこで適当にキー入力をおこなうと、フィルタリングされていく様子が見て取れるでしょう。

例えば、私の環境で、 github mackerel- という条件でフィルタしている様子が以下になります。

ここで、適当なリポジトリを選択し、エンターを押して確定すると、そのディレクトリに移動することができます。

これで、go getghq getしたリポジトリに自由に移動できるようになりました。

peco のその他の活用例は、公式のWikiのSample-Usage を見ると良いでしょう。

まとめ

これで、Goで開発をおこなう下準備は整いました。エディタ設定や、実際にプロジェクトを開始するときにどうするかなどは、そのうち書くかもしれません。

Gitのtagとpull requestのマージ履歴からChangelogを自動生成する `ghch`

https://github.com/Songmu/ghch

mackerel-agent のリリースフローでは、前回のリリース以降の、pull requestのマージ履歴を拾って、そこからChangelogを自動生成するということをおこなっている。

これは、1年半前くらいにPerlで書いていたのだが、この度汎用的にしてGoで書きなおした。それが ghch。前回打ったsemverっぽいgit tag以降のマージ履歴を抽出してくれる。例えば、こういう風にmackdownで出力がされる。

% ghch --format=markdown --next-version=v0.30.3
## [v0.30.3](https://github.com/mackerelio/mackerel-agent/releases/tag/v0.30.3) (2016-04-27)

* retry retirement when api request failed [#224](https://github.com/mackerelio/mackerel-agent/pull/224) ([Songmu](https://github.com/Songmu))
* Fix comments [#222](https://github.com/mackerelio/mackerel-agent/pull/222) ([stefafafan](https://github.com/stefafafan))
* Remove go get cmd/vet [#223](https://github.com/mackerelio/mackerel-agent/pull/223) ([itchyny](https://github.com/itchyny))
* [nit] [plugin.checks.foo ] is valid toml now [#225](https://github.com/mackerelio/mackerel-agent/pull/225) ([Songmu](https://github.com/Songmu))
* Remove usr local bin again [#217](https://github.com/mackerelio/mackerel-agent/pull/217) ([Songmu](https://github.com/Songmu))
* Fix typo [#221](https://github.com/mackerelio/mackerel-agent/pull/221) ([yukiyan](https://github.com/yukiyan))

標準だとjsonが出力される。そっちのほうがスクリプトからだと扱いやすいでしょう。

コミットログをChangelogの代わりにするというのは流石に乱暴だろうと僕は思っているので、サマリーとしてのChangelogは必要。ただ、書くのは面倒くさいので、マージしたpull requestのタイトルを拾ってきてそれをChangelogの一覧にするのは結構良いんじゃないかと思っている。

pull requestのタイトルであれば後から編集ができるので、Changelog生成前に見なおして書きなおすことも簡単。コミットログだとこうはいかず、後から編集が面倒くさいし、そもそも歴史改変もしたくない。ちなみにmackerel-agentの場合だと、 [nit] というタグがタイトルについていれば、Changelogに載せない、みたいな運用もしています。

gobump やgoxc、ghrと併用すれば、CHANGELOG自動更新を含めてリリース作業を自動化することも可能でしょう。

ちなみにマージコミットを拾う仕組みになっているので、squash mergeボタンを使ってしまうと抽出できないので注意。

以下からバイナリを取得できます。ぜひお試しください。

https://github.com/Songmu/ghch/releases

禁酒することにした

先月中頃から禁酒していて、7回飲み会行って酒を飲まないことに成功しているので、禁酒成功している。

飲み会自体は変わらず行くけど酒は頼まない。祝い酒とか食前酒とかそういうのは別に拒まず飲むくらいの緩い運用でやっております。

特に何があったというわけでないのだけど、唐突に思い立って止めようと言う気になった。

ここ数年酒は十分楽しんだなーという感じでもう飽きた感じもある。

最近、飲み会が多くて、飲み始めると無限に飲んでしまうので、流石にブレーキをかけるかというのもあった。僕は欲望を満たし始めたら徹底的に満たすことがモットーで、中途半端に飲んで我慢するのは嫌なので、完全にやめてしまうか、というところ。

最近は、完全に惰性で飲んでいて、身体もヤバいし、欲望に溺れている感じがあった。欲望を好きなだけ満たしつつ、欲望には溺れないというところがモットーなのに完全に失敗していた。

ということで、しばらく飲まない予定です。最初にも書いたけど飲み会には行くよ!