Rails: コードの自動生成を抑止する

rails g controller hoge indexとかをすると、controllerとviewのソースなどを自動生成してくれるんですが、rspecのコードも自動生成されます。
自分の場合はmodelやhelperのテストはrspecで書きたいのですが、controllerやviewのテストはSteakで行ないたいなぁと思っているので(要は受け入れテストでいい)、rspecのそれらの要らないコードは自動生成されんでいいのです。その設定はどうするんだろうか?とツイートしたら、config.generatorsで設定するらしいということを聞きました。

まずはダメなパターン。
参考にしたページ: Customizing Generators in Rails 3
config/application.rbで以下のように設定しました。
g.test_frameworkのところで、:views => falseなどにしています。ぐぐったらよく見たのは、こう書けって書いてあったのですが、書いてもダメでした。

config.generators do |g|
  g.orm :active_record
  g.test_framework :rspec, :views => false, :controller => false, :fixture => true, :fixture_replacement => :factory_girl
  g.stylesheets false
  g.javascripts false
end

次に成功したパターン。
参考にしたページ: How can I make sure Rails doesn’t generate spec tests for views and helpers?

g.view_specs falseなどの設定で抑止できました。

config.generators do |g|
  g.orm :active_record
  g.view_specs false
  g.controller_specs false
  g.test_framework :rspec, :fixture => true, :fixture_replacement => :factory_girl
  g.stylesheets false
  g.javascripts false
end

rails g controller -hしてみ?って書いてあったから、してみたらそれっぽいパラメータについて書いてありました。なるほどなぁ…。ついでにスタイルシートとJavaScriptも出ないようにしときました。

ただ、これでもまだSteakのコードが自動生成されないので、そこが自動にできたらいいのになぁと思います。方法がわからん!


第3回アジャイルサムライ読書会 IN 岡山道場

アジャイルサムライ読書会に参加してきました。
今回はファシリテーターの@mao_instantlifeさんが忙しくていない状態だったのだけれど、まぁとりあえず集まって話し合ってみよーぜというノリで開始。

まとめをやったほうがいいかなぁと思ったのでとりあえずマインドマップを作りながらやった。

クリックするとでかいのが見える。

第3章は、プロジェクトの始めが重要。最初に言いづらいことを言う。共通認識を統一する。ということが書かれていて、共通認識を統一するためのツールとしてインセプションデッキを作ろうぜ!インセプションデッキの内容については次章から紹介するぜ!という感じ。

まず集まっているメンバーに、3章を読んでどう思ったか、感じたかという質問で感想を言い合った。

  • 早いうちに共通認識を持つことは大事だよね
  • 共通認識がずれていたら、責任を逃れるためか、お客さんのいいなりになりがち。結果として、変なシステムができやすい(お客さんがITの活かし方をわかってないことが多いから)
  • そこで、インセプションデッキですよ!共通認識をお客さんと交えてできたらイイね!
  • そうなんだけど、プロジェクトに後から放り込まれることが多くてねー…
  • そもそも最初からプロジェクトに参加したいのに出れないことが多い

お客さんについて。

  • バスに乗らない…(第3章のタイトルが「みんなをバスに乗せる」なので)
  • お客さんが一番、銀の弾丸を求めている
  • 仕事が楽になればなんでもいい
  • IT化を求めているのかどうなのか…(結局、紙文化だったりするから)

ではお客さんとの認識を合わせるために今までやってきたことは?

  • 会議
  • メーリングリスト
  • キックオフミーティング
  • スカイプ

でも本来のお客さんと直接話ができる機会が少なかったりしたので、なかなかうまくいかないという印象(下請けが多いから?)そこで話は、なんで日本のIT業界は下請け構造が深いのか?という話に飛んだり。

ここらへんからやっぱりデスマトークっぽくなっていったw

  • 腹を割って話せてそれを受け入れるお客さんはいるのか?
  • そういう交友関係を築いていくにはどうすればいいのか?

まぁこちらも腹を割って話せよということだよなぁと。ただそれを聞いて激怒するような人が偉い人だったりするからなぁという話にもなった。難しいですなぁ〜。

