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

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アプリケーションフレームワークことはじめWEBアプリケーションフレームワークことはじめ

フレームワークの話の前に • 何も考えず，Blogシステムを書いてみる • 機能要件 • トップページにアクセスすると，最新5件の記事が見られる • 記事は日時，タイトル，本文がある • ページにある「新規投稿」ボタンを押すと記事投稿画面へ • 投稿画面で「投稿」ボタンを押すと記事を投稿できる • 画面設計 • トップページ（記事のリスト表示） • 投稿入力ページ（投稿内容の入力） • 投稿完了（投稿完了処理）

画面遷移 input.php index.php submit.php

とりあえずのソースコード1 index.php

とりあえずのソースコード2 input.php

とりあえずのソースコード3 submit.php

とりあえずのテーブルとライブラリ blog_lib.php

とりあえずここまで見ると・・・ • これくらいのアプリならベタ書きでいいんじゃね？と思った人は正しいかも • これくらい単純極まりないアプリの場合，ベタで書いた方が早い事もある • 実際，データのバリデーションさえやっておけばこのコードでも問題ないかも • でも，仕事で開発をした場合，通常これだけで開発が終わることはないカオスな世界へ

サンプルを見て来そうな要望など • 投稿の削除，編集機能 • 誰でも投稿できてしまうので，ログイン機能 • ログインユーザの管理機能 • 記事が増えてきたときのページング機能 • アクセスログも見たい！ • 画像を記事に載せたりしたいなぁ • デザインも今風に変えたい！！！ • コメントを付けたいね．あと投稿にタグとか付けたい Webアプリが一般的になったので，お客さんの目も肥えてきたニダなのでクオリティも高いものを要求されるニダ（ちなみに価格は安くなっているXD）

機能が増えると何が変わるか？ • スクリプトの数が増える • 今まで通り1ページ1つのスクリプトを置いていた場合，単純に画面の数だけスクリプトの数が増える！ • login.php • do_login.php • edit_article.php • delete_article.php • etc. • ライブラリ関数の数が増える • テーブル構造が変わる • デバッグが大変になる • デザインの変化に対応しきれない

スクリプトの数が増えると・・・ • 各スクリプトの初期化処理を変えると，全て変更する必要がある • セッション関係の初期化（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/

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

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

Presentation Transcript