NFuji's Café

【メイキング】ジャンヌ・ダルクの生涯（ピクトグラム４コマ）

2014-07-06T18:10:00.000+09:00

「たのしいインフォグラフィック入門」櫻田潤(BNN新社)の影響を受けて、情報編集の訓練のため、ピクトグラムの四コマ式トレーニングをやってみました。題材は、まだ記憶に新しい「傭兵ピエール」からとって、「ジャンヌ・ダルクの生涯」としました。

Step 1: ４コマのコマ割りを決める

Step 1-1: エピソードを洗い出す

最終的に使う使わないは深く考えずにエピソードを洗い出します。

フランス東部に、農夫の娘として生まれる
神の啓示を受ける
ニシンの戦いでのフランス軍敗北を予言し、的中させる
シノンで王太子シャルル7世に謁見し、軍の指揮官に任命される
オルレアンでイングランド軍に逆転大勝利する
（首都パリではなく）ランスへの進軍を提案する
ランスにてシャルル7世の戴冠式を実現させる
パリへ進軍するも石弓の矢が当たって脚を負傷、撤退する
家族とともに貴族に叙せられる
ブルゴーニュ公国軍の捕虜となり、イングランドへ引き渡される
ルーアンでの異端審問裁判により、異端の罪で火刑に処せられる
百年戦争の終結後に、復権裁判が開かれ無罪となる
20世紀になってローマ教皇により列聖される

Step 1-2: 始まりと終わりを決める

物語になるのは「2. 神の啓示を受ける」から「11. ルーアンでの異端審問裁判により異端の罪で火刑に処せられる」までなので、この２つを始まりと終わりに設定してみます。

Step 1-3: １番のエピソードを決める

ジャンヌ・ダルクを語る上で絶対に外せないのは、オルレアンでの奇跡の逆転大勝利でしょう。百年戦争の分水嶺となった戦いをジャンヌ・ダルクが勝利に導いたエピソードですので、「5. オルレアンでイングランド軍に逆転大勝利する」を１番とします。

Step 1-4: ２番のエピソードを決める

シャルル7世が王位に就いたことで、フランス王国は名実ともに復活しました。また、以降、負け戦も続いたことから、この辺りがジャンヌ・ダルクの絶頂期です。そのため「7. ランスにてシャルル7世の戴冠式を実現させる」を２番のエピソードとします。

Step 1-5: ４コマのコマ割り完成

ということで、４コマのコマ割りは以下のようになりました。

神の啓示を受ける
オルレアンでイングランド軍に逆転大勝利する
ランスにてシャルル7世の戴冠式を実現させる
ルーアンでの異端審問裁判により、異端の罪で火刑に処せられる

Step 2: ピクトグラムを作成する

Step 2-1: ラフスケッチを描く

絵心ゼロの私としては、難しいステップです。まぁ、有り体に言えば子供の落書きですが、グラフィックデザイナを目指すわけではなく情報編集のトレーニングが目的なので、えいやっと恥をさらしてみます。

ラフスケッチ

１コマ目：神の啓示を受ける

天使がメールを届ける図で、神の啓示を表現してみました。雷マークも考えましたが、天罰っぽくなってしまったの却下しました。

２コマ目：オルレアンでイングランド軍に逆転大勝利する
有名なドラクロワの「民衆を導く自由の女神」から採りました。ジャンヌ・ダルクが旗を振り、フランス兵が槍を振るい、イングランド兵が長弓を捨てて逃げるという、ちょっと詰め込みすぎの図です。なお当時のフランス王国の旗は右の（槍の穂先の）紋様でしたが、フランスであることを分かりやすくするために現在のトリコロール(三色旗)を使用したいと思います。また従軍中、ジャンヌ・ダルクが男装をしていたことは有名ですが、それも無視して赤三角のスカートにしたいと思います。

３コマ目：ランスにてシャルル７世の戴冠式を実現させる

戴冠式でジャンヌ・ダルク自身がシャルル７世の頭に載せたわけではありませんが、まぁ、イメージということで。

4コマ目：ルーアンでの異端審問裁判により、異端の罪で火刑に処せられる

安易ですが、火刑です。

Step 2-2: 清書する

ということで、Web上で無料頒布されているピクトグラムなどを切り貼りしました。サイズや余白の調整が必要そうですが、そのあたりのグラフィック的なトレーニングは目的外ということで、割愛して完成ということにします。

