blog.niw.at

JSConf 2012 に来てみた

Tue, 03 Apr 2012 01:33:00 -0700

米国 Arizona 州は Phoenix に来ています。

Phoenix はここ。Arizona 州は初めてなのですが、事前に聞くと100度(華氏 = 37度セ氏)くらいになるとか聞いてげんなりしてたのですが、そこまでヤバイくらい暑いことはなく、風は冷たいのでなんとかなる感じです。例によって夜は寒い…

さて、そんな Arizona 州は Phoenix に、今回は JSConf 2012 に参加するために来ました。Bootstrap の Jacob はプレゼンターなのですが、僕は完全に参加者で来ています。是非、発表できるようになりたいですが…

それはさておき、その名の通り JSConf は JavaScript の小中規模のカンファレンスで、今これがアツいっていうのを話し合って友達を作る会みたいなもので、遠くアイスランドから、あるいはニューヨーク、近くは地元の人までそれでもわりと多くの地域から人が来ています。

SFO から一路 PHX へ

愛しというわけではないけれど、ずっと使ってたノースウェストが買収されたデルタ航空は直行便がないので、ハブの SLC 経由で PHX 入です。遠回りすぎて直行便の倍の時間がかかるのですが、アップグレードされたのでよしとします。乗り換えの SLC は吹雪いてました…

前日の昼に PHX についたので、その日は iPad が抽選であたるとかなんとかの前日祭的な感じで開かれる notconf に行くことに。JSConf に行く人も行かない人も完全無料で楽しめる会でした。notconf では途中からだったのですが、最後の JSConf 主催者の Chris Willams の発表が爆笑だったので簡単に内容を。

「ン千ドルするようなカンファレンスなんか行くな、金の無駄だ。例えば、Rails Conf。もう完全に金儲けになってる。でもパーティーにはいけ。そこでプレゼンターを探して、ちょっと他のバーに行こうよって声をかけるんだ。大抵、プレゼンターは質問攻めに飽きあきしてるから、その提案には絶対イェスって言うさ。そしたらもうプレセンターは君のものだ！」 (だいぶ意訳)

じゃあ JSConf は違うんだな、期待していいんだなと思った次第で、iPad もハズレたしっていうので notconf はおしまい。

パーティー、そしてパーティー

ほとんどのカンファレンスでは同時開催でスポンサーのパーティーやオフィシャルのパーティーが連日開催されます。この手のパーティーは出来る限り参加してなるべく知り合いを作る、プレゼンターでなければ、ある意味カンファレンス中で最も重要な部分の気もします。

大抵の場合、会場のバーとかはすごいウルサイので何言ってるのかさっぱりわからないですが、まあこれは慣れるしかないなーと思った次第。海外からの参加で、例えば今年6月の Google I/O とか WWDC とか、その規模のカンファレンスよりはこのサイズのカンファレンスのほうがパーティーも割と気楽かもしれないので、WWDC のアレでゲンナリした人も是非チャレンジしてみてください。

カンファレンス初日

そういえば一つ面白かったこと。カンファレンスでは大量の Schwag (会社のロゴ入りグッズ)がもらえるのですが今回はなかなかすごかったです。

そもそも、スケジュールに「花火（いや、マジで花火。絶対参加！）」って書いてあって、レジストレーションの際に花火のチケットをもらったのですが花火とは景気がいいなぁ、とか呑気に思ってて、でもなんでチケットがいるの？とか話したのですが、なんと花火違いでした。

その時間になってチケットと引き換えに配られたのは、Mozilla の G2B が入った Nexus S！いいおもちゃを手に入れてしまった感じです。

その後のプレゼンテーションは興味深い V8 の最適化の手法から最近の JavaScript のツール事情など多岐に渡っており JavaScript 好きな方や、最新の雰囲気をキャッチアップするだけでもとてもいい感じです。

と、こんな感じで久しぶりのカンファレンスに来て色々刺激を受けております。

あわせて買いたい

オンラインバックアップ CrashPlan を使ってみた

Tue, 27 Mar 2012 01:20:00 -0700

先に断っておきますが、ステマではありません。単なる体験記です。

皆さん、バックアップしてますか？ここを読んでる方はほとんどが Mac OS X ユーザだと思うので、Time Machine でバックアップをしていると思いますがいくつか問題があります。

Time Machine はバックアップの最小粒度がファイルである

Time Machine のバックアップは HFS+ の特殊なハードリンクを使った世代間差分バックアップです。ある時点からの変更をファイル単位で監視してその変更のあったファイルをコピー、保存します。ですので、VMWare などが作るディスクイメージのバックアップでは毎回巨大なファイルのコピーが行われて残念な気持ちになります。
バックアップ先が物理的に同じ場所に限定される

Time Machine は外付けHDDをつないだ時に一定時間ごとに自動でバックアップをするという利用方法でデザインされているためバックアップ先は当然物理的に同じ場所（たとえば、家とか会社とか）になります。ですので、家に押し入られて盗難にあったり¹、災害²があったときに本当に消えるリスクは常にあります。

実際には、Sparse Bundle を使ってネットワークマウントした場所をバックアップ先として Time Machine を実行できるので工夫すれば解決するのですが、というか Time Machine をオンラインバックアップ化するスタートアップサービス Dolly Drive もあるのですが、これはこれで面白いと思うのですが、本来の利用方法とはちょっとだけ違うのでいろいろと不安な点もでてきます。

そこでオンラインバックアップ

そこで、現在の状況を考えるとオンラインバックアップがとても有力な候補として上がってきます。

身近な例でいくと Dropbox ですが、Dropboxに収まり切らないデータは困りますね。というかバックアップとはちょっと趣向が違います。そこで、ちょっと最近試している CrashPlan が素晴らしいので紹介したいと思います³。

CrashPlan を使ってみた

CrashPlan はすこし変わったオンラインバックアップサービスです。なにが変わっているかというと、バックアップ先が CrashPlan が運営するデータセンター以外にも選べるという点で、かつデータセンターを使わない限りに置いては一定の制約がついていますが無償でも使えるということです。

