SilverlightのRichTextBoxを調べてみたのですが、
どうも使いでがないような。

いろいろ高性能ではあるようなのですが、
それらはプログラムから泥臭く制御するしか操作方法がないようで、
バインドとかを多用したいSilverlightのアプリケーションの中では、
浮いてしまうのではないかという気がしますね。

なんかインターフェースがWindowsFormっぽい。
これだと、他との整合性を考えると、
機能一式を部品化せざるを得ないと思うのですが、
そもそも機能を部品化したものをControlとして配っているわけなので、
それを改めてラッピングして部品に、というのはどうもおかしな感じになります。

WPFのはその辺うまくまとめてあったのですが。
Silverlightでバインドあたりの機能が削られて実現不可能になり、
やけになったとかでしょうか。

それとも私の思いつかないエレガントな実装方法が何かあるのですかねえ。

適当に使うとすればWindowsFormっぽくイベントハンドラ書いてけばいいですが、
ちゃんとした製品に入れるとしたら、インターフェースを作り直す必要がありそうです。
コマンドいっぱいつければいいですかねえ。
題名から想像するほどすごいことが書いてある本ではなく、
単にPMBOKについて書かれた本です。

PMBOKについて少し調べたいと思ったので買ってみましたが、
PMBOKの具体的方法がいろいろ書いてあり、
全体像をつかむことができました。

ただ解説にどうも微妙なところがあるような。
PMBOKについてはあまり知らないので、
おかしいかどうか分からないのですが。

エントロピー増大の法則について書かれたところで、
おかしさがはっきり出ていました。

なんかすごい大雑把な理解で、
生物はエントロピーの法則に反しているなんて言う有名な迷信を信じていたり。

本のテーマからするとエントロピー増大の法則はたとえ話として挙げられているだけなので、
別にそれでもいいわけですが、
でもたとえ話として引き合いに出すだけなら、
ことわざを引き合いに出すようなものであり、
自然界の法則だから科学的だとか言っている意味がないんですよね。
こんなので科学といわれても科学が困ります。

で、エントロピーの話だけならいいんですけど、
なんかPMBOKの本体の話についてもそういう雰囲気が見られるような気がして。

まあPMBOKについてよく知らないのでわからないのですが。
なんか文章からそういうものを感じるような気がするのですな。
著者があんまりしっかり内部まで理解してないような感じを感じるのです。

たとえばいろいろ細かい数式が出てくるのですが、
誤差が重要になるとも書いてあります。
測定に誤差が大きいのに細かい計算をしても、
あまり意味がないのですが。

誤差っていうのは、トラブルのもとになるだけでなくすべき、
というのがPMBOKなのでしょうか。
まあそうなのかもしれませんが。
作者のせいかもしれないという疑いを感じてしまい、今一つ信じきれません。

ちょっと安心して読めなかったので、
PMBOKについてはいずれもう一冊買って読む必要があるなというところでした。


昨日書いた文章にネットで感想をもらったところ、
かなり評判が悪かったので。
どうも数字が入る話は一般的にかなり評判が悪いらしい。
プログラマーだから違うとか思いたくもありますが、
でもまあ聞く相手に、プログラマーだから数字に強いって人あまりいないのですよねえ。
ということで数字の出てこない話を書きなおしました。
とはいっても私の話なんで、理系の話しかないんですが。

↓ここからが発表する予定。

ここ数年、Wikipediaを読みふけっています。
Wikipediaも昔は素人っぽくて微笑ましい記述とかが多かったのですが、
最近は出典を明記しろとかうるさく言う人も増えてきまして、
学術的に信頼のできるような記述も増えてきているようです。
まあドラマとか漫画の項目は学術的にもできないのか昔のままですが。

でまあ、結構自分が知っているつもりの分野でも、
発見があったりして面白いわけですね。

そこで今回は、生物の進化について意外だったことをいくつかあげてみます。
この辺に関してはここ10年くらい遺伝子学の発展によって、
驚愕の新事実がいくつも出てきているようで、
かなり常識が覆っているみたいです。
まあもともと私が勘違いしていて驚愕したってものもあるのでしょうが。

ということで。
古い順から。
四つくらいあげます。

まず。
キノコやカビは植物じゃなかった。
むしろ動物に近い生物だった。

そもそも生物は、普通の生物と細菌ともう一つの大きく三つに分類されるのですが、
その普通のの中に動物や植物やキノコの類と、あとマイナーなのがいくつもいるのです。
で、その中で動物とキノコはすぐ隣に分類されていて、
植物は割と離れたところに広がっているのですね。