The Life Of Jeanne d'Arc

ピクトさんと２杯めのコーヒーを

2014-07-06T18:00:00.000+09:00

積読本解消ノ記録、其ノ参。

今週は２冊だけしか消化できませんでした。

１冊目は、「たのしいインフォグラフィック入門」櫻田潤(ビー・エヌ・エヌ新社)。日経サイエンスでも「グラフィック・サイエンス」というコーナーが設けられている通り、最近見かけることが多くなったインフォグラフィックの入門書です。
情報をコンパクト圧縮して、なおかつ分かりやすく表現するという能力は、グラフィックデザイナだけでなく、多くの人にとって有用な能力かと思います。ということで、「ジャンヌ・ダルクの生涯」を題材に、書中で紹介されていた４コマピクトグラムの作成トレーニングをやってみました（３冊目が読み終わらなかった原因です）。

The Life Of Jeanne d'Arc

２冊目は、「珈琲店タレーランの事件簿 2 彼女はカフェオレの夢を見る」岡崎琢磨(宝島社文庫)です。前作に引き続き、アマゾンの書評では毀誉褒貶があるようですが、軽い読み物としては個人的には１作目より高評価です。ミステリィというよりはサスペンス色が強いということもあるのでしょうが、前回のメインであった叙述トリックが、読者に対してというより、登場人物間の駆け引きとして使われているので、前作に感じたアンフェア感もなかったです。また京都駅、伏見稲荷、金閣寺、銀閣寺など、知っている土地が舞台になっているというのも楽しいです。

科学と傭兵と言葉と噂

2014-06-28T16:56:00.000+09:00

積読本解消ノ記録、其ノ弐。

まずは、「日経サイエンス 2014年07月号」から。既に08月号が出ていますが、なんとか１ヶ月遅れまで遅れを挽回してきました。
「シュレック」でフィオナ姫が髪を後ろで束ねる髪型を好む理由は、ほどけたロングヘアの3次元描画に要する計算が非常に複雑なためとか。コペルニクスによって提唱された地動説が、他の科学者たちになかなか受け入れられなかったのは、当時(16世紀)の観測事実は地動説とは別の理論を支持していたからとか。かのティコ・ブラーエ（Tycho Brahe)の影響も大きかった模様。

「Tycho Brahe, the scandalous astronomer - Dan Wenkel」(TED-Ed)

「傭兵ピエール」佐藤賢一（集英社）は、コペルニクスよりも１世紀近く前に活躍したジャンヌ・ダルク（Wikipedaの「15世紀のフランス王国の軍人」という説明はなんとなくシュールです）に付き添う無頼の傭兵隊長ピエールを主人公にした歴史小説。既に、文庫化、漫画化、さらには宝塚化もされているようです。まぁ、話が少々出来過ぎですが、百年戦争終盤頃のフランスというのがイメージしやすくなりました。

ジャンヌ・ダルクは神の言葉を伝えましたが、コピーの言葉を伝えるのは「言葉の技術思いつくものではない。考えるものである。」磯島拓矢（朝日新聞出版）です。傭兵ピエールに比べて薄くて字が大きくて余白も広いので、サクッと読み終わりました。タイトルの通り人に伝わる言葉は、思いつきで出てくるものではなく、伝えたいこと／伝える相手／競合／社会環境など、きちんと分析して考えるものだということ。当たり前といえば当たり前ですが、何も考えずにブログを書いている身としては、耳が痛いです。

広告コピーのようにマスを対象にするのではなく、人から人へとパーソナルな関係性を通じて広まるのが「うわさ」という言葉です。しかし、今ではインターネットの登場によって、パーソナルをパブリッシュ(publish)可能になってしまっています。「うわさとは何か - ネットで変容する『最も古いメディア』」松田美佐 (中公新書) では、「うわさ学(?)」の歴史を説き起こすところから初めて、これからの社会での情報との付き合い方を考えました。

しかし、このペースでは積読本がなくなるまで２年以上かかってしまいます。とりあえず、３三箇月のアマゾン＆ブックオフ禁止の刑を自己宣告しておきましょう。

パンとコーヒーと牛乳とタマゴとキウイと数学

2014-06-21T01:11:00.000+09:00

積読本解消ノ記録、其ノ壱。

