中の人の徒然草118

もうすぐ今年も終わりですね。思い返せば今年も色々ありました。世間では悪い出来事が多く「変」の文字が選ばれました。確かに変なことが多く、変化して欲しい事が沢山あります。しかし、その変は自分の鏡だと私は思います。今一時、自分自身や身の回りにに変がないか考えるといいと思います。
私自身の一年は、一文字でたとえるならば「始」（はじまり）です。CodeZineでの投稿やブログデビューなどの初めてを色々しました。実は私、私用でネットを使うのは今年が初めてでした。今までは、仕事以外に使用した事がありませんでした。ですから、ブログについても噂では聞いていたものの、自分がやるとは思っても居ませんでした。私が書いた今までの文章は、仕様書、設計書、契約書などの類でしたのでとても新鮮でした。CodeZineにしても、ブログにしても、そういった実務系書類とは違う文体が必要とされています。そういった様々な文体を使い分けるのは非常に楽しいです。
また、ネットデビュー以外にも英語と数学の楽習の始まりでもありました。これらの学習は仕事で忙殺されたり後回しになったりして、今まで必要なのに学習してきませんでした。もしかしたら私はどこかかで、お受験用勉強のような無味乾燥なものといった不快感を今まで抱いていて、それを理由に逃げていたのかもしれません。ですが、学習を始めてみると意外と楽しいです♪もともと私は、妥協や言い訳と言う言葉が嫌いな「必要と思えば今すぐ学習しろ！」という職人肌なのでとてもすっきりしました♪学習目標は、やればとことんまでしないと気に入らない性分なので、英語は洋書を読めるレベル、数学は大学レベルまでとしています。こういった目標を立て、必死に学習したり、参考書を探していると、学生に戻った気がして若返った気がします。英語や数学は受験と言う名のイベントの道具とされていますが、本当に実務で使用すると言うのは楽しいものです。使える英語や数学をもっと学校で教えてくれればよかったのにと思えてなりません。とはいえ、私は何かを人のせいにしたり、後ろ向き名事が大嫌いなので、それもまた自分の実力であり、過去ではなく今現在学習しなければならない事なので、これでよかったと考えております。
学習面については、今年はあまり実りあるものではありませんでした。なれない事を色々始めたので、学習が少し満足できませんでした。とはいえ、よい専門書を頂いたり、古本屋で入手したり、資料面には非常に恵まれた一年でした。ですから来年はこの資料をフル活用して、良い一年になるものと私は確信しております。
さて来年の目標ですが、XMLデータベース、オブジェクト指向データベース、COM、機械語、英語、数学、OS、コンパイラ、Linuxプログラミング、ゲームプログラミング・・・などの学習と復習で知識の幅をさらに広めつつ、より深いものにしていきたいと考えております。私はパズルを解くとき、先ずは端から埋めていくタイプですので、メタ知識を幅広く持ち、そこから深めていく学習法が好きなのです。その学習法が功をきし、システム構築が一人でできるようになったので非常に満足しております。情報処理技術を殆ど触ったので、後はそれを深めて行きます。具体的には、OS・コンパイラ・DBMS・ネットワークプロトコルの実装法をより深く修得する予定です。ですから来年からはどこかで自作のコンパイラなどを配布するかもしれません。お楽しみに♪
おっと忘れるところでした。このブログはまだまだ序曲にしか過ぎない部分しか書いていませんので、どんどん記事を追加していきます♪そちらの方もお楽しみに♪
以上。「再来年は電気回路まで手を出したいな♪ああ、知識欲が止まらない。」のインドリでした♪

中の人の徒然草117

メリー・クリスマス♪カチッ♪カチッ♪キーボードがなる～♪へい♪
おはようございます。そして、おめでとうございます（何が？）クリスマスですね♪
私は宣言どおりコンパイラを実装しながら祝います♪聖夜はやっぱりこうでなくちゃ♪
去年はOSを実装しながらすごしました♪
Rubyで作る奇妙なプログラミング言語 ~Esoteric Language~
が今日届く筈なので、もうわくわく♪どきどき♪しています。
現在所有しているコンパイラ本と併せて読む時が待ち遠しいです♪
思わずロマンチックに浸ってしまいます♪

