ファーシーアの一族と道化の使命

洋物のファンタジィでは久しぶりの当たりでした。

＜ファーシーアの一族＞　著：ロビン・ホブ、訳：鍛治靖子 
　　・騎士の息子(上・下)
　　・帝王の陰謀(上・下)
　　・真実の帰還(上・下)

全て文庫本（創元推理文庫※）です。
もともと小さな字がビッシリとある本なのに、巻を追うごとに分厚くなっていきます。
６分冊で　1.6cm  -> 1.4cm -> 2.6cm -> 2.4cm -> 2.8cm -> 2.8cm。
しかも、話がなかなか進みません。よくこんな本が売れるものだなと思います。
まぁ、読み始めれば、面白いのですがのですが。

　　　　

　　　　　　　　
　　　　　　　　　　　　

翻訳者の鍛治靖子氏は、ファンタジーの翻訳時にはできるだけカタカナを使わないようにしているらしく、「火酒」など、普段は使うことのない古風(？)な日本語も楽しめます。
ただ、本作では、名前の意味が重視されていて、意味のある（英）単語が人（や馬などの動物）の名前として付けられる文化を持った世界となっています。読み出せばすぐに分かることですが、タイトル中の「騎士」「帝王」「真実」も、実は登場人物の名前です。
ちょっと意地の悪い楽しみ方になるかも知れませんが、このあたりの翻訳の苦労を想像するというのも、一つの楽しみ方でしょう。

なお、続編も刊行中です。

＜道化の使命＞　著：ロビン・ホブ、訳：鍛治靖子
　　・黄金の狩人(１・２・３)
　　・仮面の貴族(１・２・３)

続編の「道化の使命」では同じ３部作ですが、各部３分冊になっています。

１冊が普通の厚さ(1.6cm程度)で、行間の隙間も広くて読み易いです。

しかしこの続編、最後の第３部が未翻訳です。早期の翻訳を望みます。
　　　　
　　　　　　　
こうして並べてみると、「道化の使命」の表紙は、３冊で１枚の絵になっていたのですね。
全く気がついていませんでした。

※創元推理文庫
　東京創元社の文庫には、「創元推理文庫」と「創元SF文庫」等があります。
　なぜか推理（ミステリィ）だけでなく、ホラーとファンタジィも「推理」に入っています。
　ホラーはともかく、「ファンタジィはどちらかというとSF」な気がする私でした。

構造化/クラス指向/オブジェクト指向/サービス指向Map Methods to the Abstraction Plane

先日のとある雑談のまとめ。その２。

前回の抽象化の基本２軸と照らし合わせながら
ソフトウェアの設計手法について、少し考えてみます。

1. フローチャート
2. 構造化設計/構造化プログラミング
3. クラス指向
4. オブジェクト指向
5. サービス指向

1. フローチャート
　「フロー」という名前の通り、
　動的な振る舞いを記述する手法です。
　条件分岐や繰り返し等もありますが、
　基本的に上から下に流れる１本道です。
　小さなバッチ処理であれば、これで十分ですが、
　構造の記述が容易ではないため　(つまり設計者に構造について考えることを促さないため)

　ソフトウェアの規模が少し大きくなると、
　使い辛い手法になってしまいます。

2. 構造化設計/構造化プログラミング
　階層的に抽象化されたプログラムの組み合わせとして
　プログラミングを記述する手法です。
　簡単に言えば「本の目次」のように
　プログラムを設計/実装することです。
　鳥の目から虫の目に段階的に変化していくということです。
　但し、「本の目次」であるため、前から順に読んでいくという
　フロー(=振る舞い)の記述も含んでいますが、
　１本道であるという点ではフローチャートと変わりません。

3. クラス指向
　さしあったって、クラス指向では
　　構造化プログラミングでの構造化を助けるために、
　　クラスという枠組み(箱)を提供している
　と考えれば良いでしょう。
　オブジェクト指向言語を導入したバッチプログラムで、
　よく見かける形態です。

4. オブジェクト指向
　バッチ処理の場合、振る舞いはほとんど１本道のため
　設計上は余り問題にはなりませんが、
　ユーザー対話型のイベントドリブン処理の場合、そうはいきません。
　様々な状態での様々なイベントに対して、
　適切な振る舞いを提供するというのが、
　大きな設計課題となります。
　そこで、構造とともに振る舞いをモデル化する
　オブジェクト指向設計が、もてはやされているわけです。
　とはいえ、イベントドリブン処理といえども
　一度振る舞いが決定されれれば、
　そこから先は(比較的短い)１本道です。
　構造化が重要なことに変わりはありません。

