2007/07/25

Y Combinator portfolio

WikipediaのY Combinatorのページが妙に充実していた。

Summer 07の会社名はまだ追加されてないが、Summer 07の Adpinionはなかなか良さそう。バナー広告をビジターが評価できて、それによりオーディエンス向けにターゲッティングしてゆくというアイディア。インタフェースとかうまく作りこんでると思う。

ところでDropboxはYCだと思ってたんだけど載ってないなあ。勘違いか、それともこのリストは全部じゃないのかな。

追記2007/07/27 12:52:11 PDT): Adpinionのアイディアは面白いとは思うけど、実際どのくらいうまく動くのか---広告を見てわざわざvoteまでする人が十分にいるのか---はやってみないとわからない。ということで実験に協力してみることにした。気づかれた方もいると思うが、practical-scheme.netのトップページ、 Paul Grahamの翻訳、それと Scheme Cross ReferenceのページにAdpinionを入れてみている。まだ広告主が少なくバリエーションに乏しい感じだなあ。

ちなみにまだレポート機能は作ってる最中だそうなんで、実際どのくらいの人がvoteしてるかとかはわからない。最初のうちは好奇心でクリックする人も多いだろうから、しばらく続けてみないとなんとも言えないだろう。

Tag: YCombinator

2007/07/20

#permalink

コードを書く人

最後にはガッツが勝つ

アーキテクチャを決めて下の人に実装を任せたりだとか他人に仕事を振ったりだとかたくさんのサブコンを使って一定の品質のアウトプットを出すべく管理したりだとか複数の会社の係る仕事でお互いの進捗を管理しつつ予想外の事やらトラブルやらを調整したりだとか会社の方針を決めるような上の会議に参加して問題を根本から解決したりだとか業界の趨勢を決めるようなサービスの立案やら実現やらに力を注いだりだとか。
そういった仕事に関わっている天才プログラマよりも、現場の最前線で延々とコードを書いているコーダーの方が最後にはプログラマとしての「物を作る能力」は高くなる、という信念のような物を、私は持っています。最後にはコードを書いている人が勝つ、と。

Googleでは偉い人ほど多くのコードを書いている、って中の人に聞いたことがある (さすがにSergeyとBrinレベルになっちゃうとそんな暇は無いそうだが)。

下にメモしたFlektorのJason RubinとAndy Gavinだとか、ZenterのWayne Crosbyだとか、まあその流れならViawebを作った当時のPaulとRobertとTrevorにしたって、やっぱり「天才プログラマ」という称号は誰よりもコードをたくさん書いてゼロから何十Mっていう価値を生み出しちゃう人々にこそふさわしいのじゃないかなあ。 (IPAに認定されたぐらいじゃだめだよね。)

世の中というのは色々な人がいてこそ動いているので、コードを書かないでも人をがんがん動かしてどんどんプロジェクトを回して行く人がいていい。でも、技術ベンチャーをやるなら、コアメンバーはやっぱり誰よりも良いコードをたくさん書く人であって欲しいかなあ。少なくともプロトタイプ作成くらいまでは。

ところで、アウトプットの管理とか現場の調整とか方針の決定とか、そういうのってプロデューサーの仕事だよね。コンテンツ製作現場では、プロデューサから制作管理へのラインと、ディレクターから製作部隊へのラインとの役割分担がわりと明確で、うまく機能してると思うんだけど、ソフト製作でもそういう分担があった方がいいんじゃないかなと思うことはある。

Tag: Programming

2007/07/18

#permalink

Flektor

Web上でメディア(video, audio, image)等の編集ができて、そのままMySpace等にパブリッシュできるFlektor。最近買収によるexitを果たしたそうな。トップページはずいぶん派手だけど(target audienceが MySpaceユーザ層あたりなのかな)、"Full Editor" などよく作りこんであるっぽい。

この会社、かつてNaughty DogをやっていたJason RubinとAndy Gavinによるものだ。そう、Lispでコンソールゲーム作ってたところである。 SCEに買われて、Lispやめちゃったと聞いていたけど、Founder達は抜けてこんなことやってたのね。バックエンドは何を使ってるのかなあ。

Startup Reviewの記事。あまりテクニカルな面には触れていないけど、「コンソールゲームで培った方法論＝ツールの整備にたっぷり時間をかける」が効を奏したとある。

Tags: Programming, Lisp, Startup

2007/07/16

#permalink

時をかける少女

アニメ版。DVDになってこちらでもレンタルできるようになったんでようやく観た。脚本も演出もやりたいことの筋が通ってて、丁寧に作られていて好感が持てたし楽しめた。それほど感情移入は出来なかったけど---20代で見てたら違ったかもしれん。まあそれだけ分別くさい大人になってしまったということだろう。今や、登場人物よりも作り手の情熱の方に共感してしまう。

背景が美しい。教室と、校門脇の守衛所、それから中庭の屋根付き通路は東京女子大かな? スペシャルサンクスに出てたし。学生の時の劇団が東女・東大中心だったのでよく東女のキャンパスで稽古をしてた。

で、やっぱり気になったのが、ネット上でも盛んに議論されている例の記憶に関するinconsistencyだなぁ。 (一応、以降完全ネタバレ)。

叙述トリックという説もあるんだけれど、そう解釈するには苦しいセリフが 2箇所ある(真琴の「だって、今、ここで…」と「ゼロになったはずなのに」)。脚本は十分に練られたらしいから、叙述トリックにするつもりならちゃんとそう出来ただろう。敢えてそうしなかったのだから、これらのセリフは (脚本上のミスではなく)制作者側が意図したものだと考える。

さらに、リーパー以外の記憶が通常は巻戻されることもセリフではっきり述べている (千昭「今のお前は知らないだろうけど、功介とあの子、一回…」)。 (「実は千昭も全部覚えていたよ説」「千昭が真琴を道連れに跳んだ説」はこのせりふと整合しない)。

この矛盾を解決するものとして「真琴勘違い説」とか「白昼夢説」とかがあるけれど、一見矛盾するせりふが意図的に仕込まれたのなら、そこには制作者の明確な意思があるはずで、これらの説はちょっと明確な意思としては弱い。制作者側に立つなら、メカニズムはどうあれ、あの記憶だけは(通常のタイムリープのルールを超越する) 特別なものであったとしたかった、と考えるべきだろう。

脚本は他の部分でも余分な説明をギリギリまで刈り込んでるから、ここでもメカニズムの説明が省略されたのは意図的だと思われる。 SFやミステリとしてはルール違反だろうけど、メカニズムの説明よりもその記憶の重大さこそが制作者の伝えたかったことなのだろう。

それでも納得できない人はターゲットオーディエンスではなかったということで。

Tag: 映画