ただのにっき

■ イーガンは短編から入れ

にじむさんのトコのツッコミ欄でイーガン読むならどう読むか的な話をしていたら、とつぜん翻訳者の山岸さんが降臨するという事態になって、なかなか楽しかった。これだからネットはやめられん。

にじむさんはやたらと恐縮しているが、SF系日記更新時刻Rとかに捕まったら、関係者の目に継続的にさらされることは覚悟しないとね。……む!? ってことは、ここに要望とか書いておくと、出版関係者に読んでもらえたりするわけか。「スコーリア戦史の続きを出してくれぇ」とか(そこかよ)。

しかし、読まれる覚悟はすべきだが、手加減もすべきではない。関係者の目を気にして書くことをためらっても、誰も得をしないであろう。まぁ、作者は気をよくするかも知れないが、書かれるべきことが書かれないことで読者が損をしたら意味がない。

というわけで、「イーガンの長編はSFマニアのもの」という意見を変える気はないんだけど、山岸さんのツッコミと、言いたいことはたぶん、ほぼ同じなんだよね。表現はだいぶ違うけど。もし、いきなり前戯もなしに『ディアスポラ』を勧めてくるようなヤツがいたら、ソイツは誠意に欠けるSFファンだと思うな、おれは。SF読みなら、この本はSF耐性のない人にはキツいということを意識すべきだと思う。ちゃんと楽しんでもらうために、体を慣らしてもらおう。

だから、イーガンを勧めるなら、まず短編集を読ませよう。イーガンの短編には、SF読みじゃなくても楽しめるくせに、SFの素晴らしさがはちきれるほど詰まっている、稀有な作品ばかりだ。読んでいるうちにSFの楽しみ方が自然に身につく。イーガンほどSFに対する急峻な学習曲線を持った作品を書ける作家はそういない。

で、「うん、面白かった!」と言われたら、もう大丈夫。『万物理論』なり『ディアスポラ』を勧めよう。いきなり『ディアスポラ』を読ませるのは、目隠しをしてジャングルのど真ん中に連れてきて放置するようなもんだし、しかも相手は10次元のジャングルなんだぜ? でも、短編集を読めた人なら、きっと長編も楽しめるだけの「SF耐性」を身に着けているので、こんな「マニア向け」の作品だってちゃんと読めるはずだ。

■ 手の込んだスパム

夕べ受け取ったスパム(エロ系)がなかなか面白く、腹を抱えて笑った。

差出人は、大学の研究者「秋山都子」を名乗る女性。男性の新鮮な分泌物(とかボカして書かないと変な検索にひっかかるようになっちゃうので)が必要なので協力して欲しいという内容。

設定に作りこみが足らなくて、ボロが出てはいる。アドレスがyahoo.co.jpだったり、「医学部二年」だったり、「ホテルの一室で口と手を使い」なんて書いてあるあたり。しかしこの季節、卒研の資料を集めるためにぶしつけなメールを送りつけてくる学生が少なくないので、微妙なリアリティをかもし出していて面白かった。それにしても、よく考えるよなぁ。

＃全文掲載してる人を見つけた→おいらブログ

■ check*padを使い始める

check*padが携帯対応したとのことなので、ようやく使い始めてみた。アカウントは以前取っておいたんだが、PCからしか使えないtodoリストには価値を見出せないので、寝かしておいたのである。障害を排除すると新しいユーザがつくというのは、昨日紹介した『Joel on Software』でまさに書かれていたことだな!

Palm依存度がどんどん下がっている一方、携帯のタスクリストはショボすぎて使う気になれなかったので、check*padで置き換えられれば、という目論見。とりあえず買い物リストを作って、頭に「YYYYMMDD」を挿入した形式で管理してみることにした。これで、自動的に昇順にソートされれば文句なしなんだが。

用途が思いつけば、共有リストも作ってみたいところ。

残念ながら上の記事のコメントにあるように、おれが使っているW31SAで簡単ログインが動かない(コメントはW21SAだが)のが困った点なんだが、たぶんすぐに修正されるだろう(とプレッシャーTrackBack)。

■ Ruby 1.8.4リリース

例によってなんの手伝いもできないままリリースされてしまった。リリースに携わった皆さん、お疲れ様でした。せめてpreviewでtDiaryの動作チェックくらいしようと思っていたんだけどなぁ。まぁ、例によって先っぽを突っ走るサーバでちゃんと動いているようなので、よしとしよう。

＃第一はsargeなので、たぶんずーっと1.8.2のままです。

■ google_analytics.rb更新

トラッキングコードの挿入位置がheadからbodyに変更になっていたようなので、contribにあるプラグインを更新。

tDiaryでfooter_procを使うと、厳密にはbody要素の末尾には来ないんだけど、ま、たぶん影響はないだろう。つーか、おそらく従来どおりhead要素に入れておいてもほとんど変わらないと思われ。

■ Joel on Sofware (Joel Spolsky / 青木 靖)

Webでも読める有名な「Joel on Software」の書籍化なんだけど、未訳の文章も収録されているそうなので、ソフトウェア関係者は必読(逆にWebにしかない文章もあるので、Web版も必読である:-)。

今回、付箋紙読書をやってみたんだけど、付箋の挟まっている部分が前半部分に集中していたのが面白いと思った。前半はJoelの実体験をベースにした実践的な話題、後半は(実体験から演繹された)他者への言及が少なくないからだろう。実践的なほうが心を打つ。もっとも、前半と後半でJoelのスタンスが大きく変わっているわけではなく、可能な限り自分自身の体験からはみ出さず、リアルであろうと心がけているように感じた。そういう意味で、非常に「誠実な」本である。

話題は多岐にわたり、いちいち言及していたら書評だけで本になってしまいかねないので、アジャイルに関する部分にだけ述べておきたい。個人的に一番「おもしれぇ」と思ったので。

Joelはどちらかというとアジャイル手法には懐疑的で、特にXPについては本書中でも(中立なふりをしつつも)批判的な書き方が目立つ。Microsoftをはじめ、パッケージ製品を開発してきた経歴からして、ある程度予想できる姿勢ではある。また、中途半端にアジャイル手法を聞きかじっている読者にとっては、「仕様書を書け」だの「スケジュールを立てろ」だのと、いささか古臭く感じる表題が並んでいる。

しかしながら、中身をじっくり読むと、じつにアジリティに溢れたことを言っているのである。パッケージ製品開発において、実際の顧客をプロジェクトに招き入れることは不可能だが、Joelの言う「プログラムマネージャ」はまさに顧客(プロキシ)に相当する作業をしている。仕様の提示がプログラムマネージャの仕事であるだけでなく、仕様の変更については(力関係ではなく)プログラムマネージャとプログラマの話し合いで決めるというところまでXP的だ。

Joelの言う「仕様書」もまた、(変更不能な聖典ではなく)必要に応じて随時書き換わる。内容もまるでストーリーカードだ。また「スケジュール」はプログラマが立てるし、時間単位で管理され、実績に応じてこれも書き換わる。他にも「デイリービルド」に「ペーパープロトタイピング」と、おなじみなものを含め、Joelが提示しているのはまったくアジャイルな手法なのだ。

ここからわかること。Joelは誰に教わるでもなく、自らアジャイル手法をあみだし、身に着けたこと。そしてMicrosoftもまた同様に、アジャイルが世に受け入れられるよりも以前から、アジャイル開発を実践していたこと。なるほど、Microsoftには、おいそれとかなわないわけだ。