Go言語でテストを書く際のベストプラクティスとして、テーブル駆動テスト（Table dirven tests） というのが推奨されている。ようはデータとふるまいを分離しましょうという話で、正直わざわざ名前をつけるようなものでもなかろうという気持ちもないではないが、まあ話がはやくていいね。 けどみんなほんとにこれで満足してるの？ と疑問に思うところはある。テストが落ちたときに表示される行番号がテストケースによらず一定で、どのテストが落ちたのかを探すのに一手間かかってしまう。 たとえば以下のコードをテストする際、 package eg import "testing" func TestExample(t *testing.T) { testcases := []struct { name string a, b int sum int }{ {"1+1", 1, 1, 99}, {"2+2"

近年、普段の作業をマウスでやりたくない気持ちが高まっている（デスク周りが散らかってきたせいだという説が有力です）。メールは結局ターミナルでメールを読むことにしたため問題なく過ごせているが、その他のタスクをキーボードだけでやるには、ターミナル動くアプリケーションを作れる必要がある。それもリッチなやつだ。見た目は派手な方がいい。 この記事は Kyoto.go remote #32 LT会 で発表した 入門 Bubble Tea の増補版です。 Bubble Tea とは GitHub - charmbracelet/bubbletea: A powerful little TUI framework 🏗 Bubble Tea とは、Go でリッチなターミナルアプリケーション（TUI）を作るためのフレームワーク。Charm というプロジェクトの一部のようで、ホームページを見てもらったら分かると

よくあるフローってのは Google の API ドキュメントを読んでたらよくでてくるやつ（Calendar API の例）。つまり: 前回のアクセストークンが保存されていたらそれを使い、なかったら localhost にサーバを立て、redirect_uri をそこに設定した認可のための URL をユーザに提示し、 code を受け取ったらアクセストークンと交換し、 トークンを保存する。 みたいな一連の流れ。これまでどの部分を抽象化したらいいのかあまり感覚がわからなくて手を出してなかったんだけど、いいかげん面倒なので書いてみた次第。 oauth2util package - github.com/motemen/go-nuts/oauth2util - pkg.go.dev 使い方は簡単で import "github.com/motemen/go-nuts/oauth2util" ..

緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb

目下新マシンの開発環境をセットアップ中なんだけど、clone しないといけないリポジトリがけっこうたくさんある。このリポジトリ群っていうのが git submodule によってモジュールを共有していて、つまり同じリポジトリを何度も fetch してくることになる。これって無駄じゃないですか？ というわけで submodule update 時にキャッシュを生成し、それを利用して以降の同コマンドを高速化するコマンドを書きました。 https://github.com/motemen/git-shared-submodule-update git submodule update の代わりに使います。 # git submodule update --init の代わりに… git shared-submodule-update --init 簡単ですね。 git submodule upd

Googleカレンダーで現在進行中のイベントをSlackステータスに反映させるようにしておくと、チームメンバーに、移動中や不在やミーティング中といった状況を自然に共有できるので便利ですね。そのように設定している人も多いと思います。 似たアイコンが並んでいるように見えますが一方はモザイクです 巷では Google Apps Script でこの連携を行うような方法が公開されていて、自分でも書いて使ってました。これは一度動かしてしまえば大変便利なんですが、インストールの方法はけっこう面倒で、非エンジニアをふくめ会社のみんなに薦めるには少しハードルが高い。 そこで、Google Apps Script を用いて、（初回のインストール手順を除いて）ワンクリックで Google カレンダーと Slack ステータスの連携を行えるウェブアプリを作りました。 GitHub - motemen/gas-g

Google App Engine（GAE）で Go 製のウェブアプリを動かしたかった話。いっぺん動かしてみると GAE/Go はウェブアプリを動かす環境としてはとてもいい。ただ、中途半端な知識だけで始めると開発者としてはつまずくことが多かったので、分かりにくい点をまとめておく。 Google App Engine Go Standard Environment について goapp は $GOPATH 以下もアプリケーションのソースとしてアップロード／コンパイルする goapp はプロジェクトルート以下のソースコードをすべてコンパイルしようとする go-app-builder: Failed parsing input: parser: bad import "syscall" in ... go-app-builder: Failed parsing input: app file x

思いつきでツールを作ってはリスのように忘れ、再発見しては新鮮な気持ちで便利に使う日々です。 一般にプログラミングにおいては、ソースコードを読むことに意外とばかにならない時間を使うもの。特に Go ではデフォルトで標準ライブラリのソースコードが手元にあり、コードを書く際よい教科書になるので、これを読むことも多いはず。 Go は静的に型付けされる言語なのでその点コードは読みやすいけれど、データ構造が不変ではないので、ある構造体のフィールドがどこで書き換わるのかを知るには、処理を追っていくしかない。名前で grep するのもひとつの手ではあるけど、精度はあまり期待できない。 そこで gofind。簡単に言うと、型やパッケージを含めた名前でもって Go のソースコードを検索するツールです。 go get github.com/motemen/gofind/cmd/gofind 使い方は以下の通り。

5年前に買った『Java並行処理プログラミング ―その「基盤」と「最新API」を究める―』をようやく読んだ。買った頃には Perl やシンプルな JavaScript ばかり書いていたので並行プログラミングなんてほとんど気にすることがなく、実感がなくて読むのも途中で止まってしまっていた本で、家を掃除しているときに見つけたもの。その後も趣味で Android アプリを書くなど Java に触れる機会はあったけれど、せいぜいが AsyncTask を使うくらいで、マルチスレッドを強く意識してコードを書くこともなかった。 Java並行処理プログラミング ―その「基盤」と「最新API」を究める― 作者: Brian Goetz,Joshua Bloch,Doug Lea出版社/メーカー: ソフトバンククリエイティブ発売日: 2006/11/22メディア: 単行本購入: 30人 クリック: 442回

Go 言語には例外機構が備わっておらず、関数や手続きのエラー的な状況を表すには、返り値を多値にして本来興味ある結果とともに error インターフェイスを返す、というのが一般的です。例をあげるまでもないですが、ファイルを開くという（失敗する可能性のある）処理を行うならこういう感じ: f, err := os.Open(filename) if err != nil { // handle err } 何ごとも明に書き下すことを求める Go らしい仕様ですね。文句ある人も多そうですが、呼び出し側が異常系を意識せざるを得なくなるので、よい効果も大きいと思います。 先の例のように、エラーを発生させるような処理を呼び出したあとは err をチェックする、というのは最初に学ぶイディオムと言ってもよいくらいよく書くことになるコードですが、ほんとうに何度も書くことになるのでこれは面倒。 go-iferr

git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って

gobump で Go プロジェクトのバージョニングをおこなう の続き。すっかり書くのが遅くなってしまったけれど、別にもったいぶるような特別なことはないです。 ここでは、Pull Request のマージを契機に、バージョンを進めるコミットをし、push して、GitHub のリリースを進める……ということを CI でおこなうことを目標とします。 これはわりと簡単で、以下のようなスクリプトで実現できます。必要なものは gobump、ghr、jq と GitHub のパーソナルアクセストークン。通常はクロスコンパイルするのに gox も使うことになるでしょう。 set -e repo_owner=motemen repo_name=test-repository committer_email=motemen+gobump-bot@gmail.com committer_name=motem

2015-12-08 追記 TypeScript の型定義ファイルリポジトリのデファクト・スタンダードであるところの DefinitelyTyped に無事 Pull Request が取り込まれました ので、今後は DefinitelyTyped のほうを参照していただければと思います！ Google Apps Script は JavaScript っぽい言語で Google 製品の自動化を行える便利環境で、定期実行や外部との HTTP 通信など、意外と痒いところに手が届く出来であり、今となっては身につけておくとよいツールのひとつと言えるでしょう。GAS の開発はおもにオンラインエディタでおこなうこととなっていて、ここで便利なのは補完が効くこと。慣れたエディタで書くこともできるけれど、補完のない環境で、多岐にわたる API をリファレンス引きながら書くというのは心細い。 そもそも JS

チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して

go run や go test でコードを試しながら書きながら……というフェーズでは、以下のような状況によく遭遇することと思います: デバッグプリント用のコードを削除したら、"log" や "fmt" パッケージが不要になって imported and not used: "log" と言われた。まだ使うかもしれないのでいちいち消したくない。 同様に、コードを整理したところ使っていない変数がでてきて i declared and not used と言われた。まだ使うかも（ｒｙ 出来上がりのコードの品質を高く保つには便利な機能ですが、試行錯誤をしている段階ではけっこうな障害になります。そこで goquickfix。 go build が通らないコードに goquickfix をかければ、コードを書き換えて go build 可能にしてくれます: goquickfix -w hoge.go

タイトルの通りです。Go は LL 的に使える、とはよく申しますが、そういう意識で使っていると REPL 的なことをしたいときに困りがちですよね。そこで作りました。gore。いい名前ですね。 motemen/gore · GitHub 以下のスクリーンキャストでだいたいの雰囲気をお察し下さい。 （スクリーンキャストは cho45/KeyCast を使って撮影しました） 特徴 gore の特徴は以下の通りです。 ラインエディタと履歴 複数行入力 パッケージのインポート、補完つき 式および文を実行可能 コード補完（nsf/gocode を利用） プリティプリント（k0kubun/pp か davecgh/go-spew がおすすめ） ドキュメントも引ける（godoc が必要） 以上のように、非常に便利なものになっております。むしろこの程度 REPL には当然あってほしい機能だとも言える。 イン

こんにちは、はてなチーフアプリケーションエンジニアの id:motemen です。今日ははてなエンジニアアドベントカレンダー2014 の 22 日目として、はてなブログのエントリをローカルと同期するツール blogsync を紹介します。昨日は id:tarao による gulpで依存関係を考慮した自動コンパイル でした。 はてなブログは CMS としても非常に便利に使えるウェブサービスで、実際Mackerel のヘルプもはてなブログで運用しています。ドキュメントのようなコンテンツはいろいろな人が触り、頻繁に書き換えるので変更履歴を残したいところ、また慣れたエディタで編集したいものですが、はてなブログ単体にそういう機能は当然ありません。そこで個人的に はてなブログ AtomPub を用いて、はてなブログのエントリをローカルのファイルシステムに保存するツールを Go で書いて、使ってみていま

こちらです。Perl でいうと Devel::KYTProf に性質がちかい。 motemen/go-loghttp · GitHub (GoDoc) 使用例 たとえばこういうコードに… package main import ( "io" "log" "net/http" "os" ) func main() { resp, err := http.Get(os.Args[1]) if err != nil { log.Fatal(err) } io.Copy(os.Stdout, resp.Body) } % go run main.go http://example.com/ <!doctype html> ... 一行追加すると: package main import ( "io" "log" "net/http" "os" _ "github.com/motemen/go-lo

Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