2014-01-25

Chromecastでお手軽wifiスピーカー

Chromecastというデバイスがあります。今日はそれを使ってちょっと遊んでみた、というもの。

Chromecastとは何か……というのはご存知の皆さんが多いのでかなりはしょりますが、下の写真のようなガジェットです。テレビに直接挿して使い、コンピュータや携帯電話のアプリから動画や音楽を流して試聴できる。
chromecast
対応サービスやアプリがまだ米国主体というのもあり、日本では未発売ではありますが、$35という低価格もあってこちらではそれなりに受けの良いガジェットのようです。ただ、動画とかをテレビで観るのはそれはそれで良いのですが、音楽だけなら画面いらんよなーとは誰しも思うところです。

というわけで今回はこのChromecastと Panlong HDMI Audio Extractor Decoder/Converter というコンバータを組み合わせます。こちらは HDMI を入力とし、画面出力は無視してオーディオ出力だけを出す、という、まさに今回の目的にうってつけのものです。
オーディオコンバータ
Chromecastと合体させれば、これだけでもう任意のスピーカーをwifiスピーカーにしてしまうことができるわけです。もちろん画面は出せませんけど、YouTubeで音楽を聴いたりとか、あとまあ音楽をGoogle Musicに上げてさえおけば、ふつうに音楽を流すぐらいはまったく支障ありませんね。
合体!
と、いうわけで、これを電源につなぎ、オーディオ出力の先に適当なスピーカーをつなぐと、どんなスピーカーでもあっというまにワイヤレススピーカーに!というわけですね(結線後の写真は省略します。ケーブルがごちゃごちゃして汚いので(笑))。

まだセットアップしたばかりで、あまりにも普通に音楽が聴けてしまっている状況のため感想も特にないのですが、これはかなりお手軽感があります。コンバータも思ったより小ぶりだし、Chromecastも小さいし。

もちろん、ワイヤレススピーカーなんてありふれてるといえばそうなんですが、どんなスピーカーでもワイヤレススピーカーにできてしまうという面白さと、それからChromecastは複数台から同時接続するのが簡単なんですが、その簡単さなどは魅力かもしれません。これはちょっとなにかあるかもしれない。気のせいかもしれないけど。

なおこのテクニックは比較的有名なようで、↑のオーディオコンバータのレビューでも Chromecast で使うと便利というものがあるし、なにしろ Frequently Bought Together が Chromecast になっておりまして、かなりメジャーなテクニックなようです。
どうでもいいけどこの組み合わせでHDMIケーブルはいらないよなー
ちなみに、Chromecastのセットアップは、いちおう画面を見て操作することが前提になっています。一番はじめはChromecastが画面にセットアップガイドを出すし、最初にコンピュータと接続してセットアップするためには、画面に出てくるランダムな数文字を確認して、あっているかどうかを確かめる必要があります。ただまあ、たまたま近所で同時にセットアップしている人がいない限りは、みずてんでオーケーしてしまっても、まあたいていは大丈夫なんではないかなあと思うわけですがいかがでしょう。どうしても気になるなら、はじめのセットアップだけはテレビを使えば良いかなとも思いますが。

まだ日本に来てないChromecastの話なんでアレですが、これはちょっと面白いなと思った次第です。

2014-01-19

天冥の標 7 新世界ハーブC



天冥の標7 新世界ハーブC

これは……「ギャルナフカの迷宮」?

前巻で「救世群」に追い立てられて主人公たちが逃げ込んだ先、その閉鎖世界のなかでどうにかあがいて生き延びていくという物語であり、ようやく1巻に続く設定が明かされることになるという7巻でした。閉鎖世界で生き延びるうちに国を作り上げていくというのは同作者の「ギャルナフカの迷宮」(『老ヴォールの惑星』所収)を思わせるところがあるなーとも思うんですが、いや、やっぱりそれなりに成熟した少数の大人で構成されていたギャルナフカとは違いますね。主に少年少女で構成される世界をスカウトたちがなんとか仕切ろうとして、けっきょくのところリソース不足からだんだんぐだぐだになっていくという流れは、なんというか、ため息しか出てこない。

