あーありがち

過去の日記 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ タブかスペースかって言うか Emacs か否かが気になる

自分はスペースです。

※ もうどこに TB したらいいのか分からないので送るのやめた。

Dan さんも「メールで patch」のネタで触れてるけど、エディタ以外の環境のことも考えるとスペースの方がいいなと思う。メール以外にもブラウザでコードを読める環境もたくさんあるし、そういう環境での再現性も考えるとタブじゃなくてスペースの方がいいんじゃないかと。

振り返ると自分も実は DOS/Windows 中心だったときはタブ派だった。タブ派の多くの人と同じように、タブの方がエディタの設定一つで見た目を変えられるから、自分の好みに合わせつつ共同作業するときにいいじゃんて思ってた。でも実際にはこれ意外とうまくいかないんですよ。これがどうにもうまく表現できなかったんだけど、上のようにエディタ以外の環境を含めてしまうと自分の中ではしっくりくる。スペースの方がより「安全」であると。

ただこう思えるようになったのは、「Emacs を使うようになったから」でもある。Emacs はその変態キーバインドで Windows 使いの人には恐らくすこぶる評判が悪いと思うが、自分が唯一「これはいいでしょ」と言えるのはスタイルの設定に従ったオートインデントの強制。

例えば Windows 用の一般的なエディタでは

function hoge() {
  if ( ) {
    ここ ←
  }
}

「ここ」の部分にカーソルを合わせるためには、中身がスペースかタブコードかによらず、行頭でタブキーを2回押すという動作が必要になる。オートインデントを on にするとその上の行の { のうしろで改行した瞬間に「ここ」にきてくれるが、デフォルトではタブキー2回という動作が必要な場合がほとんど。しかし Emacs ではタブキーを1回押すと「ここ」にきてくれる。*1

まず、タブキーはタブコードを入力するためのキーではない*2。設定されたインデントの位置までスペースあるいはタブを埋めてくれるキーなのである。これがものすごく嬉しかった。

例えば上のコードをまったくインデントせずに書いても、あとから各行で（その桁位置を気にすることなく）どかどかとタブキーを押していくだけで上のインデントは再現できるのである。そしてこの機能は当然コードの解析をもとにしているので、必要以上にタブキーを押してもスペースやタブが入りすぎることはないし、どこかで { } や ( ) の対応が壊れていたらインデントが正しく再現されない。つまり、何の気なしにタブキーを押すだけで typo に気づけるのである。（とりあえずカッコ系の対応だけね。）

言い換えると、Windows の普通のエディタを使っている人たちが思っているより、Emacs ではスペースでインデントするのがものすごく楽なのだ。たぶんこの便利さを知らないとスペース派の言い分はなかなか理解できないんじゃないかと思う。というかこの機能のないエディタでスペース派の人っているんだろうか。それくらい自分の中では Emacs を使うこととスペースを使うことは切り離せなくなってしまっている。*3

まとめ

• スペースの方がエディタや IDE 以外の環境を考えたときに安全だし、自分はスペースの方が好みである
• Emacs の場合はタブであるかスペースであるかに関わらず、インデントに関しては超楽ちんである。だからタブ派だった自分が何の不便もなくスペース派に移行できてしまった。
  • 他のエディタや IDE の場合はどうなんだろう？

まぁタブでも問題が起きない環境に限定されているのであれば、幅さえ決めてくれれば従いますけどね。従うのはエディタの仕事だし:-) それよりエディタウィンドウの幅は 80 までで制限してほしいな。日本語の文章でもなんでもそうだけど、一行が長すぎると読みにくい。一行の長さが「場合によって」80 を越えるってのは別にいいんだけど、130 前提とかで長ーいのを書かれるとつらい。

関連リンク

• Charsbar::Note - タブとスペースの話
• 404 Blog Not Found:タブのスペース化はタブ幅よりも重要である

_ <pre>と改行コード

ふとした疑問。

<pre> の中の改行コードの扱いってどうなってんの？

結果。

cr も lf も crlf も等しく一つの改行になる。cr のあとに lf 以外の文字がきた場合は cr だけで改行、lf がきたら crlf のセットで改行。つまりどれでもいいよ、と。

試したのは Firefox 1.5(OSX), MacIE 5.2, Safari 1.3, Opera 8.5(OSX), IE 6(Win) たぶんみんなこういう挙動するようになってんだろな。

_ prototype.js で Ajax してみた

※ このエントリはすぐ使えるサンプルを提供することを目的としていません。自分の試行錯誤を記録しているだけです。PHP と JavaScript をまーだいたい分かっている人間が実際に Ajax を書く際にうまくいかなかった点の実例としてご覧下さい。

まとまった情報を紙でほしかったので WEB+DB Press Vol.31 を Amazon のマーケットプレイスで購入して GW の宿題としてチャレンジ。とは言っても事前に @IT とかあれこれ情報は手に入れてるのでこの特集だけの知識で書いたわけじゃない。

しかし、思ったより難しいなっていうのが感想。

まず XMLHttpRequest そのものの理解がいまいち足りてない。つかいつも思うが JavaScript って調べにくいったらありゃしない。Ecma262 の部分はよくまとまってるんだけどな。どうにか作ったあとにつらつら見てたら

Dynamic HTML and XML: The XMLHttpRequest Object

これはコンパクトで見やすかった。こういう概観できるページってなんであんまないんだろ。

あとやっぱ prototype.js ドキュメント足りなすぎ。ほんとに便利な機能が入ってるのに、いちいち中身見なきゃ存在が分からないのはちょっと勘弁してほしい。

で、何を作ったかっていうと

24 ways: Edit-in-Place with Ajax

こんなやつ。イメージとしては del.icio.us の編集部分。

1. サーバ上に一つファイルを用意して、onLoad でその内容を受け取る*1
2. その部分をダブルクリックしたらそのテキストを編集する画面を出す
3. 編集結果を save ボタンで送信してそのファイルに保存する
4. cancel したら編集内容をすべて破棄して元に戻す

