tmty.jp

xdebug でのデバッグは eclipse+TruStudio つかってる人が結構いるみたいだが、どうも php で eclipse ほどの環境を使うというのには違和感を感じていた。開発環境という話でいえば、最近は PHPIDE(いつのまにかPDTって名前になってた) とか結構いい感じに整ってきてて、これはこれで使いやすかったんだけど、eclipse が(気分的にも)重い。

で、いっとき emacs に行きつつも Ctrl 押しながらのカーソル操作に慣れず(というか、面倒)、結局 vim に戻った。なにより xdebug2.0 でサポートされてるリモートデバッグプロトコル DBGp に対応したプラグインが使えるのが大きい。コレが激しく便利。あまりやってる人を(ブログとかで)見かけないのが不思議だ。やってる人はわざわざ書かんってことか。

ということで、ちょい前に環境を作ってみたときのうろ覚えメモ。

まずは xdebug のインストール。0.9 なら pecl でも入るけど、今回の環境は 2.0.0 使ってるので、本家 から拾ってくる。先月末に RC3 が出てたみたい。こんなかんじでインストールできるはず。

これで、modules/xdebug.so ができるので、<PHPのホームディレクトリ>/lib/php とか適当な場所に運んで、php.ini に次のように追記して読み込んでやる。

<br /> zend_extension=”<PHPのホームディレクトリ>/lib/php/xdebug.so”<br />

これで $ apachectl graceful とかして、phpinfo() みるか、$ php -i とかやれば、うまくいってれば xdebug 設定状況が見られる。こんだけでも、ブラウザでデバッグすればスタックトレース見られるし、まあ、そこそこ使える。

続いて、リモートデバッグ環境。僕の場合、php.ini に以下を追加。リモートデバッグをやるよ、そのときのハンドラ(プロトコル)は DBGp だよ、自動でリモートクライアント探して接続するよ、みたいな意味。

<br /> xdebug.remote_autostart=On<br /> xdebug.remote_enable=On<br /> xdebug.remote_handler=dbgp<br />

他にもいろいろ設定できるので、詳しくは 本家にいろいろ書いてある のを参照。

これで、また apachectl graceful すれば、リモートデバッグできるようになる。本家で拾ってきた xdebug-2.0.0 のアーカイブには debugclient というリモートデバッグクライアントが含まれているので、こいつをインストールしてやる。(どうやってやるかは忘れた。確か、./configure とか make && make install してやるだけだったとおもうけど、最終的には使わなくなるので、適当にマニュアル参照、で逃げ。)

debugclient が入ったら、サーバ上で $ debugclient すれば、php 実行待機状態に入る。

この状態で、サーバ上で適当な php を実行してやれば、デバッグクライアントにコマンドプロンプトが返る。

ここで RDBp を喋ってやればリモートデバッガと会話できる。ためしに status -i 12345 とか入れてみてやれば、starting とか status が返ってくるはず。-i 指定したのはトランザクションIDといって、レスポンスがどのリクエストに対応したものか識別するためのもの。

気が済んだら Ctrl-C とかでデバッガ終了しちゃってOK

最後に vim の設定。vim onlineから debugger.tgz を拾ってきて、~/.vim/plugin に設置。vim 再起動して、準備完了。

そんじゃ実験。適当な php を読み込む準備をして、vim の適当なバッファで F5 を押す。下の方に waiting new connection in 5 sec. と出るので、5秒以内に php 実行。vim 画面がデバッガ表示に切り替わる。

あとは、ファンクションキー各種でステップ実行。F2 でステップイン、F4 でステップアウト。F11 で変数の中身も見られる。この辺のキー説明は配布元とか拾ってきた debugger.vim に書いてある。

こんだけできればデバッグ環境としては、じゅうぶんです、僕は。さくさく快適ー。

