Download as PDF, PPTX
![例: 最低限必要なXSS対策
デフォルトで HTML エスケープ
[% req.param('query') %]
危ないことをしようとするときは手間をかける
[% req.param('query') | raw %]](https://image.slidesharecdn.com/yapcasia2011-111014231854-phpapp02/75/YAPC-Asia-2011-52-2048.jpg)
![例：
use Test::More;
# ロジックしかないので難しいところなし
my $e = Entry->new({body => '..'});
is_deeply $e->classes, [ ... ];
done_testing;](https://image.slidesharecdn.com/yapcasia2011-111014231854-phpapp02/75/YAPC-Asia-2011-74-2048.jpg)
More Related Content
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
- 1. ぼくのかんがえたさいきょうの うぇぶあぷりけーしょん ふれーむわーく cho45 <cho45@lowreal.net> 株式会社はてな
- 2.
- 3.
- 4.
- 5. Perl (バックエンド) JavaScript (フロントエンド) Ruby(ツール作り) Scala (たまにあそびで) Java (Android アプリ)
- 6.
- 7. 最近は window.postMessage にハマっています
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 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.
- 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.
- 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.
- 65. POST時にトークン自動チェック → CSRF対策
- 66. JSON出力時 XMLHtmlRequestの X-Requested-Withを自動チェック → IE XSS 対策 / UTF-7攻撃対策 / JSON読み出し対策
- 67.
- 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_usermechanize); # 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.
- 79.
- 80.
- 81.
- 82.
- 83. 大枠としてはだいたいこんなかんじです https://github.com/cho45/starter.pl/tree/master/templates/mywebapp (スケルトンジェネレータのテンプレートレベルのコード)
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90. 僕の考えた最低限の設計指針 ● 安全 (信頼性設計) ●読むコード最小 (メンテコスト) ● 早い (ユーザ体験) 実装は必要に応じて選び 必要であれば最低限自分で書くのが良い
- 91.