2010-11-21

Windows上の Emacs 日本語入力セットアップ(DDSKK のインストール)

ここではQAエンジニアと言いつつ、数ヶ月前から現在の所属は一介の開発エンジニアなので開発も多少するわけですが、コーディングには基本的に Emacs を使ってます。使ってるだけ。使いこなせてません。

少し前に出た WEB+DB PRESS Vol.58 に載っていた Emacs 特集記事が、僕のように昔に少し使ったっきりで再入門したい者にはうってつけでした。基本的にこちらの記事に習って、Windows 上の Emacs を少しずつ設定していってます。

昔は Windows だと Meadow とか入れたものですが、最近は本家 GNU Emacs のWindows版でも違和感なく使えるようになっていてすばらしい。とは言え、日本語入力についてはそのままでは少し難があり、特にカタカナ語がふつうの変換で出てこないのが僕にとっては大きな問題でした。今回ようやくその対処として、DDSKK をインストールしてみたのでそのときのメモ。

上の WEB+DB の記事をベースに設定していたので、同じ作者さんによる
http://d.hatena.ne.jp/tomoya/20100905/1283681474
をベースとして参照しつつ、Windows 固有の部分は
http://d.hatena.ne.jp/andjuny/20090928/1254144096
なども参考にさせていただきつつ。

導入手順

APEL、DDSKK をダウンロードして解凍

APEL のインストール

APEL の makeit.bat にて、変数設定部分を下のように:

set PREFIX=%HOME%\.emacs.d
set EMACS=c:\bin\emacs-23.2\bin\emacs.exe
set LISPDIR=%PREFIX%\elisp
set INFODIR=%PREFIX%\info
set VERSION_SPECIFIC_LISPDIR=%PREFIX%\elisp
set DEFAULT_MAKE_ARG=

その上で、

C:\bin\apel-10.8> makeit.bat elc
C:\bin\apel-10.8> makeit.bat what-where
C:\bin\apel-10.8> makeit.bat install

makeit.bat の部分については以下も参照:
http://www4.kcn.ne.jp/~boochang/emacs/apel.html

SKKのインストール

こちらの makeit.bat も上と同様に設定。
DDSKK の SKK-CFG にて、以下の設定:

