2006-10

TortoiseSVNを1.4.0にアップグレードしたらSubclipseやsvnコマンドでエラーが出るようになりました。

    Unsupported working copy format
svn: This client is too old to work with working copy 'xxxxxxxxxxxxxxx'; please get a newer Subversion client

subversion1.4.0のリリースノートを見ると作業コピー・リボジトリのフォーマットが変わったので、1.4クライアントからコミットしたファイルは以前のバージョンでは読めないようです。

そこでSubcliseとSubversionを1.4対応にアップグレードしました。

Subclipse

Subclipseでは1.1.7から1.4.0フォーマットに対応しました。しかし1.1.7はEclipse3.2が必要なのでまずはEclipseをアップグレードします。（ウチの環境は3.1）以前はAll-In-One Eclipseをインストールしていました。はじめから色々入っていて便利なのですが、結局Subversionクライアントしか使っていないので今度はSDKからインストールします。

まずはEclipse3.2＋LanguagePackをEclipse downloads homeからダウンロード。あとはzipファイルを解凍してEclipseは完了です。Eclipseを起動後、[ソフトウェア更新][検索およびインストール][インストールする新規フィーチャーを検索]で更新アクセス先サイトに[http://subclipse.tigris.org/update_1.2.x]を設定します。そのまま進めばSubclipse1.1.7がインストールされます。

Subversion – CentOS

subversion1.1.4がRPMで入っていました。[rpm -Uvh]で関連ライブラリと共に1.4.0にアップグレードして完了です。このサーバにリポジトリがあるのですが、1.4.0アップグレード後も特に問題なく動作しています。

 $ sudo rpm -Uvh apr-0.9.12-1.i386.rpm 
 $ sudo rpm -Uvh apr-util-0.9.12-1.i386.rpm 
 $ sudo rpm -Uvh subversion-1.4.0-1.i386.rpm 

Subversion – FreeBSD

subversionをportsで入れていたので、portupgradeでアップグレード完了です。

# portupgrade -r subversion-1.3.2

SQLite3.3.8で全文検索機能が追加されていますね。

Version 3.3.8 adds support for full-text search using the FTS1 module. There are also minor bug fixes. Upgrade only if you want to try out the new full-text search capabilities or if you are having problems with 3.3.7.

SQLite home page (2006-10-11)

ただ今回のリリースで全文検索に使われているFTS1モジュールは実験的なもの（permanent beta）のようで、本格的な実装はFTS2モジュールになるようです。デーモン要らずのDBだけに手軽に全文検索が使えるのは楽しみですね。

JavaやC/C++など一般的な言語でのオーバーロードとPHPでいうオーバーロードは違います。

一般的なオーバーロードの定義は下のとおりです。

プログラミングにおいて、戻り値や引数の数やデータ型(シグネチャ)が異なる同名の関数やメソッドを多重定義すること。

オーバーロードとは 【overload】　─　意味・解説 ： IT用語辞典 e-Words (2006-10-06)

Javaで書くとこんな感じです。

class Hoge {
  public void foo() {
  }

  public void foo(String bar) {
  }

  public void foo(int bar) {
  }

  public void foo(int bar, boolean flag) {
  }
}

同じfooメソッドを呼んでも引数によって実際に呼ばれるメソッドが変わります。

これをPHPで書くとこんな感じです。

< ?php
class Hoge {
  // 引数が一個だけなら
  function foo($bar) {
  }

  // 引数の数が変化するなら
  function foo() {
    $args = func_get_args();
  }
}
?>

厳密にはオーバーロードでは無いでしょうけど同じように動作するのでこれで良いと思っていました。ですのである日、PHPでオーバーロードができるようになった、と聞いてもピンッと来ませんでした。

PHPでいうオーバーロードは以下のような感じです。

この拡張モジュールの用途は、オブジェクトのプロパティへのアクセスと メソッドのコールのオーバーロードを可能にすることです。

オブジェクトプロパティとメソッドコールのオーバーロード (2006-10-06)

class Hoge {
  // PHP4
  function __call($method, $params, &$return) {
  }

  // PHP5
  function __call($method, $params) {
  }
}
// PHP4
overload('Hoge');
?>

この場合Hogeクラスに定義されていないメソッドを呼ぶと__callが呼ばれます。

つまりPHPでいうオーバーロードは「定義された変数、メソッドが無い場合に呼ばれるメソッド」と言った意味合いになってます。

他のLL言語にも「PHPのオーバーロード」のような機能はある（Perl:AUTOLOAD/Ruby:method_missing/Python:__call__?）のですが、「オーバーロード」という表現ではありません。（「オーバーロード」はC/C++と同じ演算子オーバーロードで使われています）

なぜPHPはこの機能に「オーバーロード」と名付けたのでしょうか。。。

 

はじめてC++でオーバーロードを見た時に「おースマートだ」と感激しました。「オーバーロード」という響きも好きですし、この言葉にはちょっと思い入れがあったので気になっていました。まあ他言語から移る方はお気をつけて、という事で。
# 昔オーバーロードとオーバーライドがごちゃごちゃになってたのはナイショです。:-P

Google Code Searchがリリースされました。

Googleは米国時間10月5日、新サービス「Google Code Search」を発表した。プログラマーはこのサービスを利用して膨大な数のソースコードを検索できるという。

グーグル、コード検索の新サービス「Google Code Search」を発表 – CNET Japan (2006-10-05)

関数をマニュアルで調べるのも重要なのですが、実際の使用例を見るのもとても参考になるので、こういうサービスはとても有り難いですね。まあ関数で脆弱性が発見された場合は速攻探されてしまいますが。。。

キーワードには正規表現も使えますし、（プログラム）言語やパッケージ名・ライセンス・ファイルの種類も指定できます。

次はAPIを待ちましょう。;-)

