tonextone.com/note/

Last-modified: 2006-09-01 (金)

Copyright ©master_at_tonextone.com All rights reserved.

PHP の強み

Posted : 2006-05-28 00:00 / Category : [開発日誌]
オープンソーステクノロジー勉強会 第3回」に参加した。
今回のテーマはウェブアプリケーションフレームワーク。
高橋さんが RoR 、藤本さんが Ethna の紹介をするという、大変に豪華な勉強会だった。

高橋さんのお話で興味深かった点をメモ:

RoR: 実行環境の現状。

Apache + mod_ruby :
ruby が富豪的なので、
実際は、Apache + mod_ruby をアプリ専用にして、
フロントにもう一個ウェブサーバ立てるのが普通。
→ 面倒。
じゃあ、WEBrick とか:
フロントに Apache 立てておいて、
アプリ専用のウェブサーバは WEBrick で。
$ apachectl graceful;
的な仕組みが無い。
Apache + FastCGI :
不安定?
Lighttpd + FastCGI :
結構、使われている。でも、Apache ほど多機能ではない。

RoR: 日本語化の現状。

ActiveHeart :
シンプルなので汎用性がある。
スペジェネ :
情熱的なので、ハマる場合と、ハマらない場合がある。
gettext :
本格的だが敷居が高い。

RoR: 文字コードの現状。

デフォルトの文字コード指定 :
$KCODE = 'u'; # s,e,n
フィルタで変換 :
before/after filter に、NKF, iconv フィルタとかを挿せる。

で、PHPはどうなんだ。

PHP: Apache の mod_* だけど…

mod_perl, mod_ruby
Apache を LL で拡張するためのモジュール。
→ 玄人向き。
mod_php
Apache で LL を処理するためのモジュール。
→ それ以外できない。潔い。安全。

PHP: 広く普及している。

普及率が高くて実行環境も mod_php が標準的。
共用レンタルサーバとかでも普通に提供されている。
したがって、既存のシステムの改修などにも利用し易い。

<所感>

共用レンタルサーバとかでも mod_php が採用されているのは、
mod_perl, mod_ruby と違って「必要最低限の事しかできない」からだと思う。
とは言え、mod_* であるからには、Apache の権限で実行されるので、
mod_* に関わる全てのファイルのパーミションは、
---赤の他人のファイルであろうとも---
Apache が読めるようになっている事が「必要」であり、
重要な情報を隠蔽する事が難しい(できない?)。
にもかかわらず PHP は共用サーバにも普及してしまったので、苦肉の策として
safe_mode, open_basedir
などの設定項目が設けられている。

</所感>

PHP: フレームワークは?

フロント・コントローラなフレームワークが主流だが、既存のシステムとの共存が難しいのではないか?
PHP の強みを活かすには、「ページ・コントローラ」なフレームワークのほうが、
既存のシステムと共存しやすくて良いのでは?

<所感>

「ページ・コントローラ」というのは、ページ毎にコントローラを持つという事。
フロント・コントローラ主流の昨今において、「ページ・コントローラ」は原点回帰とも言える。
最近 PHP 界隈で、そういう話がチラホラ出ているけど、半分はネタだと思う。何となく。
実際、高橋さんの話もネタだと思う。

でも、私が 5 年ほど使い続けているフレームワーク的なモノも、
そんな「ページ・コントローラ」に該当する気がする。
ネタではなくマジで使い込んでしまっている。
なので、「ページ・コントローラ」の実装例として、後でちゃんとまとめる事にしよう。

</所感>

トラックバック

(2)

ツッコミ

1: kdmsnr (06/01 17:19)
> 実際、高橋さんの話もネタだと思う。

ネタではなく、いつも言ってます。
2: master (06/01 23:39)
> kdmsnr さん
ありがとうございます。
ネタじゃないんですね!それは心強いです。
ずっと「ページ・コントローラ」でがんばってきた自分としては、
「ページ・コントローラ」という名前がついただけでも嬉しいのですが。

capsctrl チェックしてます!
[ このエントリへはツッコミ出来ません ]