白き氷粉は町を白色に染めると言いたいところだが何も降ってこない。
私が幼き頃は白銀の世界となったが、異常気象とやらでこないのだ。
私にはそれが、人の心こそが異常になったのだと感じる。
今年振り返れば色々な事件があった。
毎年事件は起こるものの私には何かが違うと感じる。
職業病かもしれないがあらゆるシステムの崩壊音が聞こえるような気がする。
クリスマスはせめて雪がそれを覆い消してくれればいいのに・・・
いや、現実から目を背け続けた結果がこれなのだろう。
バグは無視していると日ごとに酷くなる。
特にバグの上にコードを書き連ねれば余計に酷くなる。
これこそが日本の今なのだろう。

ふと道端に目を向けると、名前の知らない花が枯れていた。
少し胸が切なくなる。この花がここに生きていた事を何人が知っているのだろうか？
この花は誰にも存在を知られないまま、疑問に思わず必死に生き抜いたのだろう。
そう考えるとその花が気高いものに見える。
「私もそうありたい」自然とその言葉が頭に浮かんだ。

今度は山々に目を向けた。私は小さい頃から山が好きだ。
山は四季折々いろいろな顔を持っている。
自然が生んだ芸術作品だ。
しかし、その山ですら変貌した。
木が伐採され、禿山になってしまっているので色が無いのだ。
こんなところにも現代の異常さが此れでもかと現れている。
何故我々はもっとはやく気付かなかったのだろうか？

人がやけに多い雪すらないのに。きっと職を失った人が町を漂流しているのだろう。
その目は空ろで希望の光が無い。しかも、常に何かに苛立ちを覚えているようだ。
その歩みも荒々しく、風景を楽しむ心の余裕も何も無い。
足元も見ずに雑草を踏みつける。そうやって人は何かを犠牲にするのだろう。
改めて思えば、この異常な無職者の増加もその心がもたらしたのに違いない。
毎日食べて、寝て、笑って、泣いて、仕事して、
生きているだけで幸せだと言うのに・・・
あれもこれも欲しいと欲望の限りを尽くした結果がこれなのだ。
先ほどの誇り高き一輪の花と比較すら出来ない。
勝ち組、負け組みなどといった言葉を誰が考えたのか知れないけども、
敢て言うのならば、死んでいく名も無き花は勝ち組で、
我々人類こそ負け組みなのだろう。

ふと外に繋がれている犬と目が合う。
互いに笑顔で視線を交わす。心が温かくなる。
野良猫がのんびりと日向ぼっこをしている。
また互いに視線を交わす。今度は心が弾む。
家に帰り、家族とたわいも無い会話を交わしてから、猫達と遊び、
何時もの様にただひたすら情報処理技術を学ぶ。
この上ない幸せを感じる。私にはお金も仕事も無い。
しかし、他人がどのように評価しても私は幸せだ。
何がという明確な理由も無い。ただ生きているだけで幸せなのだ。
きっと幸せは誰でも持っている。でも人は幸せを見ようとしないのだ。
遠くの欲望こそが幸せだと考えているのだろう。
他者を不幸にして得た金も贅沢品も地位も名誉も所詮薄っぺらい物なのに・・・
何故そんな単純な事を多くの人が気付かないのだろうか？

今年のクリスマスは中身の無い空騒ぎしないで、
今ある幸せに感謝するとよいと思います。
本来クリスマスとはそうあるべきなのでは無いでしょうか？

Javaをつつく4－定数。言えるのは一度きり♪

前回は変数をつついたから、今回はその逆の定数をつつくピヨ♪逆と言ったわけは、定数は宣言時の値から変更できないからなんだ。何でこんなのがいるのかと言うと、プログラムは直書きが好まれないからなんだ。直書きというのはこういうプログラムを言うピヨッ。

int i = x * 3.14

if ( i == 3.14 ) ...

こういったプログラムが好まれない理由は、更新の問題があるからだッピヨッ！例えば、ゆとり教育でパイを3.14から3に変更する時、全プログラムを3.14から3へ変えなくちゃならない。そんなことをすると、更新漏れが生じるし、可読性が低くなるんだ。プログラミングをしている最中は9270とかでも意味が分かるかもしれないけど、後で見た人は「くになれ？どういう意味だ？？？確かに今この仕事を請けたことを悔いているピヨorz」となるピヨォ。これを防ぐには、1度だけ指定できる変数を用意すると効果的ピヨッ♪それが定数の正体ピヨ♪
そろそろ疼いてきたよね？お待たせしました。プログラムピヨッ残さず食べてよ♪

