_ Array#to_procとHash#to_proc

Symbol#to_procが存在するのはもちろんのこと、ArrayやHashにto_procを定義するテクニックは便利なので、割と使われています。

[Ruby on Rails 4.0.1リリース！大量のバグ修正、3系からの移行も少し簡単になりましたより引用]

というのを見て、最近はそういう流行があるのかと思っていたら、松田さん曰く

@yukihiro_matz @shugomaeda そんなもんまったく使われてないし便利でもなんでもないと思いますよ。例によってというかなんというかfacetsにはあるみたいですが、特に便利なようには見えないですね。

[Twitter / a_matsuda: @yukihiro_matz @shugomaeda ...より引用]

とのこと。

でもそう言われるとほんとにそうなのかなと考えたくなる。

Array#to_proc

案1

まず、Adding Array#to_proc to Rubyの案。

class Array
  def to_proc
    lambda { |target| target.send(*self) }
  end
end
%w(kung ruby bar).map &[:+, "-fu"] #=> ["kung-fu", "ruby-fu", "bar-fu"]

配列の最初の要素をメソッド名として、残りの要素を引数とする案。

発想的にはSymbol#to_procの延長線上にあるものだけど、Symbol#to_procより読みにくく感じるのと、最初の要素と残りの要素の扱いがまったく異なるところが気持ち悪い。 a.map &[:+, "-fu"]よりa.map { |i| i + "-fu" }の方が読みやすいし、a.map {|i|i+"-fu"}のように空白を詰めると文字数も変わらない。

案2

続いてArray#to_procの

Person.find(:all).collect {|person| [person.name, person.id]}

を

Person.find(:all).collect(&[:name,:id])

と書けるようにしようという案。

そもそもActiveRecordで全部の列をSELECTしてからcollectで間引くコードは筋が悪い。

最近のActiveRecordなら

Person.pluck(:name, :id)

でいい。

ActiveRecord以外での使い道もあまりないように思うし、map/collect以外に使えなさそうなのも減点要素。

Hash#to_proc

案1

まず、Facetsの案。

c = Class.new do
  attr_accessor :a
end

h = {:a => 1}
o = c.new
h.to_proc.call(o)
o.a  #=> 1

のようにHashの要素を与えられたオブジェクトのsetterに渡してセットするというもの。

Array#to_procの案2にちょっと似てるけど、用途が限定的過ぎてHashに持たせる機能としては適切だとは思えない。

案2