オンラインバックアップなのにデータセンター使わないってどこにバックアップすんねん！ってことですが、それはなんと友達で CrashPlan を使ってる人のところに送ってしまいます。例えば日本とアメリカに住んでる友達がいて相互にバックアップ、みたいなことができるのです。

あと一応、バックアップ先にはローカルのハードディスクやローカルネットワークの他のデバイスも選択できます。あるいは、自分でレンタルサーバーをしてそこをバックアップ先にしてもいいかもしれません。

あと、CrashPlan はバックアップ時の挙動を見る限り、ファイルの移動や部分変更があってもファイル全体のバックアップではなく、差分バックアップを行うようで、具体的にはファイルをブロック単位で暗号化・バックアップを行なっているようです。つまり VMware などが使う巨大な仮想ディスクイメージに変更を加えるようなことがあっても部分転送だけで済むということですね。

お値段などなど

その他、復元時にオンライン以外の、HDD の郵送による復元などひと通りのオンラインバックアップサービスが備えているサービスが備わっています。あと、よくありがちな外付け HDD のバックアップに関する制約はありません。

気になるお値段は1年契約で月$5程度なので、他のサービスと比べても同じか、ちょっと高い程度です。これまでいくつかオンラインバックアップを試してみましたが CrashPlan は使ってみようと思うのになかなか良さそうなサービスでした⁴。

ダメなところ

ところで、このブログを書いてる最中に CrashPlan がメンテナンスに入り、自動ソフトウェアアップデートが行われたのですが⁵、その後バックアップデーモンが起動しなくなりバックアップ不能に陥りました。一度、アプリケーションをアンインストールして再インストールして現在インデックスを作りなおしてバックアップは再開しましたが、まあ、こういうのはちょっと困りますねぇ。

ふと思ったのですが

そういえば、日本では Dropbox が違法かもしれないという話しらしいですが、オンラインバックアップは大丈夫なんですかね？ CrashPlan のデータは暗号化されていますが、オンライン上のデバイス（データセンターや友達のデバイス）に転送、記録されたりするのですが。ダウンロードに刑事罰とかもあるので不安です。

そのへん詳しい方@niwに教えてもらえると嬉しいです！

あわせて買いたい

これにローカルでバックアップして、オンラインでもバックアップすれば完璧！

未来のカメラ Lytro を使ってみた

Mon, 19 Mar 2012 17:58:00 -0700

去年に予約した未来のカメラ Lytro がついに届きました!

Lytro は普通のカメラと違い撮影後にピントを合わせることができます。つまりこう言うこと。

上の写真は撮影後のLytroのサイトにアップロードしたもので、クリックすると任意の場所にピントが合います。仕組みはこのあたりに。

届いた！

箱はとっても iPhone のような箱で中身もとても iPhone のような感じでした。

使われている素材とか表面加工とか見るとなんていうか iPhone のそれと比べていまいちなのでちょっと残念ですけど。

本体の様子

デスクトップ・アプリケーション

撮影した写真は専用の Mac OS X 用デスクトップアプリケーションで行います。 Windows 版は、必要ないと思いますが、用意されていません。

インストールして Lytro をつなぐとまずバックアップが始まります。じわじわ。遅い…

バックアップは本体のメモリのコピーをしているようで専用形式で ~/Pictures/Lytro.lytrolib/cameras/ に取り込まれるようです。

バックアップが終わると撮影された写真の後処理が始まります。じわじわ。遅い… 1枚に1分くらいかかります。

処理が終わった写真はフォーカスの変更、回転、Lytro.com や Facebook で共有ができます。というか、それだけでなんと JPEG で書き出しといった機能はありません… ~/Pictures/Lytro.lytrolib/thumbs にサムネイルの JPEG が保存されていて、⌘+4 などで画面のスクリーンショットを撮って保存できますが、ちょっと残念ですね。

ウェブで共有

というわけで、実質 Lytro.com の URL を送ったりしてウェブで共有するのが唯一の出力方法になります。

また、ブログ埋め込み用のタグもここから取れますので、基本的な使い方？である、撮影→ブログに載せる、は問題無いように思います。

上のろくろ写真を埋め込むとこうなります。

本体落とすとこうなる

ところで開封してからまもない間に、さっそく机の高さから落としました。

悲惨なことになります。一瞬、悲しみがこみ上げてきましたが、Menu から Reset して元に戻りました。落とさないようにしましょう。

まとめ

ざっくりとした印象は、まだまだやれることはあるけれど実装が追いついていない感じでベータバージョンではないかと感じました。

周辺のソフトウェアの出来やファームウェアの改善で現在の問題点、デスクトップソフトウェアが遅い、JPEG 出力できないなど撮影したあとにできることの少なさはかなり改善されると思います。

この未来のカメラをもっと良くしたい、未来を先取りしたいという場合は Lytro はエンジニアを採用をしているようなので応募してみると良いかと思います。勤務地は Mountain View のようです。

もちろん、Twitter も積極的に採用していますので、未来の Twitterを先取りしたいという場合はぜひ応募してください！

あわせて買いたい

Lytro で撮影した写真を見るのに必要ですよ！

米国の iPad WiFi + 4G のアンロック具合

Sun, 18 Mar 2012 20:54:00 -0700

先日発売された Retina ディスプレイ iPad の Verizon モデルを買いました。ちなみに、Verizon についてはこのブログに詳しいです。

しかし、これ、なんと呼べばいいのでしょうか。Apple のこれまでの命名規則だと、MacBook Pro (Late 2009) のような年式を付与する呼び方や、iPod (2nd Generation) のような世代を付与する方法がありました。しかし、Apple のサポートをパッと見た限りに置いては公式には iPad 以外の呼称がありません、あるいは iPad WiFi + 4G と呼ばれています。マーケッティング的には The new iPad のようですが。候補としては、混乱を承知で iPad、The new iPad、あるいは iPad (3rd Generation)、iPad (Early 2012)、あるいは iPad 3 と呼んでしまう?

まあ、何れにせよここで言う iPad はつまり Retina ディスプレイの第3世代 iPad のことです。

NTT DOCOMO の SIM カードを指してみた

