Go1.7のcontextパッケージ
Go1.7ではgolang.org/x/net/contextがcontextパッケージとして標準パッケージに仲間入りする．そしていくつかの標準パッケージではcontextパッケージを使ったメソッド/関数も新たに登場する．contextパッケージは今後さらに重要な，Gopherは普通に扱うべき，パッケージになると考えられる．本記事ではそもそもcontextパッケージとは何か？なぜ登場したのか？なぜ重要なのか？どのように使うべきか？についてまとめる． contextパッケージが初めて紹介されたのは2014年のThe Go Blogの記事 “Go Concurrency Patterns: Context”である．この記事ではなぜGoogleがcontextパッケージを開発したのか，どのように使うのか具体的な検索タスクを例に解説されている．まだ読んだことがない人はそちらを先に読むと良い． co
Go言語のDependency/Vendoringの問題と今後．gbあるいはGo1.5
Go言語のDependency/Vendoringは長く批判の的になってきた（cf. “0x74696d | go get considered harmful”, HN）．Go1.5からは実験的にVendoringの機能が入り，サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している．なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる． Dependencyの問題 最初にGo言語におけるDependecy（依存解決）の問題についてまとめる．Go言語のDependencyで問題なのはビルドの再現性が保証できないこと．この原因はimport文にある． Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する．このimport文は2通りの
Go言語のCLIツールのpanicをラップしてクラッシュレポートをつくる
mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない．普通はちゃんとテストをしてそもそもpanicが発生しないようにする（もしくはトップレベルでrecoverする）．しかし，クロスコンパイルして様々な環境に配布することを，もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると，すべてを作者の想像力の範疇のテストでカバーし，panicをゼロにできるとは限らない． panicが発生した場合，ユーザからすると何が起こったか分からない（Go言語を使ったことがあるユーザなら「あの表示」を見て，panicが起こったことがわかるかもしれない）．適切なエラーメッセージを表示できると良い．開発者からすると，そのpanicの詳しい発生状況を基に修正を行い，新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい． mitchellh/panicw
Go言語でテストしやすいコマンドラインツールをつくる
本記事はGo Advent Calendar 2014の18日目の記事です． Go言語は，クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い．自分もGo言語でいくつかのコマンドラインツールを作成してきた．例えば，GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている． コマンドラインツールをつくるときもテストは重要である．Go言語では標準テストパッケージだけで十分なテストを書くことができる．しかし，コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する．そのテスト，例えばある引数を受けたらこの出力を返し，この終了ステータスで終了するといったテストは，ちゃんとした手法が確立されているわけではなく，迷うことが多い（少なくとも自分は結構悩んだ）． 本記事では，いくつかのOSSツール（得に
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
高速にGo言語のCLIツールをつくるcli-initというツールをつくった
高速にGo言語のCLIツールをつくるcli-initというツールをつくった tcnkms/cli-init・GitHub cli-initを使えば，Go言語コマンドラインツール作成時のお決まりパターンをテンプレートとして自動生成し，コア機能の記述に集中することができる． デモ 以下は簡単な動作例． 上のデモでは，addとlist，deleteというサブコマンドをもつtodoアプリケーションを生成している．生成結果は，tcnksm/sample-cli-initにある． 背景 Go言語で作られたコマンドラインツールを見ていると，codegangsta/cliというパッケージがよく使われている． これは，コマンドラインツールのインターフェースを定義するためのライブラリで，これを使えば，サブコマンドをもつコマンドラインツールを簡単につくることができる（Usageを自動で生成してくれたり，bash
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