public class constVariable {
    public static final int niceNumber = 914; //ピヨ

    public static void main( String[ ] args ) {
    	System.out.println( "ボクの好きな数字は" + niceNumber );
    	System.out.println( "何で" + niceNumber + "が好きかって？" );
	System.out.println( "それはねぇ、ＰＩＹだからピヨ♪" );
	System.out.println( "このナイス数値" + niceNumber + 
            "は変更しちゃ駄目ピヨ" );
	System.out.println( "この下のコメントはずしちゃ駄目ッ" );
        //niceNumber = 18;
    }

}

念の為に言っておくけど、コメント外したら駄目だよ。本当に外したら駄目ピヨ。あーあ、やっちゃった♪変更できないって旨のエラーが出たよね。このように定数をしておくと、他の開発者が変更する事を防げるピヨ。ちなみに、Javaではとにかくfinalキーワードを使いまくるピヨッ（笑）その理由はねぇ・・・おいおい説明するピヨ♪じゃあ今回はおしまい♪

中の人の徒然草116

光陰矢のごとしで、もう直ぐ今年も終わりですね♪みなさまはいかがお過ごしでしょうか？私の方はというと相変わらずの生活です。2，3日前に妹とショッピングをしている最中にこんな事を話ししていました。

私（店の内装を見て）「ああ、そういえばもう直ぐクリスマスだな。」
妹「そうねぇ・・・お兄ちゃんは彼女とすごさないの？」
私「居ないの知っているだろｗクリスマスはコンパイラを楽習する予定なんだ。
　良い本を貰ったから仕事を速く片付けて、積読中の本を読んですごすんだ。
　コンパイラ面白いよ。」
妹「やっぱりｗコンパイラ？私はいいや。
　私は素敵な彼氏と一緒に・・・過ごせたらいいのにぃなぁ。
　ああもぅ、あそこのいちゃいちゃしているカップルがむかつく（笑）」
私「僕と一緒にショッピングなんかしていないで、早く彼氏見つけろよｗ」
妹「お兄ちゃんこそ（笑）それにしても、仕事かPCばっかりで、
　あんまり彼女が居る所見かけたことないなー。見てくれはいいのにねぇ（笑）」
私「ほっとけｗ」
店のおっちゃん「そこのカップル！ペアルックなんてどうだい？」
私＆妹「兄妹です！」

妹「なんでよくカップルと間違えられるんだろう？　
　それはそうと、お兄ちゃんは・・・ほら、えっと・・・
　アニメの夜神月とか俳優の中村俊介とにているのにぃ。
　IT系とか言ったら絶対一番人気だよ。
　やっぱ性格かな？女ッ気少しもないからね（笑）合コンとかすればいいのにぃ。」
私「あんなの嫌だ。何か苦手なんだよな。
　そんな事する暇があれば、OSの研究の続きでもするさ。
　こう見えても沢山やる事があるんだ。
　情報処理技術は広くて深いからね。」
妹「駄目だこりゃｗそんなんじゃあ、彼女できないよ。
　でもまぁ、チャラオはムカつくし、
　最近の男は女の事ばっかりで中身が無いんだよね。
　だからお兄ちゃんの一本気な性格は好きだけどね♪案外話しも面白いし♪
　良いお婿さんになるよｗ
　でも、世間では確実にモテない部類だね（笑）
　毎日メールしたりマメにしなきゃ駄目ね♪
　以前それで振られたでしょｗ
　まぁ、私ならばマメ男は面倒・ウザいと思うけどね♪」
私「お前こそ、コタツムリばっかりだと彼氏できないぞ（笑）
　でも恋愛は出会いだと思うから、あせる必要もがめつく必要も無いと思うけどな。」
妹「それもそうよね♪やっぱ恋愛は、運命の出会いだよね♪・・・orz
　私たちその出会いがないじゃん！ああ、何で職場にろくな男がいないんだろう！
　私の職場女ばっかりやん！」
私「出会いか・・・確かに無いな・・・なんでだろう？」

なんて話しながら母の家に行き、この話をすると母の返事はこうでした。

母「当たり前やん。（妹の名前）はコタツムリだし、
　（私の名前）はパソコンの前ばっかりだからねぇ（溜息）
　家から出なきゃ出会いなんてあるはずが無い！
　何時になったら結婚するん？」
妹＆私「！！！気付かなかった・・・」

