祈祷連歌

まるまる１ヶ月もブログをさぼってしまっている。 ４週間たったのでブログのトップページから記事が押し出されてなくなってしまった。 こりゃいかん。つなぎで何か書いておこう。

昔私がサラリーマンだったころ、そこはコンピューター関連商品を扱う商社だったのだが、 私の役割は「技術的なことはなんでもやる」だった。いまでもそんな感じだが。

社内で一番若いこともあって下っ端として海外のソフトの移植からマニュアルの翻訳、 社内のコンピューターの設定、ビジネスショウーなどでの荷物の搬入など、あれこれやらされた。 納入したソフトが不具合があって、現地へサポートへ行ったら、 その輸入ソフトのバクということが分かり現場でできることなどなにもないのに、 ３日ほど帰してもらえなくてもらえなかったことなど、いまとなっては思い出のひとつだ。

普段お客さんのところへ直接顔を出したりはしないのだが、 しばしば営業の人に連れ出されていたりもした。 その大先輩いわく「『忙しい』という言葉は客先では絶対に使うな。 忙しくない人間などいないのだから言い訳にしか聞こえない。」とのこと。

以来、忙しいという言葉は極力使わないようにしている。

フリーになって感じるのは、「サラリーマンほど『忙しい』を連発する」と いうことだ。実際にどうかは関係がない。 要するに『忙しい』が社交辞令的な一種のエクスキューズになっているわけだ。 サラリーマンを相手にしていると、心を亡くすとはこういうことかと理解してしまうことがよくある。

現在私など複数の納期がバッティングする羽目におちいって３方向にたいしてそれこそ眠る暇もないほどあっちいったりこっちいったりしているが、 絶対に忙しいと口にだしてはいないし、そういう状況を匂わせるようなこともしないように心がけている。でも、打ち合わせのための空き時間のすり合わせや、メールの発信時間などから、忙しくしていることは相手に伝わる。 どこも付き合いが長いので、けっこうそのあたりは理解してくれており、ありがたく甘えさせてもらっている。

しかし、新婚１ヶ月目だというのに連日徹夜＋ちょっと仮眠の繰り返しというのは、 忙しいとしかいいようがないなぁ。あと１ヵ月のがんばりだな。

今回のOOEnkaiは沖縄料理ふらり銀座店で沖縄料理。

豆腐料理ででてきたうみぶどうというのは初めて食べた。 沖縄は大学のときの先輩が住んでいるし、スキューバのアシスタントインストラクターの免許保持者としては自分としては浅からぬ縁のある地域のつもりだったのだが、こういうものを知らなかったのはちょっと間抜け。たいして種類がでたわけではなかったが、料理は全般的に可もなく不可もなく。沖縄料理にしてはちょっとぼんやりしたかんじもなきにしもあらず。

店は凝った雰囲気作りに腐心するのでせいいっぱいで、サービスにまでは手がまわってないというところか。はぶさんが大激怒。店長が呼び出されて正座して説教うけてました。にもかかわらず最後までオーダーもれが残って会計のときになってそれが指摘されてやっとでてきたというのはちょっといただけない。私も最初に灰皿を頼んだのに出てこないから自分で取りにいったぐらいだったし。

でも昨日のはぶさんはテンション高かったなぁ。m_pixyさんとずいぶんと熱く話し込んでいたようだった。私は長テーブルの逆側にいたので具体的な内容は断片的にしか分からなかったのだけど。

１１時過ぎてから店が閉まって、皆さんは２次会へ。新婚の私は１次会で失礼させてもらいました。

最近はメールのスパムが安定してきたように思う。 といっても相変わらず毎日１５通ほどのスパムが届いているようだが、 新規パターンのものがないのでブラックリストへの新規登録は激減している。

ところが、その分ふえたのがブログをターゲットにしたスパムだ。 これには２種類あって、ひとつはブログのコメントにスパムを投稿するというもので、 もうひとつはトラックバック先がスパムになっているというものだ。 世間的にこういうのもスパムと呼ぶかどうかは知らない。

こういうのは見つけると消したり、ＩＰの範囲で拒否設定をしたりしていたし、 ＭＴのソースを少しだけいじって特定キーワードを含むものを投稿拒否するように改造していた。

ところが、先週なかごろ約１時間に１通のペースで執拗にトラックバックをつけてくるところが出現した。うっかりクリックするとオンラインポーカーのサイトへ誘導されるというものだ。