(add-to-list 'load-path "c:/Users/xxxxx/.emacs.d/elisp/emu")
(add-to-list 'load-path "c:/Users/xxxxx/.emacs.d/elisp/apel")
(setq APEL_DIR "c:/Users/xxxxx/.emacs.d/elisp/apel")
(setq EMU_DIR "c:/Users/xxxxx/.emacs.d/elisp/emu")
(setq SKK_DATADIR "c:/Users/xxxxx/.emacs.d/etc/skk")
(setq SKK_INFODIR "c:/Users/xxxxx/.emacs.d/info")
(setq SKK_LISPDIR "c:/Users/xxxxx/.emacs.d/elisp/skk")
(setq SKK_SET_JISYO t)

とした上で

C:\bin\apel-10.8> makeit.bat install

.init.el、.skk の設定

設定は
http://sheephead.homelinux.org/2010/06/18/1894/
を大いに参考にさせていただきました。コピペともいう。

まだ内容もちゃんと把握していないので、このあたりは使いながら必要に応じてカスタマイズしようと思います。

操作

Ctrl+x j で SKK モードに切り替え。
アルファベットの大文字から始めるつもりで K a n j i などと入力すると、変換候補が出てくる。

まだマニュアル読んでるところ。
http://openlab.ring.gr.jp/skk/skk-manual/skk-manual-ja.html

ちょっと慣れは必要そうですが、使いながら馴染んでいこうと思います。

2010-11-21

Selenium RC のテストを別環境で動かすときの注意点

Selenium を使った自動テストを今までは主に Windows 上で実行していましたが、最近 X Window が乗った Linux 上で実行させる機会がありました。いくつかひっかかったポイントがあったので記録しておきます。

なお、僕の場合、テスト作成〜実行までの基本的な流れは以下のような感じです。

Windows 上で Firefox と Selenium IDE を使ってテストケースの主要な部分を録画・作成
Selenium IDE でそれを Perl にエクスポートし、Test::WWW::Selenium を Selenium RC のクライアントドライバーとして利用したスクリプトを作成
上の Perl スクリプトを Linux 上で実行して、Windows 上で起動している Selenium RC サーバをキックし、その Windows の Firefox でテストを流す

今回は最後の、Perl スクリプトを実行する Linux と、 Windows 上の RC Server + Firefox でのテストの部分を、別の X Window 付 Linux に置き換えた場合の問題について記述しています。

Linux: CentOS 5.2 (x86 64bit)
Perl: 5.8.x
Selenium RC Server: 1.0.3
Firefox: 3.5

テストが終了しても Firefox が閉じない

Windows 上の Selenium RC Server + Firefox でテストを実行した場合は、テストケースの終了と同時に勝手に Firefox が終了していたのですが、 Linux の X Window 上で実行すると Firefox が開いたままになりました。

解決は単純に、テストケース中で start と stop を明記すればよいようです。

use Test::WWW::Selenium;
my $sel = Test::WWW::Selenium->new{ (省略) };

$sel->start;

・・・テスト内容・・・

$sel->stop;

全角チルダ/波ダッシュ問題

Windows で作成したテストケース中で、表示されたウェブページ内の文字列の確認(VerifyText 等)を行っている場合、いわゆる「全角チルダ」「波ダッシュ」の問題にひっかかる可能性があります。

$sel->is_text_present("1件〜30件");
|perl|<

たとえば、上のように「1件〜30件」という文字列が表示されていることを確認しようとした場合、「〜」の部分を波ダッシュ(U+301C)として文字マッチしてほしいのに、Windows上で作成したテストケース中では全角チルダ(U+FF5E)として保存されてるために文字マッチしないようです。Linux 上で、テストケースを作成すれば、本来の波ダッシュ(U+301C) として保存されるので、期待通りマッチします。

参考リンク:
- http://www.informe.co.jp/useful/character/character14.html
- http://ja.wikipedia.org/wiki/Unicode#.E6.97.A5.E6.9C.AC.E8.AA.9E.E7.92.B0.E5.A2.83.E3.81.A7.E3.81.AEUnicode.E3.81.AE.E8.AB.B8.E5.95.8F.E9.A1.8C
- http://ja.wikipedia.org/wiki/%E6%B3%A2%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5#Unicode.E3.81.AB.E9.96.A2.E9.80.A3.E3.81.99.E3.82.8B.E5.95.8F.E9.A1.8C


** (おまけ) マルチバイト文字列の扱い

これは Selenium とは関係ない Perl の問題で、日本語文字列などの扱いに注意が必要かもしれません。(特に、別ファイルから文字列を読み込んだりしている場合など)

個人的に今回ひっかかった問題は、YAMLファイルから一部のロケーター(例: "//input[@value='ログイン']")を読むようにしていた箇所で、最初は以下のように記述していました。

>|perl|
use YAML qw(LoadFile);
my $config = LoadFile("config.yaml");
decode("utf8", $config->{login_button_locator});
$sel->click_ok($config->{login_button_locator});

最初手元の環境で利用していた YAML モジュールの古いバージョン(0.66) ではこれで動作していたのですが、新しいバージョン(0.72) が使える環境にもっていくと以下のエラーで落ちます。

Cannot decode string with wide characters at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Encode.pm line 174.

最初原因が分からなかったのですが、YAML の LoadFile の中を見ると新しいバージョンでは

 binmode $IN, ':utf8';

として、デコードしてくれるようになったからのようで、すでにデコードされて utf8 フラグが立ってる文字列をさらにデコードしようとしてエラーになっていた模様。

今回の件はだいぶニッチな感じでしたが、 Perl やCPANモジュールのバージョンが異なる環境で動かす場合は、このあたりのエンコードのタイミングなども注意が必要なことが、実装の仕方によってはあるかもしれません。