渋日記@shibu.jp

アメリカは自分中心すぎる、みたいに言われる理由の一つが温度。アメリカでは天気予報が華氏(℉)を使っています。とはいえ、日本でも馴染みがあるけど他国で使われてない単位とかいっぱいあるし、タタミ一畳の広さは地域によって違うとか、さらにヒドイものもあるし、まぁ郷に入っては郷に従えでいいのかな、と思っています。

DeNAサン・フランシスコの大塚さんが、以前Facebookにこんなことを書いてました。

そもそも、摂氏のほうが、水の凝固点が0度、沸点が100度と、曖昧なポイントに0度と100度がある華氏よりも実用的だと個人的には思うのですが、アメリカ人の友人には、「そんなことはない。華氏100度になると、人間はくたばる。華氏0度になると、やっぱり人間はくたばる。だから華氏の方が明確で実用的だ。」と言われ、少し負けたと思ってしまいました。

これは分かりやすい。摂氏は水が基準。華氏は人間が基準。華氏も人間の体感と結びつけて考えれば数値を言われた時に「ああ、このぐらいか」「こういう服装でいけばいいか」と考えやすいのではないかな、と思います。頭に換算表を作るのではなく、イメージを作るというのがこのエントリーのゴールなので、あえて摂氏は書きません。

• 0: 人間が死ぬ温度。スキー場でも北海道の内陸とかじゃないといかない温度。
• 50: アメリカ人がTシャツになり始める温度。日本人は長袖。サン・フランシスコの冬、東京の秋がこのぐらい。
• 70: 日本人もTシャツになり始める温度。アメリカ人は上半身ハダカになり始める。サン・フランシスコの夏がこのぐらい。
• 80: マイアミとかリゾートな温度。
• 100: 人間が死ぬ温度。熱中症とかがニュースに出てくる温度。体温として考えても、病院にいったり薬を飲む温度。
• 375: 天ぷらとかオーブン料理をする温度。

だいぶ僕の中でもイメージができあがってきました。

カリブ海に1週間クルーズ行ってきました。世界最大の船のAllure of the Seasは圧倒的な大きさでサンダルで歩いたら擦れて足が痛くなるレベルでした。バハマとかは行ったけど、パスポートの提示を求められることは少なく、アメリカ入国で税関書類は書くけど入国スタンプは押されないし、国内旅行の延長扱いでI-94ステータスの更新にはならない(Customs and Border Protectionの窓口で確認済み)のでアメリカ滞在者は要注意ですよ。

帰ってきたらいつの間にか都知事選が終わっていたり、オリンピックが始まっていたり(クルーズ船の中のスポーツバーで放送してたのはスーパーボールとXGameとNBAぐらいなので知らなかった)していたのと、なんか東京の食事に関するブログの記事が話題になってました。

• 東京の飯の話
• 東京は住みにくい

辛さに慣れてくると辛さの裏の野菜の甘みとかが感じられるようになるのが中本の奥深さ。まぁ中本は特殊な例なので中本基準＝東京で話をしちゃうと「えっ」という人は多い気がする : 東京の飯の話 - Mokosoft開発者ブログ http://t.co/zQxjiBh7oW

— 渋川よしき (@shibu_jp) February 11, 2014

東京のチェーン店の数が多いとはいっても、人口あたりの店数は少なかったりする。東京の中本だって、宇都宮餃子のみんみん/正嗣よりは少ないと思う。

— 渋川よしき (@shibu_jp) February 11, 2014

東京圏の人口は3000万人らしい。これで中本が14軒なので1軒/200万。餃子のみんみんは同じ店舗数だけど宇都宮の人口は50万なので60倍の密度。正嗣は4軒だけどそれでも中本の10倍以上と言える。

— 渋川よしき (@shibu_jp) February 11, 2014

まあ東京圏の人数とWikipedia？に書かれていたのは東京＋横浜で、中本は大宮とか北の方にはあったけど南はあまりなくてちょっと偏りがあるので厳密なカウントではないけど、だいたいのオーダーはこんなもんかと思います。

つまり、東京の食事事情よりも、いかに宇都宮の餃子が狂っているか、というのがよく分かると思う。

— 渋川よしき (@shibu_jp) February 11, 2014

@atsuoishimoto しかも、中本のカテゴリーは他の店はあまり聞かないけど、宇都宮餃子のトータルの店の数を考えると、地域性を考えるときの中本の影響力の小ささと宇都宮の異常性は一層明確かと思います。

— 渋川よしき (@shibu_jp) February 11, 2014

東京はでかいので、人口比を計算すると、他の町の方が圧倒的だったりすることがよくあります。「とちぎRuby、人口比でいったら東京の勉強会よりも圧倒的に多いじゃん」みたいな話をしたこともありましたね。10数人参加だと、毎月Ruby Kaigiクラスの勉強会を開催しているイメージですよ。あと、「一見さん相手だけでも生き残れる」というのは、観光地の鎌倉がそんな感じ、という話を聞いたことがあります。とにかくランチを食べる場所が少ないし、観光客相手の店が多くてみんな高い、と鎌倉で仕事をされていたカヤックさんの方が言われてました。鎌倉に比べたら東京は選択肢が桁違いに多い気がします。

サン・フランシスコにいると、ちょっとしたレストランでも結構かかります。ただでさえ高いうえに、チップ＋税金(外税)で3割近く額面から増えることもザラ。チップも、税金を抜いた額の15%程度で、ランチは10%、みたいな日本語の説明はあるけど、15〜20%、社交的なイケメンはざっと切り上げてさらに気前よくチップを置いとく、みたいな感じで15%は最低限という感じですね。

結果、夫婦でハンバーガーとかラーメンのお店で$35とかいっちゃいますし、「レストラン」という感じのところだと最低で$50ぐらいのイメージ。ランチでしゃぶしゃぶ(SHABUWAY)で$25、ベトナム料理のフォーとかアジア料理の店で$20-$25というのが安いクラスかなぁ。それ以下だとマクドナルドとかバーガーキングみたいな安い上にチップがいらない店とか、ホットドッグ等の食事というかスナックみたいなものしかないですね。コストで考えれば東京の方が1000円以下ぐらいのところで選択肢がいろいろあって、良い所が多いと思います。モールのフードコートも日本の方が値段的に良い気がします。Panda ExpressとかモンゴリアンBBQがかろうじて勝負できるぐらいかな、と。サン・フランシスコとかストレスがマッハな気がするので、食事事情が大事という人はあまり来ないほうがいいかもしれません。カレー10食連続でもOKという程度の意識の低い僕には問題ないですが。

他人の味覚という世界

味覚って言葉で正確に伝えるのって不可能なんですよね。冷たい水の味がどう感じるのか、言葉で説明できる人はおそらくいない。あくまでも、同じようなバックグラウンドを持つ人が「この料理みたいな味」とか相対的に伝えるか、ワインのソムリエみたいなイメージで伝えるしかなくて、直接的に表現するのはできない。で、バックグラウンドが違うとおそらく会話ができない。優劣をきちんとつけるのも難しいし、一方的な相手のDisにしかなりようがない気がします。

このことは過去Twitterで何度か書いているので僕を知っている人は何回か見聞きしているかもしれませんが、以前、インドの人(ヒンズー教で牛がダメ、週に一回すべての肉類がダメ)とパキスタンの人(イスラム教で豚がダメ)を一緒にランチに連れて行くという過酷なミッションを遂行したことがありますが、その時は「まぁ豆腐のコース料理の店なら肉使ってないから大丈夫でしょ」と思って連れて行ったら、「味がない」というようなことを言われました。チリに行った元同僚も「チリは塩味が濃い」と言っていたし、基準となる塩味のレベルですら地域差が結構あって、「すべての人が満足」という味を作るのは不可能なんだな、と悟ったできごとでした。

で、日本の人は「ダシが大事」と言いますが、しばらくアメリカにいてから久しぶりに日本に戻ると違和感を感じるものがあります。うまみ調味料(グルタミン酸ナトリウム)というやつです。日本ではいろんなところでうま味調味料がすごい使われています。アメリカではグルタミン酸ナトリウムはあまり健康に良くないものという扱いで、No MSGとか書かれている店とか食品がたくさん目につきます。うまく消化できない人に体調不良になることもあります。アメリカでは塩と脂が多少多くてもうまみ調味料を使うことはないので、料理がシンプルな味に感じます。まぁ、塩分がちょっと多いアメリカのSalt & Vinegarのポテチと、うま味調味料が効いていて塩分が多少少ないカルビーのコンソメパンチのどちらが体に悪いかというとどっちも良くない気はしますが、ちょっと距離をおいてみると日本は「うまみ調味料依存症」だなぁ、と感じます。僕はSalt Vinegarのアメリカンポテチの方が好きですね。

