忘れ物しないよう工夫する

開発時にはできるだけエラー・警告のたぐいを表示させるように設定した上で進めていき、一切のエラー・警告を出さないコーディングを心掛ける。
そして運用時にはエラー・警告のたぐいを表示させない設定にする。


でもそのつもりが、よく最後に運用時設定にしておくのを忘れることしばしば


で、考えたですよ。
設定忘れない方法がないものかと・・・

そこで思いついたのが、エラー・警告の表示フラグが立っていれば、開発モードと判断して常に「error_reporting」のようなそれと分かる文字を表示させるというもの。

つまりこのようになる。

<?php

if (1) { // 設定切り替え 0 or 1
    ini_set("display_errors" ,  1);
    ini_set("error_reporting", -1);
} else {
    ini_set("display_errors" , 0);
    ini_set("error_reporting", 0);
}

if (error_reporting() === 0) { //フラグ立ってなければ
    define("DEBUG", 0); // 運用モード
} else {
    define("DEBUG", 1); // 開発モード
}

// 開発モードの間、表示させ続ける
if (DEBUG) {
    echo "error_reporting";
}


ザクっとこんな感じになる。
これなら忘れまい。

設定切り替えも一箇所だけなので楽なのさ

このように自分が開発しやすくなる為ならなんだってしていい。
禁じ手なんてない、自由なのさ


error_reportingはいろいろな場所で設定されている可能性がある。

・php.iniのようなPHP設定ファイル
・Apache設定ファイル.htaccess
・PHPソースコード

これらのうちどこで設定されていても対応できて知らせてくれる


error_reportingの設定で以前はよく「E_ALL」だったり「E_ALL | E_STRICT」だったりを書いたりしてたけど、全表示させるなら「-1」とするのがスマートなやり方になる。

将来新しい定数が加わっても、こうしておけばエラー、警告、古新聞、古雑誌、ボロぎれ、バッテリーなど、、出せるものはなんでも出してくれるのでお奨め。



禁じ手なんてない、自由に使っていいと言い放ったついでに他の手法も考えてみる。

define("DEBUG", 1);


のように開発モードのフラグを単に「1」に設定していたのでは面白みがないしもったいない。

そこでこう設定してみる。

define("DEBUG", microtime());


そうすれば処理の最後に再びmicrotime()値を取得して実行にかかった時間を得ることができる。
// 開発モード設定
define("DEBUG", microtime());

// 開発時だけ実行時間を表示させる
if (DEBUG) {

   list($start_micro, $start_sec) = explode(" ", DEBUG);
   list($end_micro, $end_sec) = explode(" ", microtime());

   echo "実行にかかった時間：";
   echo (($end_sec - $start_sec) + ($end_micro - $start_micro));
   echo "sec";
}



これで実行にどれくらいかかっているかを常に確認できる。

別の使い方を考えてみる。

開発時にデバッグ情報を見ることができる人を制限する。

// 開発モード設定
define("DEBUG", "192.168.0.1,192.168.0.2");

if (in_array($_SERVER['REMOTE_ADDR'], explode(',', DEBUG))) {

    // 開発者たちの回線だけに見せる情報をここに書く
}


表向きは通常通り運用しながら、裏で機能追加などの開発を進めていくのに使えそうだ。

糖分補給

朝方に糖分補給をすれば脳の思考力にプラスになるようなことを聞いた事がある。


普段からほっとくと糖分はあまり取らないので不足してるはず。


なので朝は意識して糖分補給をしないとね。


ってことで、最近お気に入りの糖分は「冷凍パイン」と「生ラムネ」


そろそろホンキ出す-冷凍パイン


冷凍というだけあって、ひんやり感あるね。

噛み砕きたいけど、噛み砕くとすぐに終わってしまう。。。

そんなジレンマがある。



そろそろホンキ出す-生ラムネ


「生」なんとかって流行ったけど、どんなもんかと買ってみたら

きらいじゃないッスこの食感。表現するのが難しい食感。

ラムネ感もあるし。　ん？　ラムネ感って何だ？？



画質よくない上に光量不足？

ちょいと明るくなるよう補正してコントラストも変えてみた。


もっといいデジカメ欲しいけど、どれがいいかわからん。

そのうち購入しようと今思ったのであった。



Zend Frameworkを使いまくる

■前置き

PHP使いたる者、フレームワークをどれか一つは使えた方がいい。
幸いPHP用のフレームワークとして主要なものだけでもいつくかある。

私にはシンプルな構造である種の思想を持った「Zend Framework」が向いてそうだったので、これをとことん使いこなして魔法使いになってみせるのさ。 キラキラ

主要なPHPフレームワークのトレンドの推移を見てみるとこんな状況になってるのねん。

見てのとおり、Zend Frameworkの状況は芳しくない。
私はZend FrameworkこそがPHPフレームワークの大本命だと勝手に思っていたのだが、あれれ？　ってな感じ・・
日本ではなぜか伸びない、というか世界全体で見てもチェコやロシアぐらいでしか席巻してない。

まぁそんなことはお構いなしに、とにかくZFを使いまくる。
コンセプトとしては、できるだけシンプルに自分自身に言い聞かせるように解説しながら、できるだけ環境依存しないように、入門の初級段階からサンプルを交えていけばそれなりにまとまるんじゃないかと

