kphpug beginners-2
DESCRIPTION
関西PHP初心者勉強会なぜなにフレームワーク一年生TRANSCRIPT
なぜなにフレームワーク一年生関西PHP初心者勉強会 #2
自己紹介• 田中 久輝
たなかひさてる
• @tanakahisateru
• PinocoというWebサイト向けのフレームワークを作っています
•独自のコンセプトを持ったWebフレームワークを作っています。
• Pinoco-0.6.0 : WebアプリケーションよりWebサイトづくりのFWです。なので今日はこの話はパスします。
•いろんなフレームワークを浅く広く見てきました。
ようこそフレームワーク小学校へ
さらばPHP園児ニア
フレームワークの長所
• 命名規則やディレクトリ構成などの規則が統一されており、大規模な開発に向いている
• コードの再利用性が高いため、効率的な開発を行える
• 開発に制約を設けることで、セキュリティ・保守性が高まる
www.phppro.jp/article/framework/framework.phpPHPプロ
フレームワークの長所
• 命名規則やディレクトリ構成などの規則が統一されており、大規模な開発に向いている
• コードの再利用性が高いため、効率的な開発を行える
• 開発に制約を設けることで、セキュリティ・保守性が高まる
なんのこっちゃ
www.phppro.jp/article/framework/framework.phpPHPプロ
PHP園児ニアのやり方と比べてみるとすぐわかる
本当にあった怖い引継ぎ案件の話
もしもこんな要求仕様があったら...
•ユーザが記事を投稿できる
•一覧ページと投稿フォームがある
•入力エラーチェックあり
•フォームから投稿すると一覧ページに戻って投稿結果を表示
だめな実装
•入力チェックがJavaScript / もしくは失敗するとエラーページに飛ばす
•記事保存に成功したらレスポンスとして一覧HTMLを出力する
どんな不具合が?
•データに不正な投稿が入ってくる
•エラーページから戻るとフォームで入力したテキストが消えてしまう
•一覧ページでブラウザの更新ボタンを押すと直前に書いた記事が複製されることがある
嘘みたいですが実在します
しかも2009年に稼働開始したシステムで
バリデーションの掟• JavaScriptが効いてると思うな
• サーバ側に最終チェックが要る
• でもif文で書くと超めんどくさい
• エラーページではなくフォームを出したままエラー入力フィールドを赤表示する
• でもその制御を書くのはちょっと難しい
バリデーションの掟• JavaScriptが効いてると思うな
• サーバ側に最終チェックが要る
• でもif文で書くと超めんどくさい
• エラーページではなくフォームを出したままエラー入力フィールドを赤に
• でもその制御を書くのはちょっと難しい
と、いうのはいったん忘れて
フレームワーク的バリデーション
•「データはこういう形式だ」と定義しておけば自動的に最終チェックが走る
•エラーフィードバック付きのフォームHTMLが一発で出せる
•お約束のフローが決まっている
らくちん=重要
データ更新系の掟•データが変化するアクションと表示のためのアクションは別のURLにする
•保存が成功したら表示用のURLにリダイレクトすること
•表示系のページで「保存しました」という文言を出す
$s = $pinoco->request->server;
// プロトコル$protocol = $s->get('HTTPS') ? "https" : "http";
// ホスト名$server_prefix = $protocol . '://' . $s->get('SERVER_NAME');
// ポートif ($protocol == "http" && $s->get('SERVER_PORT') != "80") { $server_prefix = $server_prefix . ":" . $s->get('SERVER_PORT');} else if ($protocol == "https" && $s->get('SERVER_PORT') != "443") { $server_prefix = $server_prefix . ":" . $s->get('SERVER_PORT');}
// 略
// ターゲットURLを絶対パスに$fixedurl = $server_prefix. $pinoco->url($this->url);$pinoco->header('Location: ' . $fixedurl);
実はリダイレクトの実装は難しい(フルURLが必要なので)
•リクエスト1回する間しか生存しないCookieを使って解決
•保存アクションでリダイレクト前にCookieを作る
•リダイレクト先で取り出して表示し、やったらすぐ消す
リダイレクト後にメッセージを出すときはフラッシュメッセージ
と、いうのはいったん忘れて
フレームワーク的データ更新系
if($data->save()) { $user->setFlashMessage(“保存しました”); $this->redirect(array('article/index'));}
こんな感じフラッシュメッセージの表示と削除は転送後のページで自動的に行われます
かんたん=重要
ちなみにソースレイアウト
この調子で100ファイルほど
各PHPの中身はこんな感じ1ファイルで1リクエスト200～600行ぐらい <?php同じパターンが何度も何度も
よくもこんな設計を残してくれたなと、恨みを買わないために
フレームワーク的ファイルレイアウト
スタティックファイル
ドキュメントルート
決まったフォルダ構成
ちょっと複雑だけど
•実務プロジェクトはどうせ実務の都合で複雑になる
•オレオレ整理術はいちいち説明しないと引き継げないし案件ごとに変わる
きまり=重要
こんな上手いやりかたはプレーンPHPをいくら調べても発想できません
ここまでのポイント
•フレームワークは実体を伴う考え方
•正しい方法のほうが簡単にできる
•正しくない方法は逆にめんどくさい
•自然とそれがへたっぴ矯正ギブスに
•得られた良い習慣を他人と共有できる
• 命名規則やディレクトリ構成などの規則が統一されており、大規模な開発に向いている
• コードの再利用性が高いため、効率的な開発を行える
• 開発に制約を設けることで、セキュリティ・保守性が高まる
つまり
なんのこっちゃ
• 命名規則やディレクトリ構成などの規則が統一されており、大規模な開発に向いている
• コードの再利用性が高いため、効率的な開発を行える
• 開発に制約を設けることで、セキュリティ・保守性が高まる
つまり
きまりらくちんかんたん
達人の技
説明はいいから早くブツを出せ
はいすみませんYiiでデモします
たぶん誰も使わないので公平なチョイスのなず
デモ中
• いま「見たことない関数がいっぱいで難しそうだな」って思ってます?
• でも仕事のコードはそれと同じかもっと無駄に難しいですよ。マニュアルの整備も保証されているかどうか。
• 同じ難しさだったら、いちど憶えたら何度も使える技術が手に入るほうがいいですね。
重要キーワード•フレームワークの概念を理解するのに大事な3つの言葉
• SoC : Separation of Concerns• IoC : Inversion of Control• CoC : Convention over Configuration
なんのこっちゃ
SoC : 関心事の分離
• 意味的に関係あることを集める
• 意味的に関係ないグループは離れさせる
• 離れたものに変更があっても直接影響を受けないようにしておく
• 意味的な「凝集度」の高さ
ベタに言うとつまりMVCとかです
•Model: データとビジネスロジック
• View: データや機能の表示
• Controller: 上の2つを制御
•M-V-C間で互いの詳細を知らなくていいので今の作業に集中できる
MVCを理解する近道• Symfonyのユーザガイドの2ページ目
• 「フラットな PHP から Symfony2 へ」http://docs.symfony.gr.jp/symfony2/book/from_flat_php_to_symfony2.html
• 全PHPユーザがまず最初に読むべき文書
• 一般的なWebフレームワークの動作原理も理解できます
もっとわかりやすい例
•基本システムと顧客の都合は別の関心事じゃない?
•基本システム=フレームワーク設計
•顧客の都合=あなたが解決する問題
•互いに変更影響少ないよね
MVCに限らず、SoCなポイントがいろいろあるのでよ
く観察しましょう
IoC : 制御の反転
•あなたはフレームワークを使っていません
•フレームワークがあなたを使うのです
どういうこと!?
• 普通はユーザのコードがライブラリの関数を呼び出す感覚。
• 制御が反転すると、自分のコードが他人の都合で呼び出される。
つまりプラグイン• Webブラウザとエクステンション(プラグイ
ン)の関係。
• ブラウザがエクステンションを制御する。エクステンションはブラウザを支配しない。
• プラグインは基本ソフトのすべてを知らなくていい。必要なポイントだけカスタマイズする。
フレームワークがないとき
• 新規開発=トップダウン的
• 既存コードの呪いがなくてやりがいがある
• 基本設計をすべて自力でやる手間がかかる
• 保守開発=IoCに近い
• 基本設計は済んでいるのですでに動く
• その代わり変な独自仕様という呪いがある
あるとき～♪(大阪)
• フレームワークを使うと保守開発と同じスタートラインから新規開発できる
• しかも元にするコードの品質は最高レベルの達人の技をパッケージ化したもの
• 保守を引継ぐときの面倒が激減
• 「ライブラリ」との最大の違いはこれ
「使いこなさなきゃ」と思わなくていい。むしろ「都合よく使われる」を意識。
CoC : 設定より規約• Ruby on Rails 以降の新しい言葉
•面倒な設定させるより、最初からルールを決めておこう
•ルールの実践はコンピュータにさせる
•ぜんぶデフォルトでも動く
そうすると•デフォルトから外れるには面倒な設定が要る→何度かやってると、面倒なのでもうデフォルトでいいやってなる
•デフォルトにするとコーディングが標準化される→規約が共有できる
•標準=他人がわかってくれる安心感
たとえば
• URLは /クラス名/メソッド名
•名前にadminを含むものはすべて認証が必要
•データベースのテーブルは複数形で、データを表すクラスは単数形
かつて良いソフトウェアとされていたもの
•あんな設定もこんな設定もあります
•あなたの考えに合わせてどんな風にも使えます
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"><web-app> <servlet> <servlet-name>ShowDate</servlet-name> <servlet-class>ShowDateServlett</servlet-class> </servlet> <servlet-mapping> <servlet-name>ShowDate</servlet-name> <url-pattern>/SDate</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Basic Authentication</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>UserDatabaseRealm</realm-name>
こういうやつですね
男性に例えるとこういうタイプ
「ねえねえ何がしたい? 遊園地? 映画? じゃあ映画に行くなら何が観たい? コメディ系だったら2作品あるけど どっちにする? 映画の後は何する?」
「キミが望むことは何でも言ってくれたら やるから全部言ってね」 （よっしゃ俺いい男だな）←ここが痛い
CoCはイケメン「映画行こうよ。オススメはこれ。 で、映画の後はここ行こうぜ」
「大丈夫、俺の言うとおりにしたら 絶対楽しめると思うよ」
惚れてまうやろ
※ただしイケメンに限る
避けたいアンチパターン:イケメンだと思ったらただのチャラ男だった
本気でお付き合いする相手をちゃんと見極めましょう。本当に使う前に、いろいろなフレームワークを知っておくのは良いことです。
先輩からのことば
完璧なFWなどどこにも無い。要件にあったものを使うのが良いが、どれを選んでよいか分からない時は、簡単そうで普及してて情報が多いものを選んどけば良いと思います、本がたくさん出てるとか。FWの動作環境のPHPバージョンに注意。 cake_beer!!
@cakephper
分からない事はソースコードを読め。
@ktz_alias
フレームワークだからといって身構えることない、Webアプリを作るお便利ツールの集まりだよ
@atakig
cakephpに限らずFWって学習時のストレスがたまにしんどくなる。だからこそ学習前に、そのFWを惚れ込むことが大事だと思う。
@mon_sat
巨人の肩の上に立つStanding on the shoulders of giants
12世紀のフランスの学者シャルトルのベルナール（Bernard of Chartres）の言葉とされるもので現代の学問は多くの研究の蓄積の
上に成り立つという意味である。Wikipedia
フレームワークとは、先人の知見の自動適用装置
すごい人の肩ぐらいの高さから始めよう
偉大な先輩に感謝