2006-01-31

プロフェッショナル仕事の流儀(第４回)の感想

助教授NさんがほめていたのでNHKの「プロフェッショナル仕事の流儀」を見た。特集された人は、アートディレクター・佐藤可士和。なかなかおもしろい話だったが、そうじて感じたことはこの人はプロとしてまだまだ試行錯誤の段階なんだろうなっていうことだ、

アートディレクター・佐藤可士和（2006年1月31日放送） | NHK プロフェッショナル仕事の流儀:

http://www.nhk.or.jp/professional/backnumber/060131/index.html

上のWebページで述べられている方法論も試行錯誤、発展途上の感が強く、これだと２回に一度は失敗しそうな感じがする。CMだったら、まぁ、それでもいいんだろうけど、工業デザインでそれをやられたら結構困るんじゃないかな。その失敗が大プロジェクトにかぶったりもしてるんだろうなと思った。

[追記]考えてみたら、このギリギリ感が必要な場面でこそ、彼を使えばいいわけか。この辺はプロデューサーの腕のみせどころだな。

まぁ、ここで、彼が監督したXBox360関係のプロモーションを失敗の例として引き合いに出すのはまだまだ評価が確定してないところだけど、あの「ハイデフ」っていうキーワードは本当にだれが決めたんだろう？あのコンセプトだけは深刻な失敗だったはず。そもそもXBox360は日本では明らかにPS3を意識しすぎて、遊ぶゲームがない状態でのスタートなので、今の責任者が言っているとおり、日本での本当のローンチは2006年12月ってことで準備を進めているのだろうからここで書く必要はないかな。

しかし、この「最も困難な道を選ぶ」っていうのは、なかなかいい言葉だと思う。それとは逆に「最もシンプルな方法を選ぶ」っていう格言もエンジニアリングには存在する。

過去の成功を語ったプロジェクトXの後に、こんな感じの発展途上のプロを持ってくるっていうコンセプトはおもしろいと思う。でも、どうせならアート・ディレクターはミーハーだけど深澤直人でやってほしかったなー。見てて、そんなことを思いました。

Permalink | コメント(0) | 23:01

あぁ、このPVはかなりヤバイ

mixiで友人のRさんからおすすめされてみてみたのだが、このPVはまじでやばカワイイ。

YUKIの新曲メランコリニスタ

http://www.youtube.com/w/YUKI---Melancholinista?v=EM-GGkb4wOw

このPVを表現する手段としてバキを引用し、

「可愛い」と言う鉱脈はこのメランコリニスタをもって全て掘り尽くされた

と表現してみせたRさんの心意気たるや良し！

このニーソックスとスパッツをあわせたような衣装、エロ可愛いなー。Rさんに話題ふったけど、とりえあず、自分で名前をつけるなら、ニーパッツかなー。(Rさんの答えはこれこそが、メランコリニスタであるとのことでした、NARUHODO!!)ニーを出すということで、逆にニーソックスの持つ絶対領域というアドバンテージを下方向に移動させ、スパッツ属性という多くの健全な男子は好きなパーツを違和感なく表現させている。まさか、女の子のスパッツが嫌いな男はいまい。いても認めないし。

普通に履いたら明らかにあざといこのパーツを違和感なくPVに調和させている。

さすがYUKI！俺たちにはできないことを平然とやってのけるゥ！そこにしびれる！あこがれるゥ！

Permalink | コメント(0) | 02:43

GoogleのMapReduceの勉強会の様子

メモ

ふむ、並列プログラミングは少し扱ったことがあるけど、なかなかおもしろい。特にこの人の話は、自分なりに消化されてるから、わかりやすい。

近況

http://www.dodgson.org/omo/t/?date=20060127

内容としては、論文以上のことは言われなかったらしいけど、使っている人の感触って重要だよね。ちょっとずつ、コメント。

まず MR のマスタープロセスは途中経過や統計情報を HTML として(?)出力してくれる. そのスクリーションショットがスライドにあった. 進捗などがけっこうグラフィカルに表示される. こういうフィードバックの仕組みは開発生産性に影響しそうだ. (Tapestry の作者がいうところの "Feedback" 原則. )

この原則は重要。cgi開発でも、pythonのエラー補足をhtmlに出力してくれるcgitbモジュールが役に立った。リアルタイムに途中経過や統計情報をHTMLで確認できるっていうのはそういう意味で、汎用性が高く、とっつきやすい。（このテクニックは覚えておこう）

MR は CPU intensive な仕事より I/O intensive なプログラム向いている. つまり実際に Google の仕事は I/O intensive なのだろう. だから入力の分割の仕方が性能に大きく影響するという. 小さくすることで並列度をあげるだけでなく,GFS と相性の良い切り方というのがあるらしい. MR はチューニングのために細かくパラメタを指定することができる. これも I/O insentive な問題ならではという気がする. CPU insentive な問題はまずコードを見直すもんね. これは聞いたわけではないけれど, 高速化はパラメタの調整が主で, コアな問題以外はコードレベルのチューンをあまりしなそうな気がする. あまり効かなそう. 実際, MR は python binding もあるというから,規模でスケールすることや生産性の方が局所的な速度の改善よりも重要だという認識なのだろう. Map や Reduce はそれら単体で資産化されているようなので,python ではそれを組み合わせる感じで使うのかもしれない. 知らんけど.

なるほど、２万台超えるPC扱えたらそりゃI/O intensiveな仕事に向くか。Python bindingが実装されているっていうのは目の付け所がいいなー。PythonとC++とのバインディングはすげー楽だから、MapReduce->Pythonインターフェース->C++資産という流れはまっとうな気がする。

個々の MR プログラムは基本的に Map して Reduce したらおしまいになる. 複数の処理をストリーム風に処理したい場合は最初のプログラムの出力を次のプログラムに渡すことで行う. たとえばあるインデクサは 24 個の MR プログラムから構成されているという.UNIX のシェルやパイプを連想する. あるプログラム同士は直列に, 別のもの同士は並列に実行する, というケースもあるらしい. そうした連携を実現するための, UNIX の shell に相当する仕組みが必要にはならないのだろうか. と質問したら, まあ何かがあるというようなことだった. なんなのかは知らないけれど... 色々妄想したくなる一方で, ファイル名を引き渡すだけの素朴な仕組みで十分にも思える. コードを書く部分だけではなく, それをどんな感じで動かしているのかにも興味がわく.。

この部分の隠蔽の技法って、階層の違いはあるにせよある程度、Cellでも当てはまるだろうなー。

ジョブっていうのは、シェルレベルでパイプとファイル名で管理するのが一番直感的だし。それだけど管理は厳しいけど、Pythonのスレッドがそれの管理やってくれてC++で実装できたら、なんか普通に使える気がする。現場を知らないからなー。

こうやってWebに記録を残しておいてくれるのはいろいろ考えることができて、非常にありがたいです。

Permalink | コメント(0) | 00:29

maru 2006/02/01 02:13 よし！　YUKI　それでいいっ！　それがＢＥＳＴ！

gamella 2006/02/01 02:20 >maru
お、ひさしぶりー。ここにもYUKIにやられた人が一人いましたか。しかし、このサイトすげーな→ http://www.youtube.com ほとんどのPVがあったりするw

Ｔ 2006/02/02 00:22 うわぁ。。
とりあえず、gamellaさんは「スパッツ」と「ニーソックス」の単語の意味を間違っていると思います。少なくとも後者は「オーバーニー」ではないでしょうか。てか普通の人から見たら、あれはきっとガーター風タイツですって。

gamella 2006/02/02 01:01 ふむ、なるほど。この辺は一度整理しなきゃ。