　まずは「珈琲店タレーランの事件簿また会えたなら、あなたの淹れた珈琲を」岡崎琢磨(宝島文庫)から。最近流行り(？)の、連作短編を繋げての長編ミステリィです。アマゾンでの評価はあまり高くないようですが、私は楽しめました。コーヒーと京阪電車が好きな方にはお勧めです。難を言えば、叙述トリックを最後に持ってきたために、ミステリィとしてはどうしてもアンフェアな印象が拭えません。まぁ、好みの問題ですが。

さて、「カフェ、それは悪魔のように黒く、地獄のように熱く、天使のように純で、まるで恋のように甘い」とのたまったフランスの政治家シャルル=モーリス・ド・タレーランですが、メートル法成立のきっかけを与えた人物でもあるようです。その他、数学史にまつわる興味深い話が色々読めるのは「数学は歴史をどう変えてきたか: ピラミッド建設から無限の探求へ」アン・ルーニー(訳：吉富節子)（東京書籍）です。

　宇宙の真の姿を解明するために人間が生み出したツールが数学だとすれば、牛乳とタマゴは人間の知恵と執念がつくりだした食品です。「牛乳とタマゴの科学完全栄養食品の秘密」酒井仙吉（講談社ブルーバックス）によれば、特に20世紀に入ってから品種改良が進み乳牛１頭あたり平均約8トン/年の牛乳を出し、鶏１羽あたり平均28０個／年のタマゴを産むという、俄には信じられないような生産効率になっているようです。日本では、江戸時代までは牛乳とタマゴは一般的な食品ではなかったようですが、明治以降少しずつ消費が拡大し、戦後、学校給食を通じて一気に消費が拡大したようです。1950年代以降、日本人の体格が大きくなったのは、不足していた動物性タンパク質とカルシウムが十分に供給される様になったからなんですと。

　主食を忘れていました。「真夜中のパン屋さん午前0時のレシピ」大沼紀子（ポプラ文庫）です。大人も読める少女小説という評価もあるようですが、私のようなオジサンが読んでも、それなりに楽しめました。内容とは無関係ですが、京阪の淀屋橋や枚方市の駅ナカの神戸屋で夜のタイムサービスに上手くタイミング合うと、ちょっと嬉しくてついつい買い過ぎてしまいます。真夜中のパン屋さんって、もしかしたら本当に需要があるのかもしれません。

最後はデザートに「キウイγは時計仕掛け Kiwi γ in Clockwork」森博嗣 (講談社ノベルス)を。イニシャルV.C.さんが出ていませんが、同窓会的ファンサービスの１冊ですね。単に四季に繋がるルートが消されていっているだけのようしか思えず、どんな伏線が張られているのか想像もつきません。残り３冊でどう纏めるのか？纏める気がないのか？Xシリーズとの関係は？著者によれば「このあと、また少し時間があきます。」とのことなので次作はいつになることやらです。

ソフトウェアの３つのインターフェイスThe 3 Interfaces of Software

2012-11-25T01:23:00.000+09:00

ソフトウェアは以下の３つの存在に対して境界面を持ちます。

ユーザ
コンピュータ
開発者

もちろん、

ユーザにとっては使いやすく
コンピュータにとっては計算しやすく
開発者にとっては、保守も含めて開発しやすい

ソフトウェアが理想です。

必ずしもこれらは互いに対立するものではありませんが、

全てを1つにまとめる必用があること
人とコンピュータとでは得意／苦手なデータ構造やアルゴリズムが異なること
人は立場によって欲する情報が異なること

等の理由よって、トレードオフの関係になることもあり、

なかなか理想通りにはいきません。

これだけでも大変なのですが、ソフトウェア開発においては、

ユーザと顧客とが異なる場合も少なくありません。

たとえ顧客とソフトウェアの間に直接の接点はなくても、

何分お金を出して頂くスポンサー様です。

開発者は顧客を満足させるために、

いろいろと考えなければなりません。

開発者は、(コンピュータも含む)４種類の異なる方々を

満足させるソフトウェアを設計／実装する必要があります。

大変なわけです。

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

2012-10-22T23:11:00.000+09:00

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

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

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

　　　　

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

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

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

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

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

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

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

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

2012-10-16T23:59:00.000+09:00

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

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

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

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

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

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

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

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

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

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

設計と抽象化The 2 Axises for Abstraction

