ruby におけるメタプログラミングの一つの本質

1. 名前重要、超重要！！
https://github.com/baban/proxy

2. 
プログラミングにおいて名前って重要ですよ
ね

名前から、その役割、機能、データの型、値
を”感じる”ことができる

また、そうである必要がある

3. 
そのためには、名前に過不足なく必要なもの
を含めないといけない

型の情報、その役割を明確にするにはどうれ
ばいいのか

4. おすすめの方法

Rubyでもハンガリアン記法での変数名の宣
言を提案したい
接頭語 型 例
n 数値 n_attack
b ブーリアン b_bookmark
s 文字列 s_carrier
（変数名＋データ型でデータの役割もわかりやすい！）

5. というのはもちろん嘘♪

ダックタイピングな型を意識させない、型付
き言語であるRubyの文脈でこれは、"ややあ
りえない"レベルの提案

6. というわけで今回の本当のお題ですが…

7. 例１：Proxyパターンの実現
これです
デザパタ本

8. 今回のコードは以下の場所に掲載されています
https://github.com/baban/proxy

9. Proxyパターン

プリントpage１を開いてください

VirtualProxyを参考にします

Web上のコードは、Rubyによるデザインパ
ターンを参照
https://github.com/baban/proxy/blob/master/proxy1.rb

10. Ruby風味にリファクタリング

まず、Printable継承する必要はない

attr_accessor使えばgetter,setterいらない

あと、printは名前共通だな… method_missingでやってみよ
う

11. リファクタリング後
https://github.com/baban/proxy/blob/master/proxy2.rb
class PrinterProxy
def initialize(name)
@printer_name = name
end
def printer_name
@real ? @real.printer_name : @printer_name
end
def method_missing( name, *_ )
@real = Printer.new(@printer_name) unless @real
return @real.send(name,*_) if @real.respond_to?(name)
end
end

12. Proxyの正体を考えよう！
ポイント

method_missing外部に残っている機能
は、”Printer機能を生成したくない時"に呼
ばれるメソッドのみ

実はPrinterを生成したいメソッド群と、そ
うでないグループに意味の分化が行われてい
た

13. ポイントその１！
デザインパターンと言われるとGoFの23個の
パターンを最初に思い出すが、デザインパ
ターンの文脈は使用するプログラミング言語
によって異なる
(IteratorとかRubyでは言語組み込みだしね！)

14. ポイントその２！！

表現力の高い言語は、リファクタリングの間
に、”本当に書き表したい事は実は何だった
のか”を浮き上がらせる力がある

15. 例２：アクションは自動生成

管理画面：Railsでマスターデータの編集機能
を作ろう

16. 条件

現在は開発初期、テーブルは後で多分増える

必要なのは、データの閲覧、作成、編集で作
りこみはしないでいい

テーブル名は”***_masters"のテーブル名で統
一されている

17. 正直
テーブルの数だけcontroller作成とか
migrationが入る度に、管理機能も修正とか
やってられないですよねーー！！

18. 
そこでmethod_missingを利用してアクション
を生成する
https://github.com/baban/proxy/blob/master/master_controller.rb

19. def method_missing( method_name, *args )
all, table_name, bar, action_type = method_name.to_s.
match(/(w+masters)(_)?(index|show|new|create|edit|update|destroy|download|)?/).to_a
# テーブルの基本情報を取得
@table_name = table_name
virtual_table_class = Class.new(ActiveRecord::Base)
virtual_table_class.set_table_name(@table_name)
@colums_info = virtual_table_class.columns
# 適切なアクションに処理を振り分け
case action_type
when "index"
page = params.key?(:page) ? params[:page].to_i : 1
@rows = virtual_table_class.paginate(:all, page: page, per_page: 10 )
return render action:'missing_index'
when "show"
@row = virtual_table_class.find(params[:id])
return render :action => :missing_show
when "new"
@new_master = virtual_table_class.new
return render :action => :missing_new
when "create"
@created_master = virtual_table_class.new(params[@table_name.to_sym])
@created_master.save
return redirect_to :controller => :master, :action => "#{table_name}_index"
when "edit"
@row = virtual_table_class.find(params[:id])
return render :action => :missing_edit
when "update"
@row = virtual_table_class.find(params[:id])
@row.update_attributes(params[@table_name.to_sym])
return redirect_to :controller => :master, :action => "#{table_name}_index"
when "destroy"
@row = virtual_table_class.find(params[:id])
@row.destroy
return redirect_to :controller => :master, :action => "#{table_name}_index"
else
super
end

