ZF#03 基本＋隠しディレクトリ構成

前回：ZF#02 10分で試せる Zend Framework - カタコト日記

とりあえず、動かすことには成功した Zend Framework。

せっかくなので、前回入れてみたサンプルキットの中を見ながらお勉強。

MVC ってなーに？

Zend Framework にかぎらず、最近のフレームワークは MVC をベースにしています。

難しい説明は他サイトにゆずるとして、ここではそのイメージだけを理解。

コントローラ Controller

「あのデータがほしい」「これ表示しといてね」のように、Model と View に

指示を出して、全体の進行を管理するのが仕事。自分で細かい作業はやらない。

モデル Model

Controller の指示にもとづいて、データをとってきたり、計算をする実作業の要。

データ（DB、XML、RSS、ファイル、…）を管理（保存、読み込み、…）する仕事ですね。

ビュー View

Web アプリケーションの場合、HTML を担当。必要なデータは Controller が

すべて渡してくれるので、あとはそれをきれいに整形することに専念。

MVC はアプリの構造パターンの一つで、各部分の再利用、取り替えなどがカンタンに

なるだけでなく、実作業において分業もしやすくなるというメリットがあります。

ってところまでを理解して次へ。具体例を見ないとわかんないよね。(´∀｀*)

基本ディレクトリ構成

サンプルの中身はこんな具合。

Zend Framework はかなり自由度の高いフレームワークで、ディレクトリ構造も自分の

好きなように設定できます。（言い換えると、自分でいろいろ決めないと始められない…）

最初に決めるのは application ディレクトリの位置。公開されたディレクトリ（例：

/home/koto2/public_html）に置く必要はないので、別の場所（例：/home/koto2 直下）

に置いておきましょう。慣れないと変な感じだけど、セキュリティ上のメリットもあります。

次に application の中には何を配置するか。本家のマニュアル では次のようになってます。

要は、MVC に相当するファイルを置く場所を作りなさいってことですね。サンプルも

ほぼこの基本構成にそっていることがわかります。ちなみに、Zend Framework を

動かすのには、マニュアルに出てきてる4つのファイルが最低限必要です。

• .htaccess（URL の書き換えを担当）
• index.php（書き換えられたすべてのアクセスを受け取る）
• IndexController.php（View に表示しなさいと指示を出す）
• index.phtml（HTML を整形する）

隠しディレクトリ構成？

で、基本はこれで OK なんだけど、実は Zend Framework にはいろいろと拡張できるところが

あって、それらを使う（自作する）ならディレクトリを追加する必要が出てきます。たとえば

1. アクションヘルパー （アクションコントローラに共通の機能を追加できる）
2. プラグイン （コントローラの処理イベントに同期して実行できる）
3. ビューヘルパー （HTML を整形する際に使う共通の機能を追加できる）
4. ビューフィルタ （ビュースクリプトをレンダリングした後で使用するフィルタ）
5. Zend_Layout （HTML をテンプレート管理できる2ステップビューパターン）

など。最後のやつは、サンプルにもこっそり出てきてましたね。

別に隠されてるわけじゃないと思うんだけど、マニュアルにはどこに置けばいいのか

示されてないものもあって、結局自分で考えないといけなかったりする。(´・ω・｀)

まぁ、意味を考えれば自明ではあるんだけど。最初はとまどうよね。

というわけで、先ほどのディレクトリ構成を見直してみました。*1

これで Zend Framework + MVC に関わる部分はだいたいカバーできてるかな。

役割の違いだとか、これらをどうやって設定するかはまた次回！

参考にした記事 (MVC)

7.1. Zend_Controller クイックスタート
技術情報
Model View Controller - Wikipedia

参考にした記事 （ディレクトリ構成）

Getting Started with Zend Framework 1.12 – Rob Allen's DevNotes
Loading...
http://lab.youthhr.net/archives/71
ka10s world - ZendFramework　〜起動ファイル編

*1:plugins って controllers の下でいいのかなぁ？models の下とか、controllers と同階層も考えたんだけど…。

PHPコード最適化Tipsのウソと本当(解説)

PHP コード最適化 Best Practices 63+ - カタコト日記

前回は、元記事に一定の敬意を表して、項目とかはあえてそのままにしてたんですが、

自分としても気になる部分が多々あったので、少しだけ調べ直して優先度＆解説つけました。

