「Beautiful Code」を読む(中)

「Beautiful Code」の３分の２にあたる22章まで読了しましたので、２回目の中間ふりかえりです(１回目の中間ふりかえり)。
なかなか毎日Twitterで呟くことはできていませんが、呟いていない日でも少しずつ読み進めていることもあります。そのままだと呟くポイントを見失ってしまいがちですが、別途メモしておくのも読書が断続的になり、効率が落ちてしまいます。そこで、今回はブックダーツを使用してみました。

左の写真は「第22章 スプーン一杯の汚水で」の「境界条件」云々の箇所。
右の写真は本の小口(こぐち)です。

第12章 BioPerlにおける美しいコードの成長
ライブラリの設計では、そのクラスや関数がどのように使われるかの(疑似)コードを書いてみながらブラッシュアップしていく。クラス(群)レベルのユースケースシナリオと考えると良いかも。
ライブラリは、初心者がすぐに使え、中級者が簡単にカスタマイズでき、上級者が簡単に拡張できる、というのが理想。Perlのコードリファレンス値(コールバック関数オブジェクト)でライブラリを拡張可能にしている。

第13章 遺伝子ソータの設計
遺伝子解析関連のお話が続きますね。小さなプログラムの構造はアルゴリズムやマシンの都合で決めて良いが、大きなプログラムの構造は人間の都合で決めるべき。
人間の記憶は連想による部分が大きく、一度詳細に読み込んだことがあるコードであれば、概略を読んだだけで詳細を思い出せることが多い。結局、構造化プログラミングというか、本の目次のようにコードを書くことが大切ですね。

第14章 エレガントなコードはハードウェアに合わせて進化する：ガウス消去法の場合
効率的なアルゴリズムというのはコンピュータのアーキテクチャに依存するが、可読性とのせめぎ合いもある。
私はアプリケーション寄りの人間。ハードウェア(コンピュータアーキテクチャ)の違いは基本的にはOSで、足りなければフレームワークやライブラリで吸収しておいて欲しいものです。但し、OS/フレームワーク/ライブラリを選定する能力は必要ですが。
なおアプリケーション側でも、ハードウェアを意識していないと非常に非効率になることはあります。そのときは、第５章にあったように、正しく->美しく->速く で最後に計測しながら考える(もしくは得意な人にお願いする)のが私の道でしょう。

第15章 美しいデザインの長期にわたる恩恵
美しいコードと美しい数学とは、必ずしも同一物ではない。メモリが無限にあり処理速度も無限に速いことを前提としたコードは横柄ですらある。
コードの究極の目的は使われることなので、芸術作品と同様に、時間の試練に耐えたものこそが美しいと言える。
数年〜数十年以上使い続けられているコードはそれほど多くない？

第16章 Linuxカーネルのドライバモデル：一緒に働くことの恩恵
C言語でオブジェクト指向。
優秀な開発者たちが強調し、必要に応じて反復的に開発してきたため、多くの問題を解決する美しい共通解となるコードができたということ。

第17章 もう一段の間接参照
C言語でオブジェクト指向その２。
「コンピュータサイエンスにおける問題の全ては、もう一段の間接参照によって解決できる」が、「たいてい、新たな問題が作り出される」とのこと。
間接参照による抽象化で柔軟に情報を構造化できると読む。間接化による時間的・空間的オーバーヘッドは、殆どのケースでハードウェアとコンパイラの性能で解決できる。しかし、ソースコードの理解し易さを妨げる可能性があり、過剰な間接化は避けるべき。

第18章 Pythonの辞書実装：すべての人々にすべてのものであること
CPythonの辞書は言語機構の土台で、クラスやインスタンスの属性値や、関数呼び出しのキーワード引数を格納することにも使用されている。
辞書の実装では、ハッシュ表の大きさやその変更、ハッシュ値の衝突など、様々な点で最適化が行われている。但し、最適化は基本的にはアルゴリズムに関するものであり、全体としてとて素直な実装になっている。

