akky’s log

URLの”/”区切りも含めてcgiのパラメータに受け取る方法

wikipediaの/wiki/記事/サブ記事やCakePHPの/コントローラー/パラメータ１/パラメータ２をcgi(今回はPHP）でどうやって受け取るのか、ずっと気になっていた。素直に考えると、Webサーバ（今回はapache)が”/”をディレクトリの区切りと判断したら、index.phpを置いているディレクトリではなくて、サブディレクトリにあるファイルを探しに行きそうで、どうやったら、”/”で区切られた先も含めて受け取るのだろうかと。以前に、wikipediaに使われているWikiであるmediawikiが実現している方法を探ってみたけど、挫折した経緯がある。

で、最近、CakePHPの.httaccessを見ていたら、mod_rewriteで書き換えているのが判った。QSAフラグを使うのだと。

QSAフラグについて、説明があるWebサイトhttp://wiki.bit-hive.com/tomizoo/pg/mod_rewrite%20-%20QSA%A5%D5%A5%E9%A5%B0

getElementByXXXの代わりにxpathを使う

既存のHTMLページを解析して必要な情報を取り出すために、JavaScriptを使ってコーディングを始めたのだけど、対象としているHTMLページがtableタグでレイアウトを組んでいるいる上にidやclassを使っている個所が少ないので

getElementByTagName(”table”)[0].getElementByTagName(”tr”)[2].getElementByTagName(”td”)[0].getElementByTagName(”table”)[0]　～以下略～ を使って延々とコーディングして目的のエレメントにたどり着ける。これではコーディング量が増え、バグの原因ともなる。なんと言っても面倒。
それを解決する方法を模索する中で、思いついたのがSeleniumで学んだxpath

目的としていることは getElementsByなんちゃら の代わりにXPathを使うに書かれている内容と同じ事。明日以降に試してみよう。

参考リンク

• W3C XML Path Language (XPath) Ver1.0
• XPath は実用に耐えうるかの考察と xpath.js
• XPathでRSSデータにアクセスする　(JavaScript編)

翻訳者の目で文章をみる

タイトルの「翻訳者の目で文章をみる」は「ドキュメントハックス-書かない技術 ~ムダな文書を作り方からカイゼンする~」の４章に出てきた見出しです。

自分の書いた文章が判りやすいのかを判断するための基準として他言語に訳した文章でも意味が通じるのか考えてみなさいということです。文系で物書きを得意とする人に聞いてみると割とポピュラーな考え方だそうだ。自分の書いた文章を読み直していても、自分では判っている事柄を書いているので、どうしても「判り難さ」の評価が出来ないでいる。想定する読者が決まっている文章であれば、想定する読者の視線で考える事ができるのだけど、自分と同程度の人を想定している文章だと何度も繰り返し読んでみないと判らない。

他言語の視点ということで、翻訳サイトを使って自分が書いた文章を一度英語へ翻訳してから、翻訳された英語を日本語に翻訳しなおしてみる。英語から日本語に翻訳した文章と元の文章を比較して読みやすい文章であれば悪くないでしょう。ということなので、前の段落を試してみました。

原文→英語

It is to think about whether a meaning knows even the sentence that I translated for the other language as a standard to judge whether it is easy to understand one’s sentence that I wrote. It seems to be a way of thinking that is popular comparatively when I ask the person who is good at composition in a faculty of liberal arts. Because I write a matter understanding by oneself even if I read over one’s sentence that I wrote again, it is never possible for evaluation of “the difficulty to understand” it. Though I can think for the eyes of the reader to assume if it is the sentence that a reader to assume is decided on, I do not understand it unless I repeat it many times when it is a sentence assuming a person at the same level as oneself and read it.

英語→日本語

それは、意味が私が標準としての他の言語が私が書いたその人の文を理解することが簡単かどうか判断するために翻訳した文さえ知っているかどうかについて考えることです。それは、私が誰が教養学科学部で構成が得意かについて人に尋ねるとき、比較的に人気がある考え方であるようです。たとえ私が私が再び書いたその人の文を読み終えたとしても、私が単独でわかっている問題を書いて、それは「わかる困難」の評価にとって決して可能でありませんそれ。それが装う読者が決心する文であるならば私が装う読者の目のために考えることができるけれども、それが自分と同じレベルで人を装っている文で、それを読んだとき私がしばしばそれを繰り返さない限り、私はそれを理解しません。

どうでしょうか。なんだか、判るような、判らないような・・・

画面キャプチャーのツール

数ある画面キャプチャーツールの中で愛用しているのは

• CaptureXP
• FastStone Capture

の二つ

CaptureXPはタイマー指定でキャプチャーが便利。、ツールバーやプルダウンメニューなどを含めてキャプチャーしたい時に、キャプチャーしたいメニューを表示した状態でctl+ＰｒｉｎｔＳｃｒｅｅｎを押してしまうとメニューがない状態でのキャプチャーになってしまう。そこで、CaptureXPをタイマー指定でキャプチャーを開始し、タイマーで待っている間にメニューを表示させ待つ。待ちが終るとキャプチャーしたいウィンドウを指定してキャプチャー。
写真を撮影するカメラのセルフタイマーを使って撮影するのに似ている。

もう一つのFastStone Captureは画面スクロールしてキャプチャーしてくれるのが便利。延々と縦スクロールする画面を部分々でキャプチャーしてペイントで切り貼りしていた手間がアホに感じられる。惜しく感じるのはウィンドウの内側だけなので、ウィンドウのタイトルやメニュー部分を含められないということ。Ver5.3までは無料でVer5.4以降はシェアウェアになってしまったので使っていないため最新事情は分からない。もしかすると改善されているのかもしれない。

Microsoft Script Editorを使ったIEで動作しているJavaScriptをデバックする方法

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ヘルパーのobserveField

先日は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)を参考にしてください。

DragZoomControlからインスパイァーを受ける

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

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

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

mantis 1.0.7から1.1.0a4への移行　できず　の続き（文字化け解決編）

先日の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.0.7から1.1.0a4への移行　できず

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のエディタ

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 を見てみると画面が真っ白。約１年近く成果物がメンテナンスされていないみたい。休止しているのかな？