/Applications に symlink はった
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\ Simulator.app /Applications
だけコピーしたらうごくようになった。
Rakefile ファイル書いて結合するようにした。
バグをとったり高速化したりしてある程度安定していい感じになった。
サムネを表示するためにいちいち FlashAir の thumbnail.cgi というのを叩いているのが不安なので、localStorage にキャッシュするようにした。この際、サムネ画像は 30kb 前後あって大きすぎるので、canvas で一旦縮小し (この際、少し画像周辺をカットすることで中央付近を拡大してる)、toDataURL('image/jpeg') で 5kb 前後までサイズを落としてる。
しかし Android 2.x 系だと toDataURL() が全く使えないので、JavaScript JPEG Encoder を使って toDataURL を実装しなおしている。速度でるのか？ と思ったけど、デカい画像というわけでもないので、気にするほどでもなかった。
キャッシュは LRU で勝手に消えていって欲しいので、lscache というのを使ってみた。memcached と同じ感じなので簡単です。
あとロード自体も前よりもうちょっと工夫して、画面サイズを考慮し、端数が出ないように調整しながらロードするようにしてある (このほうが心理的に高速に感じるっぽい)。つまり iPhone の場合、横に 3 つしか画像が入らないので、1つ画像をロード、2つ画像をロード (ここで横が揃う)、3つ画像をロード (揃ったまま)、6つ画像をロード (揃ったまま)、6つ画像をロード…… とロードしていく。画面が埋まるまでロードしたら一旦ロードを止め、スクロールするまで待つようにしてある (autopgerize 的な)。
iPad とかでも一覧性を保ってほしいので頑張ってリキッドレイアウトにしてある。うまくおさまるようにレイアウトをJSで調整している。また、window.devicePixelRate によってサムネのサイズを調整しているので、Retina とかでも汚い感じにならないつもり (検証してないけど)。
自分は CoffeeScript が好きではない。個人的に書き捨てるコードを書くときには良いだろうけれど、継続的にメンテナンスが必要なコードに、この言語は絶対に採用してはならないと考えている。
CoffeeScript を採用することで発生するメリットについて、僕の認識を書く。当然、CoffeeScript というのが存在するためには、それ相応のメリットがあるはずだし、メリットの説明なしにデメリットとの差 (つまり採用すべきかを判定する基準) は導けないからだ。
箇条書きで
CoffeeScript は基本的には、シンプルに書きやすくすることにフォーカスされていて、例えば非同期処理が劇的に読みやすくなるとか、そういうことはない。function を -> って書けるとか、記号的な文法は書きやすくはなっても、そんなに読みやすくはならない。
確かに、CoffeeScript の導入によって、書きやすくなるコードは大変に多い。「JSではなぜこれができないんだ!」と思ったことが解消されて、かゆいところに手が届く。
しかし、継続的にメンテナンスが必要なコード (OSSとか、ウェブサービスのコードとか) というのは、書いている時間よりも、読む時間・読まれる時間のほうが多い。書くのは一人でも、読むのは複数人いるし、しばらく触っていないコードは、例えそれが自分で書いたコードであったとしても、また読解する必要がある。
CoffeeScript を読む場合、読む人には CoffeeScript の知識と、JavaScript の知識、どちらも必要だ。むしろ JavaScript を詳しく知っていなければ、CoffeeScript のメリットは理解できない。前述の通り、読む人は書く人よりも多い。書く人がいくら楽になっても、読む人にとって、CoffeeScript で書かれていることは単に学習コストの増大であり、メリットではない。
逆に、読む人にとってメリットがあれば、それは書く人にとってのメリットの何倍も嬉しいことになる。では CoffeeScript で書くことによって、JavaScript より読みやすくなるか、というと、そうでもない、と自分は思っている。function が -> になることで読みやすくなるか? 括弧を書かないと読みやすいのか? タブによるインデントの強制は読みやすさに貢献するかもしれないが、これは単にコーディングルールの問題だ。
バグが起きにくい仕組みは大変素晴しいものだけれど、残念ながらそれは、CoffeeScript を採用することで読む人にかける負担 (これは場合によって何倍にもなる) を上回らないと考えている。むしろそこは、JSLint などで、書く人が気をつける、すなわち負担をうけて解決すべきだと考える。
将来 CoffeeScript に、使うと超読みやすくなるよマジやばい!!! っていう機能が入るといいと思いますが、そうでないなら、絶対に OSS とかをこれで書くのはおすすめできない。
CoffeeScript が現状のままだと、こんな未来が想像できます。
「うわ、これおれが CoffeeScript 期に書いたやつかよ。この言語オワコンって言われてから何年経ってんだ…… もう文法覚えてねーな。あ〜終わりゆく言語の文法を学びなおすのか……まじめげるな……」
FlashAir に搭載されている HTTPD をエミュレーションする Plack::App::Emulate::FlashAir というのを書いた。SD カードマウントして書きかえて実機に直接アクセスするでもいいんだけど、それだと、書きこみで待たされたり、接続している間ネットができなかったりする。
機能は以下の通り
List.htm をリライト (デザインかえたいとか) するとか、別途機能をちょっとつけたいときのデバッグに便利だと思う。
あと、SDカード内のファイルを最新順に表示するページをつくった。
を FlashAir のカード内のどっかにおいて、アクセスしたら動くとおもう。iPhone と Android でまぁまぁいい感じになるように調整した。
JSDeferred のサンプルコードの殆どは、pre に書いてあるやつをそのままJSで実行する形になっている (二重に書いていない)
その中で console.log() とかを使っているけれど、デモなので console.log() をブラウザ側ではなく、ページ側に表示させたいと思い、それらの console.log をフックしている。この場合、評価したいコードは文字列として存在するので、Function オブジェクトを使って console のダミーを作って実行するようにした。
new Function('console', code)({ log : function () { ... } });Function オブジェクトの引数の名前を console にして、実行するときに代替オブジェクトを渡すようにした。すなわちこの場合 console はローカル変数になっている。
こうすることで、元々の console.log には一切手を加えず、このコードを実行している間だけ、console オブジェクトをさしかえた。一時的に大本の console.log を差し替えるやりかたは、非同期なコードがまざると大変なので、いい思い付きをした、と自画自賛しました。