Embed Size (px)
Citation preview
自己紹介
id:cho45http://www.lowreal.net/
株式会社はてな
京都8F勤務
Perl (バックエンド)
JavaScript (フロントエンド)
Ruby (ツール作り)
Scala (たまにあそびで)
Java (Android アプリ)
Config::PitConfig::ENVPlack::App::CocProxySQL::NamedPlaceholder
JSDeferred
最近は
window.postMessageにハマっています
が
その話はしません
趣味
神社巡り
写真
プログラミングコード群: http://github.com/cho45
日記: http://subtech.g.hatena.ne.jp/cho45/
本題
の前に
前提
1.長期的にメンテナンスする
2.大規模
3.複数人開発
個人で使うフレームワークとか正
直どうでもいいと思う。
フレームワーク
つかってますか
Catalyst, Jifty, Dancer, CGI::Application, HTTP::
Engine, Mason, Squatting, Continuity, Maypole, Tatsumaki,
Mojolicious, Ark, Noe, Kamui, Amon2
ref. http://plackperl.org/
ぼくのかんがえたさい
きょうのうぇぶあぷり
けーしょんふれーむ
わーく
アジェンダ
●良いフレームワークとはなにか
●信頼性設計とかについて
●テストについて
ぼくのかんがえたさい
きょうのうぇぶあぷり
けーしょんふれーむ
わーく
を考える前に
フレームワークの
メリット デメリット
を整理します
メリット
共同開発しやすい
安全なフレームワークは安全
形になるまで早い
バッドノウハウの蓄積
うまくいかないとき
フレームワークのせいにできる
共同開発しやすい
安全なフレームワークは安全
特に重要
デメリット
読むコードが増える
自由度がない
拡張性がない
フレームワークが糞だと
全てが糞になる
フレームワークを覚えるのに
必死になりがち
挙動が意味不明
マジカルなことやりがち
良いフレームワークとは?
読むコードが最小
(共同開発のために)
→ 薄いフレームワーク
安全であること
→ 信頼性設計
読むコードが最小
だいたいフレームワークは
結局ハマって
全部コード読む
だいたいフレームワークは
結局ハマって
全部コード読む
→ 学習コスト増大
フレームワークのコードは
マジカルすぎて
意味不明
フレームワークのコードは
マジカルすぎて
意味不明
→ 読むと Perl に詳しく
フレームワークのコードは
マジカルすぎて
意味不明
→ 学習コスト アゲ♂アゲ
ある prepan.org 作者のつぶやき
「○○っていうフレームワークつかってるん
だけど、もう嫌なんだよね。
フルスタックなんだけどドキュメントよくわ
からないし。
中身読もうとすると意味不明だし」
薄いフレームワークが良い
↑良くいう
薄いフレームワーク
を極める
何も実装がない
フレームワーク
どういうこと？
限りなく薄いフレームワークとは
↓設計指針
● 安全
● 読むコード最小
フレームワークは
実装ではなく設計指針
共同開発に必要なのは
共通の実装ではなく
共通の設計指針
僕の考える設計指針=フレームワーク
安全 (信頼性設計)
読むコード最小 (メンテコスト)
信頼性設計
危険なことをするために
より多くのコストが
必要になるように
例: 最低限必要なXSS対策
デフォルトで HTML エスケープ
[% req.param('query') %]
危ないことをしようとするときは手間をかける
[% req.param('query') | raw %]
読むコード最小
DRY3
3回コピペしたら抽象化しろ
(不必要な/下手クソな抽象化は悪)
設計例: Hatena Blog
長期的に開発することを念頭に
柔軟性
新機能を加えるときに読むべき
コードを最小化
信頼性設計
柔軟性と
読むべきコードの最小化を
同時に達成しようとすると
ドメイン特化にならざるを得ない
安全で最小限な実装を
プロジェクト内に持つ
設計指針を明確にする
僕の考える設計指針=フレームワーク
安全 (信頼性設計)
読むコード最小 (メンテコスト)
再掲
設計指針
安全 (信頼性設計)
読むコード最小 (メンテコスト)
早い (ユーザ体験)
ディスパッチャ
Plack + Router::Simple + α
ビュー
Text::Xslate, JSON:XS, etc...
DBアクセス
DBI生 + SQL::NamedPlaceholder(DBアクセスはコストがかかるので面倒にしとく)
既存実装(Ridge)を使わなかった理由
→ 安全じゃなかったら
→ テストも十分ではなかった
安全にする
テストを十分に
+ app.psgi から
あっちこっちいかずに読み下せるように
安全策
HTML出力時
自動エスケープ
→ XSS対策
POST時にトークン自動チェック
→ CSRF対策
JSON出力時
XMLHtmlRequestのX-Requested-Withを自動チェック
→ IE XSS 対策 / UTF-7攻撃対策 / JSON読み出し対策
自動で
X-Frame-Options: DENY→ クリックジャッキング対策
iframeでロードされたフォームでは
何か変更されないと submit 不可
→ クリックジャッキング対策(どうしても iframe 使う場合のフォールバック)
自動でできるだけ安全に
適切なデフォルトを設定
テスト
テストが大量にあってもメンテしない
レイヤー(Appとか)を増やすとテストが増える
読むコードが増える
↓
最小限の構成Model + Controller
Model のテスト
(仕様があまり変わらない)
ロジックのみ (DBアクセスなし)
細かい挙動をチェック
カバレッジ重視 (ホワイトボックステスト)
例：
use Test::More;
# ロジックしかないので難しいところなしmy $e = Entry->new({body => '..'});is_deeply $e->classes, [ ... ];done_testing;
Controller のテスト
(しばしば細かい仕様が変わる)
ディスパッチ → 出力までTest::WWW::Mechanize::PSGI
ユーザの挙動をシミュレート
(ブラックボックステスト)
例：
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;
早い
use DBI;
ORM は
勝手にDBひくな
ORM は
勝手にblessするな
コストがかかることを
便利にしてはいけない
実装
大枠としてはだいたいこんなかんじですhttps://github.com/cho45/starter.pl/tree/master/templates/mywebapp
(スケルトンジェネレータのテンプレートレベルのコード)
まとめ
ぼくのかんがえたさい
きょうのうぇぶあぷり
けーしょんふれーむ
わーく
とはなんだったのか
設計指針
サービス特化の
実装
僕の考えた最強の設計指針
僕の考えた最低限の設計指針
● 安全 (信頼性設計)
● 読むコード最小 (メンテコスト)
● 早い (ユーザ体験)
実装は必要に応じて選び
必要であれば最低限自分で書くのが良い
ご清聴ありがとうございました
www.lowreal.net
