Hatena::Groupsubtech

#生存戦略 、それは

-> 12 { 12 / 25 }

github で git diff from..to を表示する

16:46 | はてなブックマーク - github で git diff from..to を表示する - #生存戦略 、それは

いつも忘れるのでメモ。compare だ!(なんで diff じゃないの…)

で表示。

で text/plain な diff が表示される。.. じゃなくて ... 。

(thanks @sora_h, @kakutani)

hirose31hirose312012/12/26 02:08あわせてよみたい: http://d.hatena.ne.jp/hirose31/20120614/1339641769

secondlifesecondlife2012/12/26 09:20参考になる: +1

トラックバック - http://subtech.g.hatena.ne.jp/secondlife/20121225

-> 12 { 12 / 20 }

Capybara の using_session でセッションを切り替えつつインテグレーションテストをする

18:50 | はてなブックマーク - Capybara の using_session でセッションを切り替えつつインテグレーションテストをする - #生存戦略 、それは

ユーザAとユーザBが順番にアクセスしに来て云々という spec を書きたい、ので ググったら Capybara に using_session なんつー便利メソッドがあった!のでみなさん使うと良いです。

ドキュメント素っ気ない…。便利なのに…。

以下は wiki のページ衝突の example。片方が更新したのに、それを知らずにページ更新しようとするとコンフリクト画面が出る、みたいな。