で、まずは導入から



■導入

公式ダウンロードページのLatest Release of ZFへ行き、「Zend Framework 1.11.9 Full」のZIP形式（ZendFramework-1.11.9.zip 25.7MB）を落としてくる。

落とし終わったら、場所はどこでもいいのでとにかくZIPを展開する。

展開したら、
「ZendFramework-1.11.9」というディレクトリが出来て、この中に「library」があり、更にその中に「Zend」がある。
この「Zend」こそがZFのクラスファイルの集合体なのでこれを適切な場所に移動させて使う。

Webで使う場合が多いと思うのでドキュメントルート外に配置する。
CentOSなら/var/www/直下にZendを移動
Windowsでxampp使ってるならC:\xampp\直下にZendを移動させる。
だいたいこんな感じだろう。。

はいこれでインストール完了！

環境設定は不要！！



■ZFを使ってみる

細々とした「コーディング規約」があるが、取っ付きにくくなるので始めのうちは無視してよい。
それよりもなによりも、身に着けるまでは極力シンプルに整理しながら進めていくことを心掛けた方がいいだろう。

まずは世界にあいさつしたいところだが、落としてきたZFのバージョン表示をしてみる。

Webで表示させるならWebサーバ起動を確認することと、ドキュメントルート内に表示スクリプトを作成することになります。
コマンドライン実行ならどこか適当な場所に表示スクリプトを作成します。

<?php
/**
 * ZFバージョン表示スクリプト
 */

// パスを通す
set_include_path('C:\xampp' . PATH_SEPARATOR . get_include_path());

// クラスを呼ぶ
require_once 'Zend/Version.php';

// 定数値を表示
echo Zend_Version::VERSION;


Zend_Versionクラスを呼んで、そのオブジェクト定数値を表示させてるだけです。


※いくつかポイントをまとめます。

【ポイント1】- set_include_path()って何なのさ
クラスを'Zend/～.php'の形式で呼べるようにする為に最初にパスを通しています。

【ポイント2】- なぜ'Zend/～.php'形式で呼びたいのさ
Zend/以下にクラスファイル群が整理して置かれているので、クラス内部ではこの呼び方でハードコーディングされています。
なので'Zend/～.php'形式で呼べないと都合が悪くなるというか動かないのです。

【ポイント3】- Zend/以下にファイルが整理して置かれてる?
クラス名がZend_Foo_Barなら、必ずZend/Foo/Bar.phpというファイルにクラス定義が書かれています。

【ポイント4】- なぜ重いrequire_onceを使って呼び出してるの?
include系（includeおよびinclude_once）は、呼び出したファイルにエラーがあっても処理は続行されます。
エラーで処理が続行されたら誤動作が起こる可能性が高いので手堅く動作させたい場合にはやはりrequire系でしょう。
で、呼び出した別々のクラス内で互いに同じクラスを呼んでたりしたら二重定義エラーになっちまいます。
なのでワンスですワン！

【ポイント5】- PHP設定ファイルphp.iniでinclude_path設定できるけど?
敢えて導入の部分でPHP設定ファイルにinclude_pathを設定しなかったです。
スクリプトに直指定できた方が小回りが効くし、別環境への移植性が高くなる思います。（個人的に）



■余談

【その1】
Zend_Versionクラスの場合は内部にrequire_once 'Zend/～.php'呼び出し部分がない（唯一の？）クラスなので、実はフルパスで呼べるレアなクラスです。

【その2】
Windowsでのパス指定にも '/' が使えます。
'/path/to/foo.php' が使えるし、
'/path\to/foo\bar.php' のような混在も使えます。

【その3】
Windows⇔Linux間の移植性を高める
Linux環境で/var/www/Zend以下にクラスが置かれてる場合は、
WindowsでもC:\var\www\Zend以下に置けばパス指定を共通化できて楽?

両者とも以下の書き方で統一できる。
set_include_path('/var/www');

別の方法もある。実行スクリプトが置かれたディレクトリから見たZendへの相対パス指定が使える。
set_include_path(dirname(__FILE__) . '/../path/to/Zend');

ちょっとしたことだが、パス内に'/../'のような部分があるとアクセスが遅くなってしまうので書くなら以下のようになる。
set_include_path(realpath(dirname(__FILE__) . '/../path/to/Zend'));

【その4】
require_once呼び出しは重いので、軽くする方法があります。
requireを使えば３～４倍程速く呼べるので__autoload()関数を定義しておく。

function __autoload($class) {
    require $class . '.php';
}


これでクラス呼び出しは書かずに、すべて__autoload()関数に任せることができます。
__autoload()が呼ばれるのは、未定義のクラスをインスタンス化しようとしたタイミングなので、まだ一度も呼ばれてないクラスということになり、requireで事足りる。

ソースコードを見てどこから呼び出してるのか伝わってこないので以前にこの方法を否定しましたが、意味を解った上で使う分にはまぁしょうがないかと・・


どうでしょう。。
ZFは導入から実際に使うまで割とあっちこっち設定する必要無くシンプルだと思います。

こんな感じで布教活動をしていこうかなと