それでいて物凄く嫌な話にはなっていないのがうまいところ。この手の話でわりと適当にごまかしがちな性愛の問題を、SF的な理屈をつけることでひとまず落ち着かせておいて物語を進めるところもうまいといえばうまい。

メニー・メニー・シープの正体については、それほど意外感はないというか、まあこんなところでしょうという印象が半分ぐらいなのだけれど、この巻で描かれる閉塞感と1巻の開放感のある感覚とはちょっとかけ離れすぎというか、やっぱりこう、ギャップが大きいようにも思える。小川一水本人自体の力量が7巻まで進むうちに上がってしまっているのも一因という気がするけれど。

しかしここから300年というのはちょっと盛りすぎたんじゃないですかね小川先生……。300年間も防衛できていたダダーがすごいよ。

設定的にも解決できない部分を残すことでヒキがあるのも気になる。次はようやく1巻以降の話ということになるんでしょうか。と思って1巻のラストを読み返したら、いやーこれは厳しいですねー……。この展開から続きってどうありうるんでしょうか。気になるところです。

2014-01-06

冬休みなのでNaClで遊んでいた


せっかくの休みなので仕事と関係ないことでもすっか、と思い、NativeClientで遊んでいました(微妙に関係するのかなこれ)。Google+で #冬休みの自由研究 というハッシュタグを勝手に作って適当にあれこれ書いていたんだけど、そういえばなぜか限定公開にしてたので誰でも見える状態にはなってませんでしたね……。

なのでブログで簡単に記録を残しておきます。

やったこと:GaucheをNative Clientで動かそうと四苦八苦して挫折。その後 chibi-scheme を動かそうとしたらあっさり達成

いちおうはじめから書きましょう。

NativeClient(通称NaCl)とは何か?

NativeClientは、ブラウザ(Chrome)のなかでネイティブコードを動かすためのモノです。SDKはカスタムメイドなCコンパイラでして、少し特殊なかんじのバイナリを生成します(nexeという拡張子がついています)。Googleが作ってます。

作ったバイナリは、objectやembedなどの要素でページに埋め込み、別プロセスで実行されます(この時にバイナリを検証します。で、NaClのコンパイラで生成したバイナリにはちょっとした制約があるため、セキュリティ的に問題のあるようなコードが動かない、つまり、サンドボックスを突破して利用者側に不利益のかかるような悪意のあるプログラムを配布できないようになっています)。ページのJSからは postMessage / onMessage を使ってやりとりするというかたちになります。

よくasm.jsと比較されることがあるのですが、個人的には性格が異なるかなーと思ってます。NativeClientは(特殊な調整がされているとはいえ)普通のELFバイナリなので、けっこういろんなことができます。pthreadでスレッドもあれこれできたり、環境によるけどdlopenできたり。asm.jsは最終的にはJSの意味論に落ちるので、やるのが難しいことがあるんじゃないかなぁと思うんだけどどうなのかなあ。

GaucheをNaClで動かす

そういうわけでNativeClientではネイティブコードが動くわけですが、実際の用途として想定されているのは、パフォーマンスが大事なエリアだけCで書いて頑張る、といったことかなと思います(そういうサンプルがSDKに添付されてるので)。だけど、こう、折角だからスクリプト言語とか動かすと面白いよね、と思う人はいっぱいいるようで、Ruby、Python、LuaについてはnaclportsというNaCl用のパッケージ集みたいなところに入っています。

で、Lisp系の言語はなかったみたいだしGaucheどうかなと、思ったわけです。うっかり。

目算はありました。というのは、GaucheはガベージコレクションとしてBoehm-GCを使っているわけですが、Boehm-GCはnaclportsに入っているのですね。だからそれほど問題はないのかなと思ったわけですが……。

naclportsのBoehm-GCが全然動かねえ!

という次第でありました。NaClもいちおう普通のELFバイナリではあるとはいえ、それなりにおかしなところもあるので、そう簡単な話ではなかったというわけです。