第19章 NumPyの多次元イテレータ
Python続きですね。NumPyはPython言語のオプションパッケージで強力なN次元配列オブジェクトが提供されています。メモリ上で不連続な配列も扱えます。
NumPyイテレータにより使用する配列が連続か否かに関係なく、連続した配列と同様のコードが使えて、それでいて常に十分高速なコードが得られる、ということ。
各次元毎にストライドを設定出来るのが面白いです。

第20章 NASAの火星探査機計画のための高信頼エンタープライズシステム
巨大アプリケーションでは常に、成功の鍵はコーディングではなく統合にあるということ。標準コンポーネントを粗結合で使うこと。
巨大なアプリの美しさは、必ずしもエレガントなアルゴリズムにはないということ。
熟練開発者のスキルの１つは、何をハードコーディングし、何を開始時にロードするパラメータとするのが適切なのかを見極められること。

第21章 ERP5:最高水準の適応性に向けた設計
プロセス中心やデータ中心ではなくドキュメント中心のパラダイム。全てのビジネスプロセスは一連の文書を作り出すことを通じてその目的を達成する？なんかちょっと官僚チック？
既存のビジネステンプレートを土台にして、GUI要素を取り替え、ワークフローを調整するだけで、新しいビジネステンプレートが作れる、ということかな。ERPの開発・運用のイメージが描けていないので消化不良。

第22章 スプーン一杯の汚水で
Solarisのカーネルメモリアロケータとゼタバイトファイルシステム(ZFS)間のやり取りにおけるブロッキングチェーンで生じる問題について(むずっ)。
ある問題を、こうすれば動くのでは動くのではないかという形ではなく、こうだから動かないという形で分析して解決する能力、つまり境界条件に注目する能力が大切ということ。なんか犀川創平氏を思い出しました。
どんなに格好の良い(ように見える)設計・実装(＝樽一杯の高級ワイン)であっても、(難解で)致命的なバグが1つ(＝スプーン一杯の汚水)存在すると、それは樽一杯の汚水になるので、全部捨ててやり直しになるというのが題意。

ふ〜っ。ということで、残り３分の１、がんばりましょう。

「新ネットワーク思考」と「エピデミック」

BeautifulCodeとRESTful元号が滞っていますが、それとは別に大量にある積ん読本の解消を少しずつ進めようかと(^▽^;)。

ということで、「新ネットワーク思考―世界のしくみを読み解く」アルバート・ラズロ・バラバシ(NHK出版)(初版2002年12月26日)を読了しました。
全般的にデジャヴ感があったのは、「日経サイエンス」2003年9月号の記事「世界の“なぜ”を読み解く　スケールフリーネットワーク」を読んでいたからでしょう。こちらは同著者のA.-L.バラバシ氏とE. ボナボー氏の共著です。
ざっくり抽象化すると、静的な要素還元主義だけでは色々と行き詰まりが出てきていた状況を、動的な関係性のトポロジーという新しいモデルで打破しようということですね。ロングテールとかウィルスマーケティングとか「ブラックスワン」とかの背景理論にもなっています。
ネットワークモデルの特徴を簡単に表にしてみました。

不慮の事故/故障には強いが攻撃に弱いというのが、WWWなどのスケールフリーネットワークの重要なポイントかと思います。

続けて「エピデミック」川端裕人(角川文庫)(単行本初版2007年11月)を読了。新興伝染病のアウトブレイクを制圧する疫学ミステリィ小説です。

伝染病の拡大規模によって エンデミック(endemic) -> エピデミック(epidemic) -> パンデミック(pandemic)と出世魚のように名前が変わるようです(Wikipediaの「伝染病」の項目参照)。アウトブレイクは、エピとパンの間くらいでしょうか？

たまたまですが、伝染病の広がり方が、ズバリ、成長と優先的選択をともなうスケールフリーネットワークです。ノード(罹患者/動物、保菌者/動物)、リンク(感染経路)、さらには運ばれるもの(ウィルス)も不明確な状態です。障害耐性は強いので、放っておくとどんどん広がります。しかし主要なハブに対する攻撃には弱いのでスーパースプレッダー(毒王)を隔離して、感染経路の「元栓」を閉めることで沈静化します。

