Ruby 2.6 新機能:本番環境での利用を目指したコードカバレッジ計測機能

技術部の遠藤(mame)です。1 ヶ月くらい風邪が直らず、苦しみながらこれを書いています。

昨日は Ruby 2.6 の NEWS を裏話付きで解説する記事を書きました(プロと読み解く Ruby 2.6 NEWS ファイル)。今日と明日は、その中でクックパッドのフルタイムRubyコミッタが主に担当したところを少し詳しく紹介します。

今日は、遠藤が作った "oneshot coverage" と言う 2.6 の新機能を紹介します。

背景:Ruby では不要コードの発見・削除が難しい

クックパッドのサービスの多くは、cookpad_all という 1 リポジトリからなる、巨大な Rails アプリケーションとして実現されていました。しかし、このやり方ではメンテナンスが限界になってきたので、「お台場プロジェクト」という大整理プロジェクトが行われてきました。この辺の詳細は次の 2 つの記事が詳しいです。

お台場プロジェクトの活動のひとつに、「不要になったコードを削除する」というものがあります。

クックパッドに入るまで考えたことがなかったのですが、この「不要コードを発見・削除する」が、なかなかむずかしいのでした。他人の書いたコードが不要になったかどうかの判定はむずかしいですし、不要と思って消したら予想外のところで使われていたということもあります。特に Ruby は、インタプリタ言語なのでコンパイルによるチェックがなく*1、その上リフレクションが多用される文化なので、検証がとてもむずかしいです。

そこでクックパッドでは現在、Ruby 本体にパッチを入れて、各コード断片が初めて実行されたときに記録をつけながら本番運用をしています。これにより、長期間運用していても全く使われていないコード断片を効率的に発見できます。また、実際に使われていないコードなので、わりと安心して削除できます。この詳細は次の記事をご覧ください。

これを同じようなことを、Ruby にパッチをあてずに実現するのが、oneshot coverage です。

コードカバレッジとは

コードカバレッジを知っている人はこの節をスキップしてください。

コードカバレッジとは、どのコード断片が実行されたかを記録したものです。

-: # test.rb
1: def foo(n)
2:   if n <= 10
2:     p "n < 10"
-:   else
0:     p "n >= 10" # テストされていない
-:   end
-: end
-:
1: foo(1)
1: foo(2)

左端の数字がコードカバレッジです。各行が何回実行されたかを表しています。空行など意味のない行は - になっています。0 になっているところは、1 度も実行されなかったことを意味しています。通常、コードカバレッジはテスト時に使われ、テスト不足のコード(端的に言うと実行回数が 0 の行)を探すために使われます。

Ruby では、coverage ライブラリを使うことでコードカバレッジを計測できます。

require "coverage"

# コードカバレッジ測定開始
Coverage.start(lines: true)

# 測定対象のプログラムを読み込む
load "test.rb"

# 結果の取得
p Coverage.result
#=> {"test.rb"=>{:lines=>[nil, 1, 2, 2, nil, 0, nil, nil, nil, 1, 1]}}

配列の数字が各行の実行回数に対応しています。

Ruby のコードカバレッジ測定について詳しく知りたい方は RubyKaigi 2017 の遠藤の発表資料をご覧ください。

このコードカバレッジ測定を本番環境で使えば、いつまでたっても実行されない行を発見することができます。しかし、通常のコードカバレッジ測定では、各行を実行するたびにカウントアップのフックを実行することになり、オーバーヘッドが問題になります。また、Covearge.result は、全ソースファイル行数の長さの配列を作るので、こちらもオーバーヘッドが気になるところです。

この問題を解決するのが oneshot coverage です。

oneshot coverage とは

oneshot coverage とは、各行の実行回数ではなく、各行が 1 回でも実行されたかどうかを計測するコードカバレッジです。コードカバレッジ測定ツールは伝統的に、行ごとの実行回数を数えるものが多いですが、実際の用途としては、未テストの行(実行回数が 0 の行)を探すというのがふつうです。なので、実行回数が取れなくなることにデメリットはほとんどないと思います。

oneshot coverage の計測モードでは、各行について最初の 1 回だけカウントアップのフックを実行します。1 度実行されたら、その行のフックのフラグを消し去るので、あとはカバレッジ計測のない状態と同じになります。*2

以下、具体的な使い方を説明していきます。

1. oneshot モードにする方法

oneshot coverage を有効にするには、カバレッジ測定開始メソッドを Coverage.start(oneshot_lines: true) というように呼び出します。

require "coverage"

# カバレッジ測定開始 (oneshot_lines モードにする)
Coverage.start(oneshot_lines: true)

# 測定対象のプログラムを読み込む
load "test.rb"

#  1: # test.rb
#  2: def foo(n)
#  3:   if n <= 10
#  4:     p "n < 10"
#  5:   else
#  6:     p "n >= 10"
#  7:   end
#  8: end
#  9:
# 10: foo(1)
# 11: foo(2)

# 結果の取得
p Coverage.result
{"test.rb"=>{:oneshot_lines=>[2, 10, 3, 4, 11]}}

Coverage.result の返り値が「実行された行番号」の列に変わりました。

2. インクリメンタルに計測する方法

oneshot coverage は運用環境で使うことを想定しているので、たとえば 100リクエストごとや 10 分ごとなど、定期的に Coverage.result を呼んで測定結果を記録していきたくなると思われます。しかし Coverage.result を無引数で呼ぶと、カバレッジの測定を停止してしまいます*3

現在までに実行した行番号は知りたいが、その後もカバレッジ測定は継続して欲しい、というときのために、Coverage.resultstop というキーワード引数を追加しました。次のように使えます。

require "coverage"

# カバレッジ測定開始 (oneshot_lines モードにする)
Coverage.start(oneshot_lines: true)

# 測定対象のプログラムを読み込む
load "test.rb"

# 結果の取得
p Coverage.result(stop: false)
{"test.rb"=>{:oneshot_lines=>[2, 10, 3, 4, 11]}}

# 実行されていなかった test.rb の 6 行目を実行する
foo(100)

# 新たな結果の取得:6 行目が追加された
p Coverage.result(stop: false)
{"test.rb"=>{:oneshot_lines=>[2, 10, 3, 4, 11, 6]}}

1 回目の Coverage.result の呼び出し結果と 2 回目の結果を比べると、6 行目が追加で実行されたことがわかります。

また、clear キーワードを使うと、1 度見た行をクリアできます。

require "coverage"

# カバレッジ測定開始 (oneshot_lines モードにする)
Coverage.start(oneshot_lines: true)

# 測定対象のプログラムを読み込む
load "test.rb"

# 結果の取得
p Coverage.result(clear: true, stop: false)
{"test.rb"=>{:oneshot_lines=>[2, 10, 3, 4, 11]}}

# 実行されていなかった test.rb の 6 行目を実行する
foo(100)

# 新たな結果の取得
p Coverage.result(clear: true, stop: false)
{"test.rb"=>{:oneshot_lines=>[6]}}

# もう未到達の行は存在しない
foo(0)
foo(100)

# 新たな結果の取得(新たに実行された行はない)
p Coverage.result(clear: true, stop: false)
{"test.rb"=>{:oneshot_lines=>[]}}

このように、oneshot coverage では Coverage.result(clear: true, stop: false) を使うのが基本です。

oneshot coverage の結果は「実行された行番号の列」なので、Coverage.result を呼ぶたびに全ソースファイル行数分の配列ができるのを避けることができます。

追記(2019/01/09):clear キーワードを間違えて reset と書いてました。すみません。

3. 実行されなかった行を調べる

「実行された行番号」の列が取れるようになりましたが、実際に興味があるのは「実行されなかった行番号」です。ただし、空行とかコメント行とかのように、実行という概念がない行は無視する必要があります。

そのために、Coverage.line_stub という補助関数を用意しました。この関数を使うと、行カバレッジの配列のスタブを作れます。

require "coverage"

# 行カバレッジのスタブ配列を作る
ary = Coverage.line_stub("test.rb")
p ary #=> [nil, 0, 0, 0, nil, 0, nil, nil, nil, 0, 0]

nil になっているのは空行やコメント行など、0 になっているのは行カバレッジの測定対象(実行という概念がある行)です。

「実行された行番号」番目を 1 にすることで、見慣れた行カバレッジの形式に変換できます。

require "coverage"

# カバレッジ測定開始 (oneshot_lines モードにする)
Coverage.start(oneshot_lines: true)

# 測定対象のプログラムを読み込む
load "test.rb"

# 行カバレッジのスタブ配列を作る
ary = Coverage.line_stub("test.rb")

# 実行された行番号の要素を 1 にしていく
Coverage.result["test.rb"][:oneshot_lines].each do |i|
  ary[i - 1] = 1
end

# test.rb の行カバレッジ
p ary #=> [nil, 1, 1, 1, nil, 0, nil, nil, nil, 1, 1]

このように変換すれば、既存のカバレッジ可視化ツールに渡したり、自分で可視化したりがやりやすくなると思います。

評価実験

