2013/03/22

ピアノレッスン87回目

• Bach: Well-Tempered Clavier Book I No. 3 (C♯ major)
  • まだちょっとミスがあるのでもう一週がんばりましょう。
• Scriabin: Sonata No.4
  • 少しづつ頭に入ってきたかな。

来週が芝居の初日なので あまり練習できない。

Tag: Piano

2013/03/21

子供の勉強

昔取った杵柄で、子供の勉強を見るなどお茶の子歳々じゃ、と思っていたのだが 小学1年の段階で既にやばくなってきた。主に語学的な問題で。

らむ太が「学校でつくったよー」と持って帰ってくる作品を見ながら辞書を引きひき追いつこうとしている (教科書が無いので先回りができない)。

今日は学校の近くの公園に行って植物を色々スケッチしてきたようだ。 その中の単語を忘れないようにメモ:

• bryophyte コケ類植物
• pteriodophyte シダ類植物
• spermatopyte 種子植物
  • gymnosperm 裸子植物
  • angiosperm 被子植物

angi[o]- という接頭辞は血管とか心臓病とかそういうコンテキストで見たことがあるな (angiogram:血管造影図 とか angina:狭心症) と思って調べたら、「(血管壁、もしくは種子の皮によって)被われたもの」、という意味らしい。血管と種がどうつながるのかと思ったら、大元は「何かに被われたもの」で、その「何か」のひとつが「胸」になって胸の中にあるものから転じて血管になったのかな。

• angio- Online Ethymology Dictionary

Tags: 英語, 生活

2013/03/17

Things I wish I had been told in theatre school

役者としてキャリアを作ってゆくためのアドバイスだけど、役者に限らず専門職のフリーランスや、一般の就職にもあてはまることもあるなあと思った。

オーディションについて：

• Directors, casting agents, and producers care as much about how easy you will be to work with as they do about how good you are for the role. If not more so.
  (監督、プロデューサー、キャスティングエージェントは、あなたがその役をどのくらい上手くできるかと同じくらいかそれ以上に、あなたと仕事がしやすいかどうかを重視する)
• Ninety percent of casting decisions have nothing to do with how you perform in your audition.
  (役をもらえるかどうかの決定の90%は、オーディションでどのくらい上手くやれたかとは関係ない)
• Most of the time, when you don’t get the part, it’s not because you suck, but because of some other (probably superficial) reason altogether. Unless you suck.
  (役をもらえなかった場合のほとんどは、あなたが下手糞だったというよりも、もっとずっと表層的な他の理由でそうなっただけだ。もちろんあなたが本当に下手糞だった場合は除くけれど。)

これは就職面接でも同じだと思う。ランダムな要素があまりに多いので、落ちた場合にいちいち理由を推測して思い悩むのは無駄 (cf. 結果を待つ間)。もちろん必要とされるスキルは磨かないとならないけど、それは普段からやっておくもので、「面接のために」やる作業ではない。

仕事について：

• Don’t do everything. Seriously. Know when to turn something down. And believe me, you’ll know.
  ([来た仕事を]何でもかんでもやろうとするな。マジで。仕事を断ることを覚えよ。そのうちわかるようになるから。)
• It’s not unreasonable to expect to be paid for your work. And you should be. But you won’t always be. So when you do work for free, which will be a lot, make sure it’s work that you’re passionate about or will really be a career booster. And honestly, it should be both.
  (仕事には[それに見合う]報酬が支払われることを期待するのは問題ない。そうあるべきだ。でも時には望む報酬が出ないこともある。タダでやらないとならない時(それは[役者にとっては]よくあることなんだけど)は、その仕事が本当にどうしてもやりたいものであるか、キャリア作りに大きく役立つものであること。本来は、その両方であるべき。)
• No matter how big of a star you were in school, out here, you are just a part of a team. So act like it. And give credit where credit is due at every opportunity.
  学生時代にどんだけ有名だったとしても、現場では、あなたは単なるチームの一員だ。だからそのように振る舞うこと。そして他の人に助けてもらったら、必ずその功績を認めること。)
• Acting is actually easier than you want to believe it is. And more people can actually do it than you want to believe. And most people behind the scenes work harder than you do. So don’t be a diva.
  (演技というのはあなたが思っているほど難しくはないし、あなたが思っているよりも多くの人がこなすことができる。そして裏方で働いている人のほとんどはあなたよりもたくさん働いている。だからスター気取りになるな)

このへんは、演技を特定の技術に置き換えればフリーランスへのアドバイスになる。

Tags: Career, 芝居

2013/03/16

在宅勤務と出勤

私のプログラミングの仕事は、ほとんどのクライアントが日本か米国本土なので 必然的にリモート(在宅)での仕事となる。 自分としては在宅勤務は都合が良いし(通勤時間をカットできる、というのは本当に大きい)、 デメリットも感じない。 けれど、どんな仕事も在宅でok、というわけじゃないのも承知している。

