ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011

46,097 views

Published on

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

No Downloads
Views
Total views
46,097
On SlideShare
0
From Embeds
0
Number of Embeds
76
Actions
Shares
0
Downloads
19
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide

ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011

  1. 1. ぼくのかんがえたさいきょうの うぇぶあぷりけーしょん ふれーむわーく cho45 <cho45@lowreal.net> 株式会社はてな
  2. 2. 自己紹介
  3. 3. id:cho45http://www.lowreal.net/
  4. 4. 株式会社はてな 京都8F勤務
  5. 5. Perl (バックエンド)JavaScript (フロントエンド)Ruby (ツール作り)Scala (たまにあそびで)Java (Android アプリ)
  6. 6. Config::PitConfig::ENVPlack::App::CocProxySQL::NamedPlaceholderJSDeferred
  7. 7. 最近はwindow.postMessage にハマっています
  8. 8.
  9. 9. その話はしません
  10. 10. 趣味
  11. 11. 神社巡り
  12. 12. 写真
  13. 13. プログラミングコード群: http://github.com/cho45日記: http://subtech.g.hatena.ne.jp/cho45/
  14. 14. 本題
  15. 15. の前に
  16. 16. 前提
  17. 17. 1. 長期的にメンテナンスする2. 大規模3. 複数人開発
  18. 18. 個人で使うフレームワークとか正直どうでもいいと思う。
  19. 19. フレームワークつかってますか 
  20. 20. Catalyst, Jifty, Dancer, CGI:: Application, HTTP:: Engine, Mason,Squatting, Continuity,Maypole, Tatsumaki,Mojolicious, Ark, Noe, Kamui, Amon2 ref. http://plackperl.org/
  21. 21. ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく
  22. 22. アジェンダ● 良いフレームワークとはなにか● 信頼性設計とかについて● テストについて
  23. 23. ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく
  24. 24. を考える前に
  25. 25. フレームワークの
  26. 26. メリット デメリット を整理します
  27. 27. メリット
  28. 28. 共同開発しやすい安全なフレームワークは安全 形になるまで早い バッドノウハウの蓄積 うまくいかないときフレームワークのせいにできる
  29. 29. 共同開発しやすい安全なフレームワークは安全 特に重要
  30. 30. デメリット
  31. 31. 読むコードが増える 自由度がない 拡張性がないフレームワークが糞だと 全てが糞になる
  32. 32. フレームワークを覚えるのに 必死になりがち 挙動が意味不明 マジカルなことやりがち
  33. 33. 良いフレームワークとは?
  34. 34. 読むコードが最小(共同開発のために) → 薄いフレームワーク安全であること → 信頼性設計
  35. 35. 読むコードが最小
  36. 36. だいたいフレームワークは 結局ハマって 全部コード読む
  37. 37. だいたいフレームワークは 結局ハマって 全部コード読む → 学習コスト増大
  38. 38. フレームワークのコードは マジカルすぎて 意味不明
  39. 39. フレームワークのコードは マジカルすぎて 意味不明→ 読むと Perl に詳しく
  40. 40. フレームワークのコードは マジカルすぎて 意味不明→ 学習コスト アゲ♂アゲ
  41. 41. ある prepan.org 作者のつぶやき「○○っていうフレームワークつかってるんだけど、もう嫌なんだよね。 フルスタックなんだけどドキュメントよくわからないし。 中身読もうとすると意味不明だし」
  42. 42. 薄いフレームワークが良い ↑ 良くいう
  43. 43. 薄いフレームワーク
  44. 44. を極める
  45. 45. 何も実装がないフレームワーク
  46. 46. どういうこと?
  47. 47. 限りなく薄いフレームワークとは ↓ 設計指針 ● 安全 ● 読むコード最小
  48. 48. フレームワークは実装ではなく設計指針共同開発に必要なのは 共通の実装ではなく 共通の設計指針
  49. 49. 僕の考える設計指針=フレームワーク 安全 (信頼性設計) 読むコード最小 (メンテコスト)
  50. 50. 信頼性設計
  51. 51. 危険なことをするために より多くのコストが 必要になるように
  52. 52. 例: 最低限必要なXSS対策デフォルトで HTML エスケープ[% req.param(query) %]危ないことをしようとするときは手間をかける[% req.param(query) | raw %]
  53. 53. 読むコード最小
  54. 54. 3 DRY 3回コピペしたら抽象化しろ(不必要な/下手クソな抽象化は悪)
  55. 55. 設計例: Hatena Blog
  56. 56. 長期的に開発することを念頭に 柔軟性新機能を加えるときに読むべき コードを最小化 信頼性設計
  57. 57. 柔軟性と 読むべきコードの最小化を 同時に達成しようとするとドメイン特化にならざるを得ない
  58. 58. 安全で最小限な実装をプロジェクト内に持つ設計指針を明確にする
  59. 59. 僕の考える設計指針=フレームワーク 再掲 安全 (信頼性設計) 読むコード最小 (メンテコスト)
  60. 60. 設計指針 安全 (信頼性設計)読むコード最小 (メンテコスト) 早い (ユーザ体験)
  61. 61. ディスパッチャPlack + Router::Simple + αビューText::Xslate, JSON:XS, etc...DBアクセスDBI生 + SQL::NamedPlaceholder(DBアクセスはコストがかかるので面倒にしとく)
  62. 62. 既存実装(Ridge)を使わなかった理由 → 安全じゃなかったら → テストも十分ではなかった安全にするテストを十分に+ app.psgi からあっちこっちいかずに読み下せるように
  63. 63. 安全策
  64. 64. HTML出力時自動エスケープ → XSS対策
  65. 65. POST時にトークン自動チェック → CSRF対策
  66. 66. JSON出力時 XMLHtmlRequestのX-Requested-Withを自動チェック→ IE XSS 対策 / UTF-7攻撃対策 / JSON読み出し対策
  67. 67. 自動でX-Frame-Options: DENY→ クリックジャッキング対策
  68. 68. iframeでロードされたフォームでは 何か変更されないと submit 不可 → クリックジャッキング対策 (どうしても iframe 使う場合のフォールバック)
  69. 69. 自動でできるだけ安全に
  70. 70. 適切なデフォルトを設定
  71. 71. テスト
  72. 72. テストが大量にあってもメンテしないレイヤー(Appとか)を増やすとテストが増える 読むコードが増える ↓ 最小限の構成 Model + Controller
  73. 73. Model のテスト (仕様があまり変わらない) ロジックのみ (DBアクセスなし) 細かい挙動をチェックカバレッジ重視 (ホワイトボックステスト)
  74. 74. 例:use Test::More;# ロジックしかないので難しいところなしmy $e = Entry->new({body => ..});is_deeply $e->classes, [ ... ];done_testing;
  75. 75. Controller のテスト (しばしば細かい仕様が変わる) ディスパッチ → 出力までTest::WWW::Mechanize::PSGI ユーザの挙動をシミュレート (ブラックボックステスト)
  76. 76. 例:use My::Test qw(create_hatena_user mechanize);# DB アクセスとかはいい感じにしてるmy $user = create_hatena_user();my $mech = mechanize($user);my $blog_id = $mech->create_blog_ok;ok $blog_id;my $entry_id = $mech->post_entry_ok(blog_id => $blog_id);ok $entry_id; done_testing;
  77. 77. 早い
  78. 78. use DBI;
  79. 79. ORM は勝手にDBひくな
  80. 80. ORM は勝手にblessするな
  81. 81. コストがかかることを便利にしてはいけない
  82. 82. 実装
  83. 83. 大枠としてはだいたいこんなかんじですhttps://github.com/cho45/starter.pl/tree/master/templates/mywebapp (スケルトンジェネレータのテンプレートレベルのコード)
  84. 84. まとめ
  85. 85. ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく
  86. 86. とはなんだったのか
  87. 87. 設計指針
  88. 88. サービス特化の実装
  89. 89. 僕の考えた最強の設計指針
  90. 90. 僕の考えた最低限の設計指針● 安全 (信頼性設計)● 読むコード最小 (メンテコスト)● 早い (ユーザ体験)実装は必要に応じて選び必要であれば最低限自分で書くのが良い
  91. 91. ご清聴ありがとうございました www.lowreal.net

×