2014年09月18日

PyConJP & 引っ越し

久しぶりにPyConJPに参加しました。きけば500人を超える人数とのこと。石本さんのブログによれば、10年前のPyConが400人ということで、それよりも大きな人数を集めたというのはすごいですよね。日本の10年前のイベントでは、仕事で使っている人はごく少数で、多くの人はPythonに興味があって、いつか仕事で使いたいなぁと夢見る若者たち(ほぼ男性)だったのが、今回は実際に使っている人たちが大勢集まっていました。大きなカンファレンスなんだけども、当初のグループのメンバーというだけでオリジナルの趣旨とは全然違う話題も取り込むことで延命しているイベントもあり、なおかつ知名度と情報量と書籍の量で国内ではRubyが圧倒的な中、Python 100%でここまで大きなイベントができるというのは10年前は想像できませんでした。タカノリさん、寺田さんをはじめ、多くの方々の頑張りに拍手です。

Oktavia

僕が発表したのは自分で作った検索エンジンですが、ブラウザ上で動かしたいという偏った同期からスタートしているのであまり一般的な題材ではなかったと思います。なんとか前日にPython版をPyPIにリリースして、発表資料も一晩で作り上げて、原稿も作らず練習もせずに英語でぶっつけ本番ながら、時間を枠内に収めることができました。欧米圏の人に、アジアの言語だと検索のアルゴリズムそのままだとツライんだよ、というのを説明するのが第一の目的でしたので、一応自分としてはそこはクリアしたつもり。

数年前のPyConJPと比較して、客層が大きく変わった気はしましたが、ウェブ系の人の人数はそのままに、データ解析系の人がプラスで追加された感じでした。セッションも、データ系とか機械学習の数が多くて人気そうでした。一方で、Pythonのコアとか処理系に対する話とかはそれほど数が多くなく、毛深い(Python用語)発表の割合は減ったかなぁという気がしました。

僕自身、最近は仕事でもPythonを書くことがなくて、たまにちょこちょこ趣味コードを書くぐらい。PyConJPの客層のメインストリームからは外れた気がしました。とはいえ、触り始めが古いだけの人が幅を利かせているのは健全ではないし、外れること自体は正しいことなので、この勢いで、現在Pythonと触れる機会の多い人がどんどん進出して、めだって、活躍して欲しいと思います。Python界の新アイドルも出てきましたし、Pythonの未来は明るいです。ラーメンの大盛りを注文しては後悔するような年齢になってしまったおじさんは、今後はポスターセッションか何かで、実用とはほど遠いかもしれないマニアックなネタで細々と生きていこうと思います。あと、The History of Pythonもきちんと訳さないとなぁ。来年のPyConJPまでに。

10月はSphinxConもやりますよ。Sphinxオンリーイベントが開かれるのは日本だけ!

引っ越し

日本に帰ってきて、不動産屋に行ったり下見をしたりして家を決めたまではすぐだったのですが、2ヶ月ぐらいたってようやく入居しました。まだ開けてないダンボールもいくつかありますし、ちょこちょこメンテのために業者に来てもらったり、表札の完成待ちだったり、タスクはいろいろありますが、だいぶ快適です。スペックは、丘の上の中古の庭付き一軒家です。4人家族の広さだと、家賃補助をプラスしても渋谷周辺は高くなってしまうし、買ってしまったほうが月々の支払いがだいぶ少なそうなので買いました。駒込時代よりも2.5倍の広さで月々の支払いはほぼ同じで通勤時間はそれほど変わらずです。ウィッシュリストはこちらです。そのうち、親しい仲間を呼んで、ハウスウォーミングしたいですね。

posted by @shibukawa at 01:40 | TrackBack(0) | 日記 はてなブックマーク - PyConJP & 引っ越し

2014年07月30日

「納品をなくせばうまくいく」を読みました!

著者の倉貫さんから、「納品」をなくせばうまくいくの献本をいただきました。ありがとうございます。

日本人の日本人による日本人の顧客のための本

今まで出ていたソフトウェア開発方法論の関連の書籍の多くは、英語から翻訳された本でした。また、基本的にメインの想定読者はソフトウェア開発側のメンバーです。当然、ソフトウェア開発者の言葉を使って書かれています。翻訳者もみなプログラマ側のメンバーでした。もちろん、読んではいけないということはないし、読んでもらった方がメリットがある本も数多くありますが、必要な部分とそうじゃない部分をうまく切り分けつつ、欧米の文化と日本の文化の違いを考慮に入れつつ、自分の立場に合わせて情報をカスタマイズしつつ読むのは簡単ではないでしょう。