在宅でもokな仕事と、そうでない仕事を分けるものはなんだろうか。

在宅のデメリットとして、「対面でないと伝わらないことがある」という議論を良く見る。 もちろん物理的に空間を共有することで伝えられる非言語情報というのは大きい (それは舞台役者として日々実感してるわけで)。 けれど、客を相手にする場合とかならともかく、 仕事上のコミュニケーションを非言語情報に頼っているとしたら、 少々、いやむしろ非常にまずいんでないかと思う。

例えばミーティングなども、必要な事項を伝達したり、 自分の主張を明確に伝えたり、まともな議論をしたいならば、 情報はかなり言語(+話し方)にエンコードされているはずで、 それならリモートでのカンファレンスコールやビデオ会議で十分だ。 むしろ、「カンファレンスコール+オンラインでの資料共有や共同編集」で成立するか どうかは、有用なミーティングかどうかの判断に使えるのではないか。 それで成立しないようなら、そのミーティングは多分時間の無駄。

でもやっぱり、空間を共有しないとどうにも動かないなあ、ということはある。 それは何だろう。

最近は、あと10日ほどで初日を迎える芝居『All That Remains』のリハーサルに 入っているのだけれど、それにヒントがあるような気がした。

『All That Remains』のリハーサルは月〜金の18:00〜22:00でやっている。 (本番直前の週だけはtech rehearsalが入るから土日も埋まるけど)。

リハーサルというのは単なる練習ではなく、参加者全員による共同創作だ。 やってみる、感じる、アイディアが出る、それを試す、さらに感じる、そのサイクルを高速で回す。 これを4時間やるとくたくたになるけれど、 その間は自分の創造回路がブーストされていると感じる。 これこそ、空間を共有しないとできないことの典型例だ。

この時間を有用なものにするためには、この4時間とは別に、一人で考える時間が必要だ。 リハーサル後に、その日稽古場で起きたことを頭の中で整理する。 日中の生活のでも頭のバックグラウンドプロセスで芝居の分析を回しておく。 ああそういうことだったのか、と昼間に突然わかることもあるし、 今日のリハではこれをやってみよう、っていうアイディアが出てくることもある。 その準備がないと、リハーサルの時間を有効に使えない。

このサイクルは、何かを作る仕事なら共通するところが多いんじゃないかと思う。 「わーっと作って壊して具合を見る」ための、 共有する時間は必要だ。けれどもその時間を有効利用するための準備として、 他人に邪魔されない、一人での時間も必要だ。

毎日8時間、創造回路のブースト状態になるのは、短期間ならともかく、継続するのは よっぽど特殊な人でない限りは無理なんじゃないかと思う。せいぜい6時間、 ウォームアップを各自済ませて共同創作モードに入れるなら1日4時間で良いんじゃないか。 そして、一人でやる準備時間は他人との空間共有はむしろ邪魔であって、 本人が最も集中できるところでやるべきだろう。自宅であれ、ドアのあるオフィス部屋であれ。 それなら1日4時間出勤すれば良いことになる。 あるいは1日置きに一人モードと共同モードをスイッチするのもいけるかもしれない。 それなら通勤時間も減らせるし。

在宅が良いか、出勤が良いか、という選択ではなく、それをうまくブレンドすると 生産性が最大化できるかもしれない。

Tags: 仕事, 芝居

2013/03/15

静的チェックで困った話

Gaucheは型付けも含めて色々動的な言語だけれど、コンパイル時にわかることは なるべく検査するようにしている。例えばローカル定義された関数は、その定義が 変更されないかどうかわかるので、アリティチェックの対象となる。

(define (start/end-vector->shape Vb Ve)
  (define (interleave a b)
    (cond [(null? a) b]
          [(null? b) a]
          [else (cons (car a) (interleave b (cdr a)))]))
  (apply shape (interleave (s32vector->list Vb) (s32vector->list Ve))))

これは今適当に引っ張ってきた関数だけど、interleaveはローカル定義されて 変更されていないので、常に2引数で呼ばれることがわかる。コード中で、interleaveが 1引数や3引数で呼ばれている箇所があれば、コンパイル時にエラーにできる。

グローバルに定義されている関数の場合はちと面倒だ。 実行時に関数定義が変更される可能性があるので、 コンパイル時に呼出側を静的に拒否することはできない。 ただまあ、実行時の関数の置き換えをやりたいのは開発中とか緊急時で、 普段はそうそう必要なものでもないので、Gaucheではユニットテスト時に モジュール毎に検査するのことを推奨している(test-module)。

例外はdefine-inlineで定義された関数で、インライン展開は コンパイル時に行われるから、この関数は開発者が「これは動的に置き換えない」と 宣言したものと解釈でき、コンパイル時の静的検査の対象にできる。 インライン展開される標準関数(consとか)が、シャドウされない限り コンパイル時チェックされるのもこの理由。