2012-10-15T23:59:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

堂島ロールと山田池公園

2012-10-14T22:22:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

「Beautiful Code」を読む(下)

2012-02-17T00:00:00.000+09:00

「Beautiful Code」をついに最後まで読了。３回目、最後のふりかえりです(１回目の中間ふりかえり、２回目の中間ふりかえり)。こんな企画(？)、始めるんじゃなかったと、何度後悔したことか... まあ、それでも最後まで辿り着けた要因の１つに、つぶやかないといけないという緩い義務感があったのも確かです。

第23章 MapReduceでの分散プログラミング
解決したい問題を解くコードの詳細と並列化のための詳細を分離して、並列化処理をフレームワーク化。並列/分散プログラミングの経験がなくとも並列/分散が容易に可能。
MapReduceは「Googleを支える技術」西田圭介(技術評論社 WEB+DB PRESSプラスシリーズ)で読んでいた内容で、復習になりました。

第24章美しきかな、並列
昨日に引き続き、並列処理が問題。並列処理間で動作を協調させる手法としてのロックにはデッドロックやロック漏れ等色々と問題があるが、もっとも基本的な弱点はモジューラプログラミングをサポートしていないこと。
ロックに替えてHaskellにあるソフトウェア・トランザクショナル・メモリ(STM)を使用することで、うまく解決できる。が、詳細はちょっと消化不良です。
前章のMapReduceはデータをうまく分割して並列処理間でのロックによる動作協調を不要にしている。但し複数種類のトランザクションが同一データに対して実行が必要なときには、何らかの排他処理が必要で、それを解決するのがSTM。

第25章構文の抽象化：syntax-caseマクロ
読み飛ばし。LISPもSchemeも知らないし「The Scheme Programming Language」も読んでられませんので。

第26章労力節約のアーキテクチャ：ネットワークソフトウェアのためのオブジェクト指向フレームワーク
ネットワークプログラミングの非本質的な複雑さの多くは、CレベルのOS APIを使うことに起因する。
ソケット通信やマルチプロセス/スレッド用のAPIは、OS間の互換性がないだけなく、同じOSのバージョン間でも互換性がない場合がある。包囲ファサードパターンを用いてAPIとそのデータとを安全なオブジェクト指向クラスの内部にカプセル化する。

第27章ビジネスパートナーをRESTfulにまとめ上げる
URLとリクエスト文字列でコマンドディスパッチを行い、データを取得/更新し、レスポンス文字列を生成して返す、というのがWebサービスの基本構造。
ディスパッチされたコマンドに対応する処理をファクトリパターンで行うなど、基本を確認するのに良い内容です。文中の例でデータ取得にPOSTを使用しているは、リクエストXMLが長くなってGETで処理しきれないからでしょう。

第28章美しいデバッグ
プログラマにとっては、機能に富んだデバッグツールの使用方法を習うよりも、系統立ったデバッグ手法の訓練をする方が重要。仮説検証サイクルを回しながら欠陥のある場所の範囲を狭めていきます。
欠陥混入前のコードと混入後のコードのテストコードを用いて自動的に差分デバッグすることで、完全自動デバッグが可能となる。つまり人間による対話的なデバッグが全く必要なくなります。

第29章エッセイのごときプログラム
プログラムの美しさは、効率良くプログラムを書き、効率良くプログラムを読解し、効率良くプログラムを修正できるところにある。簡潔さ、保守的、シンプルさ、柔軟性のバランスが大切。
抽象化とは、いくつかの概念の塊をまとめてより高次の概念を作り出すこと。一度に扱わなければならない概念の数が減るので理解を助け、再利用や保守も容易になる。言語が積極的に抽象化を行うことで、プログラムをより簡潔にすることを支援できる。
軽量言語の仕様、文法、ライブラリ量は少しも軽量ではない。目標はプログラマの労力の軽量化であって言語自身の軽量化ではない。本質的に複雑な問題を解決するための言語のシンプルさを追求すると、プログラマに複雑さを押し付けることもあり得る。

第30章世界につながる手段がボタンだけだったら
理論物理学者のホーキング教授は、たったボタン１つで操作するソフトを使って書いたり話したりする。ボタン１つで手際よく使えるエディタを考案するのは、非常に興味深い技術的挑戦。
実はボタンは、ただ押した/押さないの２値の入力装置ではなく、押す時間の長さを変えて信号を出すことも出来るアナログ装置である。「長押し」の発想ですね。