NaClが動かない場合のデバッグは大変で、いちおうSDKにはgdbが付属しているんですが、年末帰省でChromebookしかない状況だったため、gdbつきでNaClバイナリを動かすことが出来ません。デベロッパーツールを見るとクラッシュしたことだけがわかる(スタックトレースも何もわからない)という状態。

ただ、後述する方法によってstderrに書きだしたものはIPCを経由してconsole.errorとして吐き出されるようにできるということはわかったのが救いで、これを使ってprintfデバッグという超原始的な手法に着手しました。とはいえfflushしてもフラッシュしてくれないので、クラッシュするタイミングとIPCの調子によっては実行してるのにログが吐かれないということもあったりするため、何度もクラッシュさせてみて「ここまで出ることはあるからここで落ちているんだろう」と推測して、とかしていました。

そういう謎の苦労のすえにわかったのは、GCの初期化時の問題だということでした。Boehm-GCはマーク&スイープのルートオブジェクトの集合として、スタック上の変数とグローバル変数をとっているわけですが、どうやら Boehm-GC がグローバル変数の領域と思っているエリアがおかしい気がする。といったところに当たりをつけたぐらいで神のような方が教えを授けてくれたわけですが、まぁ要約するとこれは無理っぽいなと。

その辺は今後解決されることを期待しつつ #define GC_MALLOC malloc 的な手段で(メモリリークを気にせず)やろうかなとも思ったんですが、Gaucheはatomic_opsにも依存しているしGC_baseもあるし、ちょっとだけ手を入れる必要があるみたいだし、といったあたりで気力を失ってしまいました。

まあ、ふだんあまり触らないような低レイヤーの領域の知識がちょっとだけ増えたのでよかったかなと思います。

chibi-schemeをNaClで動かす

で、気分を変えてchibi-schemeを動かしてみることにしたわけです。chibi-schemeを選んだ理由は、scheme処理系のなかでは実装がコンパクトっぽい(と聞いたことがある)のと、自前のシンプルなgcを持っているので↑のようなしんどい目にはあわなくて済みそう、という理由です。

で、こっちは動きました。あまりにも簡単に動いたので逆に拍子抜けしたぐらいです。Gaucheは(というかGCは)なんだかんだで一週間弱ほど苦闘していたわけですが、chibi-schemeにはほとんど罠がありませんでした。

chibi-schemeはpnaclでも普通にビルドができたので、動作環境をふつうにウェブページとして公開しておきます→こちら

pnaclとNaClについて書いておくと、NaClは普通のネイティブコードバイナリを配布するものなのですが、いまだに利用環境に制限があり、通常のウェブページには埋め込めません。 Chromeアプリとして配布されたものでしか使えないのです。pnaclはportable NaClの略で、NaClと違ってネイティブコードでは配布されません。LLVMのビットコードを使ったpexeというファイルで配布され(よく知らないのであやふやな表現)、ブラウザのネイティブ環境に変換されて動きます。こちらはなぜか制限がなく、普通のブラウザでも――ってもちろんNaClに対応しているブラウザなのでChrome限定ですが――見ることができるようになっています。

ppapi_simpleとnacl_ioについて

さて、NaClで苦戦した「遊び」でしたが、多少はほかのことも習得できました。ここではppapi_simpleとnacl_ioを紹介したいと思います。

そもそもNaClのコードは、ちょっと特殊な構造になっています。はじめにこういう名前の関数が呼ばれる、こういうクラスのサブクラスを作っておくと、JSからpostMessageが届くとこのメソッドが呼ばれて、そのときの値はこれこれで、などなど。

ppapi_simpleはその辺のことを面倒見てくれる便利ライブラリで、NaClのSDKに添付されています。普通のCのint main(int argc, char* argv[])のような関数を定義し、PPAPI_SIMPLE_REGISTER_MAIN()というマクロでその関数を登録しておくと、「初期化する」とかいったこまごましたことをひと通りやってくれて、mainのなかでループを書いてメッセージを受け取る、といったことができます。メッセージを標準入出力をとして受け渡しするようなこともでき、REPLの実装などがラクになる感じです。stderrに出力するとconsole.errorになってくれるというのもppapi_simpleの機能だったような気がします。