独断と偏見ですが。ヽ(´ー｀)ノ 検証はしてません。ごめんなさいごめんなさい。

優先度A、B、C、不明、非推奨に分けてみました。どうぞつっこんでください。

長いよ、今回は。

優先度A. 頻度も高いし使えそう - 6つ

01. static にできるメソッドは static として宣言しよう。（4倍速い）

正しくは、static なメソッドには、OOP のルールに従ってちゃんと static 宣言をつけよう！
ってとこでしょうか。本来そうでないものを無理に static にしちゃえって話ではないはず。*1

× <?php public function staticMethod() {}   // 静的に動作するメソッド（インスタンス経由で呼び出される）

○ <?php public static function staticMethod() {} // 宣言された静的メソッド（直接、呼び出される）

似た原理のTips： クラス内で定数代わりに使ってる変数があるなら、const にしよう。
（コンパイル時に1度だけパースされ、実行時のオーバーヘッドがなくなります）

04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。
19. for 文の条件式には count($array) のような関数をいれない。（変数に格納）

ループのたびに計算することになって無駄だから。紹介されてた例：

× <?php for ($j = 0; $j < count($arr); $j++) {}

○ <?php for ($j = 0, $max = count($arr); $j < $max; $j++) {}

10. 可能であれば、正規表現より strncasecmp、strpbrk、stripos を使おう。
11. strtr（str_replace の4倍速い） ＞ str_replace ＞ preg_replace の順に速い。
50. 可能なら正規表現より、ctype_alnum、ctype_alpha、ctype_digit を使おう。

正規表現は便利だけど負荷がかかるってことですね。

紹介されてた例：

× <?php if (preg_match("!^foo_!i", "FoO_")) {}

○ <?php if (!strncasecmp("foo_", "FoO_", 4)) {}

へぇーと思った例：（注：stripos は str_replace よりかなり高速）

<?php
$src_str = file_get_contents("BIG_FILE"); 
$src = array('abc', 123, 'text'); 
$dst = array('cba', 321, 'txet'); 

// BIG_FILE 中に置換対象となる文字たち $src が入ってないかを strpos() で探す
foreach ($src as $k => $v) {
        // 入ってない場合（false）は、処理しない（unset() して置換対象からはずす）
        if (strpos($src_str, $src) === false) {
                unset($src[$k], $dst[$k]);                 
        }
}
if ($src) { $new_str = str_replace($src, $dst, $src_str); }

二度手間なのにこっちの方が速いらしい。（1回の置換操作に時間がかかるような場合でしょうけど）
ファイル全体に対してループでぐるぐる置換しまくってるような箇所があれば応用できそう。

39. もとから用意されてる 関数たち を活用しよう。
53. 一時的なファイルを作るときには tmpfile や tempnam を使おう。

関数だけじゃなくって、マニュアル もよく読もう。（ここに書かれてある Tips って、
実はマニュアルに書かれてることばっかだったり）あと、自分で何か作り始める前に
PEAR とか PECL とかに似たのがないかもチェック。例として挙ってた便利な関数たち：

• file_get_contents …ファイルの内容を全て文字列に読み込む
• file_put_contents …文字列をファイルに書き込む
• microtime …現在の Unix タイムスタンプをマイクロ秒まで返す
• gettimeofday …現在の時間を得る
• convert_uuencode …文字列を uuencode する
• convert_uudecode …uuencode された文字列をデコードする
• http_build_query …URL エンコードされたクエリ文字列を生成する
• substr_compare … 指定した位置から指定した長さの 2 つの文字列について、バイナリ対応で比較する
• array_walk_recursive …配列の全ての要素に、ユーザー関数を再帰的に適用する

ファイルの内容を読み込む例：

× <?php // 昔はこうやって書いてた
$data = '';   
$fp = fopen("some_file", "r"); 
while ($fp && !feof($fp)) { 
        $data .= fread($fp, 1024); 
}
fclose($fp); 

○ <?php $data = file_get_contents("some_file"); // 今はこの関数ひとつで（しかも速い）

18. エラーメッセージはハイコスト。
55. デバッグするときは error_reporting (E_ALL); にしておこう。
17. $row['id'] は $row[id] より7倍速い。
23. 未定義のローカル変数のインクリメントは定義されたものより9〜10倍遅い。
24. 未定義のグローバル変数についても同様。