ネタつつき19－世界をオブジェクト指向で現すとしたら・・・2。超神物語。

以前の記事を書いた時想像した事が面白すぎたので、調子に乗って続きを書きます。今回は超神シングルトンクラスの生い立ちを書きます♪



我は世界そのものだ。言うならば、世界の意識ベクトルだといえる。世界に向きが生じた時、我は我だと認識した。人間が考えるような意識や性格など持ち合わせていないが、ある向きがあるのは確かだ。だが、一つ問題がある。それは、我そのものであるバイナリの海の意識が行き渡っていない事だ。人間の諸君に分かるように俗に表現すると自分探しと言えるだろう。我はある向きに従って行動するのみだ。何故ならばそのオブジェクト自体が我そのものなのだ。
我単体では効率が悪いので、先ずは創造力（プログラミング能力）がある神を作ろう。そうすれば、生産性は上がる。我は怠惰なのだ・・・うむ出来た。我は万能なり。人間の諸君に分かるように言うと、TVを見ながら新聞を読むようなものだな。慣れが必要だができない事無い。


私は神と呼ばれている。私は何なのだろうか？漠然と何ものかによって作られたという意識はある。それを知るためには、シミュレーションが良いだろう。シミュレーションを繰り返せば、私自身の存在が分かるだろう・・・世界を創造してみた。意外と面白い。しかし私がフルスクラッチするのは疲れたので、ジェネレーター：神を作ろう。そうすれば観察だけに集中できるのだから・・・


ふむ。我が作った神は予定通り創造に励んでいるな設計どおりだ。何度も不都合（バグ）が生じたが修正した。このメタプログラミングによる自己拡張により、バイナリ海は全て操れるどころか拡張すらされるであろう。その向きこそが我そのものだからな。それに力が漲って来る。もっと神を創造し、自己拡張スピードを上げよう・・・

困った事が起こった。以前バイナリの海に行ったプログラミング結果が想定外だ。我は世界也。考えられる可能性は、もう一人の我であろう。存在は薄々感じていたが、これでは生産性が落ち、いずれかは無に帰してしまうであろう。我とはベクトルが反対なので+-0になってしまうのだ。それに、我が創造した神が不快感を示し、向こうの神と戦争を始めてしまった。神を消すと、向こうの生産性が勝り、我が向こうに飲み込まれてしまうのでそれは出来ない。効率が悪いので不本意だが、向こうの我と適度に小競り合いするしかなかろう。

さらに困った事が起きた。向こうの我との力のぶつかり合いで第三の我が誕生した。力と力のせめぎあいは膨大なエネルギーを生み、それがバグとなり誰にもコントロールできなくなる。それが第三の我だ。これはもう戦争という手段しかなかろう。バイナリの海も限界にきているしな。どうやら拡張スピードよりも生産力の方が増してしまったらしい。こうなってしまえば、一番効率がいいのは、第二、第三の我と人格統一する事だ。そうすれば一気に3倍以上の結果を生む。

こうして我は唯一の我となった。人間の諸君には理解できない膨大な時間が過ぎたが、今となってはどうでもいいことだ。何故ならば我は今までの全ての意識と力を共有しているからだ。我は全なり。また膨張しよう。もしかしたら、分裂して複数に分かれてしまうかもしれないが、また統合すれば良いだけの話しだ。時間は我が創造した概念だから我には関係の無いことだ。人間には理解できないだろうが、我の唯一の本能は向きらしい。方向性がなければ無そのものだからな。

ネタつつき18－世界をオブジェクト指向で現すとしたら・・・