20. 結果

最終的なマスターデータテーブルの数...、２
３！！
生産性の比率23:1

その後の修正ゼロで本番まで動いてみせた
（まぁ、rails_adminは近い戦略を取っているものを後で知った
のですけどね）

21. どうしてこのようなことが可能な
のか

「構造」と「名前」を利用している
からだ！

22. Railsの構造その１
Railsは次のような構造を持つ

23. Railsの構造その１
ユーザーの画面遷移に名前をつけてみる

24. Railsの構造その２
データのハブとなっている
ここをハック

25. プログラミング効率化の方法

対象の正しい構造を見抜く

あるべき操作の手順を考える

それらに"正しい"名前を与える
トライ＆エラーしながら納得いくまで全体の
構造をリファクタリングして答えに辿り着く

26. ポイント

抽象化が進むと、ハードウェアから離れた、
小さな機能のサブセットを組み合わせてプロ
グラミングをするようになる

より高次な言語ほど、対象に正しい名前をつ
けることが重要になる

むしろ正しい名前がついた段階でプログラミ
ングの９割は終了している

27. 例３：身近な名前重要(Form編)

通常
<%=label_tag "user_info[nickname]", "ニックネーム" %>
<%=text_field_tag "user_info[nickname]" %>

FormBuilder依存
<%= f.label :nickname, "ニックネーム" %>
<%= f.text_field :nickname %>

formtastic使用
<%=f.input :nickname, label:"ニックネーム" %>
コード量 89文字 -> 39文字

28. メタプログラミングの方法

一番分かっておくべきことは、”最初からメ
タプログラミングで書く必要はない”という
こと

必要な要件が出揃っていない状態で共通項を
見ぬくとか人間の頭では無理

29. メタプログラミングの作法
1.最初に要件を最低限満たすコードを記述
2.それを満たすテストを記述
3.だいたいオブジェクト単位で全体を見渡す
4.共通したデータ構造を見つけたら、リファクタリングで
くくり出す
5.テストを実行して要件を満たしているか確認
6. 手順３に戻ってまだリファクタリングできないか考え
てみる

30. メタプログラミングの作法２

リファクタリングを繰り返していくことで、
最終的にこれ以上は分割圧縮できないなとい
う所まで行く

そうなったら違う戦術で括り直せないかと、
考え直してみる(例：method_missingだったも
のをdefime_methodで書き直せないか考えて
みる)

31. メタプログラミングの作法３

そうすると最終的に
「これ以上の方法は無いだろう」
という考えに”至る”

そう”至る”のです

32. プログラミングとは何か？
【真理】に至るための修行、プロセス

33. 真理とは何か？

例えば今回紹介したProxyは３つのProxyがあ
る

VirutalProxy(今回のコード)

RemoteProxy

AccessProxy

これらのProxyパターンに共通する”Proxyを
Proxyたらしめている"コードとは何なのか？
探してみませんか？

34. そう
真理の上には
さらなる真理がその影を延ばしている

35. 世界に隠れている有用なデータ構造、を探し
て正しい名前を付けてあげよう
真の名前を捉えた瞬間、そのコードは私たち
のいいなりになる
真理は、ツンデレである

36. そのために

巨人の肩の上に乗ろう

有用なパターンを学ぼう！！

レールは外れて歩き出そう

獣道を切り開こう

未踏の地の新雪に、アポロ１１号のクルーの
ように自分の足跡を残せる事はむずかしいか
もしれないけれど…

37. 
見つけた法則は世に公開してその真偽を問い
かけてみよう

知の一滴を大海に投げ込もう