第31章 Emacspeak：完全に音声のみのデスクトップ環境
GUIと同様の効率の良さを目を使わない環境でも達成することが音声デスクトップの目標。言葉だけでなく、言葉以外のオーディオ出力の表現力を活用する。
ACSS(音声スタイルシート)で発話のスタイルを指定する。CSSなのでカスケードが可能。コメント用の音声と太字用の音声を合成することで、コメント中の太字の音声を表現出来る。また頻繁に発生する事象は音声アイコンで通知する。

第32章働くコード
本のようであること、似たものは似て見えるようにすることについては全く同感。１画面で２バージョンのコードを並べて表示するdiffツールでも、行全体を見るために横スクロールが不要な程度に１行が短いのはすごい。
プログラマはコードを構文に応じて色づけしてくれるテキストエディタだけを通して読むわけではなく、diff、merge、パッチ、コンパイラのエラーメッセージ、デバッガ等を通じても読むので、コードの見た目は、結構重要。

第33章「本」のためにプログラムを書く
この「本」は数学家ポール・エルデシュのいうところの「本」。「平面上に任意の３点が与えられたときに、その３点が同一直線上にあるか？」を判定するプログラムを考える。数学的には中学生でも解けるが、美しいプログラムにするには色々と問題がある。
素朴な第１案は、２点を通る直線の方程式を求めて３点目がそれを満たすかを判定。直線がy軸に平行な場合は傾きがゼロとなり、ゼロ除算回避の特別扱いが必要。
第２案としては、３点のうち２点を通る２組の直線が平行(傾きが同じ)であれば、同一直線上にある。直線の方程式中のy切片を考えずに、傾きだけに着目すれば良くなる。それでも傾きゼロの特例扱いは残る。
傾きゼロ特例をなくす第３案。３点を頂点とする三角形の長辺が、２短辺の和と同じであれば同一直線上にある。辺の長さの計算には平方根を使用し無理数が発生し、計算精度が落ちる。また、極度に平たい三角形は計算誤差のため直線と区別できない。
第４案。３点を頂点とする三角形の面積をベクトルの外積で求め、それがゼロであれば同一直線上にある。平方根は出てこず、極度に平たい三角形でも平たくするために長辺を延ばせば延ばすほど面積が大きくなるので、計算誤差にだまされない。
コンピュータが正確かつ美しく計算出し易いように、問題を幾何的に変形していくところが面白いですね。なお訳注では、第２案を代数的に処理して、第４案と同じ結論に辿り着く方法が示されています。

ソースコード静的解析の数理

2012-02-09T00:00:00.000+09:00

「日経サイエンス」2012年03月号「NEWS SCAN 海外ウォッチ」の「がん検診の数理」に触発されて、というか殆どパクリですが、ソースコードの静的解析の数理について考えてみました。

条件
・全ステップの 0.4% (250ステップに1件) の割合で欠陥が存在する
・静的解析ツールで欠陥のあるステップを欠陥として検出する(陽性)確率を、99.5% とする
・静的解析ツールで欠陥のないステップを欠陥として検出する(偽陽性)確率を、1.0% とする

この静的解析ツールを10万ステップのコードがあるソフトウェアに適用するとすると
・欠陥ステップ数　= 100000 / 250 = 400 ステップ
・陽性ステップ数　= 400 * 0.995 = 398 ステップ
・偽陽性ステップ数 = (100000 - 400) * 0.01 = 996 ステップ
従って、
・ツール指摘欠陥ステップ数 = 398 + 996 = 1394 ステップ
・本当の欠陥ステップの割合 = 398 / 1394 = 28.6 %
となります。残念ながら、かなり少ない割合ですね。

この問題は数学者にはよく知られているようで、比較的まれなものを検出しようとしているときは、結果が陽性と出ても誤りのある可能性が高くなります。ここでは、欠陥が全ステップの 0.4% というのがミソです。これが全ステップの1.0%なら約50%程度まで、2.0%なら約75%程度まで、本当の欠陥ステップの割合は跳ね上がります。

