2013年12月19日

ブラウザ上で動く検索エンジンOktavia

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

続きを読む
posted by @shibukawa at 00:00 | TrackBack(0) | 日記 はてなブックマーク - ブラウザ上で動く検索エンジンOktavia

2013年12月08日

JSDuckからコードの情報を生成する

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

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

当初、ドキュメントアドベントカレンダーに登録した時にこちら用に書いた記事でしたが、Doc-jaという似たアドベントカレンダーを見て、「あれ?登録したはずなのにないや、JSXの方に流用しちゃえ」とそっち向けに公開しました。その後間違えに気づいたので、元のアドベントカレンダーの方にも登録しました。関係者のみなさん、ごめんなさい。原稿は11月中に書いて12/8時限公開設定してたよ、落としたわけじゃないよ。
posted by @shibukawa at 00:00 | TrackBack(0) | 日記 はてなブックマーク - JSDuckからコードの情報を生成する

2013年12月06日

果てなき渇望

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

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

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

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

続きを読む
posted by @shibukawa at 13:27 | TrackBack(0) | 日記 はてなブックマーク - 果てなき渇望

2013年11月03日

Oktavia 1.0, Oktavia.pyファーストバージョンの予定

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をバンドルする
posted by @shibukawa at 03:46 | TrackBack(0) | 日記 はてなブックマーク - Oktavia 1.0, Oktavia.pyファーストバージョンの予定

2013年10月27日

Oktavia最適化ネタ

忘れないようにメモ

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

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

稲田さん情報によると

とのことだけど、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でパースできるバイト列にシリアライズする。
posted by @shibukawa at 10:38 | TrackBack(0) | 日記 はてなブックマーク - Oktavia最適化ネタ

2013年10月15日

JSXでWebAppの開発に必要なN個のこと

Untitled

写真は某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を出しました。

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

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

grunt-jsx

続きを読む
posted by @shibukawa at 18:12 | TrackBack(0) | 日記 はてなブックマーク - JSXでWebAppの開発に必要なN個のこと

2013年10月14日

ディズニー流の喫煙シーンの取り扱い方

Untitled

独り者の時ははディズニーの映画を見ることはほとんど無かったのですが、最近ちょくちょく見ています。英語も平易で分かりやすいですしね。昨日は、嫁がずっと欲しがっていたリトル・マーメイドの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っぽかったけど、新たに作りなおしたのかな?前からそう?

1歳の子供がいるとなかなか映画館に見に行くとかもできないので家でちょくちょく見るようになりましたが、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は当分先なんですかね・・・

posted by @shibukawa at 15:14 | TrackBack(0) | 日記 はてなブックマーク - ディズニー流の喫煙シーンの取り扱い方

2013年04月01日

女性の働き方とキャリアパスについて思うこと

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

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

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

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

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

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

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

日本の女性に多いタイプ

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

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

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

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

続きを読む
posted by @shibukawa at 16:23 | TrackBack(0) | 日記 はてなブックマーク - 女性の働き方とキャリアパスについて思うこと

コミュニティに参加する上で最低限持っておくと良いもの

DSP 147: Thank You! 2007-10-11
taken by Bern Hart under CC BY-NC-SA

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

これら本の良いところ

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

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

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

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

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

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

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

続きを読む
posted by @shibukawa at 13:45 | TrackBack(0) | 日記 はてなブックマーク - コミュニティに参加する上で最低限持っておくと良いもの

2013年03月30日

ゲーム用画像最適化ツール lightpng 1.0リリース

lenna_32i

昨年からちょこちょこコードを書いていて、たまに思い立ったように機能を追加していた画像最適化ツールの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も評判も反応もまったくないけど、地味で誰もやりたがらないことを地道にやるのが大事ですよね。

現状の結果

続きを読む
posted by @shibukawa at 01:51 | TrackBack(0) | 日記 はてなブックマーク - ゲーム用画像最適化ツール lightpng 1.0リリース

2013年02月22日

PythonのPyPIのパッケージ数がPerlのCPANを抜いた日

Screen shot 2011-02-20 at 7.52.00

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

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

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

日時PyPICPAN
2007年12月3200不明
2010年6月10000不明
2011年2月1330019300
2012年12月2640026400
2013年2月2820026800

抜かれたとはいっても、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を使っていたりしているのも他の言語よりも有利かな、とも思いますが、想像以上でした。

posted by @shibukawa at 16:39 | TrackBack(0) | 日記 はてなブックマーク - PythonのPyPIのパッケージ数がPerlのCPANを抜いた日

[JSX][FM-index]httpstatus コマンドで、HTTP のステータスコードをすばやくしらべる!

一般的な 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というビッグウェーブに乗っかるために、急遽クエリーの簡易パーサだけ作って動くようにしたものです。最終形とはいろいろ異なると思います。まだまだアルファ版です。

