注文しておいたKindle DX Global Wirelessが届いた。

Kindleはこれで2台目。
1台目は他の人のところへ行ってしまわれたので、手元に有るのは1台だけど。 

今まで持っていたUS版との違いは、裏面の金属カバー部分のみ。
Global Wirelessだと各国のRegulatoryがプリントされている。

現状入れているHackは以下のもの。

• Unicode Font Hack
  http://blogkindle.com/unicode-fonts-hack/
  内蔵フォントを置き換えるHack。これで日本語が読めるようになる。
• usbNetwork
  http://www.avenard.org/kindle2/usbnetwork23-0.10.tar.gz 
  USBをEthernet RNDISにしてしまうHack。これがあればTelnetやSSHでshellに侵入できるようになる。
• Anti-bunchin
  http://www.ekesete.net/log/?p=518 
  Frameworkがこけたときに、自動的にEthernet RNDISにしてtelnetを立ち上げてくれる。
  これを先に導入しておけば、文鎮にならずに済んだのにｗ
• news_auto_downloader
  Mobiなどなんでもを一定時間毎にDLしてくれる。
  ちょっとグレーな気もするが、まぁ問題ないだろう。

Wirelessがついたので、Kindle Storeで新聞でも購読してみようかなと思ったのだが、米国外には写真や画像を転送してくれないのでやめた。写真がない新聞なんて新聞じゃないだろと思ったのだが、まぁそうじゃないか。少なくとも僕は買わない。

Kindle DXはファームを2.3に上げずに使っていたので、ファームの問題だと思うが、Mobiのレンダリングが向上した模様。
PRC形式の辞書も表示されるようになった！ 

ネットワークにつながるようになったので、ちょっといろいろHackしてみようかしら。 

仕事のお話。

いわゆる非同期処理の話なのだが、あまり僕自身もこの領域は詳しくないので、調べてつつわかったことをアウトプットしてみます。

RPCを利用して処理を実行する場合、何もしないと同期処理となる。
つまりコールをして、結果が返るのを待ち、結果が返ってきたら処理を再開する。
これだと結果が返るのを待っている間は、”待つ”という処理を行うだけなので、CPUを有効的に活用できず非常にもったいない。そこで処理が終わるまで他の処理をさせておき、処理が終わったら結果を取得し、残りの作業をするという”非”同期的処理を行う必要がある。
Ajaxなどでよく利用されるXMLHttpRequestなどは非同期処理を活用しているわかりやすい例だ。

非同期処理のハンドルの仕方には大きく2つの手法がある。

• Futureに代表される、時間がかかる処理に結果をもらえる引換券を渡し、それを任意のタイミングで結果をもらいに行き処理を行うという方法
• CallbackやDeferredに代表される、処理が終わったら実行時にあらかじめ定義した関数を実行する方法

それぞれ長所短所が有るのだが、僕が作ろうとしているものにおいて、それぞれ問題がある。

• Future
  結局誰かがFutureを監視する必要がある。
• Callback
  非同期処理を行った後さらに別の非同期処理を行い、さらにその後に・・というフローではコーディング・運用両面で大変そう。

ただこれは非同期処理を呼び出すクライアントサイドで、あまり大きな問題にならない。

問題となるのはサーバサイドだ。
たとえばRPCでクライアントからリクエストを受けた後、サーバは別のホストにhttpコネクションを張り、そこから値を取るという処理をしたい場合、それぞれの処理単位で同期的に処理してしまえば楽だろうが、そうすると結局そこでブロックされてしまい、クライアントでブロックされないだけでシステム全体で見たらブロックが発生してしまう。

という問題をどのように解決したらいいか考えているのだが、まだ考え中。

また考えて考えがまとまったらエントリーに上げたいと思います。

というわけで2chにアップしたら、明朝もくれとのことだったので、明朝も作ってみた。 

こっちがIPA P明朝（プロポーショナル）

こっちが等幅

で、ついでにフォントを流し込むスクリプトも改造してみた。
今までは、毎回パッケージを作ってKindleにコピーしてUpdateしてっていう流れで、フォントを変えるにも大変だったのでMass Storageモードで見えるディレクトリにフォントをおくことで対応するようにした。

Mass Storageモードでつないだときに、
/fonts にあるフォントを置き換えることでフォントを置き換えることが出来るようになっています。具体的には、

