.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広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。
- かくってる?: http://cocktailq.herokuapp.com/
かあさん、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
- RSpec 2.14のリリースノート(英語): http://myronmars.to/n/dev-blog/2013/07/rspec-2-14-is-released
- RSpec Mock 2.14で導入された新しい記法のついて(英語): http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。
- かくってる?: http://cocktailq.herokuapp.com/
モデルの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
- 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
--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。
- かくってる?: http://cocktailq.herokuapp.com/
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
$ 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
- Jenkins on Ubuntu の文字化けを直す: http://shunirr.hatenablog.jp/entry/2013/01/10/175426
--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が開発・運営している無料のカクテルレシピ提供サービス「かくってる?」をお試しください。
- かくってる?: http://cocktailq.herokuapp.com/
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広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が提供している無料のサービス「かくってる?」をお試しください。
- かくってる?: http://cocktailq.herokuapp.com/
タスク・カンバンの背景を、いじる
「もう残業はしたくない – 今日から使える25のタイムマネージメントテクニック【btrax】」(http://media.looops.net/btrax/2013/06/19/time/)という記事にある「14. 重要だが緊急性の低いタスクにフォーカスする事を意識する」で紹介されているタスクの分類をそのままタスク・カンバンの背景にしてみました。
そんだけですけど、なんかやったった感があるね♪
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
- Home・erikhuda/thor Wiki: https://github.com/erikhuda/thor/wiki
--- PR広告
記事を読んでくださり、ありがとうございます。もしよろしければ、この記事の著者が提供している無料のサービス「かくってる?」をお試しください。
- かくってる?: http://cocktailq.herokuapp.com/