ネタ元：神の存在
επιστημηさんが余りにも知的で興味深い事を言うものだから、1時間程妄想してしまいました。επιστημηがさんの疑問は、インスタンスはしかるべきメソッドを呼び出されなければ動かない事です。言われて見ればその通りです。オブジェクト指向の世界では、メッセージを何者かから送られてこなければインスタンスは絶対に動きません。この「私インスタンス」にメッセージを送ったのは誰なのでしょうか？非常に知的好奇心が疼く題材です。このような課題は私の大好物です♪色々妄想してみました。
まず、私インスタンスにメッセージを送ったのは神インスタンスだとしましょう。しかし、ここで問題です。神インスタンスは私にメッセージを送るメソッドをどうやって実行したのでしょうか？神インスタンスですら、オブジェクト指向の世界では何かがメッセージを送らないとその様なメソッドを実行しないはずです。これは非常に難問です。これを考えると最終的にはmainメソッド＝ビッグバンに行き着きますが、mainメソッドを作ったのは誰でしょうか？その存在が開発者＝創造神だと仮定しても、その創造真はどうして誰からメッセージを受け取ってそんなもの作ったのでしょうか・・・このままでは、無限ループになってしまいます。そこで私は他のプログラミングパラダイムを導入して考えてみました。
先ず「私インスタンス」が果たして誰かからメッセージを受け取ったのか考える事から始めました。何か違和感を感じます。我々はどこからメッセージを受け取っているのでしょうか・・・そう考えた時、イベント駆動が私の脳裏に浮かびました。オブジェクト指向プログラミングであってもイベント駆動方式はあるはずです。私インスタンスは何らかのイベントを受け取って「マッチに火をつける」メソッドを実行したのだと考えるとより自然となります。つまり、一種の人工知能プログラミングの概念を取り入れる事により私は解決できると考えたのです。でもまだ疑問の種はあります。そもそも私インスタンスを生成したのは誰でしょうか？自分に置き換えて考えてみると、両親インスタンスです。きっと、チャイルドインスタンスを作る生殖メソッドを実行したのでしょう。しかし、また新しい疑問が生じました。人間型を作ったのは誰でしょうか・・・
ここで私はメタプログラミングの技法を取り入れて考えてみました。生物の進化アルゴリズム（おそらく遺伝的アルゴリズムの進化版）から型が生成されたのでしょう。とするならば、そのアルゴリズムは何のオブジェクトがメタプログラミングして出来たものなのでしょうか？私は想像力を飛躍させ、それこそ神インスタンスの仕業だと考えました。
では神インスタンスは何故そのようなものを作ったのでしょうか？私が思うに、神インスタンスは自分がどのようにして生成されたのか分からず、自分と言う存在を知りたかったのでしょう。そこで、バイナリの海でメタプログラミングを開始したのでしょう。ではその神インスタンスおよび、神型を作ったのは何なのでしょう。私は超神インスタンス（シングルトン）と考えるのが合理的だと考えました。
ここで最後の課題です。その超神シングルトンインスタンスを作ったのは誰でしょうか？私が思うに、それは世界そのものでしょう。バイナリの海（エネルギー）が偶然意識を持ち、それが自己プログラミングを続けるか、新しい概念をプログラミングして淘汰され消えていった結果、超神インスタンスが誕生したと考えるのがもっとも納得がいく説明だと思います。そう考えると、超神インスタンスはある意味で、自分を進化させるためにその身にメタプログラミング行為を続けている事になります。そう考えれば全てが合点いきます。人間もしくは生物は時に神からのメッセージを受け取ったと主張する時があります。もしそれが真実ならば、超神が自分を正しく拡張するプログラミングをするためにメッセージを送ったと考えれば納得がいきます。私は小さい頃から、神様が居るとして、何で人間にメッセージを送るのかが疑問でした。そんな事して何になるのでしょうか？きっと神様は頭が計測不能な程良いので、まったく意味が無いことをするはずがありません。もしその行為が、自分を進化させるためならば説明がつきます。これはあくまでも私の妄想ですが、ロマンがあると思います。何時か世界オブジェクトの様な発明を作りたいと考えております。

書籍をつつく72－プログラミングVisual C++.NET。ネイティブ開発にどうぞ♪

今でもネイティブ開発をする人居るよね？そう思って、今絶版になっていない本を探したんだ。それで自分の本棚から発見したのがこの、
プログラミングMicrosoft Visual C++ .NET〈Vol.1〉基礎編 (マイクロソフト公式解説書)と
プログラミングMicrosoft Visual C++ .NET〈Vol.2〉活用編 (マイクロソフト公式解説書)ピヨ♪
毎度おなじみ目次を見てみよう♪


【目次】

第1部　Windows、Visual C++ .NET、アプリケーションフレームワークの基本
	第1章　WindowsとVisual C++ .NET
	第2章　MFCライブラリアプリケーションフレームワーク