あと、サン・フランシスコでありがたいのは、屋内の喫煙が禁止な点。日本の飲み屋とかの室内のタバコの臭いとか僕にはちょっとムリです。サン・フランシスコも外に出ればタバコとかマリファナとか臭ってくることもありますが、バーとかレストランで煙の匂いが一切しないのはうれしいです。

別の例をあげます。日本のスーパーにはさまざまな種類の醤油がおいてあります。出汁も、カツオからコンブから煮干しからいろいろあります。当然日本人でこれらの差を識別できる人はたくさんいます。で、一方のアメリカ。今朝近所のスーパーで撮ってきたんですが、アメリカには大量のバーベキューソースが売っています。同じ銘柄でも何種類も。日本人の僕にとっては、まだこれらの味の差がよくわからないです。「アメリカ人はバーベキューソースをかけてみんな同じ味にしてしまう」ということを言っている日本人もいます。でも、これだけ種類があるということは、アメリカ人にはこれらのソースの味の差が付けられるということです。

この「味覚の解像度の差」は結果として以下の2種類の判断につながります。

• 自分にはこの味の差がよく分かる。あいつらは「味がない」とか「違いがない」とか言いやがる。俺の方が味覚がすぐれている。
• あいつらはどれもこれも同じ味にして満足しやがる。あいつらの味覚は壊れている。俺のほうが味覚がすぐれている。

どちらも同じ結果になって、お互いに「俺のほうが優れいている」という考えを強化しあうことになります。最初にあげた水の味だって、状況次第でまったく「おいしさ」が変わりますよね。僕は料理番組の中では、難しい顔して食べてる料理の鉄人よりも、幸せいっぱいに食事を楽しんでいるでぶやの方が好きです。

トイプー教のススメ

まとめると：

• 東京はまだマシな方。サン・フランシスコにも中本と丸亀製麺欲しい。
• 味覚をお互いに比較するのは難しいし、生産的な会話にならない。

とりあえず、味覚で相手をDisった記憶が一度でもある人は、下記の言葉を胸に刻んで、町中でトイプーを見かけるたびに手を合わせて拝むようにすれば、不要な争いはなくなるんじゃないでしょうかね。

「東京は飯がまずい」と切り捨てるのではなく、「東京は美味しくない店でも見捨てない、優しい人たちの街」と暖かく見習ってみてはどうでしょう

— Atsuo Ishimoto (@atsuoishimoto) February 11, 2014

そういえば、Twitterのアカウントを増やしました。日本語のツイートは今後@shibu_jpになります。

2011年1月入社なもんで、もう丸3年ですよ。もう4年目。2011年からあったこと、思ったことを箇条書きにしてみる。

• 2011年1月4日。初出社。昼ごはんに選択肢があるというのが新鮮！(ホンダの研究所の周りは田んぼ)
• DeNAの新卒スキル高すぎ。意識も高い(良い意味で)。
• DeNAメンバー増える速度凄い。凄い仲間がいっぱいできて楽しい。
• 2011年3月11日。初台のビルで地震にあう。
• 2011年4月。結婚。ソニック婚というかソニックの音楽＝Crush40婚なのでCrush40ライブの日に入籍届出す予定だったけど、地震でライブは延期。でも予定日に出した。
• 2011年4月。結婚式。お寺婚。
• 2011年5月。初サン・フランシスコ出張して、日付が変わるころに帰国して次の日に初台に出社してその次の日からハワイ新婚旅行というエクストリーム新婚旅行だった。
• 2011年9月。セカンドパーティプロジェクトで某社さんのところにいっぱい行った。楽しかった。自分が子供の頃から知っているIPタイトルにちょびっと関われた。不思議な感覚！
• 2012年1月。Arctic.jsライセンス問題。午前に炎上して午後に社内のOSSの濃いメンバーが集まって議論して楽しかった。あのメンバーで新年会とかしたい気がする。
• 2012年2月。アメリカのサン・フランシスコに引っ越し。Qt + JSというニッチな仕事。ベイスターズとヒカリエを見ることなく日本を発つ。家のインターネットは6Mbpsのエリートコース。
• 2012年8月。長女生まれる。
• 2012年11月。新規タイトル開発の補助にエンジニアとして関わる。内製ツール開発にはガッツリ本気で使い込んでくれるユーザさんの巻き込みが大事だよなぁ、というのを実感した。アメリカ人のメンバーは朝早くから職場にいて早く帰ったりもするけど、夜遅くまでチャットで仕事してたり、土日や大晦日とかもメールが飛んだりして、アメリカ人像がちょっと変わった。
• 2012年12月。執行役員になるhidekさんをパシリに使ってしまった(出張でUSに来る時にセガのホームスターを持ってきていただいた)。
• 2013年1月。JSX触り始める。検索エンジン作った。
• 2013年4月。自分が物心つく前から知っているIPタイトル(空港でセキュリティで銃が映って取り調べられそうになったけど、銃がロボットに変形した事件)に関われた。不思議な感覚！JSXのQtラッパーを作って実戦投入。
• 2013年5月。JSDoc3を使ってみる。社内にJSDoc3コミッターがいた！エンジニアブログにも書いてみた。
• 2013年9月。カリブ海のクルーズ旅行に行った。子連れだとクルーズ旅行は便利。買ったばかりのコンデジ が行きの飛行機で帰らぬ人に。帰りはオーランドの空港が混みすぎて90分前に空港についたのにチェックインできずに1日空港で過ごした。iPhoneはハイチの海の藻屑となった。
• 2013年12月。娘が人形とかよりも、電車と鉄道模型に大興奮な子に育つ。

ネットで有名な人が社内にいて一緒に仕事できたり、昔、岡山にお呼ばれしたときに一緒に発表した人とサン・フランシスコの職場で会ったり、日本人以外の人のFacebook友達が増えたり、なかなか面白い経験や刺激がたくさんあります。ホンダ時代にベルリッツに100万円ぐらい課金したけど、無駄ではなかった。

仕事的にはngCoreのJavaScriptだったり、Perlをちょびっと書いたり、Knockout.jsとBootstrapでウェブアプリ作ったり、MongoDBだったり、node.jsだったり、Qt + JavaScript環境だったり、C++だったりという感じ。所在地は変わったけど、一貫して社内のツールとかフレームワークとかライブラリみたいな部署にいます。食わず嫌いはせずに、必要であればどんどん新しいこともするよ、というスタンスでいるけど、基本的にJavaScriptが多いですね。DeNAに入ったら自然とPerlハッカーになれるかと期待していたけど、そういうわけではなかった。いろいろ宿題(pull requestに対するコメント)が溜まっているので、新年早々はJSXへのコミットをちょっとがんばろうと思います。

この前、誰もが知っている某社から転職オファーとかあって、H1Bビザの手当とかもしてくれるとのお話もいただいたけど、もうちょびっとDeNAのお世話になろうかなぁ、という次第です。

JSXアドベントカレンダーのエントリーです。

2年ぐらい前から、QtをJavaScriptから使うというのをやっています。その延長でJSXから使うというのもずーっと、細く長くしぶとくチャレンジしています。12月12日に出たばかりのQt 5.2でうまくいきそうな感じなので、その成果を紹介します。コード片とかいっぱい書くのはめんどいので、コード片やサンプルはリンク先を参照してください。

Qt + JSの歴史

QtをJavaScriptから使うというのはかなり昔から先人たちによって行われてきたものの、今は誰も本気で取り組んでいなくて、ロストテクノロジーになりかけています。Qtは2007年5月リリースの4.3でQtScriptという名前でECMAScriptのエンジンを搭載しました。当初の目的はQtを使ったGUIプログラムのマクロ言語として使うというものでした。QtScriptEngineにQObjectを継承したオブジェクトを簡単に登録できるため、C++を使って作ったクラスを簡単にECMAScriptエンジンに公開することができます。簡単にECMAScriptの名前空間にメソッドや変数などを登録するAPIも持っています。当初はQt Script for Applicationsと呼ばれる処理系だったみたいですが、後にJavaScriptCoreが使われるようになりました。5.x系になって、V8が搭載されましたが、それはQMLとかQtQuickと呼ばれる環境向け限定で、スクリプティング用途では互換性のために相変わらずJavaScriptCoreが使われています。

