Shiro

Schemeを愛するプログラマ。

Practical Scheme

http://practical-scheme.net/

Island Life

http://www.lava.net/~shiro/

メモ：Shiro:芝居関係, Shiro:BeginningActing, Shiro:ActingForAdults, Shiro:AdvancedActing, Shiro:ActingForTheCamera, Shiro:AuditionRecords

過去：Shiro:log:2002, Shiro:log:2003前半, Shiro:log:2003後半, Shiro:log:2004前半, Shiro:log:2004後半, Shiro:log:2005前半, Shiro:log:2005後半, Shiro:log:2006前半, Shiro:log:2006後半, Shiro:log:2007前半, Shiro:log:2007後半, Shiro:log:2008前半, Shiro:log:2008後半

記事：Shiro:UnixUser0307, Shiro:UnixUser0309, Shiro:HackersAndPainters, Shiro:OpenSourceMagazine0606

(2009/10/31 01:39:56 PDT らむ太語録)

なるほど、そういう演繹ができるようになったか。

なるほど、「知ってるよ」はどっちかっていうとI know. だな。

(2009/10/23 01:09:12 PDT)

Proposal: Moratorium on Python language changes

Schemeならそんな心配しなくても次の仕様が出るのは数年後だっぜ。

ずーっと議論してるけど誰も譲らないから、みんな議論に疲れ切るまで決まらないのだ。

(2009/10/22 01:55:00 PDT トップレベル式)

天泣記2009-10-19 (Mon)

