akky’s log

Webアプリの開発をしていて、FireFoxにFirebugを使ってデバックしているのだけど、どうしてもブラウザ実装の差異でIEでは動かない場面が出てきてしまう。これまでIEでデバックするときは古典的な方法でalertを使いせっせと変数の値を参照していたのだけど、どうしても面倒になってしまう。
IEではJavaScriptでエラーになったときに表示される警告ダイアログ内の行と文字を見ても、問題となった箇所へたどり着くのが困難な場合が多いので、Office2003に入っているMicrosoft Script Editorを使うとデバッガが立ち上がりエラーの箇所を示してくれる。でも、変数の値を参照できない（？）のでデバッガが立ち上がったからといって問題を解決できている状況でもない。
この状況で、IEでのデバックの効率を上げるために数日模索していた結果、Microsoft Script Editorを使いブレイクポイントを設定してデバックする方法が分かったので、その手順を記録しておく。

あっ。Visitual Stadioをいう案もあるのかもしれないけど、JavaScriptをデバックするためだけにあんな重たいものをインストールするのは無し。

1. Microsoft Script Editorのインストール。英語だけどHOW-TO: Debug Javsscript in Internet Explorerを参考
2. IEを起動して、デバックしたいページへ遷移
3. Microsoft Script Editorはスタートメニューに登録されないので、「名前を指定して実行」からバイナリーを直接起動C:\Program Files\Microsoft Office\OFFICE11\MSE7.EXE
4. 「デバック」→「プロセス」を選択して、プロセス一覧を表示
   
5. プロセス一覧のタイトルにはウィンドウのタイトルが出ているので、これを頼りにIEのプロセスを特定して、「アッタチ(A)」ボタンを押す。
   
6. 「プロセスにアッタチ」というウィンドウが表示されるので、そのまま「OK」。
   
7. アッタチしたら、プロセス一覧のウィンドウは必要ないので閉じる。
8. 「デバック」→「ウィンドウ」から「実行中のドキュメント」を選択して、「実行中のドキュメント」を表示する。
   
9. 「実行中のドキュメント」からデバックしたいJavaScriptのソースファイルを選択（ダブルクリック）する。
   
10. ソースコードが表示されるので目的の場所へブレークポイントを設定。
    
    
11. アッタチされたIEから操作を行なうと、ブレークポイントで停止する。この後は、ウォッチとステップ実行でデバックを進める
12. 終るときは、「デバッグ」→「すべてデタッチ」を選択して、IEのプロセスをMiscsoft Script Editorから解放。
    

先日はAJAXヘルパーのobserveFormを使って、フォーム内の任意の項目が更新されたタイミングで非同期な検索を行うことをやり、今回は、observeFieldを使ってフォーム内の特定のフィールドが更新されたタイミングで検索を行わせてみました。observFieldの使い方はobservFormと一緒で、フォームのidを指定していた第１引数をフィールドのidにするだけ。ラクチン。フィールドがhiddenでもOKなのね。

今回、observFiledを使うことになったのは、DragZoomControlからインスパイァーを受けるの続きの話で、マウスでGoogleMap上の範囲を指定させ、指定された始点/終点（長方形の対角の２点）を使って検索を行う機能。mousedown,mousemove,mouseupのイベントを使い範囲指定させるのは上手くいったので、mouseupの最後で始点/終点の座標をフォームに設定してsubmit。検索結果を画面に出したかった。
当初はJavaScriptでsubmitさせようとしたのだけど、検索の一部と結果表示を既存のobsevFormを使っている部分を共有したかったので、方式を統一する意味でもobservFiledを使う事にした。始点X,始点Y,終点X,終点yの順番でフォームに書き込んでいき、終点yをobservFiledで監視しておくと、マウスでの範囲選択終了を契機にして、検索が行われ結果表示までつなげていく。

observFormの使い方についてはhttp://puyo2.upper.jp/cake/のCakePHPのHelperを使う〜Helperの使用法とかんたんAJAX〜(pdf)を参考にしてください。

GoogleMapを使っているサービスのブラウザ上ので座標から緯度/経度に変換する方法を探してネットの海をさまよっているうちに
http://nyanjiro.no-blog.jp/web20/2007/06/dragzoomcontrol_32db.html
でDragZoomControlというのを見つけた。選択開始コマンドのボタンを押すとGooleMapを描画しているDivタグの上に別レイヤーを重ねて画面上で範囲を決め、その範囲が収まるズームに変更してくれるAPI。