当初はC++アプリケーションにスクリプティングを提供するのが目的でしたが、Qtのプログラム自体、全部JavaScriptで作ればいいんじゃね、ということで開始されたプロジェクトがQtScript Binding Genratorです。NokiaのQt Labsの公式です。ドキュメントとかほとんどないので経歴とかはよくわからないのですが、コミット日時をみると4.4のころにスタートしたみたいです。これはQtのクラスのうち、半分ぐらい(600/1200)のクラスのためのバインディングを提供します。コンストラクタ関数やら、可変長引数に対応したインスタンスメソッドやら、定数やら、protectedメソッドを予めオーバーライドしておいて、JSで定義されたメソッドにフォーワードするShell Classと呼ばれるクラス群を生成します。Qt Script Binding Generatorのソースコードを見ると、先行して開発されていたJava BindingのQt Jambiを流用して作らていることがわかります。4.6ぐらいまではNokiaがメンテしていましたが、その後メンテはとまっています。この間も、古いQt Labs、Google Code、新しいQt Labsといくつかリポジトリがありますが、Qt Labsが一応最後の公式リポジトリです。ちなみに最新の更新は2013年になっていますが、NokiaがQt事業をDigiaに譲渡だか売却した際の名義変更コミットだけで、更新はされてません。

その後は、Sarunas Valaskeviciusというイケメンイギリス人が5.0対応のコミットを大分前に行いました。5.0で内部のプライベートクラスの構造が色々変わったのですが、彼がそれへの対応をしました。ですが最終コミットが5.0正式リリース以前で、Generator(C++のヘッダをパースして、XMLを読み込んでコード生成する)は5.0対応になりましたが、言語間の差異を吸収するxmlファイルはほとんど変更されていませんでした。彼はその後、作ってV8を搭載したQML環境のためのBinding Generatorに注力しているため、5.0リリース前夜にpushされたコード以降メンテはされてません。。

僕はそのイケメンイギリス人のリポジトリをフォークして、ぼちぼちQt 5.0系の新しいモジュール構成に対応させたりしていました。5.1がリリースされたときに一度作りきったものの、生成したモジュールを動的にロードする部分が動かなくてあきらめていましたが、この前でた5.2ではめでたくうまく動いたのでようやく陽の目を見ることができそうな感じです。コード生成部を追加してJSXのJSラッパーコードも一緒に生成します。TypeScriptとかHaxeのラッパー作りたい人はどんどんフォークしてやっちゃってください。

Qt + JSの使い方

HTML5アドベントカレンダー向けのエントリーです。ブラウザでできることがどんどん増えています。2013年に一部で熱狂的な話題となった本の高速文字列解析の世界 を読んで意識が高まったので、勢いにまかせてブラウザで動く検索エンジンを作ってみました。写真は著者の岡野原さんにお会いしたときにいただいたサインです。

ブラウザ上の検索エンジンと転置インデックスと東アジアの微妙な関係

全然調べていないので、歴史とかよくわからないのですが、僕が始めてブラウザ上で動く検索エンジンと出会ったのは、Sphinxです。SphinxはPythonで書かれたドキュメントツールです。ドキュメントツールというとJavaDocを始めとして各種あります。大きく、自然言語中心のもの(Texとか)と、APIリファレンスの生成ツール(JavaDocとかDoxygenとか)があります。自然言語中心のものはAPIの変更を手で追従しなければならず、自動生成のリファンレスは人が理解しやすい順序に構成して文章を提供するということができません。Sphinxはマークアップで書かれた中に、ソースコードから抽出したドキュメントを埋め込めるようにして両方のいいとこ取りをしていて、PDFにすると3000ページを超えるというPythonのドキュメントを支えています。Pythonだけでなく、PHP系のコミュニティやさまざまなコミュニティで使われています。

SphinxにはjQueryを使って作成されたブラウザ上で動く検索エンジンがついています。仕組みはシンプルです。Sphinxを使って文章をビルドしたら、ドキュメント中の単語をキーとして、それが含まれるドキュメント番号と段落位置の配列を持った巨大なJSONファイルを生成します。ユーザが検索すると、JSONをダウンロードして、単語から、ドキュメント番号と段落位置の配列を持ってきて、ドキュメント番号からドキュメント名とURLを生成して、リストにして表示します。Sphinxでは変換元のテキストを持っていて、これもロードして、単語周辺の文章として表示します。サーバいらずの検索エンジンです。この単語をキーとした辞書/ハッシュを転置インデックスと言います。検索エンジンのもっとも基本的なパーツです。

このシンプルな検索は東アジア系の言語ではあまり実用的になりません。欧米系の言語は単語間にスペースがあるので簡単な正規表現で単語に分けられますが日本語・中国語・韓国語はそうなってません。日本語の場合は漢字・ひらがながあるので、文字種の境界を取得すれば熟語ベースで分けるとかは可能かもしれませんが、欲しい単語にマッチしにくいだろうということは想像に難くないですよね。

東アジア系の文章を単語に区切る処理は、形態要素解析と呼ばれていて、Chasen、MeCab、kuromojiといったツールを使えばできます。サーバ用の検索エンジンはだいたいこれらのどれかが使えるようになっています。東アジア系の言語はやっかいな言語で、単語の辞書がないと単語に分けることもできません。ブラウザで日本語を快適に検索しようとすると、インデックスとは別に日本語の辞書(MeCabでよく使われるので10MB程度)をダウンロードしなければなりません。

それ以外の方法としては、n-gramという方式があります。スペースとか関係なしに、2文字、3文字ずつ区切って、それを単語と見立てて転置インデックスを作ります。これも実装がシンプルなため、オープンソースなシステムで簡単に日本語検索を可能にするために昔からよく使われている方法（僕が知っていてお世話になったことがあるものだとMojixさん作のZopeの日本語トークナイザーとか、Hyper Estraierとか）ですが、インデックスがもとの文章の倍以上に大きくなる欠点がありブラウザ用の仕組みとして使うには実用的ではありません。新聞記者みたいな揺れのないしっかりとした文章を書く自信があって、単語のリストとかを用意できれば、TinySegmenterMakerを使ってうまくやることもできそうです。これは今後トライしたいところ。

FM-index

JSXアドベントカレンダーとドキュメントアドベントカレンダーのネタです。

Ext.jsというJavaScriptのGUIフレームワークがあります。流行り廃りの早いウェブ関連の世界では比較的長い歴史を持ち、それゆえにIE 6.0から最新ブラウザまで対応しつつ、豊富なコンポーネントを備えたフレームワークとなっています。クラス数は数百あります。モバイル向けのSencha Touchもあります。Sencha Touchパーフェクトガイド という日本語の本もリリースされています。網羅的に書かれていて、バックエンドにDropboxを使う方法とか、モバイルの周辺をきちんと抑えてある本ですのでオススメです。

Ext.jsなどのプログラムには、GUIというとクラスがたくさん登場します。この型というものがライブラリにすでにたくさん定義されているのに、プログラミング時にそれを生かさないのはもったいないです。Ext.jsはドキュメント生成にJSDuckというツールを使っています。JSDuckには--export=fullと付けるとJSONでファイルを生成する機能があります。

$ jsduck --export=full --output st_jsonout ~/touch/src/

JSONには、クラスのメンバーとかいろいろ情報が含まれていますし、HTMLのドキュメントとかも含まれています。JSDuckで生成すると、独立した1ページのドキュメントが複数出力されるわけではありません。ajax的なページ片が生成されて、一部ずつロードされるようなファイルが生成されます。ブラウザの中にタブが出てきて、複数のクラスを同時に閲覧したり・・・というのはこういったバックエンドの仕組みに支えられています。

さて、クラスの情報が出力されたら、それを元に開発に使える形にします。ここで登場するのがJSXです。JSX用のラッパーができたら、コードを書いてコンパイルすればエラーチェックとかができちゃいます。それではJSONからJSXラッパーを生成するようなツールを用意しましょう。JavaScriptはフリーダムすぎる言語で、どのドキュメントツールもセマンティックスを付与できるようにたくさんのタグが提供されています。JSDuckも例外ではありません。また動的言語ということで、コールバックの返り値に対する説明が省略されがちだったりという問題もありますし、ドキュメントの型が一部間違っているということもありえます。コードコメントから生成ツールを作る場合には、元コードへのコミット権がないのであれば、ドキュメントに足りない説明を後から付与できるようにする必要があるでしょう。

それではツールを作ってみましょう。はい、できました。JSDuck2JSXというのがこのためのツールです(ここで頭のなかで３分クッキングのBGMを想像してください)。これで生成したテンプレートを使えば、GUIをJSXで生成できるようになります。ただし、Ext.jsのクラスの仕組みが複雑怪奇すぎるので、モデルとか気の利いた機能はまだ使えないです。ここはなんとかしたいところ・・・このコードを修正したら、HaxeとかTypeScript用のラッパーも作れるかもしれません(他の人がメンテするのは考えてないコードになってますが)。もちろん、手でラッパーを書くのも場合によっては悪くない選択肢になります。node-redis なんかはAPIは自動生成でシグニチャに関する情報がコード中に全然ないので、使い勝手の良いJSXラッパーを作るには手書きしかないでしょう。逆に、今回のSenchaの場合はクラス数が500を超えるので手で書くのは現実的ではないです。

