Shiro:log:2005前半
- 最新:Shiro
- 後: Shiro:log:2005後半
- 前:Shiro:log:2004後半
(2005/06/22 21:02:54 PDT)
なにやらokujiさんからMusical Baton というのが回ってきた。音楽をネタに自分語りをやる企画、なのかしらん。 自分はあまり日常的に音楽を聴く人ではないので 質問の対象外である気がするけど一応やってみる。
- Total volume of music files on my computer:
HDDから音楽を聴く習慣がほとんどない。midiファイルが2.5MBくらい、 クラシックピアノ曲中心。 The Classical MIDI Connection, Kunst der Fuge あたりをちょくちょく見ている。 - Song playing right now:
Ray Bumatai: All the things I said. たまたまokujiさんの日記を見てた時にかけてた。 こないだ映画で共演した人のCD。 この人はミュージカル出演中に脳腫瘍から出血し、途中で視力を失いながら その舞台を最後までつとめて病院に直行、手術、リハビリを経て 数週間後に再び公演に復帰したという鉄人役者であることを、 私は撮影がすっかり終わって家に帰ってから知ったのであった。 撮影中は気のいいロコのおじさんにしか見えなかったよ。 - The last CD I bought:
もう長いこと買ってない。多分、数ヵ月前に買ったこれが最後: Daniel Barenboim (p), Pierre Boulez (cond) NFO: Bartok Piano Concertos 1&3. - Five songs(tunes) I listen to a lot, or that mean a lot to me:
難しい質問。私は気にいった曲があるとそれだけを繰り返し聴いて、 そのうち覚えてしまって、以降は脳内再生で済ますのでほとんど音源を聴かなくなる。 だから日常的によく聴いている曲ってあまりないし、 一方で思い入れのある曲はとても5曲には絞れない。 とりあえず頭に浮かんだものを書いてみる。songじゃないけど。- Chopin: Etudes Op.10&25
いきなりこれで24曲だけど、ひとまとめの感覚。 一年くらい前に真面目に全曲さらおうと思い立って、 まだ道半ばだけれど、とても勉強になる。じわじわと基礎力がついてくるのを実感できる。 耳に残っている演奏はポリーニ。 - Ravel: Jeux d'eau
かれこれ20年くらいさらっててまだちゃんと弾けない。 気分を集中させようとする時によく聴こえてくる。 耳に残っている演奏はアルゲリッチ。 - Alkan: 12 Etudes Op 39
永遠の目標。さらっていると修行僧の気分になる。いま手がつけられるのは 2番くらいだが、死ぬまでに8, 9, 10番を弾きたい。耳に残っている演奏はギボンス。 - Rachmaninoff: Piano Concerts 2&3
永遠の目標。ピアノ弾きの夢でしょう。 2番と3番、どちらも好きなので両方挙げとく。 耳に残っている演奏はアシュケナージ。 3番の3楽章で、魂が肉体の殻を突き抜けて飛翔するのを感じる。 - Ravel: Concerto pour la main gauche
tuttiのオケに左手一本で渡り合う再現部から驚異のカデンツァへの流れにカタルシス。 耳に残ってる演奏は、誰かなあ、ちょっと思い付かない。
- Chopin: Etudes Op.10&25
- Five people to whom I'm passing the baton:
特に誰というのを思いつかないので、ここで打ち止め。 …としようかと思ったけど、せっかくのWikiなので、 もし語りたいひとがいたらこの下からリンクを張って語ってください。 (コメントで語るのはごちゃごちゃするので御遠慮下さい)
(2005/06/14 02:19:54 PDT
短篇映画の撮影で、丸2日Kaneohe近辺でロケしてきた。 今回はprincipal roleで、長ぜりもある。
カメラと舞台での演技のつくりかたの違い、そしてカメラでの仕事で 目指すべきことがなんとなくわかってきた気がする。
映画では、監督は役者の演技以外にも気にすることが山ほどある。 音、光、フレーミング、タイミング、背景に映るもろもろ。 全てがベストに揃えばラッキーだがそういうことは滅多に無いので、 基本的には監督の望んだレベルの画が撮れた時点で次のショットに 移ることになる。また、リハーサルの時間もあまり取れないから、 役者が持ってきたものを見せて、監督が若干adjustして、それでgoとなる。 つまり、こういうことが言える。
- 演技が "good enough" であればそこで終わり
- 演技しながら色々なオプションを発見している暇はない
舞台のようにリハーサルにたっぷり時間が取れる場合、最初に役者が 演出に見せるのは叩き台で、そこから演出や他の役者との共同作業で 場を作って行く作業が始まる。演出が当初期待していた通りの 演技をするのは役者の負けというか、そこがスタートラインであって、 そこからどれだけ上を目指せるかというのが勝負どころになる。 当初誰も予想できなかったくらい良いシーンをつくることがゴール なんで、"good enough" な演技だけじゃだめだし、演技しながら いかに発見してゆくかが重要だ。
Acting Classの先生の一人は、"If you can act on stage, you can act on anything" と言っていたけれど、"good enough" な演技をdeliverする、という意味では確かにそう言えるかもしれない。
でもなあ、やっぱり演技として観たい/観せたいのは、人の頭で あらかじめ予想がつく程度のものじゃないはずだ。 カメラの現場でそれをやるには、最初に監督に持ってく時点で "beyond `good enough'" でなければならない。
オーバー気味で持ってけばadjustmentで抑えるのはできるが、 アンダー気味で持ってくと予想を越えられない可能性が高いだろう。 また、監督の予想する演技というのは、その役者が過去にやった 仕事とかオーディションでの演技を元にしたものであることが多いだろうから、 まだ誰も発見していない側面を出したいと思うなら、やっぱり リハーサルの最初の一発でそれを見せられるように準備しておかねば ならないだろう。そこらへんで舞台と違うアプローチが必要なようだ。
(もしこの知見が正しいとしたら、カメラの演技しか経験しないことは 役者の成長にとって不利だといえる。その役者が天性の勘で上を目指さない限り、 "good enough" 以上のものを求められないからだ。)
(2005/06/06 05:29:08 PDT)
真偽の程は定かではないが、かつて忍びの者は人並み外れた跳躍力を得るために、 成長の速い木の苗を植えその上を毎日跳び越えたという。木は一日一日、目に 見えぬほど少しづつ成長し、それに伴って訓練者は知らぬうちに少しづつ 高く跳躍することを強いられる。ふと気づけば見上げるほどに成長した木さえも 跳び越せるようになっている、という。
かねてより私は子を育てる親にも同様の原理が働いてしかるべきではないかと 考えていた。すなわち、産まれたばかりの、3kg少々の赤子を「ひょい」と 抱きあげるのは造作もないことである。親ともなれば毎日いちいち数えていられない くらい赤子を抱きあげる。そして赤子は一日一日、着実に成長してゆく。さすれば 1年2年と経つうちに、親は知らぬうちに20kgの荷物を「ひょい」と 持ち上げられるようになっていて然るべきではなかろうか。
この疑問は実地検証によっていともたやすく覆された。子供の成長速度は、 親の筋力の増強速度を確実に上回っているのであった。
- 幸せって重いとは子を持って初めて分かる?そのうち(親が)軽い寂しさを味わうのでしょうか。。。(Makoto:2005/06/07 06:41:53 PDT)
- 生まれたてが3Kgちょっとで、1Km離れた場所まで行くのに奥さんと交替でだっこしてフウフウしていたのが、1年半後には、10Kg以上(忘れた)の子供をダッコ紐で片手で支えて、右手には折り畳みの(小さいやつ)ベビーカーを持って、ハイキングで山道を上ったり下ったりして歩いていました。。。(Setu?2005/06/07 12:28:56 PDT)
- おお、Setuさんのところでは忍者効果があったのですね。Shiro(2005/06/07 17:55:30 PDT)
- 我が子であれば20Kgぐらいならだっこできますが20Kgの荷物は持ち上げられません。なぜなら荷物は可愛くないから。私は子供が2歳ぐらいまでの頃が生涯でいちばん痩せていました。腰に負荷が集中するので、子供が大きくなってくると腰痛が悪くなり、だっこできなくなります。えんどう(2005/06/11 20:08:14 PDT)
(2005/05/15 01:53:42 PDT)
あちこちで話題の「コード読みのコード知らず」。自分の感覚で言えば、 OSSのコード書きは芝居の役者だな。自分でやってるプロジェクトの場合は 作・演出を兼ねてる。
役者が居ないと芝居は始まらないが、もひとつ芝居に不可欠なのは観客だ。 (あと、街頭パフォーマンスのようなものを除くなら、スタッフも)。 役者の役割は全体の何割、スタッフは何割、 観客は何割、なんていう分析はできない。
役者が観客の批評に対して「演技もできない人に口を出されたくない」 というのはおかしいわな。なんのために客に見せてるんだってことになる。 一方観客の方も、口を出すのは自由だけど、それが舞台に反映されなかったからって 文句を言うのは筋違いだわな。 双方のより良いものを(創りたい|観たい)との思いが噛み合った時にのみ、 みんなが得をする。そうでなければ誰も得をしない。
OSSでは観客=ユーザ。自分流の「プログラマの定義」を 「人に使ってもらえるプログラムを書く人」としているのはそういうわけ。
(2005/05/14 13:55:30 PDT)
へぇ。米国での経験では、宣伝媒体に出演する場合、たとえエキストラであっても 「宣伝期間が終了するか、クライアントから了承を受けない限り、 直接競合する他者の宣伝媒体には出演しない」という書類にサインさせられる。
もっとも契約はケースバイケースなので、実際の契約を知らない外野が 個々の事例についてとやかくは言えない。
(2005/05/11 15:52:00 PDT)
64bit なシステムで、64bit 浮動小数点数を即値で扱うとしたら、 どういうふうにして浮動小数点数を区別するのが適切か?
おそらく、(Fixnum が 63bit 整数であるのと同様に) 64bit よりもちょっと小さい浮動小数点を定義することになる。 たぶん指数を削るのが適切だと思うが、他の選択肢はあるか?
「浮動小数点数でNaNになるビットパターンに他の型のオブジェクトを詰め込む」 というLisp処理系があったはず。実装したのはFritz Kunze (Franz Inc.の社長)。 Fritzから聞いたところによれば、浮動小数点数の性能は格段に向上したが、 非常に稀な確率で演算結果が別の型のビットパターンになってしまう可能性が あって使えなかったそうだ (ここんとこ、具体的な話は聞かなかったんだけど)。
ネイティブコンパイラを持つ現在のCL処理系では、型をちゃんとdeclareしとけば コンパイラがboxing/unboxingを避けるコードを出してくれる。 でもインタプリタでうまくやる方法は知らない。 VM上に浮動小数点数レジスタを持っておくなんてことをちらりと考えたんだけど、 継続やクロージャ作成に伴うコンテキストの保存がとても面倒になりそうなんで 試してない。
(2005/05/11 03:17:03 PDT)
長らく2人家族だった我が家だが、 先日ついに家族が増えたので現在てんやわんやの大騒ぎ状態である。 新メンバーは元気な男児。ネット上では仮に「らむ太」としておこう。
病院はハワイで多分一番古いところだけれど、最近改装したせいかなかなか 綺麗だった。入口なんかホテルみたい。分娩室はゆったりしてて、陣痛段階 では付き添いの私が休めるように簡易ベッドまで出してくれた。いよいよという 時になって親しい友人姉妹が応援に駆けつけてくれて、出産まで立ち会ってくれた。 賑やかに会話している方が気が紛れてかみさんも良かったみたい。 分娩後は個室に移されて、らむ太も時々検査で連れ出される以外は一緒に過ごせた。 食事がいまいちであること以外は悪くない病院ライフだったが、 米国は出産後2日で退院である。そして寝不足の日々。
ようやく徐々に生活のペースができそうな気配で、 仕事も多少手につくようになってきた。 らむ太はひたすら飲んで寝て出して、毎日すこしづつ大きくなっているようだ。
- おおっ、おめでとうございます!!cut-sea:2005/05/11 04:39:55 PDT
- おめでとうございます。元気そうでなによりです。うちの愚息2号はそろそろ半年を迎えますが、まだそんな感じ(飲寝出)ですよー。Makoto
- おめでとうございます〜。お子様がしあわせでありますように。ねるWiki:ねる
- おめでとうございます!!(nobsun)
- おめでとうございます。(shelarcy)
- おめでとうございます!(ささだ)
- おめでとうございます!!!(emeitch)
- 皆様、ありがとうございます。順調に育っているようです。 (Shiro)
(2005/04/27 03:08:38 PDT) R6RS
んー、[]は()と同じ扱いになるのか… 独自拡張入れたかったんだけどなあ。 Unicode supportは揉めそうだなあ。 潔くstringをimmutableにすればいろいろと丸く収まりそうな気がするが。
- 最初見たとき?だったのが最後の Consolidation だったのですが。
comp.lang.scheme
でも少し話題になっているようで。
>>>| - all datums will be serializable and obey read/write invariance >>>I wonder how procedures and open files are going to be serialized. > > Unless they change the set of values called datums, procedures > and ports aren't datums. > >> I wonder how the eof-object will be serialized. > > My guess: #!eof (see the previous progress report). The eof-object isn't a datum either, unless they change the definition of datum. See section 7.1.2 of R5RS.
で、datumsっていわゆる値ではないのですね。 procedureが第一級の値で、こいつのことを言っているのだと思ったので、 どうやってR/Wすんだべか???とか真っ先に思ったわけですが、 sec7.1.2に確かに定義されておりますなぁ。 上でもくどくど書かれている通り、datumsの定義が変わってなければ。
結局、read/write invarianceってどういうことよ?ってやっぱり謎。
ところで独自拡張とはどんなものを構想されてたんですか?cut-sea:2005/04/27 17:23:53 PDT - Shiro(2005/04/27 20:39:03 PDT): Gauche:スロットアクセスの "[x y]" の項参照。read/write invarianceはここで説明するのはごちゃごちゃしそうなので 知りたければ別ページにしましょう。
- 是非 > Scheme:ReadWriteInvariance cut-sea
(2005/04/18 05:10:58 PDT) 「中年男」のまめちしき
ああいう役は、米国のTVプロダクションでは "under-five" と呼ばれる。 せりふが5行以下のspeaking roleということ(現地採用キャストは こちらでcoordinationを行ったプロダクションとの契約になり、AFTRA基準が 適用されたようだ。私は非組合員だけど。映画の場合はSAGになるので 少し事情が違う。)
extraには、せりふが無い。extraにも単なるbackgroundの一部と、 主役と絡むfeatured extraがあるが、どんなに目立ってもせりふが無い限り extraはextraである。それが一言でもせりふを発するとspeaking roleとなり (1)ペイが倍以上 (2)レジュメに'speaking role'と書ける、など役者にとっては 大きな違いが出る。under-fiveより上は、featured speaking roleとか principal speaking roleになるのかな、「ちょい役」ではなくなる。
もちろんプロダクションとしては支出をなるべく減らしたいわけで、 TVドラマや映画の「せりふの量」はそういう点でもかなり綿密に計画されている、はず。 たまに現場で流れ上どうしてもせりふが必要になって、 non-speaking roleからspeaking roleへの「格上げ」もあるらしい。
日本の撮影の場合はどういう基準が適用されるのか知らないけれど。 米国ほど組合が厳しくなさそうな気はする。
(2005/04/18 04:07:22 PDT)
SLIBを3a1にしたらGnucashが動かなくなった… libguile経由で依存してたとは気づかなかったよ。 帳簿がつけられないのは困るので2d6に戻した。
format.scmが除かれたのが原因みたいだけど、まったく、 多くのアプリに使われるようになるとうかつに変えられんなぁ。 まだGaucheにはそこまでの影響力はないだろうから イジるなら今のうちか。
(2005/04/14 04:59:49 PDT)
めちゃおもろい。自動生成した論文がacceptされた話 : SCIgen - An Automatic CS Paper Generator
- ytaki(2005/04/14 23:13:20 PDT): ``which exist only to make money''てあたりがキツいですね(^^;). randomly-generated talk も聞いてみたいところ. でもこれ,slashdot.org とかに出ちゃいましたよねえ. 開催側にも知られて急遽発表取り消されたりして.
- Shiro(2005/04/14 23:29:17 PDT)上記ページに追記されてます。主催者も気づいたみたい (レビュアーの一人と、それ以外からも問い合わせがあったようです)。 主催者からの言い訳めいたレターも公開されています。 取り消されちゃうかもしれませんね。
- Shiro(2005/04/15 17:48:39 PDT): さらに追記があって、結局rejectされちゃったみたい。 払い込んだ参加費も払い戻されたそうで。 こちらに、 この主催者を調べた経緯が出てます。
- ytaki(2005/04/16 08:56:38 PDT): 代わりに発表するため,今回の conference で 論文が accept された人を募集してますね(^^;).さすがに今度は知られない ようにするみたいですが,さて.
- /.Jにも出たようですが、私はふーんって感じ。
だって論文て、その内容が真理(うーむ曖昧)かどうかでacceptされるかrejectされるか が決まるわけじゃなくて(そんなもん無理だし、だからこそ論文ネタになるんだし)、 論理(というか筋道・理屈)がちゃんと通っているかどうかだからなぁと。
自動生成した論文は読んでないけど、その辺さえスジが通ってて、 あとは既出でなければ受理されるものじゃないのって思ってたもんねぇ。
だから嘘のでっちあげ実験結果であってもacceptされるものもあるでしょう。 追試やる研究者とかでて来て嘘がバレて確信犯でやったのが分かれば、 次から一切相手にされなくなるだけかな。cut-sea:2005/04/19 03:36:13 PDT - Shiro: いやいやいやいや、この話の面白さは、論文を読んでこそなんです。 人工無能のチャットログを読むみたいな不条理さがいいんですよ。 それ抜きにあれこれ論評してもあまり楽しめないと思います。/.Jではいつもどおり 元のページを読まずにあれこれ言う書き込みが多いみたいですが。 (そもそもソーカルのやつだって、「パロディがacceptされた」事実よりも 内容にポイントがあるって本人が言ってなかったっけ)。
- あ、不条理なんだ。(^^;それはシツレー致しました。
しかし、...読むのか俺の論文 「A Deployment of Voice-over-IP」だそうです。 ...........abstract見た時点で思ったのですが、 これって逆にかなり英語力ないとワケ分からないんじゃ...(-,-;;;;cut-sea:2005/04/19 04:33:42 PDT - ytaki(2005/04/19 09:13:13 PDT): /.J はチョイスされるネタがどうにも扇動的というか…. それはともかく,これはつまりアレですよ,大真面目な体裁で嘘八百並べるエイプリル フールサイトみたいなものというか(彼らがウケを狙ったかどうかはこの際置いとく). もっとも僕の場合は,今回の件聞いてすぐ ELIZA を連想しちゃってたんですが (ヒネリなさすぎ).
- 全くrandomというわけでもさなげ。
何回も何回も論文を生成してざっと見るってのを繰り返すとグラフタイトルにせよ、
セクションタイトルにせよ似たようなのを作ってくる。
まぁそれはさておき、論文誌はこういったスパムとでもいうべきシロモノを 今後どうしていくか考えねばならないのか? だれかがIpv7なんて言葉が入っててずっと分かりやすいとかおっしゃってたが、 そう簡単でもないんだよね。 現Ipv6になんらかの設計上の欠陥を発見して(それが正しいかどうかは別)、 そしてIpv7なるものを考えて発表するってことがありうるからだ。
つまり論文は常に現状の知識なんかを覆す可能性のあるものだから、 単純に単語見ただけでrejectするというわけにもいかないように思う。
まさに不条理であることを確認せにゃならんのだ。 一方、論文の査読なんて同じ分野の研究者でもなきゃできないし、 特に査読者ってのはその分野の先端いってる人だったりするからそんなものに 貴重な頭脳の貴重な時間を取らせるのは大きな損失だ。 自動生成でガンガンやられたら簡単に時間を食いつぶされそうだ。 さあ、どうする?cut-sea:2005/04/20 21:00:18 PDT - Shiro: 私はそんなに心配してないです。確かに、査読コメントを まともに書こうと思うとじっくり読まなければなりませんが、「明らかに 通らなさそうな論文」というのはアブストとイントロと結論をざっと読めば 大抵わかりますし、そこであまりにひどければ査読コメントだって力を抜くでしょう。 (今回の論文なんて、1分でjokeとわかるものです。) 本当に時間が取られるのは、ちゃんと問題を把握していることが 伺われて、それなりの結果も得られてて、でも書き方がobscureで論理が追い難い、 というような論文です。ボーダーライン上のものですね。 自動生成論文がそこまで行くかどうかというと、どうかなあ。 最悪の事態として、ものすごく大量の投稿があるようになったら、 学会の方だって下読み部隊を使って足切りするようになるんじゃないかと 思いますよ。
- 私はボーダーライン上の論文はあまり考えてなくて、 まさに大量に送られてきたらどうなるだろうと思ってました。 まっとうな論文がスパムの海に埋もれたらどうなるだろう、 人間対計算機だとあまりに分が悪すぎるかなと。 スパムメールと違ってやる目的がないですかね。cut-sea:2005/04/21 01:01:39 PDT
- ytaki(2005/04/24 12:29:12 PDT): 大量に送られてきた場合,困るのは査読する人というよりは,誰に査読を依頼するか といったことをさばくとりまとめ担当者(事務局とか)かもしれませんね(^^;). ただ,今回の件はどちらかというと,全体の投稿数が少ないゆえに,(大会を実施する ため)ろくに査読もせず大半を通している印象が.だからこそ CFP なメールが spam の ようにバラまかれているんじゃないかなと.僕も仕事の関係上,規模が小さい論文誌の 査読とかを何度かやってるだけに,この観点ではあんまし笑えない….
- あ、そうか。最初に振分ける人が要るんだ。で、こういうstoryを考える。
あー、対ウィルス関係のソフトとか作ってる会社に対して、 いつもこういうこと想像しちゃう私はホント失礼だなぁ。cut-sea:2005/04/24 16:59:49 PDT- スパム論文をさばくのが大変になる
- 当然えらい先生なんかにやらせるのは無駄だから手頃な人を確保することに決定
- ある程度人海戦術だが、誰でも良いわけでない
- 多少高額なバイトとして研究室の学生などが人力フィルタを担当
- 雇ってもらいたい学生が自らどんどんspamる
- 自分のspamは簡単なんで、がんがんフィルタリングしてウハウハ
- (不毛な)市場が出来あがる(TヮT)
- ytaki(2005/04/26 18:08:36 PDT): もしかすると引用元だったかもしれませんが(^^;), 『Matzにっき』で Graham 氏の言葉を引用しながら今回の件を取り上げてますね.いやあ,心当たりありすぎ(汗).
(2005/03/20 17:05:45 PST)
学生諸君。もしくはLisp/Schemeで一山当てたい人。
Paul Graham, Trevor Blackwell, Robert Morris他数人が、スタートアップ向けの 投資プログラムをやるそうな。学生を念頭に置いてはいるが、 特に学生に限定してはいないとのこと。今回の応募締切は3/26。 採用者にはとりあえず夏を乗り切るだけのseed moneyが 渡される。その後どうなるかは自分次第。
http://www.paulgraham.com/summerfounder.html
c.l.lの投稿で、PaulはLispを使うことは特にwelcomeだと述べている。
夏の間、Cambridgeに行かなければならないのと、ビザは自分で 何とかしなければならないのが、外国人にはネックか。
- このページのRSSを取る方法はありますか? - arai
- Shiro: このページ「だけ」取る方法はないです。ちょっとハックすれば 特定ページだけ取るインタフェースはつけられると思うけれど、 どうせならここ(自分個人のメモ書き)をもうすこしblogちっくな 構成にしたいと思い続けてはや幾年。
- arai: そうですか、blog化を楽しみにしてます:)
(2005/03/16 02:38:14 PST)
"Software factory"って1980年代くらいに言われてなかったっけ。 大学のゼミで分厚い英語の本を輪講した覚えがあるぞ。
「次世代開発基盤技術“Software Factories"」「ソフトウェア工業化を目指して」 なんて文句を目にして、かつてはこういう考えがあったっていう 昔語りかと思ったら、なんかごく最近の記事なんだねぇ。 まあ当時はOOだのパターン言語だのって今ほど言われてなかったから、 現在とは事情が全然違うが。
あ、これだ。Michael A. Cusumano: "Japan's Software Factories: A Challenge to U.S. Management"。1991年出版か。
(2005/03/15 02:21:56 PST)
今年のILCに出すのは断念。Stanfordだから行けば会いたい人もいるけれど、 ちょっと日程が。
(2005/03/05 13:32:46 PST)
昨日は初めてon cameraのactingを経験した。 日本のTVドラマのロケに現地キャスト組として参加。 役者に必要なのは忍耐であると知る。 とにかく待ち時間が多く、テンションの調節が難しい。 ぶつ切りで撮るので舞台と違って流れでテンションを上げることが できない。かといってテンション上げっぱなしでは持たない。 ちなみに9:30am集合で上がったのが1:15am。日本からの役者は 着いていきなりこのスケジュールだったからもっと大変だ。
他に訓練が必要だと思ったこと。
- 演技がくどくなりがちかも。ぶつ切りで撮ってるとつい カット中のアクションを強調したくなるんだけど、ほんとは連続してる 演技の一瞬を取り出してるだけなんだよな。
- 繰り返し、ぶつ切りで同じ演技ができないとならない。 舞台の「ノリ」の作り方よりも職人的なスキルが要求される。
- フレームを意識する必要があるのかな。CUだとあまりアクションを 大きくするとうるさくなるんだろう。もっと自分が映ってるところを 観て研究したい。現場ではあんまりそのチャンスがない。
- アップがあるので舞台よりも細かいところが目立つ。 自然さがねぇ。難しいねぇ。
まあちょい役だからたいしてダメももらわなかったんだけど。 とても勉強になった。何事も経験値を積むことが必要。
(追記)色々考えたけど、やっぱり基本は舞台と全く同じだと思い始めた。 actionの前に既に役があって、シーン開始から後は役が自然に流れるように しておけば、カメラでも舞台でも違いはないはず。 シーンの前に役が確立してなくて、始まってから演技を「押し出そう」とするから ダメになる。それが舞台では力で押し切って誤魔化した気分になれる場合が あるのに対し、カメラでは誤魔化しが効きにくいってだけなんじゃなかろうか。
ああ。思い出すと色々やり直したくなるけど、チャンスは一回きりなんだよね。 舞台では次のステージに反映させることができるけれど。 でも舞台だって、それぞれのステージが一回きりのチャンスであることには 変わりない。
ベテランの俳優さんと絡むところが数箇所あって、落ち着いて振り返って みると、やっぱり上手いなあと思う。ほんの一瞬の表情がね。 それにちゃんとreactできたかと考えると、ガタガタだ。
うーむ… 考えれば考えるほど落ち込んでくるな。精進せねば。
(追記2)もうハワイロケの情報は出てるみたいだからいいかな。 フジテレビ4/14(木) 10pm〜 「恋におちたら」冒頭の部分。役名は「中年男」 :-}
(2005/03/02 14:26:35 PST)
Matzにっき経由で JSON(JavaScript Object Notation)。 parenphobiaな同僚のためにこれにそっくりの文法の設定ファイルリーダ/ライタを 作ったことがあるなあ。
S式を含めると、'()', '<>', '{}' の三つ巴ですな。
shared substructureは無視、ってのはまあいいとして、 JSON in JavaScriptでパーズに 「evalを使え」って言ってるのはどうなんだろうか。 readとevalを言語が分けてればいいのに。 内部では分かれてるはずなのに、それをプログラマから使えないようにしている 言語は、どうしてそうしているのかしらん。
(2005/02/27 13:56:58 PST)
昨夜はArmy Community Theaterの "Miss Saigon" を観た。 ヒロインのKimを演じた役者が、昨年のDiamond Head Theaterの Actingクラスで一緒だった人であった。まだ高校生だがすごい歌唱力と キャパ900の劇場を満たすエネルギーに圧倒された。確かにクラスでも 勘が良い役者だなと思ったが、1年でここまでの成長ぶりを目の当りに すると、人間の可能性ってのにむしろそら恐ろしくなる。
Paul Grahamが書いているように、16歳のアインシュタインやシェークスピアは、 頭角を顕わしていたとしても、他の部分では普通の子供とさほど変わらなかった のだろう。そこと、数年後、数十年後に彼らが成し遂げたこととの間の連続性を 想像できなきゃいかんと思う。
(2005/02/26 15:24:15 PST)
昨年、ある脳生理学者が、Lispハッカーがハッキングに没頭している時の 脳波を計測した。すると「人間らしさ」を司る前頭前野において、α波が 優位になりβ波が低下したという。
α波はリラックスしている時に見られる脳波と言われる。「たくさんの 開き括弧と閉じ括弧が、寄せては返す波のリズムのように作用し、脳に 影響をあたえているのではないか」と研究を行ったエム博士は述べている。
エム博士はインタビューでさらに衝撃的な理論を明らかにした。 「この波形は痴呆症の患者のものとよく似ている」というのだ。 「Lispは専門家の間ではとても危険な言語として知られています。 JavaやC++といった正統的な言語では、プログラマはよく考えてから プログラムを書かないと、実行する以前にコンパイルエラーになってしまいます。 しかし、Lispにはそのような規律が全くありません。でたらめなコードでも 実行できてしまい、エラーが起きてもそこで適当に数値を書き換えて実行を続ける ことができてしまうのです。こんな言語を使っているプログラマは ものを考えなくなり、適当に式を打ち込んで、動けば良いという習慣が ついてしまいます。」
エム博士は続けた。「考えることを止めたルーズなLispプログラマは、やがてコンピュータに 合わせてプログラムを書くのではなく、あたかも自分がコンピュータを 操っているかのような全能感に囚われます。自分が一番であるというこの 全能感のために、Lispプログラマは他の言語を使うプログラマを馬鹿にし始める のです。」博士はそのようなプログラマの脳は「Lisp脳」になっているのだと言う。 「この感覚は麻薬のようなものです。一度溺れてしまうと、 そこから抜け出すのは容易ではありません。」 Lisp脳の症状としては、「他の言語を馬鹿にする」の他にも、 「定められた勤務時間を無視する」、「見積りを出す前にプログラムを書き上げてしまう」、 「会議でじっと上司の話を聞いていることができない」、 等があるという。
Lispの一種であるSchemeというプログラミング言語は、プログラミングの入門 教育で使われることがある。そのことにインタビュアーが触れると博士は激昂した。 「それは殺人教育です。 アメリカでは軍事予算でLispの研究をやっている。 日本でも最近はゆとり教育だの何だのと言って子供に好きなようにやらせている。 もともと日本には、芸事はまず形から入るという文化があった。 師匠の真似をして、一通り形ができるようになって、それから心がわかるのです。 まずは紙の上で、誤りが一切無いプログラムを書けるようになるまで 修行すべきです。私が学生の頃は皆そうやっていた。」
また最近の研究では、Lispプログラマの能力と、高機能自閉症の一種である アスペルガー症候群との間に関連が見られるという。 「Lispで自閉症になるんです」 エム博士はこう断言する。 「コンピュータを自由自在に操れる全能感に溺れ、自分の殻の中に閉じこもるのです。」 博士は一枚の紙を取り出した。「典型的なLispプログラムの見かけはこのようなものです。」
((((;゚Д゚)))
「ほら、冷汗をかいて震えている人間のように見えませんか。これはLispプログラマの 対人恐怖という潜在意識がプログラムコードの上に滲み出ているからなのです。」
---- 『Lisp脳の恐怖』出版記念インタビュー記事より抜粋
- エム研究室でよく出る決めゼリフ ベスト3 cut-sea:(2005/02/26 17:28:57 PST)
- 「括弧?そんなものあったかのう」 おじーちゃんがLisp脳でボケちゃった!!
(2005/01/25 16:59:21 PST)
What you'll wish you'd knownはこれまで訳したPaulのエッセイの中で公開後3日間の最多ヒットを記録した。 リファラをたどって感想を読んでいると、色々な見方があって参考になる。 無理矢理分類すると次の3つが主流っぽい。
- 後悔 (俺も高校生の時に知っておきたかったよ)
- 元気が出る (俺の方向は間違ってなかった / 今からだって始められる)
- ふーん
現役高校生と思しきblogで「ふーん」が散見されたのは、良いことだと思う。 自分も、高校の時に聞いていたらそんなに熱くならずに、「まあそりゃもっともだねぇ」と 思っていただろう。ただ、それが正しいということを経験を以って支持してくれる 人がいる、ということを知るのは、悪くない。
たぶんあの頃の年代は、上の世代からハッパをかけられると、 それが正しくても何か素直に従いたくないものがあるんだと思う。 自分でやりたいから、先回りされてやることを言われるのが面白くないのだ。 背中を押されるよりも、それで良い、という確認の方が素直に受け取れるんだろう。 (「あまり苦労をかけさせるなよ」と笑いながら、「やりたいならおやんなさい」 と言ってくれた劇部の顧問の先生を思い出す。)
(2005/01/23 18:52:41 PST)
半年くらい前に Paulの反オブジェクト指向のメモを 翻訳していたのを 公開するのをすっかり忘れてた。 Jonathan Reesのメッセージの方の 公開をちょっと待つ事情があって、待ってるうちに忘却の彼方に 消えてしまっていたのだった。
(2005/01/22 03:53:52 PST)
Paul Grahamのエッセイの新作が出てた。ひさしぶりに熱い内容だったので 一気に訳してしまった。
自分の高校時代を振り返ってみると、たぶん半分くらいは、 いや3/4くらいは、本当に好きなことをやっていたと思う(その大半は 演劇部だった)。でもどこかでブレーキをかけていたところがあった (「こんなに忙しくて大変だ」って思ってたからね。その時の自分に 数年後のスケジュールを教えたらどう思ってただろう)。 Paulがいうように、高校でできることの大部分はそれ以降の本物の仕事に比べたら 誤差くらいのものなんだから、遠慮無しにやってれば良かった。 今、時を遡ってあの時の自分に会えるなら、絶対後悔しないから もっとやれ、とハッパをかけるだろう。
でも、人生の到達点はそれまでの積分なんだから、同じアドバイスが どの時点でも有効なはずだ。やりたいことはたくさんある。それなら、 絶対後悔しないから、貪欲に、遠慮せずにやればいい。
- うーっむ!確かにおもしろいですね。 でも、この講演がキャンセルするのも分かるよ。 Paul Graham は刃物をギラつかせすぎ。cut-sea
- Shiro:ハッカーにTPOを期待しちゃだめでしょう。 でも高校の文化祭でこういう人を招いて、ついでに教師との パネルディスカッションなんかやったらすごい面白いと思うけど。 (私の出身高校で一度、生徒、教師、OBを集めたディスカッション企画に 参加したことがあって、結構面白かった。)
- あはは。口にできないことを平気で口にする、と。
多分 Paul Graham はキャンセル食らうなんて 本気で夢にも思わなかったのかもしれませんね。
一方、内容については私も共感できたし、Shiroさんのおっしゃる様に 高校時代に自分に教えてやりたいと思ったりもしますが、 もし、あの時点で興味のあった方向に走ってたら、UNIX や Lisp/Scheme には 出会わずに MS-DOS->Windows->VB とかに走ってた可能性が高いなと思ってたりする。
私が自身をラッキーだと思うのは、それなりに良いタイミングで 良い環境に出会えているってこと。 (もちろんWin->VBな分岐をたどった自分もラッキーだと信じてたかもしれないが)
良いタイミングとは自分がそれを受け入れられる(心の)準備が出来ているところで それに出会えているって思うこと。
あと10年早くschemeに出会いたかったというのも本心だが、 その時点の私がschemeに出会ってもつまらないと思ってしまって、 以降は素通りした可能性だってある。
私が思うのは常に出会ったことや教えてもらったことを咀嚼するのは、 今の自分じゃなくて、あくまでその時点の自分だってことですね。
実は小学生時代、担任不在の時に一度だけ教頭先生が突然教室にやって来て 代理で授業をしてくれたことがあって、その時に勉強の仕方という内容で、 学ぶ力を身に付ける方法について話してくれたことがあった。 おそらく大学の研究室に入るまでで最も高度な授業だったと(今の自分は)思う。
でもそのことはずっと忘れてて、研究室でゼミをやっている時に フラッシュバックの様に思い出して、あー、あの教頭先生が言ってたのは、 この事だったんだ!って思ったことがある。
きっとあの教頭先生は子供が教師に頼るのではなくて、 自力で全く新しい何かを学ぶ力を身につけることは可能だって 本気で信じてたんだろう。
あれはもっとずっとさりげない刃物だったけど、案の定私には見えなかった。 ちょっと奇妙な授業だったといった程度の印象だった。
Paul Graham の講演について言えば、多分ほとんどの高校生達は同じことでは無いが、 きっとどこかでこういう刃物に出会っているはずだ。ってこと。 ただ、これにズブリと刺されて真意を理解できるかっていうと・・・
私の高校時代にも『学校の勉強なんてクソだ』って言葉は 決して新鮮でもなんでも無かったし、 成功者が『とにかく好きなことをやることで成功したんだ』って経験談は、 当時もあったはずだ。
(もちろんそれ以上に学校の勉強をしっかりやれって主張はずっと多かったけど)
Paul Graham の主張が、そういった主張と同じだって言ってるんじゃないよ。 新しい主張かもしれないけど、刃物だっていう点で同じだと思う。 それを当時の自分は刺された事にすら気づいてなかったんだ。 当時の自分は『それはキレイ事さ』って思ってたんだね。 同じことが多分今の自分と10年後の自分の関係にも言えるんだろうな。cut-sea
(2005/01/17 17:40:39 PST)
yomoyomoさんとこより、 メンテナンス可能なコードの書き方、およびその関連で Great Programmers。 良いコードとは、つまるところ適切なカプセル化とユニットテストにある、という 主張には基本的に同意。
ただ、「カプセル化 encapsulation」はオブジェクト指向界隈で「実装の隠蔽」 の意味で使われることが多いような気がする (例) ので個人的には避けたい用語だ。本当に重要なのは、(a)あるコードの変更が 影響を及ぼす範囲が容易に確定できること、(b)あるコードの意味に影響を 与える範囲が容易に確定できること (両者は同じことの表と裏だが、実際に コードをいじっている時には両方を考慮している)、であるはずだ。 私はこれをモジュラリティと呼んでいる。
実装の隠蔽はモジュラリティを実現する一つのツールだが、必要でも十分でもない。 実装を完全に隠蔽してもモジュラリティの低いコードはいくらでも書けるし、
実装を隠蔽しないでもモジュラリティの高いコードは書ける。うっかりミスを 防ぐ意味では有用かもしれない、という程度だと思う。 しかも、本当に厄介なバグは実装の隠蔽だけでは防げないような種類のものだ。
モジュラリティにとってより重要なのは、状態の管理だ。 何かが状態を持ち、そのふるまいが状態によって変化する場合、 あるコードの意味はそのコードの静的なスコープだけでなく、 対象となるものの状態にも依存する。静的に確定できるスコープの 外でそのものの状態が勝手に変えられてしまうと、もはやコードの 見た目を信頼することができない。
実装の隠蔽によって状態をさわれる箇所を限定することでこの問題は ある程度軽減できるが、それは対症療法にすぎない。例えばpublicな getterとsetterを用意してインスタンス変数を隠蔽することは この問題に対してほとんど何の解決にもなっていない。 もう少しソフィスティケートされたAPIを用意したとしても、 実装者の想定した方法以外でオブジェクトの状態を変えるパスがどこかに 存在する限り、問題は残る。
本当の問題は、状態を持つことそのものにある。ただ、現実の世界が ステートフルである以上、そことつき合うプログラムもまた状態を 持たざるを得ない。状態という猛獣をいかに飼い慣らすかという視点で 設計を行うべきだろう。実装の隠蔽も、状態を常に実装者の想定に 従うように管理するという目的で使われる場合には、有用だ。 もっとも、状態遷移が明示的にAPIの一部になっていることの方が重要で、 カプセル化はその安全ネットを提供するにすぎないと思うが。
形式的に状態を制御して扱えるようにするには、現実的には 静的型が必須のように思える。(Schemeでモナドを書いても Haskellのように綺麗にならない。) ただ、そこまでやらなくても いくつかのアドホックなテクニックを使うことで、 かなり安全に状態を制御することはできるだろう。
(2005/01/10 21:37:46 PST) 言語のコアが単純であることの効用
「良いデザインは再デザインである」(Paul Graham)---これは言語そのものの デザインではなく、処理系のデザインにも言える。とりあえず動くバージョンを 作って、それを実際のアプリケーションで使ってみて、そこでの観察をもとに 処理系を改善してゆく。このサイクルを多く回せば回すほど、実装は良いものに なってゆくはずだ。また、色々なアイディアを思い付く端から実装してみて 試してみる。それが簡単であればあるほど、その中から実際に使えるアイディアを 拾いあげやすくなる。
だとすれば、処理系のリライトがやりやすい方が、良い実装へと収束しやすいだろう。 言語が、少数のコア要素と、その上に構築される要素からなっていれば、 言語のフルスペックを保ったまま、コア部分やその上の各コンポーネントを独立に 差し替えて行くことができる。これは処理系をごっそり書き直すのに比べて ずっと敷居が低い。
(コア要素の上に構築する要素は必ずしも実行時のレイヤリング、つまり ライブラリを言語のコアオペレータで書くこと、を意味しない。 構文糖衣をメタプログラミングで追加するような場合、レイヤリングは コンパイル時のもので、実行時性能には影響を及ぼさない)
もっとも最初から全てを考慮したインタフェースをモジュール間に作るのは 難しい。やってみないとわからないことがたくさんあるからだ。 時には、インタフェースを保つために変更する側のモジュールに醜いスタブを 噛ます必要も出てくる。ただ、対応するモジュールも十分に速く改善できて、 結果としてスタブがすぐに外せるのなら、大した問題ではないだろう。
最適化はモジュラリティとぶつかる場合がある。モジュラリティは一般化を指向するのに、 最適化は特殊化を指向するからだ。せっかくきれいにレイヤを切ってモジュール化 してあっても、最適化は複数のレイヤに変更を強いる場合が多い。 これについては、最適化をオプショナルにしておくこと (何かのフラグで切ることができるようにしとく)くらいしか思いつかんなあ。
(2005/01/08 01:37:10 PST)
TPOSSCON 2005. へー、Bruce Perensがハワイに来るんだ。 ちょっとのぞいてみようかな。
rio orange