その「元栓」探しが探偵小説になるのですが、「確率密度の雲のなかで持ちこたえる」という量子力学的(？、電子の雲からの連想。多分カオス的とか複雑系的という形容の方が正確なのでしょうが)なスタンスが良いですね。

なお、舞台となる(人間を含めた)生態系もスケールフリーネットワークと考えられています。

RESTfulWebサービス設計課題 #04 リソースの特定とURI

ちょっと間が空いてしまいましたが、４回目の今日は、前回作成したER図等を元にリソースの特定とURIの設計を進めたいと思います。

0. 前回までの目次
#01 最初の構想
#02 要求
#03 提供データの特定とER図


1. リソースを特定する
(1)西暦年リソース
西暦年で各国の年号情報を串刺しするというコンセプトからして、西暦年は外せないでしょう。１つの西暦年に対する各国元号年の情報を持たせます。
なお、持たせる情報の詳細は次回予定のリソース表現の検討で考えます(以下、同様)。

(2)検索結果リソース
検索は機能で情報ではないですが、検索結果は情報ですのでリソースとして扱います。元号名、元号名の読み、天皇名、及び天皇名の読みで元号情報を検索した結果の情報を持たせます。

(3)元号リソース
元号の情報を持たせます。

(4)時代・王朝別元号リソース
時代・王朝ごとの元号一覧を持たせます。

(5)地域・国別元号リソース
各国/地域ごとの時代・王朝・元号の一覧を持たせます。

(6)地域・国別西暦年リソース
最初は日本しかありませんが、他の国の対応後は国指定で元号を取得したくなりそうです。その時、(1)の西暦年リソースだと余分な情報も含まれてしまいますので、国も指定出来た方が良いかもしれないと思いました。

(7)トップレベルリソース
このWebサービスのスタート地点。西暦年の指定、地域・国別元号リソースへのリンク、検索フォームを持たせます。


2. リソースにURIで名前を付ける
仮にアプリケーションのURLを「http://gengo.appspot.com」とします。
(1)西暦年リソース
西暦年リソースは西暦年で一意に識別できるので、西暦年がそのまま使えそうです。例えば、1092年は「http://gengo.appspot.com/1192」です。「年」は付けないことにします。可読性に問題はないのでプログラムで扱い易くするためです。

(2)検索結果リソース
まず、「/search」を検索クエリを受け取るリソースのURLとします。問題は、クエリパラメータです。
(a)文字表現はどのように扱うべきか？
　(a1)元号名と天皇名の漢字表現をどうあつかうか？
　　UTF-8で%エンコードした漢字表現を、そのままURIに使用します。
　(a2)元号名の読みと天皇名の読みは、ひらがな/カタカナ/ローマ字？
　　和暦だけをターゲットにするのではなく、中国/朝鮮/ベトナムまで含めるとどうすべきかちょっと悩むところです。ローマ字表記も各国ごとにばらばらで、いろいろな方式があるためどうしたものかと。
各国/地域の表音文字表現は下記の通りです。

• 日本：ひらがな、かたかな、ローマ字
• 朝鮮：ハングル、ハングルのローマ字表記
• 中国：ピンイン（ローマ字表記）
• 越南：クォック・グー（ローマ字表記）

中国やベトナムのように独自の表音文字がない(？、よくわかりません)ケースを考えると、ローマ字表記での統一が良さそうですが、実際にはアクセント記号も込みのため、単純にアスキー文字列で表現できるわけではありません。日本人ユーザーによる入力のし易さから考えて、今回は日本用には「ひらがな」(UTF-8の%エンコード)を採用することにします。つまり、ローマ字による表現の統一は諦めるため、読みによる串刺し検索ができなくなります。但し需要があるとは思えないので良しとしました。
その他の国は機能拡張時の検討事項として残しておきます。

(b)名前検索と読み検索とで検索結果リソースを区別すべきか？
名前は漢字で、読みはその他の文字になるため、使う側としては名前と読みとをことさら意識しないと思われます。ルールは分けないで同じ仕組みでのリソースとします。