ありゃ、なんか誤解してるかな? 

    gosh> x
    *** ERROR: unbound variable: x
    Stack Trace:
    _______________________________________
    gosh> (car (begin (define x 1) '(1 2)))
    1
    gosh> x
    1

あーそれはGaucheの手抜きです。R5RSでは不正な式に対して エラーを通知することは要求されてないので、 「こんな式書かないだろう」と私が勝手に思ってる不正な式については不定な動作をします。 その動作が将来にわたって保たれる保証はありません。

あんまりエラーチェックに熱心じゃないので、「Schemeではどうなるか」 というリファレンスとして使うのに良い処理系じゃないです。 仕様書を見てもらうことが一番確実ですね。

(2009/10/18 10:40:30 PDT begin)

天泣記2009-10-19 (Mon)

ここで思ったのだが、Lisp ではなんで prog1 や progn (Scheme なら begin) は関数じゃないんだっけ? 引数の評価順序が決まってないから?

では、引数の評価順序を決めてしまえば普通の関数にしていい?

効率?

ちょっと考えてみたんだけど、順序と効率以外にSchemeの場合、次の点が問題になりそうだ。

CLの場合は末尾再帰が要求されてないし、多値の受け取りの条件も緩いので、 問題になるのはprognの最後の式が2つ以上の値を返す場合のみかな?

まあ現実問題として、(prog1 exp0 exp1 ... exp100) なんて式でprog1が 関数だと、100個分の結果を必要もないのにどっかに貯めておくなんてもったいない って思っちゃうので、実用上は効率が一番気になるかもしれん。

(2009/10/16 21:10:53 PDT Chaton-Twitter bridge)

うまく動いてるみたいだし、思ったより便利なので、こっちでも宣伝しとこう。

Lingr閉鎖に伴ってGauche部屋他の避難所として作った チャットChatonだが、 要望があったのでtwitterとのブリッジを動かしてる。

chaton->twitterの方はcometで通知するんでほぼリアルタイムだけど、 twitter->chatonは1分おきのポーリングなので多少ラグがある。 あと、twitterとのアクセスに失敗した場合のリトライとかやってないし、 こっちの都合でブリッジを落とすこともあるので、完全に信頼できるものではない。 ただまあ、フォローしとくと発言がまとめてウオッチできるのは便利。

あと、今の流量だとAPI制限にはまずひっかからないので何も対策してないけど、 突然ポピュラーになったらひっかかるかも。

ソースはsf.netのリポジトリ中のexamples/chaton-twitterに。 この手のスクリプトのサンプルにもなるかと。 ただしGaucheのsvn trunkが必要。最近足した機能を使ってるので。

(2009/10/09 22:51:13 PDT らむ太演技録)

らむ太は時々ちょっと熱を出すんで、大事をとってプレスクールを休ませることがある。 「風邪引きはおとなしく寝てなさい！」と言っても全然聞かないんだけど。 今日もそんな日。

そんな演技を教えた覚えはありません。

(2009/10/08 20:58:14 PDT らむ太語録)

プレスクールで何を言われてるのか想像がつくぞ、らむ太よ。

(2009/10/05 02:47:22 PDT 登場人物の気持ちを述べよ)

国語ネタを出したついでに。「この(台詞|行動)に込められた登場人物の気持ちを述べよ」 みたいな問題は「国語のわけのわからなさ/無意味さ」を示す例としてよく槍玉に上がるけれど、 この問い自体は無意味でもわけわからないものでもない。その証拠に、 今この瞬間にも、この問いを仕事の一貫として真剣に考えている人が たくさんいる。これは役者が脚本を読む時に必ず向き合う問いだからね。 役者に限らず、フィクションを咀嚼して自分の栄養として吸収したいなら、避けて通れない問いだ。

教科としての国語がうまくいってないとすれば、それはこの問いが悪いんじゃなくて、 大事な前提をちゃんと言ってないからだと思う。それは：

ってこと。唯一の正解が無いからといって、何でも答えればいいとか考える意味がない ということにはならない。どういうのが不正解かっていうのは、理屈で説明できることも あるし、説明しにくいこともある。でも映画や芝居をみて登場人物の行動が 嘘くさかったり、登場人物に関心を持てなかったりしたら、それは役者が正解を当ててないことの かなり良いインディケータだ。観客は、たとえ役者がたどりついた「解」そのものが 何かをピンポイントで理解しなくても、その「解」が正しいか間違っているかについては 恐ろしいほど敏感に反応する。

学校の試験という場においては、明確な採点基準が必要とされるために、 この問いの意味が歪められてしまっているのだろう。よく「出題者の意図」がどうこう 言われるが、あれは採点のために「無数にありえる正解のうち、 特定のもの以外を排除できるように仕込んである不自然な仕掛け」を見抜くって話であって、 問いの本質とは離れてしまっているのだ。

問いの本質とは。これもまた、国語の授業ではっきり教えてくれれば良いのに あんまり教えてくれない事実である。

このことを知らずに、どこかに正解があると思ってる生徒にとって、 国語がわけわからなくなるのも無理はない。

テキストは、木の塊の表面に記されたスケッチだ。この問いに答えることは、 そのスケッチの線に忠実に沿いながら、立体像を掘り出すという作業になる。 元のスケッチの制約を満たす立体像は無数にありえるだろう。そのどれもが 正解なのだ。もっとも、「素直」に掘ってみたら大抵の人がたどり着くであろう 形というのはあって、それが回答として挙げられるにすぎない。 (高校の現代国語の試験で、私は時々「ひねくれた、しかし筋の通る解」を ひねり出して答えていた。教師もそれを面白がって満点をくれた。 国語が面白くなったのはそれからだ。)

あ、あともう一つ、国語で陽に教えてくれないけれど大事なこと。

今日もラジオ番組向けに数人の役者で短篇小説を読む公開録音を やってきたんだけど、その小説の作者本人が観客席にいて、 「こんなにおもしろい話だとは思わなかった」って感想をもらしてた。 役者がたどり着いた解釈が実は作者も想像してなかったことだったってのは、 かなりよくあることだ。でもそれで良いのだ。"whatever works" と良く言うのだけれど、 不正解でない限りどんな解釈でも許されるし、むしろ作者も自分の 想像を越えた解釈をされることを望んでいるだろう。そうなることが、 作品が作者の手を離れて自立した証なのだから。

(番組は12/22(火)と12/29(火)の2回に分けて、18:30から KIPO (89.3FM)でオンエア。ストリーミングもあるみたい。 詳しくはAloha Shortsのページに。)

(2009/10/04 02:02:25 PDT 空気読み会話は日本人の専売特許じゃないよ)

国語を勉強すると空気が読めるようになる？

習った当時はなるほど、と感心したものだが、20年近く経って改めて思い出してみると、まったく恐るべきハイコンテクストというか、空気読み会話である。時計の箇所など、発される言葉のすべてにメタメッセージが載せられている。人間同士が会話のキャッチボールをしている背後で、スタンド同士がドドドドドドドと擬音つきで殴りあっているようなもの。西洋人にはおよそ理解できない、いかにも日本的なやり取りだろう。

その作品を読んだことはないのでもしかすると想像を絶する空気読み会話なのかも しれないけれど、一般的に言えば、会話文にメタメッセージ(subtext)を 載せるのは現代のテキストなら洋の東西は問わず普通のことで、 上のブログで紹介されている作品も解説を読む限りでは 「西洋人に理解できない、日本的なやりとり」であるようには見えない。

近代以降の戯曲やシナリオを読む場合は「登場人物は本音を台詞では語っていない」と いうのは出発点であって、良くできた芝居や映画では(たとえ「ハリウッド映画」で あろうとも良作なら)全ての会話シーンは「人間同士が会話のキャッチボールをしている背後で、 スタンド同士がドドドドドドドと擬音つきで殴りあっているようなもの」と言ってよい。 だってそう作ってるのだから。

しばしば英語圏での会話には腹の探り合いとか空気の読み合いが無いと思われる ことがあるが、それは異なる文化を持つもの同士が、 コンテキストを共有していないという自覚がある場合に、 敢えてノーコンテキストでストレートな会話をしているだけだ。 英語文化圏や英語文学自体に日本文化圏や日本文学に比べ コンテキストや空気の読み合いが欠如しているわけではない。 「わかりやすい」ハリウッド映画やsitcomは、 気楽に観れるようにわざとそう作っているってだけにすぎない (それが視聴者を適切に扱っているのかどうかは別。 なおsubtextの欠如という点では日本のテレビドラマの多くも どっこいどっこいに見える。)

(2009/09/25 15:30:37 PDT プログラミング言語の進化)

プログラミング言語の進化の方向

プログラミング言語の歴史を眺めていると、経験の中から立ち現れるベストプラクティスを取り込んだものが多いことに気がつく。

言語の進化はベストプラクティスをサポートするためにあるんじゃなかろうか。

そういったケースが多いのは確かだろうけれど、それだけ見てるとまずいと思う。

言語というのは表現の道具であって、動作するプログラムを表現するには 言語を使うしかない。では、これらの「ベストプラクティス」が言語に 取り込まれる前には、どうやって表現されていたんだろう?

  1. 他の機能を組み合わせて無理やり表現していた (e.g. CによるOOP)
  2. プログラムとして表現するのを諦めて、自然言語で表現してプログラマが逐一実装してた (e.g. デザインパターン)

どちらにせよ、これは表現として不自然だ。 そのプラクティスが有用であることが既にわかってるなら、 不自然な表現でも何とかそれを使おうとして、やがてそれが広まり 言語にサポートされることになるわけだけれど、そもそも最初に そのプラクティスを始めようと思った人達は、どうやって その不自然な表現を乗り越えたんだろう?

例えば、内包表記は便利で、いろんな言語が採用し始めているけれど、 多くの言語は他の言語の内包表記を見て便利なことを知って採用したんだと思う。 内包表記のおおもとの起源は数学記法だけど、「これを プログラミング言語に取り込んだら便利だろう」と最初に思って 実行した人がいたはずだ。その時点では、内包表記は 「経験の中から立ち現れるベストプラクティス」ではなかったはずだ。 だってプログラミングで内包表記を使うという経験はそれまで無かったわけだから。

あるいはスタティックスコープ+無限エクステントでもいい。 スタティックスコープは前からあったけれど、それを無限エクステント にしてlambdaがクローズするようにしたら、funarg問題があっさり解決しちゃった。 でもSchemeがそれをやってみせるまで、人々はfunction特殊形式みたいな アドホックな方法でfunarg問題を解決しようとしてたわけで、 決してスタティックスコープ+無限エクステントがベストプラクティスと みなされてたわけじゃない。

つまり、プラクティスの中には、「実際にその言語機能を使って書いてみるまで それがベストかどうかわからない」というものがある。

代替の表現方法が「ちょっと面倒くさい」程度ならまだ、その手間をかけて まわりくどい方法で書いてみようという人はいるだろう。けれど、今ある言語機能では 実現するのが非常に面倒くさい、実現できるかどうかもよくわからない、 というプラクティスについては、よっぽどモティベーションが高くない限り、 遠回りな方法で今の言語上に実現してみようとは思わないはずだ。 ベストプラクティスを取り込むという点だけ見ていると、そういう妙な アイディアを見逃すことにはならないだろうか。

逆に、ベストかどうかわからないけど、妙なアイディアを思いついたら 気軽に言語の方を変えてそのアイディアを表現できるようにしてしまう。 そしてそれを使ってみる。うまくいけば広めればいいし、ダメならスクラップすればいい。 そういう過程もまた、言語の進化には重要だと思うのだ。

(2009/09/21 21:00:24 PDT らむ太の質問攻撃)

噂には聞いていたが、これが質問攻めというやつか。

めちゃくちゃペースが速いのでちゃんとした答えを考えてる時間がない。 反射能力が試される。

(2009/09/20 13:51:09 PDT SICPのSchemeコード)

書こうと思ってたネタなんだけど別のところ で書いたのでこっちに転記。

SICP is a really good book to learn what is abstraction in programing, but keep in mind that it intentionally uses very limited range of features of actual Scheme to achieve its goal---here by "actual Scheme" I mean Scheme that is used to write real programs. Some people seem to get an impression from SICP that Scheme is minimalistic and you have to write your own structure or object abstraction using cons cells and closures, and conclude it is not a practical language you can use in your jobs.

Any modern Scheme implementation, in which you can write code at work, consists of not only the standard core language (RnRS) but also a large body of SRFIs (a kind of common libraries) and implementation's extensions. Unfortunately the extension part is fragmented among implementations, but in general, any decent implementation is far from "minimalistic" and comes with rich tools. SICP tells that Scheme allows you to make your own abstraction, but that doesn't mean you have to make ones every time.

「SICPはSchemeを学ぶ本ではない」という理由はこれね。プログラミング言語についての 説明を最小限に止めたいためにSchemeを使ってるのだから、Schemeの機能のうちでも 説明に必要な最小限の機能しか出てこないよ、ということ。

もちろんその最小限の機能を組み立てて色々できちゃう、ってところが醍醐味で、 それは知ってないとならないんだけれど、現場のSchemeコードを書く時も 小さなコアから全部自分で組み立てるなんてことはしないってこと。

(2009/09/08 03:20:17 PDT らむ太のうた)

時々、一人で遊んでいるときにらむ太が歌っている歌。 どこかで覚えてきたのか、それとも自分ででっちあげたのかはわからん。 

あたま、あたま、あたまのなかを、よっくっ見ったっらー
のーみそが、あるぅー

おくち、おくち、おくちのなかを、よっくっ見ったっらー
のーどちんこが、あるぅー

おなか、おなか、おなかのなかを、よっくっ見ったっらー
いぶくろが、あるぅー

おしり、おしり、おしりのなかを、よっくっ見ったっらー
どぅーうが、あるぅー

たいやき、たいやき、たいやきのなかを、よっくっ見ったっらー
たいやが、あるぅー

「たいやき」の項だけ言葉遊びになってるのが謎。

(2009/08/30 17:22:23 PDT おわーったー)

2日連続で自分の発表があるイベントはきつかったかなー。 他の発表をじっくり見ている余裕が無かった。

いや、その理由はひとえに準備不足なんだけどさ。2つ発表するなら2倍の時間を取らなきゃ ならないのに結局加速曲線がいつもと同じ感覚だったからなあ。

lltvでやったCiSEのネタはわりとウケたようで良かった。 実際にCiSEで書き直したlsのソースは、lltvのサイトに置かれるであろう 発表資料の中に一式含まれてる。ただしビルドには本日時点のGauche trunkが必要。

天下一の方は、20分でやるには大きすぎるネタを選んでしまったというか、 エッセンスを凝縮する技量が自分にはまだ不足していたというか、 そんな感じで時間大幅超過のうえ観客の大部分を置いてけぼりにした感がひしひしとしていて反省中。 次はもっとうまくやる。どういう機会があるかわからないけど。

(追記2009/08/31 00:15:46 PDT): 天下一の発表直後にshi3zさんから "Beating the Averages" を「普通のやつらの上を行け」と訳したことについて話題を振られたんだけど、 ちょっと燃え尽きててうまく返答できなかった。ので書いとく(shi3zさんここ 見てないかもしれないけど)。

Paulの文章はリズムが良いので、訳でも、題名とか決めの文ではリズムに 気をつける。"Beating the Averages"は「強弱弱強弱弱」という リズムで、これは英語では典型的。対応する典型的な日本語のリズムといえば 四拍でしょ、というわけで 「ふつうの / やつらの / うえをゆ / け」 とした。「人」や「人たち」「人々」だとこのリズムに合わない。 「やつら」は強すぎる懸念もあったけれど、リズムに合うことと、 内容が挑発的なのでまあいけるかなと思って選んだ。

なお、リズムでつけた邦題はほかにもある。

ほんとは本文のリズムももっと考えるべきなんだけど、 感覚的にながしちゃってるところがある。今読み返すとリズムが 良くないところが目につく。

(追記2009/09/06 02:31:55 PDT): CiSEの資料、LLTVのサイトではスライドだけのようなので コードも含めたtarballを http://practical-scheme.net/vault/lltv-shiro.tar.gz に置いときました。

(2009/08/28 02:43:16 PDT らむ太と電話)

らむ太と電話すると、描いたものや作ったものを一生懸命 見せてくれようとする。「これ」「これ」と電話口で言ってるんだけど もちろん見えない。「見えないよ」というと、受話器の角度とか色々工夫して なんとか「見せよう」と頑張ってるらしい(かみさん談)。

(2009/08/25 03:38:59 PDT recording)

自分の演技や演奏を録画/録音して後から観る/聴くと、主観的には わからなかったことがいろいろ見えてとても役に立つ。

若い頃は欠点が見えすぎて録ったものを見るのに抵抗あったんだけど、 あれはたぶん自分に幻想を抱いていたせいだね。だから録画で 自己イメージとのギャップが見えちゃうのが嫌だったんだろう。 歳のせいか経験のせいか、今は「まあこんなもんか」という心境になり、 距離を置いて冷静に見られるようになった。人に見せるのも抵抗なくなったし。

ただ、しばらく前に気づいたのだけれど、何度も繰り返し見ていると 欠点がだんだん見えなくなる。最初の見た時はトチってるところや リズムが乱れているところ、あるいは出るべき旋律が埋もれているところ などがはっきり気になるのだけれど、数回繰り返すとそういう箇所を 覚えちゃうから、見ながら欠点部分がくることを期待して脳内で補完 するようになるらしい。リズムの乱れなどは、きちんと刻まれることを 期待してるところで乱れるからひどく気になるんで、どう乱れるかわかってて その通り乱れるとあんまり気にならない。埋もれた旋律も、そこに注意すれば 聞こえるので、期待して聞くようになっちゃう。 そうなると、批判的に見ることができなくなる。

自分の表現の改善を目的として録ったものを再生するのは、せいぜい 2〜3回に止め、最初の印象を大事にするのが良さそうだ。

(2009/08/22 00:04:42 PDT 楽日)

Mai Poina公演終了。野外で演技するのはたいそう気持ち良うございました。

宮殿の正面階段使って芝居する機会など最初で最後だろうなあ。

(追記2009/08/22 15:29:32 PDT): 観客の人が撮ってくれた写真

(2009/08/19 12:46:03 PDT 冠詞)

ネイティブな英語話者にとって冠詞と名詞の関係は、冠詞の方が主で名詞が従である、 って言ってたのってマーク・ピーターセンだったっけ。

冠詞の使い方で意味が変わる場面も少なくはないので、非ネイティブな英語話者として、 英語を喋る時には「冠詞チェッカスレッド」が自動的にバックグラウンドで走る 習慣ができてしまった。思考は名詞中心に考えちゃうんだけど、チェッカスレッドが それをチェックしていて発語の手前に介入して適切な冠詞を入れる感じ。

ところで今日から本番の「Mai Poina」でこんなやりとりがある。

Suzukiが私の役で、Iolani Palaceにリリウオカラニ女王を訪ねてやってきた。 なので最初のせりふは文法的には "Where is the Queen?" が正しいのだけれど、 日本人移民で英語が不自由という設定なので"the"を抜かしてしまう。

Interpreterはネイティブ話者で、"the"がついていないので一般名詞だと 思い、Queen Streetを探しているのか、と聞き返す。

これが、せりふをさらってる時にはちゃんとできるんだけど、 役に入ってせりふが自動化されてくると "Where is the Queen?" と言ってしまうので往生した。 直前まで"where is queen, where is queen..." とさらってても 場面に出ると"the"が入ってしまう。 冠詞チェッカスレッドが勝手に動き出して"the"を入れてしまうらしい。 "the"を入れてしまうと"Queen"が女王を指していることが明確になってしまうので、 次の"Queen Street?"というInterpreterのせりふがありえなくなってしまうのだ。

昨日のゲネでやっとちゃんと言えたので、本番は大丈夫であることを祈ろう。

(2009/08/12 11:51:38 PDT いろいろ)

おお気づいたらもう八月も半ばではないか。

先々月末から先月頭にかけてはShibuya.lisp テクニカルトークに帰省と出張の日程を合わせて、 初参加。動画も上がっているのでご覧のほどを。 毎度だけど小黒さんのプレゼンのレベルが恐ろしく高い。見習わなければ。

Shibuya.lispの運営メンバーには感謝。コンスタントに発表の場があるという ことはそれだけですごいことです。場があると、じゃあ何かやってみようっていう 動機になるし。

それから何してたっけな。こっち戻って2週間くらい仕事対応で忙殺されてたような。

そんで今月頭から1週間SIGGRAPH。New Orleansは2000年以来。あの時は GSCubeでFF Movieの1シーンをリアルタイムでレンダリングするデモを やったんだった。髪の毛は確か6000本くらいのline segmentを anisotropic specularつけてセルフシャドウ無しで描いてたんじゃなかったかな。 今や500000本をdeep shadowでGPUで描ける時代。隔世の感があるのう。

この後の予定。

(2009/06/22 02:02:12 PDT らむ太語録)

寝ていたはずのらむ太が "Hey, sir, we're in trouble, trouble" と言いながら廊下を駆けてきた。

らむ太は夢を日本語と英語のどっちで見てるんだろう? (たぶん夢の中の登場人物によるんだろうけど。デフォルトとして)

(2009/06/21 21:25:55 PDT 仕組みを維持すること)

あ、そうそう。思い出したので忘れないうちにメモ。

オープンソースの肝はシステムにある、 他の分野に応用しようとしてうまくいかなかったらそれは参加者ではなく システムの不備だから直せばいい、というようなことを繰り返し書いてみたのだけれど、 Paul GrahamがやっているHacker Newsは そのひとつの実践例になってると思う。

ああいうコミュニティベースのシステムというのは、最初にコアなユーザが集まって いるうちは質が高く保たれるけれど、次第に人気が出て参加者の裾野が広がって来ると 揚げ足取り合戦や人格攻撃が始まったりと、だんだん議論の質が落ちて行く傾向がある。

で、Paul Grahamは 「それは必然ではなく、システム的な不備であって、工夫によって防げる」という命題を 証明する実験としてもHacker Newsを位置付けていて、たびたびシステムをいじって 反応を見たり、別の方式を提示してみたりということをやっている。 実装してみたけど結局引っ込めたアイディアもある。 そのシステム、例えばスコアリングの方法などはオープンになっている (arcのソースに含まれている)。

一方でHacker Newsには人間の編集者も介在していて、ふさわしくない 投稿のタイトルを直したり、あまりにサイトの性格に沿わない投稿は没に したりしている。その判断は最終的には編集者の主観なんだけど、 そういう主観が介在することを隠そうともしていない。主観もまた、システムの一部なのだ。

そして今のところ、Hacker Newsでの議論の質は保たれている。 「自発的に」うまく回っているように見えるシステムの舞台裏では、 裏方が走り回っているものだ。

(2009/06/21 03:58:35 PDT ソフトウェア開発以外の分野でのオープンソース?)

( essaさんに触発されてちょっとがんばってみる)

オープンソースソフトウェア(OSS)界隈では、 たくさんの人が自発的に協力し合って今までにないスピードで 営利企業が成し得なかったことをやっちゃう、みたいなすごいことが起きてて、 だからソフトウェア開発以外にもオープンソース的手法を使ってそういう「いいこと」を 起こそうって考える人たちがいる。

そういう人たちに、ひとつだけ注意して欲しいのは、目に見える手法---たとえば プロセスをオープンにするとか、誰でも参加できるようにしてネットで広く協力者を 募るとか---だけをコピーしてもうまくいくとは限らないよ、ということ。

OSS界隈で「いいこと」がたくさん起きたのは、 オープンソースの中に、ハッカーという人種の気質をうまく利用して ソフトウェア開発という目的に向けて自発的協力を引き出す仕組みが内包されていたからだ。 (詳しく知りたい人はノウアスフィアの開墾を読むといい)。

この仕組みは、目に見える明文化された方針よりもずっとずっと強固に、 ソフトウェア開発に特有の性質や文化と結びついている (たとえば、ソースがあれば実際に動作するプログラムを誰でも作れること、 不満があれば自分で改良できること、 プログラムが動作するかしないかは客観的に判定できること、 全体としてのゴールはより良いプログラムを手にすること、などだ)。

だから、こういう性質を持たない分野に、OSS界隈で使われている 手法をそのまま適用しても、うまく動く保証はない。 たまたまうまくいくこともあれば、うまくいかないこともあるだろう。

他の分野で、OSS界で起きてるのと同様な現象を起こしたかったら、 真似るべきはオープンソースソフトウェア開発の表面的な手法じゃない。 対象分野における参加者の性質と、成し遂げたいゴールを分析して、 OSSがやったのとパラレルになる、その分野特有の「仕組み」を考えることだ。 そして、その仕組みを実際に動かしてみることだ。 思うように動かなかったとしても、それを環境のせいにしちゃいけない。 その環境で「いいこと」が起きるようにできていない「仕組み」の方に 問題があるのだから、うまく動くまで、問題を直して何度でも挑戦しよう。

たぶん、そうやって出来上がったものが、ソフトウェア界における オープンソースの遺伝子を継いだ、別の分野でのオープンソース的な何かに なるんじゃないかと思う。

(2009/06/19 20:45:38 PDT オープンソースの罠)

http://zunda.tumblr.com/post/126168985

“オープンソースは、「有志がオープンに協力してなし遂げる」という以上にラディカルなものです。参加者よりも、成果物の自由を重視します 梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを blogのshiroさんのコメント - それはオープンソースソフトウェアじゃなくてフリーソフトウェア？というわけでもう一度勉強しなおしてくる。Why “Open Source” misses the point of Free Software

「オープンソース」がわざとラディカルな思想面をぼかしているのは 確かだけれど、Open Source Definition(OSD)を読むと「自由な改変と再配布を保証して、ソフトウェアがevolveするチャンスを 最大化する」というふうに作られてるのがわかる。

OSDが巧みなのは、OSDを採用する人がどういう意図を持っていようが、 OSDを採用しさえすれば(＝正しい意味の「オープンソース」にすれば)ソフトウェアの 自由が保証されることだと思う。善意で利他的な情熱に衝き動かされて貢献する 人ばかりでなく、ハッカー界で有名になりたい・履歴書に書ける開発実績を作りたいとか、 ライバル企業を蹴落としたいとか、他人の書いたプログラムをただで使って金儲けしたいだとか、 自分の興味を満たすために作ってみたけど保守まで面倒見きれないよ、って人まで、 その思惑のいかんにかかわらず、OSDを採用したとたん、コードはその意図を 離れて進化する自由を得てしまうのだ。一種の罠のようなものである。

これはまあ、フリーソフトウェア陣営から見れば魂を 抜くようなもので、日和ってると言われても仕方ないわけだし、実際、 そうやって思想面をぼかしたために誤解が広まっているという現状があり、 それもまたフリーソフトウェア陣営から見たら「ほらみたことか」ってな ものだろう。

でも、私はこの「悪意だろうが善意だろうが関係なく、システムによって好ましい方向に 誘導してしまう」という設計は技術者としてとてもうまいハックだと思ってしまう。 価値観なんて人それぞれですり合わせるのに多大な労力を必要とするし、 やっとコンセンサスを取ったって人間ってのは気まぐれだから明日どうなるかはわからない。 善意が正しい方に向くとも限らない。 善意や自発的協調の表出を前提とするシステムは脆いのだ。 頑健なシステムはこれらを前提としないでも回るものでなければならない。

これは善意や協調が役に立たないと言っているのではない。 むしろ、善意や自発的協調は行動をドライブする貴重なエネルギー源である。 うまいシステムは、上記の頑健性をクリアした上で、 善意や自発的協調が自ずから「引き出されてしまう」ようになっている。 最初から善意の自発的提供者を当てにするのではなく、関わる人がいつの間にか 自発的に協調するようになってしまう罠がしかけてあるのだ。

そういうシステムはオープンソースだけではない。でもOSDはかなり慎重に、 上記の頑健性をクリアすることを念頭において設計されていて、 結果として自発的協調が引き出しやすくなっているのは確かだと思う。

だから結果だけ見れば、「オープンソース」界隈に 「世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していく」 ような現象が見られることは不思議ではない。 でもそれは結果として起きている現象であって、それを指して「オープンソース的」 と言ってしまうと大きな誤解を招くことになる。

たとえばこうだ：

http://jbpress.ismedia.jp/articles/-/1216?page=2

サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働き、有志がオープンに協力してある素晴らしい達成をなし遂げるといった公的な貢献──を育む土壌がありません。

上で議論したオープンソースの意味に照らせば、 「オープンソース的」アプローチとは、「陰湿な誹謗・中傷など「揚げ足取り」のような側面」が前に出てきたとしても結果的にうまくいってしまうような システムを作ることを指すべきと言えるだろう。 「有志がオープンに協力してある素晴らしい達成をなし遂げる」ことそのものではなく、 「利害関係者がそれぞれの思惑で行動したら、オープンな協力をせざるを得なくなり、 結果的に素晴らしい達成が成し遂げられてしまう」ようにするのがオープンソース魂なのだ。

オープンソース的協力を阻むのは中傷とか悲観論みたいな感情的なリアクションじゃない。 知的財産権などを盾にとってシステム的な土台を揺るがすような力であるとか、 従業員の私的時間の作業までも拘束するような就業規則であるとか、 システムから目をそらさせるような組織的なFUDが主要な障害なのだ。

その点では、「土壌が無い」なんていうのは障害でも何でもなくて、単に 「こういうソフトが欲しいんだけどまだ無いよね」というのと同じレイヤの問題だ。 それに対する「オープンソース的」な答えは既にある。 「黙ってコードを書け」---欲しいと思ったら作ればいい。 思うように動かなかったら直せばいい。 動かして見せることの説得力が世界を変える。

(追記2009/06/20 12:01:24 PDT: essaさんのエントリがえらくわかりやすい。 成果が永遠にみんなのものであり続ける仕組みも含めてオープンソースという言葉を使おう)

(2009/06/05 19:32:44 PDT 才能と金)

THE BRADY BLOG: 炊事場のスーザン・ボイル - 素晴らしい才能を持ちながら、他に問題を抱えているため その才能を満開に発揮して一線に出ることができず、埋もれたまま社会のほんのひと隅を 支えている人はいくらでもいる。と言うような話。 素晴らしくよく書かれているので私の下手な要約よりも原文一読をおすすめ。

で、このエントリにはもう全面的に共感するんだけれど、ここの部分にちょっとひっかかった：

力のある人を世の中は放っておかない。
というのは、わたしの元上司の口癖だったが、ここでは物凄い能力のある人々が埃にまみれて世間の片隅で忘れ去られている。
とはいえ、“力”というものの中には、きっと“実際の作業をする能力”というのはあまり含まれておらず、自己プロモやネットワーキングを行う手腕といった“作業換金力”が80%から90％なのだろう。

能力がありながら恵まれない生活を送った人の話というのは事欠かないし、 能力のある人よりもその周囲の人の方が儲けていたりすることもままある。 そういう話を見聞きすると、どうにも残念な気分になるし、特に後者の場合は もともとの能力のある人が利用され搾取されているような感じもして落ち着かない。

けれどもよく考えると、ある人がお金を手にする、儲ける、ということは、 誰かが支払っているわけだ。で、自分含め人々が金を払うのはどういう時か、 ということを考えると、「才能」そのものに金を払うということはあまり 無いのではないか。生活必需品を除けば、支出の大部分を占めるのは「利便性」 に対する支払いだと思う。もちろん世の中には自分が不便な思いをしても これと見込んだ才能に投資を惜しまない人はいるけれど、それはやっぱり 珍しい存在だ。そういう人がありふれていたら世の中の芸術家の卵は みんな優雅に暮らしていることだろう。

以前、プロとアマの違いはアウトプットの山の高さではなく、不調な時でも 一定の質が保証されていることだと書いたことがある。結局、人がプロに金を 払うのは(=プロがその技術で喰って行けるのは)、

といった理由が大きいのであって、これらは要するに利便性に金を払っているわけだ。

もちろん需要と供給の関係はあって、才能が極めて得がたいものであれば、 利便性を犠牲にしても欲しいという客がついて取引は成り立つ。けれども そこまで珍しい才能でないとすれば、お客は才能そのものよりも、 その才能が提供される利便性の方に金を払うのだ。

「能力」よりも「自己プロモやネットワーキングの手腕」の方が金になる と言ってしまうとなんとなくアンフェアな感じもするんだけれど、 金を払う側はそもそも能力に払っているわけではないとすれば、 これはもう仕方ないことであって、 何か悪の力が働いてフェアネスが歪められているわけではないのだ。

それでも、素晴らしいものを創り出す才能に何とか報いたいという想いがあるのなら、 それはつまり愛である。そして充分な愛を持っている人は行動を起こすはずだ。 具体的には、才能とそれを求めている人とをうまくつなげる役割を買って出ることだろう。

その役割に、ネットはかなり使える道具になるんじゃないか、と今でも思っている。

(2009/05/29 17:16:05 PDT reliabilityとavailability)

少し前に誰かがどこかで「『信頼性reliability』と『可用性availability』の違いがよく わからない」と書いていたのを読んだのだけれど、今日昼飯を買いに行く途中でたとえを思いついた。

腕が良いと評判だけど人気がありすぎて予約がなかなか取れない医者は 高reliability/低availability。

いつ頼んでもふたつ返事で引き受けてくれるんだけど締切りを平気でブッチするライターは 高availability/低reliability。

ただまあ、インフラに近いサーバのような場合、 リクエストを受けた後で中途半端なサービスしか提供できない、というケースが 想定しにくい (そもそも中途半端なサービスしか提供できないような事態というのは リクエストを受けられない事態とほぼ同じであることが多い) ので、そうすると reliabilityとavailabilityの程度は連動して動くことが多い。 なので区別がつけにくいのかもしれない。

(こういう意味での"reliable"/"available"というのは英語では日常的に使うので 英語圏の人は悩まないと思う。日本語でavailableにぴったりくる言葉ってあるのかなあ。 "Are you available next Monday for a meeting? (来週月曜にミーティングしたら来れる?) とか、陽に訳出することが無いような気がする。)

余談だけど、フリーランスになってわかったのは自分自身のavailabilityとreliabilityの どっちもが大切だってこと。会社勤めだとreliabilityは気にしてもavailabilityを 気にすることは少ない。自分の手がふさがってれば他の誰かを手当てするのが会社の役目 だから。でもフリーランスだとavailableでないということは仕事が取れないということだ。

(2009/05/19 04:41:25 PDT 表現)

私も40の大台に乗ったからなあ。

未来のいつか/hyoshiokの日記 - 40代、50代の人たちはなぜ表現をしないのか

日本という地域では、インターネットを能動的に利用する若い世代（おそらく40前後がその上限）、あるいはヒマ人以外には、表現をする人というのはほとんど現れていない。少なくともわたしと同世代（50歳前後）にはそのような表現をする人はほとんどいない。

このエントリの読み方として、

  1. 40代、50代のひとたちで「表現」する人がほとんどいない
  2. 40代、50代のひとたちは表現しているんだけれど「ネット上で」表現活動を行う人がほとんどいない

というのがあって、吉岡さんの問題意識は表面的には一応後者なのだろうけれど、 なんとなく前提となる意識として「自分の目に届かない表現」を捨象している 印象があって、そのため前者のように受け取って反応している人も多い感じだ。

私の周囲を見回すと、少なくとも前者の命題はほとんど偽であって、 なんらかの表現を行っている40代、50代の友人知人は極めて多い。 ただしここでの「表現」とは広い意味で、先方のコメントにも書いたけれど、 人によっては仕事であったり毎日の献立であったり、あるいは日課の庭の手入れ がそうであったりするかもしれない、というふうにとらえている。

もちろん演奏をしたり画を描いたり演技をしたり映画を撮ったり、という わかりやすい「表現」をしている人もたくさんいる。 けれどもつまるところ、三木清の言うように生活が芸術になることが肝要なのであり、 それはつまり外的要因で自分の行動を決められるのではなく、自分の内的要因で 自分の行動を選んで行くということであり、自分の内的要因から行動を選ぶということは すなわち表現に他ならないということだ。 要するに充実感のある毎日を送っている人は生活そのものが表現なんである。

ブログとやらは情報流通の観点からは画期的な媒体であるけれど、 表現という観点からは単なる一媒体にすぎず、それも表現の形態を革新するような 大げさなものではない。もちろん表現者と媒体のマッチングが重要 なのであって、たまたまブログという形態が自分の表現のカタチに合った人にとっては ブログの登場は画期的であったろう。だからといって誰もがブログによる表現が 合うとは限らないし、ブログで発信していないから表現していないのだ、みたいに言われると 表現媒体としてのブログをそこまで大層に持ち上げなくても良いのでは、と感じる。

いやブログに書いてネットに載せれば広い範囲からフィードバックがあって、 という議論はあるかもしれないが、それは情報流通の観点からの話である。 吉岡さんの不満も、要するにブログみたいな媒体に書いてもらわないと 観客である「俺」が鑑賞できないじゃないか、という不満であろう。 それはわかる。私もいろいろな物語が読みたい。だからいろいろな人が ブログにその人の物語を綴ってくれたら私も嬉しい。嬉しいのだけれども、 それを主として「求めてしまうこと」は観客のエゴ、もしくは本末転倒だ。

例えて言えば、映画DVDのボーナストラックに入っているメーキングや インタビュー、私も大好きなのだけれども、あれが面白いのはあくまで 完成された作品としての本編があって、その補助として入っているからであって、 本編無しのメーキングやインタビューがあっても意味がないでしょう、ということだ。 メインディッシュはあくまで各個人の生活としての表現であって、 ブログに著された「表現」というのは副産物でしかない。

副産物だとしても、やっぱり多くの物語を読みたい。それはそうだ。 ところでドキュメンタリーやらインタビューやらというのは何も本人が 製作する必要はなくて、というか普通は対象となる人以外の人が製作するものだ。 ネット上の発信も、本人が行う必要はないのではないか。表現欲はあっても 表現する中身がない中高生くらいの時に親や身近な働く人たちの仕事を 丹念に追ってみるとか、祖父母の人生を聞き取ってみるとか、 そういう内容がどんどんネットに上がって来たら、そっちの方が面白いんじゃないかと思う。

(2009/05/11 02:41:01 PDT 状態の巻き戻し、Gauche部屋引越し)

少し前の「(2009/04/13 16:28:28 PDT デバッガが使えないパターン)」に井上さんから コメントがついていた。

さすがOcaml、だけど使いにくいのかー。 Gaucheのデバッガも、従来のbreak & inspectにとらわれずに、見たい情報を どうやって取るかってことを考えいきたいのだけれど、どうもケースバイケースで これといううまい手が思いつかない。

ところで10日前くらいにLingrがシャットダウンするとの報があり、 Gauche部屋の空気が気に入っていただけに 残念に思っていたのだけれど、その後Gauche部屋でダベっているうちに何となく 後継となるチャットを作り始めたら おもしろくなって、先週はプライベートな時間をそっちにつぎ込んでしまった。 Lingrほどサービスにコミットするのは大変なので うちで関わりのありそうな部屋だけ細々と運営するつもりだけれど、 コードはオープンにしておくので Lingrちっくなインタフェースが欲しくて自サーバが立てられる人は 選択肢のひとつとしてどうぞ。部屋ごとにCometサーバを立てるという安直な 実装なので何千とチャットルームを運営するのには向かない (でも、Cometリクエストが 別ポートになるのでXMLHttpRequestの同一ドメイン同時接続制限が回避できる かも)。

Gauche部屋は誰でも歓迎です。Gaucheに関する質問などお気軽にどうぞ。 その時見てなくてもちょくちょくチェックするのでいつか返事が返ってくると思います。

(2009/04/24 16:28:27 PDT ソース幻想)

中国政府によるセキュリティ関連製品のソース開示義務が話題になってて、 それじゃ難読化すればいいじゃん、というネタも出ているが、 わざわざ難読化などしなくても例えばStalinの出力のCコードを提出されたら 誰にも読めまい。言語処理系の立場からは、出力がネイティブコードだろうと バイトコードだろうと他言語だろうとやってることは根本的に大した違いは無く、 生成されたコードがCコンパイラの入力になるからといってそれをソースと呼ぶことには 違和感がある。

では実際に人間が書いたもののみをソースと認めるということにすれば良さそうだが、 それが本当に製品のバイナリのソースかどうかということは、処理系を手に入れて コンパイルしてみないとわからない。

ところが世の中には標準の処理系に不満があってマイ言語を作っちゃう人も多く、 DSLまで含めれば「標準の処理系のみ」で完結するものって意外に少ないのではなかろうか。 少なくとも私が今まで仕事で関わったプロジェクトの大半は、標準の言語処理系以外に 何らかの「言語処理系」を必要とする。(例えばautoconfはシェルスクリプトをターゲット とする言語処理系であって、その核はm4だけれど付属するpredefined macroが無いと autoconf処理系としては成立しない)。

そういう周辺処理系も含めて全部提出させればOKかっていうとそうは問屋が下ろさない。 言語処理系そのものはバイナリを許すの? ソース上無害なコードなのにコンパイル時に 怪しいコードが挿入されないという保証は?

よろしい、では言語処理系自体のソースコードも提出させることとしよう。 その全てを精査すれば怪しいコードは検出できるはずだ----ホントに?

言語処理系の多くは、「その言語自身」を使って書いてある。CコンパイラがCで かかれていたり、Scheme処理系がSchemeで書かれていたり。つまり、提出された 言語処理系のソースが本当にその言語処理系のバイナリを生成するかどうかを 確かめるには、その言語処理系のバイナリを使ってソースをコンパイルしてみるしかない。 でも、そのために渡されたバイナリ自体に細工がしてあったら、 ソースが全てを記述しているとは限らない。細工されたコンパイラのバイナリが、 無害なコンパイラのソースからコンパイラを生成する際に細工を忍び込ませることができるからだ (Ken Thompson, Reflections on Trusting Trust)。 「現在のバージョンの」ソースを一式持っている だけでは不十分なのだ。

ではどこまでのソースを持っていれば、確実に検証できるだろうか。 とりあえずCコンパイラとアセンブラくらいは全部自前で作った安心できるものがあるとして。

Gaucheのソースを一式持っているとして、そのGaucheをコンパイルするには 「その時点での最新リリース」のGaucheバイナリが必要だ。 それより古いGaucheバイナリでは、必要な機能が足りずにコンパイルできない 可能性がある。従って、

という具合にどんどんリビジョンを遡ったソースが必要になってくる。 で、これが最初のリビジョンまで遡れば何とかなるかというとさにあらず。 初期のGaucheのビルドにはSTkのバイナリが必要なのだ。 STk自身のビルドにSTkが必要だったかどうかはもう覚えていないが、 もしそうだとすると、今度はSTkのリビジョンを同じように遡ってゆく 必要がある。

この信頼性検証の鎖は案外脆い。Gaucheの開発中に、うっかり一度でも

とやってしまうと、新しくチェックインされたソースをコンパイル出来るのは 私のローカルマシン中のGaucheバイナリだけということになる。 そのまま開発を続けて、新たなバージョンとしてリリースしてしまったら、 検証の鎖はそのリリースで切れてしまう。 実のところ、今までにこのミスをやらなかったという自信が無い。 一人で開発してたら気がつかないからね。

あるいは、こうやって検証の鎖をたどっていったら、今はもう手に入らない ハードウェア上で動作するソフトにつながっちゃった、っていうこともあるかもしれない。

というわけで、ソースがあれば全てわかる、っていうのはまあ間違いじゃないんだけれど、 ソフトウェアの側面だけ見ても、その命題は過去から連綿と積み上げられてきた歴史の 上に載っかってどうにか成立している、案外頼りないものなのだ。

(2009/04/21 19:20:20 PDT 『おくりびと』)

こっちのレンタル屋にも来てたので観た。 そんで、テーマがはっきりしてきれいに様式にはまった良い脚本で、 演技も演出も基本的にはちゃんとそれに沿って作ってて完成度高いなと 思ったのだけれど、批評や感想を観ていたらそのテーマについて全然触れられて いないのであれれと思った。もちろん解釈は色々有り得るし、 私が感じた見方が特殊なのかもしれないけど、 この映画、Actingのクラスでストーリー分析したら綺麗に分析できる部類の 脚本じゃないかなあ。音楽でいえば古典派ソナタ形式、みたいな。

以下、内容に触れるので未見の方は目を細めてスクロールダウン。

-*-*-

この映画を一言でいえば、「主人公が父親を取り戻す」という話。

主人公(大悟)は幼い頃父親に捨てられ、心の底で痛切に父親を求めながら、 全力でそれを否定して生きている。大悟にその自覚はないけれど。 この引き裂かれる思いが物語を引っ張る力。 この二重性のため大悟はいわゆる「父性」--- と言ってしまうとジェンダー的にpolitically incorrectかもしれないけれど--- 自ら決断し周囲を引っ張ってゆき責任を取ること、ができずにいる。 チェロの借金を妻にも黙っていたことや、新しい仕事のことが言い出せないという 大悟の行動はそこから導かれる。この時点での大悟はなりはでかくても中身は 父親を求める子供なので、頼りなく、幼く見える演技は適切。 そういう大悟にくっついてくる妻も自らに母性を 見出せない存在。したがって映画前半で二人がちゃらちゃらしててままごとの恋愛のように 見えるのは、まったく正しい描写である。

NKエージェンシーの社長は大悟にとって父親の役割を果たす存在。 大悟が納棺師という仕事に真剣に向き合うようになったのは、表面的には 社長の厳かな儀式を観て感銘を受けたということだけれど、底に流れているのは 自分の役割を責任を持って果たすという行動を父親から教わっているわけ。 初仕事で社長が怒鳴るでしょう。社長が声を荒げるのはあそこだけだけど、 あれは父親の一喝。

で、妻が妊娠して生物的に大悟は父親になることになる。この時点で大悟の 表層意識はまだ「父親を求める自分」も「それを否定する自分」も認めてない けれど、納棺師の仕事を果たすことでより深いところで責任を取れるまでに 成長している。あるいは成長しつつある。鶴の湯のおばさんの納棺で妻が観るのは、 儀式の荘厳さ(表面)だけじゃなく、大悟の父性。

大悟のarcを考えると、大悟は納棺師の仕事をやればやるほど、 自分の中の二重性に向き合わざるを得なくなる。木下順二は「劇的」とは 「求めれば求めるほど、求めるものから離れて行ってしまう」ということだと したが、やればやるほど見たくないものに近づいてしまう大悟のarcはこの劇的な構造を 綺麗になぞっている。もっとも演出上、クライマックスまでの緊張の高まりは あまり明示的には描かれないけれど。

父の訃報により大悟の引き裂かれる自己の張力は頂点に達し、大悟は 「父親を否定する自己」を捨て「父親を求める自己」を受け入れる。 この受容に納棺の儀式が大きな役割を果たす。それまでのすべての納棺の シーンは大悟が父親を受容する儀式のための前フリである。 そして大悟が父親を受容し、石文を受け取ることで、それまでの納棺の儀式が 「送る者が死を受容し語られぬメッセージを受け取ること」という軸で 貫かれることになる。本木の演技はこの点でも一貫していたと思う。

「父親とのストーリーは余分」という評さえあったが、父親のストーリーがなければ そもそもこの映画は存在しないし、納棺の儀式を厳かに映した意味もなくなる。

ところでこういう解釈で観たとき、ふたつ不満がある。

ひとつは妻役の広末の演技の目的が少し曖昧なこと。 妻は役割上第一のAntagonistだ。AntagonistにはProtagonistと同じ問題を 持つ者と対照的な問題を持つ者が有り得るが、どちらもProtagonistの持つ問題を 別の側面から見せることで物語を明確に語る役割がある。 この脚本の場合、妻は大悟と同じ問題、つまり大人になれないという問題を抱えていて、 それを克服して母親になるという、主人公と同じ形のarcを一足先に描くと考えるのが自然だろう。 脚本上、このarcを際立たせる選択はいくつかあり得ると思うんだけど、どうやっても 実家に帰るあたりまで妻は「子供の顔」をしていて、鶴の湯の葬式のあとあたりでは 「母親の顔」へと変貌していて欲しいはず。監督もそう撮ろうとしているように見えたが、役者が そう思ってやってたかどうかよくわからなかった。

もうひとつは最後のシーンで、大悟が父の化粧を終え、振り向いて石を受け取る時に、 大悟自身の「父親の顔」をきちんと観たいな、と感じた。 もしかすると父親というテーマがくどくなりすぎると思って監督はわざと抑えたのかもしれない けれど、こういう脚本なんだから思い切っていっちゃっても良かったんじゃないかと思う。

-*-*-

以上でネタバレ終わり。

(2009/04/13 16:28:28 PDT デバッガが使えないパターン)

少し前にprintfデバッグかデバッガ使うかっていう話がちょっと 盛り上がっていた (わたしがprintf()デバッグをしない理由から)。 まあ結局は適材適所ということになるのだけれど、どういうケースでは デバッガが(使えない|使いにくい)かっていうケースを集めとくと建設的かも。

shinhさんが ひとつケースをあげていて、これはコンパイラ1が生成したコンパイラ2が生成した コードに出てくる問題を追いかける、というもの。コンパイラ1はしっかりした 処理系でコンパイルされるのでデバッグ情報がついているけれど、コンパイラ2の デバッガ情報を出すべきコンパイラ1はそんなにしっかりしてないので、コンパイラ2中の どこがおかしなコードを出しているかはデバッガじゃ追えない、という話。

以前ここでも書いた、VMへコンパイルする処理系のデバッグにもちょっと似ている。 デバッガで追えるのはVMの動作なんだけれど、それは同じ所をぐるぐる回ってるだけに 見える(レイヤが違う)。まあshinhさんのtccのケースの方は「ぐるぐる回っているVM」 自体が無くなっちゃうのでもっと大変だけど。

あと、私自身がよく当たるケースは、外部コンポーネントと実時間で協調してないと 再現しないようなバグ。ネットワークパケット送ったら一定時間内に返事が来てそれに 返信しなくちゃだめ、とか。パケット送ったあとブレークポイントで止めてると タイムリーに返事が返せないので状況が再現できない。相手も自分の制御下にあれば 多少はなんとかしようがあるんだけど、まったく制御できない第三者の作ったやつと 通信しなくちゃならないことも多いんで困りもの。(吉岡さんもカーネルハックしてたら そういうケースに当たることはあるんじゃないかと思うんだけれど、 デバッガで何とかするうまいテクニックがあるのかなあ。Debug Hacksに書いてあるかな?)

明らかな症状が出る時点では既に痕跡が消えているケース、というのもある。 センサ入力を1/30秒ごとに取って行列演算に使ってるんだけれど、どっかで 演算結果がおかしくなる。本当の原因は数フレーム前のセンサ入力なんだけれど、 はっきりとおかしい結果が出る時には数フレーム前の状態は上書きされちゃってる、とか。 異常が「画面を目で見ればわかる」けれども、数値的にどういう条件でそうなるのか わからないっていうのもよくあるな。1フレームだけポリゴンがパカッとするんで、 目で見てておかしいと思ってすかさず止めても、その時にはメモリは更新されてる。 本当の原因となる条件がわかれば条件付きブレークポイントをしかけられるけど、 そもそもそれがわからない段階でどうするかっていうと、いろんな状態をダンプして にらめっこするしかない。

デバッガにも簡単な条件の元で状態を出力する機能はあるけれど、だいたい こういう厄介なケースってかなり複雑な条件で出力を絞らないと ダンプ量が多くなりすぎて役に立たないことが多い。

外部コンポーネントが関わるケースについては、最終的には外部コンポーネントを エミュレートするプログラムを作っちゃうしかない。 わりとそういうケースが多いんで、私自身の印象として、デバッグというのは 単にprintfやらデバッガを使って潜んでいるバグを探すのではなく、 むしろシステムをうまく作り替えて特定の場所にバグを追い込むようにして、 そこに罠を張って待ち構えているという感覚がある。 デバッガ専門家の方の意見も聞きたいところ。

状態が上書きされちゃうケースについては、理想的には メモリを仮想化してブレーク時から時間を遡れるようになってるのが良いと思う。 言語的には上書きしてるんだけれど、実は別の場所に書いていて 元の内容も保存されてる、という感じ。

逆にprintfが使えないパターンとして私が体験したのは、 ビルドに5分かかるプロジェクト (CPUプールを使ってビルド自体は並列に 進むようになってたんだけど、最後のリンクのところで4分くらいかかっちゃうので あまり効果が無かった)。ところがこいつが、「問題の所在が多数フレームに またがった値の変遷を調べないとわからない」というパターンのやつで、 デバッガも使いづらい。結局、問題が出るコンポーネントだけを 別プロセスで回して、本体からソケット経由でデータを流して処理して 本体に返すという仕組みを作った。当該コンポーネントのビルドは 容易なのでデバッグサイクルを速く回すことができた。

(追記 2009/04/14 12:01:38 PDT): おお、shinhさんから反応が。 Window Managerのデバッグが難しいというのは、 「デバッガが実行時にデバッギの提供する機能を使う場合」と言えるかも。 なんかコンソールゲーム機いじってた時にこのパターンに時々当たったような 気がする。詳しいことは忘れちゃったけど。

(2009/03/24 00:12:26 PDT コードと別にドキュメントを書く意味)

昨日の続き。

国語力とプログラミング力の関係　解説編

異なる意味や構造を持つ2つの言語で同じことを書くと相補的に文章の正確さを高めることができるということだ。ソフトウェア開発の各段階で、コーディング言語以外にいろいろな言語を使うことの意義はそこにある。

私がコードと同時にドキュメントを重視するもうひとつの理由がこれだ。

コードは動かなければ意味が無い。動かすには、実装の詳細に気を配らないとならない。 設計上は「どちらでも良い」選択肢があったとしても、動くコードにするためには どちらかを選ばないとならない。そうやってとにかく具体的に、末端まで目を配っていると、 大局的、抽象的な視点を忘れがちになる。 そこで、実装の詳細の迷路に足を取られて大局的な方向があやふやになってきた あたりでドキュメントを書いてみると、ふっと全体の見通しが良くなったり、 実装の抜けを発見できたりする。あるいはそもそも「ドキュメントがうまく書けない」 ことから、自分が問題をちゃんと理解していないことに気づいたりする。

あるいはこういう考え方もできる。実現したい「何か」は空間上の一点だ。 それを通る直線が無数にあるように、実装も無数にあり得る。たまたま ある実装を選んだとする。ところが、後からその実装を見た人には、 どこが本当に通りたかった点なのかがわからない。ここでドキュメントという もう一本別の直線があれば、その交点として、設計者の意図を明確に 示すことができる。

(ソースコード内にドキュメントを埋め込むのを私が好まないのは、 ひとつにはこれが理由だ。 コードを書くモードと同じモードでドキュメントを書くと、 直線はほとんど重なってしまい、交点を明確に示せない。 プトロコルとか暗号アルゴリズムの仕様を詰めるときに、その仕様に 基づいた複数の実装を独立して開発してみるように、 コードとドキュメントは別の出発点から書いた方が、 より相補的に価値を高めることができると思う。)

(2009/03/23 00:10:39 PDT) 国語を「文系」に入れるのやめにしない?

国語力とプログラミング力の関係　解説編

「わたしの持論ですが、国語ができる（＝日本語できちんとした文章が書ける）人じゃないとプログラムは書けない。これは非常に重要です」

基本的には同意、というより当然すぎて言うまでもないことじゃないかとさえ 思うのだけれど、これをわざわざ言わなくちゃならないのって、国語教育の問題 なんじゃないかという気がした。

「自然言語を使って、自分の言いたいことを一貫性を持って記述・発表できる、 またそうやって記述された文章や語られた言葉をきちんと理解できる」っていう能力は、 どの方面に進むにせよ、現代社会の中で生きてゆくには重要な能力だ。 それに対して、文学小説や古典の読解(より一般的には文脈を重視したテキスト解釈) というのはもっと特殊で、社会的な話(文学史、思想史、哲学史etc)との関わりが 深くなったり、情緒的な「読み」を要求されたりする。

今の国語はこの両方がいっしょくたにひとつの教科に放り込まれている。 これが不幸の元ではなかろうか。

文系理系という分類は嫌なのだが、性向として「人の営みにより興味を惹かれるタイプ」 と「自然の営みにより興味を惹かれるタイプ」というのはあると思う。私は高校くらいまで あまり人に興味が無くて、だから人の営みを主に扱う社会という教科はずっと苦手だった。

で、「人の営み」に興味を持てない学生からすると、上に挙げた国語の二つの要素のうち 後者の話は全然面白くないんだよね。でもそれが出来ないと国語という教科が苦手に なって、前者もやろうと思わなくなる。あるいは前者にも苦手意識を持ってしまう。 それは非常にまずいんじゃないか。

もし、前者の「自然言語による表現とその理解」が、「基礎語学」とか「語学表現」 みたいな教科で、後者のテキスト解釈その他が「文学」という別の教科になってたら、 学生の受け取り方はかなり違ってくるのではなかろうか。「国語」のサブカテゴリとして 分かれるのではなく、「社会」と「英語」が別教科であるのと同じレベルで別教科。 文系って言いたい人は「文学」の方をやればいい。 一方「語学表現」は全員必修で、論説文の読解や作文以外に、 口頭発表や議論のテクニックも含める。 というか極端な話、簡単な英語によるディスカッションという題材もこっちに 放り込んじゃったっていいくらい。 あるいは、「言葉の通じない環境に一人とり残された。あなたのミッションは○○である。 どうにかして周囲とコミュニケーションを取ってそのミッションを実行するには、 何を伝えることが必要か考えよ」みたいな課題を入れるとか。

教育現場のことを何も知らんので、実はこういう話は前からあるんだけど 実現できない理由があるのかもしれない。

だけれども。

学生の頃、バイトや研究で色々なソフトウェアを使いながら感じたのは、 英語と日本語の情報量の圧倒的な差だった。英語圏発のソフトウェアだから 英語の情報が多い、という話ではない。ソフトウェアと、それに関する良質なドキュメントの 量の比率である。とにかく英語圏のプログラマってのはドキュメントをもりもり書くんだなあ、 すげえなあ、という印象だった。しかもそれがテクニカルな意味でわかりやすい。 学生が実験的に作ったようなソフトであってもカッコいいマニュアルが揃っていたりする。 そして、ドキュメントがちゃんとしていないソフトウェアは広く使われるように なりにくいし、また忘れ去られるのも速いような印象がある。

語学表現に苦手意識を持ったままのプログラマは、プログラムという作品を産み出すに あたって大きなハンディキャップを背負ってしまっているようなものではないだろうか。

(2009/03/17 21:12:30 PDT らむ太語録)

「わいとる・たいやー。みてみて。わいとる・たいやー」

わいとるって何だ? ああ、"white wall" かぁ。 Pixarの"Cars"で覚えたようだ。

(2009/03/06 22:02:54 PST returnを継続プリミティブにする話)

思考実験: returnを関数と思ってみる話 - d.y.d

おもしろい。

関数型言語だとlexical scopeと関数とがunifyされちゃっているので 「自分を囲む関数」というのをアレするのが面倒だけど、関数がまだ特別な 位置を占めてる言語では案外わかりやすいかもしれぬ。

限定継続の方だけど、関数をまたがったshift/resetっていうのは普通にありそうな 気がする。Kahuaでも使ったし。(Kahuaでの用法は、上位層のシステムと下位層の システムを切り離すのにresetを使ってて、アプリケーション層ではほとんどcall/ccの のりでshiftを使う。resetは下の方に隠れてて意識しない)。

もともとshiftって対になるresetは明示しないもんなんで、そこで無理が来てるのかな。 確かにdynamic scopeなふるまいなんだけど、もともとcall/ccがそういう動作を するからなあ (クロージャ→静的環境のキャプチャ、call/cc→動的環境のキャプチャ)。

(2009/03/06 17:51:01 PST)

日本の定額給付金って給付の手続きを自治体が負担するそうで、 その事務負担だとか振込にする際の手数料だとかでごちゃごちゃ揉めているらしい。

しかし妙な話だ。給付金は自治体予算じゃなくて国庫から出るわけで、 それなら国がやればいいじゃん、と思う。というか自治体と国の仕事の責任 分担がよくわからないなあ。自治体は住民税＋交付金で運営してるはずだが、 こういう場合の事務負担義務が交付金に含まれてるってことなのかなあ。 つまり自治体は真の意味での「自治」ではなく、国の出先機関の役割も兼ねていると。

昨年、米国でも似たような給付金があって、うちは3人家族で$900のチェックが 送られて来た。連邦の予算だから連邦が小切手を発行して郵送するだけで、 州や市には何の負担もかかってないはず。 しばしば時代遅れとも言われる米国の小切手のシステムだけれど、こういう時は極めて便利だ。

もうひとつ、郵送先住所は国税の申告に基づいてるから、全世帯が国に 直接確定申告するというシステムも話を単純にするのにひと役買ってる。 日本だともしかして各自治体しか住所を把握してないのかな? (米国の場合、この住所はあくまで国税局やsocial secutiry administrationとの やりとりに使うためのもので、私書箱や外国の住所も許されるので、 住民票のような個人の実際の住所をトラックするシステムとは異なる)。

(2009/03/01 19:17:30 PST らむ太語録)

私が注意すると、らむ太はこの世の終わりかの如くに大粒の涙をこぼし 泣きながらかみさんのもとへ駆けてゆく。

(2009/02/26 00:40:30 PST 舞台裏を見せる)

これまで自分は、作品を創る過程というのはあまり人に見せるものではない、 というような観念を何となく持っていたような気がする。 創作過程というのはいわば舞台裏の話。お客さんは完成した舞台を 観にくるわけで、それがどう創られたかに興味があるわけじゃない。 舞台裏は観客にとって見苦しいものであり、それを見せるのは恥ずかしいことだ、 という感覚だ。あるいは、結局作品自体の評価を決めるのは作品そのものであるべきで、 その作品を産み出すまでにどれだけ血の汗を流したかなんてことは関係ないはずだから、 人に見せるようなものじゃない、という感覚だ。

でもそれはただの思い込みにすぎなかったかもしれない。

ふと気づいてみれば舞台裏を見せることは既にさほど珍しく無くない。 DVD時代になり、大抵のメジャー映画については そのメイキングの過程も観客に届けられるようになっている。 オープンソースの開発もほとんど最初から過程がガラス張りだ。 オンラインの絵画掲示板では絵の出来て行く過程をプレイバックすることで 完成した絵を見ているだけではわからない試行の跡が見られて興味深い。 そして今や、 Paul Grahamのエッセイが書かれる過程すら見えるようになった。

これは良いことだと思う。創作の入り口に立っている人にとって、 完成された偉大な作品というのははるか彼方にあるものだ。 そういうすごい完成形ばかりを見せられていると、自分の手元でようやく創り始めた ものがひどく陳腐に見えてしまい、続ける気力を失ってしまうかもしれない。

けれどもどんな作品でも、最初は荒削りの、粗野で原始的な形態から始まっているのだ。

舞台裏を見せることを躊躇してしまうのは、 それが作品の欠点に対する創る側の「いいわけ」になることを恐れているから、 かもしれない。 けれども、もともと過程と作品は別物だ。過程を知ることで作品に対する理解が 深まることはあっても、至らない作品の至らない部分を創作過程が補えるわけじゃない。

敢えて失敗や迷走の跡だとか、未熟なアルファバージョンを見せることで、 次の創作者がより良いものを産み出せるなら、大いに結構なことだ。

(2009/02/20 04:22:34 PST x60s SSD換装)

→Shiro:x60s:SSD換装

(2009/02/19 13:11:40 PST)

アレルギー性鼻炎持ちなので、たまにくしゃみがとまらなくなる。

…これを10回くらい繰り返した。

(2009/02/18 13:50:16 PST)

YouTubeで"Tom and Jerry"を観ていたらむ太、突然すっくと立ち上がって 「とむとじぇりー、まっててねー、らむ太、しーしてくる」 と言うと大慌てでトイレに駆け込んだ。

まだPauseのやりかたは見つけていないようだ。 (音量調節は時々いじっている)。

(2009/02/10 02:13:08 PST)

公演終わった (昨日)。昔は楽日の後はバラしてから徹夜で打ち上げ、というのが普通だったんだけど、 今回はらむ太をピックアップして (かみさんが観に来るために チャイルドケアに頼んでいたのだ) 自宅に帰って一息ついたらそのまま朝まで眠ってしまった。 寄る年波かのう。

数日前のことだが、舞台が終わって帰るとまだらむ太が起きてて 駆け寄って来た。

「とうさん、とうさん、みてみて、ごきぶりねんねしてる」

さてはゴキブリの死骸でも見つけたかとらむ太の示すところを見た。 仰向けになって死んでいたのはゴキブリではない甲虫類 (名前は知らないのだが、以前モクレイアにキャンプに行った時に 地面に大量にいたのでうちでは「キャンプ虫」と呼んでいる) だったのだが、 らむ太はご丁寧にペーパーナプキンで掛け布団を作って ちょうど顔だけ出るように虫の死骸に掛けていた。

虫なんかどうでもいいから君がさっさと寝なさい、 と言いたいところだがきっとこれを言いたくてがんばって起きていたのだろうから、 「あーねんねしてるね。もう夜だかららむ太もねんねしなさい。むしさんばいばいだ。」 などと言って寝かす。夜商売だと子供のリズムが崩れていかん。

(2009/02/06 19:46:35 PST 表現の訓練の場)

レポートコピペ問題の問題

小中学生の読書感想文に、ネットのサイト「〜児童、そして生徒のための〜自由に使える読書感想文」からのコピペが増えており、中には市の読書感想文コンクールで上位に入ってしまったものまであって、先生たちが頭を抱えている‥‥というニュースを昨日やっていた。

なぜコピペじゃだめで自分の頭からひねり出さないとダメか、という点については 課題を出す側の目的によってそれぞれに論点が異なってくると思うが、 初等教育での読書感想文や作文については、自分の頭の中にあるもやもやを 「表現する」ということの訓練、という側面もわりと大きいのではないかと思う。 表現することが目的であれば、当然コピペは訓練にならないわけだけど、 「何でもいいから感じたことを書け」といきなり言われて困ってしまう子供の立場もよくわかる。

表現にはスキルが必要で、それは自分から表現してみることで伸びて行く。 もちろんちゃんとした指導も重要で、作文教育で体系的なスキルの教授が 行われてるかってとこにも問題はあるだろうけれど、別の側面として、 表現教育の場の問題もあるんじゃないか、という気がした。

どんな演技のワークショップでも稽古場でも、大前提となっていることがある。 それは、「基本的なルール(自分や他人に危害を及ぼさない、等)を守る限り、 そこで何を表現しようが許される」という安心感と一体感をその場に作ることだ。 出した表現はもちろん後から批評を受けるけれど (そうでないと改善できない)、 それはあくまでよりよい表現をするための建設的な意見であって、人格批判ではない、 ということをすっと信じられるだけの空気が必要だ。 これはあまりに当然のことで、わざわざ言わないインストラクターやディレクターも 多いけれど、演技にかかわる者の間ではほとんど常識に属する話だと思う。

役者という、人前で表現をすることを自ら選択した者にとってさえ、 表現することはとても怖いことなのだ。 少しでも萎縮するような要因があると、灯りかけた表現の種火はすぐに消えてしまう。 種火が、少々の風では消えないくらい力強い炎になるまでは、 慎重に守ってやる必要があるのだ。 参加者全員がその恐れを乗り越えることが出来てはじめて、

表現について取り扱う準備が整ったことになる。

プロの役者でさえそうなんだから、学校の生徒ならなおのこと、 表現をしようとする最初の段階での安心感がとてつもなく重要なのではないか。

ということがはっきりしていれば、生徒もずいぶん楽だと思うのだ。 もっとも小学生にこういうルールを(頭ではなく、体感として)わかってもらうのは 相当難しそうだ。高校生くらいなら何とかなるかもしれないなあ。

(2009/02/06 12:31:32 PST 文字列検索)

文字列検索 - ときどきの雑記帖 i戦士篇

KMPとかBM ってマルチバイト文字とか幅広文字に使うの面倒だよねえ。

というわけで、mb1 : utf-8のように文字境界を誤ることのないmultibyte encoding、 mb2 : euc-jpのようにランダムアクセスで文字境界が確定しないmultibyte encoding、 とすると、こんなふうに理解してる：

wchar mb1 mb2
BM × ○ ×
KMP ○ ○ ×

(2009/02/04 03:32:48 PST)

先々週に撮影したCentral Pacific BankのTVCMがもう流れているらしい。 ハワイにいる人は目にする機会があるかも。

ここにちっこい写真が出てる。1950年代の日系のスモールビジネスオーナーの役。

たぶんほとんど画面には写ってないけど、机の上の書類などは全て 1910年〜1950年頃の実物だった。日系の人の1940年の手帳があって、 日本語英語まじりで予定が記入されていて、生活感が妙に生々しかった。 その翌年に祖国がハワイを攻撃することになるとは、予想だにしていなかったろうか。 それとも薄々何かを感じていたんだろうか。色々考えてしまう。

(追記2009/02/06 02:15:54 PST: 火曜日のHonolulu Advertiserにかなり大きい(半面以上)広告が 出てたらしい。帰りにスタバに寄って今日のAdvertiserを見たけど載ってなかった。 むー、記念に取っときたかったのになあ。)

(2009/01/31 02:56:52 PST)

昼過ぎまで撮影、夕方から舞台のダブルヘッダ。疲れた。

間に1時間ほど昼寝したので頭は切り替えられた。

今日のロケ地は、ハワイの金比羅神社。 金比羅さんがハワイにあったとは知らなかった。 ごく短いシーンなのだけど、タイトなショットが多くて カメラを調整しながら何度も何度も繰り返し。 こっちは慣れてるけど、神主さんは大変だったかも。

放送は10月だそうな(米国内)。放送後にネットで観られるようになるかも。

(2009/01/27 19:24:35 PST らむ太語録)

微妙に発音が違うものメモ

迷言

(2009/01/26 21:45:55 PST 仕事と専門性)

学歴と職について - 言語ゲーム

進学出来ない人は悔やむ必要ないです。進学出来るかどうかは経済的な問題で、あなたの能力の問題では無いという事を社会は分かっています。

学歴があるのに専門職に就けなかった人は悔やむ必要ないです。どんな業界でも経験を積むと段々好きな事が出来るようになるので、いずれあなたの知識は役に立ちます。

いいことゆった。

ひとつの道を究めるとか、夢に向かって着々と準備をしてゆくってのは確かに 素晴らしいことだし、そうしなければ就けない仕事というのもあるにはあるのだけれど、 そういうのはそびえ立つ山の頂上みたいなもので、遠くから見て目立つけど、 たどり着ける人はごく少数だ。

世の中の仕事のほとんどはそういう輝かしいピークを支える山麓とか、 山頂と山頂の間の稜線のようなところにあるし、 ある程度登ってみて初めて見えてくる小さなピークもあちこちにある。 山頂に向かって一直線に進むばかりが人生ではない。 色々寄り道した人にしか出来ない仕事というのもあるはずだ。

寄り道が役に立つかどうかというのは事後的にしかわからないから、 分かれ道を前にしていくら悩んでも結論は出ないだろう。 結局は、自分の心のままに選ぶしかないんじゃないかと思う。 とりあえずわからなかったらPaul Grahamが言うように「風上に進む」ことか。

ただ、どんな仕事も麓から見上げているだけでは手前の丘と その向こうにある白い頂しか見えない。それだけを見ていると選択肢がとても少ないように 感じられてしまう。その間に隠れている無数の高原やピークを見つけるには、 ある程度登ってみないとならない。

一般的な指針として、その専門の業界内で報酬をもらえるくらいまでは 突っ込んでやってみるのがいいんじゃないだろうか (分野によっては「報酬を得る」ということ自体が難しい場合もあるが、 数年くらいは真剣にやってみるということ)。 一生それだけで喰って行くことはできないとしても、 業界の内部から見ることで、本当にてっぺんで仕事をするとはどういうことかを 見る機会も得られるかもしれないし、周辺にある仕事も見えてくる。 そうすると一気に選択肢が広がるし、全く新しい道が見えることもある。 そして、そのくらい真剣にやって身についたものは いずれ何かしら役に立つかもしれないし、 一緒に取り組んだ人々からは色々な人生の見方を学べるだろう。 少なくとも、麓から頂を眺めるだけで過ごすよりも得るものは大きいんじゃないかと思う。

(追記2009/01/27 23:00:14 PST: 役者というのは「あらゆる人生経験が何らかの形で役に立つ」 という意味ではかなり間口の広い職種である。ただし需要が限られているので それで喰って行くことが難しいのが困りものだ)

(2009/01/23 16:04:42 PST Apple Mailの仕様?)

最近続けて受け取ったのでメモっとく。

X-Mailer: Apple Mail (2.753.1)

と名乗るMUAなんだが(バージョンは2.930.3とかもあり)、 たぶん送信者側の設定で「テキスト・HTML併用」みたいにしてあって、 かつ送信者がメールを添付した場合、このMUAはこんなふうにMIMEエンコードしてしまう： 

  + multipart/alternative
     +--- text/plain 本文 
     +--- multipart/mixed
            +--- text/html 本文 
            +--- 添付ファイル (application/pdf、audio/mpegなど)
            +--- text/html 自動で付加されるフッタ?

これだと、受信側のMUAがmultipart/alternativeを信じて、かつテキスト優先に している場合、添付ファイルの存在そのものが受け取り側には見えなくなってしまう。

あるべき形式は 

  + multipart/mixed
     +--- multipart/alternative
     |      +--- text/plain 本文
     |      +--- text/html 本文
     +--- 添付ファイル

だと思うんだが、multipart/alternativeって一番上にこないと困るんだっけ? RFCざっと眺めた限りではそういう縛りは無さそうだけれども。

まあこれだとMIMEを処理出来ないMUAで見づらいって欠点はあるのか。 しかしmultipart/alternativeのひとつを選ぶと添付ファイルの存在自体がわからないって いうのも結構困りものだと思うんだが。 該当するMUAを自分で使ってないのでどこに要望を上げるべきかもわからん。 ここ見てるMac userの人、何かアイディアはありますか?

(なお、これらのメールについては、仕方ないので元ファイルを直接いじって トップのmultipart/alternativeをmultipart/mixedに書き換えて添付ファイルを 入手した。Gaucheのrfc.mimeで読むという手もあったのだけど後からMewで 見られる方が便利だし)

(追記メモ2009/01/23 17:56:39 PST: mew-summary-analyze-again-alternative (キーバインドは':') を使うと miltipart/alternativeの複数のパートを別々に表示できる。これで良いのか。)

(2009/01/22 10:40:51 PST)

Paul Grahamがもうすぐ父親になるそうなので 子育てエッセイに期待。

(追記(2009/01/25 11:26:18 PST): 産まれたそうな。http://news.ycombinator.com/item?id=448821 )

(2009/01/16 13:52:29 PST 劇評)

本日はstormという予報で、全島に強風波浪注意報。 予想最大風速60mphということは27m/sか。 らむ太のプレスクールも含め学校は軒並み休校で、オフィスも休業したとこが あったようだ。 ところが朝は妙に天気が良くて。 外れたのかなと思ったら11時くらいにようやく雨が降り出した。 今、いよいよ雨足が強まってきたところ。さて、今夜も本番はあるのだけれど、 お客さん来るんだろうか。

"Mainland Education"の劇評が地元紙に出た。

主人公の日系3世が抱えた人種についてのジレンマに共感できるかどうかで 感じ方が分かれるのかも。個人的には人種の話はステージングにすぎず、 テーマはもっと普遍的なものだと思うんだけどな。

(2009/01/10 16:30:21 PST)

http://news.ycombinator.com/item?id=428524

Geeks seem to have this funny blindspot when it comes to premature optimization if the premature optimization is something that would make for a good sci-fi novel.

Indeed.

理性より好奇心の方が強いのねん。

(2009/01/09 19:49:22 PST 役者の記憶力)

昨日、満席で初日があけた。シーンが終わる度に拍手が出るなど えらくsupportiveな観客に感謝。

堀江氏のブログにて、英語の単語の丸暗記をする話が出てくる。 六本木で働いていた元社長のアメブロより：

１日24時間のうち10時間を睡眠・食事・風呂などに当てて、残りは単語ずっと暗記です。14時間も使えます。14時間で2ページ。単語数は派生語入れても50行かないくらいです。どうです？それくらいなら出来そうでしょ？

私はよっぽど舞台俳優さんの台詞暗記能力のほうが凄いと思いますよ。あんまり間違えられないし。

で、これについてこんなコメントがついてた。

舞台俳優の台詞は一言一句台本通りにしゃべってるわけじゃなく 台本ど忘れしたらアドリブで切り抜けるから英単語暗記とは違うけどな

日本の小劇場での経験では、公演ために書き下ろされた脚本でやることがほとんどだし、 脚本家が演出家を兼ねていたり、そうでなくても稽古に密接に関わって逐次修正してゆくことも多い。 その場合、脚本はどちらかというとたたき台というか素材みたいな感じで、 一言一句にこだわるよりは稽古の中で自由に発展させていって良いという認識が あったように思う。

米国の地方劇場で芝居をやってみて思ったのは、 日本の小劇場のそれは比伝統的なケースであって、 「既に完成している脚本」を使う場合は、 一言一句台本通りというのが大原則なんだなあ、ということだ。

別に脚本を神聖視しているわけじゃなくて、 演出家の判断で細部を変えることもよくあるんだけれど、 大前提として「一言一句細部まで全て、脚本家は意識的にそういう選択をして脚本を書いた」 というのが当然のこととして受け止められている。 あるいは、そこまで練られた脚本でないとそもそも上演されることがない、 と言ってもいい。 (新作であっても、脚本が完成してから上演されるまで数年かかるのが普通。 その前にreadingなどで披露されることもあるけど。基本的には何年経っても 色褪せない脚本であることが求められる。) 従って役者にも、脚本家の記したものを「前提」として、そこから可能な限り多くの意味を 読み取ろうとする姿勢が求められる。

例えばある一言の台詞について、「これ、最後が'?'なんだけれど、'!'にしていい?」 みたいな細かいことまで議論に上がることがあるし、 その場に脚本家が居ればこの程度のことでも演出家は脚本家に「変えていい?」って訊く。 あと、稽古中は演出助手が台詞をチェックしていて、脚本と違ってたところは後で教えてくれる。

で、まあ一言一句暗記するのが役者の仕事なんだけれど、 日本でやってた頃は全然苦労しなかったんだよね。 意識して覚えなくちゃならなかったのは長台詞くらいのもので、 普通の会話は何回かシーンを流したら頭に入ってた。

米国で芝居を再開した時に、台詞を覚えるのに苦労して、 これはもしかすると年齢のせいじゃないか、と思った。20代前半と30代後半じゃ 記憶力に差が出てもおかしくないかなと。

ところが数年芝居を続けていると、いつのまにかまた台詞が頭に 自然に入るようになって来た。明らかにここには年齢ではなく、 継続することで身につく何らかのスキルが介在している。

脚本を「前提」にするということは、その言葉がそこで発せられる必然性について とことん考えるということで、それを考え抜いたら台詞の言葉は全て 「あるべくしてそこにある」「この流れでここにこの言葉以外がくることはあり得ない」 ってことになる。「丸暗記」しているように見えるのは氷山の水面上に出ている 部分にすぎず、実は水面下にそれを支える巨大な土台があるわけだ。 その土台の方が芝居の実体であって、その土台から水面上の 台詞を本番のたびに再構成するんだけど、それが必然的に脚本上のせりふと 「一致してしまう」ってことなんじゃないかなと思う。

(『のだめカンタービレ』で、のだめがオクレール先生に違う音を指摘されて 「ちゃんと考えてないからだよ」と言われるところがあるが、 ここでの「考える」っていうのもそういう意味かなあと思う。)

Last modified : 2009/10/31 01:39:56 PDT