予約の際に、オンラインの Apple Store に記載のあったとおり、 iPad WiFi + 4G はアンロックされており、現地の SIM で 3G 通信は可能であるらしいので、NTT DOCOMO の SIM は認識するはずです。

何事もなかったようにつながりました。ローミング先は AT&T です。

APN の設定を見るとテザリングの設定もあるのでテザリングも問題なしのように見えます。

ということは、NTT DOCOMO の MVNO な最近ヨドバシで売ってるらしい安価な SIMカードを買って入れておけば日本で便利に使うことはできそうですね。

AT&T の SIM カードを指してみたけれど

手元にある AT&T の SIM カードは既に無効になってるものしかなくて、ちゃんとした結果ではないのですが、多分使えるような気がします。少なくとも、拒絶はされませんし、キャリアプロファイルは AT&T となります。

というわけで、多分 4G LTE の仕様の違いという意味でのキャリアごとのデバイスが発売されているようですが、3G についていえばロックされていないようです。つまり、AT&T の 4G LTE を使わないのであれば Verizonのモデルでいいんじゃないかって気がしますね。

日本国内で Softbank が販売する iPad WiFi + 4G について

日本の Softbank が販売する iPad は国内の GSM キャリアに対してのロックがあるようです。つまりドコモダケロックされているようですね (将来リンクが死んだ場合ですが、日本経済新聞のサイトで「ロックの対象は国内の携帯電話事業者のみ」という記述がありました。)

あと、4G って言ってますが、HSPA+ を 4G って呼んでいいらしいですけど、LTE じゃありません。iPad では LTE は LTE と表示されるようです。さらに Softbank は現時点では HSPA+ も使うことが出来ないようです。まあ、正確には LTE も 4G じゃなかったんですけどね… なんていうか、4G に漸近してるけど、けして 4G にならない、みたいな感じ。

あわせて買いたい

風呂のフタどうですか？

日本ではこういう SIMカードもあります。

Mac OS X Lion の起動 USB を作る過程でハマった

Fri, 16 Mar 2012 22:31:00 -0700

先日、SSD を買ったので Mac OS X Lion を入れなおしましたが、その過程でハマったのでメモしておきます。

Mac OS X Lion は出た当時いろいろ言われましたが起動 USB メモリを作ることが可能で、Lion を入れるために Snow Leopard を入れる必要があるとかはありません。

起動ディスクを作る

まず、少なくとも 4GByte 以上ある USB メモリが必要です。そしてもう一台 Mac がある、あるいは事前にこの作業ができることが前提です。

そして、Mac OS X Lion を Mac App Store からダウンロードします。Applications に Install Mac OS X Lion がダウンロードされるので、その内部にある Contents/ShareSupport/InstallESD.dmg を Disk Utility を使って USB メモリに書き込みます。

が、まずその前に USB メモリを GIUD パーティションを使って初期化 します。これをしないと、作成した USB メモリで起動しても途中までは動くのですが途中で STOP マークが出て悲しい気持ちになるので注意です。

次に、先の InstallESD.dmg を Disk Utility にドラック＆ドロップして Restore を選びます。Destination: に先程つくった パーティションを ドロップして Restore ボタンを押して書き込み完成です。

そしてUSBから起動

こうして作成した USB メモリを Mac に指して Option を押しながら起動すれば USB からの起動が選べるはずです!

以上、自分メモでした。

あわせて買いたい

これ使ってます！

これ買いました！

Uber のトム

Thu, 15 Mar 2012 00:01:00 -0700

San Francisco には Uber というリムジン廃車配車サービスがあります。簡単に言えば、タクシーを呼べるサービスみたいなものなのですが、来るのはリムジンです。これが非常によくできていて、リムジンなのでちょっと高いけれど、東京のタクシー値段と比べれば大差ないみたいなサービスとなっています。

今日、仕事帰りにディナーに行くという事で Uber を使いました。 Uber はまず iPhone アプリをダウンロードして自分のクレジットカードを登録しておきます。登録するとリムジンを呼べるので、「ここに呼ぶ」ボタンを押すと一番近くにいるリムジンに配車の連絡がいき、「あとちょっとで来るよ」みたいな表示になります。と、同時にそのリムジンがどこに居るのかが地図でわかるのですが今回はトムという人が運転するリムジンが来ることになりました。

このトムのリムジン、最初は近い場所にいるように見えたのになぜだかすごい遠回りをして呼んだ場所まで来ます。この時点で結構アレだったのですが、トムはなんだかちょっと不安な感じで、目的地までの運転も途中で逆走したりしてすごい遠回りなどをしてとても残念でした。あまり道がわかってない感じで。

Uber は乗った後に☆5つで評価が出来るのですが、ちゃんと目的地にたどり着いたけど、結構待ったし、遠回りだったし、で☆2つにして評価。iPhone アプリが理由を聞いてきたのでその理由を書いてあーぁ、って思ってディナーに向かいました。

すると、しばらくして Uber からメールが来ました。

「やあ。Uber の利用レポートを送ってくれてありがとう。☆が5つじゃないから経路をみてみたら、たしかに遠回りしてるね… ごめんネ！これだけ割引するから、請求はこれだけになるよ。ありがとう！」

って書いてありました。うーん、こんなサービス、アメリカにはないと思ってたんだけどこれで「あ、今回トムはアレだったけど、また使ってみよう！」って思いました。普通のタクシーの場合は、ひどかったらチップで調整できますが Uber では出来ないのでこういうフィードバックへの対応は大事なんですね。

そんなわけで、こんな気軽にリムジンが使えるサービス東京にもあったら… と書くというのはちょっと違くて、東京ではこのクオリティがあたりまえでタクシーなんて呼ばなくても大量に走っているので困らないし、まあサービス業が死んだと言われるアメリカでも、色々考えられているんだなってことでした。

ちなみに、この Uber のファウンダー、Travisは起業家としてはかなりの経歴の方だそうです。

あわせて読みたい

これは読んでみたい。

だいぶ実装がアレな SkypeLogger の解説

Wed, 14 Mar 2012 02:13:00 -0700

tl; dr: SIMBL も Ruby も、あるんだよ。

