Transcript Webアプリケーションってどんなもの？

WEBアプリケーション勉強会第一回
at a glance
今日のついったー

今日のHashtag
#ht_webapp で
この資料の扱いについて

自由に使ってもらってもいいですが，できれば
[email protected]に一度声をかけてくれると
うれしいです
今回の話

昔の開発と今の開発では全然違う


技術，開発体制，納期，単価etc.
でもその辺の話をしてくれる本は少ない
相変わらず入門本は7年以上前の書き方を書いている
 新しい本は初心者には敷居が高すぎる


というわけで，Webアプリ開発初心者でもここ最近のWebアプ
リ開発の流れが分かるような会にしたいと思います．
今回の聴講対象

適当な言語を使って，自力で何らかのWebアプリを書いたこと
がある

某在籍管理システムとか
Linux/RDBMS/LL(Lightweight Language)をとりあえず
触れる
 でも最近のWebアプリ開発がよく分からない人
 今ひとつWebアプリの中の動きが見えない人

MORIMORI WEBアプリ開発経歴など

Web開発8年くらいやってます
EC系から業務アプリまで
 サーバ構築から運用サポートまで
 少人数開発がメイン

とりあえず歴史的な話
WEBアプリケーション今昔
原始時代
• フレームワークなどは使わず，直接スクリプトファイルを編
集
• 開発は1〜3人くらい．フルスクラッチから書き始める
戦国時代
• 色々なフレームワークやライブラリをとりあえず使ってみる
• Webデザイナが別職種として現れ始める
現代
• 使うフレームワークも大体安定し始める
• 開発速度が上がり，単価が下がる．
原始時代（1999〜2002くらい？）



開発言語はPerl，PHP（3とか4）．あとJSPとか
Ajaxって何ですか？
CSSなんてまだ全てのブラウザに実装されてません！


段組ってtableタグで作るものですよね？普通
ソースコード関連
SQLは直書き．当然RDBMS依存
 書くプログラマによって全然違うコード
 入力値チェックは手動．もしくは無し
 基本的には構造化プログラミング．昔のPHPにはclassなんて無
かった


Webアプリ開発が結構”ぼろい”商売として成り立っていた

この頃はAdobe Cold FusionとかでWebアプリ作ってたこともあっ
た
ま，まだ滅びてなんていないんだからね！！！
原始時代WEBプログラミングにおける問題

コードが冗長，拡張性が無い


デザイン修正が困難


RDBMS，環境依存のコードにより，言語やRDBMSのバージョン
を上げるのが怖い
Security


デザイン（HTMLタグ）がソースコードに埋め込まれているため，デ
ザインを変更するのにもプログラマのお伺いを立てる必要があった
Portability


拡張性があるコードで書かれていても，俺ルールで書いてあるため
他人が解読するのは大変
懐かしのSQL InjectionやらCSRF，セッションハイジャックなどな
ど，話題に上がる度に手動で対応するしかない
再利用性

よっぽど汎用性の高い関数くらいしか再利用できなかった
原始時代から戦国時代へ

クオリティの高いライブラリの登場


デザインとアプリケーションを分けるテンプレートエンジ
ンの出現


Smarty, Velocity
RDBMS非依存のライブラリ，O-Rマッパの出現


PEAR, CPAN, rubygems, etc.
PDO，PEAR::DB，Propel
色々と面倒くさいことをやってくれるフレームワークの登
場

mojavi, agavi, Maple, Ethna, etc.
それぞれがどんなものかはとりあえずスルーの方向で
戦国時代（2003〜2006くらい）

開発言語はClass対応したPHP4/5が主流

LAMPという言葉が流行った（本当）

Linux+Apache+MySQL+PHP
これまでStaticなページだけ書いていれば良かった
WebデザイナがWebアプリ分野にも参入し始める
 そこかしこでCSS啓蒙活動が実施．企業などでもCSSを
使ったデザインをし始めるようになる
 多数のPHPフレームワークが出ては消えていった．そし
て日本はガラパゴス化の道を辿った;-P


いずれも成熟度は低く，自分でカスタマイズしないといけな
いことも多かった
戦国時代WEBプログラミングにおける問題

ライブラリ選定の困難

あらゆるライブラリが出ては消え，出ては消えしまくっていた
ため，どのライブラリがstableなのか分からない


RubyにおけるRailsの様なデファクトスタンダードが存在し
なかった


当然開発停止のProjectも膨大に出たので，サポートを考えるとリス
クが高かった
唯一Smartyがテンプレートエンジンのデファクトスタンダードといっ
ても良いかも
Webデザイナの不理解
デザイナ畑の人にテンプレートの編集をお願いすると，大抵
完膚無きまでに破壊されて帰ってきた
 WebデザイナにもWebアプリケーション側の知識が必要に