インセプションデッキ自体はとてもいいツールだし、プロジェクトに途中からメンバーが加わった時にも役にたつ。なかなか作る機会がないから実際の現場で活かせることが難しいので、練習したいね。
コミュニティー運営用のインセプションデッキを作ってみては?とか、インセプションデッキハンズオンをやってみるとかしてみたいねーという感じで終わった。

インセプションデッキハンズオンとかは、プロジェクトリーダークラスの人を交えてできればすごいいいんじゃないのかなーと思う。

今回は人数が5人だったので10人くらいでやってみたいなぁ。次回も楽しみだー。

【送料無料】アジャイルサムライ

【送料無料】アジャイルサムライ
価格:2,730円(税込、送料別)


社内LT会をやった

社内というかチーム内LT会だけど、昼休憩に行なわれた。
最近、個人活動をしてないので、何を発表するのかを微妙に悩んだのだが、結局ブログに書いていたrepoの内容の焼き直しみたいな感じにした。が、自分でもまぁ微妙だなと思った。

LTはあくまで軽い話でIT業界版の深いい話みたいなもんだと思う。
他の人の発表はそれぞれの属性が活かせた「ほう」と思える内容だったので、もし自分が次回以降やるとしたら、「俺が読んでタメになった本を5分で紹介」とかそういうのがいいのかもしれないと思った。ネタがある場合は他のもやっていこうと思うけれども。


Android: gitからクローンしてJenkinsでテスト

これまでのあらすじ。
VPSでJenkinsを使ってAndroidのテストの自動化を図ろうとしたパトさん。しかし、いきなり外部環境かつローカルでも成功させていなかったテストがうまくいかなかったので、まずはMacのローカル環境でテストが成功するのを試しているのだった。

今までの記事。

  1. Android: Antでテストを実行する
  2. Android: MacのローカルでJenkins使ってテスト

次にやってみるのは、やはりというか、ソース管理ツールからcloneしてのビルド。特に、Androidのテストの場合はプロジェクトが2つあるので、2つのプロジェクトをcloneする必要がある。

参考にしたサイトは以下。
Jenkinsで1つのジョブで複数のGitリポジトリをビルドする方法

参考サイトに書いてある通り、gitプラグインだけだとうまくいかない?2つのリポジトリ(アプリとテストの)を指定したら、指定ディレクトリに両方ともcloneしようとしてエラーになって落ちた。

ということで、作業一覧。

  1. Jenkinsの管理より、プラグインの管理へ。Git PluginとMultiple SCMs Pluginをインストールする
  2. 設定より、ソースコード管理システムからMultiple SCMsを選択する
  3. gitリポジトリを2つ追加する(アプリとテスト)
  4. リポジトリ毎に『高度な設定』ボタンが2つあるが、下のほうの『高度な設定』ボタンを押す
  5. Local subdirectory for repoに、cloneするディレクトリ名を入力する
  6. Unique SCM nameに、ユニークな名前を付ける(私はgit1, git2と付けた)
  7. それ以外はほぼ前回と変わらず。ビルドの項目にて、ビルド手順の追加から、シェルの実行を選択。cloneされたディレクトリを対象にプロジェクトのアップデートを行なう。
    cd /Users/hoge/Documents/workspace/helloandroid
    /Applications/android-sdk-mac_86/tools/android update project -p .
    cd ../helloandroidtest
    /Applications/android-sdk-mac_86/tools/android update test-project -m ../helloandroid -p .
  8. ビルド手順の追加からAntの呼び出しを選択する。
    ターゲットにclean debug install testと入力。
    高度な設定を押して、ビルドファイルを指定する。ここでは、
    /Users/hoge/Documents/workspace/helloandroidtest/build.xml
    となる。
  9. 保存する。
  10. ビルドを実行してテストが通っていれば成功!

肝はなんといってもMultiple SCMs Plugin。Androidのように複数のプロジェクトを使ってテストをするような場合に重宝するのではないでしょうか?Unique SCM nameが重要っぽいので、ここはちゃんと個別の名前にするようにしましょう。普通にリポジトリ名でもよい気がする。