• Mono.ttf
  どこで使われているかわからん
• Sans.ttf
  上部のバーとかメニューのフォント
• Serif.ttf
  本文とかに使われるフォント

となっているので、好きに置き換えて再起動すればフォントが適用されるようになっています。
ただし、今までと同じく、変なフォントを指定した場合最悪起動しなくなる可能性がありますので、要注意。

ダウンロードと詳細なスクリーンショットは続きから。 

[追記]

yoshiさんが、2.3用のunicode font hackを作られたみたいです。
Kindle Software Update Version 2.3に対応したUnicode Font Hack

Continue reading →

Kindle DXを購入してしばらくたつが、
unicode hack fontで導入できるDroidフォントでは気に入らないので、
練習をかねてM+IPAフォントを導入してみた。

こんな感じ。ちょっと個人的にはいまいち。

IPAフォントなので、公開して問題ないはずなので、作成したファイルを公開します。
Kindle DXでは動作を確認しておりますが、Kindle、Kindle 2では動作は不明です。

フォントの置き換えは最悪起動しなくなる可能性がありますので、
くれぐれもお気をつけください。

またこれらを使用した結果、動作しなくなったとしてもこちらでは一切サポートはできませんので、自己責任にてお使いください。

Kindle 2,DX用M+とIPAフォントを組み合わせたフォント [kindle_mplusipa_font.tgz]

[追記 2009/09/17]

明朝も作ってみました。
http://blog.nunnun.jp/amazon_kindle_dx_font_hack_2.html

IPv6のトンネルをタダで提供してくれてる
Tunnelbroker [Hurricane Electric] が、昨日東京にもトンネル終端を設置してくれた模様。 

早速トンネルを張ってみたのだが、どうやらKDDIからだと太平洋を往復してしまうみたいで、
ちょっと残念。（まぁKDDIはサービスとしてv6トンネルあるからそれを使えということかｗ）

traceroute to 74.82.46.6 (74.82.46.6), 64 hops max, 52 byte packets
1  gateway (10.10.10.1)  0.828 ms  0.464 ms  0.507 ms
2  211.18.15.34 (211.18.15.34)  4.918 ms  4.918 ms  4.512 ms
3  211.18.15.46 (211.18.15.46)  4.751 ms  4.671 ms  4.444 ms
4  nhshibuyart103h.v4.kddi.ne.jp (211.18.15.62)  5.899 ms  6.248 ms  5.894 ms
5  sjkmlsw103.v4.kddi.ne.jp (211.5.4.25)  5.852 ms  5.953 ms  7.504 ms
6  sjkmlsw02.v4.kddi.ne.jp (61.202.2.189)  6.204 ms  5.207 ms  5.145 ms
7  tkycore04.v4.kddi.ne.jp (210.168.192.5)  6.554 ms
tkycore04.v4.kddi.ne.jp (210.168.192.53)  7.064 ms
tkycore04.v4.kddi.ne.jp (210.168.192.37)  33.354 ms
8  otecbb302.kddnet.ad.jp (203.140.128.105)  7.150 ms  7.298 ms  8.649 ms
9  otejbb204.kddnet.ad.jp (203.181.97.169)  7.133 ms  6.826 ms  6.919 ms
10  pacbb002.kddnet.ad.jp (203.181.100.94)  306.598 ms  202.313 ms  207.730 ms
11  ix-pa7.kddnet.ad.jp (124.211.34.130)  122.330 ms  126.824 ms  125.322 ms
12  124.215.192.82 (124.215.192.82)  124.002 ms
203.181.104.170 (203.181.104.170)  111.577 ms  111.307 ms
13  10gigabitethernet4-1.core1.sjc2.he.net (72.52.92.70)  116.991 ms  115.286 ms  115.321 ms
14  10gigabitethernet1-2.core1.tyo1.he.net (72.52.92.238)  250.585 ms  250.835 ms  250.782 ms
15  tserv22.tyo1.ipv6.he.net (74.82.46.6)  238.623 ms  238.672 ms  238.623 ms

v6的にも太平洋を往復してしまうので、うち(KDDI)から使うのは微妙。

ただ、Asahi-netとかだと20msぐらいでいけるという話もあるので、ルータとかでv6をトンネルするにも安価でサービスを提供している事業者がいない日本において、v6の実験とかに使えてよいのではないかと思う。