今年も咲いた
オフィスからの帰り道
韓国宮廷料理のお店。かなりよい感じ。
Stop all the clocks, cut off the telephone. Prevent the dog from barking with a juicy bone, Silence the pianos and with muffled drum Bring out the coffin, let the mourners come.
Let aeroplanes circle moaning overhead Scribbling in the sky the message He is Dead, Put crepe bows round the white necks of the public doves, Let the traffic policemen wear black cotton gloves.
He was my North, my South, my East and West, My working week and my Sunday rest My noon, my midnight, my talk, my song; I thought that love would last forever, I was wrong.
The stars are not wanted now; put out every one, Pack up the moon and dismantle the sun. Pour away the ocean and sweep up the wood; For nothing now can ever come to any good.
切実さはリスクとコストを負って何かを創りだす欲望がある地点にしか発生しない
tumblrのテンプレート
関係ないけどこのtumblrのテンプレート、macのchromeでみるとヘッダの追随にバグがある。
safariだと大丈夫みたいだけど、この伸縮嫌いじゃないのでもう少し様子みるか・・・
JazzとWeb (2)
今朝思いつきでJazzとWebについて書き始めたらすっかり長くなってしまったので、
その続き。（前回の話はこちら→「JazzとWeb」）
Webのサービス開発をやっていると、オーケストラ的な手法とジャズ的な手法で議論になることがよくある。（一般的にこういった呼び方が流通しているわけじゃないです。いきなり新人が「ジャズ的な手法で・・・」みたいな使い方をすると確実に無視されるので気をつけましょう）
具体的には仕様書がないとどうとか、仕様が固まってないから作れないとか、行き当たりばったりで作るからいつも良いものが出来上がらないとか、設計段階の良し悪しですでに結末は見えている（お前はもう死んでいる的な）とか、一方でそんな型にはまって作っても面白いものなんてできないとか、お前よりむしろオレのほうがきれいに設計できるとか、お前のプッシュはリポジトリを汚すだけなんだよ（もはやただの喧嘩）とか、まあ大抵はそんな感じだ。
要するにちゃんと作るかノリで作るかという話なのだけど、実はその根底には前回の最後にも書いた「今自分たちが直面している課題に対して、すでに正しい答えが用意されているのかどうか」という問いに対するスタンスが深く関係している気がする。
たまにいるすごく優秀なエンジニアはそこらへんをきちんと理解していて、案件によって自分のスタンスを変化させたりできるのだけど、通常のエンジニアであればそこらへんの仕事の進め方へのスタンスは長年の経験によって培ってきたものであって、なかなか容易には変えられない。（進め方のノウハウ自体が本人の技術者としてのプライドを支えてたりするケースも多いし）
逆にノリで作りたがるのは若いプログラマに多く見られて、これはスタンスというよりひとえに経験が少ないだけだったりする。
そもそも作り方なんてわかっておらず、すでに先輩プログラマが「正しい答え」の骨格を頭のなかで組み上げてるなんて想像もできないから、やたらコードを書くことを急いて「そんなのやってみなきゃわからないじゃないですか！」を連発してしまう。
つまり現実的なWeb開発の現場においては、わかっている人ほど予定調和を求めて事前に問題点を整理しようとし、そこに作ったことの無い要素が含まれていたりすると裏取りで開発が先に進まないし、わかっていない人ほど問題を先送りにして早々とカオスを招いてしまう傾向がある。
で、この構造だと結局のところ演奏は即表現となるどころか、楽譜の無い演奏が即雑音になってしまうので、経験のあるエンジニアほどリスクを取り辛くなる（しかも何もわかってない勢いだけの若手と組まされているわけだし）という悪循環を招いてしまうのである。
というわけでなんだかまだ続きそう。
腹減ったので、また明日。
携帯をかえた
半年前に買ったArrowsが音声通話ができなくなるという致命的な壊れ方をしたので、これを機会にArrowsは検証機送りにした。
(検証機という理由で最近半年おきに携帯変えてる気がする)
で、新しく買ったのはXPERIAのSXなのだけど、なにがいいってアンインストールできないプリインアプリがほぼ皆無なのに驚いた。
Arrowsのときは「スイーツの王様」とかまでアンインストール出来ず、しかも常駐するという悪どさでかなりブルーになったけど、今回はいらないアプリは完全削除で、心なしか動作も軽快な気が。
あとついでにいうとラインは機種変するとトークデータが消えてしまうことが発覚。
まあチャットだからいいのだろうけど、新しい機種で登録する前に大切な会話なんかはメールへの送信とかで保存しておく必要があるようです。
SXはかなり画面が小さいですが、まあ携帯らしいといえば携帯らしいサイズ。
重さもかなり軽いし、慣れれば結構長く使えそうです。
(自分の女子並の小さい手にもしっくりきてます)
Art Blakey’s Jazz Messengers - A Night In Tunisia (live ‘58)
JazzとWeb
Webのサービス開発には大きくわけて２つのやり方がある。
オーケストラ的な手法とジャズ的な手法だ。
どちらが正しいというのはなくて、シンプルに向き不向きだけがある。
緻密で重厚、言葉通りクラシックで完成されたものを作りたいならオーケストラ的な手法を採用する必要があるし、既成の概念を超えるような幸福な偶然に基づく何かを産み出したいのであれば、ジャズ的な手法を採用する必要がある。
オーケストラとジャズの大きな違いは、表現者と演奏者の役割を分離するかどうか、再現性と希少性のどちらに重きをおくかの２点に集約される。
オーケストラでは成果物のクオリティに関する責任は表現者である指揮者に委ねられ、演奏者の役割はいかに表現者の意図通り完璧な演奏をするかであり、演奏者が個別にあるべき独自の表現について考えることは基本的にない。（あるとしてもそれは指揮者の意図の延長にあることが要求される）
また再現性についてもあくまで目的は安定した再現性自体であり、たとえばリハーサル中に偶発的に生まれた何かを尊重することは決してなく、それは単に「何かの間違い」として処理される。（少々強引な言い方をすればだけど）
一方ジャズの世界では、価値観は全く反転する。
（ここまで書いて気づいたけど、ジャズはジャズでもビッグバンドはオーケストラとして捉える必要がある）
表現者＝演奏者であるジャズの世界において、演奏は即表現となる。
各々の演奏のクオリティについては各々が責任を持つ必要があり、全体のクオリティは各々のクオリティのかけ算になる。
ジャズにおいて同じ楽器を担当する奏者が複数配置されることは珍しく、それゆえジャズ奏者は表現に関して、明確な担当領域を任されるので、よくも悪くも個人が全体に影響を与えることができる。（もちろんオーケストラでも個人が全体に影響を与えることは可能だが、ｎ分の１で担当領域を分担しているため一人あたりの影響力は小さくなる）
また統制は必然によって導かれるのではなく偶然によって産み出されるので、そもそも再現性にあまり価値はなく、むしろリハーサル含めたすべての演奏が「歴史的表現の候補」となりえる。（実際にライブに出向いた客は、そんな冷静な考えを持てるはずがないけれど）
そしてこれらの違いに共通し根底に流れるのは、「今自分たちが直面している課題に対して、すでに正しい答えが用意されているのかどうか」という問いに対するスタンスそのものであり、それは哲学に近いものであったりする。
結構長くなりそうな感じになってきたので続きはまた次回に。
Ravel Bolero Muti／Wiener Philharmoniker
みなとみらいの観覧車の後ろに綺麗な満月が。と思って撮ったらすごいことになってた。
渋谷で働いていた頃からの定番、井の頭線渋谷駅前「山家」
node.jsと戯れてたらいつの間にか外は綺麗な朝焼け。iTunesからはいいタイミングでマッシブのプロテクションが流れてきたりして、久しぶりなこの感じ悪くない
今日から出社の新人プログラマの中国土産。
これに加えて毛沢東がケンタッキーおじさんになってるマウスパッドも貰った。