(c)元号検索と天皇検索とで検索を区別すべきか？
リソース表現を工夫することで対応出来そうな気がしますので、一旦は区別せずに進めます。但し、天皇名は最初の機能からは落とすつもりですので、機能追加時には再検討を行います。ということで、クエリパラメータは慣例に合わせて「q」とします。

(d)地域・国別に検索したい場合はどう扱うか？
串刺しをデフォルトとし、国・地域別は階層を落として分けましょう。国/地域はUTF-8の%エンコーディングでは可読性が落ちるため英語表記とします。
「japan」「china」「korea」「vietnam」
なお、串刺しでの読み検索は、ローマ字表記を諦めたので、地域・国を省略できるということ以外にはあまり意味はなくなります。
まとめると、URIは以下のような感じです。

• 串刺し：「http://gengo.appspot.com/search?q=建」
• 日本　：「http://gengo.appspot.com/japan/search?q=建」
• 　　　　「http://gengo.appspot.com/japan/search?q=けん」
• 中国　：「http://gengo.appspot.com/china/search?q=建」
• 朝鮮　：「http://gengo.appspot.com/korea/search?q=建」
• 越南　：「http://gengo.appspot.com/vietnam/search?q=建」

(3)元号リソース
同じように考えます。但し、時代・王朝名と元号でのリソース重複を防止するため「gengo」を挟みます。元号と地域・国では、地域国を上位概念とします。理由は、使うときに「建長の日本」ではなく「日本の建長」で探すことの方が多いと思うからです。串刺しについては、各国が中国の元号をまねて付けたものもなくはないため、もしかしたら良い結果を産むかもしれません。

• 串刺し：「http://gengo.appspot.com/gengo/建長」
• 日本　：「http://gengo.appspot.com/japan/gengo/建長」
• 中国　：「http://gengo.appspot.com/china/gengo/建長」
• 朝鮮　：「http://gengo.appspot.com/korea/gengo/建長」
• 越南　：「http://gengo.appspot.com/vietnam/gengo/建長」

(4)時代・王朝別元号リソース
串刺しの情報は存在しません。「時代・王朝」は「era」として、それ以外は元号リソースと同様です。なお「＊＊時代」の「時代」は冗長なため含めないことにします。

• 串刺し：なし
• 日本　：「http://gengo.appspot.com/japan/era/鎌倉」
• 中国　：「http://gengo.appspot.com/china/era/明」
• 朝鮮　：「http://gengo.appspot.com/korea/era/李氏朝鮮」
• 越南　：「http://gengo.appspot.com/vietnam/era/阮朝」

(5)地域・国別元号リソース
同様に

• 日本　：「http://gengo.appspot.com/japan」
• 中国　：「http://gengo.appspot.com/china」
• 朝鮮　：「http://gengo.appspot.com/korea」
• 越南　：「http://gengo.appspot.com/vietnam」

(6)地域・国別西暦年リソース
「(1)西暦年リソース」の下位データと考えて

• 日本　：「http://gengo.appspot.com/1192/japan」
• 中国　：「http://gengo.appspot.com/1192/china」
• 朝鮮　：「http://gengo.appspot.com/1192/korea」
• 越南　：「http://gengo.appspot.com/1192/vietnam」

但し、例えば「http://gengo.appspot.com/japan/1192」のように西暦と地域・国の逆順は代理リソースとして、「301 Moved Permanently」で上記URIにリダイレクトします。

(7)トップレベルリソース
「http://gengo.appspot.com」


ここまで考えると、「(3)元号リソース」は串刺し用と地域・国別元号用とに分離した方がすっきりしそうですね。リソースの表記順も順番をかえた方が分かり易そうですし。まあ、正式なURIの仕様書は動くものができてからきちんと整備することにして、こんな感じで進めていきます。

あ〜、今日も文字ばっかりでした。

「Beautiful Code」を読む(上)

　積ん読状態だった「Beautiful Code」を２週間程前から読み始めました。1日1章くらいのペースで読もうと思います。全部で33章あるので33日間、バッファ込みで40日間位の計画です。ただ読むだけよりは、少しでもアウトプットを意識した方が記憶に残り易く理解も深くなるかと思い、読んだ感想をTwitterで呟き中です。今日までで全体の３分の１にあたる11章まで終わりましたので、一旦ふりかえりもかねて、ブログに纏めておきました。
　以下、基本的には私個人の記憶フックメモです。読んだことがない人には全く分からず、読んだことがある人にとっても殆ど分からないかもしれません。悪しからずご了承ください。