エラーレベルが E_ALL か E_STRICT でもエラーが出ないようにしておけばこれらすべて回避可能。

ちなみに 17番。$row[id] ではまず、id が定数と解釈されて、それが登録されてるかが走査されます。
でも見つかんないので、やれやれと E_NOTICE を吐きつつ文字列に解釈し直してくれるようです。
下位互換性のための挙動。動作はするけど、無駄だらけってことですね。*2

31. キャッシュを利用しよう。通常、コンパイル回数 x 25〜100％ 分速くなる。
32. これもキャッシュについて。memcached とか使おうよ。
58. パスなどの設定パラメータは配列に serialize して入れ、キャッシュしておこう。

キャッシュの効果自体は説明不要。でもどうせなら、どこをどれくらいの頻度でどこに
キャッシュするかみたいな情報の方が有益？

優先度B. 機会があれば / 迷ったら使うかな的 - 5つ

03. echo '文','字'; （カンマ区切り）の方が、'文'.'字' （ドット連結）より速い。

あまりそそられないんですけど、使う機会があれば。

08. include や require でファイルはフルパスで指定しよう。
51. ファイル指定は basename / file_exists / open_basedir よりフルパス指定が速い。

最近は、フレームワークがオートロードしてくれたりするおかげで
パスを書くことがあまりなくなりました。Zend_Loader 最高！

09. スクリプト開始時間は time() でなく $_SERVER['REQUEST_TIME'] で取得。

類似のものとして、

• phpversion() → PHP_VERSION（定数）
• php_uname(‘s’) → PHP_OS（定数）
• php_sapi_name() → PHP_SAPI（定数）

などなど。$_SERVER とか、定義済み定数 があるなら関数を呼ばずにそちらを使おう。

20. メソッド内ではローカル変数をインクリメントするのが一番速い。
21. グローバル変数のインクリメントはローカル変数より2倍遅い。
22. オブジェクト変数（例：$this->v++）のインクリメントはローカルより3倍遅い。

「がっつり」インクリメントしたいときはローカル変数に入れてから。

28. ダブルクォート より シングルクォート の方が若干速い。

速度のためというよりは、クォートの使い分けは普段からきちんとした方がいいかなと。
意味も違うし可読性も変わってくる。ここ とか参考に書き方を統一してはいかが。

優先度C. 実はほとんど効果がないけどね - 1つ

02. echo の方が print より速い。

print は返り値をセットするかららしいんだけど、この差はほとんど無視できるみたい。*3
逆に、ob_start を使ってるときは print の方が速いって話もあるみたいですね。*4

蛇足： print よりも "速い" echo ですけど、データの出力自体がそもそもすごく遅い処理です。

echo を連発するような機会が仮にあるなら、ob_start とかでバッファリングしてまとめて

出力するのがいいみたいですね。フレームワークとか使ってるなら自動でそうなってると思う。

優先度不明. 効果がいまいちわかんないです。誰か説明 / 検証してください (ﾉД｀)ｼｸｼｸ - 3つ

05. 大きい配列のような変数は unset() してメモリを解放しよう。

正しそうっていうのはわかる。でも「大きい」ってどれくらい…？DB クエリの結果とか？
Web アプリだとメモリの解放とかあんまり意識しないんですけど、ダメな癖なんでしょうね。

07. require_once はハイコストなのです。
52. require_once より require を使おう。（opcode キャッシュがらみの理由で）

元ネタには require より3〜4倍遅いとありますが、別のベンチマーク では
真逆の結果が出てます。速度うんぬんよりやっぱり用途によって使い分けるべきでは？

16. 処理が終わったらデータベースの接続は切っておこう。

やらないと結構、違いが出るんでしょうか？
また接続したくなっちゃったら再接続コストの方が大きくなったりして。

非推奨？ 速度の代償が大きすぎるんじゃ… - 3つ

06. マジックメソッド（例： __get, __set, __autoload）は使用を避けよう。

速度を求めて機能とか効率を犠牲にしてる感じが…。根拠を探したけど見つからず詳細不明。
別のベンチマーク（__autoload vs. require_once）では、__autoload が速かったとかってのもあったし。
そうでなくても、これで便利になって生産性が上がるなら気にせず使っちゃえばいいと思う。

