ガロア 〜天才数学者の生涯〜
ガロアが20歳の若さで決闘で死んだことはあまりにも有名であるが、本書はその生涯を時代背景とともに掘り下げ、ガロアの人物像と彼が後世に残したものの意味が書かれている。
若干20歳の青年が、その後の数学の歴史を塗り替えてしまうほどの偉業をいかに成し遂げたのか。15歳のときルジャンドルの「幾何学原論」と出会ったことが数学との最初の出会いという。その本をマスターするのに通常は二年かかるといわれているものを、たった二日で読破したというから驚きだ。それ以降、数学以外には全く興味を示さず、一切の勉強もしなかった。かなり扱い難い学生だったようだ。闘争心が強く周囲に対して攻撃的な態度をとり、理解者が少なく孤立化していく。それが悪循環となり、自分への過小評価や陰謀などの妄想にとりつかれてしまう。
論文を提出するも、不運が重なり査読者の手元から二度も紛失している。不信感が募り、悶々とした疑心暗鬼が心の闇を覆う。
後にガロアがその二編を短くまとめた概要が現在残されているだけである。その内容が今日知られる「ガロア理論」でるが、それは元の論文の全体の一部に過ぎない。ガロアはもっと深遠で高次なものに到達していたようだ。しかし、残念ながら、あまりにも突然に早く逝ってしまったため、その内容を知ることはできない。
大学に入ってから、持ち前の闘争心からか、共和主義者として徐々に政治活動にのめり込んでいき、危険人物とマークされるようになった。ちょっとした事件から収監所に収容され裁判にもかけられる。
決闘は突然決まったようだ。あらゆる手段を考えて回避を試みたができなかったという。「自殺説」「陰謀説」「恋愛説」などもっともらしい理由はあるが、どれも確かな証拠は何もない。
決闘直前に友人のシュバリエに全てを託した。恐らく、ガロアは確信していたのではないか。自分はその決闘で死ぬことになるが、自分の数学は後世に残り続けるだろう。いや、残さなくてはならないと。しかし、ガロアが到達していたものは、当時のレベルを遥かに超たもっともっと深いものだった。その失われた内容は想像することしかできない。
もし、もっと生きていてくれたらと、取り返しのつかない歴史が悔やまれるが、著者の次の言葉が印象に残る。
「数学という学問はこのような視点からも鳥瞰することができる。このことを二十歳のガロアは著者に教えてくれた。それだけでも著者は幸せだ！」
今年はガロア生誕200年である。さまざまなイベントが計画されている。天才の残した足跡に思いを馳せてみよう。
- 作者: 加藤文元
- 出版社/メーカー: 中央公論新社
- 発売日: 2010/12/01
- メディア: 単行本
- 購入: 4人 クリック: 72回
- この商品を含むブログ (20件) を見る
2010年最後の夕日
実は、先週の12/23に念願のNikon D7000を遂に購入した。ボディーだけ。既に600枚以上撮ったが、まぁまぁ満足。画質が甘いという批判もあるようだが、どうなのだろうか。
今年最後の夕日を自宅の近所からスナップ。中央右に小さく富士山が見える。
エーテルは蘇ったのか？
ネット上の大方の反応はリリイではなく最近のSalyuそのものということのようだ。僕も最初に聴いた時はそのような印象を受けた。「清濁」感がない。特にハイトーン部分がリリイとしては受け入れられない。ボイストレーニングを積んだため、高音部がファルセットでなく地声で出るようになったということなのか。「グライド」「共鳴(空虚な石)」「飽和」「回復する傷」などの声は何処へいってしまったのだろう。
でも、僕にそんなことを言う資格はない。というのも、リリイをリアルタイムでは知らないからだ。初めてSalyuを知ったのは「VALON」。強烈な印象だったので今でもはっきりと覚えている。それは６年前のこと、スペースシャワーTVにチャネルを切り替えたら、ちょうど、二つの箱(そのときはバーコードとわからなかった)の中で右の男がマジメくさった顔でラップを歌っていた。左の女性がこのラップにどうやって加わるのかと見ていたら、祈るようなしぐさで両手を胸の前で絡めて目を閉じるではないか。ラップじゃない、と思った瞬間の第一声に衝撃をくらった。砂に水が浸み込むように彼女の声が僕の全身を包み込み、心の琴線に触れた。何十億光年もの彼方の宇宙から、あるいは、人類が滅び去ってしまった後の遥か遠い未来から届いたメッセージであるかのような声と旋律に釘づけになり、魂が昇華され宇宙と一体になった至高感のような感覚を覚えた。その後しばらく、他の音楽は全てノイズになった。
いったい、この女性は誰だ？
直ぐにネットで調べたが、あまり情報がない。YouTubeは既に登場していたが、音楽PVがアップされることはほとんどなかった頃だ。
男の方はRIP SLYMEのメンバであることは直に分かったが、そっちはどうでもいい。肝心の女の方の情報が少なかった。リリイ・シュシュという読者参加型のインターネット小説があり、それが映画化され、その中のカリスマ歌手という設定で登場したらしいことはわかった。現在は吉祥寺(下北沢だったか？)付近を中心にライブハウスなどで活動を行っているという程度の個人ブログからの情報しかなかった。椅子に座って歌うスタイルは当時からのものだ。
とにかく、「リリイ・シュシュのすべて」という本が角川文庫から出版されていることがわかり、早速いくつか本屋さんを探し回り入手した。
読んで驚いた。小説の中でのリリイに対する音楽描写は紛れもなく僕が「VALON」から受けた印象そのままだった。どういうことだ？小説中の歌手が実在しているということか？あるいは、これは単純な小説ではなく、小説形式のドキュメンタリーなのか？それにしても、どうして小説と実在がこれほど一致するのか？しかも形のないものに対して。僕は混乱した。
「リリイ・シュシュ、本名鈴木圭子。1980年12月8日生まれ。ジョン・レノンがファンの銃弾により倒れたその日に生まれた」これは事実だとずっと思っていた。それほどにまでに、この小説にはリアリティがあった。ネット上の掲示板での対話をベースにした小説という二重のバーチャルでありながら、掲示板に登場する人物には強い個性があり、リアルそのものである。十四歳前後の陰鬱な荒廃した日常の暗闇に射す一筋の光、それがリリイの音楽、唯一の救い。
小説を読んだちょっと後に、偶然にも(シンクロニシティか？)専門チャネルで放送された映画を観たが、内容にはかなり辛いものがある。何度も見たいという映画ではない。本とストーリが若干違う。暫く前から、YouTubeに全編upされているが、コメントを見るとほとんどが英語だ。「回復する傷」が映画「Kill Bill」にも挿入されているからだろうか。リリイファンが海外にも大勢いることは確かなようだ。
Salyuの魅力は一体どこからくるのか？とびきりの美人とか可愛いというわけではない(ときたまかなり可愛い表情もするけど)し、音程が外れることもよくある。話方はぎこちないし、歌がうまくて声の綺麗なシンガーなら他にいくらでもいる。言葉では説明できない何かがある。その無邪気な笑顔と包み込むような歌声と飾りけのないまっすぐな性格。それらが絡み合い具現化した一つの個を形成する。個人の感性の問題であり、好みは大きく分かれるものだ。
小説「リリイ・シュシュのすべて」の中には音源化されていない曲がいくつかある。しかも、「回復する傷」には詩がついている。これは何を意味するのか？もしかしたら、壮大な実験が行われているのだろうか。ネット上でリリイファンとSalyuファンの意見が食い違うのは、さながら、フィリア時代のリリイとその後のリリイのファンがお互いを主張しているのと同じだ。
リリイは現在進行形で実在して進化している。小林武史はSalyuのデビューを遅らせたのはリリイ色が抜けるのを待つためだと言った。しかし、それは不可能であり失敗に終わった。リリイを演じているSalyuとSalyu を演じているリリイ。両者が同一化することにより、歌姫を超えて神格化した新たな女神が誕生し物語は完成する。仮想と現実の融合。「エーテル」はその布石なのではないだろうか。リリイとSalyuが混じり合う「エーテル」を何度か聴いていらそんな妄想にとりつかれた。それは滑稽な妄想かもしれない。でも、一つだけ確かなことが言える。それは、リリイとSalyuの歌に出会えて本当によかった、心からそう思えるということ。
昨日のライブの状況をtwitterなどで見ると、リリイかどうかとは無関係に、とにかく良かったという意見が大半なので、本当に良かった。まぁ、ちょっと荒れているところもあるけど。
ライブには行かない怠け者のSalyuファン
PS.
初期の頃見たインタビュー記事がちゃんと残っていた。懐かしい。
Java回顧録 〜独白： 僕は全ての事をJavaから学んだ〜
先日Javaのコードを３年振りくらいで書いてみたら、無性にJavaについて振り返ってみたくなった。Javaの誕生当時をリアルタイムで経験した僕にとってJavaは感慨深いものであり、多くのことをJavaから学び、僕を成長させてくれた原点でもある。
僕とJavaとの関わりはJavaがまだOakと呼ばれていた頃から始まる。1994年の暮れの頃だったと思う。Oakで書かれたWebブラウザはWebRunnerと呼ばれていて、両者はほとんど一体だった。会社の上長からこれを使って携帯情報端末機器を開発することになったから、秘密裏に調査しておくようにと突然指示された。後になって知ったことだが、Oakは家電などの組込み系を想定して開発されたもので、当時Sunは日本の多くのメーカに呼びかけてOak を普及させようとしていたようだ。
その頃のインターネット事情というのは、Mozilla(Netscape)が登場してまもなくのころであり、その前進のブラウザであるMosaicが広く普及していて、新聞などではインターネットとモザイクが同義語として使われていたくらいだ。Googleもなければ、Wikipediaもなく、Flashさえなく、ブログも登場していない。ブラウザ上で動くものといったらMozillaのスプラッシュ画面でGodzillaが火を噴くパラパラアニメーション程度。国内のWebサイトも大学や大企業などが主で非常に数が少なかった。今では信じられない実に質素な世界だ。
そんな中、Oakが登場したのである。当初、OakとWebRunnerはオープンソースだった。FirstPersonというサイトから誰でも自由にダウンロードできたと記憶している。FirstPersonというのはOakを開発したGreenProjectの後の名前であり、Sunのエンジニア達による少数精鋭の組織である。Oakはその後、商標の問題からJavaという名前に変わり、WebRunnerはHotJavaという名前に変わった。
上長からは、キミなら興味を持つんじゃないか、とのことだったので、どんなシロモノなのか興味津々で動かしてみた。Linuxもまだ一部のマニアが使っている程度だった時代であり、動作はSun Workstation上に限られた。あたりまえであるが、Javaに関する文献・書籍等はもちろん一切なく、ソースコードとサンプルプログラムを読み解くしかない。
Javaを調査して半月くらい経ったとき、上長からJavaは今後主流になるものか、あるいは、このプロジェクトで終わるようなものなのか、どう思うかと聞かれた。僕は、これはインターネットに新たな革命をもたらす凄いものだ、一企業のものではなく、人類の財産になると答えたことを今でも記憶している。世間知らずの生意気な若造が随分なことを言ったという感じだったが、僕にとってそのくらい衝撃的なものだった。
Javaがどんなものかを技術的に解説したJ.GoslingらのWhite Paperも秀逸だった。まだ、ドラフトだったが、一般に、論文ではないこの手の冊子は事実と乖離して風呂敷を広げすぎていたり、単に企業の宣伝だったり、胡散臭さが感じらるものだが、このWhite Paperは読むだけで勉強になったし、技術に対する真摯さが伝わってきて、非常に感銘を受けた。恥ずかしながら、そのときはGoslingの名前も知らなかったが、これは本物だと直感した。
初期のJavaはJavaで書かれたクラスライブラリを除くC言語のネイティブ部分は５万行程度であったと思う。一人で全体を把握できるギリギリの規模だが、まとまったドキュメントがなく、ソースコードを毎日じっくりと丹念に読んでいった。パズルを解くような作業が連日続いたが、コードは宝の山だった。しかも、まるで一人の人によって書かれているかのように統一的で美しかった。全体を理解するのに１ヶ月くらいかかったが、とても充実した日々だった。開発者の情熱というか息遣いがコードの行間から感じられ、開発者と直接対話しているかのような錯覚さえ覚えた。
ソフトウェア技術者として知っておくべきことが、そこには全てあった。しかも、これらがほぼスクラッチからの実装になっている。記憶を頼りに当時の概要を列挙してみよう。
いわゆるスタックマシンであるが、実行時にバイトコードを書き換える(quick_*命令)など、メソッド探索などの高速化に工夫がされていた。バイトコード自体は目新しさはなかったが、変数の型に対応したバイトコードが定義されている。関数コール時のスタックの使い方やnativeコード間のデータ授受など実装がかなり勉強になった。デバッガはまだなかったが、デバッグのための情報が埋め込まれる仕組みが開発途上という状態で存在していた。一方、コードを読み始めた頃はスレッドもこのバイトコード上で実装されていると期待していたが、残念ながらそうではなかった。
マーク＆スイープ方式のシンプルなGCであったが、Cスタック上のオブジェクトのスキャンなどConservativeな実装のノウハウを具体的に知ることができた。ネイティブコードの中にSparcアセンブル言語で記述されたコードが若干含まれていたが、関数コールの際のWindowレジスタをマークする部分だった。インテル系だったらset_jmp()でレジスタの値をローカル変数上に退避すればよい技法である。
- スレッド
スレッドはOSが提供するnativeスレッドではなく、アプリケーションレベルで実装されていた。従って、Java自身はマルチスレッドであるが、OSからみたらJava全体がシングルスレッドだった。JavaのスレッドはGreen Projectの名前から、green threadと呼ばれていた。システムがアイドル時間に裏でGCが起動する機構を読み取ったときはちょっと感動した。コードの理解には苦労したが、スケジューラを含めたスレッドの実装を把握することができ、大きな糧となった。
当時、スレッドは上級プログラマの対象であり、気軽に誰でも使えるというレベルのものではなかった。Javaによって言語機能としてスレッドサポートされ、一気に大衆レベルとして身近になったことは非常に画期的なことだった。
- GUIツールキット
X11上のWidgetは使わず、Xlibレベルの最小限のネイティブコードがあり、それをJavaのクラスでラップして、その上にAWTがあった。Xlibはスレッドセーフではないため、至るところmutexの塊だった。
- グラフィックエンジン
当初のAWTは実にシンプルだった。Xlibのdraw系APIの一部を単純にコールしていただけで、回転やスケーリング機能もなく、線幅も１しかなった。Javaアプリで太い線を描くのには苦労した。さらに、曲線はOvalしかなかったと思う。
コアの極一部がCで実装され、コンパイラ(javac)はJava自身で実装されているというブートストラップ方式のコンパイラ。Java自身でコンパイルするため実行速度が遅かったが、コンパイラの勉強にはうってつけのコードだった。後にIBMからJikesというC++で実装されたJavaコンパイラがオープンソースでリリースされ、javacより非常に高速であったため、それが一時期、大変重宝した。
- ネットワーク
それまでC言語でsocket関数を使ってゴリゴリとコードを書いていた僕にとって、数行でHTTPクライアントが書けてしまうHTTPConnectionクラスは斬新だった。しかもプラグイン可能なプロトコルハンドラによりアプリケーションに独自なURIが定義でき、その潜在的可能性に新たな視界が広がった思いがした。
コードを読んでいると至る所にArthur van Hoffという名前が登場している。Netnews(java.lang.com)でもArthurが大活躍していた。いろいろな質問に丁寧に回答していて、最後のお決まりの Have Fun!という言葉を必ず添えていて、好印象だった。
幸運にも、そのArthurにパシフィコ横浜で開催されたJavaOne(だったと思うが)でお目にかかることができた。貴重な時間の合間に講演者控え室で軽いミーティングを持った。体格のいいカッチリした真面目そうな男だった。僕らは組込系にJava を使うことを検討していたが、AWTが重かった。その懸念を伝えると、TinyAWTというものがある。それを使ったらどうかと提案された。TinyAWTはまだ公式には知られていなかったが、ソースを読んでいたのでその存在自体は知っていた。Arthurはそれを趣味で自分ひとりで２週間で作ったとあっさりと楽しそうに言ってのけた。真のハッカーだ。僕は、GoslingはJavaの生みの親であるが、育ての親はArthurであり、その貢献はGoslingより大きかったと思っている。
それから３ヶ月後くらいだっただろうか。そのArthurがSunを去るということを突然自らNetnewsにアナウンスし、Java界に大きな衝撃が走った。Javaは今後どうなるのか？ArthurはSunを去る理由として、Sunにも大企業病が蔓延り、スピード感がなく、やりいたいことが思うようにできなくなっている、Javaの可能性はもっともっと大きいもので、自分たちはそれを追求していきたい、Sunを退社するのはそのための英断だ、といったような趣旨の内容だったと思う。ArthurがいなくなってもJavaは本当に大丈夫なのか？多くの心配が寄せられた。そのような懸念にもArthurは丁寧に答えてくれた。Sunには信頼できる優秀な技術者が大勢いる、自分がいなくなっても何も心配することはない、大丈夫だ、問題ない、と。
Sunを去ったArthurたちはMarimbaというベンチャーを起し、Castanetというサービスを始めた。MarimbaではJavaの名付け親でもあるKim PoleseがCEOになった。彼女はSunでもリーダシップを発揮していたが、若き女性実業家として、おまけに美人ということでマスコミにももてはやされた。僕もCNNのインタビューで見たことがあるが、直接会ったという人からはハリウッドの一流女優のようだったと聞いた。
Marimbaは製品のネーミングを南米の楽器に統一していたが、CastanetはCast-a-Netであり、ネットにプログラムや情報をキャストするという実にうまいネーミングだ。Castanetはその意味通りプッシュ技術であり、クライアントにダウンロードしたJavaプログラムも最小限のオーバヘッドで更新することができるという優れものだった。一時期大きく注目されたが、残念ながら日の目を見ることなく消滅した。今ではネットワークが十分高速であり、組込み系でも、OS含めてアプリ丸ごとバージョンアップも簡単にできてしまう。今から思えば、結局、彼らの目指したものも最初から淘汰される運命にあったということなのかも知れない。
開発を進めていた携帯情報端末について、僕自身はその後、Javaによるアプリケーション開発を担当することになり、ブラウザの中でローカルアプリケーションとネット上のアプリケーションがシームレスに連携するようなフレームワークを開発し、メンバがそのフレームワーク上に個々のアプリケーションを開発するというものを作り、一定の成果を収めたものの、残念ながらプロジェクト自体は失敗に終わった。今では当たり前のものであるが、当時は斬新な発想であった。方向性は良かったが、あまりにも時期が早すぎたのである。
プロジェクトが終了した後も、まだJavaは面白かったし、経験も生かしたいという思いもあり、全く別の分野であるがJavaを使うというプロジェクトに飛び込み参加した。１年程度開発に没頭したが、世間的にもJavaが広く認知されるようになることと反比例して、JavaBeansが登場した頃には徐々に僕の中ではJavaに対する熱が醒めていった。
さらに、Javaはクライアントサイドでは思ったように発展しなかった。ブラウザ中のAppletの起動は遅いし、頻繁に落ちたりした。Java2Dのデモを見たときは感動したが、それがJavaだからということであり、多くのネイティブアプリがLinuxでもWindowsでも走るようになってきたし、Javaを使うことによる開発者メリットはあっても、エンドユーザのメリットはほとんどなかったのである。
一方、サーバサイドのJ2EEが登場したことで再び脚光を浴び、新たな新天地が開けたが、J2EEは複雑怪奇で巨大な化け物だった。僕にとって、もうそこにプログラミングの楽しさを見出すのは困難であった。
数年間くらいJavaから遠ざかっていたとき、JavaScriptの処理系を実装するという仕事が舞い込んだ。OSS採用には色々な意味でまだ慎重な風潮があったから、自力で作るしかないし、それが求められていた。恐らく、JavaとJavaScriptの区別も付かないような人が、あいつならなんとなくできそうだという安易な人選だったに違いない。僕はといえば、正直、JavaScriptはよく知らなかったし、ノンプログラマが使うような取るに足らないつまらない言語と内心馬鹿にしていたくらいだ。趣味でLisp処理系をCで実装したことはあるので、まぁその程度だろうと高を括っていた。当時、JavaScriptに内部関数があることも知らなかったし、正規表現があることさえも知らなかった。そんな状態で、とりあえず、言語仕様であるECMA262規格書を読み始めたのである。それを読めば簡単にJavaScriptが分かると期待して。
ショックを受けた。書いてあることの意味がわからない。木は見えるけれど、森が見えないのである。書店に行き多量に並んでいるJavaScriptの本を見てみたけれど、どれも取るに足らない内容ばかりで、はっきり言ってしまえば、くだらないことしか書かれていなかった。ECMA262規格書から受けた、これは手強いぞ、という雰囲気が伝わるものは全くなく、単なるプログラミング入門的な本ばかりだった。
本で理解するなんて安易な方法が間違っていると気づき、かつてJavaのソースコードを読んでいた時と同じように、来る日も来る日もECMA262規格書を読んでいった。しかし、そんな悠長に勉強しているような時間はない。スケジュールは非常にタイトであった。言語を理解していないのに、その処理系を実装するというアクロバティックな状況であったが、プログラムを書かない日々は苦痛でもあっため、とにかくコードを書き始めた。
トップダウン方式のパーサを作り、抽象構文木を直接評価して実行するコアのプロトタイプを２週間ほどで実装した。でも、これではダメだと気付いた。メモリ消費が多く、パフォーマンスも出ない。書いたものはすべて捨てて、バイトコード方式に切り替えた。パーサにはBisonを使った。そのときには、内部関数も正規表現の概要も理解している積りだった。
しかし、愚かにも内部関数がクロージャに繋がることを理解したのは、それからずっと後のことだった。関数がfirst classオブジェクトであるような言語ならばクロージャがあって当然であるが、馬鹿にしていたJavaScriptにまさかクロージャがあるとは思ってもみなかったのである。ECMA262規格書にはそんなご丁寧なことは書かれていない。ECMA262規格書というのは、数学に例えるならば、公理だけが羅列してあり、そこから推論規則により導出される定理については一切言及されていない、という難物ものである。定理こそ含蓄のある深い意味を持つものであるが、それは冗長であるから必要ないという、よそ者が近づき難い高尚さ(?)がある。無味乾燥な規格書でも理解を助けるためのinformativeな記述があるのが普通だが、それさえほとんどない。ちなみに、結果的に廃案になったが、Edition4では実行可能な仕様記述言語としてのMLによる定義が進められていた。MLを理解しているプログラマがどれほどいるだろうか。
そんな状況だったから、クロージャを実現しなければならなとわかった時には、既に実装がかなり進んでいた。スタックのアドレスが連続した古典的なスタックマシンをベースにしていたので、そこにクロージャの仕組みを入れるのは困難であり、壁にぶち当たってしまった。現状の仕組みを変えることなく、全く別のものを入れるという難問である。解はあるはずとは思うが、すぐには思いつかない。僕は、しばしばこのようなときには、解決すべき問題を頭に積め込み、後はそのことは考えずに放っておく、いわゆる寝かせておくという手段をとる。うまくいくときもあれば、いかないときもある。一つの問題に捕らわれていると袋小路に入ってしまい逆効果なのだ。解は何気ない時にふと見つかるものである。今回も幸運なことに、うまい方法が見つかった。
一方、正規表現はOSSのPCREが利用できないかと検討していたが、ECMA262規格と動作が同じにならない部分があることがわかった。しかも、それは規格書の中の例として載っている正規表現で、間違っている方の動作になっているのである。PCREに手を入れるのは避けたかった。実用上はコーナーケースであるが、規格書ではそれは正しくないと敢えて明記されているのでる。しばらく途方に暮れたが、意を決してスクラッチから作ることにした。自分にそんな力があるだろうか？正直不安であるが、前に進むしかない。大学のとき勉強したオートマトンをちょっと復習して、パーサを実装し中間コードにコンパイルして規格書に記載されているアルゴリズムを実行する正規表現エンジンを２週間で作った。僕自身そんな短時間でできるとは思ってもみなかった。案ずるより産むが易しである。
開発はどうにか間に合い、製品に組み込むことができたが、JavaScript処理系など言ってみれば既に世の中にあるものであり、それと同じものを作ったところで、コードを書かない人から見れば、できて当たり前、その程度にしか思われない。しかし、それはそれでよい。他人にはできない、貴重な経験をさせてもらったわけだから。そして、真実を知らず、勝手につまらない言語と思い込んで馬鹿にしていたJavaScriptは今では大好きである。さらに、それ以前の自分とは異なる物の見方、視点、価値観などを得ることができた。プログラミングというのは、他に例えようのない唯一無二の特殊な内的活動だと思っている。そこから何を得るのかは人それぞれに異なる。
懐かしくてついついいろいろなことを書き過ぎたようだ。いずれにしても、あのときJavaと出逢ったことが、僕の技術者としてのその後の方向性を大きく決定付けたと感じている。人との出会い、本との出会い、技術との出会い、これらは気づかないと何事もなかったように過ぎ去ってしまうが、とてもとても大切なことなんだ。
円覚寺の紅葉
今日はプログラムネタのブログを更新しようと思っていたんだけれど、天気が良かったのでまたカメラを持って鎌倉に出かけた。といっても家を出たのは１時半ころ。
円覚寺はちょうど紅葉が真っ盛り。先日来た時と比べものにならないくらい、大勢の人がいた。もっと早く来ればよかったとちょっと後悔。
円覚寺を出て、そのまま歩いて八幡宮へ。キャンドルが灯されていた。何が始まるんだろうと待っていたら、やはり結婚式だった。昼間やるより、夜の方が周囲の注目度が高い。夏は暗くなるのがもっと後の時刻だし、真冬だと寒いので、今の季節ならではの光景（この写真には写っていないけど）。
それにしても、デジカメ一眼を持っている人の割合がかなり高い。そればかり気になった。おかげで、新しいカメラを買うぞ、という意思が強くなってきた。ボーナスで買おうかな。
ぶらりと鎌倉カメラ散歩
先週の土曜日のこと。その日は穏やかな小春日和で、久しぶりにカメラをもって散歩に出かけた。どこに行こうか何も決めていないまま家を出て、下り方面の東横線になんとなく乗り、横浜で横須賀線に乗り換え、なんとなく北鎌倉で降りた。
円覚寺の仏たち
いつもは前を素通りするところであるが、ちょっとためらった後、円覚寺境内に入った。何年ぶりだろうか。紅葉の季節にはまだ早く、観光客はそれほど多くない。これまで敬遠していたが、日常とは異なった空間に浸れてなかなかよかった。山門はいかにも古刹という雰囲気がある。
奥の突き当たりにある黄梅院の中に、円空の仏にも似た素朴な荒削りの千手観音と地蔵菩薩が並んでいる。地蔵菩薩にはキノコが生えちょうど賽銭受けとなっていた。
百観音は、以前は別の場所にあったものをここに移動してきたらしい。
国宝の梵鐘という標識があるので、急な石段を登り弁天堂に着いた。国宝という割には特に変わり映えはしない。
長閑な山間の風景が見渡せる。写真をとっていると「あれは東慶寺でしょうかね？」と声をかけられた。確かにそのようだ。東慶寺より建長寺へ行ってみようという気になったので行った。
建長寺の眺望
建長寺は円覚寺よりやや明るい雰囲気があり、観光客も多かった。三門は巨大だ。
こういうところはよく撮影禁止の文字があるが、それらしいものはなかったのでちょっと遠慮がちに撮ってみた。
どんどん奥に行き、半僧坊というところに向かった。突然、斜面に天狗がたくさん並んでいる。以前、見たことあるというデジャヴを覚えたが、確かにずいぶん昔に来たことあるかも知れない。
さらに上に行き、ハイキングコースの見晴台に出た。このハイキングコースは最初から最後まで何度か歩いたことがあるが、建長寺から上ったのは初めて。春霞のように遠くが霞んでいるため海がなんとか確認できる程度。
源氏山からハイキングコースを大仏方面へ
建長寺を出て、どうしようかと思って地図を見ると、北鎌倉方向へちょっと戻り、西に向かう細い道を行くと源氏山に行けそうなルートがある。初めて通る道は新鮮だ。ずいぶんと思った以上に岩だらけのゴツゴツした山道になってちょっと不安になったが源氏山公園の裏に出た。なるほど、こんなところに通じていたのかと思い、ついでなので銭洗い弁天に立ち寄った。いつも立ち寄るだけで、銭を洗ったことは一度もない。
弁財天から源氏山公園への急な坂道を戻り、ハイキングコースを大仏方面へ向かった。尾根伝いの山道は木々に囲まれているため景色が全く見えない。でもその方がよいのかもしれない。直ぐ近くの足元は住宅街だ。木々に囲まれていなかったら山の中を歩いているという感覚が薄れてしまうだろう。
ハイキングコースが終了し大仏トンネルの入り口に出る。大仏の近くはよく通るが、ここ３年くらい中に入っていない。いつものように観光客でごった返している。外国人もなかりの割合だ。大仏の中は大仏しか見るものがないのであまり興味がそそられない。
長谷駅方面に向かい、御霊神社に通じる細い道を右に曲がってしばらく行ったところの家の庭の柵に時計草が咲いているのを毎年見かける。西洋ではパッションフラワー(Passion Flower)と呼ばれている。日本人は放射状に伸びるめしべを時計の針に見立てたが、西洋人はキリストの十字架に見立てた。パッションとは情熱ではなく、受難の方の意味である。
Lily Chou-Chouが復活！
これは凄い。最近の曲はあまり好きになれなかったけど、まさかこんな展開があるとは思ってもみなかった。あの頃のSalyuに戻って欲しいよ。