本書は、徹底的に「日本のお客様」視点に立って書かれている本です。「ソフトウェアがビジネスに必要なのは分かるんだけど、ソフトウェアの開発とかわからんし、エンジニア雇うのも簡単じゃないし、ぼったくられたらいやだ」という日本の顧客むけです。実際のお客様の言葉なども盛り込んであって、お客さんの不安を解消し、成功しそう(失敗しなさそう)という気持ちになってもらう、という姿勢が徹底されているなと思いました。

アジャイル本として

続きを読む
posted by @shibukawa at 01:46 | TrackBack(0) | 日記 はてなブックマーク - 「納品をなくせばうまくいく」を読みました!

2014年06月25日

未来のないJavaScriptと非同期とErlang

JavaScriptはもう好き嫌いを超えて、最低限の読み書きはもはや教養レベルといっても言い過ぎではないと思います。ブラウザ限定だったら他の言語もありますが、ブラウザで標準で使える言語はJavaScript以外には選択肢はありません。3DCG系のツールのマクロ言語は未だにPythonがトップシェアだと思いますが、Flash, Photoshop, Illustratorの仕事を効率化するマクロ言語はJavaScriptですよね。先日AppleのOS Xの次期バージョンの自動化ツールが独自言語に加えてJavaScriptをサポートすることを発表しました。サーバサイドで使われるnode.jsは、コンパイル言語を除けばトップクラスの性能です。QtもQMLとしてJavaScriptを中心とした開発を推し進めてますし、Qt4時代からQtアプリのマクロ言語として提供されているQtScriptEngineはJavaScirptです。node WebKitというGUI環境もあります。Cocos 2d-xのJSバインディングとかも情報が沢山出回ってますよね。.netも初期バージョンからJavaScriptのコンパイラがついてました。Unityで使えるという型付きJSはこれなのかな?ブラウザからデスクトップ、サーバ、スマートフォン、ゲームにいたるまで勢力を広げています。ハードウェアまで広がろうとしています。

で、JavaScriptというと話題によく出てくるのが非同期のプログラミングです。ブラウザやnode.jsでは、コールバックの嵐になるとよく言われたものです。それに対するソリューションはいくつかあり、僕が使ったことがあるのはasync.jsと、次期JavaScriptに入ることが確定しているPromiseです。

Futureはどこへ?

続きを読む
posted by @shibukawa at 16:48 | TrackBack(0) | 日記 はてなブックマーク - 未来のないJavaScriptと非同期とErlang

「納品をなくせばうまくいく」を読んでません

「納品」をなくせばうまくいくという本が流行っているみたいです。僕はまだ読んでいませんが、タイトルを一目見れば、倉貫さんファンからすると内容を想像するのは難しくないでしょう。きっと今まで倉貫さんが語ってこられてきたことの集大成であろうと想像しています。

こちらのブログにはこのモデルを採用することでいろいろ問題が解決するよね!ということが書かれていますが、こちらに書いてない話で、「なぜダメと分かっている方法論がまかり通っているのか」をまとめてみたいと思います。もしかしたら倉貫さんの本にすでに書かれているかもしれませんが。

ムダのない予算管理がムダを生む

続きを読む
posted by @shibukawa at 06:42 | TrackBack(0) | 日記 はてなブックマーク - 「納品をなくせばうまくいく」を読んでません

2014年05月22日

コードを書くときに心がけていること

なんか流行っているので乗ってみます。

趣味コード

趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に関しては気にしません。

とは言うものの、先月末に二人目の子供が生まれてからは趣味のコードの時間はまったく取れてません。まあしばらくは潜伏期間かな。子供が二人いれば、少し大きくなったら子供同士で遊んだりしてくれるようになるらしいので!家で勉強する父親の背中を子どもたちには見せる予定です。勉強しない大人から「勉強しろ」って言われても説得力がないし、反発されるだけですしね。Wishリストはこちらです。

仕事のコード

いろいろ書いているけど、「いきなりチームに投入されても、既存のチームメンバーの邪魔をせずに、きちんと成果を出す」というのがコアですね。

ドキュメントなんて存在しない

続きを読む
posted by @shibukawa at 17:19 | TrackBack(0) | 日記 はてなブックマーク - コードを書くときに心がけていること

2014年05月17日

Spotifyの実験

