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

2. 自己紹介

3. id:cho45
http://www.lowreal.net/

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

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

6. Config::Pit
Config::ENV
Plack::App::CocProxy
SQL::NamedPlaceholder
JSDeferred

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. アジェンダ
● 良いフレームワークとはなにか
● 信頼性設計とかについて
● テストについて

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

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. まとめ

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

86. とはなんだったのか

87. 設計指針

88. サービス特化の
実装

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

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

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