直接、このAPIを使うことはしないのだけど実現方法はなるほどね。と関心させられた。選択開始コマンドのボタンを押すと、GooleMapの上に、divタグを重ね合わせて半透明にしておく。このときは４つのdivタグを作っておいて、マウスで選択している範囲（最初にマウスをクリックした位置から、現在のマウスの位置）が中抜けになるように４つのdivタグの大きさと位置を調整する。そうすることで、半透明になっていない部分が選択範囲として見せることが出来る。ズーム後には表示されないので半透明にした部分は網掛けに見えるので、「ここは表示されないよ」という意味をもたせられる。

(　･∀･)つ〃∩ ﾍｪｰﾍｪｰﾍｪｰ

先日のhttp://www.mantisbt.org/wiki/doku.php/mantisbt:upgrade_to_utf8にある
UTF-8への移行方法の結果です。ここにある手順を乱暴に書くと、DBのdefault character set をUTF-8にした別DBを作り、mysqldumpで現行DBからダンプファイルを取得して、iconvでlatin1からUTF-8に変換してimportせよ。と。

現行のDBのdefault charset setはUTF-8だから特段変更する必要はないのかなと思い省略。ダンプファイルをiconvで変換した結果は文字化けしていないものだと期待いていたのだが、文字化けしたまま。importしても文字化けが解消されるとは思えないので、インポートは行わず。結局、この方法でもダメなのかもしれない。

そもそも、1.1.0a4の何処で文字化けをおこしているのか、その原因を突き止める方向に変更。1.0.7のソースを見る限りではDBとの読み書きで特段の変換処理は行っていない様子。では、1.1.0a4ではどうかと思ったが、こちらも無し。でも、1.1.0系はUTF-8が標準だということなので、どこかで明示的に文字コードの指定をしているのかもしれないと予想を立て、utf8でgrepしてみる。ビンゴ。core/database_api.phpのdb_connect関数の中でSET NAMES UTF8している。この部分をコメントアウトしてみると、文字化けは解消された。