曲のリストのところのメニューで、Copy Embed Codeというのがあったので貼ってみた。普段良く聴いている、Sonic Colors、Sonic Generationsにも参加しているCash CashというグループのCash CashというアルバムのCash Cashという名前の曲です。

訂正: 違った、アルバム名はTake it to the floorでした。Cash Cashというアルバムも別にあるけどそっちには入ってないっぽい。

posted by @shibukawa at 11:03 | TrackBack(0) | 日記 はてなブックマーク - Spotifyの実験

2014年05月14日

プログラマは酵母菌じゃないんだよ

オープンソースという言葉が一般化して、多くの人が使うようになってきたというのは感慨深いものです。ただ、同床異夢というというか、オープンソースというものに対していろいろな誤解とか先入観があるように感じます。僕もまだ業務としてプロダクトを作ってオープンソース化したことはないので(パッチとかpull requestはよく送っている)、至らぬところもあるかもしれませんが、そのようなものがあればTwitter等で補足してもらえればと思います。

手間を減らすために、公開すればいいじゃんという誤解

今あるコードをgithubにgit commit, git pushすればすべてがバラ色、というのがよく言われることです。公開するのはコストゼロというのは本当なんでしょうか?少なくとも僕が知る限りではそうではありません。ざっと考えてこのぐらいの項目のコストがかかるかなぁ、と考えています。

  • 社内の特許などの技術に関わるコードがないか、調査したり書き換えるコスト
  • 外部ベンダー製のコードがあれば、書き換えるもしくは契約を結びなおすなどのコスト
  • 社内のビルド環境に特化した部分などを書き換えるためのコスト
  • ドキュメント整備のためのコスト
  • ソフトウェアの資産=人件費の減価償却が終わってなければその精算

Windows規模ともなると、コードの調査だけで億の単位でお金がかかるんじゃないかな、と思います。マイクロソフトの場合は、互換性のためにバイナリバージョンを厳しく保持しているので、ビルドシステムも特殊かと思いますし、コンシューマOS、サーバとの共通コンポーネントなどもあって、必要なものを切り出してビルドできるようにするのも一苦労だと思います。公開したら即make worldコマンド一発でヒャッハーというわけにはいかないと思います。

企業内でもう使うことがないプロダクトか、そうじゃないかにもよって多少は変わってきます。企業で今後も使っていく場合には、開発の主体・意思決定を内部に持ったまま、外にだすことになります。当然、外部のユーザから来た要望に対して、企業の方針とすりあわせて方針を決定したり、変更が許容できない場合は今ある機能でどうやってそれを実現していくのかを説明するコストが必要となります。カスタマーサポート的なコストですね。エンジニアを数人張り付きで提供するならそれだけで数千万の費用になったりしますよね。それ以外にも法務のチェックとか、いろいろな部署に協力をお願いすることになるんじゃないでしょうか。

これらのコストをマイクロソフトが負担した上で公開しろ、というのは交渉としては成り立つ要素はゼロですよね。Blenderみたいにコミュニティで必要なお金を寄付で集めて、企業から買い取るという形で実現した例もあるので、お金を用意できればプロダクトによっては可能性はゼロではありません。Windows XPの場合にそれができるかというと、有料で延長サポートというのを行っているし、組み込み向けのWindows XPはまだ使われているので、マイクロソフトとしては「まだ生きている」という扱いなので門前払いじゃないですかね。

あと、すでにマイクロソフトはカーネルのコード等は契約を結んだところには公開しているみたいです。シェアードソースイニシアチブとかでぐぐると出てきます。ただ、問題はカーネルだけではないでしょうし、ネットワーク系のところとか、ブラウザとか多岐に渡りますし、そのすべてのコンポーネントのコードを公開しているかどうかは不明です。

コミュニティのためのコスト

続きを読む
posted by @shibukawa at 05:01 | TrackBack(0) | 日記 はてなブックマーク - プログラマは酵母菌じゃないんだよ

2014年03月30日

JavaScriptのメモリリークを10倍速で発見する

Leak

メモリリーク。一言でプログラマを死に追いやる恐怖の言葉。C/C++の世界ではmallocしたのにfreeしないとかのケアレスミスでよく起きていた問題です。その後、ガベージコレクタが掃除してくれるプログラミング言語が増え、一部の言語で循環参照に気をつけるぐらいであまり気にしなくても良い的な風潮になっています。

