2012/08/08

『Full Dark, No Stars』

「人の心の暗部を描く」って言い回しは良く使われるけど、キングが本気出すとこうなるのか！ キングの作品はこれまでも人の心のダークサイドを扱ってきたけれど、 どこかに希望を残す話も多かった。 ここに収められた中短篇5編は容赦がない。本人があとがきで書いているように、 キツい(harsh)話だ。けれどもそこには真実がある。あとがきより：

It [The art of story-fiction] is the way we answer the question, How can such things be? Stories suggest that sometimes---not always, but sometimes--- there's a reason.

本を閉じた後でも、心に何かが刺さってて、考えずにはいられない。

『1922』 - 恐ろしい犯罪の告白。因果が自分に返ってくる、という類型の話を キングはいくつか過去に書いているが、この「取り返しのつかなさ」具合が、 1920年代の米国の田舎の孤独感の描写と合わさって絶望的。 書き出しがまた巧みで、最初のパラグラフを読んだらもう最後まで読まないわけにはいかない。

『Big Driver」 - ストーリーテリングとしては本書中で一番。 前半の描写がキツくてついてゆくのが辛いけれど、後半の展開がすごい。

『Fair Extension』 - 昔のキングの作品がエコーする話だが、 これも容赦ない。人間の心の暗部という点では本書中最も暗い話かも。

『A Good Marriage』 - これだけは読後感にかすかに希望があるかも。 どんなに近くにいてどんなに長く連れ添っても、決して分からない部分というのが 誰の心にもある。でもそれが見えてしまった時にどうすれば良いか。

『Under the Weather』 - ペーパーバック版に追加で収録された短篇。 短篇の妙味（キング曰く「暗闇でのつかの間のキス」）が味わえる作品。 とても悲しい味だけど。

それにしてもキング、もういい歳だというのに、テーマの掘り下げはますます深く、 技法はさらに冴えてきて、限界を広げようとしているのが感じられる。 作り手はそうあるべきだ、と言うのはたやすいが、一生実践するのはたやすいことではない。

Tags: 本, King

2012/08/02

Stravinsky

録った。ストラヴィンスキーは初めて。最初、楽譜を見ながら音を拾ってった時はわけが わからなかったけれど、弾いてるとだんだん意味をなしてくるのが不思議。外国語の学習みたい?

• Stravinsky: Tango for Piano

ストラヴィンスキーのピアノ作品の中では、比較的アプローチしやすくて かつ「ストラヴィンスキーっぽさ」が味わえる小品ではなかろうか。

Tag: Piano

2012/08/01

狂犬病への免疫

数日前に狂犬病について書いたばかりだが、ペルーの一部の地域では、 狂犬病にかかってもワクチン無しで生き延びた人がそれなりに居るらしい。

Some Rabies Patients Live to Tell the Tale - ScienceNOW

• 過去数年、狂犬病の発生が報告された地域の住人から血液サンプルを取って調べたら、1割くらいのサンプルで、本人にワクチンを受けた覚えがないのに抗体反応が出た。
• 多くの人は自覚症状さえ無かった。
• 抗体が出た人には高齢の人が多かった。
• かなり弱い種類のウィルスに複数回晒されることで免疫を獲得したのかもしれない。

ブラック・ジャックのエピソードにでも出てきそうな話だなあ。

Tag: Science

2012/07/31

デジタル世代

らむ太に「へのへのもへじ」を教えたらたいそう面白がったのだが、 「あ、そういうのぼくもしってるよ」という。「書いてごらん」と紙を渡したらこう書いた：

(^_^)

Tag: 生活

2012/07/31

マニュアル無視?

ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認

　ところが、A氏だけはマニュアルに従わず、自作の「更新プログラム」を利用してシステム変更を行っていた。A氏は今回の事故発生時だけではなく、以前から独自の作業手順を実行しており、上長もこれを認識していながら容認していた。

まあ結果的に事故が起きてるんだし過失は確かなんだけど、 「マニュアル無視の独自手順」っていうふうに取り上げるのに何となく違和感が。 これが工場の事故だったら確かに重大なんだろうけれど。

計算機システム管理の場合、マニュアル自体の変化が工場の工程などよりもずっと 高いし、設計/管理とオペレータの区別も曖昧だ。ある程度ベテランの オペレータになれば自動的にマニュアルを書く立場に立つんじゃないかってこと。 業界によってはwranglerとか呼ばれる、ほんとうにマニュアル に従ってオペするだけの人もいるけれど、自前スクリプトを書き始めた時点で もうマニュアルを書く側に足を突っ込んでると考えられるんでは。

工場の生産工程なら、マニュアルというか決められた工程というのは「固い」もので、 現場との齟齬が出てきたらそれを調査して上の方にエスカレートして、 偉い人が熟慮の上工程を設計しなおすか現場を教育しなおすかってことになるだろうけど。 計算機システムはもっとずっと柔らかくて、現場の「わかっている人」がどんどん マニュアルを書き換えるくらいで良くて、重要なのはその書き換えが複数人の チェックに晒されるレビュープロセスの方じゃないかと思う。つまり件のサーバ事故で ほんとにまずいのは「マニュアル無視を黙認」の方じゃなくて、作業のレビュープロセスの 方だったんじゃないかと。それがスムーズにいってるなら、 「実際に行われる作業＝承認を受けた工程＝マニュアルに書かれるべきこと」 という3者が自動的に一致するので、マニュアル無視ということが起き得ない。

「レビューを通さないと実行できないよ」っていうマニュアルを無視していたって 可能性もあるか。それだって、レビューを通さないと実行できないシステムを 作ってあれば良かったわけで、 やっぱり、「マニュアル」という規範が最初にあってそれに従う、っていう前提が 落ち着かないんだな。

ああ、もしかすると。プログラマにとっては「コード」が規範なので、 コードとマニュアル(自然言語で書かれた手順書)が乖離していたら おかしいのはマニュアルの方だろ、って反射的に思うのかもしれない。 仕様に対してはコードが従だけど、マニュアルに対してはコードの方が主なんじゃないか、と。 もちろんマニュアルからのフィードバックでコードや仕様が変えられることはあるけど、 主要な流れとしては。

(もちろん、「一人だけ勝手なスクリプト作られても他の人が理解できないよ」といった 個々の現場の事情はあるんだろうけど。それだってスクリプトをリポジトリに上げさせて 別の人がレビューしないと本番環境にチェックアウトできないとか、 全員に使わせる前提でなくても何とかなりそうな気はする。)

Tag: Programming