ボクちゃん探偵シリーズ第三短篇集。 ミステリとしてどうこう言うより、ハードボイルドのパロディとして楽しむということで。
「B型の女」は、『A型の女』、 「長く冷たい冬」は『長く冷たい秋』なんでしょうけど、 後の2つはわかりません。
第24回横溝正史賞優秀作。 タイトルやカバーのデザインからはどこか瓢々とした軽快な感じの作品を想像したのだが、内容はもう少し重い。 出だしは、どこかもたつく感じがする。 また、話の展開があまりにもご都合主義的なところが目立つ。 最後の捻りが面白いだけに惜しい。
VMWare上のWin2k上でckを使うと、ちょっと重いので、ckoを使うことにしました。
ボクちゃん探偵シリーズ第二短編集。 幼稚園児が探偵役の連作ハードボイルド。 幼稚園児、渋柿信介(6歳)が渋くハードボイルドに決めてくれます。 アルコール中毒にならないようアルコールを我慢する探偵に対し、 ハードボイルド探偵渋柿は、虫歯が痛まないよう、チョコレートを我慢しながら捜査するのです。 報酬は、ギンガマン・ソーセージにガムにピカチュウ・パン。 全編ハードボイルドのパロディに満ち溢れております。 語り口がハードボイルドなのは、別段、おかしくも何ともないんだけど、 語り手が幼稚園児というギャップが面白いのです。
ところで、「カラスの鍵」の元ネタのタイトルは何でしょう？ 語呂からすれば『マルタの鷹』のような気がするんだけど、「の」しか合ってない...。 ちなみに、「クロへの長い道」は『シロへの長い道』、 「縞模様の宅配便」は『縞模様の霊柩車』、 「八百屋の死にざま」は『八百万の死にざま』だと思われます。
メッセージの件、修正漏れがありました。すいません。
英語は難しい。 正直、一瞬どうでもいいだろと思わないでもなかったのですよ。 ですが、結局のところ、「XXXXに失敗しました。」というのと「XXXXに失敗します。」では全然違います。 当然、ネイティヴな人から見れば、きっとツッコミの格好の餌食となってしまうところです。 「これだから、日本人の作ったソフトは...」などと思われてしまいます。 ちょうど「これだから外国人の作ったソフトは日本語の扱いが...」の裏返しのようなもんです。 そんな訳で、ちゃんと修正しようと思ったのでした。 こういう指摘をしてくれる人がいるのは有難いことです。
一瞬、便利かも知れないと思ったんだけど、bashでコマンドライン編集がうまくできない。 Cygwinを最新版にしないと駄目なのかな。
ごめんなさい。私が悪うございました。 XKeymacs が有効になってしまってキーバインドが 無茶苦茶になってしまってました。 Teraterm使っているとXKeymacsが無効になるので気づきませんでした。 XKeymacsを無効にしておけば、なかなかいい感じで使えそうな雰囲気です。
ckが起動しているときだけ、XKeymacsを無効にするにはどうすればいい？
簡単に設定できたのか。うーん、すっかり忘れているな。
そんなこんなの副作用のため、 XKeymacs、Cygwinなどがバージョンアップされてしまいました。
手元のWin32OLEでは、WIN32OLE_TYPELIBなんていうものができつつある。 パフォーマンスだとかメモリだとかそういうことは一切気にしないプログラミング。 しかも、自分が好きで作っているだけなので、結構、楽しい。 ただ、こんな物を実装して嬉しい人はどれくらいいるのだろう。
多分、WIN32OLE_TYPE.typelibs とか WIN32OLE_TYPE.ole_classes あたりは、将来(1.9系以降) obsolete になります。 もちろん、代用品は用意します。 ←このようなことを書いたところで、インパクトを受ける人はほとんどいない気がする。
例のObjectは、VT_BYREFをつけなければどうにかなるのかも知れないと考えながらも、 面倒そうな気がして躊躇している。
価値のない物しか盗まない快盗ニックの短編集。 例によって読みどころは、どうやって価値のない風変わりな物を盗み出すかという点と、 依頼人は、どうしてそんな物を欲しがるのかという動機の謎解き。 好みは、プールの水を盗み出す「プールの水を盗め」。動機も手段も鮮か。
ダルジール警視シリーズ。 有力な犯人候補が何人かいて、個人的感情から、それぞれの刑事がそれぞれに違う人間を犯人だと主張します。 最後の最後まで、話はもつれ込み、なかなか誰が犯人かわかりません。 しかし、こんな終わらせ方をして、この後、どうする気なんだろう。
さすがにまずいと思ったのか、extの下に.documentが加わって指定したものだけ、 ドキュメントがインストールされるようになってます。 win32oleも仲間に入れてもらおう。
そろそろかも。 preview3が出る前にWin32OLEのバグを減らせて良かった。 Objectはどうすればいいのかわかりません。
ri を使って sole.rb と同じような情報が得られたりすると嬉しいかも知れない。
時間がかかるのは、別に構わない。 メモリが足りないらしく、ディスクにアクセスしているが、まあ、それも仕方がない。 そのせいで、カリカリとハードディスクの音がうるさいのも良しとしよう。 他のことがスムーズにできないのが困る。 2時間は我慢しないといけない。
るびま 2号に 『オープンソースカンファレンス 2004 Ruby BoF 参加レポート』の記事を書きました。 読んでやってください。
昨日のことですが、参加してきました。
ささださんにProgramming Ruby 2nd ED. を見せてもらいました。 Daveのサイン入りです。 自分が気になっていたところだけパラパラとチェック。 test/unit の解説がありました。 結構、丁寧に解説している感じです。 あと、Win32OLEは、ちゃんとRuby標準の拡張ライブラリとして紹介されてました。 1st ED. のときは、Ruby標準じゃなかったので、どういう紹介になっているのかちょっと気になっていたのでした。
あと、記念のTシャツも見せてもらいました。Rubyの赤ということで、赤いTシャツでした。
akrさんに[ruby-dev:24476]の件はどうなったかと質問されました。 すいません。見落としてました。 修正します。
参加するのどうしようか迷いつつも、行ったのだけど、(このように読書会とは全く関係無いところで得るところがあるので) 読書会に参加して良かったです。
相変わらず、Haskellがブームみたいです。
連作短篇集。 どれも、発想の転換というか目のつけどころを変えることで、謎が謎でなくなるところが面白い。
それぞれのタイトルは、有名の作品のもじりになっているみたいだけど、全部はわかりません。 「夜届く」が「夜歩く(カーター・ディクスン)」、 「失踪当時の肉球は」が「失踪当時の服装は(ヒラリー・ウォー)」、 「クリスマスの猫丸」が「クリスマスのフロスト(R・D・ウィングフィールド)」じゃないかと思います。
Cygwin版 Ruby 1.9、mingw32版 Ruby 1.9、Cygwin版 Ruby 1.8、mingw32版 Ruby 1.8の4つを コンパイルするのに2時間30分かかってしまう。 もちろん、1.9 は、make install だと終わらないので、make install-nodoc としている。 どうしたものか。
Ruby 1.9 Cygwin版を作ろうとしたら、「仮想メモリが足りない」とメッセージが出た。 make install-doc が終わりません。 拡張ライブラリも対象になった分、時間がかかってます。 とりあえず、win32ole.c だけを対象にしてもらうように .document ファイルを作っておくことにしました。
VMware上のWindows 2000 だから make install-doc が終わらないのかと思ったら、 Linux 上でもなかなか終わりません。
Linux 上でも、
ri WIN32OLE
で説明が出てきちゃうよ。extconf.rb で動的に .document を生成するようにした方がいいかな。
結局、VMware上だと12時間経過しても終了しませんでした。 強制終了しました。
異様にねじれたサイコ・サスペンス。
マシューズ医師がどうやって危機的状況から逃れられるのかと思いきや、 あっさりと危機を回避できてしまう。 ひねくれた展開のわりにどこか淡白な印象を受ける。 多分、現代であれば、もう少しディテールを書き込んで、重厚な作品になるのではないだろうか。 書かれた時代のせいなのか、エッセンスだけを詰め込んだあっさりした作品に思えてしまう。
この辺のあっさり感というのは、アントニイ・バークリーの作品を読んだときにも感じるところだ。 読む方としては、軽く読めるのがいいのだが、一方でどこか物足りないような気もするのだ。
短篇集。 表題作「看守眼」が好み。
つらつらと考えているのだが、WIN32OLE_TYPELIB クラスを導入するという方向に傾きつつある。
WIN32OLE#typelib では、WIN32OLE_TYPELIB オブジェクトを返す。 複数のバージョンがある場合には、最新バージョンのWIN32OLE_TYPELIBオブジェクトを返す。
WIN32OLE_TYPELIB には以下の3つのメソッドを持つことにする。
WIN32OLE_TYPELIB#libpath タイプライブラリのファイルのパスを返す。
WIN32OLE_TYPELIB#version バージョンを示す文字列を返す。
WIN32OLE_TYPELIB#name タイプライブラリ名を返す。
WIN32OLE_TYPE.typelibs は、WIN32OLE_TYPELIBオブジェクトの配列を返す。 複数のバージョンがあったとしても、全部のバージョンを返す。
WIN32OLE_TYPE.typelibsを利用している人には影響がある。 書いていて思ったけど、 WIN32OLE_TYPE.typelibs は廃止して、WIN32OLE_TYPELIB.typelibs を用意するのが自然な気がしてきた。 そのうち、Ruby 1.9 の方で実装してみようかと思っている。
依頼によって、価値のないものだけを盗み、手数料を依頼人から受け取る快盗ニックの短編集。 女快盗サンドラが登場する短編ばかり10編収録。 読みどころは、どうやって盗むかということと、どうしてそんな価値のない物を依頼人は盗みたがるのかという謎解き。 好みは、「浴室の体重計を盗め」。 こうやって、順番に続けて読むと、ニックも年を取っているのがわかって面白い。
順序は逆になったけど、『快盗ニックを盗め』『快盗ニックの事件簿』も読んでみよう。
どうでもいいけど、Amazonでは、なぜか、『快盗ニック対女盗賊サンドラ』になっている(2004-10-11現在)。
明治時代の日本を舞台にした連作ミステリ。 謎を解くのは、日本在住の新聞記者チャールズ・ワーグマン。 ワーグマンが、事件の謎を解くのではなくて、事件をどう解決するかが読みどころ。
WIN32OLE_TYPE.typelibsにバグを見つけた。
WIN32OLE_TYPE.typelibs はタイプライブラリの文字列を配列の形で返す。 ソースを見ると、同じタイプライブラリのうち最新のバージョンのものだけ配列に追加しているつもりらしきコードがある。 つもりなので、ちゃんと動かない。 EXCEL 5.0 と EXCEL 10.0 があると、EXCEL 10.0 だけを配列に追加するつもりが、 私の環境だと両方とも配列に追加してしまう。 だからと言って、絶対確実に複数のバージョンを取ってくるとも言い切れないコードになっている。
今、迷っているのは、複数のバージョンがあるとき、次のどちらがいいかということ。
最新版だけ配列に追加する。
全部配列に追加する。
現状の動きは、2.に近い。 実際、手元で2.のように修正しても、修正前のものとWIN32OLE_TYPE.typelibsの結果は変化しなかった。 一方、Excelのオブジェクトブラウザは、1.の動きっぽい。
groovyは何となく造語だと思っていました。
先日、olegen.rbの使い方を質問された。
olegen.rb Word.Application
としても何も出力されないとのことだった。 olegen.rb の引数としては、タイプライブラリ名を指定するのが筋なので
olegen.rb "Microsoft Word 10.0 Object Library"
とするのが正しい。
そう答えてはみたものの、WIN32OLE.new の引数は、ProgID(Word.Application)なので、 Win32OLEユーザーにとって馴染みがあるのは、Word.Applicationの方かも知れない。 引数の間にスペースが入っているタイプライブラリ名を指定するのも面倒くさい。
olegen.rb Word.Application
でも同じ結果が得られると嬉しいかも知れない。 などと、つらつらと考えていた。
結局のところ、
olegen.rb Word.Application
の結果を
olegen.rb "Microsoft Word 10.0 Object Library"
と同じにするのは難しい話ではない。 "Word.Application" を "Microsoft Word 10.0 Object Library" に変換できさえすれば。
レジストリとWin32OLEのソースとMSDNの間を行きつ戻りつして、 どうやら、ITypeLibとITypeInfoとレジストリの迷宮をさまよえば、 Word.Application から "Microsoft Word 10.0 Object Library" に変換できそうなことはわかった。
あとは、これを、どうWin32OLEに落とし込むかである。
word = WIN32OLE.new("Word.Application")
word.ole_get_typelib # => "Microsoft Word 10.0 Object Library"
とか
WIN32OLE.to_typelib("Word.Application") #=> "Microsoft Word 10.0 Object Library"
とか
WIN32OLE_TYPE.to_typelib("Word.Application") #=> "Microsoft Word 10.0 Object Library"
とか
word = WIN32OLE.new("Word.Application")
word_type = word.ole_obj_help
word_type.typelib #=> "Microsoft Word 10.0 Object Library"
とか...。
2番目と3番目の奴はどうにもしっくりこないので、却下。 できる限り、WIN32OLEオブジェクトにはメソッドを追加したくないので、1番目も却下。 結局、選択肢としては4番目が残った。
ここまでたどりついたのだけど、果たして、
olegen.rb Word.Application
と
olegen.rb "Microsoft Word 10.0 Object Library"
の結果が同じになるというのは、動きとして正しいと言えるのだろうかと考えてみたり。
WIN32OLE#ole_obj_help という名前は、実体と全然あっていない気がする。 別名を考えた方が良さそうだと思ってみたり。
いろいろ作業している間に、WIN32OLE_TYPE.typelibs にバグっぽいものを見つけてしまった。 でも、どう修正するのがいいんだろうと悩んでみたり。
なんか、考えがまとまらない。
どんなクラスがあって、どんなメソッドがあるのかも、その使い方もすっかり忘れている。 Win32OLEを普通に使う分には、知らなくてもいいメソッドがほとんどである。 むしろ、Win32OLEを使うにはCOMサーバーが何を用意しているかということが重要になってくる。
そんなこんなで、もはや、Win32OLEのソースを見ないと、どんな機能があるのか思い出せなくなっている今日この頃です。 駄目じゃん。
C言語に対する批判なのだけど、 Schemeの継続を理解するためのヒントにもなっている気がする。
『麦の海に沈む果実』の 水野理瀬が登場。 主役は人じゃなくて、水野理瀬が住むことになる白百合荘です。 白百合荘が主役のサスペンスです。 『麦の海に沈む果実』ほど居心地の悪さはありません。 ストレートなサスペンスに仕上がってます。 単独でも十分楽しめますが、 『麦の海に沈む果実』から読むことを オススメします。 水野理瀬の物語は、これで終わりじゃなく、まだまだ続きそうです。
標準でUTF-8をサポートするようになったそうなので、 CVS版のEmacsをインストールした。
前回、悩んだので、今回は、メモしておこう。
起動時、.emacs.el のエラーが出るので、以下のものは再インストール。
APEL
FLIM
SEMI
SKKも使えなくなるので、再インストール。
UTF-8のコードをちゃんと読めるか確認しようと思ったけど、手元にUTF-8のファイルが無い。 UTF-8対応 nkfをインストールしてから確認した。 これで、Mule-UCSは使わないで済みそう。
.emacs.elに
(setq inhibit-startup-message t)
としておく。
最近、Ctrl + f と Ctrl + v がごちゃごちゃになってます。
Emacs をアップグレードしたら色が変わってくれないことがあるような気がする。 うーむ。
前の職場にはあったんだけど、今の職場では、見かけなかった。 この際、1冊ぐらい手元にあってもいいだろうってことで。
ボクシングとか、アンボクシング とか、可変長引数とか、Genericsとか どんどん色々なものが増えて、どんどん複雑になってきてますねえ。
昨日は、急遽、プログラムを1本でっちあげることになった。 処理を考えれば、Rubyが向いているのだけど、Rubyが動く環境がない。 残る選択肢はCかPerl。 Perlは嫌いだし、すっかり忘れてるので、コード書くのに一々調べないとできない。 でも、Cで書くのも面倒くさそう。 とりあえず、何も見なくても、ある程度まで、書いていけるCで作ることにした。
一般には
Cで作るのに必要な時間 > Perl で作るのに必要な時間
なのだろうけど、私の場合、Perlだとコードを書く前に調べないと書けないので、
Cで書くために調べる時間 < Perlで書くために調べる時間
という逆転現象が発生する。で、
Cで作るのに必要な時間 + C で書くために調べる時間
と
Perlで作るのに必要な時間 + Perlで書くために調べる時間
の大小関係がどうなるか、良くわからなかった。 結局、コードをさくさく書ける分、さくさく仕事が進んでいるように錯覚できるCを選択したのであった。
Rubyをインストールしてから、Rubyで書くというのは、反則な気がしたのでやめた。
Gauche はインストールしても何も書けないのでやめた。
嫌いだけど、調べなくてもさくさくプログラムは書けるよとさらっと言えるとカッコイイとふと思った。 あと、Perlで書くとどれくらい時間がかかるか計っておくのも今後のためにいいかも知れないと思った。 うーん。Perlを触ってみようかなあ。
昨日のことだけど、ちょっとショックなことがありました。 ある程度、予想していたこととは言え、ショックです。 今日、さらにショックを受けました。 こっちも全く予想していなかった訳ではないのだけど、やっぱりショック。