次いきます。
魚の中でに、肺を持って空気でも呼吸できるってのがいて、
まあ水の中の酸素は少ないんで、
いちいち空気を吸って潜っているのも結構有利なのでそういうことをしているんですが。

そういうのが進化して両生類になって、その後陸上動物になっていった、
という話だったのですが。

実は、ほとんどの魚の祖先もその肺をもった魚だった、らしいです。
例外はエイとかサメくらい。

まあもともと両生類に進化したくらいなので、
魚の中でも優秀だったのかもしれませんし、
あと肺はなくなったんですがそれが浮き袋に変化して、
泳ぐのがうまくなったみたいですね。

動物の体ってのはもともと放っておいたら沈んでいくものなので。
エイとかサメとかは軽くするのに全身にアンモニアをためているそうですが。
まあその必要がなくなったと。


では次いきます。三つ目。
両生類の後は、恐竜が発展して、恐竜が滅んだあと哺乳類が出てきたと思ってましたが。
恐竜の前に、一度哺乳類が天下を取りかけていたらしいです。

そもそも哺乳類は恐竜が大発展する前からいたわけで、
いろいろ進化した仕組みを持っているわけですから、恐竜に勝っても不思議はなかったのですが。

一つ欠点があって。酸素を大量に必要としたのです。
で、たまたまそのとき酸素が大量に消費されて二酸化炭素が増えたらしい。
まあ今の温暖化と同じようなものですね。

今温暖化が生物に打撃を与えているとか言われているので、
温暖化は生物に悪いという印象を持っている人も多いようですが、
これは急激に環境が変化するので対応できずに滅んでいる生物が多いということで、
実際にはたぶん、熱帯ですごい生態系が発展していることからも、
温暖化したほうが生物の発展にはいいんですね。
まあ数千万年単位で、ではですが。

でまあ、酸素が足りなくなり哺乳類が細々と生き残るはめになったのに対し、
二酸化炭素が増えたので数メートルもあるシダ類が生い茂り、
それを食べる恐竜がどんどん大きくなるという楽園を経た後、
哺乳類はその間に横隔膜を発達させて腹式呼吸ができるようになり、
でまあ恐竜が滅んだこともあっていよいよ哺乳類の世の中になった。
ということらしいです。

次が最後です。
クジラは牛の仲間だった。
カバも牛の仲間なので、カバの仲間といったほうがイメージにはあってますが。

もともとクジラ目というのと、牛の仲間の偶蹄目というのがあって、
ある程度は近いけれども別々だと思われていたのですが、
遺伝子の解析をしたところ同じ仲間だということがわかったようです。

でまあ、普通は偶蹄目のほうがかなり大きいので、
クジラは偶蹄目の一種だ、ってことになると思うのですが、
生物学者にとっても衝撃的だったせいか、
クジラ目も偶蹄目もなくなって、
クジラ偶蹄目という新しい分類ができてしまっているようです。

でまあそう言われてよく調べてみると、
偶蹄目にある後ろ足を早く動かす骨がクジラ目にも残っていたらしいですね。
後ろ足はなくなってますけど。

ということで。
今日の話はこれで終わります。
会社の朝礼でなんか語れと言われたので、
意見をまとめてみました。
で、せっかくなのでブログに。

あんまり趣味に走るのもなんですが、
自分で面白いと思うことじゃないと聞いているほうもつまんないでしょうし。
プログラムの話ということで。
はてさてどうなることやら。

↓ここからが発表する予定。

今日はプログラムの美しさについて語ってみようと思います。
といってもプログラムの話はあんまりでない予定です。

そもそも美しさとはなんでしょうか。
それを考えるためにまず、美しい人間について考えてみます。

こういう話があります。

たとえば鼻の幅とか目の位置とか人間の顔の各要素について、
多くの人の情報を集めて平均をとります。

そしてすべての平均値を使って顔を描いてみると、
非常に美しい顔になるそうです。

平均的なのに非常にってのは一見矛盾するように思えるかもしれませんが、
これは平均という数字についての誤解から来るものです。

たとえば。
平均的な高さの山というと世の中にはたくさんあると思いますが、
完全に平均の高さを持つ山というと、平均値から1㎛ずれても駄目なわけですから、
たぶん存在しないでしょう。

ましてやすべての地点が平均の高さを持つ山となると。
つまりすべての地点が全く同じ高さになるということで。
水平で完璧に真っ平で表面は磨き上げられたようになっていることになります。