なってきた

戦国時代から現代へ

ようやくデファクトと言えるフレームワークの登場


ライブラリの過渡期も過ぎ，導入事例も増え，安定して
開発を続けるプロジェクトが残るようになった


Symfony, Zend Framework CakePHPあたり
ライブラリ選定が容易に，リスクが小さくなった
Webデザイナも参入してくる数が増えたせいか，昔ほど
使えないデザイナに会う機会は減ったので，淘汰された
ように思える
現代（2007〜）
まともな開発であれば，通常フレームワークを使って開
発するようになった
 信用がおけるデザイナであれば，テンプレートの編集を
任せることもできるようになった
 ソースコードの変化


SQLを見ることはほとんど無くなった

パフォーマンスチューニングは例外
フレームワークの知識がないといじれなくなった
 ほとんどのコードは自動生成してくれるので，ビジネスロジッ
クを書くのに専念できるようになった

現代における問題

フレームワークを使った開発は，新規参入者にとってはハー
ドルが高い


同じ理由で，自主学習意識の低いプログラマには理解されない
フレームワーク自体の習得にはやや時間がかかるので，修
行期間が必要
まとめ

Webアプリ開発はここ10年くらいですごく大きく変わっ
てきた
最初はみんな思い思いに書いていた牧歌的な時代
 ライブラリ開発者がしのぎを削った戦国時代
 ある程度のスタンダードができつつある現代


これからの流れでは，Webアプリケーションプログラマを
名乗るのであれば，フレームワークの知識は必須

フレームワークの利点などについては次の章で
WEBアプリケーションフレームワーク
ことはじめ
フレームワークの話の前に
何も考えず，Blogシステムを書いてみる
 機能要件

トップページにアクセスすると，最新5件の記事が見られる
 記事は日時，タイトル，本文がある
 ページにある「新規投稿」ボタンを押すと記事投稿画面へ
 投稿画面で「投稿」ボタンを押すと記事を投稿できる


画面設計
トップページ（記事のリスト表示）
 投稿入力ページ（投稿内容の入力）
 投稿完了（投稿完了処理）

画面遷移
index.php
input.php
submit.php
とりあえずのソースコード1
index.php
とりあえずのソースコード2
input.php
とりあえずのソースコード3
submit.php
とりあえずのテーブルとライブラリ
blog_lib.php
とりあえずここまで見ると・・・

これくらいのアプリならベタ書きでいいんじゃね？と思っ
た人は正しいかも
これくらい単純極まりないアプリの場合，ベタで書いた方が
早い事もある
 実際，データのバリデーションさえやっておけばこのコードで
も問題ないかも


でも，仕事で開発をした場合，通常これだけで開発が
終わることはない
カオスな世界へ
サンプルを見て来そうな要望など


投稿の削除，編集機能
誰でも投稿できてしまうので，ログイン機能






ログインユーザの管理機能
記事が増えてきたときのページング機能
アクセスログも見たい！
画像を記事に載せたりしたいなぁ
デザインも今風に変えたい！！！
コメントを付けたいね．あと投稿にタグとか付けたい
Webアプリが一般的になったので，お客さんの目も
肥えてきたニダ
なのでクオリティも高いものを要求されるニダ
（ちなみに価格は安くなっているXD）
機能が増えると何が変わるか？
1.
スクリプトの数が増える

今まで通り1ページ1つのスクリプトを置いていた場合，単純
に画面の数だけスクリプトの数が増える！
login.php
 do_login.php
 edit_article.php
 delete_article.php
 etc.

2.
3.
4.
5.
ライブラリ関数の数が増える
テーブル構造が変わる
デバッグが大変になる
デザインの変化に対応しきれない
1. スクリプトの数が増えると・・・

各スクリプトの初期化処理を変えると，全て変更する必
要がある
セッション関係の初期化（session_start()）
 必要なライブラリのinclude
 会員認証ページの場合，ログインしているかどうかの判定



ロギング処理など



これ，すごく忘れやすいので注意
そもそも忘れるとログの意味がないLOL
PHP環境変数の設定（ini_set()）
複数人で開発しているとさらに訳が分からないことにな
る
フロントコントローラという解

フロントコントローラ方式とは


1つのコントローラスクリプトが全てのリクエストを受け付け，リクエス
トの内容に応じて必要な機能を呼び出す方式
リクエストは必ずコントローラを通るため，前処理は全てここに
まとめて記述できる
簡単なフロントコントローラの例
/index.php?a=list
とか，
/index.php?a=article_input
みたいな形でURLを指定する
2. ライブラリ関数の数が増える