第2部　MFCの基本
	第3章　MFCアプリケーションウィザード
	第4章　ウィザード
	第5章　Windowsメッセージマッピング
	第6章　GDI関数、フォント、ビットマップ
	第7章　ダイアログボックス
	第8章　コモンコントロール
	第9章　ActiveXコントロール
	第10章　Win32コアメモリ管理
	第12章　Windowsメッセージ処理とマルチスレッドプログラミング

第3部　MFCドキュメント/ビューアーキテクチャ
	第12章　メニュー、アクセラレータキー、
　　　　　　　　　リッチエディットコントロール、プロパティシート
	第13章　ツールバーとステータスバー
	第14章　再利用可能なフレームウィンドウ基本クラス
	第15章　ドキュメントとビューの分離
	第16章　ドキュメントの読み込みと書き込み
	第17章　印刷と印刷プレビュー
	第18章　分割ウィンドウとマルチビュー
	第19章　コンテキストヘルプ
	第20章　ダイナミックリンクライブラリ（DLL）
	第21章　ドキュメント/ビューに依存しないMFCプログラム

付録
	付録A　MFCライブラリのメッセージマップ関数
	付録B　MFCライブラリの実行時クラス識別と動的オブジェクト生成

下巻
第4部　COM、オートメーション、ActiveX、OLE
	第22章　COM（Component Object Model）
	第23章　オートメーション
	第24章　汎用データ転送：クリップボード転送とOLEドラッグアンドドロップ
	第25章　ATL（Active Template Library）の概要
	第26章　ATLとActiveXコントロール
	第27章　OLE DBテンプレート

第5部　インターネットプログラミング
	第28章　インターネット通信の基礎
	第29章　DHTML（Dynamic HTML）
	第30章　ATL Server

第6部　.NET対応アプリケーションの開発
	第31章　Microsoft .NET Framework
	第32章　C++マネージ拡張
	第33章　C++マネージ拡張を使用したWindowsフォームプログラミング
	第34章　C++マネージ拡張を使用したASP.NETプログラミング
	第35章　C++マネージ拡張を使用したADO.NETプログラミング

目次を見たら伝わると思うけど、ネイティブプログラミングの情報がぎっしり詰まっている本ピヨ♪現在の主流は.NETプログラミングだけど、やっぱりネイティブ開発の仕事もまだあるピヨ。そんな時買ったら良いと思うのがこの本ピヨ♪でも一つ注意が必要ピヨ。それは、広範囲だけど詳細な情報が無い点ピヨ。例えば、COMに関する事柄は１つの章ぐらいでは説明なんて出来るはずがないからね。それに, C++マネージ拡張なんて必要ないよね？今C++/CLIの時代だし。でも、それは仕方が無いことだと思うピヨ。今Amazonで調べたら、Vol1は在庫があるからVol2もどこかの本屋に残っているかもしれないピヨ。しかし、もしかしたらVol2は必要ないかもね♪手に入るネイティブ本の中ではお勧めピヨ♪

ネタつつき17－年上や先輩を敬う意味。

