.noexec.yamlとは

いやね、RVMを使っていてGemfileに記述したrakeのバージョンではなく、システムにインストールされたrakeを使いたかったのですが、うまくいかなくて困っていました。
ひょんなことから、次のようにしてrakeを実行すると、rake実行時にRVM(というよりはrubygems-bundler)によって読み込まれる設定ファイルが分かりました。

$ NOEXEC_DEBUG=1 rake --version
  (以下、実行結果)
  Noexec
  Examining <path/to/>Gemfile
  Considering "<path/to/>.noexec.yaml"
  (...省略...)

ん!?.noexec.yamlってなに?
Googleで検索してみると、.noexec.yamlに次の記述を行うとGemfileに記述してあるrakeのバージョンを無視してシステムのrakeを使うようです。

---
exclude:
  - rake

これでやりたかったことが実現できるね。
.noexec.yaml、知らんかったわ〜。やるね〜♪
--- 参考URL

--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。

かあさん、RSpec Mock 2.14にTest Spyがあるようで...

RSpec Mock 2.14にはexpectっぽい記述が追加されましたね。http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/

# Old
foo.should_receive(:bar)
foo.should_receive(:bar).with(:buzz)
foo.should_receive(:bar).exactly(3).times

# New
expect(foo).to receive(:bar)
expect(foo).to receive(:bar).with(:buzz)
expect(foo).to receive(:bar).exactly(3).times

それだけかと思っていたら、DoubleパターンのTest Spyが実装されています。(Test Spyについては、日本語だと http://goyoki.hatenablog.com/entry/20120301/1330608789 の Test Spyが分かりやすいかも)待ってましたよ!!(もしかして、undocumentedだっただけで、元々実装されてましたかね?)
以下は、http://myronmars.to/n/dev-blog/2013/07/rspec-2-14-is-released の「Mocks: Spies」のサンプルコードです。

# non_spy_spec.rb
mailer = double("Mailer")
expect(mailer).to receive(:deliver_welcome_email).with(an_instance_of(User))
UserCreationService.new(mailer).create_user(params)

# spy_spec.rb
mailer = double("Mailer", deliver_welcome_email: nil)
UserCreationService.new(mailer).create_user(params)
expect(mailer).to have_received(:deliver_welcome_email).with(an_instance_of(User))

とっても、いいね!

--- 参考URL

--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。

モデルのscopeの、specを記述する

モデルのscopeのspecを記述したいと思ったのですが、「scope rspec」でGoogleで検索したところ、How can i have an rspec test for my default scope: http://stackoverflow.com/questions/6853744/how-can-i-have-an-rspec-test-for-my-default-scope にその答えっぽいのがありました!!

CatMembership.scoped.to_sql.should == CatMembership.order(:created_at).to_sql

そうか!scopeのメソッド呼び出しした結果と、そのメソッドで行うscopeをテストコードでも定義して比較すればいいのか!?
目からウロコでござる。
で、このテストに意味があるのかって?そりゃ、テストファーストの場合はどうかわからないけど、少なくともリファクタリングするときには役立つよね。互換性が保たれていることがチェックできるからね。デグレを防ぐこともできるでしょうね。
いや〜、サンキューでした。
--- 参考URL

--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。

Jenkins on Mac OS Xでの、出力結果の文字化けを解消する

簡単にいうと「Jenkins on Ubuntu の文字化けを直す(http://shunirr.hatenablog.jp/entry/2013/01/10/175426)」 の Mac OS X 版で、Rakeなどの結果に日本語が含まれている場合に文字化けしてしまうのですが、それを解消する手順ですね。なお、この手順はインストーラ(jenkins.pkg)でJenkinsをインストールした場合を想定しています。
それでは、今日もはりきっていってみましょう♪

    • -

「/Library/Application Support/Jenkins/jenkins-runner.sh」を以下のように修正します。

(修正前)
javaArgs=""

(修正後)
javaArgs="-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8"

その後、Jenkinsを再起動させます。(最初は再起動の方法がわからず、kill -9 していましたwww)

$ sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
$ sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist

これでOKです。ブラウザで「http://localhost:8080/systemInfo」にアクセスして「UTF-8」という文字が2箇所あることを確認してください。
なお、これは次回のビルド時から反映されます。過去のビルドは文字化けしたままです。残念ですね〜...

--- 参考URL

--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。

Gitの直前のコミットと、現在の修正を結合する

Gitでトピックブランチを作成して作業していると、直前のコミットと結合したくなることがあります。コメント中のtypoを見つけてそれを修正したりしたときですね(以降、typo の修正)。実は私、typo の修正をコミットした後に git rebase -i HEAD\^\^ で fixup することで、typo の修正と直前のコミットを結合していました。
しかし...



こういうときは git commit --amend を使うのですね orz

(typo を修正して、git add する前の状態)
$ git commmit --amend -C HEAD -a

commit サブコマンドの --amend オプションは、コメント・コミット日時・authorの修正にしか使っていませんでした。
git-fixup: http://d.hatena.ne.jp/tyru/20110107/git_fixup では、 fixup という alias を紹介しています。さっそく設定してみました。

$ git config --global alias.fixup 'commit --amend -C HEAD'

いい〜ね〜〜〜♪

--- 参考URL

--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が提供している無料のサービス「かくってる?」をお試しください。

タスク・カンバンの背景を、いじる

「もう残業はしたくない – 今日から使える25のタイムマネージメントテクニック【btrax】」(http://media.looops.net/btrax/2013/06/19/time/)という記事にある「14. 重要だが緊急性の低いタスクにフォーカスする事を意識する」で紹介されているタスクの分類をそのままタスク・カンバンの背景にしてみました。
https://pbs.twimg.com/media/BNGr5_6CEAAGaI4.jpg
そんだけですけど、なんかやったった感があるね♪

Gitのサブコマンドを、作成する

「git mine merged <マージ済みのブランチ名>」という Git のサブコマンドを作成してみます。このコマンドは、マージ済みのブランチ名を指定して、ブランチの名前にmergedをつけるという単純なものです。これは Git のサブコマンドを高速に作れるようになるための練習です。
といっても、以下の内容の「git-mine」という名前でパスの通ったところに配置するだけです。Git のサブコマンドの場合、ファイル名はかならず git- のプレフィックにします。簡単ですね。

#!/usr/bin/env ruby
# -*- coding: utf-8 -*-

require "rubygems"
require "thor"

class GitMine < Thor
  include Thor::Actions

  desc "merged BRANCH_NAME", "rename a branch name, 'name' -> 'merged/name' in Git"
  def merged(branch_name)
    if `git branch`.strip.split(/\s+/).grep(branch_name).empty?
      say "error: not exist branch #{branch_name}"
      return 1
    end
    cmd = "git branch -M #{branch_name} merged/#{branch_name}"
    run cmd
  end
end

GitMine.start

それで、これからサブコマンドが必要になったら、上記の GitMine を修正して、以下のような記述を追加すれば OK になります。簡単ですね。

  desc "special", "special command!!"
  def special
    say "This is a very special command!!"
  end

これで Git のサブコマンドを高速に作成できるようになりました。

--- 参考URL

--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が提供している無料のサービス「かくってる?」をお試しください。