なお本当に問題があるかどうかの精密検査として、人の目でチェックするのにはコストがかかります。それだけでなく、静的解析ツールを通すための修正やコメント追加を行って可読性を低下させたり、最悪、別の欠陥を埋め込むことになれば、この静的解析はマイナスとなりかねない面もあります。
実際の数値は静的解析ツールや欠陥の種類によって異なりますが、静的解析ツールを導入するときは、検出できる欠陥だけでなく、偽陽性の扱いにも考慮が必要です。

この点、C++の静的解析ツールの１つである cppcheck は偽陽性0%「The goal is 0% false positives.」と掲げており、卓見だと思います。

参考
　ベイズの定理、及び、ベイズ推定

コード、デフォルト、ドライバ

2012-02-08T00:00:00.000+09:00

IT用語には、日常の言葉や他業界の用語と紛らわしい言葉が色々とあります。今回は思いつくままに、コード、デフォルト、ドライバの３つを取り上げてみました。

1. コード
一般的には、紐、ケーブル、電線のことです。これは英語では「cord」です。
プログラマが使う場合は「code」で、ソースコードの省略系であり、プログラムの文章のことです。プログラムを書くとをコーディングとも表現します。元の意味は「暗号/規則」などで、Wikipediaによれば、「コンピュータの黎明期、機械語によるプログラムがまるで暗号のようだ、ということから」とのこと。分子生物学者の使う遺伝子「コード」もこのコードですね。
音楽家が使うコードは「chord」で和音のことだそうです。

2. デフォルト
一般的には、というか金融系の方々にとっては「債務不履行」という恐ろしい事態です。
プログラマが使う場合は、「システムによってあらかじめ選択された選択肢(初期設定)」となります。
英語でも同じ「default」で、元の語義は「成すべきことが成されない」状態だそうです。

3. ドライバ
一般的には、ネジ回し(プラスとかマイナスとかがあるやつです)や車の運転手を指します。
ゴルファが使う場合は、一番飛距離の出易い1番ウッド(1W)ですね。
プログラマが使う場合は、ハードウェアや他のソフトウェアを動かすソフトウェアを指します。たとえばプリンタを動かすソフトを「プリンタドライバ」と言います。
英語は全て同じ「driver」で「drive(動かす/駆動する)する人・もの」。つまり本来は、使用するときには、＊＊＊ドライバのように何をドライブするのかを示す必要がありますが、文脈によって明らかなので省略されているということですね。但し専門外の人からすると何が省略されているのかが分かり辛い場合があるので注意です。
なおスクリュードライバは、そのまま「ネジ回し」なのですが、日本ではウォッカベースのオレンジジュースカクテルの方が有名です。Wikipediaによれば「その昔、イランで働いていたアメリカ人作業員が、のどの渇きを癒すために即席のカクテルを作った。この作業員がそのときステアするために使用したものが、工具のスクリュー・ドライバー（ねじ回し）だったことからこの名前が付いた」だそうです。
このドライバの意味が分かっていれば、基本情報技術者試験の午前問題等で見かけたドライバとスタブの違いを見分ける問題は、簡単に回答出来ますね。 (^○^)

まだまだ他にも紛らわしい言葉があるかと思いますので、またいつか、第２弾を書きたいと思います。

「Beautiful Code」を読む(中)

2012-02-07T00:00:00.000+09:00

「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つ(＝スプーン一杯の汚水)存在すると、それは樽一杯の汚水になるので、全部捨ててやり直しになるというのが題意。

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

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

2012-02-05T20:00:00.000+09:00

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

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

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

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

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

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

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

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

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

2012-01-22T22:22:00.000+09:00

ちょっと間が空いてしまいましたが、４回目の今日は、前回作成した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」を読む(上)

2012-01-18T22:00:00.000+09:00

　積ん読状態だった「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図

2012-01-08T22:25:00.001+09:00

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規格ピクトグラムあれこれ

2012-01-08T00:00:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

2012-01-07T12:48:00.000+09:00

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

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

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

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

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

生態系へどのような配慮をしているのか？
ヘドロは除去しないのか？
だれが調査しているのか？(どこかの大学とかと連携している？)
調査期間が過ぎているが、調査結果はいつ出るのか？

公開されるのか？
ヘドロ堆積のメカニズムを解明して、今後は堆積しないようにできるのか？

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

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

工業デザインの超略史

2012-01-06T01:23:00.000+09:00

かなり乱暴ですが、工業デザインの超略史をまとめてみました。

