Digitune [memo]

WX310SA のカメラ

PHS を機種変してしばらく経ち、カメラもずいぶん使いました (256Mbytes の MiniSD カードなんて買ってしまったので、撮っても撮っても埋まらない…笑)。ここらで簡単な感想をば。

解像感はなし、色合いは僕好み

ケータイカメラの宿命か、はたまたパンフォーカスのためか、さすがに写真に解像感はありません。面白いのは、画面全体がぼんやりしているのではなく、画面の一部がつぶれたようになる点 (先日の桜の写真などでもわかります)。案外 JPEG 圧縮のせいだったりして。写真の色合いについてはかなりお気に入りです。結構濃い目に写る感じで、特に空の色が鮮やかに写るのが良いですね。ノイズは結構のるけれど…。もう一つ気が付いたこと。光量が多い昼間の屋外よりも、若干暗めのシチュエーションの方が鮮やかに写るような気がします。ちょっと不思議です。

暗所にも案外強い

夜の部屋の中など、ふつーのデジカメ (Lumix やキスデジ) だとシャッタースピードが遅くなって被写体＆手ぶれ写真を量産してしまうようなシチュエーションでも結構頑張ってくれます。ぶれやすくなるのは間違いないのですが、そもそも撮れる写真が小さいせいか、それほどぶれが気にならない感じ。感度も上げられているはずなのに、ノイズの乗り方もそれほど極端ではありません。夜の室内限定なら Lumix より撮りやすいかも。

動作はのろい

