Selenium Recorder

Selenium Recorder
ためしに自分ちのFireFoxにインストールしてみました。

そもそもSeleniumというのは、ブラウザベースのWebアプリケーションの
機能テストを自動化するためのツールです。

Seleniumは、JavaScriptを使って、HTMLのテーブルの形で記述された
テストケースを実行するTestRunnerという部分と、
JUnitなりNUnitなど、外部のプロセスからブラウザをコントロール
する形でテストを実行する"Driven"という部分にわかれています。

"Driven"についてはまだ調べてないのでよくわからないですが、
"TestRunner"はめちゃくちゃ簡単です。
ごちゃごちゃ説明するよりデモをみれば一目瞭然。
仕掛けは簡単ですが、効果はかなりでかいと思われます。

Selenium Recorderはユーザが行ったブラウザの操作を記録して、
このTestRunner用のテストスクリプトを吐いてくれる
FireFoxのエクステンションです。
使い方はこれも超簡単。すばらしい。

是非今度実際の開発で使ってみたいものです。

Maven2:siteプラグインにおけるi18nの問題

既にお気付きの方も多数おられると思うのですが、
Maven2のsiteプラグインは、文字エンコーディングの扱い方に
一貫性がなく、文字化け無しに完全な日本語のサイトを生成することは
いまのところ難しい状況となっております。
最近またMaven2やらplexusやらのソースコードを読んで、何が問題なのか
把握しようと努めてるのですが、問題は複数のコンポーネントに跨っており、
なかなか一筋縄ではいきません。

特に厄介なのは、site descriptorの生成処理です。
他の部分はまぁなんとかなりそうなんですけどね。
あまりにも無邪気にバイト配列<->Stringの間で変換を行っているために、
かなりわけのわからない事態に陥っています。

事の発端はふと気がむいてMaven2のsiteプラグインのプロパティリソース
ファイルを翻訳して本家にコントリビュートしたことでした。

まさかプロパティファイルが文字化けするとは思って無かったのですが、
翻訳したファイルを送りつけた後に試しに動かして見ると
見事に文字化ける化ける。

Maven2の開発者の方もすぐにコミットされたマルチバイト文字のリソースファイルが
うまく表示されないことに気づいたらしく、
「これちゃんと日本語見える？おかしくない？」みたいな
やりとりを数回やったあと、

JIRAに以下のIssueが作られることとなりました。

http://jira.codehaus.org/browse/MNG-1409

どれだけ効果があるかわかりませんが、みなさん、とりあえず
このバグにVoteしてみませんか?
日本語環境でMaven2を使う上では、結構クリティカルな問題のような
気がします。

開発者の方も動作確認する環境がないから大変なんだろうなぁ...
2.1くらいでは直っていてほしいものです。
いちおうデザインドキュメントには、More consistent i18nという項目が
あがっていますが...
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents

MSDN:XmlValidatingReaderの日本語訳

XmlValidatingReaderのMSDNの日本語訳まちがってるな。。。

初の.NETネタです。

(原文)
The XmlReader to read from while validating. The current implementation supports only XmlTextReader.

(訳文)
検証中に読み取る対象の XmlReader 。現在の実装だけが、 XmlTextReader をサポートします。

「現在の実装はXmlTextReaderのみをサポートします。」が正解。
でも引数で抽象クラスを宣言してるのに、
なんで実装に依存しているのか、そもそもそこが大問題。

工程分割のメリット

工程を分割せずにすむなら分割しない方がよい

このエントリの草稿をしたためている時に、この原則が当てはまらない、
つまり、工程を分割する積極的理由が存在する
ケースを発見してしまいました。

それは、
前工程の成果物をチェックして、
事前に何を作ろうとしているか確認すること
によって、後工程でのより大きな手直しのリスクを回避する
ということです。

しかし、このメリットが成り立つためには、当然の前提条件があります。
それは、
前工程の成果物をチェックするコストが
後工程の手直しによる潜在的コストより小さい
という条件です。私の意見としては、最近のオープン系のシステム開発に
おいて、この前提条件が成り立つケースは少なくなっているのでは
ないかと思います。ゆえに、オープン系のシステム開発に限っていうと、
やはりほとんどの場合、「工程を分割せずにすむなら分割しない方が良い」
ということは正しいと思います。

なぜ、私が、
前工程の成果物をチェックするコストが
後工程の手直しによる潜在的コストより小さい
ということが成り立たないと思うのか?それにはもちろんいくつか理由があります。

3つほどあります。

1つは要求が複雑化しているため、上流工程で
前もって何をつくろうとしているのか確認するコストが増加している
ということが言えると思います。

2つめはシステム構成の複雑さの増加という問題です。
システムに必要なこと全てをメインフレームが面倒を
見てくれていた時代と異なり、現在ではシステムは実に様々な
構成要素から成り立っています。サーバ側で基本的なものだけでも、
OS, RDBMS, アプリケーションサーバ、様々なライブラリやフレームワークを
組み合わせて構築する必要があります。
その結果、システム構築上の技術的な問題点を
設計段階で全て洗い出すことは難しくなっているとおもいます。
つまり、いくら前工程でコストをかけても
後工程での手戻りのリスクを減らせるとはかぎらない状況が生まれている
と思います。

3つめは技術の進歩による、生産性の向上
という問題です。新しい技術の登場は常に開発者の悩みの種でしたが、
でも、それでも新しい技術が登場するたびに、ソフトウェア開発の生産性は
確実に上がり、開発者から単純作業を奪っていると思います。特に、
本番環境と同じプログラムが手元のPCでも
実行できるようになったことおよび、
xUnitのようなテスティングフレームワークによって
回帰テストのコストが下がったことによって、
下流工程における手直しのコストがどんどん下がっている
と感じています。

以上の理由により、現状では多くの場合、
上流工程での品質確認のコストより下流工程での手直しの
コストの方が少ない、つまり、
動いているソフトウェアを確認した方が早い状況が生まれている
と思っています。