My Tracks crash
自転車で遠出するときに My Tracksを使っているんですが、最近バージョン1.1.10にアップデートしたところ頻繁にクラッシュするようになりました。（ログをみる限りセンサーがらみ）
http://code.google.com/p/mytracks/downloads/detail?name=MyTracks-1.1.9.apk
から一つ前のバージョン(1.1.9)がダウンロードできるので、戻したところ動くようになりました。
（「設定」＞「アプリケーション」＞「提供元不明のアプリ」にチェックをいれる必要あり。インストール後にはチェックを外しておきましょう）
http://code.google.com/p/mytracks/downloads/detail?name=MyTracks-1.1.9.apk
から一つ前のバージョン(1.1.9)がダウンロードできるので、戻したところ動くようになりました。
（「設定」＞「アプリケーション」＞「提供元不明のアプリ」にチェックをいれる必要あり。インストール後にはチェックを外しておきましょう）
スマートフォンをカーナビとして使う実験
■目的
カーナビとしてCarrozzeriaのDVDカーナビ(AVIC-DRV220を使っているのだが、タッチパネルが少々いかれてきた（タッチした点がずれたり、何もしていないのに反応したり）。また、持っている地図ソフトも古くなってきたので、そろそろ買い替えどきかなと思っているのだが、新しく買うと高い。
一方、最近ではスマートフォンにカーナビ機能がついている。もし、これが十分に実用的なら買い替え不要ってことになる。
ということで、スマートフォンがどこまでカーナビとして使えるか実験してみることにした。
事前の懸念点は、センサーの貧弱さと画面の狭さ。
センサーに関しては、専用カーナビがGPS+加速度センサー+車速パルス+ジャイロの組み合わせであるのに対し、一方のスマートフォンはGPS+加速度センサー+コンパスのみ（後ろ２つはそもそも使われているのか不明）。画面に関しては、DRV220が76×143.75mmあるのに対し、93×53mmと約3倍の差がある。
■実験方法
機種はXperia acro(docomo)で、今回試したソフトは
・Googleの「ナビ」
・docomo/ゼンリンの「地図ナビ Powered by いつもNAVI」
の２本（途中で切り替え）。
ルートは、都内＋高速＋郊外の片道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)は２台持ち（会社のiPhoneがある）で解決するので、気が向いたら試してみる予定。
カーナビとしてCarrozzeriaのDVDカーナビ(AVIC-DRV220を使っているのだが、タッチパネルが少々いかれてきた（タッチした点がずれたり、何もしていないのに反応したり）。また、持っている地図ソフトも古くなってきたので、そろそろ買い替えどきかなと思っているのだが、新しく買うと高い。
一方、最近ではスマートフォンにカーナビ機能がついている。もし、これが十分に実用的なら買い替え不要ってことになる。
ということで、スマートフォンがどこまでカーナビとして使えるか実験してみることにした。
事前の懸念点は、センサーの貧弱さと画面の狭さ。
センサーに関しては、専用カーナビがGPS+加速度センサー+車速パルス+ジャイロの組み合わせであるのに対し、一方のスマートフォンはGPS+加速度センサー+コンパスのみ（後ろ２つはそもそも使われているのか不明）。画面に関しては、DRV220が76×143.75mmあるのに対し、93×53mmと約3倍の差がある。
■実験方法
機種はXperia acro(docomo)で、今回試したソフトは
・Googleの「ナビ」
・docomo/ゼンリンの「地図ナビ Powered by いつもNAVI」
の２本（途中で切り替え）。
ルートは、都内＋高速＋郊外の片道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)は２台持ち（会社のiPhoneがある）で解決するので、気が向いたら試してみる予定。
canvasのglobalCompositeOperationの計算式らしきもの
（5/13追記あり）
canvas(HTML5)のglobalCompositeOperationがどういう計算をしているか気になったので調べた。
以下は、webkitのソースをGoogleコードサーチで検索した結果。
globalCompositeOperationはCanvasRenderingContext2D#setGlobalCompositeOperationで実装されていると思われる。ここからGraphicsContext#setCompositeOperationが呼ばれているが、GraphicsContextは各プラットフォーム毎に実装されるものらしく#if PLATFORM(xxx)が沢山並ぶなんとも面倒そうな感じ。とりあえずAndroidで使われているskiaというライブラリを使う実装を見るとglobalCompositeOperationの値とskiaの合成モードの変換表とskiaの合成モードでの変換式をコメント中に発見。
きれいに整形したり、転載するのはめんどうなので、知りたい方は上記リンクを確認してください。
canvas(HTML5)のglobalCompositeOperationがどういう計算をしているか気になったので調べた。
以下は、webkitのソースをGoogleコードサーチで検索した結果。
globalCompositeOperationはCanvasRenderingContext2D#setGlobalCompositeOperationで実装されていると思われる。ここからGraphicsContext#setCompositeOperationが呼ばれているが、GraphicsContextは各プラットフォーム毎に実装されるものらしく#if PLATFORM(xxx)が沢山並ぶなんとも面倒そうな感じ。とりあえずAndroidで使われているskiaというライブラリを使う実装を見るとglobalCompositeOperationの値とskiaの合成モードの変換表とskiaの合成モードでの変換式をコメント中に発見。
きれいに整形したり、転載するのはめんどうなので、知りたい方は上記リンクを確認してください。
ActionScript1.0のif文の展開
知っている人には有名な話（自分用メモ）。
ActionScript1.0(Flash Lite 1.1)でif文を書くとき、&&や||をつかうと、非常にいけてないバイトコードに展開される。
例えば A && Bとした場合、「Aが真じゃないとBは評価さえされない」というのを実現したかったんだと思うんだが、もう少しなんとかして欲しい…
ちなみに、上記では条件式を簡単にAと書いているが、もしvar1==var2みたいな文だったら、Aの「すべて」の場所に
ActionScript1.0(Flash Lite 1.1)でif文を書くとき、&&や||をつかうと、非常にいけてないバイトコードに展開される。
例えば A && Bとした場合、「Aが真じゃないとBは評価さえされない」というのを実現したかったんだと思うんだが、もう少しなんとかして欲しい…
| ActionScript | バイトコード |
|---|---|
if(A) { | push A |
if(A && B) { | push A |
if(A && B && C) { | push A |
if(A||B) { | push A |
if(A || B || C) { | push A |
ちなみに、上記では条件式を簡単にAと書いているが、もしvar1==var2みたいな文だったら、Aの「すべて」の場所に
push "var1"なんてコードが展開されてしまう。
getVariable
push "var2"
getVariable
equals
Railsで、１対多のmodelを、Ajaxを使ったフォームで保存する方法
１対多の親子関係のモデルをWebから入力する際に、１つのフォーム（nested object formsと呼ぶらしい）で済ませたい場面がある。例えば請求書の入力画面みたいなやつ。
そういう場合はaccepts_nested_attributes_forとfields_forを使えばできるよ〜、というサンプルはWeb上にたくさん見つかる。
しかし、ほとんどは子の入力欄の数が固定のものばかり（追加したい分だけ事前にコントローラーで子のモデルをbuildしておく必要がある）で、JavaScriptつかって入力欄を増減させたりするサンプルはなかなか見つからない。あるにはあるけど、トリッキーなコードだったり冗長だったりする。FormBuilderの取り回しやaccepts_nested_attributes_forの受け付けるパラメータの形式などを考慮すると、シンプルに書くのはけっこう難しい。
で、ようやく見つけたのがこれ。
http://railscasts.com/episodes/197-nested-model-form-part-1
http://railscasts.com/episodes/197-nested-model-form-part-2
ただし、Rails 3 の場合、ApplicationHelper#link_to_add_fieldsの最後のlink_to_functionの第２引数のhはとる必要がある（3 からデフォルトでescapeされるので２重にかかってしまう）。
そういう場合はaccepts_nested_attributes_forとfields_forを使えばできるよ〜、というサンプルはWeb上にたくさん見つかる。
しかし、ほとんどは子の入力欄の数が固定のものばかり（追加したい分だけ事前にコントローラーで子のモデルをbuildしておく必要がある）で、JavaScriptつかって入力欄を増減させたりするサンプルはなかなか見つからない。あるにはあるけど、トリッキーなコードだったり冗長だったりする。FormBuilderの取り回しやaccepts_nested_attributes_forの受け付けるパラメータの形式などを考慮すると、シンプルに書くのはけっこう難しい。
で、ようやく見つけたのがこれ。
http://railscasts.com/episodes/197-nested-model-form-part-1
http://railscasts.com/episodes/197-nested-model-form-part-2
ただし、Rails 3 の場合、ApplicationHelper#link_to_add_fieldsの最後のlink_to_functionの第２引数のhはとる必要がある（3 からデフォルトでescapeされるので２重にかかってしまう）。