今回は、初の会場提供。何かと行き届かないところもあったと思いますが、無事終了しました。会場設営/発表等々ご協力いただいた皆様、ありがとうございました。また、今回は発表内容のおかげか、#plagger 方面からのご参加を多くいただき、これまでに無い早期定員締め切り&充実発表内容でした。ご参加の皆様、お疲れさまでした。
さて、今回の発表は3つ。
1個目はhamanoさんによる、PHP Extension 作成のチュートリアル。ブログは第1回から読んでるけど、まだ一度もやってみたことなかった。一通りの手順は理解できるが、お作法オマジナイ的なところが多く、聞いても???なところが多い。こりゃやってみないとダメだ。デフォルトプロパティの設定やメソッド定義の方法(M_INIT, R_INITはいずれも初期化時に呼ばれるものだが、CLIからの起動時とapache request毎に対応するものとで違うらしい)などなどの解説。焼き肉の席では「webアプリをapacheモジュールで提供したい」とのコメントも。
2個目はhaltさんによるPrhaggerの発表。PlaggerのPHP版。Rhaco使用。YAML作成にあたる部分が、ブラウザ上GUI操作っぽく進められる辺り、手軽さを感じた。アクションという名で、subscription+filter+publish を定義していくと、これらをひとまとめのアクションにしたphpファイルが生成されるという感じ。なかなか手軽で面白いが、話を聞いていると、コンテンツ生成時に書き込み権限が必要になったり、プラグインがまだまだ少なかったりと、まだこれからという部分もあるようだ。ちょっといじって楽しむ分には十分だと思うが。
ちなみに焼き肉の席で「ソース嫁」なプラグイン作成方法の一端を聞いた。とは言っても、subscription+filter+publishそれぞれのabstractクラスがあるので、適当にextendsしちゃって、ごりごり書くというノリっぽい。まあ、これも結局やってみないとわからんけど、大体ニュアンスはわかった。
3個めはmakinoさんによるRhacoを使ったWorkStyleアプリケーションの解説。GTDというプロセス(概念を指す？)によりタスク管理を行うというもの。もとはJavaアプリで作成しているが、レンタルサーバ等で個人が気軽に動かせるようにPHP版を作っているということらしい。RhacoはDjango的実装なのね。初めて知ったが、一度Djangoしておいてよかった。なんとなく動作の流れが掴めた。
モックアップがあったとはいえ、初PHPで実装1週間は、ある意味へこむ。やれやれ。
makinoさんは現在の出向先の会社の旧基幹システム「カ●ブリア●」に関わっておられたこともあるよう。世間狭いな〜。
ちなみにPrhaggerもWorkStyleもRhaco1.0だか1.0.1のサンプルに載るとかなんとか。サンプルにしては完成度の高いアプリだ。なかなかおもろいね。
焼き肉も13名受け付けに対し、最終参加20名。ここまで多くの方にご参加いただけるとは思いませんでした。多くの方とお話できて楽しかったです。Perl方面の方となかなか交流できませんでしたが.. 次回は、ぜひ。

「gettextの使いかた」に続き、これを qcodo で使ってテーブル名カラム名等を日本語化する方法。

codegen で自動生成された panel_drafts を見ると、テーブル名やカラム名はスキーマから取得されたそのままであることがわかる。業務システムで使うには、適当なビジネスロジックを入れてやるのはもちろんだが、日本語化も必須だろう。

本家 example サイトを参考に、日本語化をやってみた。qcodo で生成されたコードは、先に書いた gettext による国際化に対応しているので、*.po ファイルを用意してやれば良い(msgfmt による *.mo の用意も不要)。大体の出力文字列が標準で国際化対応した状態でコードされているが、qcodo/includes/qcodo/_core/framework/QI18n.class.php を確認すれば、具体的にどういうルールになっているかわかる。自分で書くときには QApplication::Translate() を使っても良い。自動生成されたコードの、どこが翻訳対象になっているかは、_t() 関数で翻訳指定されている部分を grep 検索してやっても OK。

*.po の書き方。たとえば、address_book テーブルに address_book_id, address_book_class のカラムがあるのであれば、次のような形で ja.po を用意してやる。

<br /> msgid “AddressBook”<br /> msgstr “アドレス帳”<br /> msgid “Address Book Id”<br /> msgstr “アドレス帳ID”<br /> msgid “Address Book Class”<br /> msgstr “アドレス帳区分”<br />

テーブル名はアンダースコア _ を詰める、カラム名は半角スペースに変える、ともに単語頭文字を大文字にする、辺りがルールになっている。同様に Create a New や Edit などのアクションボタン名も変えられるので適当に書く。

できた ja.po ファイルは、qcodo/includes/i18n または qcodo/includes/qcodo/i18n に置く。前者のディレクトリは標準で作られていないので、前者に置きたければ mkdir する。

さて、これだけで動くように書いてあるが、僕の環境だと動かなかった。翻訳してくれない。

ソースを追っていくと、QApplication::Translate() で取得するテキストドメインが怪しいように見える。QApplication::$LanguageCode をダンプしてみると “en” になっていた。ブラウザは日本語設定になっているので、どうして英語環境で初期化されているのかわからない。どこかでこいつを初期化しなおしてやる必要がありそうだ。

先の examples サイトを見ると、

Language and country settings can be setup in prepend.inc.php

とある。下の方に言語設定している部分があるので、有無を言わさず日本語設定になるよう変えてやる。