ま、これ作るだけならトライ＆エラーでなんとかなる。escape() 使わないで encodeURI() にしてくれってところさえ気をつければほとんどコピペだし。*2

もともと JavaScript が HTTP クライアントになるだけっていうのはイメージついてたので、やっぱり気になるのは

JavaScript からのアクセスでない場合の対処が必要じゃん？

ってところ。prototype.js は HTTP リクエストヘッダにサインを入れてくれるけど、同じものを入れた普通のブラウザからのリクエストとはもう区別つかないわけでしょ？ JavaScript からのリクエストに対して XML や JSON やプレーンテキストなどの断片の情報が返るのはアリだけど、普通にブラウザでアクセスした場合どうする、ってのを考えなきゃまずいんじゃないかなぁ。誰もいたずらしないならいいけど。

そうすっとやっぱ session とか URL の設計とかって話になると思うんだけど、そういう参考になる記事って全然見ない。まぁあんまり現実に即しすぎてても面白くはないんだろうけど。あと、

「アプリケーション」じゃなくて「サイト」には適用しにくい

これ、実は最近ずっと感じていることなんだけど、世のフレームワークってほぼ全部「アプリケーション」を指向している。当然「プログラマ」から見ると Web というプラットフォームで動くアプリケーションなんだろうけど、その考え方だけではサイトとしてイマイチ。

JavaScript は geek の間では復権しているかもしれないが、セキュリティ上の問題で普段 off にしてるって人も一定程度いるだろうし、何より 「JavaScript が使えないと情報が手に入らない」という状況はユーザビリティ的にも SEO 的にもまずい。そうするとどこでどう使うかをよく考える必要がある。ま、楽しみを残してもらってるとも言えるけど。

リクエストヘッダの Accept に JavaScript 関係の情報が載れば便利なのになぁ。JavaScript が有効だったら JavaScript 用の情報を返す、そうでない場合は HTML を返すってのをクライアントサイドの JavaScript を使わずに判別できれば、JavaScript 用の分と <noscript> の分と両方返す必要がなくなる。どーーーにかうまいこといかんかなぁ、この辺。

今度は MochiKit 使ってみるかな。prototype.js だけだとバグ見つけにくい気がする。あと、当たり前だけどいくら prototype.js 使ってもイベントハンドラをセットする際の制限とか超えることはできない。prototype.js 使えば楽ちん！て思えるのは prototype.js 以前の苦労を知ってこそだなと思った。

成否の判定と PHP の error_reporting()

[2006-05-05 追記]

読み出し、更新についてわざと失敗させ*3、それへの対応を作り込んでみた。ちなみに今回はライブラリは prototype.js のみ利用し、PHP 側は何も利用せずに全部手で書いて済ませた。便利なフレームワークを使えば PHP 側と JavaScript 側、という風に分けて考える必要はないかもしれないのだけれど、とりあえず練習ってことで。

で、失敗させてるんだけど、いつまで経っても失敗したときの status が返ってこない。*4ブラウザ上では何が起きているのかさっぱり分からないのでサーバ側で簡単なログを吐く仕組みを用意し、狙ったメソッドに処理が移っているのかどうかを確認。うむ、確かに失敗している。でも livehttpheaders で確認すると 200 OK が返ってきている。あ、そうか。error が 200 OK の HTML で返っちゃってるんだ。うーむさすが PHP. てことは Ajax 作り込むときはテスト環境であっても PHP の error は全部 log に吐くようにしないとダメなんだな。

で、実際に読み出しに失敗させてみると、読み込む領域に「最初からは」編集可能ですよと目で分かるスタイルは設定しない方がよいことに気づいた。

どういうことかというと、

.editable {
  border: 1px solid #fefefe;
}
.editable:hover {
  border: 1px solid yellow;
}

こんな風に編集可能な領域はマウスカーソルを合わせると border に色がつくようにしておいたんだけど、このままだと内容がなくてもこの上をマウスが通過すると色が変わる。これはまずいので、読み出しのリクエストのときにこうしてみた。

$('box').setAttribute( 'class', 'editable' );
Event.observe( 'box',
               'dblclick',
               function() { make_editable($('box')) },
               false );

これを request の option の onSuccess にセットする*5。つまり

1. 読み出しが成功したら
2. 編集可能な領域であることを示すスタイルを追加し、
3. 編集モードにスイッチするためのイベントをセットする

box ってのは今回試しに用意しておいた、ここに編集可能な内容が入りますよっていう目印の div 要素。これはついでに

$('box').setAttribute( 'title', 'ダブルクリックすると編集できます。' );

こんな風にしておくと親切かなと思った。マウスが合ったときにここは編集できますよと教えてくれる。色が変わるだけだと意味が分からないもんね。

次、書き込みの失敗。書き込み時は

1. 内容を送る前に見た目上は編集結果が反映される
2. 成功したら黙ってそれが定着する
3. 失敗したら
   1. 「失敗した！」ってメッセージを出して
   2. 送信前の編集状態に戻す

という処理にしてみた。このためには

• 編集用の textarea
• 通常の HTML として内容を表示
• 更新に失敗した！ってメッセージ

の3つの表示を切り替える必要がある*6。ここで上の edit-in-place のサンプルを読みながら感心したことは、

JavaScript で HTML を書き換えるときは DOM を変数として扱っちゃえばいいんだ

ってこと。生の JavaScript で書いていたときはこの感覚に至ることはできなかったけど、prototype.js のおかげで

Element.show( ID )
Element.hide( ID )
Element.remove( ID )
new Insertion.After( ID, 内容 )

などの超便利な書き方ができると、内容を変数に持つんじゃなくて、DOM そのものが変数なのねという心境になってくる。あーこれはものすごい楽だ。面白いぞ JavaScript.

ちなみに今回

