狠狠撸

DSLについて語るとき
に僕の語ること
@Sixeight
第61回 Ruby/Rails勉強会@関西

まとめ
? いまさら感があふれる話
? DSLで効率UP
? DSLはこわくない
? やりすぎると駄目

顿厂尝について语るときに僕の语ること

@Sixeight
https://github.com/Sixeight

@tomohi_ro
https://twitter.com/tomohi_ro

西村友裕
にしむらともひろ

その他
? Happy Elements株式会社 (京都)
? Rails (Ruby) / Unity (C#)
? 鴨川シャボン玉の会
? Vim → Atom
? Fragment <3

Instagram
Mextures
Tangsten
&
Fragment LoryStripes
http://pixiteapps.com/

つづきはブログで
http://sixeight.hatenablog.com/
[壊しました] タグで土日以外毎日更新

–ウィキペディア
ドメイン固有言語（ドメインこゆうげんご、
英: domain-speci?c language、DSL）
とは、特定のタスク向けに設計されたコンピュー
タ言語を意味する。

desc "Install binaries"
task :install do
cp FileList["bin/*"], "/usr/local/bin"
end

利点
? もっとも簡単な方法で記述できる
? 出来ることが限定されているがゆえに安全
? コード自体がドキュメントとしての役割を
果たすことが多い
特定の問題に特化しているから、
? ? ? ? ? ? ? ? ? ? ? ? ? ?

欠点
? 学習コストが高い
? 応用が効かない
? 問題の範囲を決めるのが難しく、特化でき
ないことが多い
特定の問題に特化しているから、
? ? ? ? ? ? ? ? ? ? ? ? ? ?

外部DSL
インタプリタを作るようなもの
全てが自作のDIY精神にあふれるDSL

内部DSL
別の言語の構文を使って、
なんか別の言語っぽい感じにする

たとえば Ruby で
内部DSLを作れば、
べんりな構文やライ
ブラリが使い放題

ActiveAdmin
なんかいい感じで管理画面作ってくれるやつ

ガチャを作るDSL
アルバイトでも追加できるように最低限しか書けない
ビジネスへの影響が大きいため内部を隠蔽するのは重要

APIを定義するDSL
サーバー(Ruby)側、クライアント(C#)側、ドキュメントを自動生
成する。通信不要のモックも作成し、バージョンにも対応。べんり。

なぜ作るのか
? DSLにするとテンションが上がるから
? 勉強会で自慢できるから
? そこに问题がある(谤测

なぜ作るのか
? めんどうな業務を単純化 (簡単)
? 誰がやっても同じ結果 (安全)
? 読みやすく説明が不要 (ドキュメント)

めんどうな業務を
単純化
新しいガチャを追加するのに Migration ファイルを作って
データを追加して、Controller と View をコピペして…
設定ファイル(DSL)を記述
簡単

誰がやっても同じ結果
アルバイトにガチャの追加を頼んだら、フッターのリンクが以前の
ガチャのものになっていてレアの詳細を見ることが出来なかった
設定ファイル(DSL)は本当に必要なことしか記述しなく
てよいので、間違えにくいし、間違いに気づきやすい
安全

誰がやっても同じ結果
アルバイトにガチャの追加を頼んだら、フッターのリンクが以前の
ガチャのものになっていてレアの詳細を見ることが出来なかった
設定ファイル(DSL)は本当に必要なことしか記述しなく
てよいので、間違えにくいし、間違いに気づきやすい
安全
レビューしようとい
うのはまた別の問題

読みやすく説明が不要
新人の人にガチャの追加方法を説明していたらお昼ごはんの時間
になっていて、戻ってきたらもう一度教えてほしいと言われる
設定ファイル(DSL)を読めばだいたい分かる
コピペでもOK
ドキュメント

なぜ今さら
啓蒙するのか

Ruby が仕事で使われるよう
になって久しい今だからこそ
DSLで業務を効率化しよう

今だからこそ…？
? 仕事で Ruby を使うことが普通になった
? 情報も参考になるコードもあふれている
? 業界をリード(笑)するあの上司にも Ruby
で DSL で DO すると言えば通りやすそう

発表内容に困って主張を捏
造した。今は反省している。

先週も同じようなコード
書きませんでしたか

それ顿厂尝でできるよ

注意
例はめっちゃ適当です

毎日のように似たような
メソッドを書いている

宣言系顿厂尝
そんなあなたに、

つらい現実
人間のすることじゃない

べんりな真実
そう、DSLならね

毎日同じ手順を
書いている

操作系顿厂尝

つらい現実
エラーが起きる場所すべてにコピペ

クラスのインスタンスを組
み立てるのに苦労している

设定系顿厂尝

つらい現実
めんどうだし読みにくい

routes.rb 編集して、
Controller 作って…

定义系顿厂尝

つらい現実
あれをやってこれをやって

でもお高いんでしょ
開発コストが

宣言系顿厂尝
= ただのクラスメソッド

オレオレattr_accessor
車輪の再発明から得られる知見もある

やりたいことは
インスタンス変数を
get/set するメソッドを
いい感じで定義してくれる
my_attr_accessor
というクラスメソッドを
定義すること

突然の黒魔術/
逃げちゃ駄目だ、逃げちゃ駄目だ、逃げちゃ駄目だ

de?ne_method(name, method)
de?ne_method(name) { … }
name という名前のメソッドを定義する

突然の黒魔術/
逃げちゃ駄目だ、逃げちゃ駄目だ

instance_variable_get(var)
instance_variable_set(var, value)
var という名前のインスタンス変数を get/set
名前は @hoge である必要がある

突然の黒魔術/
逃げちゃ駄目だ

宣言系ではけっこう使う
べんり

操作系顿厂尝
= メソッド切り出し

なんかふつう
ただのメソッド呼び出しなのに専用の命令に見える

名前重要
見ただけで分かるメソッド名にしよう
このへん

よく見るやつ
いまからこのクラスを設定するんだ
というのが良く伝わってよい

たぶんこんな感じ
.() がきもかわいい

定义系顿厂尝
= instance_eval

instance_eval {?obj? … }
ブロック内の self をレシーバーに置き換える
(ざっくり言うと)

家にいる猫を管理したい
いい例が浮かばなかった

適当な実装
でもだいたいこんな感じで書きます

このCatモデルを作ります
ブロックの中で呼べるメソッドは
Cat のインスタンスメソッド

ここが本体
cat.instance_eval が全て

ファイルから読み込めばそれっぽい
文字列なので instance_eval する…

こういうのはどうするの
method_missing で…
ホワイトリストを作って undef_method しておくと捗る

手順
? 問題をみつける
? 直感的に書けるまで擬似コードを書く
? 擬似コード(受け入れテスト)が動くように
実装する
? ユニットテストを書く

テスト
? DSLがバグってたら目も当てられない
? 自分が安心するために書く
? 黒魔術的なコードを書くのでTDDは足かせ
? 完全に動作するDSLを受け入れテストとする

DSL作ってみたい
いますぐ作ろう！

学習コストが高い
プロジェクトのここもDSL、あっちもDSL。
ここは Rails のままで書く、ここもDSLだったわ。
べんり機能が知っている人にしか使われない。
むしろ普通に書くことも困難でプロジェクト炎上。

応用が効かない
たくさんの社内DSLをマスターして社内では神と呼ばれ
て頼られているので、勘違いして転職してみた。
実は Rails はそんなに書けなかったので
ついていこうと必死になり過労死

問題の範囲があいまい
べんりそうなDSLを作った。こっちもDSLにできそう
なので作った。あっちも、そっちも、ここも作っとこう。
あっちとそっちのDSLの内容が微妙に被ってて
どちらに書けば良いのか分からない

何事も
やりすぎはよくない

なんだこれ
なんだこのオプション

知見の共有
? 宣言系は相当すじがよくないと破綻する
? よくわからん書き方が増えて混乱するだけ
? 定義系は名前重要
? 学習コストを下げるには驚き最小の法則
? ドキュメント必須
? DSLの仕様は書いた本人しか知らないと思え

まとめ
? いまだからこそ仕事でDSL
? DSLで業務を効率化
? DSLは簡単に作れる
? 用法用量をよく守りお使いください

顿厂尝として切り出せる问题を见つけたら胜ち

ありがとう
ございました

狠狠撸

顿厂尝について语るときに僕の语ること

More Related Content

顿厂尝について语るときに僕の语ること