第1章 正規表現マッチャ 
　いきなり苦手のアルゴリズム系です。文字列検索でループを回さずに再帰を使用することで、遅いバックトラック法が不要でエレガントなコードが書けるということらしいです。

第2章 Subversionの差分エディタ：存在論としてのインターフェース
　まず、SVNのバージョン管理の仕組みで「書き手と読み手が干渉しない」というところが、なるほどと思いました。
　XMLのSAXパーサ等で使っていてもストリーム指向のIFがよく分かっていなかったことが分かりました。処理するデータ量に関係なくメモリ使用量が一定で、かつ処理時間もリニアにしか増えません。（参考：いがぴょんの日記ウェブページv2 2005/06/06 日記: SAXインタフェースが実現する次世代ストリーム指向パラダイム）
　SVNの差分エディタAPIは設計を誘導するので、機能追加時等に設計に関する余分な議論が不要になる、というのが びゅーちふる という結論。

第3章 私が決して書かなかった、一番美しいコード
　またまた苦手なアルゴリズム系で頭が痛い。途中何回か、迷子になりかけて読み直しが発生しました。まさかここで漸化式がでてくるとは… 数学の素養が必要な章ですね。
　クイックソートの比較回数を計算するコードを改善。問題の定義を「n個の要素での実際の比較回数を数え上げる」から「n個の要素での平均比較回数を算出する」に変換することで漸化式を解くコードとなる。結果、コードを削って機能を追加することに成功。

第4章 ものの見つけ方
　コンピュータは電子計算機だが、今日では直接的な計算よりも情報の蓄積と探索が主になっている。で、やっぱりテキスト探索には正規表現が非常に強力で、高速で美しいコードが書けるとのこと。同感です。
　ハッシュマップなどの連想記憶による探索は便利で高速。しかしデータ量が多くなるとメモリが大量に必要な上に探索以前のデータロードに時間がかかるようになる。そんなときは配列をソートしての２分探索の出番です。それでもダメなら自力で何とかしろと。

第5章 正しく、美しく、速く(この順番で)：XML検証ソフトの設計から
　まずは正しい結果を出すコードを書くこと。最適化はその後必要に応じて。速くて醜いコードを美しくするよりも美しくて遅いコードを速くする方が容易なので、美しさ優先。
　検証ロジックを表探索(既知の入力に対する全ての答えを用意した表の探索)に置き換えることで高速化。昨日やった探索の問題に繋がる。アルゴリズム(の一部)をデータで代替して探索に持ち込む、というのは問題を解き易い形に変換するということの一例。

第6章 テストのための統合的フレームワーク：脆さから垣間見る美しさ
　私には美しさを垣間見ることが出来ませんでした。何を固定し何を可変とするかの設計解は、教条主義的には決まらず状況次第で工夫の余地がある、ということでしょうかね。

第7章 ビューテュフル・テスト
　ここまでテストするのか、ということと、そのテストが出来上がる過程が分かって良かったです。スモークテスト -> 強化値テスト -> 網羅 -> 実行性能　というテスト戦略は参考になりました。
　完全なテスト駆動開発はなかなかハードルが高いですが、スモークテスト駆動開発という中間形態(?)であれば取っ付き易くて良さそうです。

第8章 画像処理のためのその場コード生成 
　数百万画素の画像のデジタルフィルタ処理には高速なアルゴリズムが必要。画像サイズやフィルタサイズやフィルタ処理内容などが実行時まで確定せず、それらの変数にまつわる計算が処理を遅くしてしまう。
　かつてWindowsのBitBltの実行C言語コードが、確定変数に基づいてメモリ上に機械語サブルーチンを生成して実行した。同様にC＃では、確定変数に基づいて.netの中間言語を生成可能。処理する量が多ければ高速化のメリット有り。
　「中間言語のコード」をデータとしてC＃で生成するということは、第５章で出てきた表探索と同様、アルゴリズム(の一部)をデータに置換するということでもある。プログラムとデータが同じ形式のLisp系の方々からすれば、当たり前のことのなのかも。