posted by @shibukawa at 01:54 | TrackBack(0) | 日記 はてなブックマーク - [JSX][FM-index]httpstatus コマンドで、HTTP のステータスコードをすばやくしらべる!

2013年01月02日

メディアの使い分け

Screen Shot 2013-01-01 at 9.11.46 AM

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

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

posted by @shibukawa at 02:19 | TrackBack(0) | 日記 はてなブックマーク - メディアの使い分け

2012年12月31日

魔法少女まどか☆マギカと英語

Untitled

なぜか子供の出産祝いということでまどか☆マギカのリミテッド・エディションの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組)でペアの場面があって、見せ場をがんばっていっぱい作っている感があったけど、まどか☆マギカはストーリーに一切贅肉がない。とらドラ!もパズルのようだ、と思ったけど(当時はとらドラ!は数学と呼ばれていた)こちらは1クール作品ということもあって、さらにシンプルで化学式みたいでした。 すでに色々情報が出きっているので今更ネタバレがどうのというのは心配することもないかもしれないけど、まぁ詳細についてはぜひご覧ください、ということにしておきます。

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

Untitled

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

続きを読む
posted by @shibukawa at 20:08 | TrackBack(0) | 日記 はてなブックマーク - 魔法少女まどか☆マギカと英語

2012年振り返り〜ソニックグッズ〜

DSC_0331

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

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

DSC_0333

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

DSC_0334

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

DSC_0336

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

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

posted by @shibukawa at 16:42 | TrackBack(0) | 日記 はてなブックマーク - 2012年振り返り〜ソニックグッズ〜

「名前っていうのは一生残るもんなんだ」

DSC_0173

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

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

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

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

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

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

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

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

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

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

性別の互換性

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

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

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

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

posted by @shibukawa at 04:52 | TrackBack(0) | 日記 はてなブックマーク - 「名前っていうのは一生残るもんなんだ」

2012年12月30日

何のために勉強会をするのか?

Brunel University student study group
By Brunel University under CC BY-NC-SA

Shin x blog 勉強会なんてやらなくても良いという記事がちょっと注目を集めていました。かれこれ10年ぐらい勉強会を開催したり、3年前と去年には勉強会とかコミュニティの本を出したり、僕もそれなりに頭を悩ませた経験がある方かと思うので、僕なりの現在の考えをまとめてみます。勉強会に悩む人の一助になれば、と思います。

参考文献

自分がすごいと思っているものの存在を広めたい

続きを読む
posted by @shibukawa at 08:16 | TrackBack(0) | 日記 はてなブックマーク - 何のために勉強会をするのか?

2012年12月25日

ベジタリアンも感謝祭・クリスマスできるアメリカ

DSC_0541

アメリカでは、感謝祭を筆頭として、お祝いの場では七面鳥とか、巨大なスパイラルハムとかが食卓に並びます。その一方、日本だとヒンズー教やイスラム教の人が来ると店探しに相当苦労しますが(同時に来て店を探したこともありますが)、ベジタリアンが一定数いて、どのレストランに行ってもたいていベジタリアンメニューがあったりして、肉がダメ/牛がダメ/豚がダメという宗教・習慣上食べられないものがある人でもなんとかなるのがアメリカです。ベジタリアン向けのターキーっぽいものも売ってたりします。Tofurkyという、会社の製品です。ここ以外にも、Trader Joe'sが自社ブランドでも出してたりします。

上記の写真は、オーブンで調理中の図ですが、足のない七面鳥な雰囲気です。醤油とオリーブオイルでタレを作って、それをかけて野菜と一緒にオーブンで1時間半ほど温めるだけ。中には七面鳥の足っぽいものが付いているものもあるらしいです。グレービーという名の別物のソースもついてきます。本来は肉汁で作るのですが、これはパンの塊が入っていたりして(温めると崩れてとろとろになる)、ベジタリア仕様です。

DSC_0543

できあがりはこんな感じ。中には最初から詰め物っぽいものもされてたりして、七面鳥風です。味もかなり肉っぽい。食感はかまぼこみたいです。そんなに悪くないです。うちは嫁が鶏肉が嫌いなのでこれを買ってみましたが、なかなかおもしろい経験です。

DSC_0547

嫁が授乳中なので、乾杯はシャンパン風の炭酸ぶどうジュース。白ワインでも使われるシャルドネ100%で作られているみたい。炭酸弱めなのでぽんっとは抜けないのですが、それっぽい雰囲気がばっちり味わえます。

DSC_0556

デザートはpecan nutsのパイと、Eggnog。オトナはEggnogにラム酒をちょっと混ぜて楽しみます。Eggnogも定番の飲み物らしく、昨日にTrader Joe'sに行った時はEggnogの棚が空になってました。pecan nutsのパイは脅威的な甘さですね。これに関しては日本のケーキの方がいいかも・・・食べ物の多様性はアメリカの方が便利なことが多いですね。宗教上の理由だけでなく、周りの人の子がアレルギー持ちが多いし、日本でももっと食べ物の選択肢(料理ではなく原料の)が増えるといいなぁ、といろんな宗教の人と仕事するようになったり、子供の親になって強く思います。

