HTTP_RequestをHTTP_Request2に書き換える

PHP 5.4以降でE_STRICTによるメッセージが出るようになったこととHTTP_Requestがデサポになっていることから、ようやくHTTP_RequestをHTTP_Request2に書き換えてみることにした。
参考にしたサイトは[php][pear]HTTP_Request2のサンプル#1 : うえちょこ@ぼろぐ
互換性があるライブラリと思いきや、かなり非互換。
コンストラクタから違う。上記参考サイトとあわせて下記参考にしてみてください。
HTTP_Request
HTTP_Request HTTP_Request( [string $url = ”], [array $params = array()])
HTTP_Request2
HTTP_Request2 __construct( [string|Net_Url2 $url = null], [string $method = self::METHOD_GET], [array $config = array()])

WSHでハッシュ値計算にSHA-1アルゴリズムを利用する

WSHはもう時代遅れなのかもしれない。
ただ、Windows 2000以降のOSにてデフォルトで動作するWSHは魅力的だ。
ところでハッシュ値を算出する方法がなかなか見つからなかったが、MD5とSHA-1アルゴリズムを利用しているソースが紹介されていたので、実際に使用してみるとすぐに利用できた。
papakingの日記
SHA-1もMD5もハッシュ値が衝突する脆弱性が指摘されており、中間者攻撃に利用されるリスクがある。ただ、SHA-256などは.NET Frameworkの特定バージョン以上をインストールしないと利用できないという問題がある。

CentOS 5.5にPHP 5.2をインストールする

CentOS 5.5のリポジトリでは、PHP 5.1.6までしかインストールできない。
PHPならびに対応するmemcachedのライブラリのインストール方法について「CentOS5.2にPHP5.2.6とmemcachedをインストールする」に記載があるので、こちらを利用するとよい。
ちなみに追加したリポジトリは次の通り。/etc/yum.repos.d/CentOS-Testing.repo として保存するとよい。
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
includepkgs=php*
priority=1

俺のコードのどこが悪い?

俺のコードのどこが悪い?―コードレビューを攻略する40のルール
コードレビューに関する分野の書籍は珍しく先月発売された新書で、書店で平積みされていたので思わず手にとって買ってしまった。実際に読んでみると、どうすればコーディングミスを減らしたり、保守性を上げられるかについて、技術的なアプローチだけでなく仕掛けづくりについても書かれており、新人が読むための教育書という位置づけだけでなく、レビュアーも参照すべき一冊である。

CacheをMemcachedにするとエラーとなる

Memcachedをインストールしたうえで、cakePHPのcore.php設定ファイルにあるcache設定をengine => ‘File’ から engine=>’Memcache’に変更すると以下のエラーメッセージが表示されてしまう。
Warning (512): Cache not configured properly. Please check Cache::config(); in APP/config/core.php
デバッグして原因を調査したところ、php.ini に
extension=memcache.so
の設定がないためにMemcacheクラスが呼べなかったためだった。
エラーメッセージが適切?ではないために小一時間はまってしまった。
なお、memcache.soはphp-pecl-memcacheパッケージをインストールする必要がある。

pageTitleが利用できない

新しいアプリケーション「oh-toilet.com」をcakePHP+Ktai Libraryで作成していたら、なぜかタイトルが編集できない。
いつも通り
$this->pageTitle = ‘タイトル’;
にしているのに。。。。
原因を探してみると、Ver.1.3から廃止になっているじゃないですか。。。

View::$pageTitleは削除されました。代わりに$this->set(‘title_for_layout’, $var);を使用してください。

セキュリティ要件でない限りは、マイナバージョンアップ時に下位互換性をなくすのはやめてほしいと思うのは僕だけでしょうか?
下位互換性がなくなるということは、cakePHPのバージョンアップをするときには、前ページの動作確認をしなければならないことを意味しています。(もちろんドキュメントに書いてあることがすべてならばキーワードだけで探して対象を絞り込むだけでよいのかもしれませんが。。。)

サーバーサイドJavaを始めるために

