RubyMine に Homebrew でインストールした rbenv を認識させる方法

rbenvは今のところ以下の2パターンでインストールすることができます。

  • $HOME 以下に直接インストール
  • Homebrew でインストール

違いは、Homebrew でインストールすると ~/.rbenv ではなく /usr/local/var/rbenv に入るところ。
普通はこの違いで困ることはないんですが、RubyMine使ってるとちょっと困ります。

問題点

RubyMineは現時点だと残念なことに ~/.rbenv にしか対応してません。 (参考:Rbenv Support)

RubyMine supports rbenv Ruby interpreters installed in the default rbenv folder ~/.rbenv only.

対応してないとはいえ、手動で追加してやれば動くんですがめんどくさい。

とはいえ、せっかくパッケージ管理システムたる Homebrew 入れてるのに rbenv だけ手動管理するのは嫌です。
というわけで、Homebrew でインストールした rbenv を RubyMine にさくっと認識させてみました。

解決方法

% ln -s /usr/local/var/rbenv ~/.rbenv

みんな思いつくと思うんですがこれだけでOK。
これでばっちり RubyMine が rbenv で管理してる ruby を検出してくれます。

git の push.default の設定値と、ブランチの指定がない push には注意

git で master ブランチを壊すという類まれなる酷い事をやらかしたので、備忘録がてら以下の内容をまとめ。

  • 何をやらかしたのか
  • どうしてそうなったのか
  • どうすれば防げたのか

push.default とか初めて知った・・・ orz

1, 何をやらかしたのか

作業用ブランチでマージ作業をしてたんですが、その際に以下のコマンドで master ブランチをぶっ壊しました。

 $ git push -f

ぶっ壊した際の状況は以下のとおり。

  • local の master ブランチは push 出来ない状態(originと差異がある上にマトモな状態ではない)
  • 現在 checkout されているのは作業用ブランチであり master ではない
  • 作業用ブランチでは rebase を行なっており、push するには -f せざるをえない状態

2, どうしてそうなったのか

git では push 時の動作を決める push.default という設定項目があり、デフォルトでは以下の設定になっています。

matching

そして、これは以下のように振る舞います。

push all branches having the same name in both ends.

・・・・はい、どぼんですね。
詳しくは https://github.com/git/git/blob/master/Documentation/config.txt を参照して下さい。

つまり、現在 checkout してるのがどんなブランチであれ、local と origin の両方に存在していて差分があれば push されちゃうのが現状(1.8)のデフォルト値です。
そして救えない事に今回は -f しちゃったんですよねー。
そういうわけで、マトモな状態ではない master が force で push されるという惨劇をやらかしてしまいました。

3, どうすれば防げたのか

色々ポカミスが重なってやらかしたんですが、やらかした後に色々話したり自分で調べたりして出たのが以下の様な内容ですね。

  • local の master ブランチを壊した状態で放置しない
  • push する際にはブランチを明示する
  • -f せざるを得なくなる rebase を避ける
  • rebase したい場合は fork して別レポジトリにする事で、やらかしても被害を最小限に食い止める
  • push.default を simple にしておく
  • などなど・・・

ちなみにですが、local の master ブランチがぶっ壊れてたのは、マージ作業する際に間違えて作業用ブランチではなく master ブランチで作業したりしちゃったせいです。
後で rollback すればいいか、と思ってそのままにしちゃったのが駄目でしたね。
あと、今回は壊した事にそもそも気づけてないという駄目っぷりも発揮したので、git 力を上げるべく精進することにします。 o...rz

RubyMine で Spork + RSpec + SimpleCov の環境を作る方法

RubyMine はデフォで RSpec のサポートがあるのがさすがですね。
これで IdeaVIM がもうちっとまともに動けば文句ないんですけど・・・
そんな RubyMine で Spork + RSpec + SimpleCov の環境を作る方法の備忘録です。
最初は RCov 使おうと思ってたんですが、github のページみたら

This fork does not work on Ruby 1.9.x. For coverage on Ruby 1.9 look at SimpleCov.

とか書いてあったので SimpleCov にしました。

試した環境

Ruby 1.9.3
Rails 3.2.8

RSpec の導入

https://github.com/rspec/rspec-rails

の通りに導入。

Spork の導入

https://github.com/sporkrb/spork

の通りに導入。

SimpleCov の導入

https://github.com/colszowka/simplecov

の通りに導入後、Sporkの為のワークアラウンドを以下のURL通りに行う。

https://github.com/colszowka/simplecov/issues/42#issuecomment-4440284

テストカバレッジの測定

RubyMine の

Run with Coverage

でテストを実行すればOK。
実行が終わるとテスト全体の統計情報が表示され、エディタ上にもカバレッジ情報が反映されます。

Haml の Filter に #{} で値を渡す場合は XSS に注意

Haml は便利ですねー。 正直最初は なんじゃこりゃ? って思ってたんですが、一度慣れちゃうと二度と素の HTML を書く気が起きないレベルで気に入りました。
今回は Rails の勉強がてら Haml を使っていて、うっかり XSS できちゃう穴が空いてたのでそのまとめです。