日本ではケンタッキーとかコンビニとかデパ地下とかスーパーが大々的に宣伝していますが、鶏肉は人数が少なくてターキーでは大きすぎる場合の代替品。アメリカでは値段もターキーの方が安いですね。100g10円ぐらいだったか・・・それがプライマリーのような感じで行動する日本人はアメリカの人から奇異な目で見られます。「年越しで手打ち蕎麦食べに行きたかったけど、お店いっぱいだったからカップ麺でごまかそうテヘ」ぐらいの感じなので、アメリカ人女性を口説く予定の男性、もしくはその逆の方は要注意です。

posted by @shibukawa at 15:32 | TrackBack(0) | 日記 はてなブックマーク - ベジタリアンも感謝祭・クリスマスできるアメリカ

2012年12月23日

Python温泉に行って本を書いた話

つまみぐい勉強法売れています!

写真は出た直後の写真です。もう2年半も経つのでさすがに平積みはもうしてないですし、他の本と比べてバカ売れで底が見えそう、なのも今はないと思います。はい。

PySpaアドベントカレンダーに混ぜてもらいました。アメリカはまだ23日ですが、(JSTの)24日のエントリーとして参加します。

Python温泉に初めて行ったのは第4回だかなんだかで、当時はもう芳泉閣になっていて、必ず雨に降られるという点も含めてすでに恒例行事な雰囲気でした。Python温泉に参加した後につまみぐい勉強法という本を書いたのですが、この本でもPython温泉で学んだことが含まれています。Python温泉は勉強会のカテゴリのイベントの一つとして見てもなかなか面白いものがあります。このあたりを軽く紹介しようと思います。

勉強会としてのPython温泉

続きを読む
posted by @shibukawa at 15:30 | TrackBack(0) | 日記 はてなブックマーク - Python温泉に行って本を書いた話

2012年12月15日

Qt+JS: Mac OS Xについての注意点

MacはOSのバージョン間での互換がいろいろクセがあるので、古いバージョンで使っていた方法がそのまま他の方法で使えるとは限りません。

バイナリ配布版+10.6, 10.7

10.6, 10.7はそれほど苦労はないと思います。バイナリ配布されているQtと、XCodeのコマンドラインツールのgcc(4.2, Apple版)を使っておけば問題はないはずです。

バイナリ配布版+10.8

clangを使わないとビルドできないです。QtCreaterを使っている場合は、ツールチェーンをClangにしてください。コマンドラインからQMakeでビルドする際は次のオプションが必要となります。ちなみに、Qt 5系はいろいろトライしていますが、QtScriptバインディングがビルドできません。内部のプライベートなクラスがいろいろ変わっていたりしますが、その部分は解消して、ヘッダをパースしてC++を出すコードの基本部分は対応できました。ただし、生成したコードはまだビルドできないです。コードジェネレータ部分(文字列操作周り)をいじる必要がありそうです。

# Qt 4系
qmake -spec unsupported/macx-clang
# Qt 5系
qmake -spec macx-clang

MacPorts版

MacPortsの中に入っているqmakeがOS設定を知っているっぽいので、とくに-specを追加する必要はありません。

QtScriptバインディングビルド時の環境変数

QtScriptのバインディングをビルドするときは、それぞれ環境変数を追加する必要があります。デフォルトのインストール先に入れた場合の各設定を紹介します。

# Qt5用(ただしまだ成功してない)
export QTDIR=~/Qt5.0.0-rc2/5.0.0-rc2/clang_64/
export PATH=$QTDIR/bin:$PATH
# Qt4系 4.7, 4.8確認済み
export QTDIR=~/QtSDK/Desktop/Qt/4.8.1/gcc/
export PATH=$QTDIR/bin:$PATH
# MacPorts版
export QTDIR=/opt/local/
export PATH=$QTDIR/bin:$PATH

OSバージョン判定シェルスクリプト

sw_versというコマンドラインのコマンドがバージョン番号を文字列で返してくれます。これを使うとバージョンごとに処理を分けることもできそうです。

if expr `sw_vers -productVersion` : "10.8.*" > /dev/null; then
    # 10.8の時のコード
else
    # それ以外のコード
fi

どの環境も、デフォルトではコンパイルしたバージョン以上のOSでしか動かないバイナリを作ると思います。Macではアプリを古いOS向けにビルドするには、リンク時に次のオプションが必要となります。

-mmacosx-version-min=10.6
posted by @shibukawa at 03:33 | TrackBack(0) | 日記 はてなブックマーク - Qt+JS: Mac OS Xについての注意点
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2018年08月 >>
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