■ソースコード検索サイトリスト

• Google Code Search
• Code Search – O’Reilly Labs
  オライリー本から検索。
• codefetch{
• Krugle
  ajaxを使っていて操作感が良い。デザインもまとまっている。
  検索結果をクリックした際に画面右にファイルツリーが表示されるのも良い。
• Codase – Source Code Search Engine
  現在はC/C++/Javaのみ。
• csourcesearch.net Search
  C/C++のみ。
• Koders – Source Code Search Engine
  Webサイトに貼れる検索フォームにEclipseやVS用のプラグイン、Firefox用のエクステンションがある。

include_pathを設定する方法には、大きく分けて2通りあります。設定ファイル（php.ini/httpd.conf/.htaccess等）に記述する方法とPHPソースに記述する方法です。

記述例

設定ファイルに記述

; php.ini
include_path = ".:/usr/local/lib/php/pear"

; httpd.conf / .htaccess
php_value include_path ".:/usr/local/lib/php/pear"

PHPソースに記述

< ?php
$lib = dirname(dirname(__FILE__)) . "/lib";

// PHP4.3.0以降
set_include_path(get_include_path() . PATH_SEPARATOR . $lib);

// 全バージョン対応
ini_set('include_path', ini_get('include_path') . PATH_SEPARATOR . $lib);
?>

 

どちらの方法でも動作はしますが、どちらがより良いか考えてみました。

記述方法

それぞれの利点・欠点を挙げてみました。

	設定ファイル	PHPソース
良い点	・設定項目がまとまっているので把握しやすい。 ・ソースと設定を分離できる。	・動的に記述できる。 ・環境に依存せず動作する。
いまいちな点	・固定値しか設定できない。（動的に変更できない。） ・影響範囲が大きいので局所的な設定には不向き。 ・httpd.conf/.htaccessの設定はCLI環境では反映されない。	・他のソースから読み込まれると影響範囲が把握し辛い。 ・ソース内に混在する。

どちらにも一長一短があります。

記述場所

各記述場所は以下のとおりです。並びは設定の影響範囲順になっています。（下にいくほど影響範囲が狭くなっています。）

記述方法	記述場所	要root権限	環境依存
設定ファイル	php.ini	○	–
設定ファイル	httpd.conf	○	–
設定ファイル	.htaccess	–	○ httpd.confで使用禁止になっている場合がある。
PHPソース	インクルードファイル 各ソースで読み込む共通ソース。	–	–
PHPソース	単一のソースファイル	–	–

これを見るとどんな環境でも使えるのはやはりPHPソースですね※1。特にソースを配布する場合はPHPソースに記述する方が使用する側は手間がかからなくて良いです。

どちらが良いか

記述場所で考えると設定ファイルは制限があるように見えますが、私が普段携わっている案件ではphp.ini/httpd.confを（直接的にせよ間接的にせよ）触れる事がほとんどですし、もし触れない場合でも.htaccessが使えるようにしてもらえば特に問題無いかと思います。（.htaccessすら設定できない環境向けに開発する方が珍しいかと）

include_pathはJavaのclasspathと同じような感覚で捉えているので、ソースには書かず設定ファイルに書く方がしっくりきます。またmbstringやらmod_rewriteやら設定する事が多いので、それらと同じところに書いておけば設定を把握しやすいです。

実際の記述ですが、php.iniはデフォルトのまま or PEARディレクトリのみ記述。httpd.conf/.htaccessにサイト（ディレクトリ）共通設定を記述。これで基本的には終了です。CLIなどでPHPソース単体で設定が必要な場合のみソース内に記述するようにしています。

 

ただし上記で少し触れたようにソース配布を前提とした場合はソースに書くのもありだと思います。（もちろんその場合も共通ファイルを作成し、各スクリプトからはそれを読み込む形にした方が良いでしょう。）

 

※1もちろんdisable_functionsで無効になっている場合は別ですが。

毎月送付するA4請求書を簡単に三つ折りする方法です。

いずれにせよ手順はこうだ。目的とするA4用紙以外にもう1枚A4用紙を用意し、これを上辺に沿って直角にあてがう。A4用紙のタテは297ミリ、ヨコは 210ミリなので、あてがった結果はみ出した部分は3分の1弱。これを内側に折り返し、残った部分を半分に折ってやれば完成だ。

ITmedia Biz.ID：A4用紙を手軽に三つ折りする方法 (2006-10-04)

これまでは印刷した請求書の罫線を基準に折っていたのですが、これは基準となる罫線などが無くてもできるので便利ですね。A4サイズの下敷きなんかで折るとよりきれいにできそうです。

ちなみにこの折り方では3等分にはなりません。（三つ折り用の封筒にはと入ります。）これまで均等に3等分で折るもんだと思っていたのでちょっと驚きました。

 

#折り姫が気になります:-)

本稼働のサイトではdisplay_errorsはoffにしときましょう。でないと晒されてしまいます。

最近はあまり見ませんが、以前はちょこちょこWarningやらNoticeやら表示しているサイトがありました。（SUNのサイトでJavaがスタックトレースを吐いているのもありましたね。。。）人の振り見て我が振り直せで気を付けましょう。

 

実は一番気になったのは[/home/php/cakephp/cake/bootstrap.php]だったり:-)