そんな山見たことないですね。

つまり、だいたい平均っていうと凡庸ですが、
すべての面において平均、とまで言うとそれはすごい個性になるわけですね。

ではなぜすべて平均だったら美しく見えるのでしょうか。

人間の感覚は、進化の過程で身についたものなので、
だいたい合理的にできているものが多いです。

人間の脳の画像認識のしくみは、人間の顔を認識することに最適化されているでしょう。
その脳で、全てにおいて平均的な顔を認識するというのは一番認識するのにエネルギーがいらず、
シンプルに理解できると思われます。

このことから、人間はシンプルなものを美しいと感じる、
という仮説が立てられます。

そしていろいろなことを考えてみると、
それに当てはまることは多そうです。
詳しいことは今日は割愛しますが。

プログラムの世界でもシンプルさは大事とされているので、
これはプログラムの美しさが重視されることと関係していそうですね。


さて。
次の話として。
他に美しさが重視される業界を例に挙げてみたいと思います。

美術とかファッション業界とかだと、
単純に美しさそのものを売り物にしているわけですから、
話は単純です。

が、プログラム業界は別に美しさを提供してお金をもらっているわけではありません。
それと似たようなことが起こる業界として、科学や数学の世界などがあげられます。

たとえば物理の世界でも、シンプルさというのは重要視されます。
経験則として、宇宙の法則はシンプルである、というのがあるからですね。

そして先ほど出てきたように、シンプルさは美しいと感じられるので、
法則や数式の美しさが重要視されます。


ここで、アインシュタインが相対性理論を初めて発表した時の話をします。

当時電磁気学という学問が、かなりシンプルな公式にまとまってきていました。
が、そこから一つの矛盾が導き出されていたのです。
それは、光の相対速度が一定になるということ。

普通、相対速度は一定にはなりません。
西に進んでいる車を、
同じ西に進んで車からみればあまりスピードが出てないように見ますし、
東に進んですれ違う車彼見ればすごいスピードに見えます。

が、光の場合はそうではないと。
西に秒速30万キロで進んでいる光を、
西に秒速29万キロで進みながら見ても、
東に秒速29万キロで進みながら見ても、
同じスピードに見えるというなんかおかしい結論が出ていたのですね。

その矛盾を解決しようと、
いろいろ複雑なつじつま合わせが考えられていたのですが、
アインシュタインの考えは非常にシンプルで美しいものでした。

美しくまとまった理論からそういう結論が出るのなら、
それを素直に認めるのが美しいんじゃないかと。

そしてそれを前提に物理法則を計算しなおしてみたのですよ。

そうするとまあ、原点が妙なところから始まっているので、
出てきた結論もちょっと常識からは考えられないものでした。

西に進んでいる人にとってみると、
東に進んでいる人は細くなります。
でも体重は増えてます。
そして時間の進み方が遅くなってます。

そしてそれはお互いさまになります。
寸法や体重はともかくとして、
お互い相手が自分より遅くなっています。

そんな常識外なことが現実だって言うなら、
どうして世の中でそういうことを見た人がいないのか。

それはそうなるためにはすごいスピードで遠ざかる必要があるので、
今まで誰も測定できなかっただけなのだと。
西に行くっていっても1秒で地球の反対側までいける人でやっと0.5%時間が遅れるくらいなので、
そんな速く移動したことがない人は今まで気づかなかなかったのだと。

まあ常識的に考えると無茶苦茶言っているようにしか思えないわけですが。

実際その理論をもとに、実験なんかしてみたら。
その理論通りだということがわかってしまったのです。
実際遅くなっていたのですね。

でまあ大発見ということになった。
今も普通の生活をしていたら時間が遅れるなんてことはありませんが、
私の大学時代の研究室なんかではその時間の遅れがなければ片っ端から実験が失敗するような研究をしてましたし、
GPSなんかもそれがないと動かないような仕組みになっているそうです。

さてここで重要なのは、
別に美しかったから正しいとされたわけじゃないのです。
理論をちゃんと作って、それに基づいて地道な実験が行われ、
その結果が理論道理だということが確認されたから、認められたのですね。
そこに美しさは何も関係していません。

まあ実際のところ、
アインシュタインは晩年に同じくらい美しい考察に基づいて、
壮絶に無駄な研究に時間を使ってしまっていたらしいですし。
結果が出なければそれまでなのですよ。

