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

はてなに入って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回飲み会行って酒を飲まないことに成功しているので、禁酒成功している。

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

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

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

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

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

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

コミュ力が無いのはいつだって自分

突然何を言い出すのかという話ですが、対話相手にコミュニケーション能力を求める醜さについて書きたくなったので書きます。

僕はオタクだったしスクールカーストで言うと下の方を彷徨ってきた。地元でもいろいろあって浮いていた。新卒時の就活も散々だった。なので、コミュ力がないことは自覚しているし、だからこそ「コミュニケーション能力」という言葉には警戒心があります。

比較的マイノリティであったことが多かった経験上分かったのは、相手とコミュニケーションが取りづらいな、と思うときは、そもそもプロトコルが異なる、ということです。

これは、話している自然言語が違うようなものだと考えるとわかりやすい。例えば、自分が日本語しか話せず、相手がロシア語しか話せないのであれば、まともなコミュニケーションが成り立たないのは明らかです。そして、その時に、日本語が話せない相手にコミュ力がないと思うような人はいないでしょう。

それが、実際のコミュニケーションになると、不思議と相手のコミュ力不足を断じるような人がでてきます。

例えば「最近の若者はコミュ力が云々」みたいなのは、老害が若者語を話せず、若者は老害語を話したくもない、というだけの話でしかありません。同様にリア充が非コミュを見下すのも、リア充が非コミュ語を話せず、非コミュがリア充語を話せないという話でしか無いのです。

もちろん、それぞれのプロコトルを使いこなして、それぞれのクラスタの人とうまくコミュニケーションが取れる人もいる。そういう人はマルチリンガルみたいなもので、コミュ力が高いと言えるのは間違いない。

ただ、コミュニケーションが取れない時に、それを相手のコミュ力のせいにするのは知性と人間性の欠如でしかありません。一般的に何らかの問題が起こっているときに、それを自分のせいにするか、相手のせいにするかで、その人の知性や人間性が試されます。

自分をマジョリティだと思っている人、コミュ力があると勘違いしている人は、普段は自分の周辺の大半の人とのコミュニケーションには困らないので、自分と違うコミュニティの人と意思疎通ができなかった時には相手のコミュ力を見下しがちです。

ただ、自然言語に置き換えると、別に言語話者の多寡はコミュ力とは関係ないのは明らかです。日本語話者より中国語話者の方がコミュ力が高いと言われて納得できる人はいないでしょう。

それに、コミュニケーションが取れない以上、自分の方が多数派だとは限りません。相手は、サンスクリット語を話しているかもしれないし、ヒンディー語を話しているかも知れません。ヒンディー語話者は身近には居ないかもしれませんが、世界的には日本語の5倍くらいの話者がいます。

実際、コミュニケーションが全く成り立たない人、というのもいます。ただそれは、自分と相手のプロトコルの問題であって、どちらかのコミュ力の高低の問題ではない。そう僕は考えるようにしています。相手とコミュニケーションが取れるか取れないかという事実だけがあり、それをどう捉えるか、という話です。

じゃあ、人間はコミュニケーションプロトコルが近しい人とだけコミュニケーションを取っていればいいかというと、そういうわけではないと考えています。

異質なものとコミュニケーションを取っていかないと変化や成長はありません。身近な人と慣れ合っていても成長が望めないというのはその裏返しです。生物の交配と同じような話で、長い目で見ると生き残れなくなる可能性があります。

また、コミュニケーションは、コストとリターンの話でもあります。相手とコミュニケーションを取るためにこちらがどれくらいのコストを払い、どれくらいの見返りが得られるか、ということです。これは相手にとっても同じです。

だから、お互いが支払うコストに対して、リターンが多いという合意が取れた場合に、健全なコミュニケーションが成り立つと言えます。

一般的に、コミュニケーションプロトコルが近い相手とのコミュニケーションは、ローコスト・ロー(〜ミドル)リターンです。そして、それが遠い相手とは、遠くなるほどコストは高くなり、リターンは未知数です。

まず、お互いのプロトコルが違いすぎて、お互いのリターンが見込めない時、むしろマイナスになりそうな時は、意識的に関わらないようにすることも大事です。これはすごく大事。

そして、お互いのプロトコルが異なりつつも、リターンの期待値を上げたい場合には、自分からコミュニケーションを取りに行くことが大事だと思ってます。

コミュニケーション能力があるとみなされている人は、ここが上手い。僕なんかは、そうやったほうがいいと思っても躊躇してしまってなかなかできなかったりするのです。ただ、少なくとも、コミュニケーションが取れない理由を相手のせいにしないで歩み寄ることを心がけていて「コミュ力が無いのはいつだって自分」だと思うようにはしています。

いろいろな人とコミュニケーションが取れるようになると、色々なプロトコルを操れるようになって、コミュニケーションの精度も上がっていくのでしょう。自然言語の習得とかも近い話であるようにも感じます。

なんでこういうこと書いたのかというと、採用とかマネージメントに関わるようになって、コミュニケーションってなんだろうなーとか考えたりすることが増えた影響が大きそう。

Webアプリケーションエンジニアにこそ薦めたい「ITインフラ監視[実践]入門」

ソフトウェアエンジニアのための ITインフラ監視[実践]入門

技術評論社様よりご恵贈頂きました。著者のkoemuさん、ありがとうございます。

この本は本当に監視入門にふさわしく、以下のように網羅的かつ、そして何より陳腐化しない、普遍的な監視に対する心構えや考え方に対して非常によくまとまっていました。

監視に対する心構えや、「監視システムをどのように運用していくか、閾値をどのように決めていくか」、そして、なかなか無い観点として「監視体制の業務設計」といった話が印象深かったです。

モデルケースとして、Linuxサーバー上のApache、MySQL、Tomcatの監視などが取り上げられており、実際に Mackerel!!!を使った監視構築にも触れられており非常に興味深くも嬉しくも思いました。

あまり監視の知見のないWebアプリケーションエンジニアが、自分が作ったサービスを一般公開したものの、監視に対する知見がなくて困っていたり、アプリケーションは作れるようになったが、実際に運用していく中でどういった心構えが必要なのか知りたい、といったケースに本書は非常に有用だと思います。

また「監視とは何なのか」という観点の本は珍しく、監視とは何なのかを改めて考えるきっかけにする意味で、実際に業務でバリバリ監視を行っている人であっても、本書を読むことをおすすめしたい。

ソフトウェアエンジニアのための ITインフラ監視[実践]入門