5. サービス指向
　鳥の目で、静的な構造を決定するときの手法の一つです。
　業務全体を鳥の目で見て、業務上の一処理を基本粒度として
　ソフトウェア群を構造化するという手法です。
　ソフトウェアの大規模化とクラウドコンピューティングの台頭により
　全体の構造がどうあるべきかということが、
　昨今のホットな話題になっているのでしょう。

ということで、雑談のまとめはこれで終わりです。

設計と抽象化The 2 Axises for Abstraction

先日のとある雑談のまとめ。その１。

そもそも(ソフトウェアの)設計とは何でしょうか？
広辞苑によれば、設計とは

　　…或る製作・工事などに当たり、その目的に則して、
　　工費、敷地、材料および構造上の諸点などの計画を立て
　　図面その他の方式で明示すること。…

とのことです。
「その目的」とは、何らかの問題解決でしょう。
「図面その他の方式」とは、実物を作るのではなく、
モデルを作るということでしょう。
「設計」のインスタンスが「実装」という考えです。
そこで、ここでは設計を
　「問題を解決する解(案)のモデルを作ること」
と定義して、
少し考えてみることにします。

1. 解(案)
2. 抽象化
3. 解はどこから来るのか？

1. 解(案)
　「解」ではなく「解(案)」としたのは、
　実際に作ってみるまでは、それでうまくいくのか
　わからないことも多いからです。
　なお、問題にはいくつもの説明が可能であり、
　そのため、解もいくつでも存在しえます。
　もちろん、解の良し悪しはありますが、
　最終的にはそれも価値判断でしかありません。

2. 抽象化
　実物を作るのではなくモデルを作るということは、
　抽象化するということです。
　抽象化とは、思考方法の一種で、
　　対象から注目すべき要素を重点的に抽出し、他は捨て去る方法
　です。
　そこで、何に着目し、何を捨てるかが問題になります。
　決まった答えはありませんが、ソフトウェア設計に限らず、
　抽象化に以下の２つの軸が広く使用されています。

　(1)鳥の目 <-> 虫の目
　(2)静的 <-> 動的

　(1)鳥の目 <-> 虫の目
　　鳥の目は、全体像に着目し、細部を捨て去ります。
　　虫の目は、細部に着目し、全体像を捨て去ります。
　　巨視的／微視的、マクロ／ミクロ、等呼び方は色々です。

　(2)静的 <-> 動的
　　静的な視点は、構造に着目し、振る舞いを捨て去ります。
　　動的な視点は、振る舞いに着目し、構造を捨て去ります。
　　データ構造とアルゴリズム、と言った方が判りが良いかもしれません。
　　会計でのストック／フロー分析も同じ手法です。

3. 解はどこから来るのか？
　これが一番問題なのですが、
　設計解を得るプロセスは明確ではなく、
　設計者の思いつきや閃きといっても過言ではありません。
　とはいえ、ゼロからでは思いつきや閃きは生まれません。

　設計中は、虫の目 <-> 鳥の目  静的<->動的 を
　行ったり来たりしならが、
　知識と経験を基にしたパターンマッチングや
　演繹／帰納／アブダクションを行っているのだと思います。

ということで、続きはまた明日。

堂島ロールと山田池公園

久方ぶり、かつ100エントリー目の節目に当たる投稿です。
が、特に内容はありません。m(_ _)m

昨日の朝ごはんは、パティシエリー モンシュシュの堂島ロール。

こういうのは、切らずにそのままフォークを突っ込んで食べるのが、美味しいのです。
ごちそうさまでした♪

-----------------------------------------------------------------

さすがに食べた分は、ちょっと運動しないといけない。
ということで、こちらも久方ぶりに山田池公園をお散歩。

池の水は一応戻ってますね。前回(2012/01)の写真とは大違いです。

ピラカンサでしょうか？赤い実がたくさんなっていました。

山田池大橋のあたりは、綺麗というか汚いというか、
緑色の縞模様ができていました。藻でしょうかね。

ところで、池干し調査についてちょっとWeb調べてみると
大阪府のWebサイトに報告書がアップされていました。
「なぜExcelなのか？」というツッコミは置いておいて
(と言いつつツッコんでますが)
全部で４ページで、一般向け広報としては
それなりに良くまとまっているのではないかと思います。

しかし、前回気にしていた生態系への配慮についても、よくわかりませんでした。
魚については、捕獲して養魚池で保管されたようですが、
水生植物／昆虫／鳥などへの影響がどうであったのかも、知りたいところです。

報告書にある通り「前例の少ない事業」ですので、
元データや写真など、更に詳しい情報も公開してもらえると
各所で有効活用されるのではないでしょうか。