という経緯で、UTF-8と指定しなければ(latin1で読み込めば？）文字化けしない可能性が出てきた。そこで試したのがこの方法

$ mysqldump -u DBユーザ名-p bugtracker --default-character-set=latin1 > bugtracker-latin1.sql
$ sed -e 's/latin1/utf8/g'  <  bugtracker-latin1.sql >bugtracker-latin1-utf8.sql
$ mysql -u DBユーザ-p bugtracker < bugtracker-latin1-utf8.sql

エディタで文字コードをUTF-8に指定してmysqldumpで出来上がったbugtracker-latin1.sqlを開いてみると文字化けしていない！！。ダンプファイルの中ではcharcter setをlatin1に指定しているのをutf8に置換して、インポート。先ほど編集したcore/database_api.phpを元に戻して画面を開いていると、無事文字化けしていない。

ふ〜やれやれ。文字コードの問題はこれで解決。残る問題はテーブルの変更。alter文が分かれば何とかするのだけどな・・・。列の追加や型/桁の変更は定義を見比べて調べることはできるのだけど、UPDATEする必要があるのは調べられないし、追加した列が必須入力の場合には妥当な値を調べる必要があるし。英語では更新できるようなので、その方法を調べればよいのか？！

念のため、charcter set 関連のパラメータ

mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name            | Value                                  |
+--------------------------+----------------------------------------+
| character_set_client     | utf8                                   |
| character_set_connection | utf8                                   |
| character_set_database   | latin1                                 |
| character_set_filesystem | binary                                 |
| character_set_results    | utf8                                   |
| character_set_server     | utf8                                   |
| character_set_system     | utf8                                   |
| character_sets_dir       | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
8 rows in set (0.01 sec)

mysql>

あっ。character_set_databaseがlatin1のままだ。テーブル変更の方法が判ったら、これも直してやり直そう。

mantis 1.1.0安定版のリリースが待ち遠しい日々のなか、wikiを試し、その勢いで1.0.7から1.1.0a4へ移行しようと思い立つ。

マニュアルのアップグレードを読みつつ作業を進めていき、install.phpをから「Install/Upgrade」を実行するとYour database has not been created yet. Please create the database, then install the tables and data using the information above before proceeding.というメッセージが表示される。でも、データベースを変更していないってさ。試しにログインして、期待と不安の中マイページを表示すると文字化けしてます。orz。ショックを受けつつロードマップを試そうと適当な改善要求にtarget versionを指定して更新すると、テーブルに列がなくてUPDATEに失敗する。もうだめです。

文字化けは何とか直そうとこげつきませんのmantis 1.1.0a2から1.1.0a4へのデータマイグレーションと同じ内容の文字化けなので、作られたツールを試してみます。しかし、添付ファイルをDBに入れていたのでダンプファイルを戻すときにエラー。この部分を削除してもコメントの文章で所々エラー。エラーになった個所を削りつつなんとかダンプファイルを無理やりDBへ戻し、削除した個所は個別にINSERTして無事（？）日本語を表示。

文字化けの問題は解決できそうな目処はあるのだけど、テーブルの変更の問題が残っている。「こげつきません」の記事を読んでいて1.1.0.a3からマルチバイトの扱いを変えているようなので、a3での変更をさぐってみたい。その結果はてなブックマークの日本語mantisのページにa3リリース当時の文章が残っていた。そこには「旧バージョンからのアップグレードは英語版のみ対象になっています。日本語等は…」と。アップグレード出来ないって。日本語等は…の続きは〜

半日以上試行錯誤して無理やりアップグレードするのは諦めました。

これを書いていて、http://www.nabble.com/Mantis-1.1.0a4-Released-tf4204546.html
にUTF-8への変換方法がhttp://www.mantisbt.org/wiki/doku.php/mantisbt:upgrade_to_utf8に書いているという記述を発見。試してみます。結果は追って報告。

eclipseを使い、プロパティファイルに定義したメッセージをResourceBundleを使って読み込むクラスをテストしている過程でプロパティファイルをeclipseから編集して、native2asciiを通さずともメッセージに含まれている漢字が文字化けせずに表示されて驚いていた。プロパティファイルで漢字を表すにはnative2asciiを使ってUnicode参照文字にする必要があるのだけど、それをやっていない。プロパティファイルを開きなおしても漢字がそのまま表示されている。

native2asciiを通していなくても文字化けしない気持ち悪さを解決するために記憶を手繰っていくと、どこかのWebサイトにプロパティファイルを編集するeclipseのプラグインがあることを思い出した。使っているeclipseはAll-In-Oneだ。きっとプラグインがインストールされているに違いない。
プロパティファイルをメモ帳で開くとUnicode参照文字になっていた。これですっきり。

これを書いている過程でAll-In-Oneのプロジェクトホーム http://aioec.sourceforge.jp/cgi-bin/wiki.cgi を見てみると画面が真っ白。約１年近く成果物がメンテナンスされていないみたい。休止しているのかな？

Subversionのpost-commitフックスクリプトを使ってリポジトリへcommitした際のログメッセージをmantisへ登録させようとhttp://www.alles.or.jp/~sogabe/mantis/article/article1.htmlを参考にしてpost-commitフックスクリプトをつくって実行してみるものの

送信しています commitしたファイル名
ファイルのデータを送信中です.
リビジョン 201 をコミットしました。

警告: ‘post-commit’ フックが次のようなエラーを出力して失敗しました:

となりmantisへコミットした際のログメッセージが書き込まれていない。エラーでて失敗したとは言われるけど、エラーメッセージには何も表示されていないので失敗する理由が判らない。フックスクリプトに記載したコマンドを直接実行する限りでは成功する。

失敗する理由を突き止めない事には先へ進めないので--verboseオプションを追加してみると

送信しています              commitしたファイル名
ファイルのデータを送信中です.
リビジョン 201 をコミットしました。

警告: 'post-commit' フックが次のようなエラーを出力して失敗しました:
: invalid option
Usage:  /bin/sh [GNU long option] [option] ...
        /bin/sh [GNU long option] [option] script-file ...
GNU long options:
        --debug
        --debugger
        --dump-po-strings
        --dump-strings
        --help
        --init-file
        --login
        --noediting
        --noprofile
        --norc
        --posix
        --protected
        --rcfile
        --rpm-requires
        --restricted
        --verbose
        --version
        --wordexp
Shell options:
        -irsD or -c command or -O shopt_option          (invocation only)
        -abefhkmnptuvxBCHP or -o option

となり、スクリプトが実行できていない。なんで--verboseオプションを付けるとオプションが違うと言われてしまうのか・・・。見直してみてもスペルミスはしていない。念のため、エラーメッセージの--verboseをコピペしてみるものの、状況は変わらず。

もう、行き詰まりです。

そういえば、shell-scriptの開発をしていて改行コードがCRLFだった為に前にこんな事もあったなと思い出して、vimエディタでset fileformatを実行してみると、DOSって言われた。ora。
set fileforamt=unixをして保存後に試してみると成功！。やったぜカトチャン。
というわけで、vimの便利設定で改行コードに気づきませんでした。というオチです。

安定版1.1.0リリースを期待したβ版を試すシリーズ（？）の２回目。今回はwikiとの統合。mantisとしてはDokuWikiが本命とおもうのだけど、1.1.0a4から対応したmediawikiと統合してみます。DokuWikiではなくmedaiwikiにした理由は同じサーバ内にmediawiki 1.6を別件でインストールしていたのと、DokuWikiをインストールするのが面倒だったから。DokuWikiならDokuWikiに手を入れてなんちゃってSingle Sign-ONとDokuWikiからmantisへ容易にリンクが張れるそうです。
認証については今回は触れずにmantisとWikiを統合したらどんなことができるのかを試してみます。

設定

config_inc.phpにwikiの設定を追加します。

        $g_wiki_enable = ON;

        # Wiki Engine (supported engines: 'dokuwiki', 'mediawiki')
        $g_wiki_engine = 'mediawiki';

        # Wiki namespace to be used as root for all pages relating to this mantis installation.
        $g_wiki_root_namespace = 'mantis';

        # URL under which the wiki engine is hosted.  Must be on the same server.
        $g_wiki_engine_url = $t_protocol . '://' . $t_host . '/wiki/';

設定を行うと改善要求と画面上部のメニューにwikiへのリンクが表示されます。

画面上部のメニューの「wiki」

画面上部のメニューにwikiへのリンクが追加されています。リンク先は選択しているプロジェクトで判断され、「全プロジェクト」であればwikiの「/wiki/index.php/Mantis:start」へ遷移し、プロジェクトを選択していれば「/wiki/index.php/Mantis:Project:プロジェクト名」へ遷移します。全体のTOPもしくはプロジェクト単位のTOPへリンクされます。

改善要求のwiki

改善要求の場合は「/wiki/index.php/Mantis:ID」へのリンクになり、改善要求が個別にページをもてます。

wikiと統合するとなにがうれしいの

で、BTSのmantisとCMS(Content Management System)を統合するとこで便利になる事を考えてみると、BTSでは個別の改善要求を行う経緯を記録することはできるけど、システム全体に及ぶことはできない。別の見方をすると個別の機能やシステム全体の仕様はBTSでは管理しきれない。CMSでは仕様を管理できるが、個別の改善要求の過程を記録することはない。そこで、相互に補完しあってシステムのドキュメント管理と変更管理を行っていこうじゃないか。

参考

• mantis本家のwiki

安定版1.1.0のリリースを期待して、現状の開発版1.1.0a4でのroadmap機能を試してみました。

設定については本家wikiのroadmapページにあるconfigurationを参考に行いました。

roadmapで管理したいプロジェクトは

• ロードマップ対象とするリリース/バージョンは「リリース」のチェックを外す
• 改善要求の「Target Version」に対象のバージョンを選択する

をするとroadmapの画面にリリース/バージョンで予定している改善要求の一覧と解決済みになった改善要求の割合を表示してくれます。

なので、実際の運用を想定すると

1. プロジェクト管理でリリース/バージョンを追加。その際には「リリース」のチェックを外す
2. 改善要求を登録。登録した改善要求のTarget Versionには目標にするリリース/バージョンを選択する。ここで選択するリリース/バージョンは上で追加したものになります。
3. プログラムが完成したら改善要求のステータスを「解決済み」もしくは「完了」に変更する

を繰り返すとリリース/バージョンに対して改善要求の完了率をroadmapで知ることができる。

先日OTNで公開されたばかりのOracle11gを早速インストールした方。
http://www.fiberbit.net/user/kunyami/oracle/11g-install.html
それにしても、512Mではスワップ多発で実用に耐えないのか。最初はメモリ使用量を調整すれば512Mでも平気じゃないかとおもったけどデータベースのインスタンスよりも管理用の機能がJavaで実装されているからメモリを喰うのだろうな。

cakePHPを使った開発でUnitテストの組み方。今回はリンクだけ

• CakePHP Test Suite http://cakeforge.org/projects/testsuite/
• 眠るシーラカンスと新米プログラマーさんの“テスト駆動開発”カテゴリ http://blog.livedoor.jp/coelacanth_blog/archives/cat_50211380.html