新しいせいか何のせいか、相変わらずヘルプが使えない。 思うにヘルプがわかりにくいソフトというのは 使い方もよくわかっていないのではなかろうか。使い方がわかっていないか そのソフトの特徴がわかっていないから、もっとも重要なことを説明できない。 VPC にとってはホストマシンと仮想マシンの間での操作の切り替えは 重要ではないのか？ とりあえずついている GUI は不要で、常駐させて 動かすのがメインで、切り替えは不要なのか？ そうういユーザもいるかも しれないが、だとすると、ホストマシンの shutown も仮想マシン内で できるようになるのか？ それとも VPC はサーバ上で実行するための ものか？

VPC 試用版というが、気分は限りなくベータ版だ。

しかし、勝手に広告ウィンドウを開いていたのは誰なのか？ ウィンドウの タイトルには NetFlash とあったような。Windows Messenger が 食った URL をそのまま表示しているだけかもしれない。だとすれば Windows Messenger はほんとうにあぶない。ウイルスを注入する URL を Windows Messenger のユーザアドレスあてに送りまくるとか、 もしかすると Messenger 用のアドレスは関係なくて Messenger の 待ちうけアドレスとポートにそれなりのデータを突っ込むだけで 特定の URL を開かせることができるかもしれない。

東京地底インフラマップも非常におもしろい。1964 (昭和 39) 年から 5 段階に分けて共同溝の施工区間が地図上に表示されており、これが まさに現在の東京の通信を支えているということがわかる。 共同溝内のマウント状況を見ても、電力と通信がだいたい同等の 分量であることがわかる。 しかし、マシンは良くなったはずなのだが、昔のほうが工事区間は長い。 現在の工事区間は 1964-1973 年の期間の工事区間の 20% 以下か？ ロボットが工事すればもっと長くなりそうな気もするが、不思議だ。 予算がないので、こんなに宣伝しなければならないのか？

循環と再生の 1424m - 地下 40m でおきていること、にある地下の 地層の図もおもしろい。

しかし、トンネルというものは長年経過するとだんだん垂れてくる。 補強のしかたによるのだろうが、トンネルの寿命というものはいったい 何年なのか？

JP DNS - a.dns.jp, e.dns.jp | RIPE NCC dnsmon DNS monitoring | JPRS: DNS 関連技術情報

• iアプリの端末ごと画面領域
• DoJa 3.5 プロファイル
• SH900i のプロファイル
  • JAR ファイル 100KB まで
  • ScratchPad 400 KB まで
  • iアプリの表示領域:
    メイン 240 x 252 pixel (Panel, Canvas クラスとも)
    サブ 160 x 120
  • ヒープ容量: 8MB
  • デフォルトフォント: 12 x 12 pixel (小さくて読めない)
  • カラー 26 万 色 (262K color/18 bit color/RGB 3-3-3 color)

• Flash の場合はフォントは 24 x 24 dot
  iモード向け Flash (TM)にもひかれるものがあるが今日はやめておく 。

• DoJa-3.0:
  • com.nttdocomo.device.location.* は F505i GPS のみ
  • com.nttdocomo.ui.Graphics:
    clipRect(), Canvas double buffer (lock(), unlock()) が標準 API に。
  • IrDA: GET, PUT 1 回のオペレーションで 100KB まで。DoJa-2.0 では 30KB まで。
  • IrLAP 接続パラメータ: 9.6Kbps, 38.4Kbps, 115.2Kbps
    データサイズ: 64byte, 128byte, 256byte
    Link Disonnect/Threshold Time: 3秒 (Threshold=0秒), 8秒 (Threshold=3秒)
    IrMC Low Power Option 対応のため通信距離は屋内で 20cm 程度まで。
  • 赤外線リモコン API:
    com.nttdocomo.device.IrRemoteControl
    com.nttdocomo.device.IrRemoteControlFrame

    赤外線リモコンの動作のしくみについても詳しい説明があり、 よい文書。

    • データフレームの送信間隔: setFrameDuration()
    • データフレームの繰り返し送信回数: setRepeastCount()
    • スタート部の形式: setStartHighDuration(), setStartLowDuration()
    • ストップ部の形式: setStopHighDuration()
    • ビットデータの値: setFrameData()
  • GetSysInfo: アイコン情報: メール受信常態、電波郷土、電池残量、マナーモード状態を 参照できる。
  • AppTrace: デバッグ情報を表示できる。
  • AllowPushBy: 赤外線またはバーコードから特定 iアプリを起動可能。
  • ダウンロード即起動アプリ可能: ilet
• DoJa-3.5 の変更点:
  
  • API のクラスの移動: バーコード認識、イメージマップ、 パレットつきイメージ、スプライト
  • com.nttdocomo.ui.Graphics: アフィン変換つきイメージ描画
    各座標ごとに行列変換をかけることができる。自由な拡大縮小、回転が可能。
  • com.nttdocomo.util.Base64: Base64 エンコーダ/デコーダ
    (わざわざ DoCoMo のクラスに作るべきものか？)