というものの、そうとも言ってられなくない状況も増えてきています。クラウドのスケールアウトブームも一段落というかコモディティ化し、go言語で再び性能向上方面に関心が寄せられたり、日本でErlangの勉強会が満席になったり、スケールアウトから再びスケールアップ方面に話題が移りつつあるのを感じます。長時間稼働のサーバで、スケールアップしてさらに数多くのリクエストを大量に受けるようになると、少しのリークでも大問題になります。

僕は現在はnode.jsを頻繁に使っています。node.jsはV8のおかげで、コンパイル言語から比べると遅いかもしれないけど、他のスクリプト言語の中では高速な部類に入りますし、今後もさまざまな場所で使われていくと思います。このエントリーではnode.jsのメモリリークの発見の方法について紹介します。

node.jsの基本的なメモリリークの発見方法

メモリリークの発見を難しくしてしている要因は、クロージャと無名関数です。

ガベージコレクタを搭載した言語のメモリリークは、「変数を持ち続けているために、リンクが残り続けてしまう」のが原因です。Chromeの開発者ツールを使うと、その時のオブジェクトのスナップショットを取得できてクラス情報も得られます。クラス名が得られますし、定義したクラスを使っている箇所は何箇所かに絞れることが多いので、比較的原因箇所を見つけるのは難しくないと思います。

やっかいなのは、クロージャです。クロージャは、構文的なつながりはなくとも、内部から参照していればその外の変数をキャプチャします。クロージャが残っていれば、そのキャプチャされている変数も残り続けます。たとえその変数がローカル変数であってもです。実際にそれが無名関数として定義されていれば(そのケースが多いはず)、難易度は上がります。具体的に見て行きましょう。

node-webkit-agentで増加したオブジェクト一覧を見る

続きを読む
posted by @shibukawa at 18:31 | TrackBack(0) | 日記 はてなブックマーク - JavaScriptのメモリリークを10倍速で発見する

2014年03月11日

詳細設計書は必要か?

よく使われている or 仕様が分かっているフレームワーク上で作業するならコード読めば理解できるので不要だと思います。実際、数週間前からチーム変わったけど、社内の共通フレームワーク上で平準化されているので、まったくドキュメント不要でした。すべての箇所に平等に書く必要性はないと思います。

とはいえ、去年、僕が当時詳しくなかったアルゴリズムのFM-indexで検索エンジンを作った時は、解説の本、論文、参考実装のC言語のコードがないと手が出なかったので、完全に無くせるかというとムリかなぁ、と思います。今も別の論文を読みつつ実装にチャレンジしてますが、コード1行に対して数倍の解説が欲しいぐらい難解でなかなか進まないです。

まぁ、詳細のドキュメントがいらないような簡単な仕事しかしてないと、どんどん自分のエンジニアとしての価値を切り売りしているような気がするので、「一行一行、コメントめちゃくちゃ書きたい!」ってついつい思うような難易度の高いことにどんどんチャレンジしていきたいですね。

posted by @shibukawa at 12:32 | TrackBack(0) | 日記 はてなブックマーク - 詳細設計書は必要か?

2014年03月01日

華氏で気温を言われてもしっくりこないんです・・・

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

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

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

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

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

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

posted by @shibukawa at 05:52 | TrackBack(0) | 日記 はてなブックマーク - 華氏で気温を言われてもしっくりこないんです・・・

2014年02月12日

Re: 東京の飯の話

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

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

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

東京はでかいので、人口比を計算すると、他の町の方が圧倒的だったりすることがよくあります。「とちぎ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った記憶が一度でもある人は、下記の言葉を胸に刻んで、町中でトイプーを見かけるたびに手を合わせて拝むようにすれば、不要な争いはなくなるんじゃないでしょうかね。

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

posted by @shibukawa at 04:19 | TrackBack(0) | 日記 はてなブックマーク - Re: 東京の飯の話

2014年01月01日

DeNAに入って3年になった

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のお世話になろうかなぁ、という次第です。

posted by @shibukawa at 14:17 | TrackBack(0) | 日記 はてなブックマーク - DeNAに入って3年になった

2013年12月19日

Qt + JSXあるいはJSの状況

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の使い方

続きを読む
posted by @shibukawa at 15:55 | TrackBack(0) | 日記 はてなブックマーク - Qt + JSXあるいはJSの状況

ブラウザ上で動く検索エンジン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) | 日記 はてなブックマーク - ディズニー流の喫煙シーンの取り扱い方
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2017年05月 >>
  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 さくらのブログ