Mac OS X のアプリケーションを作る方法が Objective-C だけとは、限りません。

今回はそういった意味ではだいぶ実装がアレな拙作 SkypeLogger の実装を見ながら、こんな作り方もあるよねということを紹介したいと思います。

SkypeLogger の紹介

まず、SkypeLogger ですが、何をするものかというと、Skype のチャットログを人間が読める形で普通のファイルに書きだしてくれるツールです。Skype.app 自体にログを残す機能はあるのですが、人間が読めないし、機械でも読めない独自の形式¹で書き出されるので不便なのです。そこで、Skype API を使ってチャットの発言の送信、受信イベントをもとにチャットの発言を逐一ファイルに書き込んでいくだけの簡単なお仕事をしていただく、というツールです。

しかしこの Skype API が曲者で、API とは名ばかりで Skype.app と通信するインターフェイスが提供されるだけで、実際に Skype.app が起動していないと使えません。今回のような用途に限ってはそれでも問題ないのですが、ボットを作る、とかだとちょっと面倒²ですね。

SkypeLogger の概要

さて以上を踏まえてこの SkypeLogger の実装についてお話しましょう。仕組みはこうです。

まず Skype.app の起動を検出して自身も同時に起動します。これには SIMBL を使っています。SIMBL とは、Mac OS X の既存の(ほとんど、どんな)アプリケーションでも拡張できるプラグインを作るためのプラグインです。具体的には、ReederをGrowlに対応させたりとか、そういうツールを作るのに使います。

動作原理についてはまた後述するとして、全体像を把握するために、ここでは SIMBL は他のアプリの起動と同時にアプリと一緒にプラグインを読み込んでくれるツールと考えてください。

SkypeLogger は、この SIMBL を使って薄い Objective-C で書かれたコードを Skype に読み込ませます。次に、そのコードは ruby をつかって Ruby で書かれた Skype API を使ってログを取るツールを内部的に起動します。これには RubyCocoa を使っています。そしてそのツールが Skype.app と通信をしてログをLogger を使って所定のファイルに書き出していきます。

あとは Objective-C で書かれた部分で Skype.appの終了通知を監視して、Skypeが終了したら、内部的に起動したツールも一緒に終了させます。

と、まあこういう仕組みで動いているのですが、つまり、このツールというかアプリ、Objective-C と、Ruby (と RubyCocoa) の2つを使って書かれています。このあたり、各言語ごとにブリッジが存在している Objective-C ならではですね。

ここまで見るとわかると思うのですが、Ruby で書かれた部分は SIMBL を使う Objective-C で書かれた部分と完全に切り離されていることに気がつくと思います。実際、この Ruby 部分だけでロガーとして別に手動で起動することも可能です。これには諸事情³あってこのような実装になっています⁴。

SIMBL の仕組み

では、まず起点となる SIMBL から見て行きましょう。SIMBL はほとんどのMac OS Xのアプリにプラグイン機能を提供してくれます。つまり、ちょっーっと足らないあと一歩の機能を自分で追加したりすることができます⁵。

さて、その仕組みなのですが、Mac OS X のバージョンアップを重ねるにつれて複雑化してきています。その昔は Mac OS Xのアプリが Library/InputManagers にあるプラグインを自動的に読み込む機能を経由して独自のプラグインを読みこませることをしていましたが、現在は /Library/ScriptingAdditions とデーモンによる複雑な手法になっています⁶。

まず、対象のアプリケーションが起動すると /Library/ScriptingAdditions にあるスクリプト拡張プラグインを読み込みます。が、実行はされません。SIMBL はここにスクリプト拡張プラグインを置いて、対象のアプリケーション内部にスクリプティング用のエンドポイントを提供します。

次にバックグラウンドで動いているデーモン SIMBL Agent がアプリケーションの起動監視をしていて、アプリケーションが起動され次第、事前にスクリプト拡張で作っておいたエンドポイントをスクリプティング経由で叩きます。

その後、対象のアプリケーション内部で Library/Application Support/SIMBL/Plugins から読み込むべきプラグインを探して +[NSBundle bundleWithPath:] で対象のアプリケーションに読み込みます。詳しい挙動はSIMBLのソースを確認してください。

なんだか面倒な仕組みですが、このような努力の結果、Library/Application Support/SIMBL/Plugins にプラグインを置いておけば、対象のアプリが起動したときに自動で読み込んで実行してくれます。

SIMBL プラグインを作る

ここからは SkypeLoggerのソースを片手にお読みください。

SIMBL プラグインを作るには、Xcode で Bundle を作り、Info.plist に対象とするアプリケーションの Bundle identifier とバージョンを記載しておきます。Skype.app の場合はこんな感じ。

<dict>
  <key>BundleIdentifier</key>
  <string>com.skype.skype</string>
  <key>MaxBundleVersion</key>
  <string>5.2.0.1523</string>
  <key>MinBundleVersion</key>
  <string>2.8.0.851</string>
</dict>

そして、SIMBL がこの Bundle を読み込んだ際に Principal class の +load が呼ばれるのでそこにやりたいことを書きます。

大抵は対象のアプリケーションの一部のメソッドを書き換えたり奪ったりしてやりたいことを追加したりします。書き換えには Objetive-C のランタイムの機能を使ったり、NSObject のカテゴリを使ったりする手法がありましたが、最近は method_exchangeImplementations を使うと楽です。

しかし、SkypeLogger はアレなのでそういうことはせずに ruby を内部的に起動します。つまり、fork します。SkypeLoggerLoader.m あたりをご覧ください。