第9章 下向き演算子順位解析
　挫折。まずは元となっているボーガン・プラット氏の論文(PDF版で15ドル)を読んでみないとみないといけないかもかも。もともともともと構文解析系は苦苦手なんですですですです。
　直接関係ありませんが、文中のJavaScriptコードを読んでいて、前に纏めたJavaScriptのPrivateメンバの実現方法を改善できるかもと思いました。やってみないと分かりませんが、Publicメンバにはプロトタイプを適用可能か？

第10章 高速ビットカウントを求めて
　私だったら基本的な方法の最初のやつで満足してしまっていますね。その改良系でもうすごい。それでやっぱりここでも表探索が強力で高速方法と。
　分割倒置法によるビット演算は凡人の私にはもう少し説明が欲しいところ。
　　　x = (x & 0x55555555) + ((x >> 1) &0x55555555)
　 なんて、一回自分で２進数に直して計算してみないとわかりません。
　キャリー保存加算器を利用した配列のビットカウントは挫折。迷子になってしまいましたが、読み直す気力もなく読み飛ばしてしまいました。アメリカ国家安全保障局(NSA)には雇ってもらえそうにありません。

第11章 安全な通信：自由のための技術
　SOPAやPIPAが話題になっている(たとえば＠IT「なぜWikipediaは停止するのか――SOPA抗議活動をひもとく」)のでちょっとタイムリーな話題。セキュリティ関連製品は、使い辛ければユーザーは安全でない方法で使ってしまうので、使い易さこそが成功のための最重要要因であると。
　市場の要求に合致しているというのは、アプリケーションのコードが商業的な意味において美しいということでもある。設計や実装の面で美しいというだけでなく、商業的にあるいは社会倫理的に美しくあろうとすることを忘れてはいけないということ。

う〜ん、文字ばっかりですね。ｍ(＿ ＿；)ｍ

RESTfulWebサービス設計課題 和暦検索 #03 提供データの特定とER図

RESTfulWebサービスの第３回目は、提供データの特定とER図の作成です。

本題のリソース設計に入る前に、サービスとして提供するデータを特定します。提供するデータは要求でかなり明らかになっていますが、構造化されていないため何をリソースとして管理すべきか分かりません。
そこでまずは、必要なデータをRDBのテーブル設計の要領でER図に落としてみました。それが下図です。（「astah*」のクラス図を使って作成したためプライマリキー(PK)が表現できていませんが、「テーブル名ID」がPKです。）

1. 説明

(1)南北朝の問題は「時代・王朝」を提供データとして設けることによって対応

南北朝や大覚寺統/亀山統の解決方法に悩みましたが、要求中には明示されていなかった「時代・王朝」を設けることで対応しました。これにより日本の平安時代の年号一覧などの機能(要求にはありませんでしたが)にも対応可能になります。

また、他の国/地域の王朝も区別できるようになります。特に中国では複数の王朝で同じ元号(「建武」など)が使用されることもあったようで、区別が容易になります。

(2)４カ国・地域共通データと日本独自データに分割

「時代・王朝」は共通データとして「元号」から参照しています。しかし「天皇」は日本独自データとして、天皇と元号を紐付けるデータを別途持たせるようにしました。

最初は「天皇」を「皇帝・天皇・国王」のように読み替えて「元号」と「時代・王朝」の間に挟むことも考えました。そうすれば、全て共通のデータ構造になるからです。

しかし

・日本の場合「将軍」や「総理大臣」という軸も考えられてなかなか複雑であること

・基本的には天皇の交代時に改元されがもし例外があった場合の処理が複雑になること

・中国/朝鮮半島/ベトナムの元号の詳細が勉強不足で分かっていないこと

・メインコンセプトである「西暦による各国元号の串刺し」には直接関係しないこと

から、断念しました。

2. 主な問題点と変更点

(1)２時代に跨がる元号の存在

