blog.niw.at

Mountain LionのMessages.appを使ってみた

Thu, 16 Feb 2012 18:20:00 -0800

Mac OS Xのあたらしいバージョン、10.8、通称「Mountain Lion」の内容がちらりと発表されました。

Mountain Lionはこういう生き物なんですが、それはさておき、今回その一部であるMessages(複数形です)が一般にダウンロードできるので使って見ました。

これはこれまでのiChat.appを置き換え、iOSのiMessageに対応させるもので、実際、Messages.appと画面には表示されますが、実態は/Applications/iChat.appだったりします。

で、感想。まだベータ版なので不都合があってあたりまえなんですが現状、日本語で使う上でこまった問題があります。なんと一つのメッセージに日本語英語が混在するとiOS上で見た時にバラバラになってしまうという問題が…

Messages.appではこのように普通に表示されるのですが…

iPhoneではこんなことに…

うーむ、これテストしなかったのかなあ。なぜバラバラになるのか、プロトコルはXMPPらしいのですが説明ができるひと、@niwまで教えてください!

以下のようなツイートをもらいました。

Mac の iMessage で、欧文と和文が混じったメッセージを iOS Devices に送ったとき分割されてしまうのはフォントの問題で、Mac の方で例えばヒラギノとか和文書体を設定するととりあえず解決する。
— Hiroki Katoさん (@cockscomb) 2月 17, 2012

謎ですが、フォントをヒラギノに変えたら分割されなくなるようです。手元の環境でヒラギノにしても分割されたこともあるのでよくわかりません。

Tahoe にスノボに行って来た

Tue, 14 Feb 2012 23:20:00 -0800

まだ筋肉痛で動きが制限されています。こんにちは。

San Francisco は California 州の都市なんですが、多分カリフォルニアっていうと、こう、海! 青い空! だと思うんですが、実は雪山もあります。

今回はそんな California 州と Nevada 州の境目にある Tahoe のスキーリゾートに遊びに行ってきたというお話。

今回はいろいろ準備が後手に回ったり、予約の過程で大失敗をしたりと色々と不手際が重なったのですが、結果的にNorthstarという Tahoe の北西にあるリゾートに行きました。

San Francisco からは只今絶賛増線中の Bay Bridge を渡ってひたすら I-80 を北上する、というコースです。昨年シーズンは渋滞で4〜5時間かかった記憶があるのですが、今回は渋滞もなく途中の Sacramento で休憩しても3時間ちょっとで到着しました。

こ、これがスキーリゾート…?!

実は Tahoe は昨年シーズン記録的な大雪で、見渡す限り真っ白でしたが、今シーズンは記録的な 雪の降らなさ で1月になってからやっと雪が降り、2月になってからは全然降っていない、みたいな状態です。到着まで雪がちらほらとしか見えないので、さすがに途中で不安になりました。

今回は4名で出かけたので2br2ba(寝室2つ、トイレ風呂も2つ、の意味)のコンドミニアムを借りました。綺麗でキッチンとか暖炉とかもあり、いろいろ準備すればBBQとかも出来ます。

さて、その雪がないリゾートなのですが、さすがにゲレンデはバッチり雪があります。けっこうガリガリしていて、春スキーって感じでした。あ、スキーはしてませんが。

山頂からの光景。

ちなみに、日本ではスキー場では1,000円のカレーと相場決まっているのですが、米国では$10のハンバーガーとなります。California なので Tacos とかもあります。

これまでずっとレンタルだったので San Francisco に引っ越してからボードなどを買いました。ところが、昨年シーズンこのリゾートに来たときにビンディングのパーツを盗まれたり、その後遭難しかかるなど、ここは思い出深いリゾートだったりします。

写ってないけれど、右足のパーツを盗られ、その後交換パーツを送ってもらったりした関係で左右で色が違います。

今回はそんなトラブルはなく、かつリフト券を Fast Pass にしたのでリフト待ちが全くなくて非常に快適でした。これはオススメです。

というわけで、今度はちゃんと準備して今シーズンもうあと1回は行きたいなあと思っています!

Mac OS Xで動的ライブラリのバージョン違いの警告が出た

Wed, 08 Feb 2012 23:48:00 -0800

たまに、nokogiri.gemを使っているときに、

WARNING: Nokogiri was built against LibXML version 2.7.8,
but has dynamically loaded 2.7.3

と言われて凹むことがあります、というか、先日ありました。原因は多分Mac OS X 10.7.3にしたことなんですがこういう時に何をすればいいのかという話です。

nokogiri.gemはlibxml2を使ったRubyのXML/HTMLパーサーなんですが、ビルド時に利用したlibxml2のバージョンを覚えていて、実行時に違うバージョンを使うと文句を垂れます。というのも特定のlibxml2はバグがアレすぎてnokogiri.gemがまともに動かないのでそれを排除する目的でそういうことをしているんだと思います。

さて、こうなった時には誰が違うバージョンのlibxml2をnokogiri.gemより先にロードしているのを知る必要があります。普通は他のgemが明らかにlibxml2を使っていたりして、あぁ、こいつが違うバージョンのlibxml2をロードしてるのかーって気がつけることもあるのですが、まったく見当がつかない場合が問題です。

そこで、Mac OS Xで動的ライブラリのいろいろを司ってるのはdyldですが、その環境変数で便利なDYLD_PRINT_LIBRARIESを使います。詳しくはman 1 dyld。

DYLD_PRINT_LIBRARIES=1 ruby a_script_requires_many_gems.rb

とすると、ロードされたライブラリがずらずら出てきますので、どのタイミングで期待してないlibxml2がロードされているのか眺めます。例えば、こんな感じ。

dyld: loaded: ... /gems/memcached-1.3.1.1/lib/rlibmemcached.bundle
dyld: loaded: /usr/lib/libsasl2.2.dylib
...
dyld: loaded: ... /Kerberos.framework/Versions/A/Kerberos
dyld: loaded: ... /Heimdal.framework/Versions/A/Heimdal
dyld: loaded: ... /Security.framework/Versions/A/Security
dyld: loaded: ... /CoreFoundation.framework/Versions/A/CoreFoundation
...
dyld: loaded: /usr/lib/libxar-nossl.dylib
dyld: loaded: /usr/lib/libDiagnosticMessagesClient.dylib
dyld: loaded: /usr/lib/libbz2.1.0.dylib
dyld: loaded: /usr/lib/libxml2.2.dylib
... ↑あっ

おや、ここでMac OS Xのlibxml2が呼ばれていますね。これが原因っぽい。じゃあこれをロードした奴は誰だってことになるので、これより上でロードしているライブラリをotool -Lで調べていきます。