PHP4+PostgreSQL7.4での開発中にトランザクションが終了しない現象が発生しました。アプリケーションのログを見てみても[begin]は発行されているのに[rollback/commit]が発行されていませんでした。

結局これ自体はPHP側の問題でPostgreSQLは無関係だったのですが、問題の処理を調べている際に複数回処理を実行するとロック待ちのような状態になりました。この処理ではアプリケーションから明示的にロックを行っていなかったので不思議に思い、DBのログを見てみると以下のようなログを発見。

LOG:  statement: SELECT 1 FROM ONLY "public"."t_category_m" x WHERE "category_id" = $1 FOR UPDATE OF x

アプリケーションで発行しているSQLではないのでgoogleに聞いて以下のサイトを見つけました。

行ロックをかける理由は，t2が参照している行が削除されるようなことがあると困るからである。そうなると，t2がt1を参照しているという参照整合性制約が崩れてしまうから，それを防ぐためにロックをかけるのはやむをえない措置と言える。

【PostgreSQLウォッチ】第20回 PostgreSQL 8.1ベータ・テスト開始，新機能ロールと共有行ロック：ITpro (2006-10-03)

外部キーを含む行をINSERTすると参照テーブルの関連行をロックしてしまうとの事です。まあ考えてみると当たり前なのですが、特に意識していなかったので「？」になりました。

普段は問題無いんでしょうが、これ意識しておかないと処理待ちやデッドロックが発生したりとまずい事になりそうです。

 

ちなみに8.1からは記事にあるとおり共有ロックにてこの問題は回避されているそうです。