pid_t pid;
if((pid = fork()) == 0) {
    ...
    if(execl("/usr/bin/ruby",
             "ruby",
             skypeLoggerPath,
             "-l",
...

とても普通に fork ですね。親プロセス(つまり Skype.app)側では fork 後、アプリケーションの終了通知 NSApplicationWillTerminateNotification を待っておきます。子プロセス(つまり、Ruby スクリプト)側は Skype API の使用準備を始めます。

親プロセスは、つまり Skype.app の終了通知が来たら、子プロセスに、つまり fork した ruby にシグナルを送って死んでもらいます。以上、ここまでは Objective-C で書かれています。

Skype API を使う

ここからは Ruby の世界になります。/lib以下をご覧ください。

Mac OS X 標準添付の Ruby では RubyCocoa が提供されていて⁷、require "osx/cocoa"することで Objective-C のクラスとRubyのクラスを行ったり来たりすることができます。

Skype API を使うには Skype.framework を読み込んで +[SkypeAPI setSkypeDelegate:] でコールバックされるクラスを提供して +[SkypeAPI sendSkypeCommand:] でコマンドを送ります。これを RubyCocoa を使って Ruby で書くとこうなります。

def applicationDidFinishLaunching(notification)
  OSX::SkypeAPI.setSkypeDelegate client
  OSX::SkypeAPI.connect
end
...
def command(cmd)
  res = OSX::SkypeAPI.sendSkypeCommand(cmd).to_s
  ...

簡単ですねー。あんまり深いことは考えなくても動くのでいろいろ楽ですが、ちょっとミスると簡単にプロセスが死ぬので怖いです。

Skype API のバグ？仕様変更？

Skype API は基本的に同期呼び出しが可能だったはずなのですが、あるバージョンから突然同期呼び出しができなくなりました⁸。つまり SkypeAPI.sendSkypeCommand() を読んでも結果はすぐに返らずに非同期で SkypeAPI.setSkypeDelegate() で登録したクラスの skypeNotificationReceived() が呼ばれます。

というわけで SkypeLogger では同期呼び出しが出来るか出来ないかを最初のメッセージを受け取った時に判断して以降のメッセージハンドラを差し替えるという ~~キモい~~ かっこいいことをしています。メッセージを受け取るたびに if 文が走るなんてことはありません。

def on_message_sent_or_recieve(id)
  handler_module = if command("GET CHATMESSAGE #{id} CHATNAME").empty?
    ...
    AsynchronousSendSkypeCommand
  else
    ...
    SynchronousSendSkypeCommand
  end
  self.class.class_eval do
    # 使える方のメッセージハンドラモジュールをincludeして
    include handler_module
    # 自分自身を消す
    remove_method :on_message_sent_or_recieve
  end
  # 選んだ方のメッセージハンドラを呼ぶ
  on_message_sent_or_recieve(id)
end

まとめ

Mac OS X のアプリケーションを作るには様々な方法があります。アプリケーションの形態も様々で単体のアプリケーションからこういうようなプラグイン形式のものなどいろいろあります。

AppStore 全盛期にアプリケーションはこれこれこういう形でこう作るんだよ、みたいな風潮がありますが、もっと本当は自由なんですよーってことでまとまったようなのでオシマイ！

感想とか、こうしたほうがいいとか、これはマズいとかは @niw にツイートしてもらえると嬉しいです。

Instapaper から Readability に移行する

Thu, 08 Mar 2012 02:56:00 -0800

「あとで読むツール」にはいろいろあって、僕の中では決定打はないというか、自作するか… と思っているもののひとつなんですが、そんななか最近 iPhone/iPad アプリが登場した Readability を使ってみようという気になってきました。

これまで Instapaper を使っていたので、じゃあ、ためてある「後で読む」たちを移行するか、と思ったらそうはなんだか簡単にいきそうにない。 Instapaper 側は CSV ファイルで2,000件までなら書き出せるらしいのでこちら側はなんとかよしとする(実は1,980件くらいあってギリギリだったんだけど。) けれども、Readability 側にはインポート機能がなくて、API はメールしないと API トークンがもらえないという面倒くささ。

しかし、よく見ると Readability で用意されたメールアドレスにメールで URL を送るとインポートしてくれるらしい。あ、つまり、SMTPっていうAPIがあるってことかー、と脳内理解したのでスクリプトを書きました。ソースはこちら。

Gemにしたので

$ gem install readability_importer
$ rehash
$ readability_importer

で使えると思います。

中身の話

URL の一覧を受け取って、メールをつくって SMTP で Readability に送る、ということをしていますが、Readability の SMTP が遅いのもあってか、普通にNet::SMTPとかで実装するとかなーり遅いです。そこで EventMachine で並列化して送るようになっているます。あんまり無茶しすぎるとブロックされそうなのでリーズナブルな並列度合いで使ってください。-cで変えられます。

あと、重要なのことなのですがOP25Bをされている環境¹ではSMTPが使えないのでたぶん動かないと思います。

Mac OS Xで追加された絵文字が怖い件について

Tue, 06 Mar 2012 00:13:00 -0800

先日はマジなブログを書いてしまったので脱力系を。

Mac OS X 10.7にはカラー絵文字というのが搭載されていて、iPhoneでお馴染みのあの絵文字がレンダリングできます。レンダリング可能な絵文字やその割り当ては真面目に調べるとけっこう色々とあるのですが、Unicode 6の絵文字仕様ものが大体搭載されているようです。

しかし、Mac OS X 10.7.3に搭載されているのをよく見るとなんだかけっこう解像度が高くて、しかも怖いのが増えてるようなのです。

なにかお持ちのようです。

これは苦手な人はアウトでは？

ちょ、頭だけのやつもある！

ちびる

John AppleseedさんのクレカのCCVは445だそうですよ！！

ちなみに、この方です。クレカの管理はもうちょっと厳重に・・・

な、なんか風呂に居る・・・

もしオレンジだったらアイコンにとか一瞬おもったけど、よーく見るとちょっと怖い。

と、ツイートしたところ、Appleの木田さんがつくってくれました (∩´∀｀)∩ﾜｰｲ

@niw こんな感じかな？ :) twitter.com/kidayasuo/stat…
— 木田泰夫さん (@kidayasuo) 3月 6, 2012

と、なかなか楽しいのでいろいろ探してみください。 Font Book.appを起動してApple Color Emojiフォントを選んで⌘+2で表示されます。右端のつまみででっかくできますよ！

あわせて読みたい

イチオシの文字コード本。ブログでふれてる木田さんも登場しますよ！

+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:] が何をしているか調べてみた

Sun, 04 Mar 2012 03:13:00 -0800

tl; dr: +[NSURLConnection sendAsynchronousRequest:queue:completionHandler:] は dispatch_async で +[NSURLConnection sendSynchronousRequest:returningResponse:error:] を呼んでいる。

NSURLConnection を非同期に使いたいなんて要望はもうそれこそかなり昔からあって、数多の車輪の再発明とブログと FAQ が生まれたわけですが、一昨年の Grand Central Dispatch¹、GCD の登場でついに抜本的な解決が見えるかのように見えてわひょーいってなった割には2010年の WWDC のネットワークのセッション²で GCD は未来、諸刃の刃、素人にはオススメしないとか言ってたりしていて、おいマジかよとか思ったのは記憶に新しいかと思います。

そんな昨今、あの NSRunLoop を回さないとロクに仕事をしなくなった³ことで有名な NSURLConnection にひっそり sendAsynchronousRequest:queue:completionHandler: なんていうメソッドが生えているではありませんか。

こ、これはっ！もうこれ使えば NSRunLoop 回したりとかいらねえんじゃね？ってなって歓喜なわけですが、よく見るとですね、

Availability
Available in Mac OS X v10.7 and later.
Available in iOS 5.0 and later.

って書かれていてガックシなわけですね。Mac OS X はいいとしても、iOS のほうはまだ iOS 4 な iPhone がたっぷりこの世にある以上無視できない⁴わけで… ぐぬぬと。

じゃあ、っていうんで当然、挙動を調べて互換のコード書いておこうってなります(ならないか… いや、なることにしてください。)

ということで、今回は +[NSURLConnection sendAsynchronousRequest:queue:completionHandler:] が何をしているか調べる過程でlldbの使い方や GCD のことやブロックの実装がどうなっているのかとか Objective-C がどうやって動いているのかを調べてみます。

まずは使ってみる

まず、簡単な短いコードを書いてどうやって動くのか確かめます。ちょっとハマったのは queue: の部分で、これは completionHandler: を実行するための NSOperationQueue を渡すので、ここで渡す queue に対して -[NSOperationQueue waitUntilAllOperationsAreFinished] をしてもうまく待てなかったりします。で、こんな感じのコードを書きました⁵。

#import <Foundation/Foundation.h>
#import <dispatch/dispatch.h>

int main(int argc, char *argv[])
{
    @autoreleasepool {
        NSOperationQueue *queue = [[NSOperationQueue alloc] init];
        NSURL *url = [NSURL URLWithString:@"http://www.google.com/"];
        NSURLRequest *request = [NSURLRequest requestWithURL:url];

        dispatch_semaphore_t s = dispatch_semaphore_create(0);

        [NSURLConnection sendAsynchronousRequest:request
            queue:queue
            completionHandler:^(NSURLResponse *r, NSData *d, NSError *e) {
            NSLog(@"%@", r);
            dispatch_semaphore_signal(s);
        }];

        dispatch_semaphore_wait(s, DISPATCH_TIME_FOREVER);
        dispatch_release(s);
    }
    return 0;
}

何もしていませんね。リクエスト投げて終わり。

$ clang -g -framework Foundation -o test test.m

とかでコンパイルします。実行すると、まあちゃんと動きますね。

はじめに

こからが本題です。何をしているのか知りたいと。まずは予想します。明らかに GCD は使っていると思われます。

なので、dispatch_async で NSURLConnection の何かを呼ぶ block を突っ込んでいるだろうと。問題は、どのキューにどんなことをするブロックが突っ込まれているかわかんないということですね⁶。

最終的に呼ばれる completionHandler はまた別の NSOperationQueue (内部的にはGCDになってる) で呼ばれてしまうのでここから実際にリクエストを投げているブロックには到達できないのですね⁷。

というけでやってみます。

デバッガ起動

$ lldb ./test

前回は gdb を使いましたが、今回は lldb を使います。基本的には同じなのですが、コマンド体系が違って困ります⁸。そんなときはここに対応表があるので便利です。

Current executable set to './test' (x86_64).
(lldb)

では、まずおもむろにターゲットのメソッドに b でブレークポイントを立てます。

(lldb) b +[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]

それで、r で走らせて止まるまで行きます。

(lldb) r
...
Process 18965 stopped
* thread #1: tid = 0x1f03, 0x00007fff90c4248e Foundation`+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:], stop reason = breakpoint 1.1
    frame #0: 0x00007fff90c4248e Foundation`+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]
Foundation`+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]:
-> 0x7fff90c4248e:  pushq  %rbp
   0x7fff90c4248f:  movq   %rsp, %rbp
   0x7fff90c42492:  subq   $64, %rsp
   0x7fff90c42496:  movq   1756339(%rip), %rax    ; 0x00007fff90def150 
(lldb)

はい、止まりました。

GCD の呼び出しを追う

ここからが勝負です。実際の挙動が予想通りだと期待して、GCD 関係の API にブレークポイントを立てておきます。

(lldb) b dispatch_get_global_queue
(lldb) b dispatch_async

では c で続きを。

Process 18965 stopped
* thread #1: tid = 0x1f03, 0x00007fff893b201d libdispatch.dylib`dispatch_get_global_queue, stop reason = breakpoint 2.1
    frame #0: 0x00007fff893b201d libdispatch.dylib`dispatch_get_global_queue
libdispatch.dylib`dispatch_get_global_queue:
-> 0x7fff893b201d:  testq  $-3, %rsi
   0x7fff893b2024:  jne    0x00007fff893b20b0     ; dispatch_get_global_queue + 147
   0x7fff893b202a:  testb  $2, %sil
   0x7fff893b202e:  je     0x00007fff893b2068     ; dispatch_get_global_queue + 75
(lldb)

おお、dispatch_get_global_queue で止まりました。やっぱり GCD を使ってますね。自分で作ったキューではなくてグローバルのものを使っているようです。 dispatch_get_global_queue は man によると、次のような引数と戻り値だそうです。

 dispatch_queue_t
 dispatch_get_global_queue(long priority, unsigned long flags);

つまり、1つめの引数を見ればどのグローバルのキューを使っているのかわかって、戻り値でそのキューの場所がわかります。1つめの引数は rdi レジスタに格納されるので見てみます⁹。

(lldb) p (long)$rdi
(long) $0 = 0

はー、0 ですか。これは dispatch/queue.h によると DISPATCH_QUEUE_PRIORITY_DEFAULT ですね。ではこのキューの場所を押さえておきます。戻り値は rax レジスタに入るので、

(lldb) finish
(lldb) p (void*)$rax
(void *) $1 = 0x00007fff74d6a0c0

ここだそうです。はい覚えた。じゃ c で続きを見ていきます。

dispatch_async の呼び出し

Process 18965 stopped
* thread #1: tid = 0x1f03, 0x00007fff893b3ae9 libdispatch.dylib`dispatch_async, stop reason = breakpoint 3.1
    frame #0: 0x00007fff893b3ae9 libdispatch.dylib`dispatch_async
libdispatch.dylib`dispatch_async:
-> 0x7fff893b3ae9:  pushq  %rbp
   0x7fff893b3aea:  movq   %rsp, %rbp
   0x7fff893b3aed:  pushq  %rbx
   0x7fff893b3aee:  subq   $8, %rsp
(lldb)

今度は、dispatch_async で止まりましたね。どうやら予想通りなにやらブロックをキューに追加しているようですよ。dispatch_async は man によると、

 void
 dispatch_async(dispatch_queue_t queue, void (^block)(void));

ということなので、最初の引数が追加するキューの場所、2つめがブロックとなります。ではそれぞれ確認しましょう。1つめの引数は rdi ですね。

(lldb) p (void *)$rdi
(void *) $2 = 0x00007fff74d6a0c0

おや、どこかで見た数字。そうです、さっき手に入れた DISPATCH_QUEUE_PRIORITY_DEFAULT なグローバルなキューですね。ここにブロックを追加していると。ふむ、このブロックが多分非同期にネットワークのリクエストを投げていることでしょう。ではこのブロックが呼ばれる箇所でブレークポイントを立てる… となるわけですが、これがちょっと難しい。

ブロックの実体について

ブロックは実体はCの関数ポインタのようなものですが、実はもっと面倒なことをやっています。次のような超絶短いコードを書いて clang -rewrite-objc で C++ のソースを生成させて実際の dispatch_async の呼び出しがブロック無しではどうなるのかを確認します。

#include <dispatch/dispatch.h>
int main() {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{});
}

何もしなさすぎですね。4行。しかし、これがコンパイラの手にかかると凄まじい行数になります。

$ clang -rewrite-objc block.m
$ wc -l block.cpp
      93 block.cpp

うぉ… 100行くらいになっとるではないか。当社比25倍。うろたえますが、中身を見てみます。どうなってんのかなぁ…

dispatch_async(dispatch_get_global_queue(0, 0),
    (void (*)(void))&__main_block_impl_0((void *)__main_block_func_0,
        &__main_block_desc_0_DATA));

長い、長いぜ… でも、ブロックのところは __main_block_impl_0 構造体のコンストラクタ呼び出しになっています。一瞬あれ？って思いますが、これ C++ のコードです。1つめの引数は __main_block_func_0 で、これがもともとブロックの中身、実体です。で、そのコンストラクタではブロックの実体を impl.FuncPtr に格納しています。

struct __main_block_impl_0 {
  struct __block_impl impl;
  ...
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int flags=0) {
    ...
    impl.FuncPtr = fp;
    ...
  }
}

impl は __block_impl で、中身は

struct __block_impl {
  void *isa;
  int Flags;
  int Reserved;
  void *FuncPtr;
};

となっています。えーっとつまり、2つめの引数に入ってる __main_block_impl_0 構造体の先頭は __block_impl 構造体で、__block_impl 構造体の4つめの FuncPtr がブロックの実体を指しているわけですね。

ブロックの呼び出しを追う

ここまで分かればブレークポイントを立てられます。2つめの引数は rsi レジスタなので見てみます。あ、すごい寄り道をしましたが、lldb は dispatch_async を呼び出したところで止まってます。

(lldb) p (void *)$rsi
(void *) $3 = 0x00007fff5fbff6a8

これが先ほどの例でいうところの __main_block_impl_0 構造体の先頭で、つまり、__block_impl 構造体の先頭でもあるので、ここから __block_impl 構造体の最初の3つの size(void *) + size(int) + size(int) 分、つまり16バイトを読み飛ばしてそこがブロックの実体のアドレスになります¹⁰。

(lldb) p *(void **)($rsi+16)
(void *) $4 = 0x00007fff90c427dd

これだー！ここがブロックの実体だ！ってことでブレークポイントをぽちっとな。

(lldb) b 0x00007fff90c427dd

ふう。これでブロックの中身、たぶんリクエストを非同期で実行する実体が書かれた箇所が呼ばれたら止まります。では c で続きを。

Process 18965 stopped
* thread #6: tid = 0x2703, 0x00007fff90c427dd Foundation`__+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]_block_invoke_1, stop reason = breakpoint 4.1
    frame #0: 0x00007fff90c427dd Foundation`__+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]_block_invoke_1
