WEBアプリケーション勉強会第一回at a glance

今日のついったー今日の Hashtag

#ht_webapp で

この資料の扱いについて自由に使ってもらってもいいですが，できれば

morimori@ht.sfc.keio.ac.jpに一度声をかけてくれるとうれしいです

今回の話昔の開発と今の開発では全然違う

技術，開発体制，納期，単価 etc.でもその辺の話をしてくれる本は少ない

相変わらず入門本は7年以上前の書き方を書いている新しい本は初心者には敷居が高すぎる

というわけで，Webアプリ開発初心者でもここ最近のWebアプリ開発の流れが分かるような会にしたいと思います．

今回の聴講対象適当な言語を使って，自力で何らかのWebアプリを書いたことがある某在籍管理システムとか

Linux/RDBMS/LL(Lightweight Language)をとりあえず触れる

でも最近のWebアプリ開発がよく分からない人今ひとつWebアプリの中の動きが見えない人

MORIMORI WEBアプリ開発経歴など Web開発8 年くらいやってます

EC系から業務アプリまでサーバ構築から運用サポートまで少人数開発がメイン

とりあえず歴史的な話

WEBアプリケーション今昔

原始時代（ 1999〜 2002くらい？） 開発言語は Perl， PHP（3 とか 4 ）．あと JSPとか Ajaxって何ですか？ CSSなんてまだ全てのブラウザに実装されてません！

段組って tableタグで作るものですよね？普通 ソースコード関連

SQLは直書き．当然 RDBMS依存 書くプログラマによって全然違うコード 入力値チェックは手動．もしくは無し 基本的には構造化プログラミング．昔の PHPには classなんて無かった

Webアプリ開発が結構”ぼろい”商売として成り立っていた この頃は Adobe Cold FusionとかでWebアプリ作ってたこともあった

ま，まだ滅びてなんていないんだからね！！！

原始時代WEBプログラミングにおける問題 コードが冗長，拡張性が無い

拡張性があるコードで書かれていても，俺ルールで書いてあるため他人が解読するのは大変

デザイン修正が困難 デザイン（ HTMLタグ）がソースコードに埋め込まれているため，デザインを変更するのにもプログラマのお伺いを立てる必要があった

Portability RDBMS，環境依存のコードにより，言語や RDBMSのバージョンを上げるのが怖い

Security 懐かしの SQL Injectionやら CSRF，セッションハイジャックなどなど，話題に上がる度に手動で対応するしかない

再利用性 よっぽど汎用性の高い関数くらいしか再利用できなかった

原始時代から戦国時代へクオリティの高いライブラリの登場

PEAR, CPAN, rubygems, etc.デザインとアプリケーションを分けるテンプレートエンジンの出現 Smarty, Velocity

RDBMS 非依存のライブラリ， O-Rマッパの出現 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なのか分からない当然開発停止の Projectも膨大に出たので，サポートを考えるとリスクが高かった

Rubyにおける Railsの様なデファクトスタンダードが存在しなかった 唯一 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マッパーを使う Propel, Doctrineなど

Formバリデーション関係 PEAR::HTML_QuickFormとかその辺

ログイン周り フレームワークについてる奴を使うとか

ページング 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？コミュニティが活発

0.9の頃からヲチしているが，活発な活動を続けている

完成度が高い RoRの影響を受けているので，自動コード生成など至れり尽くせり． Kool!!

初期から i18n対応日本語が問題なく通る

その他の競合フレームワーク 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）のこと これで管理機能は完成！（ちょっと乱暴だけど）