ドキュメントを読むのは人間だけじゃないよ、というお話でした。

本エントリーは果てなき渇望 Advent Calendar 2013の最初のエントリーである。当初より週一連載なので落としたわけではない。興味がわいた人はどんどん追加してもらってもかまわない。

握力王とか握力神といえばその道の人に通じるという、その人新沼大樹氏から本書 の３章の存在をほのめかされたのはいつだっただろうか。Kindleにはなっていないので、日本に帰るタイミングにあわせて氏が出演しているDVD と一緒にAmazonで注文してピックアップしたが、読み始めた瞬間、この本の持つすさまじい熱量の多さに圧倒されてしまった。

本書で説明しているのは、マイナースポーツにカテゴライズされる、日本のボディービルディングである。マイナーとはいえ、専門雑誌が刊行されており、競技会も多くあり、ビジネスの規模や、多くの人に（畏怖を持って）知られているあたりは、僕がやっていたインラインスケートよりもメジャーとは言えるかもしれない。ただし、その知名度に反して「やったことがある」「観たことがある」という人はおそらく多くはなく、ある種遠くのリアルではないもの、昔話の怖い話とかそういうたぐいの認識をしている人が多いのではないかと思う。

僕自身、ボディービルは目指そうと志したことすらないが、ymotongpooが「歪んだ世界が見えた」と表現したように、本書に書いてある内容は自分が見てなかった視点からのすさまじいリアルであると感じた。それと同時に、対象は異なるものの、鏡を見ているかのような感覚を抱くことも数多くあった。

Oktavia 1.0

ようやくロジック部分の既存のユニットテストが全部パスしたので、来週ぐらいにはJSX版の1.0は動くようになりそうです。

• gruntfile.jsとnpmで開発環境が簡単に入るようになったので、Stemming各バージョンの提供はしない(コメント一個はずしてビルドしなおしてね方針)。
• oktavia-web-runtime.jsと、oktavia-web.jsの2つのJSを提供。oktavia-web-runtime.jsはビルド済みのOktaviaのコードと、ページネーションとかのちょっとしたウェブ用のサポートコードが入る。WebSocket内でも、そうじゃなくても動くコード。"searchIndex=(base64文字列)";という形式の文字列と結合して、「インデックス＋エンジン」という形式で配布、利用する。このファイルには依存jsなどはない。
• oktavia-web.jsは今のjQuery UI+アルファ。起動されたタイミングで、WebWorkerが使えるかどうかを確認し、WebWorkerが使えるのであれば、WebWorker経由でoktavia-web-runtime.jsをロードする。そうでなければ今までどおりにロードする。
• フォーマット文字列はoktavia-02。
• 今のところは@uupaaさん実装のbase64を入れてある。本体コードをなるべく小さく維持したいので、@__gfx__がnpm版をリリースしたら差し替える予定。
• base64が倍ぐらい早くなったのと、Array.joinを撲滅した、Rank Less Thanがコールされる回数を最大で半分にしたので、インデックスの作成とロードのパフォーマンスは大分良くなっているはず。

Oktavia.py

FM-Indexのアルゴリズム部分まではほとんどできているので、あとはOktavia部分の移植をすれば完成の予定です。

• Python 3.3のみ対応。
• 基本的には機能縮小版、というかウェブクライアントや、コマンドラインツールのないOktavia 1.0を目指す。
• ファイルフォーマットはJS版完全準拠。
• ライブラリで提供。もしかしたらhttpstatusぐらい移植してもいいかも。
• 自作のコードに埋め込んで使いたい人は、ライブラリコードを利用してインデックスを作成してもらうかたちにする。HTMLパーサとか、インデックスジェネレータツールは提供しない。
• oktavia-web-runtime.jsをバンドルする

忘れないようにメモ

• Rank Less Than事前計算で、インデックス作成時は使う文字だけ計算するようにした。検索では「次の文字のRank Less Than」の値も使うので、使う文字+1の文字コードも使う文字になければ一緒に計算
• 現在使っている最大の文字コードの数値も保持するようにした。計算をそこまでに限定すればロード処理が大分高速化されるはず。2^ビット数の文字を処理していたので、最大二倍。

これでPython版のユニットテストの処理時間が16秒から2000倍ぐらい早くなった。文字コード(16ビット分)データは増えたけど、トレードオフとしては十分すぎるリターン。現在のコードはこちら。あとJSX版にも反映する。

稲田さん情報によると

@shibukawa 今は30bitみたいです。

— INADA Naoki (@methane) October 24, 2013

とのことだけど、JSX版と実装が大きくずれちゃってメンテが大変になったらアレゲなので、ひと通り実装が終わるまでは32ビットずつビット演算するJSX版のままにしてある。そのせいか、BitVectorのRank計算がやたら遅い。手軽に高速化できないかなぁ、と思ってmemoizeのライブラリの@lru_cacheデコレータを何箇所かに使ってみたけど、統計情報を保持したり、いろいろ高性能なせいか逆に遅くなるケースが多くて結局使えず。

現在のOktavia.pyの実装方針:

• Sphinxも3系対応しているので、Python3.3のみ対応。サーバなどのフレームワークじゃなくてツールなので問題ないはず。
• 文字はすべてUTF-16だかUCS2で扱う。文字列は内部でUTF-16-LEにデコードして、2バイトの数値の配列にする。最終的な検索クライアントがJavaScriptなので、JavaScriptに合わせる。
• とりあえず全部リトルエンディアン。node.jsでは読み込めた。すべてのJS環境で互換性があるかは今のところ不明だけど、0.5のOktaviaでMobile SafariとかAndroid Browserでも動いていたし、モバイル含めてだいたい大丈夫だと思う。
• バイナリ化するときも、16ビット単位で扱うJavaScriptに準拠して、JavaScriptでパースできるバイト列にシリアライズする。

写真は某JSX関係者の一人が喜びそうな、骨董市で見かけた看板です。写真と本文は関係ありません。あと、タイトルは釣りですが、N個のことエントリーに入っているようなネタはほぼ網羅していて上位互換だと思うのでご容赦を。

最近はJSX関連のコードを書きまくっています。現状の成果報告ということで、取り組んでいることを書き連ねたいと思います。

JSXのnpm対応

node.jsは、requireで他のモジュールを読み込むときに、パッケージ名が"."(ピリオド)でも"/"(スラッシュ)でもない文字ではじまった場合は、自分のローカルフォルダから読み込み、見つからなかったら親フォルダのnode_modules、それでもなかったらその親のnode_modules・・・とルートフォルダまで順々に探しに行きます。node.jsのパッケージマネージャであるnpmは、そのようなnode.jsがうまく扱えるように、現在地+node_modules以下にパッケージを展開します。さらに依存パッケージがあれば、そのフォルダの中にnode_modulesフォルダを作ってその中に展開します。複数のパッケージが同じモジュールを利用する場合は、それらのモジュールの共通のルートのモジュール直下のnode_modulesに入るので、同じものがいくつもインストールされることはありません。このページのAlgorithmの項目に詳しく書かれています。ただし、あとから手で追加した場合とか、package.jsonのパッケージにgitリポジトリを書いた場合は複数ダウンロードされちゃうっぽいですが・・・後はフォルダ+index.js(node)か、フォルダの中にpackage.jsonがあれば、それのmainの項目があれば、それらのフォルダをrequireできます。Pythonの__init__.pyみたいな。

JSXの処理系も、node.jsと同じような参照の仕方をするようになれば、npmにJSXのライブラリを登録できるようになります。既存のJSライブラリへのラッパーライブラリの場合は、そいつと一緒にインストールできるようになります。これに関しては、JSXのコードを一部手直しして、Pull Requestを出しました。

• https://github.com/jsx/JSX/pull/275

node.jsと違って、コンパイルしちゃうと実行時には必要ない＆別パスの同じモジュールは別のものとして扱われてしまうので、なるべく１つだけがインストールされるように、あと実行で必要なものはルート直下にないとダメなので、マージされた後はこんな感じの運用をするのがいいんじゃないかなー、というガイドライン案がこれです。@kazuhoさんとTwitterで会話した内容などがベースになっています。

• JSXのライブラリはnpm install --saveでインストール。
• ラッパーライブラリの場合、実行時に必要なnpmパッケージはnpm install --save-devでインストール。と同時に、ルートのアプリケーションのpackage.jsonではnpm install --saveでインストール(孫を直接参照はできないため)
• なるべくモジュールを重複してインストールしないように、バージョン番号は>=で指定。

grunt-jsx