Foundation`__+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]_block_invoke_1:
-> 0x7fff90c427dd:  pushq  %rbp
   0x7fff90c427de:  movq   %rsp, %rbp
   0x7fff90c427e1:  pushq  %r14
   0x7fff90c427e3:  pushq  %rbx
(lldb)

はい、ちゃんとブロックの中身で止まりました。スレッド番号がこれまでと違いますね。ちゃんと並列化されているようです。って、ちょっ、ちゃんとブロックの実体の名前が表示されてるじゃん！そうです、実は

(lldb) b __+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]_block_invoke_1

ってやればブロックで止められたんです。まあそんなことわからなかったのでブロックの勉強になったってことでよしとします。

Objetive-Cのコードを追う

ここからはObjective-Cな感じで。Objective-Cのメソッド呼び出しはすべてランタイムの objc_msgSend で行われます。中身はアセンブラらしいですが¹¹、Objective-Cはコンパイラとランタイムによる協奏曲のようなもので、Cで動的で美しいですね。ということで objc_msgSend の呼び出しを監視すれば、Objective-Cのコードがなにをしているのか大体わかります。ではここにブレイクポイントを立てておきます。

(lldb) b objc_msgSend

では c で続けます。

Process 18965 stopped
* thread #6: tid = 0x2703, 0x00007fff8d9a8e80 libobjc.A.dylib`objc_msgSend, stop reason = breakpoint 5.1
    frame #0: 0x00007fff8d9a8e80 libobjc.A.dylib`objc_msgSend