仕事の都合上Java言語をようやく勉強することになった。
大学時代でswingなどを少しやったもののほぼサーバーサイドJavaは知識ゼロの状態である。
インターネットで調べてみるもののつかみが分からない場合には書籍に当たるのが時間を無駄にせずに済む。
いろんな書籍を探してみたが、手っ取り早く勉強するためには、Eclipse WTPではじめるサーバーサイドJava入門―Eclipse 3.3/WTP 2.0対応が分かりやすいように感じていて、今学習を進めている。
Eclipseを日本語化したPleiades 3.5を使っていると書籍のハードコピーと異なる部分があって戸惑うことがあるが、流れをつかんでしまえば体系的に学習できると思う。

Content-Typeヘッダフィールドは必須か?

Webプログラミングをする場合には、必ずと言っていいほど意識しなければならないメディアタイプや文字コードではあるが、Content-Typeヘッダフィールドを制御しない場合には、MIMEタイプをWebサーバーで判断し、text/plainやtext/htmlの場合においてはデフォルト文字コード設定(ApacheでいうところのAddDefaultCharsetディレクティブ)によって出力がされる。
ただ、今日見たWebアプリケーションプログラムは、LocationヘッダフィールドによりリダイレクトしているページにおいてContent-Typeヘッダフィールドの出力なしにボディーにデータが書き込みされていたので、RFCに違反しているのかどうか調べてみた。
対応するRFCは2068(ハイパテキスト転送プロトコル HTTP/1.1)になる。
該当する項目は、7.2.1 型にある

実体本体を含むどんなHTTP/1.1メッセージも,その実体のメディア型を定義するContent-Typeヘッダフィールドを含むことが望ましい。

であり、強制されるものではないようである。したがって、受け手(ブラウザ)はContent-Typeヘッダフィールドがない場合でもメディア型を推定しようとしてよいのである。しかし、こちらも推定しなければならないわけではないので、結果的には正しく通信できない恐れがあるということを示しているようだ。
やはりContent-Typeヘッダフィールドは通信トラブルを避けるためにも「ほぼ」必須のヘッダフィールドであるといえる。

携帯サイトをキャッシュする

財テク.jpのモバイルサイトは、CakePHPにKtai Libraryを使って動かしているのだが、Viewキャッシュをしてしまうと、キャリアごとの絵文字に対応できないことと、PCサイトがUTF-8だった場合に、headerでのcharset指定がUTF-8となってしまうため、キャッシュされたページは文字化けしてしまう可能性がある。
前者については絵文字を利用しない方法で対応可能だが、後者についてはキャッシュ済みの場合には、controllerすら通らず、エンコード指定を切り換える対応方法が分からなかったため、しばらくキャッシュさせないようにしていたが、データが多くなってくるとレスポンスが悪くなってきているため、キャッシュの方法を考えてみた。
Viewキャッシュが無理な場合には、modelキャッシュということで、CakePHP1.2 Behaviorでモデルのメソッドキャッシュを行うを使って、modelでキャッシュさせることにした。
結果的には、携帯サイトはmodelキャッシュ、PCサイトはmodelキャッシュ+ビューキャッシュとなりキャッシュによる効果は高くなったように思う。

logrotate

ログを出力するプログラムはたくさんあるが、1ファイルに書き出し続けると不要な過去のログを保持し続けて容量不足になってしまったりすることがある。
logrotateを使えば、出力側のプログラムを変更することなく、きめられたタイミングで現在のファイルをリネームしたうえで、新しいログファイルを作成してくれる。
Fedora Coreであれば、
/etc/logrotate.d/ の下にファイルを作成して、
/var/www/XXX/logs/*log {
daily
missingok
}
とすれば、cakePHPで出力されるdebug_logとerror_logを1日単位でローテートしてくれる。
create (パーミッション) (ユーザー名) (グループ名)のオプションを付ければ、空のファイルを作成してくれるし、apacheプロセスのようにログ出力プログラムがログファイルが無くなってしまうとそれ以降ログを書き出さないような仕組みなのであれば、postrotateオプションをつかってプロセスを再起動させることもできる。
詳しいオプションは@ITが参考になる。