特定キーワードで拒否するような改造は、ソース中に暫定的にハードコードしてしまっていたし、 コメント投稿部とトラックバック受信部で共通するので、MT::Util.pmに追い出して共通化した。MT::App::Comments.pmのpostとMT::App::Trackback.pmのpingからこのUtilityを呼び出す。

これで別途リストアップしてあるNGワードにひっかかるコメントとトラックバックは「お前はスパムだ」というようなメッセージとともに受付を拒否できるようになった。

件のトラックバックはとりあえずなりを潜めたようだ。

ここのところブログをサボっていて、つまり読書記録もサボっていた。 サボっている間に読んだ文庫をまとめて記録することにする。

文庫の読書量はここのところはずいぶんと減ってしまった。 もっとも文庫といっても、ＳＦだのそんなものばかりなので、 読書量が減ったといってなにがどうなるということでもない。

起こったことを淡々と文字にしていくだけの極めて映画的なものなので、 最近の本にはちょっとみられないタイプであると思う。 ただ、ファンタジーというジャンルでのそういう映像的な描写が、 迫力のある内容をもたらしているのではないかと思う。

内容が古典的過ぎてちょっとタルイかんじもするが、 どのストーリーもオチがあっさりしているので胸焼けするようなしつこさはない。 ヒロイックファンタジーというジャンルがどういうところから始まったのかを 知っておくという意味では一読の価値があるのではないだろうか。

これを読んでいて思い出すのがグインサーガなのだが、 そろそろ１００巻になるはずだが、あれはどうなったんだろう。 ７０巻あたりでうんざりして読むのを止めてしまったのだが。 最初の１０巻あたりはこのシリーズの血をひいた話だったと思う。

シリーズが完結したらもう一回読む本とする。

半分は惰性で読んでいるシリーズだが、読んでいて面白いからしょうがない。

いくつもの重層的に折り重なるエピソードが同時進行するし、登場人物が多いので、 新刊を読み始めるとしばしばどんな話であったか忘れてしまって困る。

相変わらず女性が強いが、ここしばらく女性陣の内面もよくでてくるようになった ので、その強さが違ってみえてくるようになったと思う。ただ、もうちょっと人物を 書き分けられないものか。

物理学の歩みに関して数学がどのようにからんでくるのか、というさまざまなエピソードが面白い。 物理における数学とは、単に物理学の問題を解くためのツールとして使われているわけではなく、 その物理学の発展とともに数学もまた発展してきたのだということがよくわかっていいのではないだろうか。

カオス理論などまだまだ発展途上の分野も紹介されており、 ソフトウェア工学などにどのようにかかわってくるのだろうかと考えると楽しくなる。 ソフトウェア工学ではまだまだ数学というのは問題を解くための補助概念というところに とどまっており、どちらかというと「数学＝数式」という構図から毛嫌いされているのが現状だ。 そう思うと、３年もすれば古いものになってしまう個々の技術を紹介する本だけでなく、 こういった本こそソフト屋さんたちに読んでもらいたい。

ソフトウェア工学が今後どのような方向にむかっていくのかはわからないし、 しかも生まれてまだ間もない分野であるので、数学がどのようにかかわってくるのかとか どのぐらいの比重をしめるようになるのかといったこともまったく想像がつかない。 今後Small Worldやカオスなんかはどんどん導入されていく可能性があると思う。 今後どうなるか楽しみだ。

物理の話にもどると、物理に触るのは大学の授業が最後だ。 それ以後はこういう一般教養の範囲でしか触れていない。 だからだろう、こういう本で順を追って説明されるとすごく勉強になったような気がする。

全体的にパワーダウンの感が否めない。

ドラマもない。

ストーリーが都合よすぎ。

この作者のもう一方のシリーズもそうだが、最近はちょっと惰性に走りすぎ。

ソウヤーの作品は、どの作品も作者の優しさがしみこんでいるので、安心して読める。

解説にもあるが、一部突っ込みたくなるような物理の理論や現象の描写とかもあるが、 ソウヤーの作品の見所はそのドラマの作り方だろう。最後ちょっと駆け足な感もあるし、 ネアンデルタール人側の世界での裁判のエピソードなどもちょっと消化不良を起こして いるようなところもあるので、このストーリーはもっと引っ張っていっそのこと１・２巻 にわけてもよかったのではないだろうか。