A Hash Is A Function (Hash#to_proc)の案。

class Hash
  def to_proc
    lambda {|x| self[x] }
  end
end

のように定義して、

specialism_codes.map {|code| SPECIALISMS[code] }

を

specialism_codes.map &SPECIALISMS

と書けるようにしようというもの。

ここでfunctionと言っているのは数学的な意味での関数で、たしかに、キーの集合を定義域、値の集合を値域とするような関数とみなせるし、Hash.new {|h,k| k.to_s}のようにデフォルト値をブロックで与えた場合はプログラミングの文脈においても関数そのもの。 Hash#callはないけど、Hash#[]を使えばProc#[]と多相的に扱えるし。

例えば

NG_WORDS = {
  "XXX" => true,
  "YYY" => true,
  ...
}

のようなHashを用意しておくと、

clean_words = words.reject(&NG_WORDS)

や

if words.any?(&NG_WORDS)
  ...
end

のようにmap以外の使い方もできそう。

結論

Hash#to_procの案2だったらあってもいいかなと思うが、今までほしいと思ったことがなかったので必要かと言われるとよくわからない。

他の案はArrayやHashに定義すべきものなのかというところに疑問がある（まあ、Symbol#to_procもそうだったんだけど）し、便利かどうかも疑問だったり、用途が限定されすぎている。

_ ロシア人形キャッシュとキャッシュダイジェスト

Russian-doll Caching (Cache Digests) は、Rails 4 に導入された機能です。これは、複数のフラグメントキャッシュを入れ子にしている場合に、内側のコンテンツの更新に連動して、外側のフラグメントキャッシュのキーが自動的に変更されるというものです。

[Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しましたより引用]

という記事を見て、内側のフラグメントキャッシュ内で使用されているモデルが更新される場合も、外側のキャッシュのキーが自動的に更新されるのかなと勘違いしたけど、そんなわけはなかったのでメモ。

ロシア人形キャッシュ

まず、ロシア人形キャッシュというのは、

<% cache @article do %>
<h1><%= @article.title %></h1>
<p><%= @article.body %></p>
<h2>コメント</h2>
<%= render @article.comments %>
<% end %>

のようなフラグメントキャッシュがあった時に、キャッシュの中で使用しているテンプレート（comments/_comment.html.erb）でも

<% cache comment do %>
<p><%= comment.body %></p>
<p>by <%= comment.name %> at <%= comment.created_at %></p>
<% end %>

のようにフラグメントキャッシュを使うこと。こうすると、外側のキャッシュが無効になった時も内側のキャッシュ（の一部）は有効なことが多いので、更新された場合をレンダリングするだけで済む。

モデル更新時のキャッシュの無効化

内側のキャッシュが無効になった場合は、外側のキャッシュを無効にする必要があるが、belongs_toのtouchオプションを使うと子モデルが更新された時に親モデルのupdated_atを自動的に更新できる（これはRails 3でも使える機能）。

class Article < ActiveRecord::Base
  has_many :comments, dependent: :destroy
end

class Comment < ActiveRecord::Base
  belongs_to :article, touch: true
end

キャッシュのキーはupdated_atを元に生成されるので、updated_atが更新されると古いキャッシュは無効になる（ヒットしなくなる）。

テンプレート更新時のキャッシュの無効化

問題はテンプレートファイルを更新した時で、モデルのデータは変わっていなくても、キャッシュを無効にする必要がある。

従来は、

<% cache ["v1", comment] do %>
…
<% end %>

のようにcacheの引数にテンプレートのバージョンを含めて対応することができた。 フラグメントキャッシュは引数のオブジェクト全体からキャッシュキーを生成するので、commentの方に変更がなくても、"v1"の部分を変えてやればキャッシュキーが変わり、古いキャッシュが無効になる。 ただ、手動でやるのはいかにも面倒くさいし、このテンプレートに依存する他のテンプレート（この場合はarticles/show.html.erb）の方のバージョンを更新するのを忘れるリスクがある。

キャッシュダイジェスト

Rails 4では自動的にテンプレートファイルのダイジェスト値がキャッシュキーに追加されるのでこういったことをする必要がなくなった（これがキャッシュダイジェストという新機能）。 また、テンプレートの依存関係を把握していて、内側のテンプレートが変更された場合も外側のキャッシュのキーが自動的に変更される。

注意点

上記のように賢い機能だが、

<%= render @project.documents.where(published: true).order('created_at') %>

のような複雑なケースだと依存関係を自動では認識してくれないようなので注意が必要。

render partial: 'documents/document', collection: @project.documents.where(published: true).order('created_at')

のようにpartialオプションでテンプレートを明示したり、

<%# Template Dependency: documents/document %>

のようにコメントで依存関係を明示すれば大丈夫らしいけど、render partial:とか冗長だよねとか言ってリファクタリングしてもテストは通るからハマリそうな気がする（Railsってこういう罠が多い気が）。

あと、キャッシュデータそのものは勝手に消えるわけではないので、例えばMemCacheStoreを使っている場合は、以下のようにexpireする時間を指定するなどの工夫が必要になる*1。

config.cache_store = :mem_cache_store, "cache1.example.com", "cache2.example.com", {expires_in: 3.hours}

_ NaClってどんな会社?

Rubyistが楽しく働ける会社は日本でC社くらいじゃないかという話をTwitterで見かけて、Twitterでは自虐的な発言をしていたのだけど、誤解されそうなのでちゃんと書いておく。

C社との比較は置いておいて真面目な話をすると、最近弊社への採用応募が減っているという残念な事実がある。 とくに県外から松江に来たいという人が格段に減っている。 Uターン希望者を除くとほとんど0に近い気がする。

一つにはRubyで仕事をできる会社が増えたことがあると思う。 僕が就職を考えた時(15年くらい前)は一社くらいしか選択肢がなかったけど、今ならRubyアソシエーション認定SIerだけでも90社近くある。 これ自体は喜ばしいことだと思うし、止められるようなものでもない。

もう一つの理由は、NaClがどんな会社なのかわからないということがあると思う。 昔はそれでも、「他にRubyやってる会社もないし、ちょっと覗いてみよう」という感じで応募があったんじゃないだろうか。 NaCl公式の見解ではないけど、この機会に僕個人の考えを簡単にまとめておきたい。

何をやっている会社なの?

簡単に言うとほとんど受託開発(お客さんから依頼があったシステムを開発して対価を得るお仕事)でやっている。 それも旧態依然とした一括請負が多い。 普通のSIerというのがどんなものかわからないけど、たぶんそんなに平均から外れてないと思う。 開発言語はRubyが多いけど、C/C++/C#だったりすることもある。一部、COBOLを使っている部署もある。

たまたまRuby開発者が数名在籍してるけど、Rubyの開発自体は会社の業務というわけではない。 就業時間中にRubyの開発をすることも許されているけど、Ruby開発者への仕事のアサインが特別に減らされているわけではない(まつもとさんを除く)ので、その点もそんなに特別というわけではない。

会社の雰囲気は?

とくに会社のビジョンのようなものはないけど、何となく楽しく開発しようという雰囲気はあるかな。 人によっては物足りないと思う人もいるかもしれないけど、僕みたいにいい加減で人に縛られたくない人間には居心地はいい。

僕の部署にどうしても偏ってしまうけど、メンバーの傾向としては、技術的な向上心は高いけれど開発プロセスなどにはそれほど興味がないような人が多いように思う。 「顧客にとっての価値を高めるんだー」というよりは、「自分なりにもっといいものを作りたい」という雰囲気の人が多いんじゃないかな。

あと、多かれ少なかれオタク的な要素がある人が多いと思う。 別に言語オタクとかアニメオタクだけじゃなくて、釣りとかバイクとかそういうのも含めて。 僕も含めてあんまり社交的なタイプではない人が多いけど、仕事の場ではそれなりに話すし、好きなことに関しては親しい人とはよく話すかもしれない。 でも会社でみんなで雑談するのは昼休憩の時間くらいで、他の時間はディスプレイを見てにやにやしてる感じかな。 昔は席が隣同士でも社内IRCで会話してたけど、最近はTwitterとかになってるのかも。

敷居が高いのでは?

意外とそうでもない。 FizzBuzzを自分で考えて解けるくらいのスキルがあれば採用試験は通ると思う。 どちらかというとスキルよりも、プログラミングが好きかどうかと、素養があるかどうかを見ている。 逆にいくら優秀でも、大学の授業でしかプログラムを書いてませんという人はちょっと辛い。 あと、Rubyに興味があって応募しましたと言いながら、Rubyを触ったこともない人とか。 興味があるなら触ってるはずですよね?

ただ、入社後に充実した研修制度みたいなものはないので、周りの人に聞きながらがんばって自分で勉強してもらう必要がある。 Rubyについては、たいていのことは社内のだれかに聞けばわかると思う。

あと、社員の中でもGC周りをデバッグできるような人はごく一部なので、どうしようもない時はGC.disableしてもらっても構いません。 僕が入社してすぐの頃は、アプリケーションの開発よりも、開発中に出て来るRubyのバグを直してる時間の方が長いこともあったけど、最近はそういうことはあまりなくなったと思う。

労働条件は?

採用情報のページに色々書いてあるので、興味があったら覗いてみてください。

他に何か知りたいことがあればコメント欄か会社の問合せフォームでどうぞ。

大事なことを書き忘れてたので追記。

NaClってまつもとさんがいた会社でしょ?

たまに勘違いされてる方がいますけど、今もいます!

採用応募が減ったのは、この影響が一番大きいのかも。

まつもとさんの肩書が増えたので大分印象が薄くなっていると思うけど、まつもとさんが会社にいる時間はうちが今でも一番長いんじゃないかなあ。 ただ、何となく話しかけづらい雰囲気があるようで(別に気難しいとかじゃなくて多忙な方なので)、ちゃんと話したことがないという人も社内にちらほらいるようだ。

僕自身も、feature requestをRedmineでするようになってからはあんまり会社でまつもとさんとRubyの話をしてないかもしれない。 直談判するのは何かずるい気がして。

_ 型システム入門

型システム入門 −プログラミング言語と型の理論−(Benjamin C. Pierce/住井 英二郎/遠藤 侑介/酒井 政裕/今井 敬吾/黒木 裕介/今井 宜洋/才川 隆文/今井 健男)

遠藤さんがサイン会してたので、いい機会だと思って型システム入門を買った! レジのお姉さんに7000円と言われて一瞬ひるんだけど、いい大人なのでやっぱりやめますとも言えず。

本棚の飾りに7000円は高いので頑張って読むぞ。

_ RubyKaigi2013(1日目)

RubyKaigi2013に参加して発表した。 とりあえず資料を↓に置いておきます。

• Refining refinements

発表では喋らなかったけど、どっちかというとpackrat parserの実装の方が大変だった。

しかも、遅いし入力が大きいと落ちる。理由は、

• 末尾呼出しの最適化がデフォルトでオフになっている。
• 末尾呼出しの最適化を有効化しても、Procの呼出しの場合は効果がない(多分Proc#callでCの関数をまたぐため最適化が効かない)。
• Immutable::Promiseを使うと、内部的にトランポリンを使っているので、末尾呼出しの最適化ができるけど、Parser#bindなどの実装ではそもそも末尾再帰の形になっていない。しかもPromise使うと余計遅くなる。
• 加えて、Rubyだともともと関数型言語に比べて再帰呼出し回数の上限が低い。 (Ruby 2.0では環境変数RUBY_THREAD_VM_STACK_SIZEで調整できる。)

といった感じかなあ。

Rubyだと提供するインタフェイスは関数型っぽくする場合でも、内部的な実装は命令型にしないと実用的でない気がする。 Scalaも割とそんな感じだし、もともとOOPLだから仕方ないかなあ。