よくよく見てみると，似たような機能を大量に書いている
ことが分かる

DB関係
条件を指定してSELECT
 特定の外部キーでSELECT
 新しい行をINSERT
 既存の行の一部をUPDATE
 指定した行をDELETE

ユーザ入力値のバリデーション
 ログイン周りの処理
 ページング
 ロギング

色々なライブラリを使う

DB関係

O-Rマッパーを使う


Formバリデーション関係


フレームワークについてる奴を使うとか
ページング


PEAR::HTML_QuickFormとかその辺
ログイン周り


Propel, Doctrineなど
PEAR::Package::Pager？
ロギング

PEAR::Log
3. テーブル構造が変わる

テーブル構造が変わると生SQLはすごく影響を受ける

根本的なテーブル構造の変更


フィールドの追加


全部書き直し＼(＾o＾)／
not null属性を追加すると，insert文は全て再確認しないとエラー
で止まる
フィールドの削除

該当テーブルを参照するSQLを全て確認 ／ (＾o＾) ＼
「これくらい簡単でしょ？ちゃちゃっとやっちゃってよ」という言葉に軽く殺意が湧きます:-P
そもそもSQLを使わないライブラリを使う

O-Rマッパーを使えばSQLとはオサラバ

特定のRDBMSにも依存しなくなってGood
4. デバッグが大変になる

テーブル構造の変更や，謎のバグが発現すると，必ず
変数をdumpして見たくなることがある


ライブラリが大きくなると，あちこちでSQLを呼んだり関数を
呼んだりしているので，デバッグコードを挿入するだけでも面
倒
昔のコードとか他人のコードの場合，全体構造から把握
しないといけないので辛すぎる

延々追いかけたあげく，デザイナのテンプレート修正ミス
だったりとかwwwww
自動的にロギングされる方法を使う
PEAR::Logとかは明示的にログを書かないといけない
 フレームワークのLoggerはある程度自動でログを吐い
てくれるので，便利

どんな関数を呼んだか
 どんなSQLを発行したか
 どの処理にどれだけ時間がかかったか
 そのページで使われたセッション変数やRequestパラメータ

5. デザインの変化に対応しきれない

スクリプトにHTMLタグとPHPのコードが共存していると，
Webデザイナに弄らせるのが恐ろしすぎるため，結局プ
ログラマが編集する事になる

最近の細かいCSSの知識もプログラマに必要になる


かなりきつい．ブラウザ依存などもあるし
でもたまにデザイナが勝手にコードを修正して破壊され
ることもある（お客さん側で勝手に編集することがある）
テンプレートの概念を導入する

HTMLとプログラムロジックを分離する
HTMLはテンプレートファイルに分離し，テンプレートファイ
ルには最低限の処理を記述する
 テンプレートファイルはデザイナに弄ってもいいよと言ってお
く


Smartyなどのテンプレートエンジンを使う

テンプレート側でそもそもPHPのコードが使えないので，破
壊される心配がない

ただし，プログラマ・デザイナ共にSmartyタグという独自タグを勉強
する必要がある
結局フレームワークって何をやるの？

最近のフレームワークの機能








フロントコントローラ＋α
O-Rマッパー
テンプレートとビジネスロジックの分離
外部Pluginの開発・サポート
フォーム生成
デバッグ機能
ロギング
etc.
MVCの分離
フレームワークには「あるといいな」がある！
細かいことはできるだけほっといて，
フレームワーク使ってみる
フレームワークを使う前に

この手のフレームワークでは，CoC（Convention over
Configuration）が常識



何を言いたいかというと，規約を定め，それに沿って書くこと
で




Convention – 慣例，規約
Configuration – 設定
色々なコードが自動生成できる
プログラマの俺ルールの範囲が狭まり，チーム開発しやすくなる
といった恩恵が受けられるという話．
新規参入者は大体ここで引っかかる


好きなようにやらせてくれよ！とか思ってはダメ
最初は面倒だけど，必ずそれに勝る恩恵が待っている！
フレームワークを使った開発では，そのフレームワークの規約を
理解し，ルールに従ったコードを書くことが重要！！！
MVC的な基本的な話

一般的なMVCモデル
Model - データの処理などを担当
 View – UI等を担当
 Controller – ユーザの処理をハンドリングする


Webアプリでは
Model – O-Rマッパーなどのデータ処理ライブラリ
 View – HTMLテンプレートなど
 Controller – フロントコントローラ

WHAT’S SYMFONY？

特徴
Mojavi3-DEVから派生したPHP Webアプリケーションフレーム
ワーク．RoR(Ruby on Rails)からの影響も受けている
 開発コミュニティが活発，Documentが充実（最新に追いついてい
る）


Symfonyでできること