33. if (strlen($foo) < 5) を調べたいなら if (!isset($foo{5})) と書くと速い。

へぇーと一瞬思ったけど、1年後くらいに見たらたぶん意味不明なんだろうなぁ。
ソースから恒常的にロジックが読み取れるって経験的にすごく大事なことだと思います。
追記：でもって、マルチバイトだと期待どおり動作しないらしいです。

34. $i++ より ++$i の方が速い。（そういう opcode optimizer が走ってる場合）

「そっかぁ ヽ(*´∀｀)ノ」っていきなり $i++ を ++$i に置換したりしちゃダメですよ。
文脈によってはまったく 別物 なので。これも意味の汲み取りを妨げる微妙な Tips かなぁ。
++$i がそこで実装すべきロジックを反映したものか、速度を求めたおまじないなのかが曖昧になるし。

あとは独断で省略。（サーバ、DB、設計とか）それぞれかなり大きなトピックだと思うんだけど、
元記事にリストアップされてたのはかなり粗い寄せ集め的な印象を受けたので。
サーバのチューニングは特効薬になりうるし、DB まわり（設計とか SQL）は実際に
ボトルネックになってることも多いと思うから、まとめがあると役に立つと思うんだけど。
誰かやってくれないかなぁ、あっち系に強い方々。人まかせであれですが。( ´ー｀)y-~~

あと、前回のエントリーにトラックバックをいただいた
http://d.hatena.ne.jp/hanageman/20080523
http://d.hatena.ne.jp/gegegen/20080524/1211622711
上に挙げた細かいテクニックよりも、一つ上のレイヤーの話なども。おもしろかったです。

今回、参考にした記事（前回と重複）

PHP & Performance By: Ilia Alshanetsky (PDF)
PHP & Performance By: Ilia Alshanetsky (PDF、タイトル同じですが別物)
Optimizing PHP Through Habits - Joakim Nygård
http://phplens.com/lens/php-book/optimizing-debugging-php.php

ちなみに、大元のネタとしていろんなサイトで引用されまくりの Ilia Alshanetsky さんは

PHP 開発チームの中の人みたいです。おぼえとこっと。

*1:インスタンスメソッドと静的メソッドのお話。5/27 例の部分を訂正 コメント欄もぜひ見てくださいね

*2:PHP: 配列 - Manual

*3:http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40

*4:http://phplens.com/lens/php-book/optimizing-debugging-php.php

いっぱいブックマークされてたよ（嬉）

さっき気づいたら 先日のエントリー にたくさんブックマークを

いただいてるようで。うれしかったので記念にこれを見た瞬間の反応を描いてみた。

驚＋嬉

昨日まで 0 だったと思うんだけど。何があったのでしょう？

ZF#02 10分で試せる Zend Framework

前回のつづき：ZF#01 入門！何はともあれ Hello World - カタコト日記

手っ取り早く Zend Framework を試してみたい！って人のために、スターターキット

みたいなのないかなあと思って探してみたらありました。ありがたい。(´∀｀*)

• Getting Started with Zend Framework 1.12 – Rob Allen's DevNotes
• Zend Framework Tutorial, by Chris Shiflett

日付の新しい（そして Zend Framework 1.5 に対応してるらしい）前者を使ってみよう！

手順1. サンプルファイルたちをサーバに展開

まずは、上の URL にある「Zip file of tutorial (〜9KB)」って リンク から

ZIP ファイルを入手。サーバ上にアップして展開します。*1

フォルダは3つ。以下のような感じにしました。 ~/public_html が公開するディレクトリ。

/home/koto2/public_html/ （ここに public の中身を直に index.php、css、…）
/home/koto2/application/　（これは application フォルダをそのまま配置）
/home/koto2/library/Zend/ （前回 入手した Zend Framework の中身をごっそり移動 Acl、Acl.php、…）

3つのディレクトリを同じ階層にしてれば、パスを通す必要もなしという優れ（怠け）もの。

手順2. DB の準備

このサンプルは DB に MySQL を使ってるようなのでセットアップします。

適当な名前のデータベース（ここでは仮に zftest）を用意して、

そこで付属の SQL (application/dbschema.sql) を走らせます。

アプリ側は、ユーザー名とパスワードを application/config.ini で設定するだけ。

application/config.ini

