http://rubygems.org/gems/ghn/versions/2.0.0.pre2
ChangeLog:
Thank you reporting, @hamaco san!
ghn v2.0.0.pre2 をリリースしました。未知の type をもつ notification を処理するとき例外が発生する問題を修正しました。 @hamaco さんご指摘ありがとうございました。
I've released ghn v2.0.0.pre1. v2.0.0 have some backwards incompatible changes.
ghn open command (--open options is removed)--all option to list/open all unread notifications--mark-as-read optionYou can install v2.0.0.pre1 by $ gem install --pre ghn.
I'm going to release v2.0.0 within a few days. If you have any problems/questions, feel free to open issue https://github.com/kyanny/ghn/issues.
ghn v2.0.0.pre1 をリリースしました。 v2.0.0 はいくつかの後方互換性のない変更を含む予定です。
ghn open サブコマンドを追加 (--open オプションは廃止)--all オプションを追加
--all オプションつきだと内部でページングして未読の通知を全て開きます--mark-as-read オプションを廃止v2.0.0.pre1 を試してみたい方は $ gem install --pre ghn でインストール可能です。
自分で数日使ってみて特に問題なければ v2.0.0 をリリースするつもりです。もし何か問題や要望等ありましたらお気軽に https://github.com/kyanny/ghn/issues までご連絡ください。
余談。この期に前から気になっていた内部の刷新も合わせてやった（というほど元々コード多くなかったけど）。
こういう感じの理由 が当時わかってなくて octokit ダメなのかと思って github_api を使っていたのをやめて octokit にした（どうも sawyer 側でなおったらしい）。あと何をトチ狂ったか自前でサブコマンドやオプションを処理してたのを thor 使うようにした。
GitHub API v3 は多くのエンドポイントでページネーションをサポートしていて、 octokit には auto_paginate = true にすると内部で全ページなめてくれる便利機能がある。しかし Notification API はこれが効かず、なんでだろうとおもったら Notifications API のレスポンスヘッダには Link ヘッダがない。 octokit は Link ヘッダの中身をみてページ情報を得ているのでダメだった、という。
仕方ないので諦めようかと思ったけど、未読が多いときほどコマンド一発で全部開けない、というのが普段使ってて一番の不満点だったのでどうにかしたくてこんな風にしてみた。
あとエイリアス。これも普段使ってて長い NAME を毎度入れるのが面倒くさかったのでぜひ入れたかった機能。マッピング情報の保存場所が思いつかずにお蔵入りにしてたけど、突如 .gitconfig に入れることを思いついてあっさり解決した。たぶん ghq とかでみたのをぼんやり覚えてたのかもしれない。
TL;DR ウィンドウ幅の情報はセッションクッキーに保存されているのでブラウザを再起動すればなおる。
このひとのツイートとリンク先読んで解決した。最近ブラウザは常時起動しっぱなしなので再起動という発想がなかった。クッキー削除も（再起動せず開発ツールから）試してみたけど効果がなく、詰んだかと焦ったところだったので助かった。
@jsfiddle fixed it (w/ unnecessary effort). Maybe just (but I never) restart browser? You could check values tho; http://t.co/hYZ4Ug0CId
— toddkaufmann (@toddkaufmann) April 23, 2013[JavaScript] Fix jsfiddle window config when draggable bars are gone - Pastebin.com http://pastebin.com/rBMHfvqV
I am honored to be a speaker of RubyKaigi 2014!
RubyKaigi 2014, 18-20 september
昨年 に引き続き、光栄にも RubyKaigi 2014 にスピーカーとして登壇することになりました。今回も bundle update 周辺の話題です。一年経って自分の中の問題意識がどのように変化し、新しい問題を解決するためにどのようにアプローチしたのか、という試行錯誤の過程を共有できれば、と思っています。
きっかけは些細なことだった。 Emacs で RSpec のテストケースを書いていて、全体的に動作がのろくてイライラさせられた。どうやら ruby-mode だか ruby-electric だかが悪さをしているらしいが、何年も前に .emacs.d に放り込んだもので、どんな風に設定するのかも覚えていない。最新バージョンに入れ替えてみたら、手元でちょろっとカスタマイズしていた改行時のオートインデントだか何かの挙動が変わってしまい、気になってコーディングどころではなくなった。
もともと Emacs Lisp は読むのも書くのも苦手で嫌々ながらも騙し騙し付き合ってきたが、このときばかりは心底うんざりして、もうこんな古代のツールに頼るのはやめにしよう、自分の仕事は高度に知的な作業であるはずのプログラミングであって多彩で変態的なキーボード操作を駆使してテキストを編集しまくることではない、ならばもっと仕事内容にふさわしい道具を使うべきじゃないのか—そんな風にして、乗り換えを決意した。
IDE に興味があり、この機会にチャレンジしてみようと思ったものの、細かいことばかり気になる面倒な性格のせいで IntelliJ IDEA と RubyMine のどちらを購入するべきなのかで迷い、結局どちらもお試し版すらインストールすることなく、とりあえずもうちょっとなじみやすそうなのを...と妥協して Atom.io を使い始めたのが一月半ほど前のことだっただろうか。
なぜ Sublime Text ではなく Atom なのかというと、 Atom のユーザーインタフェースのほうが多少洗練されていて気に入った、というのがひとつ。そしてもう一つは、そもそも乗り換えた動機が「なるべくカスタマイズに労力をかけたくない」だったので、パッケージ管理の仕組みがデフォルトで提供されている Atom を選ぶほうが理にかなっている、と思ったからだ。
それから一ヶ月ほど、いくつかのパッケージを試したりやめたりしつつ、 Emacs に慣れきった両手の指で真新しいキーバインドをたどたどしく練習しつつ、仕事でもプライベートでも Emacs を一切起動することなくコードや文章を書いてみて、最終的にこれは無理だと観念して Emacs に出戻った。
Atom を使っていてどうしても我慢がならなかったこと。それは、一つのウィンドウで一つのディレクトリ配下のツリーしか開けないことだ。
仕事で扱うリポジトリは複数あり、しかも相互に行き来してコードリーディングをしながらの作業が頻繁に発生するため、 Atom のこの仕様は自分のユースケースとはとても相性が悪かった。上記のスクリーンショットでいうと、 mongomapper と plucky のファイルは頻繁に相互に見比べたいので、ウィンドウごと切り替えていたのでは手間がかかりすぎる。右側のウィンドウのように親ディレクトリを対象に開けば一つのウィンドウ内で全てのファイルを開けるが、親ディレクトリ配下に数十ものディレクトリ（リポジトリ）がある場合、ノイズが多いし動作も遅くなってしまった。
他にも不満はたくさんあったが、もう一つだけ自分のユースケースと合わなかったことを挙げるなら、コマンドラインから Atom を開くときの動作の遅さにはずいぶん時間を無駄にさせられた。 Git のコミットログを書く際にいちいち Atom の起動で待たされるのには辟易した。
Atom をほんのお試しではなく、それなりに真面目に使ってみて良かったこともある。 Tree view は素の dired に比べるとずっと見やすいし、 Line diffs （いわゆる GitGutter）は地味だが想像以上に便利だった。当然これらに類似した機能は Emacs でも—そう、有志の手による拡張 Emacs Lisp パッケージとして—利用でき、出戻りのタイミングで Emacs のカスタマイズを整理しなおしたついでに Atom で経験した便利機能を Emacs のカスタマイズでも取り入れ、結果として Emacs がより便利になった。単に Emacs カスタマイズの情報収集を怠っていただけ、ともいえる。
結局いまだに RubyMine は試していないが、趣味で Java のオンライン学習コース（無料）を勉強しはじめて IDE の雄である Eclipse に触れる機会も作れるようになったことだし、ヌーに左手の小指を呪われた運命を受け入れてもう死ぬまで Emacs でいいかな...。