1. 編集に失敗した！ってメッセージを出し、
2. ちょっと経ってから
3. 編集画面に戻る

という処理をするためにどうしても sleep() がほしくなり、あちこち探しまわったが汎用の sleep() で使いたくなるものがなかったんだけど、これは

var failure_notice = '<div id="' + obj.id + '-failure">失敗しますた！</div>';
Element.hide( obj );
new Insertion.After( obj.id, failure_notice ); // メッセージを表示
setTimeout( function() {
  Element.show( obj.id + '-edit' );            // 編集画面を表示
  Element.hide( obj.id + '-failure' );         // メッセージを消去
}, 1500 );

こんな書き方ができることに気がついた。更新に失敗したら

1. 今まで表示してた内容を消して
2. 失敗しましたってメッセージを Insertion.After で作り、
3. 1.5秒後に編集画面を on にしてメッセージを消す

sleep() 要らない。無名関数最強すぎ。

参考

• Hawk's W3 Laboratory : XML : XMLHttpRequestについて
• JavaScriptにおけるURLエンコードの処理

_ FreeBSD(98) 2.1.0R 入門キット

CD を整理してたら FreeBSD入門キットが出てきた。中身は FreeBSD(98) 2.1.0R. たぶんこれが初めてのやつだな。

でも捨てちまおう(酷

Amazon で調べると 2.1.0 が入ってるのは恐らく 95年か 96年のもの。でも自分が初めて入れたのはたぶん 97年なんだよな。まだのんびりしてた時代なのね。

※ CPAN の CD とか Prime Time Freeware の CD とか出てくるなぁ…。「筆入れのバックアップ」が出てきたよ。すごいぞ、昔のおれ。

_ あれこれアップデート

• Apache 2.0.58 にいきなり気がついた
  • この間まで 2.0.55 じゃなかった？
• zsh 4.3.2
  • いい。euc-jp でも日本語ファイル名が文字化けしない

_ Mail_mimeDecode でアドレス消えませんか？

[2006-05-08 追記]以下、めっちゃガセでした。htmlspecialchars してなかったから消えたように見えただけでした。ごめんなさいごめんなさいごめんなさい。たまに PHP の出力をブラウザで見ていることを忘れてしまうのです。もーしわけないっ。

PEAR :: Package :: Mail_mimeDecode

を試してみたけど、なんか

From: nickname <address>

の <address> の部分が消えちゃうぞ？ みんなこれ使ってないの？

確認した環境。

decode_headers が true でも false でも消えるんだけど、中身まで追いかけてないのでマルチバイト拡張の有無が関係するかどうかとか、ちょっと分からない。

※ ->decode() した結果の配列を print_r() して確認した。

_ 片付け

カタログとか取説とか保証書とかいっぱい出てきた。とりあえずなんかあったときの連絡先とかっていう意味で取ってあったんだな。

大きめの封筒がいっぱい。これはあれだな。封筒でカタマリを作って通信記録とか書類とかまてめてたんだな。今そういうの自分ちには全然必要ないから無意味にかさばる封筒がたくさんになってしまった。

使いかけの履歴書もいっぱい出てきた。うーん。

2000年頃のものも出てきた。いろいろ捨てた。こうして考えるとずいぶん経ってんだなぁ。

_ ラジオ日和

山下達郎は本当にいいな。絶対番組 DVD（Super Audio）を出すべきだと思うんだけどどうだろう。

あ、安部礼司

初めて知った。なんかゴールデンウィークスペシャルでものすごい 80年代セレクトが炸裂してる…。本当に今80年代って流行ってるんだなぁ。どんぴしゃすぎて何が流れても大笑いしてしまう。

_ 知らないことばがいくつか

fancyURL, magicalURL

[49] FancyURLとMagicalURLモードで複数blog運用

scaffold

Lost-Season: Rails、CatalystのScaffoldを比較

magicalURL はともかく、fancyURL って Nucleus 用語？ 少なくとも Nucleus 界隈発祥のように見えるんだけど、どうなんだろ。fancyurl.com っていうサービスもあるけど、そっちが先か？

scaffold はあれか。skelton とかそんな感じの言葉に置き換え可能なものかな？

_ onLoading が変？

先日書いた Ajax のテスト を得意げに動かそうとしたら…。

Windows 版 Firefox で動かねぇ！ えー。Safari で動かないのは確認してたけど。

見たらどうも Ajax の request を投げる際の options の onLoading でセットしたものが Complete したあとに復活してる！ どういうこっちゃ。Windows IE, Windows Firefox 1.0.7/1.5.0.3, Safari 1.3 が同じ挙動。Mac Opera 8.5x, Mac Firefox 1.5.x は狙い通り動いている。

あと Safari 1.3 で dblclick が拾えないなぁ。Javascript - Event compatibility tables によると拾えるはずだし、ここのテストページではちゃんと動いてるんだけどな。

まぁとりあえず dblclick はあんまりよくないかなぁと思って使わないようにすればいいやっていうのと、onLoading に書く処理を Ajax request そのものの前に書いて、onLoading を消したら狙い通り動いた。

ここに書く
var options = {
  onLoading: function() {
    ここに書くのはやめる
  }
}
new Ajax.Request( URL, options );

うーん、そういうもんなのか。そういうもんなのか？

_ apache bench 1.3 って connection 数が正確じゃないのね

負荷テストに apache bench を使ってみた。今まではあんまり厳密にやったことなかったんだけど、ふとカウンタを作って数えてみた。

数が合わない。

厳密には concurrency の数を上げていくとずれてくる。例えば

ab -n 100 -c 10 URL

ってやるとレポートには

Concurrency Level:      10
Time taken for tests:   1.714 seconds
Complete requests:      100
Failed requests:        0

てな具合に100回アクセスしましたよと出るのに、実際の connection 数が 108 だったり 110 だったりする。

ただし、この現象は apache bench 2.x では起きない。確認したのは以下のもの。

サーバは Apache 1.3 だろうと 2.0 だろうと影響ない。単純に ab の問題。

'general/6129: AB gives fake failed connections' - MARC

を見ると 2000年にも似たような話が確認されている。もう Apache 1.3 系のものはその程度のものとして諦めておくのがいいのかな？ まぁ実際のテストでは数が合おうが合うまいがだから何？ってことの方が多いんだろうけど。

_ CHM ファイルのタブビュワーってないのか、あるいは CHM ファイルなんかきらいだ

CHMファイルあるじゃないですか、CHMファイル。Webサイトを丸ごと固めたみたいな一つのファイルのことで、これは通常のブラウザではなく専用のビュワーを使って閲覧するのがセオリーです。（Windows の場合は中身は IE エンジンだけど。）

しかし、タブブラウザに慣れた今、これがすげー使いにくい。

特に CHM ファイルってたいがい何かのマニュアルだったりリファレンスだったりするので、要するに調べものなわけですよ。なのに見ていたいページ（だいたい何かの用語などの説明）を開きっぱなしにできないわけ。

これチョー不便。

「じゃあ CHM ファイルを HTML にバラして普通にタブブラウザで見りゃいいじゃん」て思うでしょ？ やりましたよ。

ナビゲーションがグダグダでとても使いものにならない

わけですよ。すべての CHM ファイルがそうなのかは知りませんが。

なんつーか、幅は利かせてるけど気の利かないやつだな、これ。

_ 辞書サーバあったら便利かなぁ

と、不定期に思いつくんだけど面倒くさくて放置になってる。辞書サーバがほしいのは

• CD とか DVD とかメディアに縛られるのはいや
  • 別に買うのがいやっていうわけじゃない
• goo とか infoseek とか Google とか使うけど、やっぱインターネット接続って速くないし、辞書はみんなが使うせいか反応がよくない
  • 自分のサーバに放り込んでおけば LAN でサクサクだぜー
• 自分サーバなら自分で辞書データ選べて嬉しいぜー

という辺りが理由。サーバというからには当然 TCP/IP 越しに辞書データが検索、閲覧できることを想定している。

今はフリーで公開されていた当時の英辞郎データを後生大事に使い回してるんだけど、これだと英和しか引けない*1。和英は全文検索でなんとかなるけど英英とか引けないし、当然国語辞典にもならない。

で、何が面倒くさくて放置になっているのかというと、

• そもそもイマドキの電子辞書形式が分からない
  • まだ EPWING でいいの？ そこで知識止まってるんだけど、もう古くない？
• クライアント/サーバで動く辞書ソフトを調べてない
• つかネットワーク越しに使うことについてライセンス的にはどうなってるんだろう？
  • 個人利用は ok ? 複数人で共用は？

一台のクライアントマシンで使うだけなら、仮想CDのソフトと辞書のビュワーだけでいいんだろうけど、

それじゃ面白くないんだよな、なんとなく。

[2006-05-13 追記]

• Motoyuki Kasahara's Home Page

ndtp という情報が先に引っかかったが、最近は eb ライブラリ + (ebnetd | ndtpd | httpd) な感じっぽい。いやーここはなんでも揃ってるな、と思ったら以前 cvs proxy 調べてたどりついたページだった*2。

ndtp クライアントは Mac なら iDictionary.app がいいか？ Windows ネイティブは見つからないなぁ。CLI だったら結構いろんなものがある。EBView は GTk+ でよさげなんだけど、これはネットワークには対応してなさそう。ふむ。面倒なので Jamming *3 にしようかとか思い始めていたけど、ちょっとやる気出てきたかも。データは FreePWING による各種辞書 を見ると結構いろんなものが活かせそうだし。

参考

UNIXで電子辞書をしゃぶりつくそう

情報量が多すぎてあんまり見てない(^^;んだけど、たぶん一通りの情報は全部揃ってるんじゃないかな。EBNETD の方も詳しいマニュアルがあるのであとは辞書があればよさげな気がしてきた。

_ 思いっきり反対向いてるなorz

※ まぁ世の中のメジャーな方向は向いていない自覚あるけど:-P

CHM ファイルとそのビュワーが使いにくいって話を書いた途端に

HTML Helpを使おう

textfile.org では逆に HTML Help の情報が…。

そりゃー検索もできるしファイルがバラつかないって意味ではいいと思うよ。でもさぁ、タブ開けないとなぁ。みんな調べものでこそ思いっきりタブ使うでしょ？ 使わないの？

おれだけなんか変な勘違いしてんの？

_ ports の PHP がまた変わった

今度は CLI, CGI, mod_php が同居できるようになった。便利便利。

_ 英辞郎買った

サーバうんぬん言ってたんだけど、とりあえず辞書データそのもののアップデートもしたかったし、調べていくうちに買いたい辞書だけで結構な値段になりそうだったので、はやる気持ちを抑えるためにも英辞郎を買った。

手元の辞書が v.54 で最新版が v.94 なので差はかなりでかい。和英にいたっては 32 で止まっていたうえに古くて捨ててしまったので和英が一瞬で引ける快感を得たのは実は数年ぶり。いいなぁ。金のない時代の習性が染み付いてたおかげでたかが2000円の買い物をケチって不便な思いをしていたのか。あほだな > おれ

これで英英と日本語が引ければ…ってことで最初に戻るのか。でも英和の値段をとりあえずケチれるぞ。（けっきょく貧乏性。）

_ jsUnit ってよくできてるなぁ

※ サイトが移転して独自ドメインになってる

JScript + WSH のテストができないし困ったもんだと思っていたんだけど、考えたら WSH 独自の処理なんてそんなに多いわけじゃないし、極力 ecma262 の部分と JScript + WSH の部分を分離して、ecma262 の部分を jsunit でテストできるようにしようと思い始めて作業している。

で、実際に jsunit を使ってテストを書くわけだけど、これが細かいところでよく考えられてて感動したのでメモ。ごく当然のことなのかもしれないけど、

file: // でアクセスしたときと http: // でアクセスしたときで、testRunner.html へのテストケースの在り処の教え方が違う。

という点である。

二つの画像を比べてほしいのだが、テストを実行したいファイルを指定する部分が異なる。これはそれぞれサーバ上の testRunner.html にアクセスした場合と、ローカルの testRunner.html にアクセスしたときのスクリーンショットである。

サーバ上の testRunner.html にアクセスした場合は HTTP でアクセスする（恐らく testRunner が置いてあるのと同じサーバにある）テストスクリプトを指定するようになっており、ローカルの testRunner.html にアクセスした場合は input type="file" によるファイル選択フォームが現れ、ローカルのファイルを選択できるようになっている。つまり、スクリプトの記述をサーバでやろうがローカルでやろうが、そこに jsunit があればどちらでも同じようにテストできるということである。

賢い。

また、何かを目視で確認したいという場合は jsUnitCore.js に定義されている warn(), info(), debug() を使うとよい。ここに書かれたメッセージは Trace level を上げるとポップアップウィンドウに表示されるようになる。

Trace level はデフォルトでは no tracing になっているが、warn, info, debug を選ぶことができ、それぞれ先に挙げたメソッドに対応している。確認はしていないけど一対一対応じゃなく、当然しきい値として働くはず。普段は warn に合わせて本当にチェックしなければいけない情報だけ、より深く動作を追いかけたい場合は debug に合わせて細かい情報まで出力させる、という使い方をする。

[2006-05-18 追記]試してない*1けど、eclipse plugin まであるのね。すげーな。

注意

[2006-07-13 追記]

jsUnit を動かす時は絶対に cache を無効にすること。testRunner.html をどんだけスーパーリロードしてもダメ。

参考

Javascript/JsUnit - Bobchin's Wiki

_ MacBook 13" びみょー

アップル、“MacBook”を発表 (/.-j)

ほんとに小さいの作る気ないんだなぁ。

ポリカーボネートの質感、そしてそのうえに載ったキーボードの質感が納得できずに iBook は見送った経緯があるので、もう今度から 12", 13" ディスプレイサイズの OSX マシンは手に入れようがなくなってきたなぁ。テカテカ液晶も好きじゃないしー。今回のモデルチェンジで質感が急によくなってれば話は別だけどもなぁ。Windows もあんまり使いたくないけど、ノートはプロプラ OS の方が断然安心して使えるし…。

[2006-05-18 追記]

ITmedia +D PCUPdate：MacBookに触ってきた！ (1/2)

VAIO の安物とか昔の MSX なんかにこの形のキーボードあったな…。はっきり言ってやだこれ。

_ JSDoc 1.9.9.2 を使ってみて大事だなと思ったこと

JSDoc をやっと真面目に使ってみた。実際に使ってみてハマったところを取り上げていく。基本的な使い方は自分で調べるなり試行錯誤するべし。

なお、以下はバージョン 1.9.9.2 について書いている。時間の経過とともにおかしな内容になっていく可能性大なので注意されたし。あと日本語のコメントは試してないんでどうなるか知らない。

正しく書く

値を取る attribute で値を書いてない*1など、構文的に正しくないときに、よく HTML::Template の方でエラーを吐いて止まる。phpDocumentor みたいにエラーレポートは作ってくれないし、HTML::Template 段階でのエラーってことは当然パーサが吐いてるわけはなく、どこの何の記述（あるいは記述不足）がエラーなのかさっぱり分からないので、あとでまとめてドキュメントを生成するのではなく、こまめに作るようにした方がよさげ。

書き方は JSDoc のサイトにもあるけど、細かいものは JavaDoc のものを探してくるといい感じかも。

コンストラクタの書き方

きちっと対応しているのは

function Object() {
  ..
}

のみっぽい。

var Object = new function() {
  return function() {
  };
};

はコンストラクタは解釈できるが、中のメンバ変数（JSDoc の出力では Field ってやつ）が解釈できなかった。

あとこのコンストラクタ関数のコメントの中に @constructor を書いておいた方がよい。書かないと Field の解釈に失敗しやすいみたい。

フィールド（メンバ変数）の書き方

JavaScript 的には単にコンストラクタで初期化されるプロパティなんだと思うんだけど、まぁ要するに

function Constructor() {
  this.prop1 = 'foo';
  this.prop2 = undefind;
  this.prop3;
}

のところ。中身のない状態で初期化するのは 3 ではなく 2 の方法、つまり明示的に undefined をセットする方法が正しい。JSDoc 的には。

明示してないものは Field Summary にも当然 Field Detail にも現れない。

メソッドにも @type を

@return に型を書いてもメソッドの型としては認識してくれない。ちょっと面倒だけど、

/**
 * @type   boolean
 * @return boolean
 */
method: function() {
}

にしないといけない。まぁ気にしなきゃいいって話もあるかもしんないけど、それだと Method Summary のところで戻り値の型が分からないのよね。

うっかり : が書けない。

/**
 * summary
 *
 * detail: foo bar hoge
 */
method: function() {
}

てなことをすると

detail: foo

の部分が

Class.prototype.detail = foo;

に展開され、結果として

Class.prototype.detail = foo;bar hoge

になる。

※ ただ、必ずなるかというとそうでない場合もある。よく分からん。

組み込みオブジェクトの拡張には @addon

@member を書くと二重に出力されるのでうざい。例えば以下のような感じ。

/**
 * @addon
 */
Array.prototype.include = function() {
}

ただ、ないとエラーになっていたような気がしていたのに、なくてもそのまま通ったりもする。あっれ？

メソッドの書き方

できないと思っていたが、

Class.prototype = {
  method: function() {
  }
}

の書き方も

Class.prototype.method = function() {
}

の書き方も両方いけた。

夜中は嘘書いてごめんなさい。

感想として

JavaScript の構文解釈の精度は意外と悪くないと言ったら失礼だけど、自分の書き方だとほぼ思った通りに解釈してくれる。ただそのうえでコメントの記述がその後押しをしていて、正しくコメント付けするとよりよいドキュメントが生成できる、という感じ。まぁコメント付けは正しい方がいいのは言うまでもないことなんだけど、phpDocumentor のエラーレポートみたいなものは期待できないので、若干人間の側の負荷が高いかなって気はする。

あと、こまめにドキュメント生成しろって辺りか。複数のファイルを一気に処理するとどこでおかしなことになってるのかなかなか分からないんで。

最後に、これは使えると思う。

_ 英辞郎 94 -> EPWING の変換ができない

FreePWING による各種辞書 にある英辞郎データの変換スクリプトがうまく使えない。具体的には ' で止まる。

パーサ見なきゃいかんのかなぁ。まぁわざわざ英辞郎を EPWING にする人なんてあんまりいないんだろうけどねぇ。

_ ありがとうを言いたいblogというのはめったにない

いや、いろんな情報やネタや資料を提供してくれるという意味では多くのサイトに対して感謝しているし感謝しなければいけないのだろうとは思うのだけれど、自分は結城さんのようにデキてないから感謝を自覚することなんてめったにないのだ。

しかし、「おれか？おれが書いているのか？」と思うほど*1痛快なエントリが連発される「雑種路線でいこう」には本当に本当に感謝したい。

ほっとくとすべてのエントリを del.icio.us に放り込みそうになるので思い切って今後は何もしないと決意をする代わりに、ここにエントリを起こそう。

ありがとうございます。これからも多くの刺激を勝手に受けていきます。できればしばらくは書き続けてくださいな。

_ Windows用 JammingDicTools がメモリを食いつぶして終了

複数の辞書を一つのツールでいっぺんに検索できるのは便利なので Jamming を買ってみた。（Win/Mac 両方。）これで EPWING も英辞郎もみんな扱える。 *1で、英辞郎 94 のデータを Jamming 形式に変換してみた。

結果、

• インデックスがないと遅くて使いものにならない
• 専用とは言え、英辞郎ビューア*2はテキストデータの検索なのにかなり速くてステキ

てなことが分かった。

しかしこの変換が曲者で、

• OSX版では変換、インデックス作成とも正常に完了する。
• しかしこのインデックスは Mac 専用なので Windows では使えない。
• それではと Windows版の JammingDicTools を使うが、変換はできてもインデックスの生成ではメモリを食いつぶして終了してしまう。

つまり現時点では Windows では Jamming で英辞郎データは使いものにならない。

開発ツールがタコなのか OS がタコなのかツクリがアレなのか分からないけど、とりあえず報告しとこう。

_ prototype.js が MacIE でコンパイルエラー

うーん。一部機能が利用できませんとか言うならいいんだけど、コンパイルエラーじゃ対処のしようがない。

ちょっとの修正で動くという話もあるんだけど、具体的な方法が分からないorz

MochiKit も試してみたけどやっぱダメ。コンパイルエラーっつーのは困るなぁ。はてなとかどうやって対処してんだろ。とりあえずこれも急ぎじゃないので置いとく。

試しに iCab 3 beta を動かしてみたら Classic 版でも OSX 版でもコンパイルエラーは起きない。XMLHttpRequest には対応してないっぽいけど、DOM の操作とかは普通にできた。ただし CSS の解釈にあやしいところがまだある感じ。上のカレンダーのポップアップのポジショニングは明らかにおかしい。しかし Classic版より OSX版の方がバシバシ落ちるっつーのはどうかなぁ…。

Classic をあえて選ぶ人はもうみんな IE 捨ててiCab に乗り換えてくれって言った方がいいのか？ まぁ恐らく通用しないんだろうけど、でもあれだ。正直、なんか懐かしくてかわいいらしい感じはするね。

_ cmd.exe を捨てて ckw.exe へ

Windows 以外も使う人が Windows を使うときに cmd.exe の存在は若干問題になるなぁと思う出来事があった。で、今回はこれを機会に自分の使う範囲内では cmd.exe をやめて ckw.exe にしようかなと思ったという話。

この ckw は以前も触れたことのある terminal emulator ck の別バージョンで、cmd.exe 互換なんだけどウィンドウの外観だけ違う程度のものだと思うと分かりやすい。実際、euc-jp なんかは表示できない。

で、今回の話、いったい何が理由かというと、

cmd.exe のウィンドウでは IME ツールバーが機能しない

というのが発端。cmd.exe ではウィンドウ内で IME が機能するようにできているためで、こうなると何が困るってマウスで IME を ON/OFF させることができない。そんなの別にいいじゃんて思うかもしれないけど、リモートでの作業やバーチャルマシン上の作業の場合はマウスで操作できると便利なことがあるのだ。

リモートでの作業やバーチャルマシン上の作業の場合、IME の ON/OFF などのキーコンビネーションをローカルの実機と異なる状態にしておくことがある。これは意図しない機械に命令が影響しないようにするための工夫でもあるけれど、例えば Mac から Windows を操作する場合は Windows の標準のキーコンビネーションを Mac のキーボードで再現できなかったりするので、必然的に「割り当て」を行う必要がある。

これがそもそも面倒くさい。つかどのキーに割り当てたのか忘れちゃう。

だからマウスで操作できると嬉しい。それと、

cmd.exe 内で動く IME には Windows 全体のキーコンビネーションの設定が効かない。

例えば X 使いの人が shift + space に IME の ON/OFF を割り当てていても、cmd.exe 内では標準の [全角/半角] を押さないといけない。これは面白くない。

ということで ckw.exe

これを使っても特別何が便利ということはない。ウィンドウの外観の設定やコピペの動作が標準と違うってだけで、特別な機能は付加されていない。それでも、

cmd.exe と違って通常のウィンドウである

というアドバンテージがある。通常のウィンドウなので IME ツールバーが他のアプリと同じように機能する。これが、大きかった。

_ 乳剤なくなったらほんとにアウトだもんな

キヤノンも銀塩カメラ開発停止か？ (/.-j)

35mm については銀塩はあんまり期待してないんですよ。現役で銀塩写真撮ってた時期からいずれ消えるなとは思ってたんで。ただフィルムや印画紙といった乳剤そのものの供給がかなり厳しくなってるんで、そのうち「カメラをはじめ機材は手に入るけど何もできない」という状況になっちゃうんだよな。カメラは中古でどうにでもなるけど、乳剤は生ものだから中古ってあり得ないし。そのうち「ビンテージ乳剤を使った半世紀ぶりの銀塩写真」とかいうよく分からない作品とか出てくるのかな？ やだなぁ。困ったなぁ。

おれデジタルで写真楽しめるかなぁ？ 不安だ。モノクロ派としてはやっぱ乳剤の力は圧倒的だもの。

※ このあと私はデジカメとろいし電池食うし値段の割にたいした描写力ねーしうざいんだよな、と暴言を吐いたのだった。駆逐するなら凌駕してくれ、頼む。

_ Yahoo だからなのか Yahoo さえもなのか

Yahoo.com のトップページのレイアウトが変わったんですね。しかも横幅が固定で広がって。なんつーかもう、幅固定ってなんでこんなことしたいの？ なんで Web デザイナはみんな画面サイズが大きくなったら当然ウィンドウサイズも大きくなってるものと決めてかかってくるの？ なんで？ さらに情報量増やしたいからフォントサイズも小さくしてさ。もうこういうのやめにしようよ。見にくいし使いにくいって。

_ Tiger の Mail.app うぜぇ

自分で使う気はないんだけどデフォルトの設定が変じゃねーか？と思って調べるために立ち上げてみた。ウィザード形式でアカウントの設定ができないと通常のウィンドウを拝むことすらできねぇ。それ自体はすげーいやだけど Outlook Express でもお馴染みの方法。問題は途中途中でいちいち設定したサーバに接続にいって丁寧に確認しくさりやがってくださること。

遅いんだよ！

なんだこれ。なんでこう前より悪くするソフトが次々出てくるんだ。

今日はですますで始まったのに一気に「うぜぇ」まで気分が変わってしまいましたとさ。あーやだやだ。

_ 家計簿期待晒し上げ

※ 晒し上げっていうか、向こうの方が人気blogなんだけど。

家計簿が欲しい！ - てくのーと Splash☆Star

JavaScript が有効ならできるだけストレスなく操作でき、かつ w3m でも編集できるとチョー嬉しいです。あと Rails 依存はやだな。

MoBo でつけてたんだけど、全角半角の処理が不親切とか編集が月全体になって重たいとかで挫折したもんで、別な実装におおいに期待するところなのでありました。

MoBo を直す気はあったんだけど、どうしても優先順位が低くなっちゃうのと、本家 commit までの道のりがどーも遠く感じるので結局何もしてないですが。

_ 今さら収納に頭を使う

収納グッズを手に入れた。

上はナチュラルケース ヨコ型ハーフワイド NATU-Cで、なんか財布だの携帯だのをあまり考えずにつっこむところ。日用品をとりあえず散らばらないようにするために使う。こういうのはなんて名前なのかよく分からなくて結構調べにくい。自分の中ではカゴとかって感じになるんだけど、そういうカテゴリってフツーないよね。ケースってカテゴリで片っ端から見ていかないとなかなかちょうどいいのが見つからない。

下はCOKAGU レターケース FUBAKO-YOKO 文箱-横 BX-008-dで、二段あるのでどちらかを処理の必要な書類や請求書、もう一方を領収書だのの一時保管に使う。*1レターケースっていうのね、こういうの。A4 がちょうど収まるけど大きすぎず重くもない。なかなかいい感じ。

あんまりこういう「浮かない」レターケースってないんですよね。事務用品だと普通の家具にはまず合わないし、プラスチックのものはカラーボードとかメタリックなラックにはあんまり違和感ないかもしれないけど、チェストとか木の家具には合わない。あとおしゃれなやつもそうだけど、家具に傷がつきやすそうな作りになってることがある*2とか、大きすぎるとか、意外と選ぶの大変。*3

こういうの、前からほしかったんだけど以前は腰よりちょっと高いくらいの棚がなくて、収まりのいい場所がなかったんで放置しまくりでテーブルがものすごいことになってた。これでやっとテーブルの上のものが少し減らせる。

いやーストレージの設計って難しいな(違

_ あーびっくりした

1. 道を鴨がゆうゆうと歩いていて、危うくひきそうになった
2. 意を決して ThinkPad を修理しようと思ったら見積もりだけで2万近く取られるところだった
   • 結局自分でパーツ買って直す決意をしたよ

2 のついでに。

プログラマに最適なPCって？ - てくのーと Splash☆Star

を読んで思っていたことを書いておこうっと。なぜプロに ThinkPad が受けるのか？

それは金が掛かるうえにブランドが持ち主の心をくすぐり続けるからではない。

• 自分の手を動かせる人間にとってこの機械は安心で、かつとても安上がりだから

である。

この話を説明するには「道具を手に入れること」と「お金を出してモノを買うこと」がイコールでないということをまず伝える必要がある。　

バイク乗りならこの話はスムーズに理解できると思うが、自分の道具は自分で手入れをし続けてこそ快適に使い続けることができるのである。自作機もそう、楽器も包丁もカメラもみんなそう。道具を本当によい状態で使い続けるためには自らその道具を愛し、手入れをするのがいちばんなのだ。そしてそれが可能なノートPC が ThinkPad なのである。

理由は ThinkPad 使いには常識すぎて今さら書くまでもないことだが、

• 分解マニュアルが本家サイトから手に入る
• 個人でもフツーにパーツ単位で購入が可能。そしてこれが安い。

の2点である。こんなことができるノートPC が他にもあるのか自分は知らないが、少なくともこれがあるから ThinkPad に安心感を抱いている人は多いはずである。*4

別にプロでなくたってそれなりに頑丈であるという理由だけでも ThinkPad を選んでいいと思う。しかし世間一般での ThinkPad の利用率と、オープンソース系のカンファレンスなどでの ThinkPad の利用率は恐らくものすごく違うはずである。自分の周りには自分の薦めた以外の非IT系の人が ThinkPad を使っている例はない。というか普通は薦めても Let's note の方を選ぶ。

だが上のことを知っていると、安心して型落ちの ThinkPad を買うことができる。ドライバや BIOS アップデートもサイトから手に入れればいい。多少壊れても自分で直せるし、液晶をつかんで本体を持ち上げてもフツーは壊れない。そういう、自分の手を動かして自分の思う通りにしかも安価に使い続けることができる感が ThinkPad の良さなのだ。

もちろんこういうことをわざわざ書く人間は、当然のようにキーボードの感触にもトラックポイントの使い勝手にもやられまくっている。間違いない。そして多少の重さや同時期の他社のマシンと比べたときのスペックの低さなどはまったく気にならなくなっているのである。*5

以上が起きている間中キーボードを叩いているような人たちの間に ThinkPad 使いが多い、一つの理由である。

_ 知り合いに子どもが生まれたというので

※ 28日の話なんだけど、28日がもういっぱいなのでずらして書いてます。

お祝いを探しにトイザらスに行ったのにほしいものが見つからず、間違ってルービックキューブを買ってしまった。

というのも店頭で 5X5 のバージョン を見つけてビックリしてしまい、なんじゃこれとしばし夢中で取り組み、なんとか1面合わせることができた時点でものすごく楽しくなってしまったのだ。

ところで今ってルービックキューブの何回目のブーム？ 確か3回目くらいだよね？ 10年くらい前にも一度流行ったような気がするんだけど…。ま、とにかく自分にとっては20年ぶりのルービックキューブ。出た当時はまぐれの3面までしか合わせられなかったが、今ならイケるかもとか思い、思わずお買い上げ。

_ キーボードとキーバインドの設定

Q. コンソールでキーボードの Ctrl キーと Caps Lock キーを交換して使いたい。その他、任意のキーの意味を交換したい。 (FreeBSD QandA 365)

FreeBSD で日本語キーボードを使いつつ A の左を ctrl キーとして使いたい場合、

keymap=jp.106x

にすればよいらしい。こんなものがあったとは。本体のキーボードはほとんど使わないし、FreeBSD をクライアントで使うこともまずないので知らなかった。kbdcontrol とか、どうもこの辺の基本的なところがすっぽり抜け落ちてるな。

vi ユーザなので、vi のキーバインドで使いたい (または、emacs のキーバインドで使いたい)　（zshのある暮らし - FAQ@zshスレ)

※ フラグメントID は変わっちゃう可能性おおいにあり。

遅い機械なので環境変数 EDITOR には vi を設定しておきたいが zsh での操作には emacs バインドを使いたいという場合は

bindkey -e
export EDITOR=vi

にすればいいのか。bindkey -e なしの状態で C-a とか C-e とか効かずにちょっとパニクってしまった。

_ tDiary を port forward 越しに使うと一部おかしい

※ 長いんでまた日付を未来にずらしてしまう作戦。

とりあえず日記に書いちゃえメソッド。2.1.4 で確認。

具体的には tdiary.rb の base_url メソッドでの URL の組み立て方の問題と、それの適用範囲の問題。

def base_url
  return '' unless @cgi.script_name
  if @cgi.https?
    port = (@cgi.server_port == 443) ? '' : ':' + @cgi.server_port.to_s
    "https://#{ @cgi.server_name }#{ port }#{File::dirname(@cgi.script_name)}/"
  else
    port = (@cgi.server_port == 80) ? '' : ':' + @cgi.server_port.to_s
    "http://#{ @cgi.server_name }#{ port }#{File::dirname(@cgi.script_name)}/"
  end.sub(%r|/+$|, '/')
end

別段おかしなところはなさそうに見えるんだけど、port forward してると期待通りに動かない。

例えば localhost 8080 からサーバの 80 に飛ばしているとき、サーバでは 80 に繋がっているわけだから、8080 は無視されてしまう。これを基準に URL を組み立てている RSS auto-discovery や image プラグインは http:// localhost/hogefuga/ へのリンクを生成してしまう。しかし実際にはそこには何もない。通常のリンクは相対で生成しているので、ほんとに一部だけでおかしなことになっている。

対応としてはヘッダの Host フィールドを使う。http:// からの絶対 URI はどうしても必要でなければ極力使わないってだけでずいぶん話は簡単になると思うけど、RSS はそうもいかないし。ただ逆に port forward した URI が RSS に埋め込まれても困る、という別な問題もあったりする。だから

• base_url は Host を利用できるなら利用し、できない場合は上の処理
  • そのうえで、極力使わない
• makerss.rb 独自か、あるいは日記の設置 URI という値を用意して、そこに正規の絶対 URI を保存する

って感じで対処するのがいいんだろか。

ちなみに今回自分がどうしたかというと、

@options['image.url']

を設定して http:// からの URI が生成されないようにして回避した。RSS とかその辺は気にしてないものなので無視。

あ。

自画自賛で思いついたけど、日記の設置 URI って値はあったら嬉しいかも。例えば permalink もこれを使うようにできればいい。

なんでかっていうと、このサイトは現在 aligach.net だけれども、www.aligach.net でもアクセスでき、そっちでアクセスしちゃうと TrackBack の送信先とかも www 付きのものになっちゃう。でも複数の URL でアクセスできるってことと permalink が複数あるってのは意味が違うと思うんだよな。できれば permalink は常に aligach.net になってほしい。

そういうときに便利かなと。