[general]
db.adapter = PDO_MYSQL
db.params.host = localhost
db.params.username = ユーザー名
db.params.password = パスワード
db.params.dbname = zftest

手順3. ブラウザでアクセス！

あとは、http://あなたのテストサーバ/*2 にアクセスするだけ。

できました！全然、付属のマニュアルとか見なかったわけだけども、

なんかアルバム（曲名と歌手）を登録できるアプリケーションなんですねぇ、見た感じ。

PHP と MySQL が使える環境があれば、ほんとうにものの10分程度。

よくできてるサンプルだなぁ。

ソース自体はとっても短いんですが、いろいろと Zend Framework の基礎が

つまってるみたいです。解説はまた次回ということで！

→ZF#03 基本＋隠しディレクトリ構成 - カタコト日記

*1:ローカルで展開してからアップする場合は、public の中にある .htaccess も忘れずにアップ。
（エクスプローラ / Finder の設定によっては見えないので）

*2:ドキュメントルートの設定をいじってないなら /~koto2/ 付きで

PHP コード最適化 Best Practices 63+

みたいなタイトルの記事を Digg 経由で発見。チートシート代わりにと思い超訳。*1

A Software Architect

PHP 最適化 ベストプラクティス！

• 01. static にできるメソッドは static として宣言しよう。（4倍速い）
• 02. echo の方が print より速い。
• 03. echo '文','字'; （カンマ区切り）の方が、'文'.'字' （ドット連結）より速い。
• 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。
• 05. 大きい配列のような変数は unset() してメモリを解放しよう。
• 06. マジックメソッド（例： __get, __set, __autoload）は使用を避けよう。
• 07. require_once はハイコストなのです。
• 08. include や require でファイルはフルパスで指定しよう。
• 09. スクリプト開始時間は time() でなく $_SERVER['REQUEST_TIME'] で取得。
• 10. 可能であれば、正規表現より strncasecmp、strpbrk、stripos を使おう。

• 11. strtr（str_replace の4倍速い） ＞ str_replace ＞ preg_replace の順に速い。
• 12. 引数に配列、文字列両方を受け入れるような関数は避け、個別に関数化しよう。
• 13. if をたくさん使ってるなら switch を活用しよう。（訳注：ってことでいい？）
• 14. @によるエラー制御はすんごく遅い。
• 15. Apache の mod_deflate（Apache2系） を ON にしておこう。（No.42 参照）
• 16. 処理が終わったらデータベースの接続は切っておこう。
• 17. $row['id'] は $row[id] より7倍速い。
• 18. エラーメッセージはハイコスト。
• 19. for 文の条件式には count($array) のような関数をいれない。（変数に格納）
• 20. メソッド内ではローカル変数をインクリメントするのが一番速い。

• 21. グローバル変数のインクリメントはローカル変数より2倍遅い。
• 22. オブジェクト変数（例：$this->v++）のインクリメントはローカルより3倍遅い。
• 23. 未定義のローカル変数のインクリメントは定義されたものより9〜10倍遅い。
• 24. 未定義のグローバル変数についても同様。
• 25. メソッドの起動コストはクラス内のメソッド数とは無関係。
• 26. 派生クラス内のメソッドは、基底クラスで定義されたメソッドよりも速い。
• 27. 引数1つの空関数を呼び出すのにも、ローカル変数 $local++ 7〜8回分のコスト。
• 28. ダブルクォート より シングルクォート の方が若干速い。
• 29. 03 と重複か。（注：これは複数の引数を受け取る echo でのみ有効）
• 30. PHP スクリプトは静的な HTML ページよりも2〜10倍の時間がかかる。

• 31. キャッシュを利用しよう。通常、コンパイル回数 x 25〜100％ 分速くなる。
• 32. これもキャッシュについて。memcached とか使おうよ。
• 33. if (strlen($foo) < 5) を調べたいなら if (!isset($foo{5})) と書くと速い。
• 34. $i++ より ++$i の方が速い。（そういう opcode optimizer が走ってる場合）
• 35. 全部が全部 OOP でなくても良い。（コストやメモリの浪費になってるかも）
• 36. すべてのデータをクラスにしようとしないこと。配列も十分便利です。
• 37. メソッドを分割しすぎない。（どれを再利用するのかよく考えよう）
• 38. メソッドを分割したくなったら後でいくらでもできる。
• 39. もとから用意されてる 関数たち を活用しよう。
• 40. 非常に時間のかかる関数 → C言語による拡張モジュール化も検討しよう。

