映画「ノルウェイの森」の感想

映画「ノルウェイの森」みました。かなりな勢いで、気に入ったので2回みました。また観るかも。そんなわけで、興奮にまかせて映画の感想を書いてみます。

免責事項を2つ。まず、全力でネタバレです。それから、映画や文学のことはほとんど知らないので、かなり稚拙な内容です。映画評ではなくて、感想です。原作もそんなに読み込めていません。はい。以上、いいわけ。

表層的なストーリーはヤンデレなラブストーリーで、その下のレイヤーは、村上春樹お得意の、こちらとあちらの話です。この映画では、その境目に水があるように思えます。原作になかったのか、読めていないのかは不明です。

たとえば、直子とワタナベが再会するのは、池の前のベンチです。このとき、直子はあちらからこちらにきたのでしょう。そしてセックスをするわけですが、そのあと、あちらに行ってしまいます。このとき雨が降っています（これは原作にもある）。

ワタナベが、あっちとこっちを行ったり来たりし始めるのは、阿美寮に行き始めてから。このあたりでは、阿美寮と早稲田大学を交互にカットが入ります。

緑は一貫して、こちらがわにいるんですが、ワタナベがうろうろしているので、プールが登場したりします。

直子と緑に共通する、雪をどう解釈するかは、自分の中でまとまっていません。

最後のほう、レイコさんとワタナベが寝たあと、直子のシーンが出てくる。水辺の木の枝の上にワタナベが立ってて、木の幹に直子がもたれています。レイコさんが、少し離れたところに座っていて、立ち上がり、そのまま直子の前を通りすぎていってしまう。すぐにシーンは切り替わって、ワタナベのアパートから、レイコさんとワタナベが出て行く。

このシーンは原作にはないのですが、原作で直接語られていない、登場人物の世界の移動というか立ち位置の変化を、映像化しているのだと思います。直子のそばからレイコさんが離れていくけれど、ワタナベはそこにいる。だから最後にワタナベは「今、どこにいるんだろう？」って言うわけですよ、きっと。

小説ではこの表現はできないでしょうね。けど、無粋にならない程度に、トランの解釈が表現されていると思いますし、小説だけでは分かりにくい部分が解説されていると思いました。

あと映画を見て思ったのは、ビリヤードでポケットにボールが落ちるのは、井戸に落ちるメタファーなのかな、と。それは考えすぎですかね。

ちなみに、原作があろうがなかろうが、映画は、その製作者（監督なり、脚本なり、俳優なり、カメラなり）の表現である、という解釈をしています。原作に忠実とかはそれほど気にしないです。あんまり離れてたら気持ちわるいですが、原作から汲み取ったエッセンスを使って表現しているんだなぁってことで。なので、スカイ・クロラも好きだし、頭文字Dの海外版も好きです。それを踏まえて、この映画は、原作をよく表現できているなぁと思いました。

小室淑恵 / ６時に帰るチーム術

ワークライフバランスって言葉が目に付く本ですが、究極的には生産性向上のしくみの提案です。仕事すんな、とか、そういう話ではないです。

たとえば、その日の予定を立てて共有する朝メールと、実績を報告する夜メール。まだ他者と共有してはいませんが、私はカレンダーに大きなタスクをざっくり書きこんで、それを予定にしています。で、それを実績のとおりに修正すると、それが日記というか活動記録になります。ほんとは、予定と実績を別のカレンダーにしたほうがいいのかもしれません。

まあ自分の予定通りには進まないです。残念ながら。

ただし、就業時間と残業時間の区分はしっかりしておきましょう。残業ではどんな業務が多いのか、なぜ残業にずれ込んでしまうのかを意識させると、次のステップにつなげやすくなります。(p.90)

別に勤務時間外で仕事をしちゃいけないとかいう意味ではなく、予定とどのくらいずれているか、ってことのフィードバックが重要なんですよね。そもそも見積が甘いのか、割り込みがあったのか、云々。

共有と言えば、

一つの業務を一人で担当すると、自分にしかわからないことばかりですから、「休みたくても休めない」という状況に陥ります。(p.117)  

こんな話も。仕事自体の共有です。XP のペアプロを彷彿とさせます。レビューやコードの共有は重要だから、ペアプロしようぜという極端なやりかた。いつも仕事を一緒にやっていれば、日々、少しずつ共有が進んでいくってわけです。じゃあいきなり、ってわけにもいきませんが、なにがしか近いことはできるんじゃないかなと思います。

ワークライフバランスっぽい話でいくと、取引先の時間が夜型のときには、全体的にこちらもそれに引きずられやすいので、そうしない工夫とか、あるいは、始業時間をシフトさせることを言えるようにしたい。いまは、なんとなく自分がバリューだせていないっていう引け目があって言いにくい。

業務上のタスクには締め切りがあるはずですが、締め切りまでの間にさらにいくつか「チェックを入れるタイミング＝締め切り」を設定するのです。

マネジャーからメンバーに仕事を依頼するときにも、「何を、いつまで、何時間ぐらいかけて」と指示するとともに、「こことここの段階で見せて」と言っておきます。 (p.177 )

ほんとにダサい話なのですが、私は締め切りの設定が下手で、非常に大きな誤差が発生します。ほとんどの場合、見積もりのほうが楽観的すぎますが、「なぜそんなにかかるのか？」という修辞的質問の圧力に屈してしまいます。そしてまったく根拠のない締め切り設定をしてしまう。だからこそ、チェックポイントを用意して、締め切りごとのごさを小さく、そして修正を早めにできるようにならないとなぁ、と、思いましたとさ。自分にも他人にも。

Python 3.x 対応のフレームワーク QP