人間社会とネアンデルタール人社会が接するとどうなるかといえば、 おそらく悲しい話が登場するのは不可避であろうと想像する。 続編があるなら、そのあたりソウヤーはどう収拾するのだろうか。

もちろん、オブジェクト間のメッセージという概念には、一番抽象的なレベルでは、 同期か非同期かといった区別は存在しない。

ただ、抽象化のレベルをどんどん下がっていくと、どこかで同期メッセージと 非同期メッセージの区別が生じるところがあることは確かである。 一番底辺のマシンコードのレベルまで降りてくると、そこでは理論上は全ての メッセージがマシン語のサブルーチン呼び出しのコードにまで分解される。

このマシン語のサブルーチン呼び出し自体は同期呼び出しである。 当然ながら、上位の抽象レベルでのメッセージがそのままマシン語のサブルーチン呼び出しになっているわけではない。 しかし、最終的にはメカニズムとして同期するような仕組みにまで分解されることは確かで、だから非同期式のメッセージも同期式のサブルーチン呼び出しや割り込み機構によって実現される。

すると、非同期メッセージというのは同期メッセージによって実現できるのではないだろうか、と考えることができる。実際、マシン語のレベルにいたるまでのどこかでは全ての非同期メッセージは同期式のサブルーチン呼び出しに分解されているわけなので、少なくともこの考えは方向として間違ってはいないはずである。

抽象化のレベルの階梯を上から下がっていくと、 どこか途中で同期非同期の区別が必要となり、 さらに下がるとどこかで同期式に統一されるということになる。 この区別が必要となる条件はどのようなものなのだろうか。 同期と非同期というのは、どちらがより本質的なものなのだろうか。 単に歴史的経緯がその区別を必要なものにしてしまっているだけのような気もするが。

ここ1ヶ月ほど大量のシーケンス図を描く機会に恵まれた。 今まではシーケンス図などは、ちょっと設計を確認する場合とか、 後になってからドキュメントを書くときにちょろっと必要になる程度だったので、 あまり積極的には活用してこなかった。 しかし、最近はなるべくＭＤＡなどを意識してしまうことが多く、 シーケンス図などからコード生成させる方法などを考えてしまうので、 いきおい、シーケンス図が必要になったときにはなるべくそこに全てを記述しようと 試みることになる。

シーケンス図そのものはソフトの挙動のほんの一スナップショットを例示しているに 過ぎない。だから、それだけでコード生成に足る記述は本質的にはできない。 ソフトの動的な側面を完全に記述するには、シーケンス図に加えて、 フローチャートなりアクティビティ図なりなんらかの別の手法を組み合わせて、 挙動の抽象的な側面を補足する必要があるのだ。

つまり、ソフトの動的な側面を記述するだけでもいくつかの抽象化のレベルをまたいだ仕組みが 必要になるというわけで、シーケンス図自体でもそういうことになるだろうと思う。 すると、まず最初に思い浮かぶのがオブジェクト間のメッセージで、 その記述自体もその抽象度のレベルに合わせて何段階かあるだろうということになる。

で、思ったのが同期非同期の区別はどこまで本質的なものなのだろうかということであったわけだ。

非同期メッセージは同期式のサブルーチン呼び出しに分解できるのは上で見たとおりだ。 ある特定のＣＰＵに、あるいは、ある特定の言語の、さらにいえばあるライブラリセットの、 プラットフォーム依存の形では全てのメッセージは同期式のなにかに分解される。 逆にプラットフォーム非依存の形においては同期非同期の区別はどこまで必要なのだろうか。

非同期メッセージは同期メカニズムに分解できる。 一方、同期メッセージも非同期メカニズムに分解可能だ。 マシン語のレベルまで下がろうとすると非同期から同期へ分解されることになるが、 そこにいたるまでのプラットフォームによっては全てが非同期というのも、極端だが、考えることができる。全てが、というわけではないが、ウィンドウメッセージなどそのいい例だろう。

同期非同期がらみで、抽象化のレベルとそれらの区別の必要性の条件というのをはっきりさせないと、シーケンス図をはじめとする動的なソフトの挙動の記述からコードを生成する仕組みは、 膨大な経験則の塊になってしまうのではないかと危惧する。 より本質的な部分とより実用的な部分、この二つの観点の切り分けをはっきりさせる必要がる。 今年の１００プログラムには、ちょっと初心にもどって、このシーケンス図も含めることにしよう。