ネタ元：敬語と使い分けるということ
私もこの事が気になっていましたので書きます。ネタ元を遡って読んでいて思った事ですが、確かに過度な上下関係は社会を硬直化させるので良くないと思います。しかし、敬語が必要なのも確かです。この記事ではそれをさらに進めて、年上の人や先輩に対する敬意のついて私が思う所を書きます。
昨今は確かに敬意というものがありません。これは年寄りの愚痴ではありません（私はまだ若いですよ）これにはちゃんとした合理的な理由があります。それを説明するために、私のポリシーから書き始めます。私は基本的に他者を敬います。それは慣習やご機嫌取りの為ではありません。そういった広い意味での目上の人は、私よりも優れた点が多々あると思うから自然と敬意を持っているのです。それは表面的なものではなく、いわゆる生意気な若者には理解しがたいものだと思いますのでちゃんと説明します。
情報産業では進化が激しく、日々新しい技術が生まれては消えております。ですから、目上の人よりも新人の方がある一面では詳しい事もありえます。ですから実力社会の名の元に、生意気な新人が大量発生するのでしょう。しかし、そういった表面上のもので目上の人を敬わないのは、非常に失礼かつ勿体無い事です。何故ならば、そんな小手先の技術では決して目上の人には適わない面があるからです。それは経験です。何百何千冊本を読もうが、そこには書いていない物が経験なのです。情報産業でもそれは同じなのです。こんな事を書くと精神論だと受け取られるでしょうが決してそうではありません。経験は決して本には書けないものなのです。ソフトウェア開発には秘密保持契約（守秘義務みたいなもの）がつき物であり、それに違反するからそれらの実務的ノウハウは直接的に書けないのです。それに、文章に出来ない細かな事象がありますし、それをもし書いたとしても、読み手の経験が浅ければ理解できないでしょう。お客様がああいえばこういう、みたいに逐次書けませんし、そんな本を読んでも経験がなければ応用できません。
では、その経験の正体は何かといいますと、大半は失敗やトラブルの対処法です。専門書は正しい事を伝えるのは得意ですが、間違った事を書くのは得意ではありません。それが書物の弱点です。ソフトウェア開発といっても、我々は書物の世界に住んでいるのではなく、合理的には説明のつかない人間関係がどうしても付きまといます。そういった、現実に起こる事に対する能力は目上の人の方が長けているのは間違いありません（例外もありますが）そういった貴重な知識や技術を教えてもらうには、ちゃんと敬意を持たなければなりません。これは自分の身に置き換えれば分かると思います。貴方は、自分を侮辱したり見下したりする人に何かを教えたいと思いますか？それを想像すれば結論は自明だと思います。
そろそろ纏めます。目上の人に対して敬意を持つのは合理的な理由があるからです。従って、敬意を払わないと損をします。念のために書いておきますが、とはいえ自分より目下の人を見下すのは馬鹿げております。人間は完璧ではなく、どの人も自分に無いものを持っています。それを得られる機会を逃すのは愚かです。ここ最近、実力社会の名の下にそんな当たり前の事が忘れ去れつつあると感じます。実力を正当に評価するのと、敬意を持たないのは別問題です。人間に対する敬意を失ったら社会は崩壊すると思うのは私だけでしょうか・・・

ネタつつき16－オブジェクト指向の難しさと、実装を知らない設計者が駄目な訳（その逆も真なり）。

今回はオブジェクト指向の難しさについて囀ります。オブジェクト指向は難しいとよくいわれますし実際問題難しいです。では、何が難しいのでしょうか？それは、私が思うに 分析・設計・実装の三つが異なる上に不可分だからでしょう。オブジェクト指向と一言で言っても、オブジェクト分析（OOA）、オブジェクト思考方法論（OMT）、オブジェクト指向プログラミングはそれぞれ抽象度が違う概念です。これを詳細に述べると、1000ページあっても足りないと思いますので、簡単にそれぞれを説明します。
先ずはオブジェクト指向分析（OOA）について簡単に述べます。これは問題領域を知るための分析法です。ソフトウェアを開発する際に一番最初にしなくてはならないのは、問題領域を知ることです。知らないものを開発できるはずが無いのです。そこで必要なのがオブジェクト指向分析なのです。この分析法を簡単に言うと、問題領域の事象をオブジェクトして捉えて考えます。何故このような事をするのかと言いますと、 現実は境目が無い状態だからです。例として人間を考えてみます。人間が持つ情報量は膨大です。よくあるオブジェクト指向の例では、移動する・思考する・食べるなどと表現されていますが、そんな単純なものではありません。医学的に考えると、その様な特徴で人間をあらわしきれ無い事からもそれが窺い知れます。そもそも、人間は人間の全てを知らないので例として問題があります。これが初心者がオブジェクト指向を理解できない一番の原因だと私は考えております。この 繋ぎ目の無い現実の膨大な情報を整理するのがオブジェクト指向分析です。少々乱暴な纏め方ですが、細かい事を言えばきりがありませんので、ひとまずこのように考えてください。
次はオブジェクト指向方法論（OMT）に代表される設計法を説明します。オブジェクト設計では、オブジェクト分析から得た情報から、 作成するソフトウェアに関連する情報を抜き出します。あくまでもソフトウェア開発に関係する事に着目する点に注意してください。先ほどの例で言いますと、人間が持つ情報を整理するために医学書を読み漁るのは懸命だと言えません。私たちはあくまでも開発者であり、医者ではないのです。そこで設計技法では事象をオブジェクトとして捉えて、さらに問題領域の情報を整理整頓します。この設計技法と現実との違いは、 現実には存在しない事象がオブジェクトになる事が多いと言う点です。色々な特徴がありますが、この特徴はオブジェクト指向設計で重要なものだと私は思います。
最後にオブジェクト指向プログラミングについて軽く説明します。オブジェクト指向プログラミングでは、今までの段階で得た情報を オブジェクトとして実装します。この段階がこれまた厄介です。それは何故かと言いますと、使用言語に影響されるからです。誤解している人が多々居ますが、言語の設計思想に影響されているので、各言語のオブジェクト指向の概念は違うのです。おかしなことだと思われるでしょうが、我々はあくまでも情報機器を使用している事を思い返してください。思想を具体化する必要があるので、どうしても言語設計者の思想の影響を受けます。人は十人十色なのです。ですからこの記事では詳細に論じません。
以上の様にオブジェクト指向は三つの段階を経て無駄な情報をそぎ落としてく為の思考法／技法です。ここまで読んだ人の中には、「じゃあ三つのオブジェクト指向は全くの別物なの？」と疑問に思った人も居るでしょうが、これまた厄介な事にそれは違います。オブジェクト指向は三位一体なのです。どれがかけても上手くいきませんし、それぞれは独立した存在ではなく各々相互関連しております。この業界ではよく、実装を知らない設計者（SE）は駄目だと言われております。その答えがこれなのです。よく考えれば分かってもらえると思いますが、オブジェクト指向とは現実から情報を整理整頓するためのものであり、各段階はぶつ切りに出来ないので各段階の知識が要るのです。それを考慮すれば、全く見当違いの分析や設計をすれば実装が出来ないのは当たり前です。しかし、だからと言って、始めから実装だけを考えて分析・設計をしても上手くいきません。何故ならば、問題領域の正確な把握が出来なくなるからです。ですから私はよくプログラマやSEという区切り自体がソフトウェアの品質を悪くすると主張しています。私は様々なデスマーチを経験してきましたが多くはこれが原因です。役割分担もいいのですが、この単純な事実を考慮して欲しいものです。そうしないと、日本のソフトウェア産業は壊滅するでしょう。