nacl_ioはファイルIOのためのラッパーです。スクリプト言語を動かす場合、初期化するにしてもライブラリを読むにしても、どこかにあるファイルを読む必要があります。ところがこれが厄介でして、HTML5のfilesystem APIはNaCl用の独自のAPIを呼ばなければなりませんし、NaClバイナリと同じディレクトリにファイルでも置いておくかと思えばHTTPでフェッチしないといけないし、かなーりめんどうなわけです。

nacl_ioはディレクトリをマウントすることでその辺をラップしてくれる便利ライブラリです。"httpfs"という擬似ファイルシステムが指定できて、こいつを指定するとファイルをopenするだけでフェッチしてどうこうみたいなことをまるっとやってくれています。上で指定したchibi-schemeでもこれを使っているので、様々なライブラリをロードできますが、その都度ロードしているのでimportするとネットワークを感じます。

naclportsに入っているLuaやPythonなどでは、必要なライブラリファイルなどをまとめてひとつの .tar ファイルにしておき、これをhttpfsで開いてlibtarを使って(やはりnacl_ioでmemfsとしてマウントされている)ディレクトリに展開する、といったことをやっているようです。都度ロードはやっぱり遅いですからね。

そういうわけで、「NaClで遊ぶ」の一部始終でした。

2014-01-04

小谷田奈月『星の民のクリスマス』



星の民のクリスマス

第25回日本ファンタジーノベル大賞の大賞受賞作。結論から書いておくと、自分はけっこう気に入った。良いと思います。

ある歴史小説家が幼い娘のために書いたクリスマス童話。ところがその娘がその童話の世界に入り込んでしまう、というメタフィクション的なファンタジーだ。童話のほうはトナカイとサンタクロースとキツツキの子が出てくる可愛らしい掌編だが、この童話をベースにした「町」は長い歴史を持つ異世界になっており、サンタはいないし、トナカイもキツツキの子も象徴的い扱われている。そんな町に迷いこんでしまった娘と父親の歴史小説家によって引き起こされる騒動、とまあそんな感じの話。

設定的にはわりによくありそうなファンタジーという気がするが、この作品のユニークなところは、こういう構造のファンタジーとしては、童話がベースになった「町」が妙に現実的だというところだろう。もちろん常に雪が降っていて雪が光るといった設定は童話的なのだけれど、この町自体には長い歴史があり、民主的な政府があり、人々もふつうに生活をしている。クリスマスを意味する「贈り物」は町の重大なイベントだと認識されてはいるものの、それがなぜかといえば、贈るという行為が町と光る雪の維持に欠かせないものだという認識があるからであって、誰に、何のために贈るのかすら町の人々はわかっていなかったりする。配達員たちは世代交代しつつその任務を負っている。

町に住む登場人物たちも、それぞれに複雑な背景を背負っていて、味がある。なかでも味があるのは、トナカイの子の役を担うキャラクターだろう。幼いながらに高い知能を持ち、町の歴史に興味を持っているトリックスター的なキャラクターだ。そういうキャラクターだからこそ、町のいわば「創造主」である歴史小説家と邂逅することで物語が進んでいくというわけだ。

ただ、読んでいて感じたのは「よく書けていて面白いけれども、まあフツーだな」というものだった。上述したような設定は確かにひねってあるといえばひねってあるが、ものすごく斬新ということでもない。お話としてはよく出来ていて楽しく読めるが、突出してはいない。

だったのだけれども、最後まで読んで気が変わった。詳しくは書かないが、最後の最後でこの話にはメタフィクション的なオチがつくのだけど、そこが気に入った。メタっぽい構造だよなあと思いつつ読んでいるとオチそれなんだ!というのが心地よかった。

もちろんこのオチだけで評価するというのは正しくないと思うけれども、そういうわけで全体としてはぼくはけっこう気に入った。それがなくても、完成度の高いファンタジーだと思う。