<br /> // Initialize I18n if QApplication::$LanguageCode is set<br /> if (QApplication::$LanguageCode) {<br /> QApplication::$CountryCode = ‘jp’;<br /> QApplication::$LanguageCode = ‘ja’;<br /> QI18n::Initialize();<br /> } else {<br /> QApplication::$CountryCode = ‘jp’;<br /> QApplication::$LanguageCode = ‘ja’;<br /> QI18n::Initialize();<br /> }<br />

とりあえず、これで僕の環境では翻訳してくれるようになった。が、このままだと、国際化してる意味が無いので、QApplication::$LanguageCode が true のときは既存のものを上書きしないようにするのが吉かな。

先日試したqcodoは国際化対応しているので、自動生成されたコード中のテーブル名やらカラム名やらボタン名やらは外部設定ファイルで翻訳情報を設定しておくことができる。php であれば gettext() という関数( _() というエイリアスで書かれていることも多い) があり、これを使った実装を心がけておけば、いつの日か自前アプリを世界発信(インターネットに置いた時点で世界発信だが)することになったときに、国際化対応に苦労することも無い、のかもしれない(なにしろ国際化対応アプリなぞ作ったことが無いので、そのときの苦労はわからない)。

ということで、gettext の使いかた。UNIXコマンドラインで使えるので、まずはこれの使いかたを押さえておく。PHP でさくっと使ってみるなら、 ウノウの方のエントリ がわかりやすい。

こんな感じで、gettext の引数に翻訳対象文字列を渡すと、あらかじめ作っておいた辞書ファイルを参照し、文字列を翻訳して返してくれる。では、その辞書ファイルはどうやって作って、どのように gettext で(その辞書ファイルを)指定してやるのか。

簡単にいうと、*.po というファイル名で辞書ファイルを作り、msgfmt というコマンドで *.mo というファイルに変換してやる。最後に、この *.mo の場所を gettext のオプションまたは環境変数で指定してやるという流れになる。

まず、*.po の作り方。msgid と msgstr というエントリを改行区切りで書いてやる。これを ja.po とする。xgettext というコマンドを使って、翻訳対象のソースコードからこの *.po のベースを生成することもできる。

こんなかんじで、複数エントリは1行開けて書く。次に、msgfmt で、このファイルをコンパイルする。-o オプションで出力ファイル名を指定できる(指定しないと messages.mo というファイル名で保存される)。

生成された ja.mo を /usr/share/locale/ja_JP/LC_MESSAGES/ja.mo として保存する。これで準備完了。

ja.mo の ja の部分は TEXTDOMAIN 環境変数で指定することもできるし、gettext の -d オプションでも指定できる。PHP だと textdomain() で指定する。つまり、標準で以下の設定になっているのであれば、上の gettext コマンドは、

という形でも実行できる。あとは gettext に渡す各種設定。

gettext コマンドでは、上記 *.mo を設置する /usr/share/locale ディレクトリを TEXTDOMAINDIR という環境変数で指定することができる(TEXTDOMAINDIR が指定されていない場合は、/usr/share/locale が標準利用される)。PHP だと bindtextdomain() で指定できるのが、コレ。詳しくは gettext –help とか参照。

なお、ja_JP は利用環境 LANG から取得されるので、echo $LANG とかで確認して、違っているようであればその通りのディレクトリ名にしてやる。PHP だと LC_ALL という定数を define 指定するのがコレ。

今度、これを踏まえて qcodo の国際化機能利用について書く。なお、上に挙げたウノウの方のエントリにあるが、i18n という言葉は internationalization の i と n の間の文字数から来ているそうだ。

書くまでもない小ネタだけど、「qcodoを試してみた」の続き。

qcodo の codegen で生成された panel_drafts は微妙に表示がオカシイ。dashboard の dashboard_left, dashboard_right 辺りの配置とスタイル指定がよろしくないようで、僕の環境だと、dashboard_right が下に配置されてしまい、スクロールしないと使えない。というか、panel が縦にデカすぎて使いにくい。

この辺の話は、 qcodo/asset/css/style.css と qdoco/panel_drafts/index.tpl.php を適当に書き換えてやれば OK。qcodo は smarty とか使ってるわけでは無いが、この辺りのビュー周りの設定をちゃんと外に切り出してくれてあるので、このくらいの修正は簡単にできる。

コード生成時のテンプレをいじりたければ、qcodo/includes/qcodo/_core/codegen 以下の templates, subtemplates 以下の *.tpl.php を書き換えてやれば良い。うまくやれば、業務システムのメンテ画面自動作成もさくさくいけるようになりそうだ。