実は「時代・王朝」の対応には、問題がありました。

日本では１つの元号が２つの時代に跨がることがあり、例えば「延暦」は西暦782年〜806年のため奈良時代と平安時代の両方に属します。少し複雑になりますが、「元号」のデータを２時代分重複してもつことで対応可能なので、正規化して「元号_時代・王朝」を設けました。

(2)「西暦」を削除

西暦ID = 西暦 で問題なさそうなので、「西暦」を作ったのはちょっとやり過ぎでした。

（が、下図のように消してから気が付きましたが、リソース設計用のデータ構造を示すだけなのでの残しておいた方が良かったように思えます。）

ということで変更後のER図を以下に示します。

3. 課題

(1)正規化し過ぎ

このER図は、リソース設計を行うためのデータの構造化として作成しました。

CRUDのうち基本的に使用するのは「C」と「R」のみで、しかも「C」を行うのは管理者のみであることを考えると、ほとんどの処理は「R」で、管理者がたまに簡単な「C」と「R」を行うのみであることを考えると(2012/01/09修正。改元時に終期の「U」があることの考慮もれ)、ここまでの正規化は行き過ぎかもしれません。

また現状では、RDBではなくGAEのBigTableに載せることを考えています。「元号年」のデータ数は多く見ても１万件程度のオーダーですので、ごりごりテーブルを結合させても大丈夫かと思いますが、詳細設計の段階では正規化を崩すことの検討も必要です。

(2)歴史学上の議論

元号、王朝、時代、その他諸々、今回のアプリで扱うデータの値にはいろいろ議論のあるところです。いくつかバリエーションを持たせることも不可能ではありませんが、ここでは何かひとつ決めうちで対応することにします。

たとえば「元号の読み」ですが、明治以前は明示されていないため複数の読み方が成立します。しかし今回は複数の読は対応せず、私の独断と偏見で読みを１つに絞らせて頂きます。

4. 要求の再確認

要求を上から順番に確認し、実現できないものないことを確認して本日は終了です。

○1. 機能要求

　○1-1. 西暦から和暦を知りたい(例：西暦2012年 -> 平成24年)

　　○1-1-1. 西暦に対応する和暦が存在しない場合は、その旨を教えて欲しい

　　○1-1-2. 西暦に対応する和暦が複数存在する場合

　　　○1-1-2-1. 改元の場合は、改元月日と併せて全和暦を表示して欲しい

　　　○1-1-2-2. 南北朝期の場合は、南朝/北朝両方の和暦を表示して欲しい

　○1-2. 和暦から西暦を知りたい(例：平成24年 -> 西暦2012年)

　○1-3. 元号から和暦情報を知りたい

　　○1-3-1. 和暦情報としては少なくとも以下の項目が欲しい

　　　　　　元号名、元号名の読み、元号の年数、始期(年月日)、終期(年月日)、天皇名、天皇名の読み

　　○1-3-2. 元号名の部分一致で和暦情報を検索したい

　　○1-3-3. 元号名の読みの部分一致で和暦情報を検索したい

　○1-4. 天皇から和暦情報を知りたい

　　○1-4-1. 天皇名で和暦情報を部分一致検索したい

　　○1-4-2. 天皇名の読みで和暦情報を部分一致検索したい

　○1-5. 他アプリへのサービス提供を可能とするためJSON形式のデータが欲しい

　○1-6. もちろん人間の読みやすい形でのデータも欲しい

○2.非機能要求

　○2-1. 他の元号使用国(中国、ベトナム、朝鮮半島)用機能の追加が容易な設計にして欲しい

　○2-2. 機密情報は扱わず、ユーザー管理も行わないのでセキュリティに配慮する必要はない

以上、お疲れさまでした。

JIS規格ピクトグラムあれこれ

「JIS T0103 コミュニケーション支援用絵記号デザイン原則」に収載されている絵記号例（いわゆるピクトグラム）が(財)共用品推進機構のサイトで無償ダウンロード可能なことを知りました。それで早速ダウンロードして確認。

基本的には全部良く出来ていて、よく感じが出ている「204005 歌う」とか 