Python Web フレームワークアドベントカレンダー の 7 日目担当の、ふるかわとおるです。よろしくお願いします。

あのですね。Python 3.x みんな使わないんですよねぇ。やっぱり、それなりのことをやりたくなると、サードパーティのライブラリに依存することになるんですが、そのライブラリが 3.x 対応じゃないと、なかなか乗り換えられませんよね。特にウェブの場合は、文字列まわりの変更の影響が大きいですし、WSGI の次期仕様である PEP444 が確定してないこともあったりで、軒並み Python 3.x 対応していません。http://python.org/3kpoll を見ると、Python 3.x 対応してほしいランキング 1位が Django ですね。私も1票投じているわけですが。

さてさて、そんなわけで、ここでは Python 3.x に対応しているウェブフレームワーク QP を紹介します。Mac OS X 10.6.5 でビルドした Python 3.2 を使いました。紹介といいつつも、ドキュメントがほとんどないので、必死でサンプルを読み解いた軌跡です。やべぇ、もう 23:22。

インストール

setuptools では、途中のビルドに失敗するので、Distribute を先にインストールします。

http://pypi.python.org/pypi/distribute からソースをダウンロードして、

$ python3.2 setup.py install

つづいて、

$ easy_install-3.2 durus
$ easy_install-3.2 qpy
$ easy_install-3.2 qp

durus は ZODB っぽいデータストレージ、qpy はテンプレートエンジンです。qp は Quixote の後継フレームワークなんですけど、23:27 になったので次。

Hello world!

qp のプロジェクトは、配置する場所が決まっています。/var/qp_sites とか。あるいは環境変数 QP_SITES に格納されたパスに置いておきます。

ここでは qp_sites/hello ディレクトリをまず作ります。必要なファイルがいくつか必要です。

• qp_sites/hello/__init__.py ... からっぽで OK
• qp_sites/hello/var ... 空っぽのディレクトリ。pid ファイルとかが置かれる。
• qp_sites/hello/slash.py ... ここにコードかく

では、slash.py を見ましょう。

from qp.pub.publish import Publisher

from qp.fill.directory import Directory

class SitePublisher (Publisher):

    configuration = {"http_address":("", 8000)}  

class SiteDirectory (Directory):

    def get_exports(self):

        yield ("", "index", "top page", "Home page of hello")  # パス、メソッド名、名前、タイトルのタプル

    def index(self):

        return "hello, world"

ターミナルから

   qp -u hello

で、起動します。

テンプレートエンジン使う準備

変更するファイルがトリッキーです。まず、slash.py を slash.qpy にリネームして、以下のように編集します。

# qp_sites/hello/slash.qpy 

from qp.pub.common import header, footer

from qp.pub.publish import Publisher

from qp.fill.directory import Directory

class SitePublisher (Publisher):

    configuration = {"http_address":("", 8000)}

class SiteDirectory (Directory):

    def get_exports(self):

        yield ("", "index", "top page", "Home page of hello")

    def index [html] (self):

        header("Hello!")  # <html><head> ... とかを出力してくれる

        "<strong>Hello,</strong> <em>World!</em>"

        footer()  # </body></html>を出力してくれる

つづいて、__init__.py も編集。

#__init__.py 

from qpy.compile import compile_qpy_files

compile_qpy_files(__path__[0])

.qpy は、微妙に Python とはことなってて、def index [html] (self) あたりが拡張されています。テンプレートエンジン qpy はこのファイルをコンパイルしたものを使います。なので、テンプレート書き換えたら、qp を再起動します。

  qp restart

index メソッドがテンプレートになっていて、各行を評価した結果の文字列が、テンプレートの出力になります。

header() の戻り値、"<strong>Hello,</strong> <em>World!</em>"、footer() の戻り値が連結されて、レスポンスになります。

テンプレートと永続化を使う

わたくし、ちょうど1年くらい前にウェブ業界にはいりまして、データベースとか詳しくないんですよねぇ。なので、MySQL とかとつなぐとかめんどくさくって。qp なら durus というオブジェクト永続化の仕組みをつかえるので楽ちんです。ZODB を知ってる人ならなじめるらしいです。

# qp_sites/hello/slash.qpy

from qp.pub.common import header, footer, get_publisher

from qp.pub.publish import DurusPublisher

from qp.fill.directory import Directory

from durus.persistent import PersistentObject

class SitePublisher (DurusPublisher):

    configuration = {"http_address":("", 8000)}

    def count_up(self):

        d = self.get_root()

        d['count'] = d.get('count', 0) + 1

        self.commit()

        return d['count']

class SiteDirectory (Directory):

    def get_exports(self):

        yield ("", "index", "top page", "Home page of hello")

    def index [html] (self):

        header("Hello")

        "<strong>Hello,</strong> <em>World!</em>"

        "<p>"

        get_publisher().count_up()

        "</p>"

        footer()

データは SitePublisher クラスのプロパティとして格納されます。でデータは基本的にツリー構造になっていて、ツリーの根をとるのが、get_root() メソッドで辞書っぽいオブジェクトを返します。これに任意のオブジェクトを追加して、commit() メソッドを実行すると、データが保存できます。上の例では、 count_up() メソッドがそれです。

てな感じですね。

まとまらないまとめ

テンプレートが 似非 Python コードであること、データの保存がオブジェクト永続化であること、あたりが、メジャーどころと大きくことなる QP ですが、ちょっと気になっています。durus はマルチスレッド、マルチプロセスに対応している雰囲気です。そんなわけで、QP と Python 3.x 、これからも気にしていこうと思います。

つぎは、Python 界のイケメン地ビール愛好家 @MiCHiLU さんにお願いしまっす。