2006/02/02
とうとうこのWiLiKiにもspamが来ていたようで。revertしてくれたこびとさん、 ありがとうございます。いたちごっこになるとは思うけれど、アクセスログを 睨んで何か対策を考えなければ。
月曜から今日まで、某ホテルチェーンのプロモーションフィルムの撮影だった。 ちょっとしたドラマ仕立ての数分のプログラム。 太陽光を利用する屋外での撮影は早朝から夕方までのことが多く、 集合は朝5時とか6時だ。夕方仕事が終わってから子供を 風呂に入れて飯を食わせ、自分達も食事を済ませると8時。 翌日の台本を確認して、ストレッチとヨガをやって9時就寝。 こういう生活も悪くはない。コンスタントに(役者の)仕事があればいいんだけれど そううまくはいかないね。
クルーの中に去年の映画で一緒だった人が2人ばかり。こちらも狭い業界である。 ほんの3日でも、一緒にプロダクションをやると他人とは思えなくなるのが 芝居の魔力だ。
Tag: 芝居
2006/01/28
- Matzにっき:「オブジェクト指向神話」神話, 「オブジェクト指向」改め「抽象データ指向」
- 404 Blog Not Found:オブジェクト指向は構造化の「次」か?
プログラミングパラダイム及び言語の進化ってのは、 複雑すぎでそのままでは人間の頭に入りきらない問題をいかにして 頭に入りきる大きさに収めるかという試みに他ならない。構造化も抽象化も カプセル化も、そのための道具だ。
オブジェクト指向の出自は現実の世界のモデル化にあったはずだが、 ある時、それが「簡易抽象データ型＋簡易名前空間＋簡易クロージャ」として 使えることに誰かが気づいた (誰が最初に気づいたかは知らないけれど 広めたのはStroustrupだろう)。これらの概念はそれぞれが、 モジュラリティの高いプログラミングに使える道具であり、 問題の複雑さを整理するのに役立った。で、後者の方が広まってしまった。
オブジェクト指向がわかりにくいとされる理由の一端は、 このような経緯にあるのだろう。 小飼さんが「『オブジェクト指向』は『構造化』の進化系ではなく、 元来直交して扱える概念」という時、それは出自に遡ってとらえている。 一方、プログラミングパラダイムの方から見ると、構造化の後でたまたま 「使える」概念として出てきたのがオブジェクト指向だったわけで、 Matzさんの「実際には、オブジェクト指向プログラミングは、 構造化プログラミングの『次』と 認識されるべきものだと思う」というのは そっちの立場なんだと思う。
後者が広まったのはC++のせいもあるが、旧来のプログラミングに 慣れていた人々が現実のモデル化というのを具体的にイメージするには、 Smalltalkのような環境が無いと難しかった、ということもあるのではなかろうか。 私自身は、アセンブラでちょっと面倒なプログラムを書いてて スパゲティになってしまった時に、伝え聞いていた「データと手続きを 一緒にして、オブジェクト間のメッセージパッシングでプログラムを記述する」 という手法を試してみたらびっくりするほどすっきり書けて、 ああこれが巷でいうオブジェクト指向というやつなのかと納得した 覚えがある。つまり方法論から入ったわけだ。C++どころかCもろくすっぽ 知らなかった頃だ。もしCを使い込んでいてC++に触れて、 構造体の延長として抽象型もどき、名前空間もどき、クロージャもどきを 手に入れればこりゃ便利だと思っただろう。
上で「簡易」とか「もどき」とか言っているのは、初期のC++が提示した それらは結局本来の概念の代用、もしくは一次近似に過ぎなかったからだ。 それ自体は悪いことではない。 それも一種のモデル化(それも、結構使えるモデル化)だから。 ただ、言語の限界を押し広げるように使ってゆくといつか近似はほつれてきて、 不満が出てくる傾向はある。テンプレートを導入したり名前空間を別に入れたり、 あるいは無名クラスやデリゲートやらと言っているのは、 ほつれを何とかしようとして近似の度合を二次、三次と上げているようなものである。
Tag: Programming
2006/01/26
CVS管理してるもの以外のデータは以前は適宜CD-ROMに焼いてバックアップと していたのだが、1枚に入りきらなくなって面倒になってきた。 こういう大事な仕事が面倒だとプロクラするようになって後で悲劇が起きる ことになっている。 付ける場所が無くて転がってたEIDEのディスクがあったのでHDDエンクロージャを 買ってきてバックアップディスクにすることにした。 USB2のだともう安いねえ。デザインで選ぶようなものになってるんだなあ。
バックアップそのものはrsync --link-destで。Gauche:gdumpfs?もあるけど、 まあ出来合いのコマンドがあるならそっちがいいかと思って。 でもいちいちコマンドラインをタイプするのも面倒なので 結局wrapperを書いてしまった。
Tag: Programming
2006/01/23
センター試験のリスニングのトラブルのニュースを読んでいて思ったんだが、 新しい機械を50万台近く配って、一回限りの試験をやらせようっていう発想が 何というか、日本人的だなあと思う。「ちゃんと動いて当然」という頭 があって、付けたしのようにトラブルへの対応手順を考えたんじゃなかろうか。 こっちじゃそういう発想は出てこない。うまくいきっこないから。
人間が相手の場合、失敗に大きなペナルティを課すことで「ちゃんとやる」 圧力をかなりの程度まで増やすことができ、実際に日本社会の多くの部分が そのようにして動いているのだが、機械の故障率ってのは人間ほど柔軟じゃない。 メーカーにプレッシャーをかけて多少調整することは出来たとしても、 結局はコストとのトレードオフになる。入試センターは当初 「故障はゼロと思っていた」と言ってたそうだが、 本気で故障率を10^-6以下にしたつもりだったんだろか。
エラー処理が醜くなる時っていうのはだいたい設計をしくじっている。 トラブルが一定率で起きることを織り込んでいれば、 トラブル時の再テストや再試験などにあまり複雑な手順を設定できないはずだ。 例えば「一度しか聞けない」という制限をはずせばずいぶんすっきりすると 思うのだが。装置に頭出しをつけなくちゃならないけれど、機器トラブルは すぐに交換すれば済むし、操作ミスのリカバーも容易になる。 それによって故障率のマージンが広く取れるならコスト的には どっこいどっこいになるかもしれない。
何度も聞けていいのか、に関しては、そもそもリスニングで何を 試験したいのかってことになる。ネイティブのスピードで読まれた英語を 一発で聞き取れる受験生なんてほんのごく一部だろうから、問題はかなり ゆっくり読み上げられていたのだろうと想像する。 だが、今後受験生が英語を使ってゆく場面で、(1)相手がゆっくりと 一度だけ喋ってくれる (2)相手は普通に喋るが、聞き返したら何度でも 言い直してくれる、のどちらに遭遇することが多いだろう。
自分の経験からすると、リスニングの能力はリニアに向上するのではなく、 不連続な段階がある。その一番重要なものは、「どの単語が聞き取れな かったかが自分でわかる」という段階だ。それをクリアすると実用上 あまり不自由することがなくなる。 で、複数回聞くことによって救われるのはその段階に達している受験生 だけなので (それ以下だと何回聞いてもわからない)、複数回聞けるように することの影響ってあんまり無いんじゃなかろうか。
Tag: 生活