YamlからのModel一括生成
MVCの分離
O-RマッパーPropel/Doctrineのサポート
高機能なデバッグ機能
ロギング機能
キャッシュによる高速化
セッション変数の一括管理
その他いろいろ
WHY SYMFONY？

コミュニティが活発


完成度が高い


RoRの影響を受けているので，自動コード生成など至れり尽
くせり．Kool!!
初期からi18n対応


0.9の頃からヲチしているが，活発な活動を続けている
日本語が問題なく通る
その他の競合フレームワーク
Zend Framework: PHP開発に加わっているZendが作っ
ているフレームワーク
 CakePHP: 割と最近出てきたフレームワーク．Symfonyより
も構造が単純

フレームワークを勉強する前に

一つをマスターする前に色々かじるのはNG


コミュニティが活発なものを選ぶ



どれも使えなくなるので注意
日本人しか使っていないものは危険
オブジェクト指向言語が怪しければ先にそっちを勉強した方
がいいかも
壊してもいい開発環境を手に入れておく
SYMFONYのCONTROLLERモデル

Symfonyでは，アプリケーション，モジュール，アクションの3
階層のControllerモデルを採用している

アプリケーション



モジュール


一つの機能群．例えばログインmoduleとかブログmoduleみたいな感じ
アクション


一番大きな単位．例えばアプリケーションそのもの．ここで分けるとすれ
ば，管理用のアプリケーションとユーザに見せるアプリケーションに分け
たりする．
アプリケーション同士は独立したものと考えると良いかも
最小の機能単位．ここにコードを書く．例えばブログmoduleであれば
listActionとかaddAction, EditActionみたいになる
URLは基本的に/${MODULE}/${ACTION}になる

設定で変更可能
※この辺はフレームワークによって違うので，使うフレームワークのDocumentを参照
SYMFONYのCONVENTION（DIRECTORY
その1）

Symfonyは$SF_ROOT (アプリケーションディレクトリ)
以下を次のように定めている










apps – コントローラ，テンプレートを格納（後述）
cache – キャッシュ置き場
config – 設定ファイル置き場
data – テストデータ置き場
doc – ドキュメント置き場
lib – モデル置き場
log – ログファイル置き場
plugins – プラグイン置き場
test – テストコード置き場
web – ドキュメントルート
SYMFONYのCONVENTION(DIRECTORY
その2)

apps以下は

${アプリケーション名}のディレクトリが作られ，その下がさら
に
config – アプリケーションのコンフィグ置き場
 i18n – 言語ファイル置き場
 lib – アプリケーションライブラリ置き場
 modules – モジュール（後述）置き場
 templates – アプリケーションテンプレート置き場


modules以下は

${モジュール名}のディレクトリが作られ，その下がさらに
actions – Action置き場
 templates – テンプレート置き場

訳が分からなくなってきた？ですよね LOL
CONVENTIONのメリットとか
lib以下に置いたクラスファイルは，Controllerから明示
的にincludeしなくても使うことができる
 configの中身を変えるだけで，MySQL, SQLite，
PostgreSQL,etc.の色々なRDBMSに対応可能
 その他まだまだ色々あります

もうめんどいのでLIVE CODINGしてみる

手元にSymfonyの開発環境があるのでやってみます


ちなみに交響曲の方はSymphonyです
CentOS5.3でこんな感じの環境です

http://www.jasonlitka.com/yum-repository/



のリポジトリをyumに追加（PHP 5.2系インストールのため）
yum install php php-cli php-xsl php-pear, mysql
mysql-server
Symfony 1.2系（current）はPHP5.2が必要

1.0, 1.1系はPHP5.0系でも動いた気がする
そろそろ力尽きたので終わり
Symfonyみたいなフレームワークを使った開発はこん
な感じです
 次回はもうちょっとコーディングとか開発現場に寄った
話をしたいと思うので，希望があれば言って下さい
 Symfony使ってみたいという人は，VMWare辺りに
CentOSでも入れて，Symfony公式の「My First
Project」というチュートリアルをやってみるといいです


公式：http://www.symfony-project.org/
SYMFONYでの開発手順（その1）
1.
適当なディレクトリに入ってsymfony generate:project ${PROJECT}
2.
まずはconfig/databases.ymlを設定して，DBを作る
3.
config/schema.ymlを編集して, symfony propel:build-all．これで
Modelができる
4.
symfony generate:app ${APP_NAME}，これでアプリケーションがで
きる
5.
symfony propel:generate-admin ${APP_NAME} ${MODEL} –
module=HOGEHOGE，これでCRUDができる


CRUD（Create, Read, Update, Delete）のこと
これで管理機能は完成！（ちょっと乱暴だけど）