次の 3 つの条件で、プログラムの実行にかかる時間を測定してみました。

  • (1) コードカバレッジ測定なし
  • (2) 従来の行コードカバレッジ測定(Coverage.start(lines: true)
  • (3) oneshot coverage モード(Coverage.start(oneshot_lines: true)

マイクロベンチマーク

次のプログラムは、コードカバレッジの計測オーバーヘッドが最大になりそうな人工的な例です。

# bench.rb
def bench
  x = 1
  x = 2
  x = 3
  x = 4
  x = 5
  x = 6
  x = 7
  x = 8
  x = 9
  x = 10
end

10000000.times { bench }

このプログラムの実行時間を測定した結果はこちら。それぞれ 3 回測定した平均です。

条件 時間 (秒)
(1) カバレッジ測定なし 0.972
(2) 従来の行カバレッジ 4.53
(3) oneshot coverage 0.967

(2) がだんとつで遅く、(1) と (3) がほぼ同じです。oneshot coverage が実質ゼロオーバーヘッドであることがわかります。

optcarrot の例

もう少し現実的な例として、Ruby 3 のデファクトベンチマークである optcarrot も測定しました。

結果はこちら。やはり 3 回ずつ測定した平均です。単位は frame per second で、数字が大きいほうが速いです。

条件 fps
(1) カバレッジ測定なし 39.8
(2) 従来の行カバレッジ 10.6
(3) oneshot coverage 39.4

やはり、(2) が 4 倍くらい遅く、(1) と (3) はほぼ同じです。

先ほどのマイクロベンチマークでも optcarrot も CPU 律速のベンチマークなので、Rails のような IO 律速なアプリでは、オーバーヘッドはさらに小さくなっていくはずです。

余談:MJIT との相性

少しだけ補足です。Ruby 2.6 の一番の目玉機能である、JIT コンパイラ、MJIT との相性について。

coverage(というか TracePoint API)が有効だと MJIT は動かないようになっています。oneshot coverage はバイトコード(フックフラグ)を実行時に書き換えるので、JIT コンパイルしてもフラグが変わったらコンパイルのやりなおしになるためです。optcarrot を --jit オプション付きで測定し直した結果がこちら。

条件 --jit なし fps --jit あり fps
(1) カバレッジ測定なし + --jit 39.8 56.1
(2) 従来の行カバレッジ + --jit 10.6 10.3
(3) oneshot coverage + --jit 39.4 38.8

--jit をつけると、(1) カバレッジ測定なしなら 39.8 → 56.1 fps に大幅スピードアップしていますが、(3) oneshot coverage は 39.4 → 38.8 fps と、MJIT が無効になっていることが確認できます。

しかし、現時点では MJIT はまだ Rails アプリを高速化するには至っていない(k0kubun さんによる進捗報告記事)ので、気にしなくても大丈夫です(?)。MJIT のクオリティが上がっていったら、なんか改善できる(してくれる)のではないかと思います。

まとめ

Ruby 2.6 で入った、(最初の1回のフックの後は)ゼロオーバーヘッドでカバレッジを測定できる oneshot coverage という機能を紹介しました。これを本番環境で使うことで、使われていなさそうな行の情報が得られます。不要コードの発見・削除のお役に立てば幸いです。

なお cookpad_all はまだ Ruby 2.6 で運用されていないので(当たり前)、まだ oneshot coverage は適用できていませんが、使っていく方向で計画が進んでます。これについてはまたの機会に報告できればと思います。

*1:インタプリタ言語だからといって同様の検証ができないとも限りませんが、とりあえず Ruby にはそういう検証ツールがいまのところありません。

*2:もう少し言うと、Rails のような IO ボトルネックなプログラムでは、カバレッジ計測のオーバーヘッドは元々ほとんど問題にならないと思います。少なくとも、cookpad.com のテストをカバレッジ計測あり・なしで走らせても、実行時間に違いはみられませんでした。ただ、本番環境で従来のカバレッジ計測を有効にするのは、オーバーヘッドが問題になるリスクがあるかもしれません。

*3:これは Coverage.result の仕様を最初に決めたときの判断ミスで、とても後悔しています。

プロと読み解く Ruby 2.6 NEWS ファイル

技術部の笹田(ko1)と遠藤(mame)です。クックパッドで Ruby (MRI: Matz Ruby Interpreter、いわゆる ruby コマンド) の開発をしています。お金をもらって Ruby を開発しているのでプロの Ruby コミッタです。

もうすぐ Ruby 2.6 がリリースされますね! Ruby 2.6 の新機能は何だろう、と調べるためには、ソースコードの diff を見ればいいのですが、膨大な変更があるので、一つ一つ見ていくのは大変です。

$ git diff --compact-summary origin/ruby_2_5
...
 6404 files changed, 228441 insertions(+), 97984 deletions(-)

そこで、NEWS ファイルという、主要な変更点をまとめたファイルが用意されています。これを見るだけで、Ruby 2.6 の変更点が把握できます。NEWS ファイルは Ruby 2.6 の tarball などに入っています。

ただ、NEWS ファイルも、あまり詳細は書いていないため、読みづらいかも知れません。淡々と、「このメソッドが追加された」とかが並んでいるだけです。

そこで、本記事では Ruby 2.6 の NEWS ファイルの内容を、プロ Ruby コミッタの笹田と遠藤で解説していきます。解説記事はすでにいくつかあり、さらに出てくるだろうと思うのですが、本稿では、なぜ「そのような変更がおこなわれたか」という背景事情をなるべく書くように心がけています。

なお、NEWS ファイルに追記しているのは人間なので、当然追記忘れなどのミスがあります。そのため、これ以外にも変更があるかもしれませんが、ご容赦下さい。

See also:

(ko1) <- 以降、こんなふうに文責を明示します。

NEWS ファイルの読み方

まず、NEWS ファイルの構成について解説しておきます。

見ての通り、Markdown ではなく、RDoc フォーマットで書いてあります。まぁ、読む分には見た目の雰囲気でわかるんじゃないかと思います。

章立ては次の通りです。

  • Language changes / 言語の変更
  • Core classes updates (outstanding ones only) / 組込クラスのアップデート(主要なもののみ)
  • Stdlib updates (outstanding ones only) / 添付ライブラリのアップデート(主要なもののみ)
  • Compatibility issues (excluding feature bug fixes) / 非互換(バグ修正を除く)
  • Stdlib compatibility issues (excluding feature bug fixes) / 添付ライブラリの非互換(バグ修正を除く)
  • C API updates / C API のアップデート
  • Implementation improvements / 性能向上
  • Miscellaneous changes / その他

読めばわかると思いますが、言語の変更が最初にあって、組込クラス、標準ライブラリの仕様変更とかの話になり、最後に互換性関係ない性能向上とかで話を締めています。やっぱり、これまでの Ruby アプリが動くかどうかと言う、仕様変更が気になりますよね。

文中に出てくる [Feature #12912] といった表記は、https://bugs.ruby-lang.org/projects/ruby-trunk/issues に登録されたチケット番号になります。https://bugs.ruby-lang.org/issues/ の後ろに番号を付ければ、この場合は https://bugs.ruby-lang.org/issues/12912 とすれば、当該チケットを見ることができます。

NEWS は上記の順番で並んでいますが、本稿では、この順番は無視して、我々が重要だと思っている、もしくは興味がある変更を順に紹介していきます。でも、笹田が一番興味のある性能向上については、最後にまとめます(知らなくても使う分には問題ないですから)。

(ko1)

言語機能の改善

少し、文法などの拡張がありました。新しい文法などを使うと、古い Ruby で動かなくなるので、お気を付け下さい。

終端なしの Range が導入された

  • Endless ranges are introduced. You can use a Range that has no end, like (0..) (or similarly (0...)). [Feature #12912]

(1..) のように、終端を省略した Range が書けるようになりました。

遠藤が提案・実装しました。提案時に想定していたユースケースは、次の 3 つです。

ary[1..] #=> ary[1..-1] と同じ
    
(1..).each {|index| ... } # 1 から無限にループ

# each_with_index を 0 でなく 1 から始める
ary.zip(1..) {|elem, index| ... }

どれも、意外とスッキリ書けなくてモヤモヤしていました。終端が省略できればいいのでは、と思って実装してみたら、意外にすんなり実装できて驚きました。

他の用途としては、下限の指定を DSL 的に表現するのにも使えそうです。(この用途としては beginless range も欲しくなりますが、こちらの提案は pending となってます)

users.where(id: 10..)

(1..)(1..nil) の構文糖です。終端を nil にするかどうかは少し議論がありました。従来から書けていた nil..nil が endless になってよいのかとか。Qundef(Ruby ユーザからは見えない未定義を表す値)を使うとか、他にも選択肢はありましたが、一番直観的なものということで nil になりました。 (1..)(1...) の違いも結構議論がありました。(1..) は無限大を含む Range のように見えて数学的にはちょっと不思議、とか。しかし ary[1..]ary[1...] と書かないと行けないのは面倒なので、数学的な直感はおいといて (1..)(1...) の両方が入ることになりました。なお、これらはオブジェクトの等価性としては別(exclude フラグの有無が違う)です(ary[1..]ary[1...] は同じ結果になります)。

なお、次のように書くと syntax error になるのでご注意ください。

case id
when 10..
  puts "id >= 10"
end

これは、10.. で行が終わると、行継続になってしまうためです。when (10..) のようにカッコをつければ動きます。直すこともできたのですが、複数行に渡る Range リテラルの例が発見されたので、互換性重視で現在の挙動になりました。

(mame)

ローカル変数の shadowing 警告を削除

ブロックの引数の名前が、外のスコープのローカル変数と衝突しているとき、警告モードで実行すると警告が出ていました。

x = "str"
1.times {|x| ... }
#=> warning: shadowing outer local variable - x

この警告を取り除くことになりました。これにより、次のようなコードで警告を見なくてよくなりました。

user = users.find {|user| cond(user) }
#=> warning: shadowing outer local variable - user ← 2.6 で消えた

歴史的な話をすると、Ruby 1.8 ではこういう衝突があるとき、外のローカル変数を上書きしていたのですが、1.9 から現在の挙動に変わりました。

x = "str"
(0..10).each {|x| }
p x #=> 10    (in Ruby 1.8)
#=> "str" (in Ruby 1.9+)

この警告はその非互換を伝えるために存在しましたが、さすがにもう要らなそうだし、妥当なコードでも警告されてしまうのが邪魔であるということで、消すことになりました。もしこの警告が欲しい人は、Rubocop の Lint/ShadowingOuterLocalVariable を使うといいんじゃないでしょうか。

(mame)

rescue のない else が禁止

  • else without rescue now causes a syntax error. [EXPERIMENTAL] [Feature #14606]

例外処理の構文 begin ... rescue ... end には、例外が投げられなかったときの処理を書く else 節があります。

begin
  ...
rescue
  # 例外が投げられた場合
else
  # 例外が投げられなかった場合
end

rescue 節は何個書いてもよいのですが、0 個でもよかったのでした。

begin
  ...
else
  ...
end

が、このプログラムは意味がなく、理解もしにくいだろうということで、rescue 節 0 個のときは SyntaxError とすることになりました。同様に、メソッド内での rescue 無し else も禁止になりました。

def foo
  ...
else
  ...
end

個人的には、変なコードが書けなくなったので少しだけ残念な気持ちです。

(mame)

定数名で非 ASCII の大文字も利用可能に

定数名は ASCII の大文字でないとダメでしたが、2.6 で Unicode の大文字も OK となりました。

class Мир
  def приветствовать
    "Привет, Мир!"
  end
end

Мはキリル文字の大文字です。

完全に余談ですが、Unicode の大文字・小文字の話題になると、「Dz」という字の話をするのがお作法です。これは D と z の 2 文字ではなく、D と z が合体した 1 つの文字です。こういう文字を、digraph、二重音字と言います。この文字には、大文字・小文字に加え、タイトルケース(先頭の文字だけが大文字)の 3 種類があります。

# 大文字
p "\u01F1" #=> DZ

# 小文字
p "\u01F3" #=> dz

# タイトルケース
p "\u01F2" #=> Dz

Ruby では、大文字とタイトルケースの両方を定数として使えます。

class DZ # OK
end
class Dz # OK
end
class dz #=> class/module name must be CONSTANT
end

ちなみに、Dz はスロバキア語、ハンガリー語などで使われるそうです(Wikipedia の記事)。digraph は Dz 以外にもいくつかあります(List of Unicode Characters of Category “Titlecase Letter”)。

(mame)

キーワード引数とオプション引数のコーナーケースを禁止

  • Non-Symbol keys in a keyword arguments hash cause an exception.

matz がみつけた、オプション引数とキーワード引数を両方受け取るときの微妙な挙動が禁止になりました *1

def foo(h = {}, key: :default)
  p [h, key]
end

foo(:key => 1, "str" => 2)
  #=> [{"str"=>2}, 1] (2.5 まで)
  #=> non-symbol key in keyword arguments: "str" (ArgumentError) (2.6)

Ruby 2 のキーワード引数にはいろいろ変なところがあり、Ruby 3 での作り直しが検討されています(参考:大江戸 Ruby 会議 07 『Ruby 3のキーワード引数について考える』)。この変更は、それの伏線になっているとかいないとか。

追記(2019/03/12):逆にキーワード引数作り直しの障害になることが判明(Bug #15658)したので、キャンセルされました。2.6.2 で戻る予定です。

(mame)

バックトレースで原因(cause)のバックトレースも出るようになった

  • Print cause of the exception if the exception is not caught and printed its backtraces and error message. [Feature #8257]

例外処理中(rescue 文や ensure 文実行中)に、新しい例外を意図して発生させたり(下記の例の NantokaError)、意図せず発生させちゃったり(rescue 文に typo があったりとか。例外処理のテストは網羅するのが面倒なので、よくありそうな話ですね)することがあります。そのとき、プロセス異常終了時のバックトレースの表示には、最後に発生した例外の情報しかありませんでした。ランタイムとしては、最後に発生した例外オブジェクトで、 Exception#cause というメソッドで取れることは取れるんですが、プロセス終了時のエラー表示には含まれていませんでした。

Ruby 2.6 からは、プロセスが例外で終了したとき、あがってきた例外オブジェクトに cause の情報があれば、その情報も一緒に表示するようになりました。

class NantokaError < RuntimeError
end

def my_open
  open('non_existing_file')
end

begin
  my_open
rescue Errno::ENOENT
  raise NantokaError
end

この例では、openErrno::ENOENT 例外を発生しますが、呼び出し元で NantokaError をさらに発生させています。

Ruby 2.5 では、

Traceback (most recent call last):
        1: from /home/ko1/src/ruby/trunk/test.rb:8:in `<main>'
/home/ko1/src/ruby/trunk/test.rb:11:in `rescue in <main>': NantokaError (NantokaError)

と、最後に発生させた NantokaError だけ表示しています。

Ruby 2.6 では、

Traceback (most recent call last):
        3: from /home/ko1/src/ruby/trunk/test.rb:9:in `<main>'
        2: from /home/ko1/src/ruby/trunk/test.rb:5:in `my_open'
        1: from /home/ko1/src/ruby/trunk/test.rb:5:in `open'
/home/ko1/src/ruby/trunk/test.rb:5:in `initialize': No such file or directory @ rb_sysopen - non_existing_file (Errno::ENOENT)
        1: from /home/ko1/src/ruby/trunk/test.rb:8:in `<main>'
/home/ko1/src/ruby/trunk/test.rb:11:in `rescue in <main>': NantokaError (NantokaError)

と、5行目の open が元々のエラーの原因であることを示すようになりました。

冗長になりますが、原因がわからないよりは便利だろう、ということで、導入されることになりました。Java とかで、すでにそのように表示されるようですね。

ちなみに、cause がたくさん連鎖していると、バックトレースはどんどん長くなります。また、上記例をちょっと変えて、少しメソッド呼び出しの深いところで実行してみると、

class NantokaError < RuntimeError
end

def my_open
  open('non_existing_file')
end

def foo
  bar
end

def bar
  begin
    my_open
  rescue Errno::ENOENT
    raise NantokaError
  end
end

foo

結果:

Traceback (most recent call last):
        5: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        4: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'
        3: from /home/ko1/src/ruby/trunk/test.rb:14:in `bar'
        2: from /home/ko1/src/ruby/trunk/test.rb:5:in `my_open'
        1: from /home/ko1/src/ruby/trunk/test.rb:5:in `open'
/home/ko1/src/ruby/trunk/test.rb:5:in `initialize': No such file or directory @ rb_sysopen - non_existing_file (Errno::ENOENT)
        3: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        2: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'
        1: from /home/ko1/src/ruby/trunk/test.rb:12:in `bar'
/home/ko1/src/ruby/trunk/test.rb:16:in `rescue in bar': NantokaError (NantokaError)

こんなエラー出るようになりました。これをよく見てみると、

        5: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        4: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'
        ...
        3: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        2: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'

共通するこれらの行が被っていますね。Java だと共通する行は出力しないように制御するようですので、冗長な表記をやめるように、今後変更されるかもしれません。

結構面白いハックネタだと思うので、Ruby インタプリタをいじってみたい人は、挑戦してみませんか?

(ko1)

フリップフロップ構文が非推奨に

Ruby には、フリップフロップと呼ばれる、知る人ぞ知る機能がありました。条件式に 開始条件 .. 終了条件 と書くと、開始条件が成立してから終了条件が成立するまでずっと真になるという便利機能です。たぶん awk → Perl 経由で Ruby に入ったと思われます。

["a", "b", "c", "d", "e"].each do |str|
  if (str == "b") .. (str == "d")
    p str #=> "b", "c", "d" が順に表示される
  end
end

しかし、この機能は 3.0 で削除される方向になりました。2.6 では "warning: flip-flop is deprecated" という警告が出るようになりました。ちょっと残念ですね。

削除が提案された理由 [Feature #5400] が "Nobody knows them. Nobody uses them.(誰も知らない。誰も使ってない。)" という煽りだったので、若干荒れました。「誰がこんなの使うの」と思うような機能でも、誰かは使ってるんですよね。まあそれはともかく matz が消したいと言ったので、消える方向に。

遠藤が非推奨の警告を入れる作業を行ったのですが、思った以上に標準添付ライブラリやビルドスクリプトの中でフリップフロップは使われていて、消して回る対応が大変でした。実際にやってみるとわかるのですが、フリップフロップを使っているコードをフリップフロップ無しにするのは、思った以上にややこしいです。ということで、本当に消えて大丈夫なんでしょうか。

(mame)

Refinement の拡張

Refinement という、Ruby のメソッドを拡張する仕組みがあるのですが、拡張が効く部分が足りない、ということで拡張されることになりました。

Refinement 自体がすごく難しい機能であまり使うべきでは無いと思っているので(笹田個人の感想です)、ここではあんまり紹介しません。ただ、自分が Refinement を使っていて、「あれ、ここで拡張が効くはずなのになんで効かないんだろう?」ということがあれば、それはもしかしたらバグかもしれないので、ご報告頂ければ幸いです。

(ko1)

クラスやメソッドの追加・改善

いろんな変更がありました。

to_h がブロックを受け取るように

  • Array#to_h now accepts a block that maps elements to new key/value pairs. [Feature #15143]

to_h にブロックを渡すことで、キーと値を指定できるようになりました。

# 従来の to_h の使い方

["Foo", "Bar"].map {|x| [x.upcase, x.downcase] }.to_h
  #=> {"FOO"=>"foo", "BAR"=>"bar"}

# 新しい用法

["Foo", "Bar"].to_h {|x| [x.upcase, x.downcase] }
  #=> {"FOO"=>"foo", "BAR"=>"bar"}

Array の他に Enumerable や Struct なども同じように拡張されました。

この提案は過去にもあった([Feature #10208] Passing block to Enumerable#to_h)のですが、そのときは matz がリジェクトしています。しかし今回はシュッとアクセプトされました。気が変わったそうです。何度も言ってみるものですね。

(mame)

Enumerable#chain

  • Enumerable#chain returns an enumerator object that iterates over the elements of the receiver and then those of each argument in sequence. [Feature #15144]
  • Enumerator#+ returns an enumerator object that iterates over the elements of the receiver and then those of the other operand. [Feature #15144]
  • Enumerator::Chain: This is a new class to represent a chain of enumerables that works as a single enumerator, generated by such methods as Enumerable#chain and Enumerator#+.

Ruby プログラミングをしていると、イテレータをよく使います。イテレータが複数あって、それらをいっぺんに辿りたいときはどうするといいでしょうか。

例えば、配列 a1, a2, a3 があるとします。これらの要素すべてを表示する、という簡単な例を考えてみましょう。

こんな感じでしょうか。イテレータの配列を作っています。多重ループになっちゃうのがイマイチですね。

a1 = %w(1 2)
a2 = %w(3 4)
a3 = %w(5 6)
[a1, a2, a3].each{|ary| ary.each{|e| p e}}

では、配列を全部つなげてみるといいでしょうか。

(a1+a2+a3).each{|e| p e}

ただ、これはイテレータが配列の時にしかうまくいかず、また大きな配列を作ってしまうと性能悪化の懸念が生じます。

Ruby 2.6 からは、Enumerable#chain を使って、イテレータをつなげることができるようになりました。例えば、この例では、次のように書くことができます。

a1.chain(a2, a3).each{|e| p e}

Enumerator#+ を使うことで、Enumerator を同じようにつなげることができます。

(a1.each + a2.each + a3.each).each{|e| p e}

Enumerator#+each を持つメソッドならなんでも受け取るので、例えばこんなふうに書けます。

(a1.each + a2 + a3).each{|e| p e}

each を持ったオブジェクトならなんでも与えられるので、a2 だけ逆順に表示したい、といったときは、Array#reverse_eachEnumerator を返すことを利用して、こんなふうに書くことができます。

(a1.each + a2.reverse_each + a3.each).each{|e| p e}

# or
a1.chain(a2.reverse_each, a3).each{|e| p e}

Enumerator::Chain クラスは、この機能を実装するために導入されたので、まぁこのクラスの存在を気にする必要はないでしょう。

要望自体は以前からあったのですが、なんとなくペンディングになっていたのを、最近話題に取り上げたことで導入されることになりました。時々欲しくなりますよね。

最初は、Enumerator だけを対象に、Enumerator#+ だけでいいんじゃないかな、と思っていたんですが、開発者会議で議論するうちに、Enumeable#chain という、みんなが使う配列とかも影響がありそうなメソッドに発展していきました。

Enumerator#+ を使って i1 + i2 + ... と沢山足していくと、内部的に深い木構造を作ることになるので、効率の心配がありました。まぁ、何十も重ねる人は居ないと思うのですが、心配なら、Enumerable#chain(i1, i2, ...) や、Enumerator::Chain.new(i1, i2, ...) を利用するといいと思います。まぁ、居ないと思うんだけど。*2

(ko1)

Enumerator::ArithmeticSequence の導入

  • This is a new class to represent a generator of an arithmetic sequence, that is a number sequence defined by a common difference. It can be used for representing what is similar to Python's slice. You can get an instance of this class from Numeric#step and Range#step.
  • Added Range#% instance method. [Feature #14697]
  • Range#step now returns an instance of the Enumerator::ArithmeticSequence class rather than one of the Enumerator class.

Arithmetic Sequence、つまり等差数列を扱うクラスが提案されました。なんじゃこの長い名前は、誰が使うんだ、と思うかも知れませんが、生成は簡単です。

as1 = 3.step(by: 2, to: 10)

また、Range#% を使っても作ることができます(Range#step の別名として導入されました)。

as2 = (3..10)%2 # 3.step(by: 2, to: 10) と同じ

どちらも、to_a[3, 5, 7, 9] を取り出すことができます。

さて、なんでこのような等差数列が必要になるかというと、Python における スライス があると、色々と便利だそうで(笹田は、どう便利かはよく知りません)、そのため、Ruby ではどのように導入するか、ということが議論になり、最終的に Enumerator::ArithmeticSequence という形で導入されました。

Python では 3:10:2begin:end:step)のように書くそうです。(3..10)%2 は、Ruby で許される表現の中で、短く書けるのでこれでいいか、といった議論を経て導入されました(新規文法の導入も検討しましたが、そこまですることはないか、となりました)。

実は Ruby では、これを役立てるための仕組みは、まだあまり組み込まれていないため、実際に便利に使えるには、いろいろと揃ってきてからかな、と思います。例えば、配列の要素を取り出すといったことはできません(あ、MRI のハックネタですね)。

p (1..20).to_a[(1..)%3]
#=> no implicit conversion of Enumerator::ArithmeticSequence into Integer (TypeError)

例えば Python だと、こんなふうに使えます。

>>> list(range(1, 21))[1::3]
[2, 5, 8, 11, 14, 17, 20]

ちなみに、Enumerator::ArithmeticSequence には #begin#end#step メソッドがあるので、自分のライブラリをこれに対応することが可能です。

なお、Range#step は Enumerator クラスを返していましたが、この変更で Enumerator::ArithmeticSequence が返るという非互換があります。が、まぁ誰もはまらないよね、多分。

(ko1)

Kernel#yield_self の別名に Kernel#then が導入された

yield_self 便利だけど名前がね... という議論に終止符を打つべく、我らがまつもとゆきひろさんが満を持してコミットした別名then です。まつもとさんの久々のコミットでした。

then という言葉自体は、Promise などで使われていて、それと被るから良くないんじゃないの、という批判があったんですが、Matz が、まぁいいんじゃないの、ということで導入されました。新たな名前論争の種になるかもしれません。

(ko1)

Proc に関数合成オペレータ Proc#>>Proc#<< が追加

一部の方にとっては待望の、関数合成オペレータが追加されました。

Proc の f1 、f2 に対して f1 >> f2 とすると、まず f1 を呼び出し、その返り値を f2 に渡して呼び出す、という Proc を新たに作ります。f1 << f2 は逆で、f2 、f1 の順に呼び出します。次の例を見ると違いがわかると思います。

plus2  = -> x { x + 2 }
times3 = -> x { x * 3 }

times3plus2 = plus2 << times3
p times3plus2(3) #=> 3 * 3 + 2 => 11
p times3plus2(4) #=> 4 * 3 + 2 => 14

plus2times3 = times3 << plus2
p plus2times3(3) #=> (3 + 2) * 3 => 15
p plus2times3(5) #=> (5 + 2) * 3 => 21

提案自体は古くからありましたが、なかなか記号が決まらなくて pending になっていました。数学での関数合成の記号は小さい円(たとえばf ∘ g)なのですが、どちらが先に評価されるかわかりにくいことや、Unicode でないと書けないので * で代用せざるを得ないことなどで議論がまとまらないということが続いていました。

今回、Groovy が <<>> を使っている(6.3. Composition)ということが決め手となり、それにならうことになりました。上の例も Groovy のドキュメントのサンプルを翻訳したものです。

(mame)

exception オプションの導入

  • Kernel#Complex, Kernel#Float, Kernel#Integer, and Kernel#Rational take an :exception option to specify the way of error handling. [Feature #12732]
  • Kernel#system takes an :exception option to raise an exception on failure. [Feature #14386]

予想外の入力に対して、例外を起こすか、nil を返すかは、API デザインにとって難しい問題です。例えば、Array#[] は、範囲外アクセスを行うと nil を返します。Array#fetch(index) では、範囲外では例外を返します。Array#[] のほうが圧倒的に短いため、普通は Array#[] を使うと思いますが、その辺(なにをデフォルトに置くか)は言語デザインの妙なのかなと思います。

さて、Kernel#Integer(obj) は、何か obj を与えると、良い感じに整数に変換してくれるメソッドです。ただ、変換できない場合、例外を発生します。

p Integer('hello')
#=> `Integer': invalid value for Integer(): "hello" (ArgumentError)

JSON などをパースするとき、整数としてパースできるかな、という検査をするとき、このメソッドが使えそうですが、失敗時にいちいち例外が発生してしまうと、ちょっと面倒です(プログラムを書くのも面倒だし、性能が落ちてしまうのもいや)。そこで、exception: false というキーワード引数を指定することで、整数への変換に失敗すると、例外ではなく、単に nil を返すようにしました。

Integer だけでなく、Kernel#Complex, Kernel#Float, Kernel#Rational にも同様についたようですね。

似た話で、system() で実行が失敗したときに例外を発生することができるようになりました。

p system("ruby -e raise") #=> false
p system("ruby -e raise", exception: true)
#=> `system': Command failed with exit 1: ruby -e raise (RuntimeError)

(ko1)

File.read('| ...') が出来なくなった

  • File.read, File.binread, File.write, File.binwrite, File.foreach, and File.readlines do not invoke external commands even if the path starts with the pipe character '|'. [Feature #14245]

File.read('| cmd') のように実行すると、cmd の実行結果を返す、みたいな機能があったんですが、File って言ってるのにコマンド実行しちゃうのは罠だろう、ということで、例外になることになりました。

もし必要なら、 IO.read('| cmd') などを使ってください。

(ko1)

String#crypt が非推奨に

crypt(3) はなんかもう古くて脆弱なので消しましょう、ということで、2.6 では非推奨となりました。まあ、String クラスのメソッドにするのは現代から見たらやりすぎですよね。

互換レイヤとして string-crypt gem がリリースされています。

require "string-crypt"

とすれば String#crypt が利用可能になります。これを書きながら気づいたんですが、この gem は Linux でビルドできませんでした。PR を投げておいたのでお待ちください。(なお、Ruby 2.6 でも組み込みの String#crypt が消えたわけではないので、今すぐ困ることはないはずです)

(mame)

Time オブジェクトのタイムゾーンを指定できるように

  • Time.new and Time#getlocal accept a timezone object as well as a UTC offset string. Time#+, Time#-, and Time#succ also preserve the timezone. [Feature #14850]

タイムゾーンを指定した Time オブジェクトを作る方法が環境変数経由しか無かった(びっくり!)ということで、API が追加されました。

Time.new(2018, 12, 25, 0, 0, 0, tz)

tz として渡すオブジェクトは、local_to_utcutc_to_localutc_offset の 3 つのメソッドを実装している必要があるらしいです。

追記(2018/12/25 15:58):local_to_utcutc_to_local が必須、abbrname があると望ましいらしいです。 (mame)

Array#unionArray#difference

それぞれ、Array#|(和集合)と Array#-(差集合)の別名です。

p [1, 2, 3].union([2, 3, 4])      #=> [1, 2, 3, 4]
p [1, 2, 3].difference([2, 3, 4]) #=> [1]

となると Array#& の別名の Array#intersection もありそうなものですが、こちらは導入されていません。なぜなら要望が来なかったので(貢献チャンスかも?)。

追記(2018/12/25 12:33):単なる別名ではなく、任意個の引数がとれるという微妙な違いがありました。

(mame)

Array#select の別名として Array#filter が追加

select の別名です。

[1, 2, 3, 4, 5].filter {|n| n.odd? } #=> [1, 3, 5]

filter というと、該当するものを残すのか(select と同じ)、それとも消すのか(reject と同じ)、曖昧だという声もありましたが、他の言語では残すのが多そうということで、select と同じということになったようです。

#filter!#select! の別名として追加されています。Array 以外に Enumerable や Hash なども同様に追加されてます。

(mame)

Binding#source_location の追加

Binding が作られたファイル位置を返すメソッドが追加されました。[Feature #14230]

# test.rb
bndg = binding # ここは 2 行目

p bndg.source_location #=> ["test.rb", 2]

これには中々面倒くさい背景があります。

現在、eval 内で例外が発生すると、binding 引数由来のファイル名や行番号を表示してしまいます。

bndg = binding # ここは 1 行目

eval(<<END, bndg)
  def foo  # bndg 基準では 1 行目
    raise  # bndg 基準では 2 行目
  end
END

foo #=> Traceback (most recent call last):
    #       1: from test.rb:9:in `<main>'
    #   test.rb:2:in `foo': unhandled exception

例外のスタックトレースを見てください。2 行目で例外が発生したと言われています。しかし、このファイルの 2 行目を見ると、空行です。びっくり。この問題を避けるために、evalbinding 引数の生成元のファイル名や行番号を利用しないようにしよう、ということになりました。[Bug #4352]

しかしこの変更を実際に試したところ、eval("[__FILE__, __LINE__]", bndg) として Binding の生成元のファイル名や行番号を取り出すというイディオムが pry など一部のプログラムで利用されていることが発覚しました。このイディオムはあまり推奨されるものでもないので、この情報をより明示的に取り出す手段の Binding#source_location を導入し、世の中のプログラムではこちらを使うように変えてもらう期間を置くことにしました。

なお、Ruby 2.6 でこのイディオムを警告ありモードで実行すると、警告が出るようになっています。

$ ./ruby -w
eval("[__FILE__, __LINE__]", binding)
-:1: warning: __FILE__ in eval may not return location in binding; use Binding#source_location instead
-:1: warning: __LINE__ in eval may not return location in binding; use Binding#source_location instead

(mame)

Dir#each_child

Ruby 2.5 で導入された、ディレクトリの中を探る(ただし、., .. は列挙しない) Dir.childrenDir.each_child というクラスメソッドはあるけど、Dir.open で生成する Dir インスタンスで使える Dir#each_childDir#children はないから入れましょう、という提案で、「そうだね」とすんなり入りました。

こういう、「そうだね」という提案ばかりだと楽なんですが。

(ko1)

Exception#full_message に highlight, order キーワード引数がついた

  • Exception#full_message takes :highlight and :order options. [Bug #14324]

まぁ、書いてあるとおりなのですが、引数がつきました。そもそも、Exception#full_message とは、って感じですが、ログとかに出力するため、文字列でバックトレース表記(+エラー原因)を出力するために Ruby 2.5 で導入されたものです。これに、いろいろカスタマイズするオプションがついた感じです。

(ko1)

Hash#merge#merge! が任意個の引数を受け取るようになった

  • Hash#merge, Hash#merge!, and Hash#update now accept multiple arguments. [Feature #15111]

Hash#merge が任意個の引数を受け取るようになりました。h1.merge(h2).merge(h3) と書かなくて良くなります。

h1 = { 1 => 1 }
h2 = { 2 => 2 }
h3 = { 3 => 3 }
h1.merge(h2, h3) #=> { 1=>1, 2=>2, 3=>3 }

クックパッドが開催した、Ruby をハックしてみようというイベント Cookpad Ruby Hack Challenge #5 の参加者の方が提案して、作成したパッチが取り込まれました。めでたいですね。Ruby Hack Challenge は、今後もちょくちょく開催すると思うので、貢献してみたい人はぜひご参加ください。

(mame)

open のモードに修飾子 "x" が追加

  • Added new mode character 'x' to open files for exclusive access. [Feature #11258]

Kernel#open などのモードに "x" という修飾子が追加されました。"w" と組み合わせて使うと、ファイルをうっかり上書きしなくて済むようになります。

open("file", "w")  # file を作って開く(すでに file があったら上書き)
open("file", "wx") # file を作って開く(すでに file があったら例外)

(mame)

KeyError 発生原因の receiverkey を Ruby レベルで指定可能に

  • KeyError.new accepts :receiver and :key options to set receiver and key in Ruby code. [Feature #14313]

Ruby 2.5 から、KeyError が発生したときのレシーバとキーが KeyError インスタンスから参照できるようになっています。

begin
  { 1 => 2 }.fetch(:foo)
rescue KeyError => e
  p e.key      #=> :foo
  p e.receiver #=> {1=>2}
end

このように、組み込みの Hash#fetch は内部的にこれらの情報を設定していたのですが、Ruby レベルで投げる例外にこの情報を設定することができませんでした。2.6 では、次のようにできるようになりました。

raise KeyError.new(receiver: recv, key: key)

NameErrorNoMethodError でも、同様に receiver が指定できるようになりました。

(mame)

Module#method_defined? とかが inherited オプショナル引数を受けるようになった

  • Module#method_defined?, Module#private_method_defined?, and Module#protected_method_defined? now accept the second parameter as optional. If it is +true+ (the default value), it checks ancestor modules/classes, or checks only the class itself. [Feature #14944]

細かい話です。

Module#instance_methods は、inherited オプショナル引数を受け取ることができます。デフォルトは true ですが、false にすると、クラスの継承木を辿らないで、そのクラス・モジュールだけ調査します。

p String.instance_methods(true).size   #=> 183
String.ancestors.each{|c|
  p [c, c.instance_methods(false).size]
}
#=>
# [String, 128]
# [Comparable, 7]
# [Object, 0]
# [Kernel, 50]
# [BasicObject, 8]
# 合計 193 ... あれ、あわないよ?
# というのは、10個ほど、重複するメソッドがあるからです(多分)。
# ちなみに、String の 128 個というのはキリが良いですね。

このように、いくつかのメソッドには、inherited オプショナル引数を取りますが、似たようなメソッドで、それを取らないものがあったので、似たようなもの全部に入れてしまえばいいのでは、という提案があって、イイネイイネと入りました。

(ko1)

Object#=~ が非推奨に

Object#=~ が非推奨になりました。と言うとびっくりするかもしれませんが、String#=~Regexp#=~ は残るので、gets =~ /regexp/ みたいな普通のマッチングは引き続き可能なので、ほとんど影響はないはずです。

Object#=~ は、引数にかかわらず常に nil を返すという、あまり用途のわからないメソッドでした(導入経緯も調べたのですが、古すぎてよくわかりませんでした)。

p(1 =~ 1) #=> nil

用途がわからないだけでなく、運が悪いとバグを隠すことがあった(次のような例)ので、非推奨ということになりました。

s = ["foo"] # 文字列のつもりだったのに、うっかり文字列の配列にしてしまった
if s =~ /foo/
  puts "マッチしない……なぜ……"
end

なお、nil はマッチング対象にしたいことがある(たとえば ENV['non_existing'] =~ /regexp/)ということで、NilClass#=~ は新たに導入されました。

Object#=~ と対になる Object#!~ は、非推奨になっていません。!~=~ を呼び出してその返り値の not をとって返すので、自分のクラスに =~ だけを定義するというプログラムが存在します。そういうプログラムは完全に無実であること、また !~ が残っていても =~ がなければ結局 NoMethodError になるだけで実害はないことから、そのまま残されることになりました。

(mame)

Random.bytes が導入

ちょっとした便利メソッドです。

p Random.bytes(3) #=> "\xCF\xB5\xF4"

提案チケットは 2011 年に登録されていて、非常に長い間放置されていました。遠藤が古いチケットを整理しているときに見つけたので、開発者会議の議題にあげて無事採択されました。つまり遠藤がえらい。

(mame)

String#split がブロックを受け取るように

  • String#split yields each substring to the block if given. [Feature #4780]

String#split にブロックを渡すと、区切られた各断片が yield されてくるようになりました。

"foo/bar/baz".split("/") {|s| p s } #=> "foo", "bar", "baz"

これも 2011 年からほったらかしだったチケットを掘り起こした成果です。えらい。

(mame)

Unicode のバージョンが 10.0.0 から 11.0.0 に

  • Update Unicode version from 10.0.0 to 11.0.0. [Feature #14802] This includes a rewrite of the grapheme cluster (/\X/) algorithm and special-casing for Georgian MTAVRULI on String#downcase.
  • Update Emoji version from 5.0 to 11.0.0 [Feature #14802]

Unicode のバージョンが上がったようです。あと Emoji も。正直よくわからないのですが、たとえばジョージア語の大文字が導入されたそうです。

p "ლალი".upcase #=> "ლალი" in 2.5
                 #=> "ᲚᲐᲚᲘ" in 2.6

(mame)

Ruby の抽象構文木を取り出す実験 API が導入

  • RubyVM::AbstractSyntaxTree class is added.
  • RubyVM::AbstractSyntaxTree.parse parses a given string and returns AST nodes. [experimental]
  • RubyVM::AbstractSyntaxTree.parse_file parses a given file and returns AST nodes. [experimental]

なぜか結構話題の、抽象構文木を取り出す API が実験的に導入されました。

ast = RubyVM::AbstractSyntaxTree.parse("1 + 2 * 3")

pp ast #=>
# (SCOPE@1:0-1:9
#  tbl: []
#  args: nil
#  body:
#    (OPCALL@1:0-1:9 (LIT@1:0-1:1 1) :+
#       (ARRAY@1:4-1:9
#          (OPCALL@1:4-1:9 (LIT@1:4-1:5 2) :*
#             (ARRAY@1:8-1:9 (LIT@1:8-1:9 3) nil)) nil)))

RubyVM::AbstractSyntaxTree#children を使うと、サブツリーを取り出せます。

pp ast.children[2] #=>
# (OPCALL@1:0-1:9 (LIT@1:0-1:1 1) :+
#    (ARRAY@1:4-1:9
#       (OPCALL@1:4-1:9 (LIT@1:4-1:5 2) :* (ARRAY@1:8-1:9 (LIT@1:8-1:9 3) nil))
#       nil))

RubyVM::AbstractSyntaxTree.parse_file なんてのもあります。

さて、この API がどういうときに便利かと言うと、実際のところ、そんなに便利ではないと思います。というのも、この抽象構文木は、MRI の評価器の実装に結びついてて読み解くのは難しいし、もちろんドキュメントは無いし、今後の Ruby のバージョンアップで説明なく非互換な変更が入っていくし、微妙に最適化っぽい変換がされててソースとの対応が取りにくいし、という感じで、一般ユーザがカジュアルに使うものではないです(RubyVM という名前空間にあるものは、そういうプロユースのものです)。想定用途は、Ruby 本体のデバッグやテスト、Ruby のバージョンアップに食いついていく覚悟のあるプログラム(たとえば静的解析器とか)などです。普通に Ruby の抽象構文木で遊びたい人は、たぶん parser gem を使うのがよいと思います。

(mame)

RubyVM::AbstractSyntaxTree.of

  • RubyVM::AbstractSyntaxTree.of returns AST nodes of the given proc or method. [experimental]

メソッドオブジェクトや Proc オブジェクトから抽象構文木オブジェクトを取り出す API です。

def f
  1 + 2 + 3
end

pp RubyVM::AbstractSyntaxTree.of(method(:f))
#=> (SCOPE@2:0-4:3
#    tbl: []
#    args:
#      (ARGS@2:5-2:5
#       pre_num: 0
#       pre_init: nil
#       opt: nil
#       first_post: nil
#       post_num: 0
#       post_init: nil
#       rest: nil
#       kw: nil
#       kwrest: nil
#       block: nil)
#    body:
#      (OPCALL@3:2-3:11
#         (OPCALL@3:2-3:7 (LIT@3:2-3:3 1) :+ (ARRAY@3:6-3:7 (LIT@3:6-3:7 2) nil))
#         :+ (ARRAY@3:10-3:11 (LIT@3:10-3:11 3) nil)))

これはもう完全な闇 API です。というのも Ruby インタプリタは、読み込んだソースコードをバイトコードにコンパイルし終えた後は、ソースコード文字列も抽象構文木も捨ててしまうので、本来この抽象構文木は取り出しようがないはずのものです。どのようにしているかと言うと、

  • パース時に、すべてのノードに番号を振っておく
  • 抽象構文木のコンパイル時に、元ソースファイル名やルートノードのノード番号をバイトコードに書き加えておく
  • RubyVM::AbstractSyntaxTree.of が呼ばれたら、メソッドオブジェクトなどのバイトコードが持つ元ソースファイル名とノード番号を引っ張り出す
  • ソースファイルをもう一度開いて、読み込み、パースし直して、対応するノード番号のサブツリーを特定し、抽象構文木オブジェクトとして返す

というハックになっています。なので、ソースファイルの中身が変わっていたり、ソースコードを標準入力などで流し込んだ場合は、RubyVM::AbstractSyntaxTree.of は使えません。闇ですよね。覚悟なしに使わないでください。

(mame)

RubyVM.resolve_feature_path

  • RubyVM.resolve_feature_path identifies the file that will be loaded by require(feature). [experimental] [Feature #15230]

require は、(1) 読み込むファイルのパスを特定する、(2) そのファイルを読み込んで実行する、の 2 段階を行いますが、RubyVM.resolve_feature_path は (1) だけをやる API です。

静的解析を作るときにほしいなーという気分だったのでとりあえず作ってみました。RubyVM の名前空間にある通り、一般ユーザが使うことは想定されていません。もし何か用途があったら、ちゃんとした API として導入することも検討できると思うので、教えてください。

(mame)

TracePoint の拡張

いろいろ便利だったり悪用できたりする TracePoint ですが、いくつか拡張がありました。そもそも、使う人が居なさそうなのに、さらに複雑な拡張が入ったので、普通の人は気にしないでいいと思います。普通じゃない人には待望の機能です。

まず、TracePoint#enable で、target: キーワード引数が導入され、フックを有効にする場所を指定することができるようになりました。

TracePoint(と、その前身となった set_trace_func)は、フックを登録すると、すべての場所でフックが呼ばれるようになります。例えば、あるファイルのある行を実行したときだけ、フックを実行したい、というケースを考えます。つまりブレイクポイントですね。これまでは、フックの中で場所(ファイル名と行番号)を確認する、ということを行っていました。ちょっと考えるだけでも非効率です。TracePoint#enable(target:) を指定することで、本当にフックが欲しいところだけでチェックできるようになりました。

次に、新イベントscript_compiled に対応しました。スクリプトをバイトコード(MRI用語では ISeq: InstructionSequence、命令列)にコンパイルしたタイミングで呼ばれます(ついでに便利メソッドがいくつか増えています)。

この新イベントと TracePoint#enable(target:) を組み合わせることで、(例えば)ブレイクポイントが便利に実装できることになります。

なお、TracePoint の拡張については、後日改めてまとめます。

追記:まとめました。

techlife.cookpad.com

(ko1)

ライブラリの変更

あまり詳しくないので、わかるところだけピックアップしてご紹介します。

Bundler の同梱

Bundler がついに、Ruby と一緒にインストールされるようになりました。もう、gem i bundler としなくてもよくなります。

今後 rubygems と少しずつ統合が進んでいくそうです。

(ko1)

oneshot coverage の導入

  • A oneshot_lines mode is added. [Feature #15022] This mode checks "whether each line was executed at least once or not", instead of "how many times each line was executed". A hook for each line is fired at most once, and after it is fired the hook flag is removed, i.e., it runs with zero overhead.

コードカバレッジ測定機能に、oneshot coverage という新モードを追加しました。 これは、各行の実行回数ではなく、各行が1回でも実行されたかどうかを記録するものです。

oneshot coverageについては、明日詳説する記事を書く予定です。

追記(2018/12/26 10:46):書きました。

techlife.cookpad.com

(mame)

FileUtils#cp_lr

ディレクトリの中の全ファイルを再帰的にハードリンクしていくメソッドです。cp -r と似ていますが、コピーの代わりにハードリンクをします。

2010 年に提案されていて放置されていたチケット [Feature #4189] をチケット整理で掘り起こした成果です。えらい。

(mame)

Matrix の拡張

Matrix が交代行列かどうかを判定する Matrix#antisymmetric? が追加

  • Matrix#antisymmetric?, Matrix#skew_symmetric?

交代行列とは、転置して符号反転させたら元の行列と一致する行列のことです。日本語で言うとややこしいですが、行列 mm.t == -m を満たすなら交代行列です。

これを判定するメソッド antisymmetric? が追加されました。skew_symmetric? という別名も入っています。

以下、どうでもよい話。このメソッドにはなかなかややこしい経緯がありました。このメソッドはそもそも、反対称関係(antisymmetric relation)の行列表現の判定として提案され、取り込まれました。しかし、反対称関係の行列表現とは別に、反対称行列(antisymmetric matrix、日本語では交代行列)という概念があります。Matrix#antisymmetric? という名前なので、「反対称行列の判定がなにかおかしい」というバグ報告が来て、現在の挙動に変わりました。しかし不幸なことに、この行列は数学の分野ではあまり反対称行列とは言わず、歪対称行列(skew-symmetric matrix)と言います(ただし、物理学の世界では antisymmetric matrix が普通らしい)。ということで Matrix#skew_symmetric? の別名も追加されました。なお、日本語では交代行列ということが多いですが、英語で alternating matrix とはどの分野でもあまり言わないようです(ゼロでもないみたいですが)。名前がこんがらがると不幸が起きるという例でした。

(mame)

Matrix の破壊的更新が可能に

  • Matrix#map!, Matrix#collect! [Feature #14151]
  • Matrix#[]=
  • Vector#map!, Vector#collect!
  • Vector#[]=

Matrix#[]= で要素の破壊的更新ができるようになってしまいました。[Feature #14151]

Matrix#map!#collect!Vector#map!#collect!Vector#[]=なども入っています。

個人的に、Matrix みたいな数の一種が破壊的に更新可能なのはとても違和感があるのですが。Matlab とかの方から来た人は、更新したくなるようです。

(mame)

性能向上

最後に、みんな大好き性能向上の話です。本章の執筆は全て笹田 (ko1) が担当します。

MJIT

  • Introduce an initial implementation of JIT (Just-in-time) compiler. [Feature #14235] [experimental]

MJIT という JIT コンパイラが導入されました。Ruby 2.6 の目玉ですね。

私が何か説明するよりも、国分さんの解説記事(Ruby 2.6のJITで実装か検討を行なった最適化集 - Qiita)や発表資料( https://speakerdeck.com/k0kubun )などを見て貰うのが正確で良いと思います。他の人も沢山解説記事を書いているようですし。

現状では、バイトコード実行することによるオーバヘッドを、MJIT によって削減する、といった程度の効果なので、すごく劇的に性能向上、というレベルではありません。いろいろな理由で、Rails での性能向上も、まだ難しいでしょう(他人の仕事には厳しい)。今後、どこまで速くなるか楽しみですね。

Proc まわりの性能向上

ブロックパラメータで渡された Proc#call で呼んでも速い

  • Speedup block.call where block is passed block parameter. [Feature #14330] Ruby 2.5 improves block passing performance. [Feature #14045] Additionally, Ruby 2.6 improves the performance of passed block calling.

Proc まわりでは、def foo(&b); ... baz(&b) のように、渡されたブロックを、別のメソッドに単に渡すだけなら、Proc オブジェクトをわざわざ作らないので速くなる、というハックを Ruby 2.5 で導入しました(Ruby 2.5 の改善を自慢したい)。Ruby 2.6 では、その続きで、もう少しいろいろしています。

大抵、&b と渡ってきたブロックは、yield じゃなくて b.call って呼びたくなると思うんですが、Ruby 2.5 では、結局ここで(b を参照した時点で)Proc オブジェクトを生成してしまので、遅いという問題がありました。

Ruby 2.6 では、ちょっと工夫して(説明が面倒なので詳細割愛)、Proc を生成しなくても済むようになりました。チケットにはどれくらい高速になったか書いていないのですが、下記のベンチマークで試してみると、

Benchmark.driver{|x|
  x.executable name: 'ruby 2.5', command: %w'/home/ko1/ruby/install/ruby_2_5/bin/ruby'
  x.executable name: 'ruby 2.6', command: %w'/home/ko1/ruby/install/trunk/bin/ruby'

  x.prelude %q{
    def foo(&b); b.call; end
    def bar(); yield; end
  }
  x.report 'b.call', %q{
    foo{}
  }
  x.report 'yield', %q{
    bar{}
  }
}
Warming up --------------------------------------
              b.call     2.719M i/s -      2.815M times in 1.035435s (367.78ns/i)
               yield    13.591M i/s -     13.646M times in 1.004094s (73.58ns/i, 272clocks/i)
Calculating -------------------------------------
                       ruby 2.5    ruby 2.6
              b.call     3.451M     12.293M i/s -      8.157M times in 2.363882s 0.663573s
               yield    15.725M     19.970M i/s -     40.772M times in 2.592803s 2.041643s

Comparison:
                           b.call
            ruby 2.6:  12292769.5 i/s
            ruby 2.5:   3450742.9 i/s - 3.56x  slower

                            yield
            ruby 2.6:  19970380.1 i/s
            ruby 2.5:  15725212.8 i/s - 1.27x  slower

こんな結果になり、この環境だと Ruby 2.5 と比べて 3.56 倍くらい速いようです。 ただ、やっぱりまだ yield よりは遅いですね。もうちょと頑張って欲しい。しかし、なんで Ruby 2.6 で yield こんなに速いんだろう。

$SAFE を一部諦めて Proc#call を高速化

  • Speedup Proc#call because we don't need to care about $SAFE any more. [Feature #14318] With +lc_fizzbuzz+ benchmark which uses Proc#call many times we can measure x1.4 improvements. [Bug #10212]

$SAFE という古の機能があるのですが(何の機能かはググってね)、この仕様の一部をこっそり削って、Proc#call が高速になりました。たくさん Proc#call を実行するベンチマークでは、1.4 倍の速度向上が得られたようです。やったね。

具体的に何をしたかというと、Proc#call を呼び出した時の $SAFE を保存しておいて、Proc#call が終了したとき、必ず保存しておいた状態に戻す、という仕様があったんですが、それを撤廃しました。戻すだけなら簡単じゃん、と思うかもしれませんが、「必ず戻す」というのがくせ者で、例外時などでも戻せるように、いろいろ準備が要るのでした。

ただ、そもそも $SAFE を誰も利用しないので、この値を戻す必要がないことが大半で、無駄な努力でした。と言う事情を開発者会議で説明すると、「じゃあやめよう」とすんなりやめることになりました。そのため、元に戻すための諸々のコードが不要になり、軽量になりました。

VM生成系の一新

  • VM generator script renewal; makes the generated VM more optimized. [GH-1779]

VM 生成系と言われてもよくわからないと思いますので、ちょっと解説します。

現在の MRI の仮想マシンは、直接ソースコードを全部書くわけではなく、insns.def というファイルに、命令定義が記述してあります。このファイルを、ある Ruby スクリプトを通すことで、C のソースコードに変換し、それを使って MRI バイナリが完成します。つまり、Ruby のビルドには Ruby が必要です。この「ある Ruby スクリプト」が VM 生成系です。

で、この VM 生成系なんですが、私が10年以上も前に、1ファイルに汚く書き散らしていたモノを Ruby 2.5 までは使っていました。それを今回卜部さんがモダンな感じにファイルを分割したりして整理してくれました。これで、さらに insns.def ファイルに情報を入れやすくなりました。

ということで、すでに最適化に必要な情報を入れたりして VM の実行がいくらか高速化されています。何もしなくても、Ruby 2.6 にバージョンアップするだけで数%速くなる、かもしれません。

スレッドキャッシュの有効化

  • Thread cache enabled for pthreads platforms (for Thread.new and Thread.start). [Feature #14757]

スレッドのキャッシュが有効化されました。ってだけだとわかんないですよね。

Ruby(MRI)のスレッドはネイティブスレッドと1対1対応なので、Thread.new{...} でスレッドを作成すると、OS などが提供するネイティブスレッドの生成が必要になります。例えば、POSIX Thread が利用できる環境では、Ruby は POSIX Thread を pthread_create() 関数を用いて作るのですが、これが重い(ことが多い。実装方法によります)。例えば、Linux では重い。

そこで、このパッチでは、終了して使わなくなった POSIX Thread は少しの間キャッシュしておいて、また Thread.new{...} でスレッドを生成したら、そのキャッシュされたものを使う、というものになります。ベンチマークによっては 70 倍程度速くなったそうです。スレッドを作っては捨て、と繰り返すような、ちょっと特殊かも知れない処理ですね。

なお、「少しの間」というのは、5秒間のようです。

3rd party library が TLS (Thread Local Storage) を用いて、初期値に依存していたりすると、もしかしたらまずいことが起こるかも知れません(再利用されたときは、初期値は前のスレッドの値が残っているため)。もし、そういう例を知っていたら教えてください。

タイマースレッドを不用に

  • timer thread is eliminated for platforms with POSIX timers [Misc #14937]

スレッドを扱うために、インタプリタ内部で、タイマースレッドというものを利用していました。タイマースレッドのために、Ruby プロセスを起動すると、かならず(メイン処理用のスレッドとあわせて)2 つネイティブスレッドを作るようになっていました。

Ruby 2.6 では、POSIX timer API が使えるなら、それを用いることで、タイマースレッドを生成しなくても良くなりました。起動時間の削減と、メモリ等のリソース消費削減に、少し効果ありそうです。

しかし、昔タイマースレッドを導入したのは私(ko1)なんですが、今回の Eric Wong さんによるこの変更、難しすぎて理解できてないんですよね...。

Fiber の実装向上

  • Native implementations (arm32, arm64, ppc64le, win32, win64, x86, amd64) of coroutines to improve performance of Fiber significantly. [Feature #14739]

NEWS エントリ的には「コルーチンをネイティブで実装した」ってありますが、コルーチンを実装するための API を CPU ごとに書いたって話になります。だいたいアセンブラで書いてあります。

技術的には、Fiber の実装には(POSIXの場合)swapcontext といった(現在では非推奨の)API を使っているのですが、こいつらが Fiber の実装にとって、若干無駄な処理をしていました。多分、一番無駄だったのは signal 関連の処理です。今回は、そういう無駄な処理を除いたコンテキスト切り替えの API を独自に作った、というものです。

Fiber 切り替えを沢山行うマイクロベンチマークでは数倍、環境によっては20倍くらい速くなったそうです。また、聞くところによると、Fiber を利用するウェブアプリで数%の性能向上があったとか。

TransientHeap による効率的なメモリ確保

  • Transient Heap (theap) is supported. [Bug #14858] [Feature #14989] theap is managed heap for short-living memory objects. For example, making small and short-living Hash object is x2 faster. With rdoc benchmark, we measured 6-7% performance improvement.

Transient Heap (theap) という新しいメモリ管理のための仕組みを導入して、短寿命のオブジェクトの生成が2倍くらい速くなりました。ただし、対応しているのは、限られたオブジェクトだけで、一番効きそうな String については未対応です。

これについては、後日改めてまとめます。

追記:まとめました。

techlife.cookpad.com

まとめ

Ruby 2.6 の NEWS ファイルの内容を駆け足でご紹介しました。ご紹介したとおり、変更いっぱいありますが、まぁ普段使ってる分にはあまり変らないと思うので、とりあえずバージョンアップしてみてはいかがでしょうか。

なお、本稿をまとめるにあたり、Ruby コミッタ各位にいろいろ「この説明で良い?」とか、「この変更ってなんでやったの?」とか、「なんでこんな仕様にしたの?」といったことを聞いて回りました。快く答えて頂きました各位に御礼申し上げます。

で、その調査の過程で、いくつかのバグを見つけたので、本稿は Ruby 2.6 のリリースに貢献しています。褒めて欲しい。

では、良い Ruby 2.6 ライフをお送りください。メリークリスマス。

(ko1)

*1:ko1: Matz が最近見つけたと言っても、私が気づいた時にはそういう仕様だったので、そういうもんだと思っていたよ...(Ruby 2.1 当時)。

*2:mame: 純粋関数型データ構造っていう、そんなことばかり考えてる本があります。

EnvoyCon 2018 Seattle で登壇しました

f:id:aladhi:20181217091426p:plain

こんにちは、Taiki です。先日、Envoy proxy のためのカンファレンスである EnvoyCon 2018 がシアトルで開催され、参加・登壇してきたので、私の発表内容や他の登壇者の内容をいくつかこの記事では紹介できればと思います。また、EnvoyCon は KubeCon + CloudNativeCon North America 2018 の co-located event として開催されたのもあり、KubeCon + CNCon にも参加してきたので、そちらのほうからも Envoy 関係の発表をいくつか紹介します。

クックパッドの発表

クックパッドではおよそ1年前から Envoy をサービスメッシュの data plane proxy として利用しています。クックパッドは Amazon ECS を使用しているのもあり、サービスメッシュの構築にあたり、自分たちの requirements や環境に合う製品が見つからなかったので、自社で control plane を開発するアプローチを採用しました。事前に生成した Envoy proxy 向けの xDS response を Amazon S3 を用いて配信する、という設計は Envoy ユーザーの中でもユニークなものであり、その設計の詳細や運用の側面について紹介しました。

EnvoyCon での発表

時系列順にいくつかご紹介します。

まずは Google の Harvey から、Envoy 開発の統計をもとに Envoy の開発状況について誰がどのように開発しているのか、という内容のトークがありました。OSS のユーザーとして、利用している OSS の開発状況やコミュニティは、その OSS プロダクトの将来性に関わることもあり関心があるので、興味深いセッションでした。クックパッドからも私がパッチを送っているのもあり、スライドに少し登場しています。

f:id:aladhi:20181217091530p:plain

次に eBay から Bala と Qiu が、 edge proxy としての Envoy 利用事例の発表をしました。eBay の PoP の中で動いていたハードウェアロードバランサーを、visibility の強化やより柔軟なトラフィックルーティングを実現するために、Envoy で置き換えるというチャレンジングな内容でとても楽しめました。

次に Yelp の Ben と John から、Yelp でのサービスメッシュの進化と data plane の Envoy への置き換えについてセッションがありました。Yelp では以前より HAProxy ベースのサービスメッシュを運用していて、そのサービスメッシュの改善・進化についての発表でしたが、”小さく始める” ポリシーやプロダクトの開発に集中するといった考え方がクックパッドでの考え方に近く、親近感を持ちながらセッションを聞きました。

次に、Google の Alyssa から、 Envoy のセキュリティ面での強化(hardening) について発表がありました。Google では全てのトラフィックを受け持つ frontend proxy での Envoy 利用が進んでいるようで、そのために Envoy のセキュリティ面、特に攻撃に対する耐性の強化についての発表でした。こちらは個人的に興味関心がある分野で興味深く聞きました。

他にも非常に興味深い発表が盛りだくさんでした。Twitter の #envoycon ハッシュタグ でも様子を少しつかめるのでぜひご覧ください。

KubeCon + CNCon での発表

Lyft から Daniel が、 database traffic に Envoy を利用している事例について発表しました。主な目的はメトリクスの確保です。Envoy はすでに Redis, DynamoDB, MongoDB への通信に対応したフィルターを実装しており、それを利用してどのような利点があったか、という内容でした。クックパッドでは MySQL, PostgreSQL の利用が主であり、Envoy のフィルターの実装を待つか手伝う必要があるのですぐには実現は難しいのですが、今後導入を図りたいと個人的に考えています。

Keynote, Envoy Update: Lyft から Matt, Constance, Jose の3人が Envoy の近況についてキーノート発表をしました。今回の KubeCon + CNCon での Envoy の盛り上がりを感じられるセッションかなと思います。

KubeCon + CNCon はすでにある程度 YouTube にセッション動画がアップロードされています。EnvoyCon も録画をしている様子があったので、そのうちアップロードされるのではないかと思います。

終わりに

Envoy やサービスメッシュに関連する事例を共有しあったり、現在の課題や実現を目指していることなどをお互いに話し合える場は大変貴重で、とても楽しみ、また数々の学びがありました。

クックパッドという会社はこのような海外登壇であっても強力にバックアップしてくれます。また、先進的な領域で問題に取り組み成果を出しやすい環境があります。興味のある方はぜひ下記のリンクよりコンタクトください。

https://info.cookpad.com/careers

We’re hiring!

/* */ @import "/css/theme/report/report.css"; /* */ /* */ body{ background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527163350.png'); background-repeat: repeat-x; background-color:transparent; background-attachment: scroll; background-position: left top;} /* */ body{ border-top: 3px solid orange; color: #3c3c3c; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; line-height: 1.8; font-size: 16px; } a { text-decoration: underline; color: #693e1c; } a:hover { color: #80400e; text-decoration: underline; } .entry-title a{ color: rgb(176, 108, 28); cursor: auto; display: inline; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; font-size: 30px; font-weight: bold; height: auto; line-height: 40.5px; text-decoration: underline solid rgb(176, 108, 28); width: auto; line-height: 1.35; } .date a { color: #9b8b6c; font-size: 14px; text-decoration: none; font-weight: normal; } .urllist-title-link { font-size: 14px; } /* Recent Entries */ .recent-entries a{ color: #693e1c; } .recent-entries a:visited { color: #4d2200; text-decoration: none; } .hatena-module-recent-entries li { padding-bottom: 8px; border-bottom-width: 0px; } /*Widget*/ .hatena-module-body li { list-style-type: circle; } .hatena-module-body a{ text-decoration: none; } .hatena-module-body a:hover{ text-decoration: underline; } /* Widget name */ .hatena-module-title, .hatena-module-title a{ color: #b06c1c; margin-top: 20px; margin-bottom: 7px; } /* work frame*/ #container { width: 970px; text-align: center; margin: 0 auto; background: transparent; padding: 0 30px; } #wrapper { float: left; overflow: hidden; width: 660px; } #box2 { width: 240px; float: right; font-size: 14px; word-wrap: break-word; } /*#blog-title-inner{*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-position: left 0px;*/ /*}*/ /*.header-image-only #blog-title-inner {*/ /*background-repeat: no-repeat;*/ /*position: relative;*/ /*height: 200px;*/ /*display: none;*/ /*}*/ /*#blog-title {*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527172848.png');*/ /*background-repeat: no-repeat;*/ /*background-position: left 0px;*/ /*}*/