Goのテーブル駆動テストではテストケースの定義位置を知りたいのでライブラリを書いた - 詩と創作・思索のひろば
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"
Vimmer、Visual Studio Codeを使う - 詩と創作・思索のひろば
まだ汚れを知らない若者だったころに「プログラムはね、これを使って書くんだよ」と言われて以来Vimは友達だと思ってずっと（15年くらい）使ってきたが、最近は、とくに新しく何かを書くときにはVSCodeを使うようになってきた。コードを書く間隔が広がってきたせいか、新しい技術や言語に対応することができておらず、なんか最初からいい感じになってるエディタを重宝する。歳を取ってきたからなんだろうな、と素直に思うけれど、自分向けになにかをカスタマイズすることにあまり熱を感じなくなっていて、すでにあるよいと分かっているものに自分を調整していくことを選ぶようになってきた。 とはいえ身体はVimに慣れきってるのでVSCodeを使い始めたときはVSCodeVimを使っている……いた、というのが今回の話。よくできてるとは思うが、とにかくu（アンドゥ）の挙動が本家と違うのがどうも身体に合わない。逆にストレスが高まっ
なぜプレゼンで失敗するのか - 詩と創作・思索のひろば
自分も大方の人間と同じように人前で喋るのは苦手で、可能であれば避けたいと思っているけれど、一方でこの業界で生きのこる方法のひとつとして避けられないものでもあると思っている（ので苦しい）。若かりしころ手痛い失敗をしたこともあって、かなり苦手意識を持ちつづけていたが、最近はわりかし上手く付き合えるようになってきたかなとふり返って思う。 今もうまいプレゼンテーションをする方法は知らないし、それを僕から知りたいという人はいないとおもうが、プレゼンでしくじる方法なら経験から知っている。準備をしないこと。自分の経験からはそうだし、まずいプレゼンを見ていてもそうなんだろうな、と思うことはやっぱり多い。 このエントリはプレゼンがいやでいやで仕方がなかった自分のための分析であり、プレゼンのマイナスレベルをゼロまで引き上げようとする努力です。ソフトウェアエンジニアの技術者間交流のためのプレゼンというのが前提。
はてなの3代目CTOに就任しました - 詩と創作・思索のひろば
はてな退職の辞 - stanaka's blog にある通り、id:stanaka の引退に伴い、2016年8月1日付で私の勤務する株式会社はてなのCTOに就任いたしました。初代のはてなCTOが id:naoya でしたので、3代目のCTOということになります。 はてなで働きはじめたのは2006年、アルバイトの学生としてでした。まだはてなの本社が東京にあったころの話です。もともとはてなはユーザとして使っていて、すごいエンジニアが面白いものを作っている憧れの会社だったのを覚えています。入社すると社内で使っているグループウェア（はてなグループ）のメンバーにしてもらいましたが、そのグループ日記やキーワードにそれまでのはてなのサービスづくりにまつわる議論ほかもろもろのログが残っていて、全てにアクセスすることができたのは印象に強く残る経験でした。 はてなが京都に本社を移転した2008年より正社員とし
git commit --fixup とは何か - 詩と創作・思索のひろば
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 から入って
2015年に作ったもの20点（セルフレビューつき） - 詩と創作・思索のひろば
いちおう振り返っておかないと 2016 年を迎えられないという心持ちになったので、全部ではないけど列挙する。また、作ってブログに書いたけど自分では使ってません、というのも無責任なので、現在自分で利用中かどうかも添える。 go-typeswitch-gen (Go、コマンドラインツール) Pocket Expose（Go、ウェブサービス） gore（Go、コマンドラインツール） goquickfix（Go、コマンドラインツール） lgtm.sh（シェルスクリプト） hub-pr（Go、コマンドラインツール） go-cli（Go、ライブラリ） google-apps-script.d.ts（TypeScript、型定義ファイル） Mackerel API でホスト名を補完（いろいろ） gobump（Go、コマンドラインツール） Goの簡易ベンダリングシェルスクリプト（シェルスクリプト） go-
Go のシンプルかつ明快な SQL クエリビルダ go-sqlf - 詩と創作・思索のひろば
Go でリレーショナルデータベースを利用したアプリケーションを書いているとき、動的に SQL を組み立てたい場合には、いくつかの方法が考えられます: クエリビルダを使う。世の中にすでにいろいろ存在します。（そのためのライブラリなので）動的に生成するにはもってこいですが、この場合、それぞれのライブラリに合わせた書き方をしなければならないので読み手にもある程度負荷がある点、また、Go は言語として冗長に書くことをよしとする思想を持っているため、DSL 的な API との相性が悪いという欠点があります（map の組み立てが冗長、条件分岐する式が書けないなど）。また、一般にクエリビルダから生成される SQL がコードから想像しづらくなる問題もあります。 文字列連結や fmt.Sprintf を使う。発行される SQL は比較的分かりやすくなりますが、動的に組み立てると SQL プレースホルダとバイ
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
秒速でLGTMするコマンド - 詩と創作・思索のひろば
LGTM するときはよさげなアニメーション GIF を探し出してきて lgtm.herokuapp.com にかけるのがデファクト[要出典]だけどこの「よさげなアニメーション GIF を探し出す」というのがくせ者で、大量のアニメーション GIF をブラウザで開くと CPU パワーを浪費するし選択にかける人的な労力もばかにならない。エコではない。そこで Tumblr のランダムな画像を LGTM 化するコマンドラインツールを書いた。その名も lgtm.sh だ。Tumblr には /random というエンドポイントがあるのでこれを利用して特定の Tumblr ブログ群からランダムに画像 URL を得ている。 ./lgtm.sh -m | pbcopy -m オプションをつけると Markdown フォーマットで出力する。つけない場合は画像 URL のみ。 /random へのアクセスには少
コード補完もできる Go の REPL「gore」を作った - 詩と創作・思索のひろば
タイトルの通りです。Go は LL 的に使える、とはよく申しますが、そういう意識で使っていると REPL 的なことをしたいときに困りがちですよね。そこで作りました。gore。いい名前ですね。 motemen/gore · GitHub 以下のスクリーンキャストでだいたいの雰囲気をお察し下さい。 （スクリーンキャストは cho45/KeyCast を使って撮影しました） 特徴 gore の特徴は以下の通りです。 ラインエディタと履歴 複数行入力 パッケージのインポート、補完つき 式および文を実行可能 コード補完（nsf/gocode を利用） プリティプリント（k0kubun/pp か davecgh/go-spew がおすすめ） ドキュメントも引ける（godoc が必要） 以上のように、非常に便利なものになっております。むしろこの程度 REPL には当然あってほしい機能だとも言える。 イン
Pocket の未読フィードを秘密の URL で公開するウェブサービスを作った - 詩と創作・思索のひろば
Pocket はあとで読むサービスで、とりあえずの URL を放り込むところとして使っているんだけど、これをほかのサービスとうまく連携しようとすると、IFTTT に対応していないところでは意外と面倒なときがある。今回は未読アイテムのフィードが欲しかった。 Pocket には RSS フィード形式で未読リストにアクセスできる機能がある（ヘルプ）のだけど、これは http://getpocket.com/users/username/feed/unread という URL に Basic 認証でアカウント名とパスワードを入力させるという形であったので、うーん……ちょっと使いたくない。認証を解除して全公開することも選べるが、自分がリストに何を入れているか知ってほしいわけでもない。こういう時はリセット可能な秘密の URL を作ってくれれば取り扱いしやすいだろ、というわけで作った。Pocket の
Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする - 詩と創作・思索のひろば
ghq をメンテナンスするにあたっていくつか無料の CI サービスを試してみたのですが、今回は Wercker を使うことにしました。いろいろ試行錯誤した結果表題のことがなんとか実現できた（ghq のリリースは GitHub 上 にあります）ので、ハマりポイントと共にこのエントリで紹介します。 Wercker Wercker は CI サービスのひとつで、ビルド環境やデプロイの 1 ステップを box および step という形でユーザが公開・共有し、それらを組み合わせることで CI の設定をシンプルにしようとしているところが特徴です。 ghq の wercker.yml を見てもらえばだいたい雰囲気は分かると思いますが、大まかに言って “box”, “build”, “deploy” の 3 項目をプロジェクトごとに設定します。 box はビルドが走る環境です。OS や、テストに必要なパ
ソースに一行追加するだけですべての HTTP 通信をロギングするモジュールを書いた #golang - 詩と創作・思索のひろば
こちらです。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
GitHub と CI を連携してる人にオススメの userscript: PR Build Status in Favicon - 詩と創作・思索のひろば
GitHub を使って Pull Request ベースで仕事しているとこんなことがありますよね…… ( ^o^) LGTM もらった！:sushi: ( ˘⊖˘) 。o(CI 通ったらマージしよう) |花金|┗(☋｀ )┓三 ( ◠‿◠ )☛ マージしてから帰れよ ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂ 忘れてたああああああ Issue/PR のタブを開きすぎて、自分のにしろ他人のにしろ何がどこにあってステータスがわからなくなってしまうという問題もありますね。 そんなときに便利なユーザースクリプトがこちら。 GitHub PR Build Status in Favicon chrome://extensions に放り込むなどしてインストールすると、ビルドステータスが設定されている Pull Request（例）では、Favicon の右下にそのステータス（最新コミットのもの）を表す色
git-browse-remote 0.1.0 を公開しました & Vim からいい感じに GitHub を開く - 詩と創作・思索のひろば
git-browse-remote | RubyGems.org | your community gem host git-browse-remote は、コマンドラインからいい感じに（リビジョンを指定したりファイルを指定したり）リポジトリのウェブサイトを開いてくれるツールです。 入れていた変更でまだ RubyGems に上げてなかったぶんをリリースしただけなんですが……。今回の変更で行番号（-L）に範囲が指定できるようになりました。 % git browse-remote -L 5,10 -- README.md で https://github.com/motemen/git-browse-remote/blob/master/README.md#L5-10 を開いてくれます。--stdout を指定すれば標準出力に URL を書き出すだけ、ってこともできます。 おまけで便利な Vi
ページのドメインによって Favicon の色を変えられる Chrome 拡張を作りました - 詩と創作・思索のひろば
ウェブ開発者の皆さまにおかれましては、少なくとも本番環境・開発環境の2種類に常に接していると思いますが、ブラウザで両方を開いているような場合にこの区別をつけることが難しい。この問題には、環境によって Favicon の色を変えるという手法が有効であると知られています。たいてい実装は難しくないとはいえ面倒なことに変わりはないし、GitHub と GitHub:Enterprise のように直接手を入れることができないようなものもある。そこで Chrome 拡張によってこれを実現しようというものです。 Chrome Web Store - Flavoured Favicon https://github.com/motemen/chrome-Flavoured-Favicon 設定するにはオプションに JSON を直接書く必要がある（手抜き）のですが、単純なので難しくはないはずです。特定のドメ
Dockerfile を元にコンテナを走らせてローカルにポートを割り当てるところまでを自動化 (boot2docker のラッパ) - 詩と創作・思索のひろば
……というのを書いてみた。boot2docker によって OSX でもかなり簡単に Docker が使えるようになり、開発に必要なミドルウェアを用意する助けになってくれるけれど、いちいち -p オプションでポート番号を指定するまでもなく、ミドルウェア（コンテナ）によって決まったポートが割り当てられていれば十分、ということもよくある。 そこでこの forward2docker。 以下のようにすると、Dockerfile からイメージを作成し、走らせて、EXPOSE されているポート番号 + 10000 番を割り当てて待ち受けてくれる。 % curl -LO https://raw.github.com/motemen/forward2docker/master/forward2docker % chmod +x forward2docker % ./forward2docker path/
Shipped ARGV::JSON 0.01 - 詩と創作・思索のひろば
English entry is here. ARGV::JSON というモジュールをリリースいたしました。Perl では <> という特殊な演算子で、プログラム引数として与えられたファイルやら標準入力やらをよしなに読み込むことができます（デフォルトだと行ごと）が、この ARGV::JSON を use しておくと、<> から 1 行読み込む代わりに、パースされた JSON データが返ってくるようになります。 実例を見ると明らかでしょう: % curl -s https://api.github.com/users/motemen | perl -MARGV::JSON -E 'say <>->{blog}' http://motemen.github.io/ jq のようなことが Perl でもできますね！ perl のワンライナーで便利な -n や -p といったオプションも <> を
はてなブログについた訂正コメントを適用する JavaScript パーツ - 詩と創作・思索のひろば
記事に typo があったとき、見知らぬ人に「s/荻原雪歩/萩原雪歩/」などといったコメントを書き残されることがありますが、それをいちいち適用するのも面倒なので、そのような形の訂正コメントをそのまま記事本文に適用するスクリプトを書きました。この記事でも有効になっています（何が起きるのか分からないと思うので、下部の「例文」をご覧ください）。 設置方法 デザイン編集画面 の「フッタ」部など HTML が書けるところに、以下の内容を貼り付けるだけでインストール完了です。 <script src="http://motemen.github.io/hatenablog-scripts/auto-apply-correction-comments/auto-apply-correction-comments.js"></script> 場所はこのへんですね。 リポジトリ https://github
いい感じに出力をインデントしてくれるモジュール #perl - 詩と創作・思索のひろば
[2013-11-20: Print::IndentedがCPANになくてしょんぼりしている。 とのことで shipit いたしました。 あざーす！] 過去のよく分からないコードの挙動を把握したいときには print (warn) するのが少なくともとりあえずの方法としては常套手段ですが、これがただ平坦に画面に現れるだけだと見づらい。例えば条件分岐やループの中にいる時は出力をインデントするようにすると動きが掴みやすくなるけれど、ただでさえ人間に単純労働を課す print デバッグにそこまで労力を使うのは辛い。そういう面倒さを減らそうという動機で、このモジュールは書かれました。 https://github.com/motemen/perl5-Print-Indented 一体何をするのかというと今書いた通りですが、print 時に、その print 関数の呼び出しコードのインデントに応じて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
