2014-06-15

AppleとGoogleに一番近い日本食を本気で探してみた

米国 Apple 本社に一番近い日本食レストランは「吉野家」なんだそうです。へえ知らなかった。たしかにクパチーノには吉野家があります。味もわりと日本と同じです。ぼくはあんまりいかないけどね……。

で、この記事の末尾にGoogleオフィスに一番近い日本食レストランはHappi Houseだと書いてありますが……違うよ! ぜんぜん違うよ。
Shalalaの生姜焼き定食。なかなかいいもんです
GoogleオフィスのあるあたりからHappi Houseのあるあたりに行く途中に、マウンテンビュー市のダウンタウンがあります。このあたりにはけっこういろいろ日本食レストランがあるんです。しかもHappi Houseみたいにいかにもヤバゲなくいもんじゃなくて(ていうか俺、 Happi House には入ったことすらないのでほんとにヤバイのかどうかすら知らんのですが)、もっとふつうのお店です。具体的に挙げると、しゃぶしゃぶ屋のShabuway、居酒屋のBushidoNami nami、すし屋のSushi Tomi、ラーメン屋のShalalaあたりは鉄板です。ちょっと離れるけどGochiのマウンテンビュー店も美味しい。ラーメン屋のMaru Ichiもまあ悪くはない。これ以外にも日本食のレストランはちらほらあります。あと最近はKobe Curryという日本風カレー屋さんもできました。このへんはみな、Happi Houseより近いです。

ではそういうダウンタウンエリアのが一番近いのか? この辺で直線距離的に一番近いのはBushidoか? などと考えてみるに、おそらくそれは間違い。
Google地図より。紫のピンがGoogleのメインキャンパス、右下のAがHon Sushiで左のBがHanabi Sushi
物理的に一番近いのはたぶんきっと、Sports Pageの脇にあるHon Sushiだと思います。ここなら歩いていける距離。もしくは、Googleのキャンパスは広いので、西の方にある建物からであれば、Rengstorff CenterにあるHanabi Sushiなる寿司屋が一番近いことでしょう。まあどっちもぼくは行ったことないので、日本人の言う寿司が出てくる店なのかどうかは定かではありませんが……。

……もっと細かいことを言うなら、会社に一番近いのは、アンドロイドチームのいる建物の1階にある会社カフェでしょう。そのカフェは日本料理(ということになっているもの)主体のカフェなので。ただ会社カフェがありなのだとすると、アップルの会社カフェは羨ましいことにちゃんとした日本料理が出てくるのでノーカンということになるのですが。

日本人Google社員の実感として、ふつうの日本料理の出るお店でいちばん近いのは、まあダウンタウンにあるあたりのお店じゃないでしょうか。ランチということならShalalaですかね。ラーメン屋だけど、ぼくはたまに生姜焼き定食とか食べるんです。普通なんだけど安心できる味。量がちょっと多いけどねw

---

ところで、ちょっと調べてみたらアップルのキャンパスから一番近い日本食レストラン、たぶん吉野家じゃないですね。直線距離では、先ほど出てきた居酒屋のGochiのクパチーノ店が近いです。Google Mapsによると車でわずか1マイル、3分です。Gochiは居酒屋なんですが、ランチもやってるみたいだし……ただ、土日はランチ営業していないから記事の趣旨からは外れるんですかね。
オレンジのピンがApple所在地として出てくる場所。AがGochi、Dが吉野家
もう一つの候補はCurry House。ハウス食品のやってるカレー屋さんでファミレスみたいな雰囲気のところです。直線距離では吉野家と大差なさそうだけど、車で行くと1.3マイルと吉野家より少しだけ近い(しかも土日も営業中)。あと、さすがに吉野家よりは遠いでしょうが、南の方にもう少し足を伸ばせばAjitoのような居酒屋もあります。

さらに移動距離でいくと、どうやら一番近いのはSushi Kuniというところのようです。直線距離ではGochiのほうが近いっぽい気がするけれど、同じDe Anzaの西側という好立地のため、Infinite Loopからの車による移動距離はわずか0.9マイルでした。ただしここも土曜は夜のみ、日曜は休日というGochiと同じ営業パターンのようなので、今回の趣旨からは外れるのかもしれませんが。

