みかログ

わたしは英語が苦手なので，翻訳ソフトなんかをよく利用するのだけど，やっぱり翻訳ソフトの精度はいまいち．
書籍などをオンラインで読む場合は，たいていサンプルが豊富だし，知っているような英単語が多いので，わからない単語が相当あっても，なんとなく意味はつかめる．でも，最近英語のMLとかをチェックしだしたら，かなり言ってることが理解不能な部分が多く．．．

色々調べていたら，学習者向けの英英辞典が良いらしいということなので，一番有名なロングマン英英辞典を買ってみた．
英和辞典だと，いまいちピンとこないような感じは確かにしていたので．

ロングマン英英辞典は普通の紙の辞書＋CD-ROMという構成だけど，目的はCD-ROM版．
紙のは引くのが面倒なので使うつもりは無し．(^^;

ロングマン現代英英辞典 4訂増補版 CD-ROM2枚付 <上製版>

発売日2005/12/21

一部ソフトに不都合があるらしいので，
『ロングマン 英英辞典』付属CD-ROMの不具合につきまして
のパッチを当てると良いらしい．

これで，さくさく検索できて，単語も発音してくれる．
（発音はあまり関係ないけど，子どもに英語を教えるときに便利かも・・・．）

英英辞典はネイティブ用と学習者用の２つがあるらしい，というのも今回はじめて知ったけど，ロングマンはもちろん後者．
学習用も有名どころがいくつかあるらしく，比較しているサイトもあった．

有名＆使ってる語数が一番少なく，わたしにも理解しやすそう(^^;という理由でロングマンを選択．
辞書を作るときに，単語の利用頻度とかの統計を取って，頻度順にまとめているあたりも好感触．

で，早速使ってみると，こんな感じ．
ATLAS V13 の機械翻訳で失敗した部分を辞書で調べてみる．

原文：Thickbox seems good, but overkill for what I wanted.

ATLAS V13：Thickboxは欲しかったものに関してしかし、利益、過剰殺傷に見えます。

excite翻訳：Thickboxは私が欲しかったものに関してしかし、利益、過剰殺傷に見えます。

※Thickboxは画面内にHTMLでポップアップさせるプラグイン．

過剰殺傷ってところが意味不明．
で，調べてみると

ATLAS V13の辞書：過剰殺傷，過剰各殺戮力

ATLAS V13付属の電子辞書：
　N ○過剰殺傷, (核兵器による)過剰殺りく・(一般に)やり過ぎ, 過剰核殺戳力
　○オーバーキル
　○過剰殺傷

ATOK2006のジーニアス英和：
　【名】 過剰殺傷；大量核破壊力；過剰．
　―【動】｜他｜…を過剰殺傷する．

ロングマン英英：
　more of something than is necessary or desirable:

一番ぴったりくるのはやっぱりロングマン英英．
このくらいの単語ならなんとかわかるし．
（disirableはさらに辞書引いたけど(^^;）

過剰殺傷という意味は出てこないので，その使われ方はたぶんマイナーなのかな？（と勝手に推測）

例をもう1つ．

原文：
It's a brand spanking new system,
which transforms John's autogenerated XML via a custom XSLT stylesheet.

ATLAS V13：
それは、カスタムXSLTスタイルシートでジョンのautogenerated XMLを変える新しいシステムをぶつブランドです。

excite翻訳：
それはカスタムXSLTスタイルシートでジョンのautogenerated XMLを変える新しいシステムをぶつブランドです。

spanking の意味が変ぽい．autogeneratedも訳せないぽい．
さっきの例もそうだけど，exciteもATLASも傾向がほとんど一緒・・・

ATLAS V13の辞書：ぶつ，ピシャリと打つ，打つ，叩く，平手打ち
（そもそも名詞しか登録されていない・・・）

ATLAS V13付属の電子辞書：
　ADV ○とても, 非常に・clean, fine, newなどの前に用いる, しり叩き

ATOK2006のジーニアス英和：
　spank・ing１
　―【副】［clean，fine，good，newなどを修飾して］ とても，きわめて∥
　have a ～ good time｜ とても楽しい時を過す．

ロングマン英英：
　spanking2(adberb) informal
　1 spanking new very new and impressive:
　　→a spanking new shopping centre
　2 spanking clean very clean

今度はどれも普通に意味がわかるけど，ロングマンは spanking new / clean しか出ていない．
他の用法はマイナー？

まぁ，調べたのがぴったり出てくるのはさすがというか，この辺が統計的に調査した成果なのかも．

とりあえずもう少し使ってみるつもり．
今のところは調べたい意味がかなり優先的に出てくるような感じがするのと，たぶん英和で調べるより，ニュアンスのずれが少なそうなので．．．

ｊQuery 1.0がリリースされました．
詳しくは本家Blogの以下のエントリを．

jQuery 1.0

ホームページやドキュメント周りの修正はこれからの模様です．

これでプラグインの開発とかがやりやすくなったかも．
今までは最後の公開版用とSVN版用とで互換性がなかったので・・・

サイトを普通にAjaxを使って作ると，ブラウザの戻るボタンが使えなくなったり，ブックマークができなくなってしまう．
サイトの中の一部（たとえば商品情報）をAjaxで差し替えるようなケースでは，これが結構使い勝手を悪くしてしまう．

location.hashを使ったセッション復元＠最速インターフェース研究会
の記事をみて，location.hashでできそうなことを知ったけれど，どうもIEではうまく動かない．

さらに色々調べてみると，
Fixing the Back Button and Enabling Bookmarking for AJAX Apps
というような情報を発見．

IEの場合は，location.hashの代わりにiframeを使えばできる模様．

ブラウザごとの挙動をまとめると

となっている模様．
なので，単に両方を使ってしまうと，Opera9で不都合がでてしまう．

IEの場合のみiframeを使い，そのほかの場合はlocation.hashを使うのが良さそうな感じ．
（ちなみに，Safariではうまくいかなかった．手元にMacがないので詳しく調べることもできず）

jQueryから簡単に使えるようにしたプラグインを作ってみた．
http://www.mikage.to/jquery/jquery_history.html

とあるサイトに導入したけど，今のところ問題なく動作している模様．
これでSafariにも対応できたら完璧なんだけど，さすがにそのためだけにMacは買えないし・・・(^^;

Ajaxをやって最初にはまるのは，やっぱりキャッシュ問題．
IEでは，同じURLに対してリクエストすると，必ずキャッシュが返ってきてしまう．

サーバ上の特定のコンテンツを，更新があるかチェックしようとすると，時刻とかをURLの末尾に付けて，URLをユニークにしてあげる必要がある．
でも，そうしてしまうと，常に毎回コンテンツ全体を読み込んでしまって効率が悪い．

AjaxでもIf-Modified-Sinceが効けば良いんだけど，効かないようなので自前でやるしかなし．

調べてみると，すでに同じ事をやっている方がいた．
[Ajax tips] XMLHttpRequest と If-Modified-Since

prototype.jsのラッパも公開していたけど，これはファイルが無くなっている模様．

というわけで，記事の方を参考にさせてもらいつつ，jquery.js にパッチを当てた．
ただ，コンテンツ自体をキャッシュするとメモリを消費するので，その辺は変更して，コンテンツのキャッシュはしないようにしてみた．

また，IE，Operaは素直に動くのだけど，Firefoxはブラウザ側でキャッシュをしてくれるようで，サーバが304を帰しても，JavaScriptの方にはキャッシュされたコンテンツを200ステータスで返す模様．
記事の方は常に本体を返す形だから問題なかったんだろうけど，こちらのは変更なしならそれを知りたい．
そこで，Last-Modified時刻を比較して，判定するようにして回避．（完璧ではないけれど）

更新なしを知りたいのは，更新があったときだけ，highlight fade とかで目立たせたり，変更内容に関する処理を実行したい場合がありそうだったから．

で，パッチをMLになげてみたら，数時間でSVNにマージされた．早っ．
MLを見ていると，作者のJohnさん一人でかなりがんばっている模様．
それにしても対応が早い．．．

改良のペースが速いので，今後が楽しみ．

新Ajaxルーチンのデモは以下の場所に．
jqueryの最新のSVN版を使ってます．

http://pepper.sherry.jp/jquery/newajaxfunc.html

prototype.jsとかは，この辺は標準装備されていないので，標準装備したjquery.jsはちょっと有利？かも？

仕事でJavaScriptを使う際に色々ライブラリを見て，一番良さそうだったのがjQuery．
普段ほとんどJavaScriptは使わないのだけど，使い始めてみるとこれがなかなかおもしろい．

prototype.jsのように実績がいっぱいあるわけではないけど，やりたいことをコンパクトに書けるところが良い．
Perlも短くコードを書けるけど，それに似ているから好きなのかも．

その上，JavaScriptコードをHTMLの中に埋め込まなくて良いのが素敵．
CGIとHTMLを分離するように，HTMLの中でJavaScript部分とHTML部分をうまく分離できる．

AJAXで「Hello World!」

で紹介されていたサンプルを見ると激しく長いけど，jQueryなら1行だし．

■コードを分離しない場合

<script type="text/javascript">
　function sayHello(){
　　$("#result").load("helloworld.html");
　}
</script>

<body>
　<a href="javascript:sayHello();">Say Hello</a><br />
　<span id="result"></span>
</body>

■コードを分離する場合

<script language="JavaScript" type="text/javascript">
　$(document).ready(function(){
　　$("#hello").click(function(){
　　　$("#result").load("helloworld.html");
　　　return false;
　　});
　});
</script>

<body>
　<a href="" id="hello">Say Hello</a><br />
　<span id="result"></span>
</body>

KENT本＠bakelattaの日記をみて読んでみたくなったので購入．

感想としては思ったよりはまとも，という感じ．
特に初心者向けという点では，ほんとの基礎部分（FTPでのアップの仕方とかパーミッションとか）の説明がちゃんとかかれていたり，Windows上にテスト環境を作るための手順が細かく説明されているのは良い感じ．

上の日記で引用されていた部分を，もう少し前後を書くと，

Perlを使う人々は，想像力を十分に発揮できると感じます．そこに「表現の自由」があることを体感します．もし，他人が書いたPerlプログラムのコードを見て，残念なことにその未熟さを批判する人がいたとしたら，実は彼自身の方が未熟です．彼はPerlが何たるかを理解していないからです．Perlは初心者から熟練者までを幅広くカバーしています．初心者は初心者なりに，熟練者は熟練者なりにコードを書き連ねればいいだけです．Perlはそれに応えるだけの柔軟さを持った言語です．未熟なままを，それはそれとして認めるところにPerlの文化があります．私はPerlをそのように理解しています．

となってました．まぁ，ほぼほぼ同意．
ただ，書き方の問題はともかく，セキュリティだけはもうすこしちゃんとしてほしい，というところでしょうか．
その辺ができていないと，表現の自由，ではすまされなくなってしまいますので．

セキュリティに関しては，一番最後に説明があるものの，もう少し細かく説明してくれればなぁという感じ．
取り上げられている問題は
・強制ブラウジング
・ディレクトリ・リスティング
・クロスサイトスクリプティング
の３つだけです．
この本の中の例では，よくsendmailを起動する例なんかが出てきているのだけど，コマンド実行に関しては何にも無し．
例の中では引数にリクエスト内容を渡すものが無いので，そのままの記述なら安全だけれど，パイプ出力を使ってコマンドを実行する部分の説明にも，その辺の記述が一切無いので，少し他のことをやろうとしたときにはまりそうです．

ちなみに，対策について，のところは，

本書のサンプルプログラムでは対応していませんが，～～～

で始まっています．うーん(^^;

サンプルプログラムはしっかり対応しておいた上で，対策を紹介すべきなところだと思いますけどねぇ．
（でも，ぱっと見では，クロスサイトスクリプティング脆弱性とかはなさそうです．）

それから，最後の方で，入力した内容をメールで送るタイプのショッピングカートの例があります．
でも，SSLの話とかは全然でてこないあたりが・・・
掲示板とちがって，サンプルとしては取り上げない方がよかったのではないかと思ったり．

----

1階がKENTというより1階のKENT口がアレより

KENT本がたとえば文字コードをUTF-8にしたりせめてCGI.pmとか使ってくれるだけでも世の中に与える影響力はものすごいものがあるのに、Javaといえばアプレット的な説明を2006年にもなってしてる場合じゃないだろうと。

KENT本に対する反応を見ていると，モジュール使うべき，というのがよく出てきますが，これはKENT本の利用者層を考えると無理という感じが．
モジュールが便利か便利でないかとか以前の問題として，モジュールを使う環境がないからです．

わたしもちょっと普通のプロバイダで使えるCGIでも書いてみよう，と思って調べてみたのだけど，プロバイダから提供されるCGI環境が惨憺たる状況に・・・

http://www.futomi.com/ispinfo/isp.html

・シェルが使えないのは当たり前．（perl -MCPAN -e shell とか無理．XS使うモジュールも全滅）
・Perlバージョンが古い．（5.6が多い．5.8ならEncodeがあるのに．）
・BiglobeとかNiftyとかでは，Perlコアモジュールすらない！

この状況で，モジュール使おう，といくら主張しても無理でしょう．
せめてCGI.pmくらい使って，と言おうにも，それすら使えない環境で動かしているわけで．
一部といいにくい大きなところがそういうことをやってしまっているようです．なんだかなぁ．

まぁ，そう考えれば，フォームを自前デコードするのも致し方ないですね．
（CGI.pmを自分でアップして使う手もあるでしょうけど，
　CarpとかFile::Specとかに依存してるので，
　その辺の対応も考えると現実的ではなさそう）

プロバイダの環境がもう少しまともになればいいんですけどねぇ．
初心者にモジュールの便利さを説く前に，プロバイダをなんとかするか，代替手段を提供しないと，ステップアップは無理そう．

CGI.pmコンパチな動作をする CGI.pl を提供するとか．（requireすれば使えるような）