　18世紀：産業革命
　19世紀：粗悪な工業品
　　　　　 アーツ・アンド・クラフツ運動(工業製品に伝統美術/伝統工芸を適用)
　　　　　 アール・ヌーヴォー(工業製品にオリジナルのデザインを付加)
　20世紀：モダンデザイン(工業製品を均質化/標準化することで社会格差の解消を狙う)
　　　　　 ポストモダン(無機質なモダンデザインからの脱却を狙うが奇抜なだけで終わる)
　21世紀：情報デザイン(人間中心の体験デザイン)

情報デザインとは、工業デザインにおけるルネサンスなのかもしれませんね。

参考文献

「情報デザインの教室」情報デザインフォーラム編(丸善)
Chapter1 情報デザインとは
1-1 情報デザインとはなにか
1-1-4 デザイン史から見る情報デザイン

RESTfulWebサービス設計課題和暦検索 #02 要求

2012-01-06T00:00:00.000+09:00

とりあえず、和暦検索サービスの要求をざっくりと考えてみました。

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. 機密情報は扱わず、ユーザー管理も行わないのでセキュリティに配慮する必要はない

不足はあるでしょうが、まずはこんなところかと。

1-4の天皇による検索は、最初の開発からは落としてもよさそうです。

2-1の他の元号使用国用サービスについては、下の図のように各国元号を西暦で串刺しできると良さそうな感じです。いろいろと面倒なうえ、この記事のタイトルも和暦検索としてしまっているので多分作りませんが、URIの設計等では配慮しておきたいところです。

「精霊の木」と「ミシェルフーコー」異文化を理解しようとしないことこそが「野蛮」

2012-01-05T00:44:00.000+09:00

お正月に読んだ本から、印象に残った２冊を紹介します。

　まずは、「精霊の木」上橋菜穂子(偕成社)。氏のデビュー作で「守人」シリーズの原点ともいえるSFファンタジーです。科学技術が未発達で独自の風習を持つ先住民を低能で野蛮と決めつける移住民、その隠された野蛮な開拓時代を暴く物語です。
　文中、マスコミの使命についても熱く語られています。インディアンを野蛮人として描くハリウッド西部劇流報道の罪深さが知れるというものです。中学生以上が対象の「児童書」と分類されたりしていますが、大人が読んでも十分に楽しめます。

　２冊目は、「ミシェル・フーコー - 近代を裏から読む」重田園江(ちくま新書)。近代国家の刑罰は自由刑が中心で、拷問や不必要で長時間に渡る苦痛を与える方法による死刑(身体刑)などは野蛮と考えられることが多いです。しかし近代以前の社会においては、拷問を含む身体刑はそれなりの合理性をもっていた、というお話が本書の導入部分です。
　中盤以降の「監獄」の話からは、はちょっと難しくて挫折しました。曰く、自由刑自体が近代をもたらす原動力の一つである啓蒙主義とは相容れない考え方で、国民国家と重商主義に(つまりはブルジョワジーに)都合の良い「規律」を強制する手段として云々...

　両者に共通しているのは、物理的に優位に立ったものが劣位のものを、価値観の違いを斟酌することなく「野蛮」と断定するという、ヒトが陥りがちな枠組みです。異文化を理解しようとしないことこそが「野蛮」なのだということを、忘れないようにしないといけないと思いました。

RESTfulWebサービス設計課題和暦検索 #01 最初の構想

2012-01-05T00:00:00.000+09:00

「Webを支える技術 -HTTP、URI、HTML、そしてREST」山本陽平(技術評論社 WEB+DB PRESS plus) を読んで、RESTfulなWebサービスのリソース設計を自分でもやってみようと
思い立ちました。

とはいえ、本に記載されている郵便番号検索サービスをまねして作ってみるだけでは全く芸がないので、和暦検索サービスを考えてみたいと思います。中期連載(?)になるかと思いますので、のんびりとお付き合い願います。

ということで、まずは簡単に構想を練ってみます。
Googleを検索すると、既にいろいろと和暦<->西暦の検索あるいは変換サービスがあるようです。

しかしこれらのサイトでは、RESTで最も重要なアドレス可能性(※)が実現されていません。
実はWikipedeaでは

の形で、アドレス可能性が実現されています。しかし、和暦->西暦への変換は元号の後の年を指定できませんし、基本的には人間が読むことを想定したフォーマットでしか提供されておらず、JSONP等でマッシュアップし易いサービスとはなっていません。