やっぱり専用のデジカメに比べるとあらゆる動作が遅いです。立ち上げにも保存にも閲覧にも数秒オーダーで時間がかかります。プレビューの追従性も昔のデジカメみたい。京ぽんからの移行組である僕にとってはあんまり違和感ないですけどね(笑。一つ気がついたのは、保存先を「本体」としている場合より、「MiniSD」にしている場合の方が圧倒的に保存が早い点。僕はエレコムの「MF-FMISD256」というメモリーカードを使っていますが、これが結構速めのメモリ (公称 7Mbytes/s) なのが効いているのかしら？電池の持ちが極端に悪くなる、ということもなく、問題なく使えています。

デカイ写真は転送に時間がかかる

考えてみると当然の事実なのですが、SXGA (1280x960)、ファインで写真を撮ると、ファイルサイズは 300Kbytes 前後になります。これを NetFront でアップロードしようとすると分オーダーの時間がかかります。WX310SA には挿した MiniSD を USB ストレージとして見せるモードも付いているのでそちらで転送すればよいのですが、外出中にブログを更新しようと思ったりすると結構大変。

WX310SA は Java アプリ実行機能があったり、ZIP ファイルの展開機能や PDF ビューアなどが標準搭載だったりと、機能的にはちょっとした PDA 並みだなぁ、と感心してしまいました。いわゆる今日的なケータイ、というのはずいぶん進化しているのですね¹。

リアル・金田のバイク

すげー(笑。作った人のイメージがもろわかりで楽しい。量産化予定なのはふつーのスクーター然とした小さいほうらしいのがちょっと残念ですが。

ゲーム機商戦は転換期？

最近、セールス好調な Nintendo DS の成功を受けて、こういった論調の記事をよくみますが、個人的にはちょっと拡大解釈しすぎなんじゃないかと思うんですよね。
確かに、「他のマシンを遥かに凌駕する」といういわゆる久夛良木イズムも開発費の高騰、表現力のサチュレーションからかつての輝きを失い、特にゲームの企画、販売戦略的に「新しい何か」が求められているのは間違いないでしょう。そして DS がその一例を提供し、市場に受け入れられていることも。ただだからといって、ゲーム機のハードウェア戦略においても高機能化が間違っている、と結論付けるのは、甚だ時期尚早であるように思います。
なぜかと言えば、ゲーム機は極めて近い将来、HD への対応を余儀なくされるからです。リビングの AV 環境は今、すごい勢いで HD 化されつつあります。HD 環境に自然に適合するためには、最低 Xbox360 や PS3 クラスのスペックは必要になります¹。そういう意味では、Xbox360 や PS3 性能は、スペック競争の結果生まれたものであると同時に、HD への対応の結果必然的に生じたものとも言えるのではないでしょうか。
そんなことを考えると、今の「 DS による揺り戻し」を大きく捉え過ぎることに少し危機感を感じてしまうのです。

リビング・ゲーム機の終焉？

ふと、こんなことを考えました。
「DS や PSP が定着し、PC もすっかり普及した。もしかするとそもそも、『リビングでゲームする』というライフスタイル自体が、いまや過去のものとなりつつあるのではないか」
うーむ。そういう可能性は大いにあると思う反面、個人的にはちょっと寂しいです。過去何度か書いていますが、僕の中で「ゲームをする」こととは、PC-6001 で初めてやったマイクロキャビンの「ミステリーハウス」の頃からずっと、家族で楽しむことだったからです。「ミステリーハウス」は英単語入力式のアドベンチャーゲームだったので²、当時小学生だった僕ら兄弟では知っている語彙など高が知れており、結果両親に知恵を出してもらいつつ、一緒に楽しみながらプレイしました。それ以来、ゲームというのは家族、兄弟でわいわいがやがややるものなんですね。この間のドラクエ８も、まだ字の読めなかった鳥乃も含め、家族みんなで楽しみましたし、ワンダにしてもそうです。
なので実は、携帯ゲームというものにもあんまり興味がなかったりします³。一人でゲームしててもなんだかつまんないような気がするのです。

「ユキビデオ」

ご存知 YUKI ちゃん⁴のビデオ・クリップ集。彼女のソロ・デビュー・シングル、「The end of shite」のクリップのエッチさに惹かれ、ずいぶん前から欲しいと思ってたんですが⁵、ようやく買いました。

期待してた「The end 〜」も良かったんですが、「joy」のクリップが出色。すごくかっこよくてすごくかわいい(←ちなみに「かわいい」のが YUKI ちゃん本人ではないのがポイント)。曲もいいしね。

他のビデオも変で楽しくて可笑しくてかっこいいので、ひとしきり笑いながら見られます。

近所の桜

会社に行く道すがらに立派な桜並木があり、毎年楽しませてもらっています。今年もとても綺麗でした。

菜の花畑

日本に帰って来たら、なんだかすっかり春ですね。桜はまだ少し早いけど、近所のアウトレットモールの土手は菜の花が満開です。

そういえば WX310SA にはまだ微妙にバグがあるらしく、カメラで撮った画像の保存に時々失敗します。保存先を本体にした場合も MiniSD にした場合も失敗する時は失敗するので、メモリカードの相性、という訳でもないみたい。この菜の花の写真も最初全然保存できなかったんですが、試しに画質をノーマルにしてみたところ無事保存出来ました。

思うに、情報量の多い画像を低い圧縮率で保存しようとするとダメなのかもしれません。ワークメモリを使い切ってしまうんでしょうか？

昼食と飛行機

はてさて。

WX310SA と tDiary 絵日記プラグイン機能追加版

この間書いた対処方法は、やっぱりあまりに手抜きなやり方だったらしく、結局正しいサイズが取れていなかったことが分かりました¹。乗りかかった船なのでちょっと調べてみたんですが、そもそも image_size.rb での JPEG ファイルのサイズ取得方法がどうも不十分っぽい。libjpeg での処理と見比べたりといろいろ調べ始めたときに、はた、と気がつきました。

僕は tDiary の絵日記プラグイン機能追加版を ImageMagick の「convert」を使うモードで使っています。だとすれば、サイズ取得にも同じ ImageMagick に含まれる「identify」を使えばいいのです。WX310SA の JPEG ファイルでも、identify コマンドでは正しいサイズが取得できることはかなり最初の方から分かっていました。

というわけで、おととい加えた image_size.rb への修正は元に戻し、代わりに絵日記プラグイン機能追加版のスクリプト、image_ex.rb に下記のような修正を加えました。

kazawa@tpx20:~/src/tdiary/plugin$ diff -u image_ex.rb.orig image_ex.rb  
--- image_ex.rb.orig    2006-03-21 22:13:06.761265514 +0900  
+++ image_ex.rb 2006-03-21 22:21:13.690420236 +0900  
@@ -139,7 +139,7 @@  
 end  
  
 def image_link( id, str )
-  @image_date ||= @date.strftime("%Y%m%d")
+       @image_date ||= @date.strftime("%Y%m%d")
        @image_year ||= @date.strftime("%Y")
        if @imageex_yearlydir == 1  
                image_url = %Q[#{@image_url}/#{@image_year}/]  
@@ -178,7 +178,7 @@  
                imageex_convertedwidth =  @options && @options['image_ex.convertedwidth'] || 160  
                imageex_convertedheight = @options && @options['image_ex.convertedheight'] || 120  
  
-               if imageex_useresize == 1 || imageex_useresize ==2  
+               if imageex_useresize == 2  
                        begin  
                                require 'image_size.rb'  
                        rescue LoadError  
@@ -198,7 +198,7 @@  
                                        imageex_convertedsize = %Q[#{imageex_convertedheight}x#{imageex_convertedwidth}]  
                                        imageex_convertedsize  
                                end  
-                               system(imageex_convertpath , "-geometry", imageex_convertedsize , orig, new)
+                               system(imageex_convertpath , "-quality", "100", "-geometry", imageex_convertedsize , orig, new)
                                if FileTest::size?( new ) == 0  
                                        File::delete( new )
                                end  
@@ -268,7 +268,26 @@  
                                }  
                        end  
  
-                       if imageex_useresize == 1 or imageex_useresize == 2  
+                       if imageex_useresize == 1  
+                               open("|identify #{image_file}", "rb") do |fh|  
+                                       img_info = fh.readline  
+                                       img_info =~ /^\S+\s+(\S+)\s+(\d+)x(\d+)\s+/m  
+                                       orig_type = $1  
+                                       width = $2.to_i  
+                                       height = $3.to_i  
+                                       if imageex_converttype == 0  
+                                               new_type = "jpg"  
+                                       elsif imageex_converttype == 1  
+                                               new_type = "png"  
+                                       end  
+                                       if width  
+                                               if width > imageex_thresholdsize or height > imageex_thresholdsize  
+                                                       small_image_file = %Q[#{image_dir}s#{image_date}_#{image_name.length.to_s}.#{new_type}]  
+                                                       resize_image(image_file, small_image_file, width, height, imageex_convertedwidth, imageex_convertedheight, orig_type, new_type)
+                                               end  
+                                       end  
+                               end  
+                       elsif imageex_useresize == 2  
                                open(image_file,"rb")  do |fh|  
                                        img = ImageSize.new(fh.read)
                                        width = img.get_width  

今度こそちゃんと動くようになったと思うんだけど、どうだろう？ (いくつか本題とは関係ない修正も加わっているのはご愛嬌)

ちなみに右の写真は、今日の自分の誕生日用のガトーショコラ作りをお手伝いする鳥乃さんです。

PHS 機種変

いつも使っている Willcom の PHS を、これまでのいわゆる「京ぽん」、つまり京セラ AH-K3001V から、「洋ぽん」こと、三洋 WX310SA へ機種変更しました。右の不気味な写真が新しい電話です。色はプログレッシブ・レッドです¹。

「京ぽん２」、WX310K ではなく WX310SA にした理由は、カメラ部の作りです。そもそも出てくる画像も WX310SA の方が好みでしたし、縦位置、横位置を撮影時に選択できるのも、そこからすぐアップロードしようと思うととても便利です。さらにいろいろ調べていて、WX310SA はいわゆるマクロモード付のパンフォーカス機なんですが、こちらのページなどで、マクロスイッチを微妙にコントロールすることでマクロモード、標準モード双方でピントの来にくい距離 (10〜50cm くらい？) でもピントを合わせることが可能、という冗談のような仕様があったことも、一つの理由でした。ある意味マニュアルフォーカスだよな、コレ。

噂どおり、NetFront は Opera に比べると重く軽快感には欠けますが (Web ブラウズに関してだけ言えば AH-K3001V よりも遅いかも)、僕はケータイで Web を見ること自体まれだし、まぁいいか、と思っています。

そうそう、あと WX310SA のカメラの作る JPEG ファイルが若干特殊なものなのか、tDiary の絵日記プラグインへ写真をアップロードしようとすると、image_size.rb 内の JPEG イメージのサイズを取得しているところでエラーが出て、サムネイル画像が生成できない、という不具合がありました。せっかく大きな SXGA サイズの写真を撮れるようになったのだから、ちゃんとそれを使いたい、と思い、少しだけ image_size.rb をハックして、とりあえずエラーが出ないようにしてみました。

kazawa@tpx20:~/src/tdiary-current$ diff -u image_size.rb.orig image_size.rb  
--- image_size.rb.orig  2006-03-19 23:37:45.376965460 +0900  
+++ image_size.rb       2006-03-20 00:50:10.672238905 +0900  
@@ -121,14 +121,14 @@  
                c_marker = "\xFF"   # Section marker.  
                @img_data.read_o(2)
                while(true)
-                       marker, code, length = @img_data.read_o(4).unpack('aan')
-                       raise "JPEG marker not found!" if marker != c_marker  
+                       nil until c_marker != @img_data.read_o(1).unpack('a')
+                       code, length = @img_data.read_o(3).unpack('an')
  
                        if JpegCodeCheck.include?(code)
                                height, width = @img_data.read_o(5).unpack('xnn')
                                return([width, height])
                        end  
-                       @img_data.read_o(length - 2)
+#                      @img_data.read_o(length - 2)
                end  
        end  
        private(:measure_JPEG)

基本的にエラーチェックを甘くしただけ、というような修正なので、誰にでもお薦めできるものではありませんが (多分何か悪い副作用がありそう)、とりあえず WX310SA からアップロードしてもエラーが出なくなりました。こんなんでいいのか？！（；´Д｀）

英語漬け

ここのところ仕事ですっかり英語漬けです。メールも英語、ドキュメントも英語、会議も英語、英語、英語、何もかも英語！

これまでの僕の人生ときたら何しろ、大学の選択基準が「二次試験に英語の無いところ」だった、というほどの英語からの逃避人生ですから、そりゃまー大変なことです。

一応、学生の頃の自分にもそういった逃避行動に対する自己正当化ロジックがあって、いわく、「そもそも語学というのは、頭で考えて身につくものではなく、ある意味その基礎は楽器や歌、スポーツなどのように訓練によって身体に叩き込まなくてはならないものだろう。そういったこともせずに文法や言い回しの知識だけを詰め込んだところで、使いものにはならない」と。そらまー確かにそうかもしれないけど、今から思うと単語くらいは覚えとくといいことあったような気がするなぁ(笑。

そういう意味では日常的に英語を使わざるを得ない今の状況、というのは、僕が本来考えていた学習のためには最適なわけで、これを機会にちょっと勉強してみるか、という気分になっています。電子辞書、自動翻訳¹の助けを最大限借りつつも、周りの人にはスチャラカ英語でご迷惑をおかけするかもしれませんけどね…(汗。

エニグマの暗号、64年ぶりに解読

第二次世界大戦中のドイツ軍の暗号 (暗号機)、エニグマをめぐる物語はとても有名ですが、これは戦時中ブレッチリー・パークでも最後まで解読できなかった三つの暗号文のうち一つを、ドイツのアマチュア暗号解読家 (そ、そんな人がいるのか…パズルマニアとは違うんですよね？) が64年ぶりに解読した、という話。ところで、どこかの記事に「軍の専門家でも解けなかった暗号を解いたことは素晴らしい」なんて暗号専門家のコメントが載っていたんですが (ソースが見つからん…)、これを読んで僕はちょっと「？」と思ってしまいました。
ワンタイムパッド暗号ではない普通の秘密鍵暗号の場合、そもそも理論的にはほぼ必ず解読可能なはず。問題は解読にかかるまでの時間で、最近良く使われているような AES などでは一般に鍵長として 128bit といったものが使われ、かつ探索範囲を狭めるような欠陥も見つかっていないため、現在最高速のコンピュータでも総当りするにはとんでもない時間がかかる、というのが安全性の根拠になっています。
つまり、秘密鍵暗号方式はそもそも「時間さえかければ必ず解ける」ものなのです。一般に利用者は、計算にかかるコストや利便性と、守るべき情報の性質 (重要性や鮮度など)、暗号の強度 (どのくらい時間をかければ解けるか) を勘案して暗号アルゴリズムを選択していますし、攻撃者もそもそもタイムリーに解読できなければ無意味ですから (明日の作戦行動に関する情報を一週間後に得られたとしても何の意味も無い)、必死で欠陥を探そうとするわけです (エニグマも単なる総当りでは厳しかったところを、ドイツ軍の気づいていない弱点をいろいろ見つけて何とか探索範囲を狭め、ギリギリのところで何とか解読作業が間に合っていた、という話です)。
そう考えると今回、軍の専門家に解けずアマチュア暗号解読家に解けたのは、単にかけられた時間、計算リソースの違いであって (記事によれば解読に成功した人も分散コンピューティングによる総当り攻撃だったようですし)、暗号技術的には別段意外でも何でもないんじゃ…？と思ったのでした。もちろん、64年も前の、これまで破られていなかった暗号に何が書いてあるのだろう？というロマンは理解できるんですけどね。

「美しくなければならない−現代科学の偉大な方程式」

グレアム・ファーメロ著。プランクやアインシュタイン、シュレーディンガーやシャノンなど、現代科学を支える偉大な11の方程式について、ロバート・メイ、ジョン・メイナード＝スミスからロジャー・ペンローズといったこれまた現代のいろんな分野の有名な方がエッセイを寄せて出来た本。

何でもポピュラー・サイエンス本の不文律として「数式を載せてはならない」というものがあるらしいのですが、この本はその真逆をいってみよう、というところから企画されたんだそう。各方程式について、偉大な先生方がその個性を大いに発揮してエッセイをまとめてくださっていて、とても面白かった。

ジョン・メイナード＝スミスやペンローズのお話はいつもながらとても面白かったながら、今回、個人的にとても面白く読めたのはアイスリング・アーウィンのフロン問題に関する章。フロンに関する問題は単なる科学的な問題にとどまらず、政治や社会を巻き込んだ一大ムーブメントになります。ごく普通の研究者が、環境や社会に対するインパクトの大きさから、社会的行動に出る覚悟を決める、という一連のプロセスがとても感動的に書かれていて、そのうち映画か何かにでもなりそうな感じでした。

シュレーディンガーの章なんかは科学的な内容よりもハイゼンベルクとの確執にフォーカスが当てられていたりして、章によってかなりバラエティ豊富なこの本、それぞれの方程式をめぐる歴史も分かるし、そこからわれわれが進むべき道も見えてきそうな、とても面白い本だと思いました。お勧め。

Path MTU Blackhole(2)

先週、こんなことがあったので、ふと自宅サーバの設定を「Path MTU Discovery (RFC1191) を利用しない」よう変更してみました¹。そのまま一日が過ぎ、今日になってサーバのログを確認してみると、

Feb 26 16:46:42 tpx20 kernel: ICMP: xx.xx.xxx.xx: fragmentation needed and DF set.  

なるログが山ほど出ていることを発見、いろいろ調べてみたところ、どうも一部クライアントからのアクセスに対して正常に返答できていないようです²。

そもそもこのメッセージはなんなのよ？と思い、kernel source をごそごそとあさってみたところ、net/ipv4/icmp.c の中に次のような箇所があり、どうもここで出力されているようでした。

        case ICMP_FRAG_NEEDED:  
            if (ipv4_config.no_pmtu_disc) {  
                LIMIT_NETDEBUG(  
                    printk(KERN_INFO "ICMP: %u.%u.%u.%u: "  
                             "fragmentation needed "  
                             "and DF set.\n",  
                           NIPQUAD(iph->daddr)));  
            } else {  
                info = ip_rt_frag_needed(iph,  
                             ntohs(icmph->un.frag.mtu));  
                if (!info)
                    goto out;  
            }  
            break;  

…これってつまり、Linux の場合 Path MTU Discovery プロトコルが無効になっている状態 (/proc/sys/net/ipv4/ip_no_pmtu_desc が“1”の状態) では、経路途中の Router が ICMP Type=3、Code=4 (つまり「Destination Unreachable.」＆「fragmentation needed and DF set.」) を返してきても、ログに出力するだけで何もしない、って事のように見えます。

確かに、この Linux サーバ的には、Path MTU Discovery プロトコルを無効にすると、送出されるパケットの DF (Don’t Fragment) フラグも 0 となり、つまり経路の Router がよろしく Fragment してくれさえすれば、ICMP Type=3、Code=4 のメッセージに答える必要は本来無いはずではあります。

しかしどうも巷にはそもそも DF フラグが立っていようがいまいが Fragment 出来ない Router が山ほど存在するらしく (とは SAK 氏談)、その場合その Router は (DF フラグの状態に関係なく) 上記 ICMP Type=3、Code=4 を送信元へ送り返すようなんですね (IPv4 には他に使えるメッセージがないのでしょうがないようです)。しかし上で見たように Linux kernel は Path MTU Discovery が有効になっていない場合単にそのパケットを破棄してしまいますから、結果的にその Router の先にいるクライアントへはパケットが届かないことになってしまうようです。

というわけで、こと Linux をサーバとして利用する場合、Path MTU Discovery は無効にしてはいけない (そもそも最近のトレンドでは常に on にしておくことが強く推奨されている模様)、また Blackhole を検知した場合も、サーバ側設定を変更するのではなく経路上で ICMP を破棄してしまっている Device の設定を変更しなくてはならない、というのが正解のようです。

ネットワーク屋さんにはきっと常識なのでしょうが (と、SAK 氏がうるさく連呼しているが)、いやはやいろいろ難しいですねぇ。