• ↑ com.nttdocomo.opt.device の FingerprintAuthenticator はおもしろそう。 端末内のすべての登録済みの指紋データとの照合、または 登録済みの指紋データのうち指定した一つの指紋データとの照合が 行える。
  照合命令 (authenticate()) 呼び出すと、ネイティブの指紋認証機能が 呼び出され、Java アプリケーションはいったんサスペンドされるという。 指紋認証が終了すると、Java アプリケーションは復帰 (resume) する。 全件照合の場合、成功するとその指紋データのエントリ ID を返す。

  ↓ どの程度合っている、という情報は見当たらない。 本来のバイオメトリクスの使い方からは遠い。

• ↓ 「ネイティブのスケジューラ機能にアクセスする手段を提供する」
  という com.nttdocomo.system.Schedule だが、ウソ。 「管理機能」というものではなく、「アクセス」はできない。 ただ新しい予定を追加登録できるだけ。ブックマークも同じく 新規登録のみ。

  だいたい、「スケジューラ」とかいうけどそんなえらそうな ものなのか？ 昔から IrDA の I/F でも全件入出力か 一件追加しかなかったがいまだにそのまんま。PDA にはなりそうにない。

RBB TODAY のスピードテスト だと、

SPEED 2.0 (speed.rbbtoday.com)
Date: Thu Apr 22 06:48:55 JST 2004
  Download : 7.50Mbps
  Upload   : 5.04Mbps

フレッツコネクト:

• ルータ配下でも同時に利用できる端末は 1 台のみ
• .connect は 172.0.0.0/8 へ
• ソフト: http://www.flets.connect/
• 経路: http://routing.flets.connect/routing.html

エリア内速度測定サイト接続:

• PPPoE ユーザ名: speed@speed.flets
• PPPoE パスワード: speed
• IP アドレス: 自動取得
• DNS サーバアドレス: 自動取得
• サイト URL: http://flets.speed/

東京エリアでのスピードテスト結果は 5.8-6.6Mbps 程度。 コンテンツ用スピードテストも同じ結果だった。

しかし、JavaScript 一行のみでリダイレクト。前にもこの日記に書いたが まだ同じだった。しかし、Content-Location: の値もよくわからん値だ。 これを見せて何がしたいのだろうか？

Mobile: 有楽町で SH900i を手にして web を見ようとしたら、何度やっても 違うサイトや imenu までもが「接続できません」とのこと。 おかしい！ と思ったがデュアルネットワークで SH900i は待機状態に なっていたからだった。しかし、ただ「接続できません」じゃ何も わからないよなぁ。とに。ひどいエラー表示。

勉強用とはいえ、疲れる＞SH900i

• 現象: UTF-8 で Google API に送った文字列が もういちど UTF-8 に変換されているように見える。
  そのため、Google はタイ語のようなページを検索結果 として返してくる。
  そのタイ語のような検索結果には PDF もあったのだが、 Acrobat Reader で開くと、ちゃんとそれらしきタイ語 のような文字が読めるところがえらいのだが。

• SOAP::Lite を使っていたが、SOAP::Lite に渡す文字列変数に、 この文字列はすでに UTF-8 になってますよ、という意味の UTF-8 フラグを立てると問題なく使えるようになった。

  use Encode;
Encode::_utf8_on($q);

• デバッグのため、SOAP::Lite も LWP も使わず、HTTP ヘッダと SOAP のメッセージを自分で作って socket() で送ってみた。 それでも動いたので SOAP::Lite もいらないかと思う。 返ってきたメッセージのパースも正規表現で簡単にできるし、 現在の Google API 程度であれば NoXML のような使い方も 十分ありだろう。WSDL のファイルも、いつもは手元に 置いておいて、自動的に更新しているわけではないし。 とはいえ Google が Google API を 2002/8 以降、改良していない のも気になる。やはり重くて遅いのか？＞SOAP

• 別の方法として、Google Hack で紹介されている NoXML と LWP を 使った方法を試してみたが、 LWP::Protocol::HTTP が使っている syswrite() のところで UTF-8 の文字列を含んだ XML 形式のリクエストを送ろうと するところで、500 Wide character in syswrite という エラーメッセージを出力して、リクエストも送らずに 処理を停止してしまう (LWP: libwww-perl-5.76)。 結局、LWP では UTF-8 などのバイナリを含むデータは 入出力できないかもしれない。www-formed-encoded が 前提だとすれば、全部 base64 でエンコードされているのだろうが。

  時代遅れを感じる。なお、 perl -C0 で Unicode feature をすべて disable してみたが 影響がなかった。Wide char を出力するのが違反らしいので -X も使ってみたがやはりだめ。LWP は XML プログラミングに 向かないかも。

• あと、Google API に送る HTTP ヘッダには以下のように 文字コードを指定した Content-Type: ヘッダを入れないと、 Google の側で自動的にもういちど UTF-8 に変換してしまう。

  Content-Type: text/xml; charset: utf-8

  ということは、まだ試していないが、EUC-JP などで Content-Type: text/xml; charset: euc-jp などとして検索文字列を送ると、 自動的に UTF-8 に変換されて検索できてしまうのかもしれない。 Google API ではすべて UTF-8 のこと、とあるが、そんなことくらい やってしまっても不思議はない。当然あってしかるべき処理だ。

• それから、SH900i は UTF-8 でも使えるし、2 種類の 大きさの文字が使える。けっこうやるな＞SHARP。 これならもっとリッチな表示をしてもいいぞ。

今日のシビれる CODE:
$soap_request =~ s/\$(\w+)/$args{$1}/ge;