Rails勉強会@東京第78回
現在、弊社ではエンジニアが自分一人しかいないので、開発がらみの話をする相手がいないのが目下の悩み。
そんなわけで、その相手を外部に求めようとココ最近、あちこちの勉強会に参加するようになったわけですが、特に「Railsについて語りたい！」という欲求が強くなってきた折、ちょっとしたネタをたずさえて、行ってきましたよ。Rails勉強会@東京へ。
http://wiki.fdiary.net/rails/?RailsMeetingTokyo-0078
もってきたネタについて
Railsっていいですよね。でもhelperが嫌いなんですよ、私。
なんでそこだけ、オブジェクティブじゃなくなるの、と。コードが冗長になるし。
そこで、かわりにDecoratorパターンをやりたくなってライブラリを探したのですが、
・https://github.com/amatsuda/active_decorator
・https://github.com/drapergem/draper
あたりが、まあ、一般的な選択肢なのだろうとわかったわけです。
もちろん、どちらも素晴らしいライブラリなのですが、ただ一点だけ自分には不満が。
それはviewだけ見ても、そのオブジェクトがDecorateされたものなのか、いないのかがわからないということ。
そこで考えた方式がこんな感じ。
class Person < ActiveRecord::Base
def say
“Hey!”
end
end
class PersonDecorator < DecoModel::Decorator
def say
origin.say * 3
end
end
person = Person.new
person.say # == "Hey!"
person.decorate.say #=="Hey!Hey!Hey!"一目瞭然。
まあ、こんな考えで作ったgemを勉強会の場で参加者の皆様に批評していただくことにしました。
批評の結果。
そこはRuby初めてたかだか2年の私が足下にも及ばないRuby強者が集う場所、当然といえば当然、みなさんからは実にいろいろな指摘をいただきました。
飛んできた斧を拾い集めてリスト化すると、下記のような感じ。
・ライブラリならsendを使ってはダメ。__send__を使うべし。
→すいません、__send__は極力使わないものと思い込んでいました。
たしかに、ライブラリ側では上書きされる危険の少ない__send__を使ったほうがよいですよね。
・method_missingを使ってるけど、respond_to?はケアしないの？ そもそもdelgateを使った方がよくない？
→respond_to?の存在は忘れてました。でも、ケアしていないライブラリが多い気が・・・。
delegateで書き直そうと思ったんですが、Decorate元と、link_toとかの場合はview_contextの両方に委譲しなければならないので無理でした。
・書式を統一しよう。
→はい、喜んで！
・protectedを使ってるけど、RubyのprotectedはC++やJavaとは違いますよ。
→なんですって？ 思わずアゴが落ちましたが、Rubyistにとっては常識らしい。
「子クラスの中では、privateもprotectedもレシーバなしならアクセスできてしまうのだよ。ふっふっふっ」みたいな盛り上がり方をしていましたが、こちとらは驚いたのなんのって。
・ActiveRecord::Baseを勝手に拡張しているけど、Decoratorがいる奴だけでよくない？
→「Decorate元でincludeしたらどう？」「Decoratorを書くのと、二度手間になるので嫌なんです」みたいな議論を経て、inheritedを使うといいよ、とMさんから素敵なアドバイスが。
ActiveRecord::Baseを拡張するのは、ちょっとクリーンじゃないと思っていたので、ありがたく実装に取り込ませていただきました。
・begin~endが例外処理でもないのに使われていてちょっと気持ち悪い。
→下記のようなコードが気持ち悪い、と。けっこう便利なので、ついついやっちまうのですが・・・。
@_decorater ||= begin decorator_class = DecoModel::Factory.instance.decorator_for( self.class ) decorator_class ? decorator_class.new( self, options ) : self end
・ちょっとコードがもにょもにょした感じ。
→はい、がんばります・・・。でも、どうすれば・・・。
・person.decorate.nameっていうのは英文として不自然だからdecoratedにしたほうがよいよ。
→person.decorated.nameですね。おお、たしかにDSLっぽい。
・Githubのドキュメントをちゃんと書こう。英語が苦手なら日本語でも書いた方がいいよ。
→英語力のなさに対するあたたかいお言葉。まったく、その通りなのでがんばっていこうと思います。
・ActiveDecoratorと同様、ActiveRecord::Base依存は外せるはずなのでそうしたほうがいいよ。
→すばらしい提案なので、実装に取り込みました。
・DecoModelって、名前がダサくない？
→ええ、ダサいです(笑)
というわけで、勉強会参加者の皆さんがいろいろと素敵な名前を考えてくれました。
その結果、RDecoratorが賛成多数として採用に。
※Rの意味は、Ruby、Rails、Readableという感じ。
一緒に考えてくれた皆様に感謝を捧げます。
なんだか最後の方では、突っ込まれるのがもはや快感になってましたよw。
勉強会の途中、偶然にもActiveDecorator作者のamatsudaさんが姿を見せたので、猿真似した側としては思わず恐縮。
もしかしたら怒られるかな、とも思ったんですが、amatsudaさんからは大人の態度で「ActiveDecoratorからいろいろパクっているのはいいけど、ちゃんとコピー元は明示しないとだめだよ」と丁寧な指摘を頂きました。ありがとうございます。
というわけで、指摘の結果を反映した結果がこちら。
https://github.com/takuya327/r_decorator
※rubygems.orgにもpush済み。
自分のプロジェクトに取り込んで、これからドッグフーディングをしていこうと思います。
でも、かなりシンプルになって、使い勝手のいいライブラリになったんじゃないだろうか。思わず自画自賛。
Rails勉強会の皆様には、あらためてお礼を申し上げます。