独り者の時ははディズニーの映画を見ることはほとんど無かったのですが、最近ちょくちょく見ています。英語も平易で分かりやすいですしね。昨日は、嫁がずっと欲しがっていたリトル・マーメイドの3Dリメイク版を見ました。お話の方はなんというか、まぁ古風な感じですね。ディズニーのプリンセスも時代によって必要とされるものが変わってくるらしくて、最後には王子様と一緒に仕事しているプリンセスと魔法のキスのティアナとかびっくりしたし、ハッピーエンドにもはや王子様を必要としない姫もいるし、 とか、かつて姫だったけどもまったくそんなのと無縁のキャラとかいろいろですね。比較して見てみると面白いです。今年の冬公開のFrozenはどんな感じなんですかね。

アニメにおける喫煙？シーンの取り扱い

喫煙というほどではないですが、パイプを楽器だと勘違いしたアリエルが、パイプを吹いて灰を散らばらせる、というシーンがあります。これを見て「あー、なるほど」と思いました。アニメ本編が始まる前に、喫煙は良くない！Secondhand Smokingはさらに危険！というのを紹介する30秒ぐらいの映像があったからです。過去のリトル・マーメイドは見てないので、もしかしたら以前のDVDにもあったのかもしれないですが、「話の都合上喫煙・タバコの登場はさけられないけど、現行のルールでは良くない」ということで追加されたのかな、と。厳密にはアリエルは「吸って」はなくて「吹いて」いるので、喫煙ではないのかもしれませんが・・・

これを見て思い出すのは、宮崎映画なのにタイトルに「の」が入っていないということで話題騒然だった「風立ちぬ」です。もっとも、まだアメリカではBD売ってないし、僕はまだ見てないのですが。それどころか、まどか☆マギカの映画のBDを買って実家に送ったけど、まだ受け取れてなくて、それなのにもうテレビ放送するとかなんとか、世の中は理不尽ですね。

風立ちぬでは、喫煙シーンがあるとかで、禁煙を推進する団体がクレームを付けて、そのようなクレームはありか、なしか、みたいに一瞬盛り上がりました。もう忘れている人が大多数でしょうけど。僕もクレームの話を初めて聞いた時は、揚げ足取りな印象を受けましたが、その後Twitterとかで回ってきた、「アニメとかの喫煙シーンが子供に与える影響は大きい」とする統計があるとか、いろんな情報を見ると、確かにそのクレームは妥当なんではないかな、と思いました。それと同時にクレームの仕方はもっと改善の余地がありそうな気がしました (ちなみに4日後に追加で出されたPRにはそのあたりの情報も追加された模様)。

一番大きなポイントは、クリエーターにとっての「子供」とも言うべき作品の改変を行わせたいかのように聞こえる点です。もしかしたら本当にそうだったのかもしれませんし、そこは聞いてみないと分からないのですが、ディズニーが今回のリトル・マーメイドで入れた注意喚起の映像は、こちらの問題にとってもひとつの歩み寄りのポイントとなるのかな、と思いました。

アメリカではディズニーがジブリの配給を行っているので、この2つの作品は無縁ではないです。風立ちぬがアメリカで公開されるときには、おそらく同じような注意書きが追加されるんじゃないかなと思います。もしかしたらワンピースのサンジみたいに全書き換えとなるのかもしれませんが・・・

そして3D

今回は3Dリメイク版ということでしたが、3D化のレベルはすごい高かったです。背景が後ろで、キャラが手前、みたいな単純な感じではなく、すべてがきれいに3D。海の中とか水面を大胆に動くカメラワークとマッチして、とても良い3Dでした。最近は3Dカメラを使わずに、撮影後にデジタル的に編集して3Dにする作品が多いそうです。重くて取り回しが難しい3Dカメラよりも映像に自由度が生まれるとか、遠近感を細かくコントロールできるというのがその理由だそうです。オズ・はじまりの戦いは、3Dの実写映像とCGの合成がなんかおかしいらしく、うちの3Dテレビでは遠近感がおかしかったですが、すべて手付けだとそういう問題はないです。技術的にもこなれてきたのか、大分良い映像でした。船が大きく動くシーンは3D CGっぽかったけど、新たに作りなおしたのかな？前からそう？

１歳の子供がいるとなかなか映画館に見に行くとかもできないので家でちょくちょく見るようになりましたが、3Dのテレビ＋Blu-Rayはとても良い買い物だったな、と思います。家で見る映像の2/3ぐらいは3Dで見ています。3Dというと不要なハイエンド機能としてよく言われるけど、そんなに価格差もないし満足度は高いです。PS3/360だと3Dでプレイできるゲームもそこそこありますしね。Pacific Rimも3D BD版買いました！届くのが楽しみです！

難点は、ちょっとソフトが高い点ですね。新作DVDが$20だった場合、BD+DVDが$30、3D BD+2D BD+DVDが$35というのがよくあるパターン。3D単体売りしてくれればいいのに、同じ内容の別フォーマットのディスクと抱き合わせでちょっと値段が高い・・・あと、HDMI 2.0の規格に3D対応が入っていないのが気になりますね。4K+3Dは当分先なんですかね・・・

かずひこさんのfacebookの投稿で知ったのですが、日本が先進国の中で女性の働きやすさワースト２になったそうです。まぁそうだよね、というのは色々なところから実感できます。@fumiさんのサムスンの話も読んで、考えさせられたのですが、日本は女性の労働力を生かしていないだけでなく、その影響で男性の労働力もぜんぜん活用できてなくて、どんどん弱体化していっているなぁ、というのを感じます。今まで漠然と考えてきたことをまとめてみました。

下積みを積んで管理職になるというキャリアパスについて

日本では、島耕作シリーズを読むまでもなく、平社員→課長→部長→・・・のようにステップアップして管理職になっていくのが当たり前のように言われています。でも、それって本当は不自然なんだろうな、と思います。プログラミングみたいな仕事を考えても、集中して勉強して知識を蓄えて・・・で、管理職になると仕事ががらっと変わります。プログラミングが得意な人でも、マネジメントが得意とは限りません。ただでさえ組織では無能な人で溢れかえるというのがピーターの法則ですが、あえて組織の武器になるものを放棄している状態です。戦士でレベル20にしたのにあえて商人に転職、みたいな。IT系とか大手でも「プログラミングで手を動かし続けるのは30代前半」「管理職を捨てて給料アップを放棄する以外に道はない」みたいな話をたまに聞きますし、僕が転職したのも生涯現役プログラマーでいたかったからです。

いつまでもエンジニアとしてスペシャリストの技能を磨きたいと思っていた時に、はっとさせられたことが2つありました。

ディレクターとマネージャー

僕が勝手に師匠と呼んでいるほりうち師匠が以前勉強会で発表されたという資料に、ディレクター(リーダー)とマネージャーという表現がありました。ディレクターはチームを「こっちを目指そう」と先導する人です。何にフォーカスすべきか、何をやらないかを決め、なにか余計なものがあれば「それはいらない」と捨てるのが仕事です。マネージャーは細かい仕事の取りこぼしがないか目を配るのが仕事です。タスクを減らす(余計なものを)、増やす(見落としていたのを追加する)という意味ではまったく正反対です。

日本では、これらの役割の違いを意識することはありません。今時な役職名をつけようとしているところでも適当にマネージャーと名乗っていてディレクションの仕事をしていたり、リーダーだけどマネジメントが仕事だったり、謎の和製英語のプロデューサーがあったり、謎です。

日本の女性に多いタイプ

もうひとつがめんたねで教えてもらった、岡田斗司夫さんの人生のトリセツです。人間にはいくつかのタイプがあり、得意なスキル、何が好きか、嫌いか、どういう価値が理解できないか、というのがあるというものです。「どういう価値が理解できないのか」というのには衝撃を受けました。頭では分かっても理解できないものがあるというのを意識したことがなかったからです。理解できないからこそ意識もしなかったのですが。岡田さんは自分で発想されたとのことでしたが、数千人だか数万人の人間のアンケートをとって作ったと言われている正確分析手法(名前忘れたけど)とほぼ同じ分類だったので、何かしらの参考にはされたのかな、と思っていますし、これに書かれている分析手法にはそれなりに信ぴょう性を感じています。