• 41. コードをプロファイリングしてボトルネックを見つけよう。Xdebug とか。
• 42. Apache の mod_gzip（Apache 1系）は、転送量を最大80％減。
• 43. http://phplens.com/lens/php-book/optimizing-debugging-php.php を見てね。
• 44. 28 と重複か。
• 45. 13 と重複か。
• 46. 19 と重複か。
• 47. ループ処理には foreach を使おう。
• 48. 複雑なクラスを作ってるなぁと思ったら → Singleton モデルを検討しよう。*2
• 49. DB に入れる値なら GET より POST を使おう。（パフォーマンスが上がる）
• 50. 可能なら正規表現より、ctype_alnum、ctype_alpha、ctype_digit を使おう。

• 51. ファイル指定は basename / file_exists / open_basedir よりフルパス指定が速い。
• 52. require_once より require を使おう。（opcode キャッシュがらみの理由で）
• 53. 一時的なファイルを作るときには tmpfile や tempnam を使おう。
• 54. 外部サービスに XMLHTTP で接続するときにはエラー回避のため Proxy を使おう。
• 55. デバッグするときは error_reporting (E_ALL); にしておこう。
• 56. Apache の allowoverride を "none" にしておくとパフォーマンスが向上。
• 57. 静的なコンテンツには thttpd のような高速なファイルサーバを使おう。
• 58. パスなどの設定パラメータは配列に serialize して入れ、キャッシュしておこう。
• 59. アクセスの多いページには PHP の 出力バッファリング を使おう。
• 60. DB 固有の prepare メソッドではなく PDO::prepare を使おう。

• 61. SELECT * （ワイルドカード）を使うのはやめよう。
• 62. PHP より賢い DB ロジック（queries, joins, views, procedures）を活用しよう。
• 63. SQL の省略表記を活用しよう。
  （例：INSERT INTO MYTABLE (FIELD1,FIELD2) VALUES (("x","y"),("p","q"));）

以上。

っていうか、ありすぎ (；´∀｀)

前半は http://labs.unoh.net/2007/05/phptips.html と同じでしたね。

こういう Tips は検証環境によっていろいろと差が出てくるみたいですけど、

どっちにしようか迷ったときなんかには参考にしてもいいんじゃないかな。*3

元ネタの元ネタらしきもの（引用の引用とかで正確には不明ですが…）

• No.01〜43 http://reinholdweber.com/?p=3 (2007/10/14)
• No.44〜63 ALL ABOUT COFFEE, by William H. Ukers
• http://phplens.com/lens/php-book/optimizing-debugging-php.php (2005/02/28)
• PHP & Performance By: Ilia Alshanetsky (PDF)
• whenpenguinsattack.com -  (2006/07/21)
• Optimizing PHP Through Habits - Joakim Nygård (2007/03/31)

これを書いてる途中に発見した関連記事

• http://labs.unoh.net/2007/05/phptips.html（既出、2007/05/13）
• http://labs.unoh.net/2007/01/array_key_check.html (2007/01/16)
• http://labs.unoh.net/2006/10/php_4.html (2006/10/27)
• PHPプログラミングのベストプラクティス:phpspot開発日誌 (2007/08/20)
• 43. 基礎構文処理速度のあれこれ | 日経 xTECH（クロステック） (2007/07/04)
• Forget It Not: PHPの文字列連結のスピード (2006/08/26)
• http://www.mt312.com/php/41/ (2007/05/10)

なんだこれは、もっとくわしく！

って方へ。簡単な解説（例とか）つけてみました。よろしければどうぞ。
→ PHPコード最適化Tipsのウソと本当(解説) - カタコト日記

*1:文中のリンクは、元記事にはないんですが、参考のため勝手につけちゃいました。

*2:原文：Do consider using the Singleton Method when creating complex PHP classes.
どういう意味なのかちょっとよくわかりません…。コメント欄で試行錯誤してます。

*3:訳を思いっきりはしょってる ＆ 何より根拠を知らずにがんがん使うのは危険だと思うので、英語ですけど元ネタもあわせてどうぞ。

ZF#01 入門！何はともあれ Hello World

GW に Zend Framework で遊ぶぞーと書いてからしばらくたってしまった…。

