fchiba memo

カテゴリ: 未分類

SPDYのパケットを覗きたくて、spdyshark(WiresharkのSPDY plugin)をビルドしたらハマったのでメモ。結果的にはできてない。

配布元の手順はここ。
http://code.google.com/p/spdyshark/wiki/BriefInstallInstructions

$ ./autogen.sh
エラーが起きるので AG_CONFIG_HEADER -> AC_CONFIG_HEADERS に変更する

configureするとライブラリがいろいろ足りないので、brewで追加。

$ brew install gtk
$ brew link --force cairo
$ brew install pixman
$ brew link --force pixman
$ brew install freetype
$ brew link --force freetype
$ brew install fontconfig
$ brew link --force fontconfig
$ brew install libpng
$ brew link --force libpng

抜けあるかも。keg-onlyをlinkしまくってるが副作用は大丈夫か???

$ PKG_CONFIG_PATH=/usr/X11/lib/pkgconfig:$PKG_CONFIG_PATH ./configure --with-ssl

$ make
libdissectors_la-packet-rtmpt.o で固まる

$ CFLAGS=-O0 PKG_CONFIG_PATH=/usr/X11/lib/pkgconfig:$PKG_CONFIG_PATH ./configure --with-ssl

ビルドはできて起動はする。が、SSLのデコード自体ができない。Why?
最新のビルド済み WiresharkだとOK。

ここで一旦断念。

同じアプリ(eclipseとかxcodeとか)を複数インストールする場合などに、アイコンを加工したいことがある。その場合の手順。

1. Hoge.app/Contents/Resources にあるアイコン(icns)をプレビューで開き、tiffで書き出す。
2. 適当に書き換える。ImageMagickならこんな感じ
> convert Xcode.tiff -fill red -pointsize 256 -draw "text 600,900 '4.4'" -resize 256x256 Xcode_4_4.tiff
3. tiff2icns でicnsに変換してから書き戻す(バックアップとってから)