さて、ここまでが前置き。

以前、map系関数のインライン展開を試していた時に、 コンパイル時アリティ検査が干渉して困ったことがあった。 実際はmapじゃなかったんだけど、話を単純にするためにこんなナイーブなmapの定義を考える。

(define-inline (map proc xs . xss)
  (if (null? xss)
    ;; (map proc xs) で呼ばれた場合
    (if (null? xs)
      '()
      (cons (proc (car xs)) (map proc (cdr xs))))
    ;; (map proc xs ys zs ...) で呼ばれた場合
    ... 定義省略 ...))

そんで、このmapにローカルで定義された関数を渡したとする。

(define (foo as bs)
  (define (bar a b)
    ...)
  (map bar as bs))

mapがインライン展開されるとこうなる。

(define (foo as bs)
  (define (bar a b)
    ...)
  (let ([xs as]
        [xss (list bs)])
    (if (null? xss)
      (if (null? xs)
        '()
        (cons (bar (car xs)) (map bar (cdr xs)))) ; !!
      ... 複数引数の処理 ...)))

!! の行で、barが1引数で呼ばれている。コンパイラがこれを弾いてしまったのだ。

実際には !! の行は実行されることがない。 ローカル束縛をちゃんと追跡すれば、(null? xss) が常に#fであることが コンパイル時にわかるので、1引数の場合の処理部分はコンパイル時に削除されるべきで、 そうすれば問題は生じなかっただろう。

けれどもこの分岐が単純な (null? xss) でなかったらどうだろうか。 例えば (weird-map info proc . args) みたいなインタフェースで、 procのアリティが外部関数の呼び出しで計算されるものだとしたら?

(define-inline (weird-map info proc args)
  (if (= (calculate-arity-from-info info) 1)
    ;; procは1引数
    ...
    ;; procは複数引数
    ...))

こうなってくるとコンパイル時に静的にprocのアリティを検査して弾くことは難しくなる。

今回はアリティだったけれど、同じことは実行時に属性が検査される あらゆる場所で起こり得る。例えばこんなコード:

(define-inline (do-somethin x)
  (cond
    [(check-it x) (string-length x)] ;; check-itが#tならxはstring
    ...))

プログラマはcheck-itが#tを返したらxが文字列であることを 知っているが、コンパイラにはわからないとする。この関数が 次のようなコンテキストでインライン展開された場合:

(let ((n 3))
  ...
  (do-somethin n)
  ...)

整数がstring-lengthに渡される、という呼び出しがコード中に 出現することになる。そこは一見矛盾しているけれど、 実際には決して実行されないのでコードのコンパイルは通ってくれないと困る。

ナイーブな解法は、こういう箇所にその都度注釈を入れてコンパイラに 情報を伝えてやることだろう。Common Lispの記法を借りればこんな感じ：

  (cond
    [(check-it x)
     (locally (declare (string x))
       (string-length x))]
    ...))

だけどこういう注釈をちまちまつけてると、コンパイラのご機嫌を取ってる気分に なってくるのも確か。さらにdo-somethinの定義が自分の触れない場所に あったりすると不満が募る。(それで不満に感じないなら最初から静的型付き言語を使ってるって)。

問題の根源はコンパイラが十分に情報を持っていないことにある。 静的型付き言語は「コンパイラに型という言語でもって情報を伝える」っていう 方針なわけだけど、型という言語体系にうまく載せられる情報と載せにくい情報があるからなあ。

ひとつの手は全てのプログラムをコンパイラが見ることだ。Stalinがやってるけど、 標準ライブラリも含めてコンパイル時に全部を見ることで、今回の場合だとcheck-itが #tならxが文字列であることを演繹できる。でもこの方法はプログラムが大きくなると コンパイルに時間がかかりすぎて破綻する。

むしろ、コンパイラが使える材料を一種の知識ベースのように 考えて、後付けでいろいろな情報を放り込んでやれないかな。 ここの例でいえば、「(check-it x)が#tを返したらxはstringだよ」っていう情報を check-itの実装者以外でも後から注記できるようにするとか。

ライブラリ関数が使われる箇所でコンパイラが実際にどういう情報を必要とするかを、 ライブラリ実装者があらかじめ全て見通しておくことはできないと思う (「それができるように型システムを整備する」というのが静的型の発想だけど、 そこで完全を目指すと「仕様を全部形式言語で書いておく」なんてところに 行き着いちゃうんじゃないだろうか)。

Lispのカルチャーの一つは、「システムを書いた人より、それを使う人の方が賢い」 という前提だ。なぜなら人は道具を使うことで、その道具に関する新たな知見を「発見」して ゆくから。後付けで作者以外が知識をばらばらに追加してゆくのはこういう思考に 合うかもしれない。

Tag: Programming