なお、吉野家から通りを渡った反対側ぐらいのところにちょっとしたアジア系のショッピングセンターがあり(ここには日本スーパーのMarukaiとかダイソーがあります)、このエリアには牛角があります。寿司屋もあるみたいですね。まあ吉野家よりはちょっとだけ遠いけどね。

そういうわけで、何が言いたかったかというと、吉野家しかないわけじゃないんだよねーという。Fさん、たまには牛角ぐらい行ったら良いのでは。いや、いいけどね、吉野家も。っていうか休日出勤って(ry

追記:なお本件調査は +Kazunori Sato さんによるGoogle+の投稿でのコメントの応酬をベースにしております。

2014-06-11

悪いほうが良い原則とJSON

なんとなく改変コピペである(日本語版はこちらによった。ちなみに面倒そうな箇所は適宜はぶいている)

あるとき、MIT 出身と Berkeley 出身の二人の有名人がWebサービスAPIの問題を話し合うために集まった。 MITの彼は SOAP (XMLのRPCフレームワーク) に精通しており、JSONベースのRESTfulサービスのためのドキュメントを読んでいた。彼はJSONがどのようにスキーマ問題を解決できるかに興味を持った。スキーマ問題はサービス事業者が新しいWebAPIを定義するときに起こる。もしAPIの返す値にuserといったフィールドがあるとすると、その意味するものはユーザを指示するID値であったり、なんらかの文字列であったり、簡単なプロフィール情報を含むオブジェクトであったりする。しかしAPIの返すそうしたフィールドは通常ただの1つの名前しかないため、クライアントはその内部構造を把握することができない。そこでサービスは構造の意味をあらかじめクライアントプログラムの作者に伝えなければならない。 「正しい」やり方はもちろん、機械処理可能な構造の意味を表現するための手法を定め、URIによって指定できるようにすることである。
MITの彼は読んでいたJSONやRESTのドキュメントの中にこの問題に対処するセクションを見つけられなかったので、New Jersey側の彼にどうやってこの問題に対処しているのか尋ねた。New Jerseyの彼は、JSONでRESTfulなサービスを作っている人はこの問題に気付いているが、 解決はきちんとしたAPIドキュメントをつねにメンテしておき、そのドキュメントを公開しておくことだと答えた。したがって、正しいユーザプログラマはドキュメントを読んでどのフィールドをチェックするか自分で決めるものだと彼は言った。
MITの彼はこの解決は気に入らなかったが、それはもちろんこの解決が 「正しい」やり方ではないからだった。
New Jerseyの彼は、このJSONの解決は正しい、なぜならJSONの設計哲学は単純さにあるのであって、「正しい」ことをするのは複雑過ぎるからだと言った。 それだけでなく、プログラマがドキュメントを見てフィールド名などのチェックコードを入れることは簡単なことだと。
MITの彼はそれに対して、実装は簡単だが使用法が複雑すぎることを指摘した。New Jerseyの彼は、ここではJSONの設計哲学に従って適切なトレードオフが行われていると答えた。すなわち、実装の簡単さの方が使用法の簡単さより重要なのだと。
MITの彼はそれを聞いて「屈強な男がやわらかい鶏料理を作ることも 時にはあるものなのに」と嘆息したが、New Jerseyの男には理解できないようだった[筆者もよくわからない]。

2014-06-09

Edge of Tomorrow。桜坂洋のラノベの映画化。別物だがこれはこれで


桜坂洋の『All You Need Is Kill』をベースにしたというハリウッド映画、Edge of Tomorrow (→日本の公式サイト)を見てきました。

話としては別物ですが、これはこれでなかなか良かったと思います。

基本的な設定やアイデアの核を流用しながらも、まったくイチからストーリーや設定を再構築した作品といった印象で、ほんとうの意味でも別物。細かい設定なども全然ちがいます。

その核となる部分というのは、「正体不明のエイリアンに襲われて人類は押されている状態」「ほとんど新兵状態の主人公がいきなり前線に送り込まれる」「エイリアンに由来するとある理由により主人公だけが、死ぬと前日に戻り時間がループする」「同じ日を繰り返すうちに主人公は次第に熟練していく」「人類側のエース級の兵にリタという女性がいて、彼女はループの謎を解く鍵をにぎっている」とまあこんなもん。あと登場人物の名前は(主人公以外は)わりと原作そのままかな。

それ以外の部分は全部違うといったほうが適切。とくに「どういう機序によって時間のループが発生するか」「ループから脱出する方法」などが大幅に違います。したがって結末も全く異なるものとなっています。

でもまあ見ていて、これでも良いのかなという気がしてきました。見る前に『All you Need Is Kill』を再読したんですが、なんというかこう、あんまし映画向きというわけでもない(部分も多々ある)よね。原作に忠実にしつつ適宜改変を加えるよりは、基本設定から再構成するという判断でもまあ良かったんじゃないかな、という気もします。原作の映像化も、それはそれで見たかったという気もするけれど……。

映画としては、ひとつにはミリタリーものという側面があって、いきなり戦場に放り込まれた主人公が右往左往していくなか、周囲でもどんどん人が死んでいく過酷なシーンの繰り返しというものがあります。繰り返していくなかで次第に熟練していく主人公がだんだん人を助けられるようになっていくといった展開も面白い。

もうひとつ、主人公だけが同じ時間を繰り返すために主人公はある種の予知能力的なものを持っていることにあり、それを流用していろんなことを試みるわけですが、このセリフ回しや展開でちょっと笑っちゃうところも多々。ループものの面白さはかなり生かされていると思います。

難点を挙げるとすると、エンディングはもうひとつ納得いかないのと、やっぱり冒頭、軍の広報みたいなことをやっている少佐がいきなり三等兵に降格されて出撃という展開がちょっと無理めな気がするんですよね。原作だとただの新兵なところが少佐って……まあトム・クルーズの顔で新兵というのはどうしても無理があるだろというのは確かなんですが(笑)。

タイトル Edge of Tomorrow というのは、ストーリーを完全に変えたものとしては良いと思います。All You Need Is Kill というタイトルは原作のあのラストの展開と結末を踏まえないとつかないタイトルなので。

---

ちなみに、なんでまた日本人のライトノベルがハリウッド映画化されているかという話なんですが、日本のSFを英語に翻訳してアメリカなどで売るという出版社がいくつかあり、そこで英訳されていたという下地がありました。桜坂洋の代表作は『よくわかる現代魔法』シリーズかと思われますが、本作が選ばれたのは長いシリーズでないということと、たぶん英語圏でも受けそうな内容だというあたりでしょうか。それがあたったのは確かですね。原作そのままの映画にはできないまでも映画にしたくなるような設定ではあった、ということでしょうか。

# いま見たらグラフィック・ノベルにもなってたのね。でもデザインがダサすぎ(笑)

2014-06-08

地上最後の刑事。おすすめ



ベン・ウィンタース『地上最後の刑事』

1年ほどまえに発見された小惑星マイアは、やがてその軌道が地球とまじわり、つまり衝突することが明らかになり、その結果、人類は滅亡するか、すくなくとも文明が崩壊するレベルの破滅が起こることが確実になった。

衝突の予定日は、約半年後。

自暴自棄になる人もいる。有り金をはたいて最後の贅沢をしたがる人もいる。人々は仕事をしなくなるのでインフラが崩壊しつつある。もちろん、自殺をする人もいる。

そんななか、アメリカのごく平凡かつ平穏な街のマクドナルドのトイレで、男の死体が発見される。ベルトで首を吊ったのだ。生真面目というきらいのある保険屋の男。だれもが、当節ならありふれた自殺だと思う。そもそも今日び犯罪捜査なんてだれもやる気がない。どうせ半年経てば同じなのだ。

それでも主人公は、わずかな引っ掛かりをもとに、これを殺人事件として捜査しはじめる。

---

いやーこれは面白いね。

破滅することがわかった社会をリアルに描く、となると、破滅もののSFになってしまうんだけど、この本はそこのリアリティや社会を描くということに拘泥せず、あくまでも警察小説の線を保っている。つまり、一部におかしい人はいるけれども、概ねの人はまあまあそれなりに生きようとしている。けれども、小惑星の存在は誰もの心の上に、いつも重くのしかかっていて、行動に影響を与えないはずがない。そういう社会に生きるそういう人々の機微を、警察小説・犯罪小説という面からうまく描いているように思う。

破滅ものをSFとしてしまうと、どうしても人類全体を描くような大きな物語になるか、人類全体の行く末と個人の運命が奇妙に結びつくセカイ系になっちゃう。そういうところに陥らずに面白いポジションをキープしているのがこの本の面白さだ。

警察も総じて士気が低く、そもそも人材が枯渇しており(放蕩生活をすると決めていなくなってしまった人も多いので)、しかもみんなどうせこの件は自殺だろうと決めてかかっているため主人公が孤軍奮闘するという展開になるのだけど、結果的にここがノワールぽい雰囲気になっているという解説の指摘はひざポン。でも主人公はぜんぜんタフじゃないんだよね。読んでいて俺のイメージは線の細い新米くんな感じ。なぜ刑事を続け、なぜ事件捜査をするのか、本人もうまく説明できていない。

物語としての構成はさらに複雑で、警察小説として犯罪の謎を解くという物語の筋と平行して、主人公の妹や妹の恋人、主人公の元恋人などがからんでくる謀略がじょじょに形を見せていく、といった体裁になっている。ただそちらのほうは本書だけでは完全には解決しない。本書は3部作だそうで、その辺のストーリーは続刊で絡んでくるのかな。

ただこの、いかにもSFっていうようなSFといった設定でありながら、その実わりと普通の警察小説でもあり、そうでありながらこのSF設定でないと成り立たない筋立てになっているという微妙なさじ加減がこの本の妙味だなあと思って読んだので、妹がらみのストーリーに主軸を移していくとあんがい平凡なSFになってつまんなくなる危険性は秘めているかも、という気もします。

とはいえ本書単品としてはとてもよい。おすすめ。

2014-06-02

盆栽プログラミング



Google+に限定公開で書いたらそこそこウケが良かったので一般公開してみる。

さいきん、趣味のプログラミングでテキストエディタを作っている。HTML/JS/CSSでPolymerを使って書くというのを特徴ということに定めて、ちまちま書いているところ。まだシンタックスハイライティングやモードなどが存在しないので未完成もいいところ。

で、エディタなんて簡単でしょ、と思うわけだし、実際のところものすごく難しいということはそんなに多くない。大枠は単純きわまりないものであって、キー入力から編集コマンドを実行してビューを適切に保つというだけのはなし。大枠の部分は、まあそれほど苦労しなくてもある程度動くところまではできる。

ところが、ものすごく細々したどうでもいい細部が、案外いろいろあるのだった。たとえば……などと書き始めるときりがないのだけれど、些細なことも実装しないと動かなかったりするわけで、まあめんどい。ここ数日は画面のスクロールやpageup/downあたりをいろいろ作っていた。そういうものが山ほどある感じ。

で、趣味でこんなことをやってると、これはなんかこう盆栽だなーと思うわけですよ。

こう、ちまちまと細かいところを直して、しばらくしたら遠くから眺めて「うんうんいいかんじ」ってなるところが盆栽っぽいかなと。……いや、盆栽やったことないのでイメージで言っているわけで、本当のところ全然そんなんじゃなくても驚かないんだけど……。

敷衍すると、ソフトウェア業界には盆栽仕事がけっこうある気がするのだった。いまの自分の本業もわりとそういう面はあるかなと思う。

ただ、わたしは盆栽仕事はけっこう好きだな。世の中的には、ズバンとでかいことをやるほうが華やかだし、好きな人も多そうだけど。そしてそれは否定しないながらも、そういう大きな仕事やハックに付随する形で、盆栽仕事が量産されていく。仕事では、polish(磨く)という単語をよく使うけど、これもまあ近い概念かなと思う。骨董品を隅々まで磨いているかんじ。

ただ、盆栽って単語を持ちだしたのは趣味性の高い活動だからなんだけど、こういうちまちま作業を趣味プログラミングでやるのが良いことなのかどうかはよくわかりませんな。

Photo: Picea abies bonsai / Weetrees contest entry by Chris Guise, CC-BY-NC-SA