「303001 しょうゆ」と「303002 ソース」の区別の仕方とか、好きですね。

ただちょっと気になったこともあります。

1. ユニバーサルデザインを志向すべき

まず、JISの規格概要を引用します。

話し言葉及び文字表現によるコミュニケーションが困難な高齢者，障害のある人などが，絵記号を利用して自分の意思及び要求を相手に的確に伝え，正しく理解されることを支援するために必要とされる基本的な絵記号及びそれらの作図方法について規定。

対象者の中心が、高齢者と障害のある人となっています。観光立国を謳うのであれば、外国人をもっと意識すべきでしょう。また、そもそも視覚表現の強力さを考えれば 「話し言葉及び文字表現によるコミュニケーションが困難な」人に対象を限る必要はなく、全ての人をターゲットにすべきかと思います。
文化や風習の異なる人々は異なるメンタルモデルを持っているため、全世界での完全標準化は難しいでしょう。ユニバーサルデザインをベースにローカルデザイン(?)を上乗せする形で、世界標準を提案するぐらいまでいけると良いのでしょうけど...

2. 看護師のナースキャップは必要か？

「102004 看護師」です。非常に分かり易いかとは思います。ただ職業を外観で表すのは難しく、これを外すと分かり辛くなってしまいますが、ナースキャップが気になってしまいました。既に有名な話ですが、現在多くの病院でナースキャップは使用されていません(Dr.鷲崎の健康エビデンス 第３回 なぜナースキャップは廃止されたのか)。
ステレオタイプとして有効というのは分かります。しかし現実と乖離した(時代遅れとなった)メンタルモデルを維持/強化する方向に働くアイコンを使い続けるべきか、考えどころかと思います。

山田池公園の池干し調査について

久しぶりに山田池公園に行ってみると、なんと池の水が干上がっています。

「10月1日～11月30日の期間、生態系に配慮しながら池の水を抜いて実態調査を行います。水位回復は平成24年春頃を予定しております。」とのことですが、何の実態調査なのか？、どのように生態系に配慮しているのかが、わかりません。

私が探せていないだけかも知れませんが、大阪府の枚方土木事務所のページには

山田池公園の主要施設である山田池は、灌漑用水にも利用されていますが、公園開設以来池干し（池の水を完全に抜いて、池底まで干すこと。公園として開設するまでは毎年実施し、水質の保全に役立てていた。）を行っておらず、ヘドロ等が堆積して水質の悪化が進行しています。
このため、今回、生態系に配慮しつつ、池の水を抜いて、池底等の実態を調査します。
なお、水位の回復は、気象条件により変動しますが、平成24年春ごろを予定しています。
皆様のご理解とご協力を、よろしくお願いいたします。
調査期間；平成23年10月1日から11月30日

としかありません。ヘドロ堆積による水質悪化の対策だということまではわかりましたが、それ以上は不明です。この程度の情報量であれば、全て張り紙にも書いておいて欲しいです。財団法人大阪府公園協会の山田池公園のページにも、これ以上の情報はありません。

• 生態系へどのような配慮をしているのか？
• ヘドロは除去しないのか？
• だれが調査しているのか？(どこかの大学とかと連携している？)
• 調査期間が過ぎているが、調査結果はいつ出るのか？
• 公開されるのか？
• ヘドロ堆積のメカニズムを解明して、今後は堆積しないようにできるのか？

「ご理解とご協力を」というのであれば、もっと情報を公開すべきではないでしょうか？
生態系へのインパクトやヘドロ堆積のメカニズムの解明ということに関しては、今回の水抜きは割と大きな実験として捉えることもできなくありません。なかなかできることでもありませんので、興味を持つような研究機関や府民などに大々的に調査協力を呼びかけても良かったのではないでしょうか？採集したデータや調査結果などもオープンに公開すれば、みんなで議論もできますし...。
まだ「水位回復 -> 生態系回復」のフェーズが残っていますので、何か調べてみたいことがある方は、枚方土木事務所に連絡してみると良いかもしれませんね。

ちなみに、2010年03月22日時点の山田池は以下のような感じです。中央右の白三角が、この記事の３枚目の写真のお堂です。