ただ、最初に、
美しくシンプルな理論から出たことを、
シンプルにそのまま使って理論を構築する、
ということをやったのは、
シンプルだからそれは正しいと信じてないとできなかったわけですね。
信じてなければ、そんな常識はずれな結論なんか発表せずに捨てていただけでしょうし。

このことから、
美しさは結果について何の保証もしないけれど、
結果を導き出すヒントになることはある、ということです。


さてここでやっとプログラムの話です。
ここまでの話をプログラムに応用するとどうなるか。

プログラムというものはとかく複雑になりがちなものですから、
常に極力シンプルにしていく努力をしていかないと、
開発、保守工数が爆発的に増えて使い物にならなくなります。

で、人間はそのシンプルさを、美しさという感覚で感じることができる。
だから美しさを求めることが大事です。

ただ、美しいことが必ずうまくいくかというとそうではない。

そもそも開発保守工数を節約するための方法論なんて、
開発現場ごとに微調整が必要なものですから。
美しいものを作るなんてどんぶり勘定だけでうまくいくわけがない。

だから、この自分の美しいという感覚は、
本当に工数の節約の役に立っているのか。
疑問に思ったら根拠だてて確認する必要があります。

そしてその根拠に合わせて、自分の美的感覚を微調整していかなくてはならない。

そういう手間をかける必要は依然としてありますが、
それをやっていれば、
少なくとも大体の作業においては、
人間の生まれもった美しいという感覚だけで、
一瞬でシンプルさを判定することができ、
正しいプログラム技法を選択することができるようになる。

とまあプログラムという工業的な作業に美しさというものを持ち込むことには、
そういう利点があるといえます。
読んだ技術書がたまっていたので、
その感想で続いているのですがね。

まあこういうのがあると、
本を読む意欲がわいてよいですな。

読みたい本は多いのですが、
やっぱり技術書は小説よりは読みにくいもので。
一度止まったら全然進まなくなるもので。

勢いで読んでいけるのはよいですな。

続けて書いているうちに、
下書き機能というのを使えばいいと気づきました。

今日はもう書いたし、とか思わずに済むと、
ケチらずに書けるというものです。

よいものですな。
三日坊主を返上できるかも。
マイクロソフトの社員が書いた、開発手法の本です。

マイクロソフトというと、
まあいろいろ評判の悪いところもありますが、
基本的には優秀な人材を集めているわけです。

実際あれだけのソフトウェアを作り出せる会社はあまりありません。

巨大な会社だからシステム的にしっかりとした開発をする必要もあります。

また、マイクロソフトの主義として、自社のドッグフードを食べてみる、
というのがあるそうです。

自社製品はまず自分たちが使ってみる、という主義だそうです。
だから、マイクロソフトの開発者向け製品に一番親しんでいるのは、
たぶんマイクロソフトの社員です。


そういう人が、開発手法について書いてあります。
多数の大規模プロジェクトの経験に裏付けられているであろう、
大変スマートな開発手法について知ることができます。

まあ大体その他の開発手法に書いてあることと同じようなことが書いてあるんですけどね。
そんなに世間と違った方向を目指しているわけもないですし。

とはいえ、ちょっと特徴的なところもあり、参考になります。
アジャイルっぽいこともかなり取り入れているとはいえ、
ウォーターフォールに近い感じは強いです。

大規模プロジェクトを多く経験しているというのも大きいでしょうし、
頭のいい人ばかりだから、完全に近くフレキシブルな設計を最初にやることも得意なのでしょう。

マイクロソフトの製品の紹介が多いのも特徴の一つ。
まあ社内で強く推奨されているのだから、
その経験が多いでしょうしね。

全体的に一社のもので固めるというのも、
全体をシステマチックに固めることができる要因の一つなのでしょうね。

ハンガリアン記法を勧めていたところあたりは、
少し笑ってしまいましたが。

.NETでは非推奨になっているのですから、
マイクロソフト的にもすでに非推奨と言っていいと思うんですがね。


などなど。
なかなかおもしろく、考えさせられ、参考にできる本でした。

基本的な開発手法の心得も大体抑えてありますし、
読んでみるべき本ではあると思います。
とある会社の社長の書いた本。

以前同じ人の本を読んだ時調べてみたら、
ブラック会社のワンマン社長らしいのですが。
その時点ですでにこの本も買っていましたし、
まあ別に著者の性格によって書いている内容が変わるわけではないのでいいでしょう。

内容を鵜呑みにすると危険かもしれないとは思いますが。

まあ実際、ちょっと無茶かなということも書いてあります。