めんたねでは、オリジナルのSMマトリックスという性格分析手法を作っていて(それなりの人数の日本人をサンプリングしていて、日本人に特化した分類を作っています。日本人と欧米人では分散が大幅にことなっていて、日本人全体が１つのカテゴリーに入ってしまい、差が分析できないというのはよくきく話です。めんたねの分類では女性は「魅力ライン」という空気を読んだり、自分の願望を空気に含ませて伝えるようなことが得意な人が比較的多いとのこと。人生のトリセツで言うと王様タイプにまとまりますが、SMマトリックスでは、支配Mと服従Sの2パターンになります。もちろん、多いとはいっても100%ではないですし、男性でもこのタイプの人はいます。これについては後で触れます。

魅力ラインじゃないラインは、というと能力ラインです。比較可能な能力の差、チカラの差が人間の差であると考えるタイプです。僕もここです。現状のキャリアパスはどちらかというと能力ライン的な、能力の差や下積みの量(キャリア年数)を重視する傾向がありそうです。これは日本女性に多い魅力ラインの人たちにとっては不利ですし、さらに出産などでキャリアの中断がありえる女性からすると不公平とも言えます。

マネジメントが得意なのは女性？

taken by Bern Hart under CC BY-NC-SA

だいぶ前に「たのしい開発 スタートアップRuby」と「Pythonプロフェッショナルプログラミング」の献本をいただいておりました。ブログとか色々書くのが遅くなってすみません。4/1で、ちょうどスタートアップには良い時期だと思いますので、ブログエントリーを書きます。とは言え、細かい言語のことは書きません。あと、コミュニティ運営についても書きません。

これら本の良いところ

プログラムを書くということにはとても多くの活動が関わっています。具体的なモノの方が考えやすいと思うので、家を建てることに例えて考えてみると、どこに立てるか？家族構成は変化しそうか？どんな間取りにすればいいのか？予算はどうか？どこの会社に頼もうか？とかを考える必要があります。業務用の建造物なら、ビジネスとして成り立つか？採算は合いそうか？が大事です。

ソフトウェア開発も同じです。プログラムのソースコードを書くだけがソフトウェア開発ではありません。プログラミング言語を何にするか、データベースを何にするかなど、どれが最適かを選ぶ必要があります。より良い(性能とか修正のしやすさとかバグの少なさ)コードを書くのが大切ですし、そのためには勉強も必要です。仕事であれば、作る手間ができあがった成果よりも大きいとビジネスになりませんし、さまざまな人が関わってきてプロジェクトになっていくでしょう。趣味でも、時間が潤沢に使えるわけではないので、ある程度目標を定めて、フォーカスを集中する必要があるでしょう。

この２冊は双子のような本で「コードを書く」だけの部分だけではなく、貪欲にソフトウェアに関わる多くの項目を取り込んでいます。テストの仕方や継続的インテグレーションツールの導入などは共通しています。また、スタートアップRubyでは最後の章で、Pythonプロフェッショナルプログラミングでは最初のまえがきの企業の行動規範(著者はみな同じ会社なので)で「たのしさ」について語っています。

とは言え、一方は「スタートアップ」でもう一方は「プロフェッショナル」なので扱っている対象は微妙に違っていたりします。スタートアップRubyの方は、Rubyの基本文法から始まって、Railsを通じてコードの書き方を紹介しつつ、会社にどうやって働きかけて採用させていこうか？とか、勉強会を通じた勉強方法などを紹介しています。またRubyの文化やアジャイル開発についてもページをさいて説明しています。ゆるふわな雰囲気です。個人的にはRubyでは昔から咳プロダクツのファンなのでそっちの紹介もあればうれしかったですが、Rubyとは何かを学ぶ人には刺激が強すぎるかもしれませんね。

プロフェッショナルプログラミングの方は、.vimrcと.emacsの設定の仕方から始まり、Flask/Django/Google App Engineなどの開発を紹介しつつ、ドキュメンテーションや、分散バージョン管理、課題管理などを紹介しつつ、デプロイの自動化、パッケージ管理サーバを独自に立ててパッケージ管理みたいな、他の本で紹介されたのを見たことがないようなネタまで満載です。Python業界の専門用語ではこういうのを「毛深い」と言います。褒め言葉です。

もちろん、ページ数が無限につかえて、著者の時間が無限で、読者数と読者の財布と時間も無限であれば、全世界のソフトウェアのすべてのネタを100%網羅することはできるでしょうが、そういうわけにはいきません。どちらも、読者のステージにあったベストなものをピックアップして選んでくれています。どちらも学習していく上では良いマイルストーンとなってくれると思います。

このような本の著者になるために必要なこと

昨年からちょこちょこコードを書いていて、たまに思い立ったように機能を追加していた画像最適化ツールのlightpngに1.0のタグを打ちました。だいたいやりたい機能は入ったかな、ということで。時間的にはこんな感じで進化してきました。

• 2012/5/17: ファーストバージョン。pngを読み込んで16ビットに減色機能
• 2012/6/14: クロスコンパイルでWindowsバイナリ生成
• 2012/6/16: jpeg読み込み。
• 2012/6/18: PVRTC/ATITCの生成。
• 2012/7/30: libpng/zlibの圧縮オプションをブルートフォースで最適化
• 2012/11/5: プレビューモード追加
• 2012/11/28: Mac OS 10.8上でも10.6から動くバイナリが作れるようにビルドオプション変更
• 2012/1/28: png最適化スキップ機能を追加
• 2012/3/18: pngnqの256色化コード＋パレット最適化のインデックスカラー画像生成機能追加
• 2012/3/23: 16bitかつ256色コード生成機能を追加
• 2012/3/24: Zopfli圧縮オプションを追加
• 2012/3/25: 256色化をpngnqから生成後のサイズの小さいpngquantに変更
• 2012/3/28: ドキュメントを修正して1.0タグを打った

なぜこのコマンドを作ったのか？

ngCoreというゲームエンジンがありまして、16ビット画像を使って使用するテクスチャメモリ半減！みたいな機能があったり、ATC/PVRの圧縮テクスチャが使えたりします。16ビットはpngとかjpegファイルを読み込んで末尾のビットを削って1ピクセル4バイトの情報を2バイトに押し込めます。当然そのまま削るとグラデーションがガタガタになったりうれしくないので、ディザリングをかけて見た目がおかしくならないようにする必要があります。

ATCの圧縮テクスチャ生成も、Windows用のコマンドラインツールはあるんですが、Mac用が見当たらなかったというのもあります。PVRも、Macのtexturetoolと同じ形式(古いPVR v2形式)で画像を出力するコマンドラインツールがWindowsで見つからなかったり。Android/iOSの両対応のゲームを開発する＆WindowsでもMacでも！という場合は、それぞれ足りないツールを補完する必要がありますよね。まだ試してませんが(たぶん動く)、Linuxでも動けば、Jenkinsで継続的インテグレーションで画像ファイル変換とかもできるようになるはず。

圧縮テクスチャはメモリサイズが1/4になったり1/8になったりパフォーマンスも向上したりといいことが多いのですが、圧縮のしすぎで細部のディティールが悪化したりします。特に圧縮率の高いPVRTC。PVRTCがVQと呼ばれていたDreamcastで使われていたPowerVR2時代でも、キャラクタの顔に使うのをデザイナーさんが嫌がったり、ということがあったとか。エッジがはっきりしたUI画像とか文字とかもPVRTCは厳しいです(特にアルファ値を使うケース)。そういう時には16ビットのpngは有力な選択肢になります。

このあたりは最初の1〜2ヶ月で完了し、後はファイルサイズ縮小の追求ですね。pngはマニア向けなフォーマットで、圧縮オプションしだいでファイルサイズが微妙に変わったりします。最適化してもzlibの内部の辞書情報の最適化なので展開速度は全然変わらないはず(展開時のメモリ使用料は制御可能)。クオリティが微妙に変わっても良ければさらに大胆にファイルサイズを削れます。

10%でもファイルサイズが減れば、ブラウザゲームのレスポンスは上がるし、apkとかappファイルにそれだけ多くのコンテンツを入れられるようになります。何かをしながら過ぎている10分よりも、何もしない10分の方が苦痛が数倍だったりすることを考えれば、Google PlayとかAppStoreからのダウンロードは他のことをしながらバックグラウンドでできるけど、ゲーム起動後の追加ダウンロードで待たせるのは、ユーザさんからすれば何もできない待ち時間なので苦痛が数倍です。このツールを使って、少しでもインターネットを通じて世界をより良くしよう、ズッ友だよ！ということです。

フィードバックもpull-requestも評判も反応もまったくないけど、地味で誰もやりたがらないことを地道にやるのが大事ですよね。

現状の結果

2011年2月ごろのスクリーンショットです。

いつの間にかPythonの方がパッケージ数が多くなってました。荒い結果ですが、archive.orgを見ると、2012年12月23日のPyPIの記録が26444で、2012年12月22日のCPANの記録が26438なので、12月中に抜いたっぽいですね。過去のエントリーでは2014年ぐらいかな、と思っていましたが、1年ほど早かったです。

大雑把な経緯はこんな感じ。Perlはmodulesとdistributionsという2つの数字が書いてあって、distributionsの数が配布物の数っぽいのですが、過去のページにはmodulesしか書かれてないので、昔の状況は不明です。

抜かれたとはいっても、Perlも過去2年で7000ぐらい数を増やしてきているわけだし、まだまだアクティブです。僕もお世話になりましたが、アップロードされているソースコードを読んでアルゴリズムの勉強をさせてもらったり、価値の高さは健在です。歴史がある分、ハッカーな人も多くてレベルが高いイメージです。ちょっと前に「エンジニアならgithubのアカウントでソーシャルコーディングで」みたいなバズワードが流行ってましたが、20世紀からsourceforge.netのアカウント持っている人の方が断然オーラを感じるぜ、的な。

そして、PythonもPerlを抜いたとはいえ、その立場すでに脅かされています。node.jsのパッケージのnpmです。Google Trendsで見ると、2010年8月ぐらいにできたばかりかな、というところですが、すでに23300。ここ1ヶ月でも1500ぐらい数を伸ばしていますし、ペースはPythonの倍近いです。僕もいくつかnpmに載せようかな、と思っているものがあるので、何個か貢献はしますが、それとは関係なく今年中にPythonを超える勢いです。emscriptenで、Qtがブラウザ上で動いたらしいと会社で噂話をしていたのを小耳に挟んだりもしましたが、JavaScriptの勢いは凄まじいですね。CoffeeScriptみたいなJS系言語もnpmを使っていたりしているのも他の言語よりも有利かな、とも思いますが、想像以上でした。

一般的な Web Programmer ならば、HTTP Status code はすべて暗記していると聞きました。

しかし、僕は初心者なので、なかなか覚えきれていないので、HTTPのステータスコードをさがすのに便利なツールを用意しました。httpstatusです。インストールはJSX(npm install jsx)とgitが使える環境で:

    $ git clone https://github.com/shibukawa/oktavia
    $ cd oktavia
    $ make

です。使い方はコマンドの後ろに検索ワードを書けばいいのですが、Googleの検索と同じようなクエリーも少しだけサポートしています。本当はダブルクオーテーションでくくるとそのフレーズを完全に含む検索もいれたかったのですが、JSXにパラメータが渡ってくる時点でダブルクオーテーションが消えてしまうので判別が不能・・・

    $ ./httpstatus ok           #okを含む行
    200: OK
    $ ./httpstatus 40 -not   #40を含むけどnotを含まないステータス
    400: Bad Request
    401: Unauthorized
    402: Payment Required
    403: Forbidden
    407: Proxy Authentication Required
    408: Request Timeout
    409: Conflict
    $ ./httpstatus ok OR not # okかnotのどちらかを含むステータス
    200: OK
    406: Not Acceptable
    405: Method Not Allowed
    510: Not Extended
    404: Not Found
    501: Not Implemented
    304: Not Modified
    416: Request Range Not Satisfiable
    505: HTTP Version Not Supported

オプションなしで実行すると、すべてのステータスの一覧とともに、今日のあなたの運勢にピッタリなステータスコードを1つピックアップして表示してくれます。僕の今日の運勢は「Today's status: 503: Service Unavailable」でした。

JSXというエラーを見つけてくれて、JavaScriptよりもデバッグがラクな言語で書きました。JSも生成できます。ちょっとソースコードは長くなっちゃったので、割愛しますが(github参照)、言い訳をすると、もともとJSXでFM-indexを使った全文検索エンジンを作っていまして、これもそれを内部で利用しています。

FM-indexは日本に出張中に買ってみた高速文字列解析の世界という本で紹介されていた検索のアルゴリズムです。圧縮インデックスを使った全文検索です。転置インデックスを使う方式と違って、検索するだけならキーワードに分割しておく必要がありません。そもそもキーワード分割の難易度が高く、10MBだかの辞書を装備したMeCabさんに協力してもらわないと満足に分割もできない日本語だと、ブラウザ上でちょろっと精度よく分割というのは難しかったりします。それをしなくてもよい！しかも2-gram, 3-gramとかと違ってインデックスが圧縮されていて小さいですし、一文字でもマッチさせられます。また、圧縮されているインデックスから元の文章を復元できます。ドキュメントツールのSphinxだと、検索後のページサンプル表示に、元のソースのテキスト(.txtとしてアップされている)を利用します。これだと、翻訳機能と相性が悪い(元のソースは別言語)し、ソースをエクスポートする機能を有効にしないと検索機能が弱くなるという欠点があります。FM-indexならその部分も解消できる！まさに、Sphinxのブラウザ上で動く検索エンジンのためのアルゴリズムといえます。FM-indexに関してウェブで読める記事としては@echizen_tmさんのこの解説が分かりやすいですが、ちょっとまだ完全に理解できてない部分もあってまだまだコードを書きながら勉強中です。

現在は@echizen_tmさんのShellinfordをベースにいろいろ改造中です。Shellinfordの場合は、ドキュメントという区切りの情報を持てて、検索結果ではドキュメントのインデックスを返したり、インデックスを使って元のドキュメントのコンテンツを復元できるようになっていましたが、Oktaviaではこの部分をいろいろなケースに対応できるように自由に情報を付与できるように拡張しています。以下の4パターンを実装しています。Table以外は組み合わせて利用できます。今回はSplitterを利用して、行ごとに検索結果をマージして出すようにしています。

• Section: 名前付きのセクション。ドキュメント、タイトルの入ったセクションで利用することを想定
• Splitter: 名前なしのセクション。行番号、パラグラフ、分かち書きの単語区切りなどで利用することを想定
• Block: 名前つきのブロック。サンプルコードの箇所など、特定の範囲(スタートとエンドがある)を表すのを想定
• Table: CSVとかTSVみたいなデータで使うのを想定。row/column情報を返すことができる

現在はJSX実装のみですが、Sphinxに組み込んで使えたらいいな、ということでPython版も作りたいと思っています。

検索エンジンの作業の進捗としては、FM-indexのコア部分は動くようになっていて(@echizen_tmさんのFM-index紹介記事で書かれている線形探索な問題は今後修正が必要)、Snowballという由緒正しきステミングアルゴリズムに関連するツールのソースコードジェネレータを改造して、JSX版とPython版をそれぞれ生成できるようにしたのと、HTMLのパース用にJSのSAXParserをJSXに移植したり、node.js用のgetoptをJSXに移植したり、といった段階です。今はインデックス生成ツールをぼちぼち作成している段階です。クエリーのパーサ、スコア計算部分も追加して、最終的には、ブラウザで動く全文検索エンジンとして、Webサイトに簡単に組み込める部品っぽい形式でリリースしようと思っています。あとはインデックスを中間形式でSQLiteか何かにいれて、部分的なインデックスの更新をできるようにして、ExpressとかDjangoとかからサーバサイドの簡易全文検索ツールとしても使えるようにしてもいいな、とか。今回はhttpstatusというビッグウェーブに乗っかるために、急遽クエリーの簡易パーサだけ作って動くようにしたものです。最終形とはいろいろ異なると思います。まだまだアルファ版です。

嫁によくいろいろ使えるね、と言われたので、飲みながらGoogle Driveで作った図がこれ。子供写真を喜んでLikeしてくれる人は主にPathとFacebookにいるので、子供写真はなるべくiPhoneで撮って、Path経由でFacebookに。TOLOTも試しで２冊ほどつくってみたので(日本国内に発送したので実物は見てない)、よさそうなら、D3100→TOLOTという経路もできる予定。

英語の情報発信を足したいところ。blog.shibu.jpは日本語で大分記事を書いているので、違うURLが欲しいかな。どこかの渋谷さん、shibu.com解放してくれないかな・・・

なぜか子供の出産祝いということでまどか☆マギカのリミテッド・エディションの1が送られてきて(@ytakeuchさんありがとうございます！)、見たら勢いで2、3と全部買って、1年9ヶ月遅れでシブカワ家にもまどか☆マギカブームが来ました。日本と違って、1本に4話入り、BDとDVDが両方＋サントラも付いてきて$80。日本だと5〜6000円ぐらいで6本(1本に2話入り)なので、アメリカの方が安いかな。オーディオコメンタリーはついてないです。魔法少女同士が日常生活的に仲良くしている絵のポスター(本編では存在しない、嫁曰く妄想ポスター)とか、ポストカードとかおまけもいろいろ付いてました。

ちょっと前にウェブで見た記事「「魔法少女まどか☆マギカ」なぜ避けて来たのだろう」は非常によく理解できます。個人的には萌えはあるけど中身はないものには興味がないので、見た目でちょっと敬遠してました。でも、その後文化庁のメディア芸術祭で大賞をとったりしていたので、ちょっと興味を持ちました。

昔、「CMでボディーブレードが出てたよ！見に行こう！」と大学のサークルの後輩と一緒にしょーもない理由でクレヨンしんちゃんの映画を見に行って(当時部室でボディーブレードがちょっと流行っていた)、おもいがけずにいい話でびっくりしたら、その後その映画も文化庁の賞を受賞した、ということもありました。メディア芸術祭で戦闘妖精雪風のOVAを見て、その後はまって小説を買えるだけ買って読んだり、その賞が選ぶものと、自分の感性と合いそうな感じがしたのがその理由です。ただ、その後は渡米準備とかもろもろがあって、日本にいる時にはまどか☆マギカを見るチャンスがありませんでした。

今年は映画とかを映画館で見たり、BDやDVDを買ったりといろいろしているけど、これが一番良かったです。シリアスなファンタジー。これと比べるとダークナイトもダークじゃないですね。 嫁と一緒に2周見て、今3周目ですが、想像以上に良かったです。主人公が5人組というガンダムWを思い出すけど、こちらは4クールで、5人の全組み合わせ(10組)でペアの場面があって、見せ場をがんばっていっぱい作っている感があったけど、まどか☆マギカはストーリーに一切贅肉がない。とらドラ！もパズルのようだ、と思ったけど(当時はとらドラ！は数学と呼ばれていた)こちらは１クール作品ということもあって、さらにシンプルで化学式みたいでした。 すでに色々情報が出きっているので今更ネタバレがどうのというのは心配することもないかもしれないけど、まぁ詳細についてはぜひご覧ください、ということにしておきます。

アメリカ版のBD/DVDには、英語音声と、日本語音声＋英語字幕の2パターン選べます。英語音声＋英語字幕という組み合わせはできません。英語版の声優さんも、日本語版の声優と雰囲気がすごい近くてびっくり。セガのソニック並のクオリティ。

英訳のマンガもすごかった

アメリカ赴任で何が一番楽しみだったかって、ソニックグッズが日本よりもいっぱい売っていることですよ。ソニックが日本発のキャラクターなのに、日本人にすら「アメリカのキャラでしょ？」と言われたりもすることもあるぐらいなので(それだけ日本離れしたクールなキャラという立ち位置がきちんと成立しているということなんだと思います)、日本ではあまり手に入らなかったり・・・数日前に、ジョイポリスで海外のグッズも売られるようになったと中の人がつぶやいていましたが、それだけアメリカの方が充実しています。

まずは、フィギュアとかもろもろ。2011年のソニックジェネレーションズでは、新旧のソニックが共演というコンセプトだったので、目が緑の新ソニックも、目が黒の旧ソニックも、フィギュアがいろいろ販売されてました。本当はもう１つ、新旧ソニックが一緒に走っているフィギュアを会社に置いてきてます。あと、モノポリーとか、神経衰弱(レアキャラもいるよ！)なども。興味深いのはトイザらス限定(ToysRus exclusive)な商品がいくつもあったことですね。一番右はパーティー用の紙ナプキンです。ラジコンとか、コースつきのプルバック式の車のフィギュアなど、未購入なのもたくさんあります。

次はぬいぐるみとか。できのいいものも、わるいものも、いっぱい売ってます。こっちも新旧いろいろ。でかいシャドウのぬいぐるみのクオリティがとてつもなく高いです。奥のシャドウのクッションは誰かが誕生日のプレゼントで送って下さったのですが、どなたでしょう？下の目が入っている方のソニック帽子は@vestige_さんからのプレゼントです。メロン熊は帽子が潰れないように置いただけですので、ソニックキャラではありません。

Tシャツもたくさん売ってます。SEARS、TARGET、J.C.Pennyなどの量販店を覗くとだいたい何枚か置いてあります。ゲームキャラの中では、マリオ系、Angry Birdsと並んでトップ3に入る感じです。ベビー服は会社の方々からお祝いでいただきました。真ん中の手描き風のがお気に入り。

こちらもシャツ系。ウェアホッグとかマニアすぎるチョイス。１枚並べ忘れたけど、それにはブレイズが・・・嫁がエミー好きなのですが、エミーが描かれているTシャツはほとんど売ってないです。女の子向けのキャラクタはハローキティ一人勝ち状態なので、ぜひセガ・オブ・アメリカには頑張ってもらって、女の子用のアパレルコーナーにも切り込んでいっていただきたいです。あと、3月のCrush 40ライブのTシャツも(ライブには行ってないけど)ゲットできました！経路は秘密です！右上の15周年Tシャツは、元セガの方からいただきました。

そろそろ、暗黒の騎士のランスロットのフィギュアとかが出てくるらしい・・・日本では今まで出ていて、海外で逆に手に入りにくかったソニックの音楽CDも、iTunesで配信が始まったりして、アメリカのソニックファンはますますハッピーですね。このペースで増え続けると、ちょっと収納がやばいです。

• 2012年、最も多かった赤ちゃんの名前は？

この記事の中に、クレヨンしんちゃんのとうちゃんの言葉(表題のやつ)が書いてありました。名前は、人と人が接する時に使われる「道具」です。プログラマーなら誰しも、名前の重要さを知っています。うちも、今年娘を授かったのでいろいろ考えて決めました。うちの子の名前を決めたのは生まれる4ヶ月ぐらい前だったと思います。名前が決まっていると、お腹の中にいるときも親しみがわきますね。

うちの子の名前を決めるときに重要視したのが「外国の人(英語圏の人)にも通じやすい名前」です。今の時代、海外と接点を持つのはすごく簡単です。メールでもなんでも、国内とやりとりするのと変わらないコストで海外とやりとりできます。アメリカ生まれでアメリカ国籍も持っていることだし、将来海外相手に仕事するようなことも当然ありえることですしね。これは、僕のファミリーネームの「シブカワ」が外国人にとって発音しにくい事この上ないので、特にシブカワ家の場合は切実です。日本人名としても通じる名前。外国人にも親しんでもらいやすい名前にするためには、このあたりを意識すればいいのかな、と考えました。

• オノマトペ・言葉としての発音のしやすさ
• 綴りの互換性(ローマ字表記と英語表記が同じか？)
• 発音の互換性(ローマ字表記の読み方)
• 性別の互換性

オノマトペ・言葉としての発音のしやすさ

発音のしやすさの大切さついて教えてくれたのは@uupaaさんです。名前は声に出して読まれるものです。発音しやすさは親しみやすさにつながります。呼びやすい名前の方が声をかけやすいですよね？オノマトペの本などを参考にすると良いらしいです。僕はそれは読まなかったのですが、今習っている英語の先生に名前を見てもらって、発音しやすさを確認してもらいました。

知り合いから教えてもらったエピソードとしては、「カズオ」という名前の人が海外の人と結婚したのですが、相手の両親がどうしても「カズオ」と発音できず、「クズ男」になってしまうという・・・

綴りの互換性(ローマ字表記と英語表記が同じか？)

パスポート、クレジットカード、会社のメールアドレスなど、名前のローマ字表記はいろいろなところで使われます。例えば、ジョージという名前があったとします。日本でも譲治、みたいに普通に使われる名前出し、アメリカでも初代大統領の名前だったりします。当然、英語圏の人から親しみのある名前です。でも、日本語のローマ字表記はjojiで、英語名だとgeorgeですよね。リサも英語だとLisaで、ローマ字だとRisa。日本人を悩ますRとL問題がここにも・・・

発音の互換性(ローマ字表記の読み方)

サラ(Sara)はセーラとも読めます。同じ綴りでも、ちょっと違う読み方をされることがあります。

性別の互換性

例えばケイトという名前があったとします。日本人の場合は男の子の名前。アメリカ人は女の子の名前と考えます。性別が逆転しちゃってますね。まぁ、同じ名前が男性、女性の両方に使われるケースは英語の中にも結構ありますけど・・・周りを見ても、クリスとか、ジェシーとか。

これらを全部を満足させるのはなかなか難しいし、男の子の場合はさらに選択肢が狭いという問題はありますので、この中から重要だと思うものをいくつか選んで、それに合致する名前を決める必要があるでしょう。うちは発音は日米で一致しないけど、綴りと性別が日米で一致する名前にしました。 もちろん、ミドルネームを使う方法もあったり、ローマ字じゃない綴りを使う方法もありますが、手続き上いろいろ不便がありそうなので、子供が書類手続きで苦労しないように、ローマ字綴りがそのまま使えるようにしました。

日本人名としてもそのまま使う名前なので漢字もあります。漢字の読みはちょい変則的ではあるけど、他の読み方がしにくい表記だし、辞書に乗っている漢字の音・訓の読みから大きく外れてはないので、キラキラではないです。

両親も気に入っているし、娘も将来きっと気に入ってくれるはずと思っています。