それでもちょっとずつ触ってみてますよ、Zend Framework。

せっかくなので、いろいろ試しながら学んでる様子をさらしていきたいと思います！

今回（〜次回）はお決まりの Hello World さんにご挨拶するところまで。

準備 〜 料理でいうとお鍋とかまな板をそろえるところから

ローカルサーバを用意

PHP5 と今回使う予定の MySQL がローカルのサーバ上で動くようにごにょごにょと設定。

本題から大きくずれるので割愛です。いずれ時間があれば。(´∀｀*) と言いつつ、

実はずいぶん前に用意した Parallels Desktop（Mac 用ね）上の Fedora 6 にそのまま

がんばってもらう予定なのだ。古いね、巷では Fedora 9 が出たと言うのに…。

Fedora 9正式リリース − ＠IT

ちなみに PHP 5.1.4 は以降、できれば 5.2.3 以降を使用することが推奨されてるみたい。

Zend Framework: Documentation（付録 A. システム要件）

ブツを入手 ( ・∀・)っ旦

http://framework.zend.com/download

本家のサイトより Latest Release とあるやつの tar.gz（Linux 上で展開するので）を

ダウンロード。現時点での最新版は 1.5.1 だそうな。

ファイルをそのままサーバーの自分のディレクトリに FTP か何かで放り込んで展開！

$tar zxvf ZendFramework-1.5.1.tar.gz

/home/koto2/ZendFramework-1.5.1 ってなディレクトリができました。

しめしめ、準備完了？

Hello World はまだぁ？

じゃ、とりあえず何か表示させたいところなんですが、いきなり .php ファイルをペタっと

作ってもダメなのがフレームワークの最初のカベ。MVC モデルにのっとった処理の流れを

理解してファイルを配置していく必要があります。

んー。(´・ω・｀)

…。

めんどくさい…。とにかく動かしたい、理解とかは後でいーじゃん！

初心者用のパッケージみたいなのはないのかぁー (ノ｀Д´)ノ彡┻━┻

と思ってたらありましたわ。(ﾉ´∀｀*)

つづく。
→ ZF#02 10分で試せる Zend Framework - カタコト日記

ヒロ・ヤマガタ氏の美術展に行ってきた

GW もあと一日だねぇ、しみじみ…。

週末に、ヒロ・ヤマガタさんの個展に行ってきました！版画の一種である

シルクスクリーンや現代アートの分野で世界的に有名なアーティストなんだって。

「知らない」って言ったら友達びびってたけど (´∀｀*)

ヒロヤマガタ/HIRO YAMAGATA（本名：山形博導、1948年5月30日 - ）は、
画家、美術家。滋賀県米原市出身。アメリカ在住。

日本ではカラフルなシルクスクリーンアーティストというイメージが今なお強いが、
世界でのヒロ・ヤマガタはむしろレーザーやホログラムを使った現代美術家として
知られており、先端的なイリュージョニストとして現在も精力的に活動している。

ヒロ・ヤマガタ - Wikipedia

個展はそのシルクスクリーンがメイン。

現実の世界の中に小人さん（妖精だそうです）がいる絵がたくさんあって、

なんとも幻想的な＋パワーのある印象を受けました。例えば、こんな感じ。

聞くところによると、オリンピックのような世界的に大きなイベントの

ポスターなども手がけてるそうで。いい勉強させていただきました。

で、もう一つ驚いたこと。

現在、このヒロ・ヤマガタさん、あのバーミヤンの仏像をレーザー光線で

描き出そうってプロジェクトをやってるそうです。

このプロジェクトは、今日の最新技術の一つであるレ−ザー光線でアーティストによる
仏像のイメージ図をバーミヤンの仏像跡に映し出すものです。
このことによって、バーミヤンの大仏像を作り出した人類の偉大な創造の精神が呼び戻され、
同地の古の文化と新しい文化のコラボレーションが実現し、アフガニスタンの
新しい文明の文化的象徴を作り出します。

http://www.bamiyanlaser.org/exhi/index.html

こんな感じでバーミヤン遺跡が復元される予定なんだって。

すごいなぁ。

*1

スケールが大きいし、何より夢があるよね。

2012年の完成が待ち遠しいです！

*1:画像は http://www.bamiyanlaser.org/exhi/index.html より転載