using_session(:bob) {
  login(bob)
  visit page_edit_path(target_page)
}
using_session(:tom) {
  login(tom)
  visit page_edit_path(target_page)
}
using_session(:bob) {
  fill_in 'page_content', with: "# bob's page"
  click_button 'Save'
  page.should have_selector 'h3', text: "bob's page"
}
using_session(:tom) {
  fill_in 'page_content', with: "# tom's page"
  click_button 'Save'
  page.should_not have_selector 'h3', text: "tom's page"
  page.should have_selector '#page_content', text: "# tom's page"

  page.should have_selector('#confrict')
...

Rails でアプリ内部から発行してる http をトレースする

16:17 | はてなブックマーク - Rails でアプリ内部から発行してる http をトレースする - #生存戦略 、それは

の続き。デバッグ用にセットしたら便利だったのでメモ。

Gemfile

group :test, :development do
  gem 'webmock', require: false
end

しておいて

config/environments/development.rb

if ENV['WEBMOCK_ENABLE']
  require 'webmock'

  WebMock.allow_net_connect!
  WebMock.after_request do |request_signature, response|
    res = ["=== HTTP Request ===",  "#{request_signature}", "", response.status.join(' ')]
    res << response.headers.map {|key, val| "#{key}: #{val}" }.join("\n")
    unless response.body.empty?
      res << ""
      res << response.body
    end
    res << "=" * res.first.size
    Rails.logger.debug res.join("\n")
  end
end
```

しておいて

WEBMOCK_ENABLE=1 rails s

すると、http 叩いてるところが以下みたいに出て便利。

=== HTTP Request ===
GET http://example.com/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=0.3', 'User-Agent'=>'Ruby'}

302 Found
Location: http://www.iana.org/domains/example/
Server: BigIP
Connection: Keep-Alive
Content-Length: 0
====================
=== HTTP Request ===
GET http://www.iana.org/domains/example/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=0.3', 'User-Agent'=>'Ruby'}

200 OK
Date: Thu, 20 Dec 2012 07:16:22 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Thu, 06 Dec 2012 19:40:14 GMT
Content-Length: 606
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
....
トラックバック - http://subtech.g.hatena.ne.jp/secondlife/20121220

-> 12 { 12 / 07 }

git-new-workdir が便利

13:21 | はてなブックマーク - git-new-workdir が便利 - #生存戦略 、それは

作業中、別のベクトルの作業するからブランチ切り替えじゃ無くてもういっこワーキングディレクトリを作って作業したい!って思った経験ありませんか?みなさん n 回ぐらいあるんじゃないでしょか。

そんなときいちいち clone して…などしなくても git-new-workdir コマンドを使えば一発!git-core の contrib に入ってます。

ln -s /usr/local/share/git-core/contrib/workdir/git-new-workdir ~/bin/ 

とか適当に symlink 等張って

git-new-workdir . ../foobar

するだけ!便利!べんり!もちろん .git/config 等の内容もちゃんと同じのがつかえます。あと cp するより速度がめちゃくちゃ速いので、大きいレポジトリで作業してるほど効果を実感できるます。(追記: .git 以下を symlink 張るから速いって得さんが書いてた)

[1]>_<X time git-new-workdir . /tmp/foobar
Checking out files: 100% (16546/16546), done.
git-new-workdir . /tmp/foobar  1.03s user 2.60s system 56% cpu 6.401 total
[1]>_<X rm -rf /tmp/foobar
[1]>_<X time cp -rpf . /tmp/foobar/
cp -i -rpf . /tmp/foobar/  2.12s user 35.67s system 31% cpu 2:00.27 total

git-new-workdir でググってもあんまり引っかからないのでエントリー化。なお同僚のレオ氏に教えて貰いました。どうりょうべんり。

なお、contrib が入ってないディストリの方々は以下から落として使うと良いと思います

トラックバック - http://subtech.g.hatena.ne.jp/secondlife/20121207

-> 12 { 11 / 22 }

Ruby を 1.9.3 p327 から 2.0.0 dev に上げたら Rails の起動時間が2.5倍速、rake spec の速度が1.8倍速になった

21:05 | はてなブックマーク - Ruby を 1.9.3 p327 から 2.0.0 dev に上げたら Rails の起動時間が2.5倍速、rake spec の速度が1.8倍速になった  - #生存戦略 、それは

流しのフェローRuby 2.0.0 速いって言ってたので、いやいや速いっていっても〜、と思って社内の Ruby 1.9.3 な Rails プロジェクトで 2.0.0dev 使ってみたら

1.9.3

[5]>_<X time bx rails runner 'puts Rails'
Rails
bundle exec rails runner 'puts Rails' 6.24s user 1.06s system 86% cpu 8.396 total

2.0.0dev

[5]>_<X rvm use ruby-head
Using /Users/yuichi-tateno/.rvm/gems/ruby-head
[5]>_<X time bx rails runner 'puts Rails'
Rails
bundle exec rails runner 'puts Rails' 2.51s user 0.61s system 93% cpu 3.343 total

な感じで、Rails の環境ロードして立ち上げが 8.3 秒 -> 3.3秒 になって 2.5倍やばい!!!!って感じに!!1 require が高速化したから、ライブラリたくさん読み込むプロジェクトはかなり速くなるらしい。

また、rake spec の速度も unit test / functional test メインのプロジェクトで

# ruby 1.9.3
Finished in 49.18 seconds
bundle exec rake spec 59.51s user 3.54s system 89% cpu 1:10.50 total

の spec 時間49秒、その他もろもろ含めて70秒から

# ruby 2.0.0dev
Finished in 28.53 seconds
bundle exec rake spec 29.72s user 2.92s system 84% cpu 38.854 total

spec 時間28秒、もろもろ含めて39秒と1.8倍速に。快適すぎてマジヤバーイ。ちなみに社内の ruby 1.9.3 なプロジェクトは試した限り ruby 2.0.0dev でもすべて spec 通った。さすが 100% 互換性という話し!

なお、text で hello world を表示するだけの Rails app (unicorn) のベンチを ab でとってみたけど、これぐらい単純なアプリだと 1.9.3 と 2.0.0 の速度差は誤差レベルでした。

あわせて読みたい

  • no title
  • no title
    • Ruby 2.0 のツボを押さえためちゃくちゃ解りやすくて良い資料…!

きょうはいちにち ruby 2.0.0dev 厨でした!はやく 2013年2月24日の ruby 2.0.0p0 リリースこないかなぁ〜わくわく!

トラックバック - http://subtech.g.hatena.ne.jp/secondlife/20121122