なお、和暦には

１年の中で複数の元号が存在する(昭和64年と平成元年など)
南北朝時代には２系統の元号が存在する
元号の読みに同音が存在する(URIにローマ字表記を単純には使用できない)
未来の元号が不明(西暦2050年は平成で良いのか？など)

等の適度な(?)設計上の課題も存在するので、トレーニングとして丁度良さそうです。
また、過去分のデータは確定しているので最初は読み取り専用のサービスとして設計できるという利点もあります。

ということで、最初の構想の結論としての方針です。

RESTを満たす和暦検索Webサービスを作ってみる
主眼はWebサービスの(リソース)設計を学習とする
見た目、実装、デプロイはできるだけ簡易に済ます(多分GAE Python)
コンピュータが使いやすい形式でも提供する(Wikipediaや他サイトとの差別化)

(※)アドレス可能性
　URIでリソースを一意に特定可能であること。Wikipediaの例のようにアドレスで特定の情報が指定できることです。例に挙げた和暦検索サービスはそのような構造にはなっておらず、どの検索結果でも同じURIが割り振られています。

ブラウザがOSを抽象化する~アプリケーションソフトウェアの標準はWebアプリ~

2012-01-01T00:00:00.000+09:00

明けましておめでとうございます。
新年ということもあり(?)、各所で言われていることですが、HTML5対応Webブラウザのインパクトを、再確認もかねてざっくり自分の表現でまとめてみました。

---
かつて、オペレーティングシステム(OS)によってハードウェアが抽象化されました。

いまや、HTML5(+JavaScript+CSS3)対応のWebブラウザが、クライアントマシン(のOS)を抽象化し、HTTP対応のWebServerは、サーバーマシンとその機能をクラウドOS(+ミドルウェア)として抽象化しています。

大抵のアプリケーションソフトウェアは、できるだけ多くのユーザーに使ってもらうことを願って作られるものです。従って、HTML5によるWebアプリとするのがデフォルトの選択肢となります。

補足１
　Webアプリをサーバーマシンが提供するアプリとみることも可能ですが、ここでは以下のように考えています。
　　(1)サーバーマシンが提供する機能
　　　・HTML/JavaScript/画像ファイルなどを格納するファイルシステム(OS)
　　　・データベースとそのアクセサ(ミドルウェア)
　　　・その他便利機能の提供(OS or ミドルウェア)
　　(2)クライアントマシンが実行する機能
　　　・サーバーの機能を用いて、ユーザーにアプリケーションの機能を提供する
補足２
　以上から(?)導かれるWebアプリを作るときの注意点は以下２点となることでしょう(天気予報風)。
　　・可能であれば、既に提供されている機能を利用(マッシュアップ)すること
　　・便利機能として他のアプリから利用しやすいようにインターフェースを設計すること

Ζザクの規格 --- 統一か柔軟か？

2011-07-09T08:55:00.011+09:00

昨日、社内の会議で＜ガンダムに学ぶ本＞の話が出ました。（さて、いったい何の会議でしょう ^_^; ）
あいにく未読のため、どの本なのか正確にはわかりませんでしたが、おそらく「ガンダムに学ぶ経営学―宇宙世紀のマネジメント・ケーススタディ」か、「ガンダムが教えてくれたこと　一年戦争に学ぶ“勝ち残る組織”のつくり方」のどちらかでしょう。

で、「確かザクの頭をつけたガンダムがいたなぁ～」と思ってYouTubeを検索してみると、ダブルゼータにでてくるΖザクでした。ここで、ITエンジニアとして気になるのは、やはりガンダムボディとザクヘッド間のインターフェースです。少々問題があるとはいえ十分に機能したということは、連邦軍とジオン軍との間で軍事テクノロジの共通規格化が進んでいたということでしょうか。それとも、少々の規格の違いなどは柔軟に吸収可能なテクノロジが発展していたのでしょうか。現実的には前者でしょうが、後者の解釈の方が好きです。

それにしても、ダブルゼータって、合体ロボットアニメだったのですね... そんなイメージは全くなかったのですが、子供の頃の記憶はアテにならないものです。あっ、でも、ファーストガンダムも真ん中にコアファイターが収まる合体ロボットアニメでした。