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

1. ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく cho45 <cho45@lowreal.net> 株式会社はてな

2. 自己紹介

3. id:cho45http://www.lowreal.net/

4. 株式会社はてな京都8F勤務

5. Perl (バックエンド)JavaScript (フロントエンド)Ruby (ツール作り)Scala (たまにあそびで)Java (Android アプリ)

6. Config::PitConfig::ENVPlack::App::CocProxySQL::NamedPlaceholderJSDeferred

7. 最近はwindow.postMessage にハマっています

8. が

9. その話はしません

10. 趣味

11. 神社巡り

12. 写真

13. プログラミングコード群: http://github.com/cho45日記: http://subtech.g.hatena.ne.jp/cho45/

14. 本題

15. の前に

16. 前提

17. 1. 長期的にメンテナンスする2. 大規模3. 複数人開発

18. 個人で使うフレームワークとか正直どうでもいいと思う。

19. フレームワークつかってますか

20. Catalyst, Jifty, Dancer, CGI:: Application, HTTP:: Engine, Mason,Squatting, Continuity,Maypole, Tatsumaki,Mojolicious, Ark, Noe, Kamui, Amon2 ref. http://plackperl.org/

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

22. アジェンダ● 良いフレームワークとはなにか● 信頼性設計とかについて● テストについて

24. を考える前に

25. フレームワークの

26. メリットデメリットを整理します

27. メリット

28. 共同開発しやすい安全なフレームワークは安全形になるまで早いバッドノウハウの蓄積うまくいかないときフレームワークのせいにできる

29. 共同開発しやすい安全なフレームワークは安全特に重要

30. デメリット

31. 読むコードが増える自由度がない拡張性がないフレームワークが糞だと全てが糞になる

32. フレームワークを覚えるのに必死になりがち挙動が意味不明マジカルなことやりがち

33. 良いフレームワークとは?

34. 読むコードが最小(共同開発のために)　→ 薄いフレームワーク安全であること　→ 信頼性設計

35. 読むコードが最小

36. だいたいフレームワークは結局ハマって全部コード読む

37. だいたいフレームワークは結局ハマって全部コード読む → 学習コスト増大

38. フレームワークのコードはマジカルすぎて意味不明

39. フレームワークのコードはマジカルすぎて意味不明→ 読むと Perl に詳しく

40. フレームワークのコードはマジカルすぎて意味不明→ 学習コストアゲ♂アゲ

41. ある prepan.org 作者のつぶやき「○○っていうフレームワークつかってるんだけど、もう嫌なんだよね。　フルスタックなんだけどドキュメントよくわからないし。　中身読もうとすると意味不明だし」

42. 薄いフレームワークが良い ↑ 良くいう

43. 薄いフレームワーク

44. を極める

45. 何も実装がないフレームワーク

46. どういうこと？

47. 限りなく薄いフレームワークとは ↓ 設計指針 ● 安全 ● 読むコード最小

48. フレームワークは実装ではなく設計指針共同開発に必要なのは共通の実装ではなく共通の設計指針

49. 僕の考える設計指針=フレームワーク安全 (信頼性設計) 読むコード最小 (メンテコスト)

50. 信頼性設計

51. 危険なことをするためにより多くのコストが必要になるように

52. 例: 最低限必要なXSS対策デフォルトで HTML エスケープ[% req.param(query) %]危ないことをしようとするときは手間をかける[% req.param(query) | raw %]

53. 読むコード最小

54. 3 DRY 3回コピペしたら抽象化しろ(不必要な/下手クソな抽象化は悪)

55. 設計例: Hatena Blog

56. 長期的に開発することを念頭に柔軟性新機能を加えるときに読むべきコードを最小化信頼性設計

57. 柔軟性と読むべきコードの最小化を同時に達成しようとするとドメイン特化にならざるを得ない

58. 安全で最小限な実装をプロジェクト内に持つ設計指針を明確にする

59. 僕の考える設計指針=フレームワーク再掲安全 (信頼性設計) 読むコード最小 (メンテコスト)

60. 設計指針安全 (信頼性設計)読むコード最小 (メンテコスト) 早い (ユーザ体験)

61. ディスパッチャPlack + Router::Simple + αビューText::Xslate, JSON:XS, etc...DBアクセスDBI生 + SQL::NamedPlaceholder(DBアクセスはコストがかかるので面倒にしとく)

62. 既存実装(Ridge)を使わなかった理由　→ 安全じゃなかったら　→ テストも十分ではなかった安全にするテストを十分に+ app.psgi からあっちこっちいかずに読み下せるように

63. 安全策

64. HTML出力時自動エスケープ → XSS対策

65. POST時にトークン自動チェック → CSRF対策

66. JSON出力時 XMLHtmlRequestのX-Requested-Withを自動チェック→ IE XSS 対策 / UTF-7攻撃対策 / JSON読み出し対策

67. 自動でX-Frame-Options: DENY→ クリックジャッキング対策

68. iframeでロードされたフォームでは何か変更されないと submit 不可 → クリックジャッキング対策 (どうしても iframe 使う場合のフォールバック)

69. 自動でできるだけ安全に

70. 適切なデフォルトを設定

71. テスト

72. テストが大量にあってもメンテしないレイヤー(Appとか)を増やすとテストが増える読むコードが増える ↓ 最小限の構成 Model + Controller

73. Model のテスト (仕様があまり変わらない) ロジックのみ (DBアクセスなし) 細かい挙動をチェックカバレッジ重視 (ホワイトボックステスト)

74. 例：use Test::More;# ロジックしかないので難しいところなしmy $e = Entry->new({body => ..});is_deeply $e->classes, [ ... ];done_testing;

75. Controller のテスト (しばしば細かい仕様が変わる) ディスパッチ → 出力までTest::WWW::Mechanize::PSGI ユーザの挙動をシミュレート (ブラックボックステスト)

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. 早い

78. use DBI;

79. ORM は勝手にDBひくな

80. ORM は勝手にblessするな

81. コストがかかることを便利にしてはいけない

82. 実装

83. 大枠としてはだいたいこんなかんじですhttps://github.com/cho45/starter.pl/tree/master/templates/mywebapp (スケルトンジェネレータのテンプレートレベルのコード)

84. まとめ

86. とはなんだったのか

87. 設計指針

88. サービス特化の実装

89. 僕の考えた最強の設計指針

90. 僕の考えた最低限の設計指針● 安全 (信頼性設計)● 読むコード最小 (メンテコスト)● 早い (ユーザ体験)実装は必要に応じて選び必要であれば最低限自分で書くのが良い

91. ご清聴ありがとうございました www.lowreal.net

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

Hiroh Satoh

Transcript