helm-ghq で Searching for program: No such file or directory, ghq エラーが出るときの対処法

ghq コマンドに Emacs からパスが通っていないので、 exec-path に追加する。

(add-to-list 'exec-path "/Users/kyanny/gocode/bin")

GUI 版 Emacs.app を使っているとシェルの rc ファイルでエクスポートした環境変数が引き継がれないのでこういうことがよくある。

自分の場合 ghq は /Users/kyanny/gocode/bin/ghq にインストールされていた。環境変数 $GOPATH を $HOME/gocode にしているためと思われる。

環境によってホームディレクトリのパスや gocode の部分はかわるので、適時よみかえること。

masutaka/emacs-helm-ghq · GitHub

ghn v2.0.0 released

http://rubygems.org/gems/ghn/versions/2.0.0

ChangeLog from previous stable version:

• New Features:
  • Add open subcommand (support open(1) alternative commands at some platforms)
  • Add --all (-a) global option to list/open all unread notifications
  • Add aliases for username/reponame shot form
  • Add Follow issuecomment anchor option
• Deleted Features:
  • --open option is removed
  • --mark-as-read option is removed
• Bugfixes:
  • Support Release type notification

Thank you very much for Contributors!

---

ghn v2.0.0 をリリースしました。変更点は上記またはリリースノートをご覧ください（内容は同じです）

過去のバージョンも含め、パッチを送ってくれたりバグ報告をしてくれたコントリビューターの皆さん、ありがとうございました。

---

うっかりメジャーバージョンを 2 にあげてしまったけど、 pre リリースを除いた一番最新のリリースバージョンは v0.1.0 で、バージョン 1 を飛ばしてしまった。次に何か作るときは最初のリリースから v1.0.0 として出すようにするべきだなと思った。

今回バージョンアップするにあたって、内部のコードをごっそり書き換えた。なぜか自前でサブコマンドやコマンドラインオプションの処理をしていたのを thor を使うようにしたのと、 GitHub API クライアントを github_api から octokit に変更した。

前者は hub のようにファイル一個を配布すれば使えるようにと依存ライブラリを減らしたかった名残だ（当初は GitHub の API も net/http か open-uri を使って自前で叩いていた覚えがある）しかし自分が使うぶんには gem という配布形式で不便しないし、そういうツールも増えてきたように思う。そもそも Ruby が必要な時点で単体配布向きではないかもしれない。配布の容易さにこだわるなら Go で書くべきなのかもしれない。気が向いたら移植してみたい。

後者は sawyer が url という属性を風変わりに扱う問題への対処方法を知らずに苦肉の策で別ライブラリを採用した名残だ。公式の強みで仕事等でも octokit を使う機会は多く、わざわざ似てるけどちょっと違うものを使う意味もないと思って定番に乗り換えた。残念だったのは Octokit. auto_paginate が Notifications API ではうまく動かなかったこと（Link ヘッダが無いため） auto_paginate があれば --all オプションはすぐ実装できると思ってやり始めたので使えなくて拍子抜けだった。自前実装でとりあえずどうにかなってよかった。

Video: GoGaRuCo 2013 - Measuring Ruby by Sam Saffron and Jeff Atwood

GoGaRuCo 2013 - Measuring Ruby by Sam Saffron and Jeff Atwood - YouTube

YouTube の Watch Later に入ってたのを消化した。硬派なパフォーマンスチューニングの話。以下視聴メモ。

• Discourse のパフォーマンスチューニング、特に Ruby プログラム部分の話
• 前半でクヌースの「早すぎる最適化は悪」を引用しつつ、サイトが遅い原因の大半はフロントエンドにあると指摘
• しかしフロントエンド最適化の話はせず（おそらくそれは踏まえた上でなおサーバーサイドを限界までチューンする話、だったのだろう）
• dtrace の扱いづらさ（？自信なし）を経て rbtrace に触れる
• rack_mini_profiler の使い方に触れる、 /?pp=help とすると裏コマンドがいろいろ見られる
• memory_profiler gem を使うとメモリについて詳しいことがわかる、オブジェクトが作られた数とかそれによって消費したバイト数とか（動画内では ruby-head が必要とあるけど一年前の動画だから。 2014 年現在はふつうに最新リリース版の 2.1 系で使える）
• あと flamegraph オプションを使うとコールスタックがカラフルなグラフで見れる
• それらを踏まえてオブジェクト生成コストを減らすコーディング指南とか、常に実行可能なベンチマークコードを持っておいてライブラリの新しいバージョンに対して実行し改善や悪化を計測可能にするとか

僕はこう思ったッス

• 動画のタイトル見たとき「まさかあの Jeff Atwood なわけないよなー、同姓同名の人なんだろうけど気の毒だなー」と思ったら本人でびっくりした
• 大規模ハイトラフィックサイトにおけるハイパフォーマンス Ruby プログラミングという感じでためになった
• 個人的にパフォーマンスへの関心が薄くてベンチマークの類いにもあんまり興味が無いのだけど、技術者としてやっていく上でそれはマイナスに働きそうだなという懸念が以前からあったので、たまにこういうのをみると刺激されてよかった
• とはいえ個人的には消費メモリを節約するためにオブジェクトの属性をハッシュに詰め直す、みたいなコーディングの工夫でがんばる方向性にはやっぱり賛成できなくて、だったらもっとメモリ効率の良い、用途に適した言語で書けばいいのに、と思ってしまう（もちろん習得コストとかいろいろあるけど、必要に迫られたらできるはず）
• とはいえ遅いと言うだけよりはコードとデータで示したほうがよっぽどいいし、そういう動きがないと処理系を作る側にも伝わらないだろうから、やっぱこういうことをする人はそれはそれで偉いと思った
• script/bench.rb で Rails edge とかに対して Discourse のベンチを走らせて継続的にパフォーマンスの変化をチェックする、というのはちゃんと人柱になっててえらいなーと思った。ノブレス・オブリージュっぽさを感じた
• flamegraph というものを初めて見たけど youpy さんっぽいなと思った

Video: OSCON 2014: How Instagram.com Works; Pete Hunt

OSCON 2014: How Instagram.com Works; Pete Hunt - YouTube

YouTube で Facebook Developers チャンネルを購読してたら新着動画のお知らせメールに載ってたので視聴した。以下メモ。

• instagram.com は React を使った Single Page Application
• ユーザーエクスペリエンスを最優先した結果 SPA を選択した
• 初回ロード時間はリクエスト数 x 転送バイト数で決まるので .js/.css ファイルを一個に結合するのは良くない
• エントリポイントごとにモジュールを分けて、モジュール単位で一個に結合、 minify/gzip などすると効率が良い
• .js/.css は CommonJS の require を使って（？自信なし）ロードする。サイズの小さい画像も DataURI を require して img 要素を作る
• このような特殊なファイル読み込み手法のため CSS の読み込み順序が不定になりセレクタ名の衝突・上書きで見た目が崩れるので命名規約とかいろいろ使い方を工夫する
• ファイルの編成には browserify や grunt gulp 等ではなく、依存関係の扱いに長けた（？自信なし） webpack がオススメ。ブラウザのファイルロード・読み込み速度が 250ms -> 120ms に改善した

僕はこう思ったッス

• ブラウザパフォーマンスも考えた上でモジュールシステムを決めたりしててさすが Facebook だなと思った。 Rails とかでやってると何も考えず一個にまとめているけど、考え無しでやるだけは良くない
• 「オレは CSS が嫌いだ」には同情するけどセレクタの衝突でややこしくなったりするのは自分らがわざわざ特殊なやり方でファイル読み込みしているせいじゃん...と思った
• 「Facebook は巨大なベヒーモス」とか所々で笑いをとろうとしてるのに会場の笑い声が一切録音されてなくて気の毒だった。でも会場が広いのとマイクの集音性能が優秀なせいかもしれない
• webpack って初めて知ったなーと思ったら数ヶ月前に日本語でも紹介されていてアンテナの低さが身にしみた
• 40分枠のうちほぼ30分ぴったりに収まるトークと10分の質疑応答でほぼ40分ぴったりで終わっててすごいと思った。プレゼン慣れしてるのだろうし、準備や練習も相当してるのだろう

ghn v2.0.0.pre5 released (final v2 pre release)

I'd like to make this as a final pre release of ghn version 2.

ChangeLog:

• Add ghn.followissuecomment config and --follow-issuecomment command line option (see README)

Now "follow issuecomment anchor URL" feature is optional.

---

ghn v2.0.0.pre5 をリリースしました。これが最後の pre release になる予定です。

GitHub の Notification ページ に表示される issue や pull request へのリンクは、それが新着コメントのものだった場合 #issuecomment-XXXX という anchor つきの URL になります。 ghn もこの挙動と合わせて欲しいという要望をいただいたため 2.0.0 系の開発初期からその対応を組み込んでいましたが、自分で使っていてどうもしっくりこない気がしたので、デフォルトでは無効とし、オプションで有効にできるようにしました。