libobjc.A.dylib`objc_msgSend:
-> 0x7fff8d9a8e80:  testq  %rdi, %rdi
   0x7fff8d9a8e83:  je     0x00007fff8d9a8eb0     ; objc_msgSend + 48
   0x7fff8d9a8e85:  testb  $1, %dil
   0x7fff8d9a8e89:  jne    0x00007fff8d9a8ec7     ; objc_msgSend + 71
(lldb)

はい、止まりました。objc_msgSend はリファレンスによると、

id objc_msgSend(id theReceiver, SEL theSelector, ...)

ということなので、一つめの引数がメソッドを呼び出す対象のオブジェクトで二つめがメソッド名となります。SEL の名前は sel_getName で見られます。id からクラス名を得るのはちょっとめんどくさくて、objc/objc.h の id の定義を見ると

typedef struct objc_object {
     Class isa;
} *id;

となっているので、まず isa の Class を得て class_getName を使います。ということでこうなります。

(lldb) p (const char *)class_getName(((id)$rdi)->isa)
(const char *) $5 = 0x00007fff90d22f23 "NSURLConnection"
(lldb) p (const char *)sel_getName($rsi)
(const char *) $6 = 0x00007fff8b1f75f6 "sendSynchronousRequest:returningResponse:error:"

結論

なんと！そういうことか！なんと、ブロックの中で +[NSURLConnection sendSynchronousRequest:returningResponse:error:] を呼び出しているではありませんか。どうやらこれが答えのようです。

+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:] は GCD で同期呼び出しである +[NSURLConnection sendSynchronousRequest:returningResponse:error:] をつかっていました！NSRunLoop なんて回していないし、NSThread でゴチャゴチャやっていない。いやはや。

というわけで、すでにすごい数ある NSURLConnection のFAQにもうひとつ追加。

NSURLConnection を非同期に簡単に並列化したい場合は、GCD の dispatch_async で +[NSURLConnection sendSynchronousRequest:returningResponse:error:] を呼び出す。

最初につくったものと同じような動きをするコードではこうなります。

#import <Foundation/Foundation.h>
#import <dispatch/dispatch.h>

int main(int argc, char *argv[])
{
    @autoreleasepool {
        dispatch_semaphore_t s = dispatch_semaphore_create(0);

        dispatch_queue_t queue = dispatch_get_global_queue(
                                 DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
        dispatch_async(queue, ^{
            NSURL *url = [NSURL URLWithString:@"http://www.google.com/"];
            NSURLRequest *request = [NSURLRequest requestWithURL:url];
            NSURLResponse *response;
            NSError *error;

            [NSURLConnection sendSynchronousRequest:request
                                  returningResponse:&response
                                              error:&error];

            NSLog(@"%@", response);

            dispatch_semaphore_signal(s);
        });
        dispatch_semaphore_wait(s, DISPATCH_TIME_FOREVER);
        dispatch_release(s);
    }
    return 0;
}

まあ、いろんな状況があるのでこれが最適解かといえばそうでもないと思います。これだと途中でリクエストを止められないとか問題がある気がしますし、その場合は、いまのところは NSRunLoop を回してバックグラウンドスレッドでぐんにょりみたいな感じでやることになるんでしょうね。

以上、長くなりました。

もっとこうするとかっこ良く挙動が調べられるよ！とか @niw まで教えてください！

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

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

あわせて買いたい

Mountain Lionって、たぶんこんなの。

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%;の指定をして特別デカイ文字でニュースを掲載したことが話題になりましたの。参考画像がこちらです。

blog.niw.at

JSConf 2012 に来てみた

SFO から一路 PHX へ

パーティー、そしてパーティー

カンファレンス初日

あわせて買いたい

オンラインバックアップ CrashPlan を使ってみた

そこでオンラインバックアップ

CrashPlan を使ってみた

お値段などなど

ダメなところ

ふと思ったのですが

あわせて買いたい

あわせて読みたい

未来のカメラ Lytro を使ってみた

届いた！

本体の様子

デスクトップ・アプリケーション

ウェブで共有

本体落とすとこうなる

まとめ

あわせて買いたい

米国の iPad WiFi + 4G のアンロック具合

NTT DOCOMO の SIM カードを指してみた

AT&T の SIM カードを指してみたけれど

日本国内で Softbank が販売する iPad WiFi + 4G について

あわせて買いたい

Mac OS X Lion の起動 USB を作る過程でハマった

起動ディスクを作る

そしてUSBから起動

あわせて買いたい

Uber の トム

あわせて読みたい

だいぶ実装がアレな SkypeLogger の解説

SkypeLogger の紹介

SkypeLogger の概要

SIMBL の仕組み

SIMBL プラグインを作る

Skype API を使う

Skype API のバグ？ 仕様変更？

まとめ

あわせて読みたい

Instapaper から Readability に移行する

中身の話

あわせて読みたい

Mac OS Xで追加された絵文字が怖い件について

あわせて読みたい

+[NSURLConnection sendAsynchronousRequest:queue:completionHandler:] が何をしているか調べてみた

まずは使ってみる

はじめに

デバッガ起動

GCD の呼び出しを追う

dispatch_async の呼び出し

ブロックの実体について

ブロックの呼び出しを追う

Objetive-Cのコードを追う

結論

あわせて読みたい

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

あわせて買いたい

Tahoe にスノボに行って来た

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

おまけ - gdbで追いかける

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

移管先を探す

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

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

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

移管完了

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

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

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

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

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

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

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

boundioで電話を鳴らす

2011年を振り返ってみる

687人、140文字をお届け

59,693マイル、15区間

Uber のトム

Skype API のバグ？仕様変更？

せたが屋ニューヨーク

一風堂ニューヨーク