オマケ情報。
私はBitBucketにサンプルのAndroudプロジェクトを置いて試しているのですが、BitBucketにSSH用の公開鍵(id_rsa.pub)を登録していたのですが、コマンドラインからだとcloneできるのに、Jenkins経由だと、なぜかcloneできず。

Jenkinsのユーザも自分のユーザ名にしているにも関わらず、cloneできないので、不思議に思っていたのですが、id_dsa.pubをBitBucketに登録したところ、なぜかJenkisからもcloneできるようになりました。なんでかはわかりません。詳しく調べようとあんまり思わなかったので、この問題はここまで。


Android: MacのローカルでJenkins使ってテスト

前回の状態でAntを使ってテストをするところまで出来たので、次はローカル環境のJenkinsでAndroidプロジェクトのテストを行なえるようにしようと思う。

  1. まず、Jenkinsのサイトより、MacOS X用のパッケージをダウンロードする。
  2. Jenkinsをインストールする。インストール成功すると、http://localhost:8080でJenkinsにアクセスできるようになる。
  3. Jenkinsの実行ユーザとグループがdaemonになっているので、それを普段使っているアカウントとグループに変更する。理由としては、
    • Android SDKのアクセス権限が770のため、グループがstaffじゃないとアクセスできない
    • 自分が作ったAVDを使いたいが、AVDは自分のホームディレクトリの.android以下に保存されるから

    である。

    sudo vi /Library/LaunchDaemons/org.jenkins-ci.plist
    

    GroupNameをstaff, UserNameを自分のユーザ名にする。

  4. Jenkinsのホームディレクトリの持ち主を、自分のユーザにしておく必要があるので変更。
    hogeはユーザ名に変更すること。

    sudo chown -R hoge:staff /Users/Shared/Jenkins/Home
    
  5. Jenkinsを再起動する。こうするらしい。
    sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
    sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
    
  6. Jenkinsにアクセスして、Jenkinsの管理 > プラグインの管理 より、Android Emulator Pluginをインストールして、Jenkinsを再起動する。
  7. Jenkinsの管理 > システムの設定 より、
    1. Androidの項目で、Android SDK rootに、Android SDKのディレクトリを指定する
    2. JDKの項目を設定する。自動インストールのチェックを外し、JAVA_HOMEを設定する。私の場合は /Library/Java/Home を設定した。
    3. Antの項目を設定する。自動インストールにチェックする。

    そして、保存する。

ここまでが、MacのJenkinsでAndroidプロジェクトを動かすために必要な設定である。

次に、Jenkinsにジョブを登録する。登録するジョブは、もちろんAndroidプロジェクトをテストするためのものである。

  1. 新規ジョブ作成を押す。ジョブ名は適当に。フリースタイル・プロジェクトのビルドを選択する。
  2. ビルド環境の項目で、
    1. Run an Android emulator during buildにチェックを入れる
    2. Run existing emulatorを選択し、既に作成済みのAVD名を入力する
    3. Common emulator optionsで、Show emulator windowのチェックを外す(ご自由に)
  3. ビルドの項目を設定する。
    1. ビルド手順の追加より、シェルの実行を選択する。
      Androidプロジェクトのアップデート用のシェルスクリプトを書く。
      ユーザー名がhogeで、Android SDKかApplications以下に置いてあるとする。

      cd /Users/hoge/Documents/workspace/HelloAndroid
      /Applications/android-sdk-mac_86/tools/android update project -p .
      cd ../HelloAndroidTest
      /Applications/android-sdk-mac_86/tools/android update test-project -m ../HelloAndroid -p .
      
    2. 次に、Antの呼び出しを選択する。
      ターゲットに、clean debug install testを入力する。
      高度な設定ボタンを押し、ビルドファイルをAndroidのテストプロジェクトのbuildファイルを設定する。
      /Users/hoge/Documents/workspace/HelloAndroidTest/build.xml
  4. 保存する。
  5. ビルド実行する。
  6. 成功するはず。(してなかったらコンソールログを見ながら原因を探る)

今のところは、これでテストはJenkinsでできるようになった。
次の方向性は後日考える。