$ otool -L /usr/lib/libxar-nossl.dylib
/usr/lib/libxar-nossl.dylib:
    /usr/lib/libxar-nossl.dylib (compatibility version 1.0.0, ...
    ...
    /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, ...
    ... ↑あっ

ほう、libxar-nossl.dylibがlibxml2をロードした犯人っぽいですね。で、

$ otool -L ... /Security.framework/Versions/A/Security:
    ... /Security.framework/Versions/A/Security (compatibility...
    ...
    /usr/lib/libxar-nossl.dylib (compatibility version 1.0.0, ...
    ... ↑あっ

ほう、Security.frameworkがlibxar-nossl.dylibをロードしていますね。という感じで掘り進めます。で、この依存関係を呼ばれる逆順に書き出すとこうなります。

/usr/lib/libxml2.2.dylib
← /usr/lib/libxar-nossl.dylib
← Security.framework
← Kerberos.framework
← /usr/lib/sasl2/libgssapiv2.2.so
← /usr/lib/libsasl2.2.dylib ←これはotool -Lではわかりませんが、明らかですね。
← gems/memcached-1.3.1.1/lib/rlibmemcached.bundle

なんと、お前かー! まさか、memcached.gemがlibxml2をロードしているとは思いもよりませんでした。memcached.gemはmemcachedのクライアントですがXMLを使う余地など無いのでパッと見さっぱりわからないですね。多分、10.7.3でどこかの誰かがこの依存関係を創り上げたのではないかと思っていますが、今後SASL関係のやつらが全部libxml2をロードすると思うとげんなりです。

で、この場合、解決策はnokogiri.gemを素直に/usr/lib/libxml2.2.dylibを使うようにビルドしなおせばいいのですがまあ、最適解はそれぞれの状況に応じて変わるのでなんとも言えません。というわけで、原因がわかってめでたしめでたし!

おまけ - gdbで追いかける

最初、DYLD_PRINT_LIBRARIESなんて気が付かなかったのでgdbしてdlopenでブレイクポイント立ててロードしている奴らを知ろうと思いました。結果から言えばdlopenだけではすべてのdyldのロードを見られるわけではないので失敗したのですが、忘れないようにやり方をメモしておきます。この場合は、dtraceしても良いんだけど。

ここでのポイントはdlopenはデバッグ情報がないのでそのままではgdbで引数が表示できないこと。そこでx86_64の場合、rdiレジスタから順にrsi、rdx、rcx、r8、r9に引数が入ってるので、それを見ていきます。こんな感じ。

$ gdb --args ruby a_script_requires_many_gems.rb
(gdb) b dlopen  ←dlopenにブレイクポイント立てる
(gdb) r ←実行
...
Breakpoint 1, 0x00007fff93c18929 in dlopen () ←止まる
(gdb) i r ←レジスタ一覧
...
rax    0x1    1
rbx    0x7fff8cbe1000    140735554654208
rcx    0x69    105
rdx    0x9    9
rsi    0x10    16
rdi    0x7fff8cbe1980    140735554656640
rbp    0x7fff5fbfe650    0x7fff5fbfe650
rsp    0x7fff5fbfe640    0x7fff5fbfe640
...
(gdb) p (char *)0x7fff8cbe1980 ← rdi をchar *として見る。$rdi でも同じ。
$1 = 0x7fff8cbe1980 "/usr/lib/libobjc.A.dylib" ←見えた
(gdb) display (char *)$rdi ←止まるたびに出るようにする
(gdb) c ←続行
...
Breakpoint 1, 0x00007fff93c18929 in dlopen ()
1: (char *) $rdi = 0x100275210 "... /thread.bundle" ←見えた
(gdb)

便利ですね!

多分もっとかっこいい方法があるはずなので、是非@niwまで教えてください!

ドメインを移管してみるテスト

Thu, 02 Feb 2012 23:28:32 -0800

現在個人で保有しているドメインがいくつかあります。

そのうち伝統的に古い90年代に取得したある.comドメインがずーっと当時のNetwork Solutions、今のVeriSignで管理されており、その管理費用が異様に高い(年間$40くらい)なうえに、Network Solutionsのサイトが広告まみれで、なにか操作をするたびに「この機能いらない？いらない？ねえ、本当にいらない？」と聞いてきて非常にイライラするので更新時期を踏まえて移管することにしました。

移管先を探す

まず、移管先を決めなくてはいけません。条件は、手頃な値段で、うざくなくて、ある程度長い間営業している米国から使っても問題ない、.atドメインに対応している業者ということで選びました。

しかし最後の条件がキビしくてかなり絞られることになりました。最初はGoDaddyが浮かんだのですがSOPAの一件もあるのでちょっと敬遠し、結果的にNo Bullshitと言っているレジストラ、Gandiに移管することにしました。

フランスの会社です。

移管する前にネームサーバーを変えておく

ドメインレジストラを変えるということはそのレジストラが提供しているサービスも変えるということになるので、もしレジストラのネームサーバーを使っている場合はそれを予め切り替えておかないといけません。ダウンタイムが発生してもよいのならなにも考えずに移動すればいいような気もしますが、運用されているドメイン名の場合はそうもゆかず。

ということで一旦、第三者で、簡単に設定できるAmazon AWSのRoute 53に書き換えておきます。移管が終わって問題なさそうなら移管先のネームサーバーに再度切り替えるのでもいいですし、もし移管先のネームサーバーが事前に分かっていて、かつ設定できるのならそれを利用すればいいとも思います。

# そのドメインで使っているネームサーバー一覧する
$ dig NS ドメイン.名
...
;; ANSWER SECTION:
ドメイン.名.     165948  IN  NS  ns-....awsdns-....com.
...

Route 53はAmazonが提供するDNSサービスで名称の53はもちろん、DNSが使うUDPのポート番号に因んでいると思います。サインアップしてゾーンを追加して現在DNSに設定されているレコードを全部作ってから移管元のレジストラでネームサーバーをRoute 53のものに変更します。

AWSのManagement Consoleからできるので楽チン。

移管申請の前にAuthorization Codeを取得

.comなどのドメインを移管するときには、移管元のレジストラでAuthorization Codeを取得して、それを移管先に伝える作業が必要です。このあたりのやり取りで重要になるのがドメインのWHOISで登録されているメールアドレスで所有者の確認に使われます。

# WHOISを見る
$ whois ドメイン.名
...
Registrant:
Yoshimasa Niwa    メール@アドレス
...

まずDomain Protectみたいな機能がある場合はそれを外して、Authorization Codeを取得します。レジストラによって手順が異なるようですが、基本的にウェブインターフェイスで完了するでしょう。

費用の支払いと移管元、移管先からの確認

ここまで準備ができたら、移管先のレジストラのサイトで移管したいドメイン名を指定してAuthorization Codeを入力して移管費用などを支払います。

その後移管元、移管先双方から移管したいドメインのメールアドレスに対して「移管したい言うてるんだけどほんまかいな」的なメールが来ますので、リンクを踏んで「せやで」と答えておきます。この確認メールが来るまでに数時間を要しました。

移管完了

ここから待つこと数日。その日にそのままサクサク終わるかと思いきや、まったくぜんぜん。

忘れたころに移管元から移管が完了したという通知が来ます。そして移管先からも移管が完了したという通知が来てすべて完了しました。

結果的に、移管が完了するまでにさらに5日かかりましたが、そういうもののようです。ひょっとしたら手動なのかも。

Mac OS Xのパッケージファイルを操作する

Sun, 29 Jan 2012 03:00:00 -0800

Mac OS Xではアプリケーションなどをインストールするときに伝統的に.pkgで終わるパッケージが使われています。しかし、インストールする前にどんなファイルが展開されるんだろう、とか、あのインストーラーに入ってるあのファイルだけ取り出したい、みたいなことがあると思います。

そんなパッケージにまつわる基本的な操作をまとめました。基本的にTerminal.appでの操作になります。

インストールされているパッケージの一覧

$ pkgutil --pkgs

例えば、mysqlが入ってるかなーとかは、

$ pkgutil --pkgs|grep '[m]ysql'
com.mysql.mysql

となります。[]がついてるのは、そういうgrepのテクニックです。

インストールされているファイルの一覧

既にインストールされているmysqlのパッケージがインストールしたファイルの一覧は次にようにします。インストール前のpkgに対しては後述。

$ pkgutil --files com.mysql.mysq

インストールされているファイルの削除

一応pkgutilにオプションがあったんですが(--unlink)、うまく消せないし、フォルダが残ることがあるし、なんかコマンドそれ自体がなくなった気もするので、自前のコマンドを作っています。このあたりから入手してください。こういうのはrootで実行しますが、なんか重要なファイル消えちゃうかもなので、自己責任で。

インストールされているパッケージを消す

ファイルの削除ではなく、パッケージの登録を消す場合は次のようにします。

$ pkgutil --forget com.mysql.mysq

インストール前のパッケージのファイル一覧

どんなファイルがpkgでインストールされるか知るには、パッケージによって2種類の方法があります。まず、pkgが単一のファイルの場合(Flat Package File)は次のようにします。

$ pkgutil --payload-files path-to-flat-package-file.pkg

もし、pkgファイルがディレクトリ形式の場合は次のようにします。

$ lsbom path-to.pkg/Contents/Archive.bom

BOMってなんじゃらほいってことですが、Bill of Materialsという意味だそうです。詳しくはman bomで。

インストール前のパッケージからファイルを取り出す

これも2種類それぞれに違う方法が必要です。まず、Flat Package Fileの場合は次にようにしまう。

$ pkgutil --expand path-to-flat-package-file.pkg ./tmp
$ ditto -x --bom ./tmp/path-to-Bom ./tmp/path-top-Payload ./

pkgutilでFlat Package Fileからディレクトリに展開して、その中にあるBomを使ってPayloadファイルからファイルを取り出します。めんどくさい…

ディレクトリの場合は次のようにします。

$ pax -rzf path-to.pkg/Contents/Archive.pax.gz

また別のコマンド… なんだか様々な圧縮方法とファイル形式があって、非常に大変です。

他にもArchive.bomがない場合とかいろんな形式がある雰囲気なので、もっと良い方法があったら@niwまで教えてもらえると嬉しいです!

boundioで電話を鳴らす

Tue, 17 Jan 2012 00:57:00 -0800

さっきTwitterでちらっとboundioというのを見かけたので試して見ました。簡単に言えばHTTP POSTで電話を鳴らせるというサービスです。

なにはともあれアカウント作る
管理画面の「音声ファイル管理」で音声ファイルをアップする。さくっとMacのsayコマンドで作りました。
```
say -o hello.aiff "hello, world"
```
アップロードしたファイルのIDを覚える。多分最初は000001。

curlでお試しURL(サイトではデベロッパーツールというわかりにくいネーミング。)にHTTP POSTする。

$ curl -v 'https://boundio.jp/api/vd1/<自分のユーザーID>/call' \
-d 'key=<デベロッパーツールに載ってるアプリケーションキー>' \
-d 'tel_to=<電話番号>' \
-d 'cast=file(<さっきのアップロードしたファイルのID>)'
{"success":"true","_id":"****"}

050の番号から電話がかかってくるらしい

電話がつながったかどうか後で調べるにはこうする

$ curl -v 'https://boundio.jp/api/vd1/<自分のユーザーID>/tel_status?
  key=<デベロッパーツールに載ってるアプリケーションキー>'
[{"success":"true",
  "result":[
    {"_id":"****",
     "_from":"050********",
     "_to":"+1415*******",
     "_start":"2012-01-17 17:34",
     "_end":"",
     "_duration":"0",
     "_status":"架電待機"},
    {"_id":"****",
     "_from":"050********",
     "_to":"080********",
     "_start":"2012-01-17 17:28",
     "_end":"2012-01-17 17:29",
     "_duration":"34",
     "_status":"架電完了"}, ...

ドキュメントにはtel_idが必須と書いてあるけど、指定しないと履歴が取れる。

ところで、電話がかかってくる「らしい」、というのは、実は米国の番号を試したのですがAPI呼び出しは成功するものの電話かからず。残念ながらダメだったので、日本にいる人の協力を仰いだわけで、本当に電話が鳴ったかどうかは僕にはわからないのです。

喋らせる音声は自分でアップしたファイルを組み合わせたり、合成音声で番号を喋らせたりできるようです。

というわけで、~~イタ電~~例えば、電話認証やちょっとアレげな通知をするウェブアプリとかに使えそうですね!

2011年を振り返ってみる

Mon, 02 Jan 2012 20:29:00 -0800

2010年も同じようなことをしていましたので、2011年も数字で振り返ってみようと思います。

687人、140文字をお届け

あまりこのブログでは仕事や職場のことを書いていませんが、今働いてるTwitterはこの1年でさらに何倍にも成長しました。二度同じことがない、とてもエキサイティングで楽しい1年でした。

59,693マイル、15区間

2011年は太平洋を何度か往復しましたが、結局、太平洋横断だけで終わりました。是非、2012年こそはヨーロッパ方面にも等にも行けるように頑張りたいと思います。

35回レンタル

カリフォルニア州のいろいろな所に車で出かけました。あとハワイ州とニューヨーク州にも行ったかな。いい加減、車を手に入れようと思います。

62,708通

送受信した電子メールの数。だいたい、8分あたり1通の計算。まだ健全ですね。

1,679コミット

去年よりはちょっと多いかな。平均5時間あたり1コミット。Make things!

2012年、あるいは平成24年

どの数字も少しだけ去年より増えて、よりアクティブな1年だったということがなんとなくわかりました。2012年もたくさんの友達を世界中につくって、新しいものいっぱいつくって、エキサイティングで楽しい年にしたいと思います!

今年もよろしくお願いします!!

New Yorkの焼き鳥事情

Fri, 23 Dec 2011 01:33:00 -0800

先日、New Yorkでブランチをした店から出てきたらいきなりコワーカーに声をかけられて、まさに同じ店に入ろうとしていた所だったと。多少有名な店だったのは事実ですが、ばったり街で人に会うことがまさかNew Yorkまで出かけていって起こるとは。

さて、先輩のブロガー@drikinにラーメン以上に恋しい美味しい焼き鳥と言わしめた焼き鳥ですが、ちょっと前にタイムラインでこんなツイートを見かけたので、

Like yakitori? In New York? Come get #truechicken at Tori Shin torishinny.com/about-us/ Pre-Nationals omakase with @yarrow :)
— crystalさん (@crystal) 12月 13, 2011

これは行かねば! ということで今回は前回に引き続きNew Yorkの焼き鳥編です。

鳥心

Upper Eastといっても1st Ave.沿い、Lexington Ave.から極寒のなかを歩いて数分いきなり日本風の門構えの店、鳥心が現れます。

店内は、なんていうか日本です。日本の大企業の方々の駐在員さんがスーツ姿でお食事をなさっていて、いやはや格差社会とか思ったのですが、それはさておき。

メニューは単品をランダムに選ぶ方法とコースのおまかせがあって、おまかせは分量的にも内容的にもかなり満足できました。

最後に親子丼とスープと、ちょっと鳥尽くしすぎる! ってくらい楽しめます。

デザートのしそシャーベットはアメリカのデザートではまずありえない甘さ控えめで驚きです。

お値段は、だいたい日本円で6,000円くらいでした。つまり$80なんですが、お安いですね(ドルが)! ちょっと歩く場所にあるので行きづらいかもしれませんが、たまに焼き鳥が恋しくなったときは6時間の飛行機とさらに数百ドルはらって食べに来るのもありかなと思いました。

ちなみに、帰り際にSan Franciscoに出店して下さい! と、お願いしておきましたが軽く笑って流されてしまった感があってガックシです。

合わせて読みたい → New Yorkのラーメン事情

New Yorkのラーメン事情

Tue, 20 Dec 2011 01:33:00 -0800

週末を利用してNew Yorkに遊びに行きました。San Franciscoからは飛行機で5〜6時間と、成田からですと、Singaporeちょっと手前くらいと同じ距離があります。飛んでる間はずっと北米大陸上空ですので、gogoによるインターネットが使えるのですが、それはまたの機会にブログすることにして、今回はラーメンのお話。

「San Franciscoが東京のラーメンにやられたようだな…」「フフフ… San Franciscoは米国べいこく都四天王としてんのうの中でも最弱」「ラーメンごときで消えるとは北米都市の面汚しよ…」

はっきり言って、New Yorkのご飯クオリティはSan Franciscoとは比べ物にならないクオリティです。ラーメンも例外じゃないです。

せたが屋ニューヨーク

まずひとつめ、せたが屋。

East Villageのなんだかよく見ると和食っぽいなぁ、みたいな店がいっぱいあるストリートにあります。地下鉄を8で降りてちょっと歩きました。このへん。

お店はこんな感じ。

塩ラーメンです。

日本のお店には行った事がない気がするので比較できないんですが、美味しいです。お昼だったのもあって、あまり混んでませんでした。

店内は日本のラーメン特集番組が流れていて、デザートにはちゃんと餅アイスがあって定番な感じ。何故か米国にあるラーメン店の基本メニューはラーメンと餃子、唐揚げ、デザートに餅アイスがあって、これはSan Franciscoのお店も同じ。

一風堂ニューヨーク

さて、次は有名店、一風堂。

場所はせたが屋から遠くないEast Villageの4th Av.沿い。なんかすごい店の外に寒い中並んでる! って思ったらバス停のバス待ち客でした。

しかし、近づくと中ですごい人が並んでる… ぐぬぬ。ちなみに、2人とかで1時間くらい待ちみたいのようでした。

ラーメンは日本の一風堂と同じメニュー構成で、白丸をチョイス。

替え玉もあります。

ところで気になるお値段なのですが… この円高であってもちょっとこれはっていう値段します。具体的には日本の倍くらい。まあ、ちゃんとしたディナーとしていく雰囲気の店なので五行に近い感じなのかな。

しかし、ちゃんと米国でこのラーメンが食べられるんですねー。さてはて、ベイエリアにはいつ来るのか。

という訳で片道6時間(と、ん百ドル)かけてラーメンを食べに行った話でした。おしまい。

合わせて読みたい → San Franciscoのお寿司事情

重要なことはfont-size: 600%で

Sun, 18 Dec 2011 19:34:00 -0800

来週から、年末年始に東京に行きます。みなさん遊んで下さい! お寿司とか好きです。

12/18, 2011 追記: 過ぎ去ると意味がわからないので、解説しておくと、日本時間の2011年12月19日の特大ニュースを日本経済新聞がウェブに掲載した際に、ヘッドラインにfont-size: 600%;の指定をして特別デカイ文字でニュースを掲載したことが話題になりましたの。参考画像がこちらです。

San Franciscoのお寿司事情

Thu, 15 Dec 2011 00:54:00 -0800

ごめんなさい、San Franciscoと書いておきながら、San Franciscoのお寿司屋さんの話題は出て来ません。

以前にこのブログでもちらっと触れたことがあるのですが、全然関係ない事を書いてしまったので、そのお寿司の話を。今回はgitとか出て来ません。

San Franciscoから北に車で20分弱、橋を渡った向こう岸にある小さな街SausalitoにあるSushi Ranというお寿司屋さんがお気に入りです。

まず赤いけどGoldenなGolden Gate Bridgeを渡ります。そ言えばSan Franciscoだったここ、と思う瞬間。

ちょっと山を降ります。テキトーに路駐してお店に。夜だといい感じになってます。

このお店、今日知ったのですが実はミシュランの星が1つ以上付いているようです。

そして問題のお寿司。

カウンターでは食べた事はないのですが、テーブルだとこうやって握りを頼んであとはランダムに好きなお寿司を足していく感じです。

大体、あんまり飲まないでいっぱい食べるか、飲んで普通に食べるかどっちにしでもチップ込みで$80位ですので、チップ込みでも日本円で6,000円くらい… や、安い… (ドルが)。

ベイエリアにはいっぱいお寿司屋さんがありますが、ここはお寿司以外の料理や雰囲気、行きやすさやお値段を考えるととても魅力的なお店です。

是非、一度お試し下さい!!

デーモンプロセスをゆるふわ監視するときに便利な$0

Tue, 06 Dec 2011 00:24:00 -0800

たとえばデーモンがあったとします。こんな感じで。

$ ruby -rwebrick -e 'include WEBrick; Daemon.start;\
HTTPServer.new(:Port => 3000).tap{|s|\
  s.mount "/", HTTPServlet::ProcHandler.new(Proc.new{|req,res|\
    res.body = "hi"});\
  trap(:TERM){s.shutdown}\
}.start'

これで3000番でHTTPサーバが起動しました。ちょっとリクエストしてみましょう。

$ curl 'http://127.0.0.1:3000/'
hi

期待通り動きましたね。ではちょっとこのデーモンが今どんな状態なのかを監視できるようにしましょう… ってなると多分、ログをどっかにとかになりますが、もっと簡単になんとなく知る方法として$0が使えます。

rubyの$0はご存知の通り現在実行しているrubyスクリプトの名前とかが入ってるんですが、これ書き換えができるんです。で、書き換えるとps(1)の値が変わ(ることがあ)ります。

先のコードをちょっと書き換えて、何回リクエストが来たか数えておきます。そしてそれを$0に入れてみます。あ、今度のを実行するまえに前のプロセスをkillしといて下さいね。

$ ruby -rwebrick -e 'include WEBrick; Daemon.start; $count = 0;\
HTTPServer.new(:Port => 3000).tap{|s|\
  s.mount "/", HTTPServlet::ProcHandler.new(Proc.new{|req,res|\
    $count += 1; $0 = "mydaemon: count=#{$count}"; res.body = "hi"});\
  trap(:TERM){s.shutdown}\
}.start'

新しいデーモンが起動しました。ちょっとps(1)してみます。

$ ps x|grep '[r]uby'
16046 ?        S      0:00 ruby -rwebrick -e...

あー、居ましたね。こいつです。このPID覚えておきます。で、一回リクエストします。

$ curl 'http://127.0.0.1:3000/'
hi

期待通りの結果ですね。ではps(1)はどうでしょうか。

$ ps x|grep '[r]uby'

ぶへ、なんも出ない。となるわけですが、これはさっき$0を書き換えたからps(1)で表示される名前が変わってるんです。こうします。

$ ps x|grep 16046
16046 ?        S      0:00 mydaemon: count=1

いたー! しかも処理したリクエスト数が見える! と、このようにps(1)でこのデーモンがどれだけリクエストを処理したかが見えますね。適当に何度か呼んでみましょう。

$ while true; do curl 'http://127.0.0.1:3000/'; done

それでこっそり裏でtop -cp 16046とかしてみます。おおーじわじわ増える…!

PID   ... VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16046 ... 14556 4652 1388 S    0  0.6   0:03.42 mydaemon: count=1025

ま、こんな感じで$0を使うとゆるふわにデーモンの状態を眺められますよ、という話でした。

うまく行かない場合は環境がダメなんだと思います。実は$0でps(1)の結果を書き換えるのは環境依存なので必ずしもどんな環境でも使えるわけではありません。上記例はLinuxで実行してます。

あともうひとつ、rubyを起動する際に、この例ではワンライナー的に-eでスクリプトを渡していますが、これは実はミソで$0で書き換えられる範囲は最初にプロセスを作ったときの名前の長さまでという制約があったりします。なので場合によっては十分な長さのダミーな引数を付けたりして呼び出すと大丈夫だったりします。

GmailのIMAP設定画面が難解すぎて生きるのが辛い

Sat, 03 Dec 2011 04:48:00 -0800

Gmail使ってますよね。もうメール = Gmailなのではないでしょうか。メールそれ自体はとても古い技術に基づいており、これだけ分散してまともに動いている仕組みは他にDNSくらいなんじゃないかなと思いますが、どちらも問題を抱えていて、特にメールはスパムやらとの戦いの場となっていて多分当面この状況は変わらないんじゃないかなと思います。しかし、メール = Gmailを意味する世界になっているのだとしたら、もうあまり深いこと考えなくてもそういうもんだと思って使っていけるんじゃないかなあと思いつつ、いい加減代替手段が出てきてもいいよねと思っている次第です。

さて、そんなGmailですが、メールの仕組みの上に乗っかっているサービスなので、とんでもない複雑な設定画面がくっついています。いや、結果的にそうなってしまいました。

そして、設定画面の中で最難関なのがIMAPの挙動の設定ではないでしょうか。はっきりいって、普通に読んだだけでは何を言ってるのかさっぱりわけが分かりません。

まず、そもそものIMAPの設定画面ですが、Gmailの設定タブ「メール転送と POP/IMAP」の中にあります。そして以前に「Labs」の一分の機能として用意されていたAdvanced IMAP Controlsが標準になっていて、これが設定の複雑さを増しています。

というわけで今回は、この設定をひとつずつ意味を理解しながら見ていきたいと思います。

IMAP を有効にする、IMAP を無効にする

IMAPを使うか、使わないか。これはわかる。

フォルダサイズの制限

順番逆ですが、これは簡単なので先に。これで1つのIMAPのフォルダに現れるメールの最大件数を指定できます。

ご存知の通り[Gmail]/All Mailフォルダには抹消されていない過去の全メールが現れます。ですので、頑張る系のメーラーでこのフォルダに触れた途端、過去のン万件のメールをダウンロードし出します。これはその挙動をなんとかするための設定で、多分、時間順で新しい方から1000件までしか現れないようにする、みたいなことができます。最低1000件なので、それは我慢しましょう。

IMAP のメールを削除するようマークを付けた場合(自動消去をオン/オフ)と、最後に表示された IMAP フォルダからメールを削除/消去するようマークを付けた場合

これが難解。この2つの設定、パッと見では意味不明ですね。実は日本語では難解度が上がるっていうかちゃんと翻訳されていないので、英語の設定画面を見てみます。それぞれ、

When I mark a message in IMAP as deleted: Auto-Expunge on/off
When a message is marked as deleted and expunged from the last visible IMAP folder

となっています。一部太字にしました。これらの単語は日本語訳では意味が失われているか、意味を取り違えて翻訳されています。しかし、英語にしてもやっぱり意味不明なんですね。そこで、この挙動を理解するにはIMAPのフォルダとGmailのラベルの関係と、IMAPのプロトコルでの削除の挙動を理解する必要があります。

まず、GmailのIMAPでは、GmailのラベルはIMAPのフォルダとして機能します。つまりあるメールがUrgentとBugという２つのラベルを持っていた場合、同じメールがUrgentとBugと[Gmail]/All Mailの3つのフォルダに登場します。でも実態は1つです。もしすべてのラベルがなくなった場合でも、[Gmail]/All Mailには残ります。

次にIMAPのプロトコルですが、IMAPでのメーラーがメールを削除する時には次のようにコマンドを発行します。EXPUNGEではなくてCLOSEを使ったほうが行儀がいいという話もあるようですが、後述の理解を深めるためにEXPUNGEにしておきます。

# INBOXフォルダを開く
SELECT "INBOX"

# Deletedフラグを立てる
STORE 1 +FLAGS (\Deleted)

# Deletedフラグを立てたメールを抹消する
EXPUNGE

IMAPは状態のあるプロトコルで、メールを削除するときには、特定のフォルダを開いてそのフォルダのメール対して削除フラグを立ててそして最後に実際に削除するという流れになります。Gmailの設定でいうところの英語「Expunge」はこのIMAPのEXPUNGEコマンドを意味していて、最初のオプションは、このコマンドを自動でサーバ側で発行するかしないかを選択するオプションになっています。

デフォルトではAuto-Expungeは、つまり自動消去はオンになっています。つまり、GmailではメーラーがDeletedフラグをSTOREコマンド立てると、裏でEXPUNGEが走る仕組みになっていて、その瞬間に「そのフォルダが表すラベルがメールから消される」という挙動をします。ポイントは、ラベルが消されるというだけでメールが本当に消されるわけではない、という点です。この自動消去の挙動では、メールは[Gmail]/Trashには移動しません。[Gmail]/All Mailには依然表示されます。[Gmail]/All Mailで削除を実行した場合EXPUNGEしても削除されません。

自動消去をオフにするとDeletedフラグをSTOREコマンドで追加しただけでは何もしないようになります。つまり、よりメーラーが期待するIMAPサーバの振る舞いに近いものになると言えます。ちなみに、Deletedフラグを立てただけでEXPUNGEしないとそのメールはDeletedフラグが立ったまま残ります。この状態はウェブからは全く見えません。

そして、自動消去をオフにすることで、次のオプションが有効になり、メーラーからEXPUNGEコマンドが発行された際に、Gmailがどのように振る舞うのかを選ぶことができます。

まずEXPUNGEを実行したフォルダが表すラベルがある場合は、そのラベルがメールから削除されます。次に、もし、そのメールがどのIMAPプロトコルから見えるフォルダにも登場しない場合(この太字にした部分が設定画面の日本語訳では誤って訳されています)、つまり「ラベル」の設定タブで「IMAP で表示」としたもののうち、どのフォルダにも登場しない場合、つまり条件式として書くと、

EXPUNGE を実行したときに:
すべてのラベルが削除されていて &&
([Gmail]/All Mail 上で EXPUNGE を実行した ||
 [Gmail]/All Mail を IMAP で表示しないようにしている場合)

に、次の中から挙動を選べます。

メールをアーカイブする
デフォルトの挙動です。結果的に何もしません。[Gmail]/All Mailを見えるようにしていてもいなくても、あるいは[Gmail]/All MailでEXPUNGEを実行したとしても消えません。
メッセージをゴミ箱に移動
そのメールを[Gmail]/Trashに移動します。つまりGmail上のゴミ箱です。[Gmail]/All Mailからも消えます。30日ほど放置するとGmailから消されます。
メールを今すぐ完全に削除する
そのメールをその時点で抹消します(「今すぐ」って… これも設定画面の誤訳)。[Gmail]/Trashにすら残りません。つまりGmail上でそのメールを削除してさらにゴミ箱から削除を選んだ挙動です。

難解ですね。これは様々なIMAPのメーラーがそれぞれ異なった挙動をすることと、GmailのラベルがIMAPの概念にまったく合ってないことに起因していると思います。

ユーザーはこれらの挙動と利用するメーラーがメールをメーラー上で削除したときに発行するIMAPコマンドの挙動とを照らしあわせて、最適なIMAP環境を構築することになります。

で、こんな解説どこに載ってんねんって話ですが、いちおう、ここでGmailのエンジニアが書いてます… こんな挙動わかるかいな!!!

まとめ。このIMAPの設定を使いこなすにはIMAPのプロトコルを知る必要があります。仕様はRFC3501(といくつかのRFCで構成されている)なので読んでみることとおすすめします。

また、これらの挙動を踏まえて、最も普通のIMAPサーバーと同じ挙動にするには、

「IMAP のメールを削除するようマークを付けた場合」は「自動消去オフ」
「メールを今すぐ完全に削除する」にする
「ラベル」の設定で、「すべてのメール(All Mail)」の「IMAPに表示」のチェック外す

とかでなんとなくうまく行くんじゃないかなーって気がしますがこの設定だとメールを消すと本気で消えるのでご利用は計画的に。

あと、一応、今回このブログを書くのには実際にGmailのIMAPサーバとIMAPでおしゃべりして挙動を確認しています。ですがあくまでもこれが書かれた時点での挙動ですので今後変わるかもしれませんね。

というわけで、快適なGmailライフを!

Zapposを使ってみた

Thu, 01 Dec 2011 00:59:00 -0800

ちょっと前のブログで書いたようにZapposで靴を買ったんですが、その後の顛末を。

Zapposは普通のオンラインサイトと同様に普通に買い物して普通に商品が届くのですが、びっくりしたのはそのサポート体制。無償で返品交換が出来ることは知っていたのですが、ちょろっと「予定よりも届くのが遅い…」ってツイートしたら速攻でVIPアカウントにしたので次回からは1 day shipping使って下さい! と来たりしてなかなか(あ、でもこれは1回買えば、普通にそうなるものらしいとも聞いた気がしますが。)

Twitter経由以外でもどんな不満でもリーズナブルならそれなりの対応をしてくれるようでここが顧客満足度を上げるキモなのかなあと。つまり返事が無い、のれんに腕押し状態のサポートや電話で延々マニュアル対応されるみたいなのが不満を高めるわけで、小売業として、オンラインサービスとしてこの点はとても大切なんじゃないかな、と思った次第。少なくともちゃんと聞いてるよ、という姿勢を見せることは聞いていても見せないよりはずっといいということで。

自分はこういったTwitter経由のサポートでとてもいい体験をいっぱいしていて、@Deltaとか@Comcastにはそれぞれサービスはアレなことが多いんですが、ある意味普通よりは多少の満足度を持っています。まあ日本のそれと比較すると足元にも及びませんが、ま、この話はまた別の機会に。

ちなみに、買った靴はサイズもぴったり(やっぱり 7½ でした←今後の為に自分メモ)で満足してます。

Amazon Kindle Fireの処遇について。Kindle Fire、差し上げます。

Tue, 29 Nov 2011 19:38:00 -0800

発表があってから数ヶ月、Amazon Kindle Fireで遊ぶことができました。到着する2日前に東京に出かけたので受け取ることが出来ずにいましたが、先日帰宅したので結構長く待つことに。

じゃじゃーん。開封!

さて、一晩遊んだんですが、結論としては、うーん、残念って感じ。遊ぶ前から色々なブログやストリーミング放送などでディスられていますがざっと上げるとこんな感じ。

ウェブブラウザがAndroidのそれをなんら変わりない使いにくさ、そして微妙な挙動。Silkの影響か、戻るボタンを押しても内容が戻らないということが多発。
PDFは、ただ表示されるだけ。それ以上でもそれ以下でもない。
見た目以上にズッシリ。
画面は綺麗なんだけど… あれ、なんだか、狭い… ような…
Amazon App Storeがまだ現時点では欲しいものが見つからない。

そして(普通に使う限りでの)決定的にアレなのが、

iPad以上の何かがまったく見つけられない。

という点。正直、処遇に困ってしまいました。

将来性はとてもあると思います。Amazonのビジネスとしても理解できます。今後のソフトウェアアップデートで大幅に改善されることとは思いますし、上記のような問題は解決されるような気もします。またrootしてしまえばいろいろ遊べるAndroidデバイスなんだとは思いますが、ちょっと今は必要ないかなぁ、と。

そこでアメリカ流に簡単に返品もできるのですが、どうせなら数多の批判記事を読んでもそれでも欲しいという方に楽しくつかって頂きたいと思いますので、次のルールでご希望の方に差し上げたいと思います。

趣旨

僅か1台のAmazon Kindle Fireですが、僕がこれを残念だなーとか言いながら使うよりも、Android的にこれを使って面白いハックをしたり、面白いアプリケーションを作ったり、楽しいブログ記事が出ればきっと楽しいはず! と思ったので差し上げます。つまり、無償譲渡です。

このAmazon Kindle Fireについて

このAmazon Kindle Fireです。なにか他のKindle Fireがあるかもしれませんが、ここに写真の掲載のあるアレです。
開封済み、一度使用済みで、一度僕のAmazon.comのアカウントにリンクされていますが、工場出荷時へリセットします。
丁寧に使ったので傷などはないはずですが、すんごい細いのがあるかもしれません。
Amazonから届いたときのまま、箱と本体添付の充電通信ケーブルを付けますが、箱や添付品を含めることで送料が増えるなどの理由で要らないという場合はご連絡下さい。

無償譲渡のルール

日本語(か英語)で僕とコミュニケーションの取れる、数多のAmazon Kindle Fireのディスり記事を読んでも、それでも欲しくて、ハックしたりアプリケーションを作ったり、面白いブログ記事を書いたりして活用できる!、という個人や組織が対象です。
11/30, 2011 追記 - ハック必須じゃないです、面白い使い方とか面白い記事とか書けそうとか、そういうのでもいいです。鍋しきに使いますとかは心が痛むのでやめて欲しいけど…
本体は差し上げますが、送料については状況がそれぞれに異なりますのでご負担下さい。
基本的に皆様の善意を信じます。しかし転売等はご遠慮下さい。直接的な利益享受が目的の行為は今回の譲渡の趣旨に反します。
譲渡をうけて活用してみた結果、しかしすんごい残念で期待はずれでうまく活用できなかったということでしたら、今回と同じ条件での無償譲渡を行うことを許可します。その譲渡には今回と同じルールを適用して下さい。この同じルールを適用するというルール事態も適用してください。つまりGPLのように継承されます。
この譲渡行為に対しての法的な問題があったり、かなり面倒な事態になるという事がわかった場合はこの譲渡事態を取りやめる可能性がありますが、まあそんなことは無いでしょう、多分。
今回の譲渡に関わる一切は僕が所属する組織等にはまったく関係がありません。あくまでも個人的なものです。
今回譲渡するAmazon Kindle Fireが1台しか無い以上、応募多数の場合は期日が過ぎてから抽選します。その時点で連絡が取れなかった場合は再度抽選を行い連絡がとれるまで繰り返します。

応募のルール

今から5日後の 米国太平洋時間 の 2011年12月4日(日曜日) 23:59:59 までにTwitterで@niwに次のフォーマットでツイートすること。
```
@niw #kindlehack (活用のしかた) (あればブログとかgithubへのURL)
```
必ず、もし譲渡された場合にどう活用したいのかをツイートに付して下さい。例えば、「Androidとしてハックしてスキャナをつなげるようにして自炊から即電子書籍として読めるようなアプリを作る」とか「すんごい面白いブログ記事を書く」とか「日本語の電子書籍を販売しようとしていて、現実的な電子書籍を普及させるにのこんなふうに使いたい」などです。
皆様の善意に任せますが、実現不可能な活用方法の提案はご遠慮下さい。ご自身で可能なかつ面白い活用方法をある程度は具体的に(秘密のアレ、とかならぼかしてもらっても結構です)お願いします。
ブログやgithubのレポジトリなどの客観的なエンジニアリング力やブログ力がある方はそのURLも付して頂けると嬉しいです。
万が一応募の意思なく僕とのコミュニケーションの一環で上記のようなフォーマットのツイートを送ることになった場合はそれらのツイートは無視します。
同様のフォーマットで1つ以上のツイートを送られても1つとみなしますが、いくつものツイートで長々と送るのはご遠慮下さい。上記フォーマットには自由に書ける100文字以上の余裕があります。
やはり善意に任せますが、複数のアカウントを取得して一人が複数応募するのはやめて下さい。応募元のアカウントがちゃんと使われていなさそうな場合は応募したとはみなさいないことにします。
抽選結果の連絡はTwitterで行います。その後のやり取りや送付先のやり取り等はダイレクトメッセージ等で行いたいと思います。

発送について

このブログが日本語で書かれているので主に日本の方向けとなるかと思いますが、国際発送致します。送料と関税に関してはご負担下さい。
本体は米国サンフランシスコから発送します。日本宛だと、USPSのEMSで$20くらい、1週間程度かかかると思います。
1週間も待てない! 速攻欲しいからFedExで! という場合は対応しますがそれなりに値が張ります。

以上、まだルールに抜けがあったり色々手間取ったりするかもしれませんが、始めての試みなのでお手柔らかに…! では応募お待ちしております!

当選者と今後

12/13, 2011 追記 - 期日を迎えまして、有効応募ツイートは5件、その中から厳選なる審査の結果 @kinneko さんに譲渡が決まりました! おめでとうございます。先日Kindle Fireを発送し、譲渡が完了しました。

@kinnekoさんのブログはこちらです!

あるSan Franciscoでの休日、たとえば秋刀魚

Mon, 07 Nov 2011 02:52:00 -0800

いろんな意味で先輩のブロガーから「ブログがアレすぎる」とアレされたので、もっと普通な記事も増やそうと思いました。

というわけで今回記事にはこの1行を除いて、一切gitとかrubyとかgccとかvimとかそういうのはありません!

というわけで今日は夏時間が終わって最初の日。すべてが1時間遅れている世界というか元に戻ったんですけどそんな日曜日の出来事です。

のんびり起きてあまりの寒さにびっくり(最低気温47度F、8度Cでした)しつつ、MacBook Air片手にふらっと靴を見に出かけてからいつものカフェでブランチを。

いろいろ見た結果、初めてZapposを使ってみることにしました。Zapposは返品交換自由のオンライン衣類販売サイトでLas Vegasにある会社です。噂だけは色々聞いていて友達も使っているのを見たことはあるのですが自分は使うのは初めて。ちょっと値段が高いらしいのですが、店でみた感じとあまり変わらなかったので購入。さてどうなることやら!

その後、昨日突如企画されたいろんな意味で先輩のブロガー宅での秋刀魚ホームパーティーに向かいます。途中でAT&TストアでJawbone Upを物色して黒しかないので今回は購入せず。店員がやたら「取り寄せる? 取り寄せる?」って聞いてきて商魂たくましいと思った次第。

秋刀魚パーティーでは文字通り美味しく秋刀魚を頂き、Kindle DXがあと一息でベストPDFリーダーになるなあと思ったり、SonyのReaderがけっこう出来がいいなあと思ったり、フィギュアの出来がすごいなーってなったり、アレがアレすぎるような話や、アレがアレなのを聞いたりしてドン引きしたり、アレとアレとアレが同じ場所に引っ越すとか、日本のテレビを何ヶ月ぶりかに見てTwitterについて普通に話をしてて感慨深かったり、リア充について真剣に議論したり、中二病について理解を深めたりしました。

しかし、和食はいいものですね! ごちそうさまでした!!

gitの小ネタ

Thu, 03 Nov 2011 22:49:00 -0700

SausalitoでBostonからのゲストを迎えておいしいお寿司を食べてきました。

ま、全然それは関係ないんですが、久しぶりのブログとして軽くgitの小ネタ的なものを。

gitのコマンドショートカット

git commitとか長いですよね。そういう場合は、~/.gitconfigに次のように書き足しましょう。

[alias]
    ci = commit

これでgit ciでgit commitと同様の動きをします。

カラフルに

生のgitは地味ですよね。そういう場合はこうします。

[color]
    diff = auto
    status = auto
    branch = auto

あのマージのグラフが見たい…

いくつかのGUIツールだと、綺麗なマージ状況を表示する機能があって羨ましいですよね。そういう場合はこうします。

[alias]
    gr = log --graph --date=short --decorate=short --pretty=format:'%Cgreen%h %Creset%cd %Cblue%cn %Cred%d %Creset%s'

こうすると、git grでこんなグラフを表示できます。

以上、gitの小ネタ集でした。いちおう、gitについてはまた今度ちゃんと書こうかと思ってます。

iPhone 4S アンロック!

Wed, 19 Oct 2011 01:11:00 -0700

先日購入したVerizonのiPhone 4Sをアンロックしたのでまとめておきます。

正確に言うと、いわゆるどんなSIMでもなんでもござれのファクトリーアンロックではなくて、海外での利用を目的として、米国ではCDMAのVerizonを、米国外ではGSMで現地のキャリアのSIMを使える、というリージョンロックつきのアンロックをしました。

これには店頭でも確認したとおり、一定の条件(たとえば、60日とか、6ヶ月使った後、あるいは優良なユーザー、1年あたり1回線まで、などと言われています。)を満たす必要があるらしいが可能である、ということがわかっていました。

実は僕は明日から東京に出かける関係もあって、できれば今日のうちにアンロックできたらいいなと思っていてものは試しと、VerizonのGlobal Services Activation Specialist (800) 711-8300 に夜の8時過ぎに電話をしました。

大抵、米国のカスタマーサービスは夕方5時には終わるので機械と話して終わりかな? と思ったらちゃんと人間がでるではありませんか! もうこれだけでVerizonの株が上がってしまいます。そこから、1. 明日から東京に旅行する 2. 現地のSIMカードを持っている、GMSのSIMアンロックができると聞いているがやってくれないか 3. ローミングしたいのではないの3点を説明します。

まず最初に電話に出た人に話して、わからないからみたいな感じで次の部署に回されます。よくあるパターン。そして次、また次となり、たらい回しを食らってそのたびに同じ説明をしました。そして最後にでた兄ちゃんは「名前は?」「PINは?」の後になんといきなり「OK! アンロックしたヨ!」とあっさりと… 僕が、へ? 聞き間違い? と思って少し戸惑ってると、

そうダヨ、もうアンロックしたヨ、持ってるSIMカードをさしたら使えるヨ! でも初回にiTunesに繋ぐかWiFiでアクティベーションがいるヨ、だから米国にいる間にSIM差し替えてアクティベーションしてネ? PCは持ってるカイ? じゃ簡単だネ! Have a nice flight!

みたいに言われて唖然。なんと簡単なことでしょう、その結果がこちら。

おお! AT&Tって出た! これだけ見るとAT&TのiPhone 4Sと何ら違いがない…

というわけで、こちらも。最初の画像でアンロックって言うと、AT&Tでも使えるの!ってなりますが、実は使用したのは手持ちのNTT DOCOMOのSIMカードで、AT&Tは米国でNTT DOCOMOのローミング先として表示されています。

さてその手順ですが、電話でお兄ちゃんが言っていたとおり、NTT DOCOMOのSIMを挿入すると暫くは電波を探していますが、見つかるとホーム画面が暗転Appleのロゴが表示されてシャキーンっという感じの動画(こんな感じ、ちょっと違うけど)が流れた後、アクティベーションしてネ!と表示され、WiFi接続画面になります。この時点でiTunesにつないでもアクティベートできるようですが、そのままWiFi経由でアクティベーションを進めました。そしてすぐに普通のホーム画面に戻ってAT&Tと表示されました。

一度アクティベートしたSIMは二度目以降はアクティベーションの必要はないようなので、このまま飛行機のドアが閉まるまでVerizonが使えて、成田に着陸したら即NTT DOCOMOで使えるわけですね! すごい便利!

ちなみに、アンロック後AT&TのSIMも試しましたがそのSIMは使えないヨ!と表示されてしまいました。

という訳で、まとめ。

VerizonのiPhone 4SはたしかにGSMでSIMアンロックできる
但し、米国外のSIMのみ有効のリージョンロック付き。
- しかし、実質Verizonのほうが良いのでAT&Tを無理に使う理由がないのも事実。
国外のGSMのキャリアのSIMを利用できる。
初回のSIM挿入時にWiFi経由、あるいはiTunes経由でアクティベーションが必要。
- このプロセスでVerizonに使って良いSIMか問い合わせているように思います。
2回目以降はアクティベーションの必要ない。
アンロックするのに60日待ったり6ヶ月待ったりする必要は必ずしもないようである。
- ただし通常の米国のカスタマーサポートと電話口で交渉するだけの英語力と気合は必要。
アンロックに費用がかかる、といような話は今のところ聞いてない。多分タダ。

以上、このようにVerizonのiPhone 4Sは現状かなりいい選択肢のようですよ!

合わせて読みたい→米国でのiPhone 4S事情

10/26, 2011更新 正しいAPNの設定は必要ですが、なんの問題もなく通信、通話ともNTT DOCOMOで利用できています。

ようこそ、税金地獄へ!

Tue, 18 Oct 2011 01:41:00 -0700

先日iPhone 4Sなどを買いました。

電話会社やAppleは16GのiPhone 4Sは$199.99と謳っています。ということはまあ$200ちょいで買えるかな、と思いますよね? まさかそんなアマちゃんじゃありませんよ。

さてここで米国はカリフォルニア州サンフランシスコ市の消費税についてお話ししましょう。そうです、カリフォルニア州は市によって税率が異なります。簡単に、乱暴に言えば約10%です。2011年10月現在は正確に言うとサンフランシスコ市では8.5%ですが、この間までは9.5%だった気がします。ということは、iPhone 4Sは$217くらい? と思うわけですが、実際は$255近く必要となります。

何故…

実はこれ、元の本体価格、つまりこの赤い電話会社では$649.99なんですが、それに対する消費税が加算されているですね。つまり、2年契約で$199.99になる$450の値引きは本体値段だけにしか効かないから税金のことなんか知らないよ、と。当たり前っちゃあ当たり前なんですが… つまり、消費税は元の値段に対する8.5%で$55.25となり、$199.99に$55.25を加えてはい、$255.24ね、と言うわけです。

まあ些細な額っていえばそうなのかもしれないですけど、解せないでよねー。実は所得税はもっとすごいことになってるんですが… それはまたの機会に。

というわけで。ようこそ、税金地獄へ!

ちなみに、日本では税込表示がルールなのでこういうことはあまり起こらないですね。あと、日本も消費税率を10%にするとかしないとかそういう話があるみたいですね。