■目的
カーナビとしてCarrozzeriaのDVDカーナビ(AVIC-DRV220を使っているのだが、タッチパネルが少々いかれてきた(タッチした点がずれたり、何もしていないのに反応したり)。また、持っている地図ソフトも古くなってきたので、そろそろ買い替えどきかなと思っているのだが、新しく買うと高い。

一方、最近ではスマートフォンにカーナビ機能がついている。もし、これが十分に実用的なら買い替え不要ってことになる。

ということで、スマートフォンがどこまでカーナビとして使えるか実験してみることにした。


事前の懸念点は、センサーの貧弱さと画面の狭さ。
センサーに関しては、専用カーナビがGPS+加速度センサー+車速パルス+ジャイロの組み合わせであるのに対し、一方のスマートフォンはGPS+加速度センサー+コンパスのみ(後ろ2つはそもそも使われているのか不明)。画面に関しては、DRV220が76×143.75mmあるのに対し、93×53mmと約3倍の差がある。



■実験方法
機種はXperia acro(docomo)で、今回試したソフトは
・Googleの「ナビ」
・docomo/ゼンリンの「地図ナビ Powered by いつもNAVI」
の2本(途中で切り替え)。

ルートは、都内+高速+郊外の片道50km。最悪とんでもない指示をされても、なんとかなる慣れた道を選んだ。

事前準備として以下を購入。
・シガーソケットをUSBに変換するもの(elecomの投げ売り100円)
・オートバックスで買った車載ホルダー(メーカー忘れた)


■結果
(1) センサー
地図の追随に関してはほとんど問題なし。
進行方向を地図の上にする機能も、信号待ちの低速時でさえほとんど異常なし。

意外にも今回の実験ではセンサー由来の部分での不便さは感じなかった。

都内であっても、それほど回りに高い建物がなかったせいかもしれない。
あと、トンネルに入ると動きが止まるが、やはりほとんどトンネルがなかったので、特に問題は発生せず。
(新宿のようなビル群や首都高のようなトンネル内分岐では問題があるかもしれない)


(2) 画面の狭さ
こちらもそこまでは気にならず。
画面サイズは、縦の大きさは専用品もスマートフォンも変わらず、違うのは幅のみ。
地図は、基本的に進行方向が上なので「曲がった先ですぐ曲がる」ような場合以外はそれほど問題にならない。

さらに「地図ナビ」の場合は、曲がった先の次の音声案内がほぼ必ず入る(「50メートル先右折です。その後100メートル先左折です」みたいな感じ)ため、こちらはDRV220より親切。


地図以外の情報量に関しては、googleナビは全体的に足りない感じ。たとえば、高速道路で次はどのICなのか?とかの表示がないなど。
「地図ナビ」は特に不満を感じず。旧世代のカーナビよりは圧倒的な高精細の液晶を使っているため、画面が狭くても割りと詰め込める。



(3) 操作性
リモコン/ボタンなしはつらい。

・信号待ちなどで拡大縮小スクロールして、先の道を調べる
・オートリルートなどの可否を応える
などのシチュエーションでナビを操作する場合があるが、視線を前を向けたまま手元を見ずに操作することができないのは非常に不便。

ガラケーvsスマートフォンという一般的なユーザービリティの文脈においても、「ボタンのクリック感」というフィードバックがないことは大きな欠点だと思っているが、それが決定的に現れている感じ。

これは、BluetoothなりUSB接続なりのカーナビ専用リモコンでも発売されなければ解決されないだろう。


(4) ルート探索
明らかに劣る。

DRV220の場合、最初にルート探索した場合に出てくる候補に比較的バリエーションがあり、その中から自分にとって望ましいルートを選ぶことができる。しかし、Google「ナビ」もゼンリン「地図ナビ」も選択肢はかなり少なく、ほぼ高速の利用有無それぞれで最短のみの感じ。

例えば、今回の実験では、同じ高速を使うルートでも「最短距離だが高速代が1400円」と「少し離れたICを使って遠回りになるが高速代700円」の2通りの行き方がある。DRV220の場合、基本的には両方が候補に出てくるし(なぜか出ないこともある)が、スマートフォンではでてこなかった。

また、ルートを外れたときのリルートについても、DRV220では「現状の場所+進行方向から最適なルート」を選んでいるような印象を受けるが、スマートフォンではとにかく元ルートに戻そうとする。
これは抜け道に入ったりした場合に顕著で、スマートフォンでは明らかにそのまま進んだほうが最短になる場合でもUターンさせようとするケースが多々発生した。

このあたりは純粋にソフトウェアの問題で解決するのだから頑張ってほしいところである。


あと、到着予想時刻についても差があるが、こちらは良し悪しというよりは癖の問題。DRV220は現在地点からスムーズに走れた場合の時間が出るようで、楽観的過ぎる。一方「地図ナビ」はそれまでの平均速度を元にしているらしく混み具合も反映されるが、直近の速度に引っ張られすぎてガクガク時間が変化する。
いずれにせよ当てにならないので、まあ参考程度に使えばよい(強いて選ぶならDRV220で、楽観的到着時間+渋滞情報+経験&勘で補正する)


(5) 携帯との兼用の問題
車から離れる場合に必ずホルダーから外す必要があり面倒である。
また、走行中に着信があるとナビ画面が見えなくなってしまう。かといって電波をオフにすると地図データが取得できなくなってしまう。

あと、車内では音楽プレイヤーからFMトランスミッターで音を飛ばして聴くことが多かったのだが、スマートフォン購入後は音楽プレイヤーを持ち歩かなくなってしまった(人にあげてしまった)ので、それができなくなってしまう。なんでもかんでも集中させるのは考え物である。

■結論
もし現在ナビを持っていないとすれば、スマートフォンをナビとして使うことは十分実用的に感じた。

ただ、今もっている専用品をすぐに置き換えられるかというと、そこまでのものではない。やはり、(多少壊れかけていても)ルート検索というナビの根本的機能の優位性や専用品ならではの細かな使い勝手は譲れない。完全に壊れるまでは今のカーナビを継続使用する予定。

壊れてしまったら……そのとき考えることにしよう。


ただし、(4)は他のナビソフトではそんなに問題が無いかもしれないし、(5)は2台持ち(会社のiPhoneがある)で解決するので、気が向いたら試してみる予定。

[ガジェット]たった600円でオライリー本をiPadやKindleで読む。すてき。- このブログは証明できない。

を真似してkindle用ファイルを作ってみたら、少しはまったのでメモ。

購入したのは Programming PHP(エクステンションの作り方が知りたかった)。

まず、
> Payloadというフォルダの中にappファイルがあります。
は、Windowsだと "(アプリ名).app" フォルダだった。

また、kindelgen を実行すると、
Error(prcgen): TOC section scope is not included in the parent chapter:BCMath Arbitrary Precision Mathematics ("BCMath~"というのは書籍内に含まれる章の名前)
というエラーが発生した。

エラーメッセージでググッたところ
http://www.mobipocket.com/forum/viewtopic.php?p=49267&sid=494a2df12b48a1e8fdca8ae0e7bfb752
がヒット。どうも、「toc.ncx」と「content.opfのspine要素」の整合性が取れていないためらしい。

toc.ncxの該当部分は
        <navPoint id="id2424422" playOrder="1004">
<navLabel>
<text>B.1. Optional Extensions Listing</text>
</navLabel>
<content src="apb.html#progphp2-APP-B-SECT-1"/>
<navPoint id="id2424885" playOrder="1005">
<navLabel>
<text>BCMath Arbitrary Precision Mathematics</text>
</navLabel>
<content src="re514.html"/>
</navPoint>

となっているが、id2424422とid2424885の両方ともspineに含まれていない。
(id2424422はアンカー指定となっているためかmanifest要素にさえ含まれていない。apb.html自体はさらに親のid2424369として含まれている)

試行錯誤の結果わかったのは、navPointに含まれるidは親も子もspineの中に記述されていないと駄目らしいということ。

・content.opf の spine にid2424885(子)を追加。
・toc.ncxのid2424422(親)のIDをid2424369(apb.htmlのID)に書き換え。

でコンパイルを通りmobiファイルが生成された。
kindle for PCで動作を確認したところ、本文は正しく表示された。ただ、目次のほうはkindle for PC に機能自体がないのでうまく動いているかどうか不明。

余談:epubファイルを作成するとき、本来はmimetypeを一番初めに無圧縮で格納しないといけないのだが、そこは適当でもkindlegenは大丈夫だった。

EMOBILE(D02NE)を使おうとしていたのだが、ドライバのインストール後に
「データ端末の通信ポートが利用できませんでした」
というダイアログがでて動かなくて困った。

いろいろ試したが、おそらく原因はVMWare Server。

カードをPCに挿すとき(ドライバがインストールされるとき)に、VMWareのサービスを落とすと動くようになった。いったん動くようになったら、VMWare Serverのサービスは立ち上げてOK。

逆に、いったん上記ダイアログがでる状態になってしまうと、ドライバをアンインストールする以外に動作させる方法は見つからなかった。
(「EMOBILE D02NEユーティリティ」と「Windows ドライバパッケージ - NEC Inforontia (d02nemdm) Modem」の2つをコントロールパネルで削除する)

以前、D01NEが使えなくてあきらめたことがあるが、おそらくそちらも同じだと思われる。

このページのトップヘ