保守契約の見積もりの監査を行う中立の機関が必要、
というのが著者の主張なのですが、
その事例として自社の行った監査をあげるのはどんなもんでしょうか。

また。
監査を行うことによって、
今までどんぶり勘定で余分にかかっていた費用が削減できる、
という主張なのですが。

減る分だけ明確になるってものでもないような。
今までどんぶり勘定でサービスしていた分もあるでしょうに。

値下げ分だけを表に出したら、
赤字になったりつぶれたりする会社ばかりになるでしょうし、
そうなったら全体的に値上げをせざるをえない。

ということを著者は考えていっているのかもしれませんが、
少なくとも書いてはありませんね。

まあ全般的に、作業する側ではなくお客さんをメイン読者と考えている本のようですから、
そういう書き方になっているのでしょう。

独断専行のワンマンだから考えてないって可能性もありますが。


とはいえ。
作業をする側の人間としても、
何も考えずに反論ばかりする抵抗勢力をやってばかりいるわけにもいかない、
ということは認めざるを得ないんじゃないでしょうかね。

どんぶり勘定をやめて細かい話がお客様とできるようになれば、
一つ一つの点について、建設的に作業の効率化をすることもできます。
それは大変なことですが、ちゃんとやれば競争優位の元にもできる。

著者の言う通り、それをやっている国際社会で、
競争に一方的に負けないためには、
確かに必要なことなのですよ。

そういう意味で、著者の主旨をちゃんと読みとれば、
いい本なのではないかと思いました。
Silverlightの調査にかまけて、
いろいろ作るのを休止していましたが。

構文解析とともに、xlsxファイルの解析も再開。

新技術を調べるのも面白いですが、
きりがないのでちょっとずっとやっていると飽きてきますな。
考えて作り上げるってのもやらないとモチベーションが下がります。

まああまり気合を入れても燃え尽きるのが早くなるだけなんで、
ちょっとずつですけどね。

Office Open XML SDL2.0も試してみてますが。
割と使いにくいように思えます。

膨大なOffice Open XMLのすべてを扱えるようにすると、
どうしてもXMLを扱うインターフェースが主になり。
それにExcelのインターフェースが混ざっている感じなので、
全体的に見通しが悪いですね。

まあそもそも扱わねばならないものが膨大なので仕方ないのですが。
気軽に使えるライブラリはやはり自作する必要はあるみたいです。

とりあえずC#で初めて、必要に応じてVBに移行、ってのをやってみたくて、
あえてC#でやってますが。

たぶん、XMLの扱いについてはVBにかなり差をつけられているってのを、
実感することになるであろうと思います。
まあそれが実感したくてあえてやっているのですが。
プログラムの達人になるための方法が、
ずらっと並べて書いてある本です。

最初のほうから、
プログラム言語を1年に一つは覚えろというのと、
メールは推敲して出せということが書いてあり、
著者の本気さがわかります。

技術力は容赦なく身につけつつ、
もちろん対人関係もちゃんとできないと達人にはなれないと。
もっともな話ですな。

全般的に、プログラムに大事なことが片っ端から書いてあります。
こういう本は結構あるものですが、
有名な本だけあって実際の役立つことが分かりやすくまとまっていますね。

10年前の本のようですが、
抽象的なことについてはそうそう古くはなっていません。

が、実際に具体的にコードの例をあげている部分もあり、
そういうのは少し古い感じがするので、その辺が残念です。
この本を読むくらいの人なら新しい具体例に読み替えることもできるでしょうが、
にしてもちょっと違和感を感じてしまい読みにくさにつながっています。

「人月の神話」くらい古ければ、今とは全然違うため、
かえって違和感なく読み替えられるものですが。
中途半端に古いのが気になりますね。

全般的に、かなりためになる本でした。
以前作っていた構文解析のライブラリですが、
関数型言語があっていそうなので、
F#で作りなおすことにしてみました。

絶対に車輪の再発明ですが、
学習を考えると車輪の再発明はぜひやるべきなのでまあよしです。

F#の練習にちょっとずつ進めていこうと思います。

ちゃんと他の.NET言語からも参照できるライブラリにしようかとも思ったのですが、
F#にはF#向けのライブラリがあり、
.NETのインターフェースは付け足しのようなので、
まずF#として正しい書き方を探ることにしてみました。

関数をつないでやろうかと思ってやっていますが、
うまくいくかどうかは不明です。
そもそも発想が間違っているかもしれませんが。
まあうまくいくかどうかを探りつつ進めていきます。