使ってる gem のバージョン

Rails 3.2.8
Haml 3.1.7

XSS が行えるパターン

Haml の Filter に #{@entry.body} といった形で値を渡している場合。
(※ @entry.body が既にサニタイズされていれば問題ありません)

僕は @entry.body がサニタイズされていない状況で、以下の形でやらかしてました。

:markdown
  #{@entry.body}

Haml で普通に #{} する分にはサニタイズされていたので、すっかり油断してました。

XSS が行える原因

Haml のドキュメントにまんま書いてありました o...rz

Currently, filters ignore the :escape_html option. This means that #{} interpolation within filters is never HTML-escaped.

参考:http://haml.info/docs/yardoc/file.REFERENCE.html#filters

解決策

Haml の Filter に #{} で値を渡す場合は h メソッド経由にする。

:markdown
  #{h @entry.body}

これでXSSは行えなくなります。

なんとなく残った疑問

というか、なんで Filter は :espace_html オプションを無視するんでしょうね?
デフォルトは有効で、オプションを指定したら無視の方がいい気がするんですけども・・・
デフォルトで無視しないと困るような状況が何かあるんだろうか。。。

テスト実行時に Unable to attach test reporter to test framework or test framework quit unexpectedly って言われた際の対処法

Rails系のテストでもちゃんと結果みれるんだ!ってワクワクしながら実行した結果が以下のエラー o...rz

" Unable to attach test reporter to test framework or test framework quit unexpectedly "

RubyMineのコンソール上にはテキストで結果でてるんで困りはしないんですが、せっかくならUI上で見れたほうが便利なので直します。

直し方

http://www.jetbrains.com/ruby/webhelp/minitest.html

ここの Prerequisites をひと通り実行すればOK。 これでUI上からテスト結果が見れるようになります。

情報源

http://youtrack.jetbrains.com/issue/RUBY-11537

Windows 7 で Ruby 1.9.3 と Rails 3.2.8 をインストールする方法

あんまり Windows 環境でのインストール方法とかハマリポイントがまとまってない感じがしたのでまとめ。
とはいえ Ruby やるなら MacOSXLinux でやったほうがいい気がしてきてる今日この頃。
Mac に TrackPoint つかないかなぁ・・・

注意事項

Ruby 1.9.3 を入れた際にはいってる Gems 1.8.23 は SSL 周りでバグがあるので、そのままだと Rails を入れた後に

> rails new

しても以下の様なエラーが出てしまい Bundler の実行でこけます。

Gem::RemoteFetcher::FetchError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/gems/rake-0.9.2.2.gem)

その為、Gems を 1.8.24 にアップデートするのが何よりも重要なポイントです。
詳しくはこちら:1.8.23 actually does not install pem file · Issue #320 · rubygems/rubygems · GitHub

1, Ruby 本体のインストール

Windows 環境で Ruby 入れるなら RubyInstaller が良いらしいのでそれを使います。
確かに Ruby 単体で入れて、OpenSSL 入れて・・・とかやらないでいいので非常に便利。

RubyInstaller for Windows

上記 URL から 1.9.3 をダウンロードしてきてインストール。
インストールが完了したら以下のコマンドで動作確認。

> ruby -v
ruby 1.9.3p194 (2012-04-20) [i386-mingw32]

2, DEVELOPMENT KIT のインストール

json の gem をインストールする際とかに必要になるのでこっちもインストール。
インストール方法は下記を参照。

Development Kit · oneclick/rubyinstaller Wiki · GitHub

3, Gems のアップデート

これ忘れるとバグに引っかかって悲しい思いをするので注意。

> gem update --system

アップデートが終わった後に以下のバージョンになってればOK。

> gem -v
1.8.24

4, Rails 3.2.8 のインストール

> gem install rails --version=3.2.8

結構時間かかるのでまったり待つ。
インストールが完了したら下記コマンドで確認。

> rails -v
Rails 3.2.8

5, 最後に rails new が出来るか確認

> rails new hoge

これがこけなければ最低限度の環境はOK。

Maven 2系からMaven 3系に移行した際に、Mojoで意図したcompileClasspathElementsやtestClasspathElementsが取得出来ない場合の解決方法

Maven 2系から3系への乗り換えで一部Mojoが正常に動かずに超絶ハマったのでメモ。

発生する問題

Maven 2系列の場合、例えば compile フェーズであれば (特に指定していなければ)compileClasspathElements で以下のような値(正確にはList)が取れます。

[module]\target\classes, [関連するjar]

しかしながら、Maven 3系列では以下のような値しか取れません。

[module]\target\classes

解決策

MojoのJavadocにrequiresDependencyResolutionアノテーションを指定する。


最新のMojo api specificationのThe Descriptor and Annotationsを見てみると、requiresDependencyResolutionアノテーションの説明が昔に比べて増えた事がわかります。
(参考までに、2009年6月28日時点での説明)
説明を見てみると

If the annotation is not present at all, the mojo must not make any assumptions about the artifacts associated with a Maven project.

なんて書いてあります。
アーティファクトに関係するものまでclasspathに含めたければ、指定しないといけなくなったっぽいですね。