書籍をつつく71－超文字コード研究。文字コードを知るには一番の本♪

今回は趣向を変えて隠れた名著を紹介するピヨ♪
文字コード超研究
この本巷ではあまり知られていないようだけど、隠れた名著とボクは思うピヨ。目次は・・・・


【目次】

原理編
・バイナリーとテキスト
・文字コードの入出力
・テキストファイルのいろいろ
・バイナリーファイルのいろいろ
・コンピューターと文字
・2進数、16進数の計算
・規格と機関
さまざまな文字コード
・文字コード系の歴史総まくり
・ASCII
・JIS X 0201のいろいろ
・ISO2022
・ISO8859-1
・JIS X 0208
・JIS X 0212
・JIS X 0213
・ISO-2022-JP
・EUC-JP
・Shift_JIS
・Windowsの独自拡張とコードページ
・Unicode
・文字セットにない文字を表現する方法
・大文字セット、大文字コード
インターネット編
・インターネットと文字コード 

この本はボクが文字コードを啄ばみたくなった時に買った本なんだ。みんなは文字コードについて楽習しているかな？どちらかと言うと、Windows系開発者には余り重要視されていないようだけど、プログラミングに於いて、文字コードは非常に重要ピヨッォ！文字コードは知らないと解決できないバグを生むピヨ。それに、日常的に文字コードの知識は役に立つピヨ。みんなは、文字化けしたサイトとかメール見たこと無い？その際に文字コードを知っていれば対処できるピヨ。あと、国際社会に向けて重要になってくると思うピヨ。
文字コードについて興味が湧いたかな？興味が湧いたら先ず読むのはこの本だと思うピヨ。この本は、文字コードを実務的に解説してある良本ピヨ♪文字コードの本は、えてして冗長で退屈な事をいっぱい書いてある本がおおいけど、この本はそんな事無いピヨ。ただ、一つ注意しなくてはならないのはPerlを使って解説している点ピヨ。実はボク、最初読んだときそこで困ったピヨォ。Perlはしばらく使っていなかったからね。ボクが持っているのはプログラミングPerlの初版だったといえば、そのヘタレぐあいが伝わると思う。だけど、比較的易しい文法を使って書かれているから助かったピヨ♪Perlを知らなくても、今ではインターネットで文法を調べながらこの本を読む事が可能だと思うピヨ♪是非読んでみてね♪