2007年4月アーカイブ

宗教音楽であるグレゴリオ聖歌に端を発し、ルネサンス～バロック～古典派～ロマン派～そして「クラシックの黄昏」である近現代における"クラシック"、現代音楽、ポピュラー音楽にいたる流れを、音楽そのものが、あるいは社会における役割が、どのような変遷をしてきたか、またその変遷にはどのような必然性があったかを分かりやすく解説してくれる良書。

プログラマ兼SE兼PMとして、ソフトウェア業界においてはおそらく人並みの苦労をしてきた自分がぼんやりと感じていたことがいくつも言語化してある。目から鱗が落ちるような気づきを与えてくれるというわけでは決してないのだけど、自分の中の暗黙知を形式知に変えてくれる、ありがたい本。

就職活動の際にも経験した、特に期限を定められずに結果を待つというこの状態。

それ以外のことがいま一つ手に付かず早くここから解放されることを切望する状態から始まり、時間の経過と共に期待（あるいは不安）がゆっくりと諦めに置き換えられていく中で、望みどおりそこから少しずつ解放されていくのが心地よくもあり、悲しくもある。そんな今日この頃。

そんなわけで原作に引き続き映画。

原作と映画を両方見るというのはおそらくここ数年では初めての経験なのだけど、原作を読んだ上で予告編をチェックしたところ、ちょっといまいちかもと思っていた。

人間の想像力というのは自分が思っているよりも優れているようで、文章から自分の頭の中で構築される世界はある意味自分にとっては最適化されていて、それはつまり、面白いシーンは最も面白く、悲しいシーンは最も悲しくなっているということに他ならない。対して、自分以外の誰かによって定められた形と音を持った映像が、自分にとっての最適化された世界という点においてこれを超えることができるかどうかといえばそんなわけはなく、それゆえ原作と比較した場合にはどうしても感情の振れ幅の小さいものになる。

ただ、実際観てみると映画は映画で優れていた点がいくつかあり、一つは原作にはないエピソード、すなわちサプライズ。

そしてもう一つは、自分にとっての最適化がなされていないが故のリアリティ。それはたとえばお葬式のシーンであり、あるいはオカンが抗がん剤治療で苦しむシーン。これらのシーンは自分の頭の中ではそれはもうドラマチックに仕上がってしまうわけだけれど、映像というある種の実体を与えられることにより想像の余地が狭められた分、逆に「実はそれほどドラマチックではない現実」というリアリティを持つようになるという一面もある。そのリアリティは当然のごとく現実の残酷さというものを際立たせることになり、際立った残酷さは一方で残酷さの対角にあるものを際立たせることになる。

というわけで、これはこれで意外とよかった。☆☆☆☆★

映画を見に行く予定なので原作をチェック。決して世の中の平均的な家庭ではないものの、さりとてそれほどドラマチックな事件が起こるでもなく淡々と進んでいくそれぞれの半生。と、ところどころに現れるちょっと良い話、ちょっと良い言葉。そんな、人生そのものみたいな本。基本的には人生をそのまま書いた本なので、人生そのものみたいなのは当たり前なんだけど。

携帯でPCのメールが読める「リモートメール」。便利なサービスなんだけど、なぜかスパムフィルタがついてなくて超不便なため、自分でスパムフィルタ付きのそれを作ろうと思い立ちとりあえず設計までは完了した。

そんなときに颯爽と登場した 携帯対応 Gmail。普段使いの Gmail アカウント宛てメールと混ざるのもうっとおしいので、それように Gmail アカウントをひとつ作成し、会社の POP を設定。そして携帯から見てみると・・・見事スパムフィルタが効いた状態で携帯からPCのメールにアクセスできた。

というわけで自分の中ではちょっとあついプロジェクトだったのだけど、車輪の再発明はしない方向で。Gmail のこの使い方はちょっとした TIPS になりそう。

非常に地味といえば地味な作業なのだけど、いけてないSQLをいけてるように直した時の絶大な効果といったら100倍速いとかざらなのですごいカタルシス。時間の見積もりがしずらいのが難点だけど、この作業は何気に熱いかも。

元はといえば自分の書いたいけてないSQLが原因なので、ただのマッチポンプだろって話もありますが。

しかしこれって、お客さんが素人で性能要件や契約がしっかりしていない場合、わざといけてないSQLを書いておいてサービスが軌道に乗った頃に表面化するであろうパフォーマンス上の問題に対するチューニングで追加費用をいただくという方法がかなり成り立つ気がする。運用されているサービスのパフォーマンス改善はたいていの場合急を要するし、そうでなくてもベンダーの変更など到底現実的ではないので。

当社は人情あふれる会社なのでそんな悪いことはしませんが。

PostgreSQL の VACUUM FULL は定期的に行う必要はないということになっているみたいだけど、某システムにおいて大量のデータを日次で全件 DELETE -> INSERT という乱暴なことをしていたら日次バッチの pg_dump に時間がかかりまくるようになって死にかけた。

当然、ファイルも異常に大きくなっていたので、やっぱり VACUUM FULL 必要だよね、と思ったのだけど VACUUM FULL するより DROP TABLE -> CREATE TABLE -> INSERT の方が早いっぽいのでその方向で。

ちなみに余談だけど、上記の状態では SELECT COUNT(*) FROM hoge; とか SELECT * FROM hoge; で死ぬほど時間がかかっていた。Sequencial Scan で削除マークなしの行を探すから時間がかかるってことだろうか。この SELECT * FROM hoge; で超絶時間がかかっていたというところが、pg_dump で時間がかかっていたことにつながるのだと思う。

どうやらなくしたらしいので2つ目を購入。

なので、多分近日中になくしたはずの古いのが見つかると予想。人生は多分そういうものだ。

9月に某学会の年次大会＠大阪でちょっぴりお話をする予定。

人前で話をするというイベントはどっちかというと避けて通りたいのだけど、将来的にはやはり人前で話ができたほうがいろいろ便利だろうということで、断ろうと思えば容易に断れた本案件も2つ返事でおｋ。何事も場数が大切なのだ。

あるいは、久しぶりに出張というやつをしてみたかっただけという説もあり。