DSLについて語るときに僕の語ること

678 views
578 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
678
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DSLについて語るときに僕の語ること

  1. 1. DSLについて語るとき に僕の語ること @Sixeight 第61回 Ruby/Rails勉強会@関西
  2. 2. まとめ • いまさら感があふれる話 • DSLで効率UP • DSLはこわくない • やりすぎると駄目
  3. 3. @Sixeight https://github.com/Sixeight
  4. 4. @tomohi_ro https://twitter.com/tomohi_ro
  5. 5. 西村 友裕 にしむら ともひろ
  6. 6. その他 • Happy Elements株式会社 (京都) • Rails (Ruby) / Unity (C#) • 鴨川シャボン玉の会 • Vim → Atom • Fragment <3
  7. 7. その他 • Happy Elements株式会社 (京都) • Rails (Ruby) / Unity (C#) • 鴨川シャボン玉の会 • Vim → Atom • Fragment <3
  8. 8. Instagram Mextures Tangsten & Fragment LoryStripes http://pixiteapps.com/
  9. 9. つづきはブログで http://sixeight.hatenablog.com/ [壊しました] タグで土日以外毎日更新
  10. 10. 本題
  11. 11. DSL
  12. 12. Domain Specific Language
  13. 13. –ウィキペディア ドメイン固有言語(ドメインこゆうげんご、 英: domain-specific language、DSL) とは、特定のタスク向けに設計されたコンピュー タ言語を意味する。
  14. 14. 例えば Rake
  15. 15. desc "Install binaries" task :install do cp FileList["bin/*"], "/usr/local/bin" end
  16. 16. 利点 • もっとも簡単な方法で記述できる • 出来ることが限定されているがゆえに安全 • コード自体がドキュメントとしての役割を 果たすことが多い 特定の問題に特化しているから、 • • • • • • • • • • • • • •
  17. 17. 欠点 • 学習コストが高い • 応用が効かない • 問題の範囲を決めるのが難しく、特化でき ないことが多い 特定の問題に特化しているから、 • • • • • • • • • • • • • •
  18. 18. 外部?内部?
  19. 19. 外部DSL インタプリタを作るようなもの 全てが自作のDIY精神にあふれるDSL
  20. 20. 内部DSL 別の言語の構文を使って、 なんか別の言語っぽい感じにする
  21. 21. たとえば Ruby で 内部DSLを作れば、 べんりな構文やライ ブラリが使い放題
  22. 22. 実例
  23. 23. ActiveAdmin なんかいい感じで管理画面作ってくれるやつ
  24. 24. ガチャを作るDSL アルバイトでも追加できるように最低限しか書けない ビジネスへの影響が大きいため内部を隠蔽するのは重要
  25. 25. APIを定義するDSL サーバー(Ruby)側、クライアント(C#)側、ドキュメントを自動生 成する。通信不要のモックも作成し、バージョンにも対応。べんり。
  26. 26. じ、自作…?
  27. 27. なぜ作るのか • DSLにするとテンションが上がるから • 勉強会で自慢できるから • そこに問題がある(ry
  28. 28. 利点を思い出そう
  29. 29. 利点 • もっとも簡単な方法で記述できる • 出来ることが限定されているがゆえに安全 • コード自体がドキュメントとしての役割を 果たすことが多い 特定の問題に特化しているから、 • • • • • • • • • • • • • •
  30. 30. なぜ作るのか • めんどうな業務を単純化 (簡単) • 誰がやっても同じ結果 (安全) • 読みやすく説明が不要 (ドキュメント)
  31. 31. めんどうな業務を 単純化 新しいガチャを追加するのに Migration ファイルを作って データを追加して、Controller と View をコピペして… 設定ファイル(DSL)を記述 簡単
  32. 32. 誰がやっても同じ結果 アルバイトにガチャの追加を頼んだら、フッターのリンクが以前の ガチャのものになっていてレアの詳細を見ることが出来なかった 設定ファイル(DSL)は本当に必要なことしか記述しなく てよいので、間違えにくいし、間違いに気づきやすい 安全
  33. 33. 誰がやっても同じ結果 アルバイトにガチャの追加を頼んだら、フッターのリンクが以前の ガチャのものになっていてレアの詳細を見ることが出来なかった 設定ファイル(DSL)は本当に必要なことしか記述しなく てよいので、間違えにくいし、間違いに気づきやすい 安全 レビューしようとい うのはまた別の問題
  34. 34. 読みやすく説明が不要 新人の人にガチャの追加方法を説明していたらお昼ごはんの時間 になっていて、戻ってきたらもう一度教えてほしいと言われる 設定ファイル(DSL)を読めばだいたい分かる コピペでもOK ドキュメント
  35. 35. なぜ今さら 啓蒙するのか
  36. 36. Ruby が仕事で使われるよう になって久しい今だからこそ DSLで業務を効率化しよう
  37. 37. 今だからこそ…? • 仕事で Ruby を使うことが普通になった • 情報も参考になるコードもあふれている • 業界をリード(笑)するあの上司にも Ruby で DSL で DO すると言えば通りやすそう
  38. 38. 発表内容に困って主張を捏 造した。今は反省している。
  39. 39. まとめ • いまさら感があふれる話 • DSLで効率UP • DSLはこわくない • やりすぎると駄目
  40. 40. 先週も同じようなコード 書きませんでしたか
  41. 41. それDSLでできるよ
  42. 42. 注意 例はめっちゃ適当です
  43. 43. 毎日のように似たような メソッドを書いている
  44. 44. 宣言系DSL そんなあなたに、
  45. 45. つらい現実 人間のすることじゃない
  46. 46. べんりな真実 そう、DSLならね
  47. 47. 宣言系DSL
  48. 48. 毎日同じ手順を 書いている
  49. 49. 操作系DSL そんなあなたに、
  50. 50. つらい現実 エラーが起きる場所すべてにコピペ
  51. 51. べんりな真実 そう、DSLならね
  52. 52. 操作系DSL
  53. 53. クラスのインスタンスを組 み立てるのに苦労している
  54. 54. 設定系DSL そんなあなたに、
  55. 55. つらい現実 めんどうだし読みにくい
  56. 56. べんりな真実 そう、DSLならね
  57. 57. 設定系DSL
  58. 58. routes.rb 編集して、 Controller 作って…
  59. 59. 定義系DSL そんなあなたに、
  60. 60. つらい現実 あれをやってこれをやって
  61. 61. べんりな真実 そう、DSLならね
  62. 62. 定義系DSL
  63. 63. べんり
  64. 64. まとめ • いまさら感があふれる話 • DSLで効率UP • DSLはこわくない • やりすぎると駄目
  65. 65. でもお高いんでしょ 開発コストが
  66. 66. 🙏
  67. 67. 作ってみましょう
  68. 68. 宣言系DSL
  69. 69. 宣言系DSL = ただのクラスメソッド
  70. 70. オレオレattr_accessor 車輪の再発明から得られる知見もある
  71. 71. やりたいことは インスタンス変数 を get/set するメソッドを いい感じで定義してくれる my_attr_accessor というクラスメソッドを 定義すること
  72. 72. 突然の黒魔術/ 逃げちゃ駄目だ、逃げちゃ駄目だ、逃げちゃ駄目だ
  73. 73. define_method(name, method) define_method(name) { … } name という名前のメソッドを定義する
  74. 74. 突然の黒魔術/ 逃げちゃ駄目だ、逃げちゃ駄目だ
  75. 75. instance_variable_get(var) instance_variable_set(var, value) var という名前のインスタンス変数を get/set 名前は @hoge である必要がある
  76. 76. 突然の黒魔術/ 逃げちゃ駄目だ
  77. 77. 宣言系ではけっこう使う べんり
  78. 78. 操作系DSL
  79. 79. 操作系DSL = メソッド切り出し
  80. 80. なんかふつう ただのメソッド呼び出しなのに専用の命令に見える
  81. 81. 名前重要 見ただけで分かるメソッド名にしよう このへん
  82. 82. 設定系DSL
  83. 83. 設定系DSL = 代入
  84. 84. config.hoge = piyo
  85. 85. よく見るやつ いまからこのクラスを設定するんだ というのが良く伝わってよい
  86. 86. たぶんこんな感じ .() がきもかわいい
  87. 87. 定義系DSL
  88. 88. 定義系DSL = instance_eval
  89. 89. instance_eval {¦obj¦ … } ブロック内の self をレシーバーに置き換える (ざっくり言うと)
  90. 90. 家にいる猫を管理したい いい例が浮かばなかった
  91. 91. 適当な実装 でもだいたいこんな感じで書きます
  92. 92. このCatモデルを作ります ブロックの中で呼べるメソッドは Cat のインスタンスメソッド
  93. 93. ここが本体 cat.instance_eval が全て
  94. 94. ファイルから読み込めばそれっぽい 文字列なので instance_eval する…
  95. 95. こういうのはどうするの method_missing で… ホワイトリストを作って undef_method しておくと捗る
  96. 96. 🙇
  97. 97. 僕の場合
  98. 98. 手順 • 問題をみつける • 直感的に書けるまで擬似コードを書く • 擬似コード(受け入れテスト)が動くように 実装する • ユニットテストを書く
  99. 99. テスト • DSLがバグってたら目も当てられない • 自分が安心するために書く • 黒魔術的なコードを書くのでTDDは足かせ • 完全に動作するDSLを受け入れテストとする
  100. 100. まとめ • いまさら感があふれる話 • DSLで効率UP • DSLはこわくない • やりすぎると駄目
  101. 101. DSL作ってみたい いますぐ作ろう!
  102. 102. ちょっと待って
  103. 103. 欠点を思い出そう
  104. 104. 欠点 • 学習コストが高い • 応用が効かない • 問題の範囲を決めるのが難しく、特化でき ないことが多い 特定の問題に特化しているから、 • • • • • • • • • • • • • •
  105. 105. 学習コストが高い プロジェクトのここもDSL、あっちもDSL。 ここは Rails のままで書く、ここもDSLだったわ。 べんり機能が知っている人にしか使われない。 むしろ普通に書くことも困難でプロジェクト炎上。
  106. 106. 応用が効かない たくさんの社内DSLをマスターして社内では神と呼ばれ て頼られているので、勘違いして転職してみた。 実は Rails はそんなに書けなかったので ついていこうと必死になり過労死
  107. 107. 問題の範囲があいまい べんりそうなDSLを作った。こっちもDSLにできそう なので作った。あっちも、そっちも、ここも作っとこう。 あっちとそっちのDSLの内容が微妙に被ってて どちらに書けば良いのか分からない
  108. 108. 何事も やりすぎはよくない
  109. 109. まとめ • いまさら感があふれる話 • DSLで効率UP • DSLはこわくない • やりすぎると駄目
  110. 110. なんだこれ なんだこのオプション
  111. 111. 知見の共有 • 宣言系は相当すじがよくないと破綻する • よくわからん書き方が増えて混乱するだけ • 定義系は名前重要 • 学習コストを下げるには驚き最小の法則 • ドキュメント必須 • DSLの仕様は書いた本人しか知らないと思え
  112. 112. まとめ • いまだからこそ仕事でDSL • DSLで業務を効率化 • DSLは簡単に作れる • 用法用量をよく守りお使いください
  113. 113. DSLとして切り出せる問題を見つけたら勝ち
  114. 114. ありがとう ございました

×