2011年2月25日
ステレオタイプ
以前からよく聞く言葉だったが、今回あるきっかけで気になったので、Wikipediaで、どういう意味が調べてみた。
古典的な類型性
漫画の悪役像ステレオタイプは、物語やフィクションなどで造形される人物像にその典型的な形が見られる。勧善懲悪の物語では、善役はいかにも善役らしい姿や言動があり、他方、悪役は同様にいかにも悪役らしい姿や言動で表現される。
大衆向けの娯楽目的の小説や映画、ドラマなどでは、人物造形がステレオタイプなだけではなく、物語の構成やプロット、展開・結末などもステレオタイプになっているのが一般である。漫画やアニメなどでは、「Boy
meets girl, and fall in
love」という言葉があるが、これは最近の物語におけるステレオタイプではなく、古代の青春恋愛物語である『ダフニスとクロエー』においても同じような構成になっている。
これらはステレオタイプというより寧ろ、神話類型（Cat:神話類型）にも通じる、物語の基本的な類型構造で、人間心理の普遍的・先天的なありようとも関係すると考えられる。しかし近代において、大衆社会、マスコミュニケーションが成立すると、政治的、経済的、あるいは社会的な目的において、過剰に単純化され類型化されたイメージが広く一般の人にも流布するようになり、文字通り、紋切り型な把握や観念や思考となって定着するようになった。
ステレオティピカルな観念の特徴
ステレオタイプは、現代では多くの人が持つ観念に、その代表的な例が存在する。これらの観念は偏見や差別意識と関係し、先入観やタブロイド思考とも関連している。「紋切り型」という言葉が示すように、個々人が抱く考え方・観念に個性が乏しく、同じような考え方やものの見方が、多数の人において類型化されて共有されている。
何故、そういうステレオタイプな思考やものの見方が妥当と確信するのか、ということについても、メディアがそう述べているとか、まわりの人がみなそう言っているとか、自分自身で主体的に反省して吟味することが殆どなく、外部の意見やものの見方をそのまま無批判に取り入れ、鵜呑みにしていることが一般である。その為、観念や確信に客観的根拠がなく、底が浅く、また複雑なものごとを単純化している結果、当人は十分に理解しているとの錯覚を持っているが、迷妄であって、固定観念になっている場合も多々ある。
2011年2月15日
http://el.jibun.atmarkit.co.jp/pressenter/2011/02/13-61a8.html
tweet を見ると、三浦マネージャのファンが多いみたいですね。「銀魂」のよろずや銀さんみたいに、ワルで絶対自分の非を認めないってタイプが人気があるからなあ。
「疎結合」とか「具象クラスの中まで調査したのか？」なんて筆者のコラムにコメントをネタにしているのがスゴいですね〜。
常道なシステム構築って、どこのクライアント企業にも使えるような汎用的なロジックとクライアント企業ごとに違うロジックを切り離すために、抽象化を用いて、クライアント企業ごとに仕様が違うロジック疎結合にし、具象クラスにコードを記述するのが普通だと思うんだけど・・・仕様変更が多いのは具象クラスのコードのほうだと思うの です。なんで具象クラスは変更なしで済んじゃうの？
どうも三浦マネージャが来る前から、このクライアント企業のシステムって普通と逆の設計思想だったのか？なんて変なことを思ってしまします。
まるで、最初からこのクライアント企業の業務ロジックはクラスライブラリ化されていたみたいな印象です。まあフィクションですからあまり深いことは考えないようにしましょう。
2011年1月27日
http://el.jibun.atmarkit.co.jp/hidemi/2011/01/post-39dc.html
人気女性コラムニスト、ひでみさんにウケた！
みながわけんじさん。
「staticだらけのコードを自動でリファクタリング」というのは、かなりおもしろいテーマですね。
ちょっとつくってみたいです。
ところで、「ポリリズムなコード」ってなんかかわいいですね。
踊りだしたくなるような感じです。
2011年1月17日
http://el.jibun.atmarkit.co.jp/pressenter/2011/01/9-bf58.html
高慢と偏見(9) 誰がスケジュールを遅らせた？それはあなたとプロマネは言った
ヤスさん 2011年1月20日のコメントより
＞三浦マネージャに教育された新人みたいな人も良いものを読めば何かが変わるかもしれない。
オブジェクト指向教育、特にポリモーフィズムに関しては、デザインパターン本や大学の先生の講義まで、ビジネスになってますよね。デザインパターンの話をすれば人から尊敬されると思っているプライドが高いかたもいます。誰も簡単にわかる本とかレクチャーなんてしませんよ。むしろ簡単に説明してしまったら皆さん困るでしょうね。良い本がなく、本当にわかる人なんていないと思ったほうがよろしい。
2011年1月14日
１分でわかるデザインパターン本の書き方
まず基底クラスとそれを継承する数個の派生クラスをつくります。読者が興味を持てる例だといいのですが、なかなか私も例が浮かばない。たとえば、
基底クラス：お買いもの
派生クラス：大阪のお買いもの
メソッド 「値段を聞く」 実行内容「なんぼでっか？」
派生クラス：東京のお買いもの
メソッド 「値段を聞く」 実行内容「いくらですか？」
このように多態性を持たせるように派生クラスでは同じメソッド名「値段を聞く」を定義しておく。さらに他のクラスを作り、その中のメンバー関数の引数やリターン値に派生クラスのインスタンスを使えば、それなりにデザパタっぽいサンプルプログラムになります。チャレンジャーの人は、もう一つ違う基底クラスを作り、それを継承する派生クラスを複数個つくり、そのクラスのメソッドで、上記の例のような派生クラスのインスタンスを生成したりしてみましょう。メソッドの代わりに、クラスのコンストラクタの引数に派生クラスのインスタンスを入れたりすることもできます。
引数やリターン値の型が基底クラスとなっている関数に派生クラスのインスタンスをぶち込む。そして派生クラスのメソッドを実行すればデザパタになるんです。自分なりにできたサンプルプログラムに名前をつけてみるのもいいと思います。たとえば「お買いものパターン」とか。
こんなことをして自分オリジナルのデザインパターン本を書いたら、著名なデザインパターン本を読んでみましょう。きっと自分のデザインパターンと似ているものを発見すると思いますよ（笑）
まあ、私の意見としては、ポリモーフィズムを使ったデザインパターンは、あくまでもサンプルコードであって、実践で役に立つかどうかわからん！としか言いようがないです。ただ、デザパタっぽいサンプルプログラムを作ることは暇人ならばできるということです。
2011年1月13日
チェックイン・チェックアウトではなくチェックアウト・チェックインだ！
かつてはプログラムのソースコード管理で行われていた排他制御技術、チェックイン・チェックアウトは、シェアポイントサーバーなどで一般の文書編纂作業にも用いられるようになった。技術者でさえも、どっちがチェックインで、どっちがチェックアウトだっけ？ まあ、ツールの使い方を体で覚えてるからいいや！なんて思ってる。しかしSEは文書管理システムを導入する場合、ユーザーに使い方を教えなければならない。そこでチェックインとチェックアウトを混同しちゃったら、ユーザーが不機嫌な顔をするだろう。
普通ホテルを利用する場合、ホテルに入るのがチェックイン、ホテルから出るのがチェックアウトとなっている。だから皆さん文書管理システムでも「チェックイン・チェックアウト」なんて説明しちゃう。だけど文書を修正追加するとき、チェックアウト、編集、チェックインですよね。だから私は「チェックアウト・チェックイン」といういいまわしをします。このほうがしっくりくるんです！
利用者からすれば、最初は文書を作成してチェックインします。しかし、その後はチェックイン状態が長くて、文書を変更したいときだけ、チェックアウトし、文書編集後にチェックインします。つまりチェックイン状態の方が長いのが通常ではないかと・・・ ホテルの場合は、チェックインしてから数泊後にチェックアウトです。だからホテルで毎日生活する大金持ち以外は、チェックアウト状態が長いんです。ホテルとファイル管理、文書管理を同じ利用形態と考えるは無理があるんです。
2011年1月12日
エンジニアのキャリアパターン
職業はと聞かれたら、「エンジニア」と答えればいい。昔は学生時代にコンピュータ実習というものがあったのだが、ハードとかソフトとか言われてもなんだかわからなかった。カードを鉛筆で塗りつぶしてフォートランプログラムを動かすなんて、そんなことできるわなかった。大学の研究室にPC98があったので、それでBASICのプログラムを書いて、電磁波のシュミレーションを始めたのが私の情報処理システムとの本格的な出会いだ。
今の人たちは恵まれている。家庭にPCがある。そのPCを使えば何も大学生になるまでもなく、子供でもプログラミングができてしまう。
はやかれ遅かれ、IT系のエンジニアの最初はプログラミングで始まるのではないか？それがまったくできない人はインフラ系エンジニアになっても失敗すると思う。だってインフラはアプリケーション・プログラムやOSを動かすためにあるのだから・・・
● 非IT分野のキャリアパターン
これからのエンジニアとして望まれるのは、ITエンジニアだけではなく、IT以外の分野でプログラ
ミングやサーバーの運用をやってしまうのがやりがいがあるのではないだろうか？例えば農業試験場とか水産試験場のような第一次産業の分野で、専門分野とITに詳しい人材。
● 業務アプリケーション分野のキャリアパターン
最初は人が書いた仕様書や要件定義書を理解して、プログラムを書くが、そのうち対象の業務分野の業務知識が身に付き、自分で要件定義からプログラム作成までやってしまう。大規模なシステムならばプロジェクトリーダーになる。金融、会計、生産、在庫管理などの企業活動として必要な知識が要求される。またプログラムの生産性を常に意識する努力も必要。
● インフラエンジニアのキャリアパターン
おもにサーバーのサイジング、導入、設定、バックアップ検証を行う。しかしサーバーの移行などでデータ移行プログラムの開発する必要もあるし、マニュアル、時には英語のドキュメントまで読む読解力も要求される。本来、システムエンジニアと呼ばれる人たち。
● プログラミング教育者のキャリアパターン
本当にプログラミングしか興味が持てない人。業務に対しての知識や資格もないし、サーバーソフトのインストールもしたことがない人の場合。いくつもの言語をマスターし将来的プログラミング教育者となる
● 勝ち組のキャリアパターン
最初は自分でプログラミングしていたが、会社が発展し、３０歳程度で多くの部下を持ち、部下の
指導とコスト管理をするだけでよい。
● エンジニアとはいえないキャリアパターン
すべて外注丸投げの会社に就職した人。
なぜ、ずっとプログラマーという道がないのか？
理由１ さすがに５０歳前後で老眼になり業務効率が落ちます（笑）。
理由２ プログラミングは疲れるから３０歳以上になると管理職になりたいとか、独立企業したいと夢見ている人が多い。
理由３ プログラミングはできるけど、ユーザー要件定義ができない人は効率が悪いです。いわゆるウォーターフォール型の開発しかできない人です。スパイラルやアジャイル開発を行うには、何よりも業務に対する理解がないと難しいのではないでしょうか？
2011年1月11日
新説オブジェクト思考
いろいろなブログでオブジェクト指向技術について解説しているが、なかなかわかりいやすい説明って難しいみたいですね。犬や猫のたとえが悪いといいながら、ピンとこない用語が羅列していて、やっぱりわかりにくい解説が多いです。私
はSEですからソフトウェアの専門家とは言えませんが、私なりに理解しているオブジェクト指向について解説してみましょう。
[直球勝負のオブジェクト指向]
もう何かの例えとか、哲学的な前置きなんてしません。
● クラスは単にプログラム全体のサブプログラムと考えればよい
● クラスはメンバー変数とメンバー関数（メソッド）により構成される。メンバー変数はクラス内に限定されたスコープでのグローバル変数である
● メンバー変数やメンバー関数をパブリック宣言することにより、他のクラスからメンバー変数に値の受け渡しができたり、メンバー関数を実行することができる
● インスタンスを生成することにより、インスタンスごとに違うメンバー変数値を保持することができる。インスタンスはつまり、クラスによって生成されるオブジェクトの識別子のようなポインタである。
これにより、同じクラスで違う状態値を持つオブジェクトを生成することができる。
これらのことから、クラス生成されるインスタンスはステートマシンを実現し、メンバー変数の値は状態値となります。プログラム全体としては、複数のステートマシンが通信（メッセージパッシング）するシステムとして構成されます。
オブジェクト思考とイベントドリブンは別の技術ですが、現代のGUIフレームワークでは、イベント制御を行うのに都合がよいシステムとなっているわけです。フレームワークの代表的なもには開発ツールです。フレームワークの定義はユーザーがクラスや関数の中にコードを書き込むものです。それに対しクラスライブラリは、クラスが多数用意されて、ユーザーがそのクラスを利用するものです。最近の.NET
FRAMEWORK という言葉からフレームワークはクラスライブラリではないかと思っている方も多いと思いますが、フレームワークとクラスライブラリは違います。
クラスをたくさん作ってクラスライブラリのようなものを作ると、自然に似たようなクラスは同じメンバー変数、同じメンバー関数を使うことが多くなってきます。そこでクラスの共通するメンバー変数やメンバー関数を基底クラスとして定義して、それを継承してクラスを作ったほうが冗長化されずに効率的なコードとなります。基底クラスを継承して作ったクラスは派生クラスと呼ばれます。
同じ基底クラスから派生して作ったクラスで、似たようなメンバー関数がある場合、同じメソッド名にしてユーザーに扱いやすくなります。これが多態性です。基底クラスを使って派生クラスのインスタンスを生成することができるのが多態性の特徴です。
オブジェクト指向言語では、関数の引数やリターン値またはコンストラクタの引数にオブジェクト（インスタンス）が使えます。関数のオブジェクト引き渡しに派生クラスをつかうとさらにバリエーションのあるプログラムが生まれます。この例がデザインパターンとも言えます。
これがオブジェクト指向の要点です。現在でも論争の焦点となっているのは次の点です。
● メッセージバッシングの多用はプログラムの動作が追いにくい原因となる。関数でできるものは関数で実現するのがよいのではないか？
● デザインパターン本では派生クラスを多用しているサンプルプログラムが多いが、実際の開発でこのようなケースが有効につかえるのか？
クラスを使うメリットはメンバー変数に状態を保持することであり、そのような必要のない、引数から単純にリターン値が演繹されるものは関数が適しています。それに対し、ファイルを一行ずつ読むようなプログラムでは、何行までファイルを読んだか状態を保持する必要がありますので、ファイルを読むようなことをする場合、ファイルオブジェクトクラス使うことが適切であります。例えば、ボタンをクリックするごとにファイルを一行ずつ読むような動作も可能なようにするには、ファイルの読み出しに適したクラスを作る必要があります。
しかし、状態保持としてメンバー変数を使わずに、データベースやセッション変数を使っている場合は、クラスではなく関数でプログラムを作成しても問題ありません。結果として業務ロジックではメッセージパッシングは使わないほうが、メンテナンス面で有利となります。
デザインパターン本ではオブジェクト指向のメッセージパッシングよりも、多態性が強調されています。
return(new 派生クラス()):
のような関数のリターン方法などデザパタでは「決めの一手」といった印象を受けます。現実の業務ロジックでは、綺麗なタイプ分類により、派生クラスのメソッドの挙動が変わるようなケースは少なく、「一般的な処理と例外的な処理」でコーディングされるのが通常です。
たとえば、5つの派生クラスと5つの関数を記述することなると、25個の関数を記述することになります。このようなプログラム構造はいくらデバッグしてもバグが残存する原因となります。
条件分岐がバグの温床になり、多態性を使ったほうがいいというのが一般論ですが、if文の == と書くべきところを = で書いてしまったり、switch
文の break
を抜かしてまったりするポケミスが多いことは多くの人が経験しています。。ユーザー要件としては、あくまでも条件として定義されてくるものなです。それから本当に複雑な条件文では多態性は役にに立ちません。
それでは、どのようなケースで多態性は有用なのでしょうか？それは違うI/Oインターフェイスを切り替えるような場合です。またデザパタでは基底クラスの仮想関数に派生クラスのメンバー関数をオーバーライドを行うような例がありますが、これはユーザーごとにプログラムをカスタマイズし、違う動作を実現するのには有用な技術となます。パッケージソフトのアドインなどには応用できます。
これからもオブジェクト指向を学ぶ人は、サンプルコードを見た時に、漫然と見るのではなく、どの一行が「決めの一手」なのかを考えてくださいね。
2010年12月28日
http://el.jibun.atmarkit.co.jp/pressenter/2010/12/7-28-5748.html
平良君、ちゃんと説明しなくちゃだめだよ。
「xxxConfigFactory.createメンバーで、違うタイプの派生クラスのインスタンス生成して、それをcofngAccessor に代入する。そうするとcofigAccessor.getResult() メンバー関数はタイプによって違う派生クラスのgetResult()メソッドを実行してresultList オブジェクトを返すようになる・・・・」
とか。 今のところ、このコラムコメントがないけどどうなることやら。
おれもついにヤクザになったのか？
Japanese Gang of One
とでも呼んでくれ！
【追記】
http://el.jibun.atmarkit.co.jp/yamayattyann/2010/12/post-15d1.html
これすげ〜な。ありとあらゆる技術の羅列。こんなにガンガン書かれたら本当かどうか信じません。こんないろんなことをやっていたらコラムなんて書く時間もったいないもん。最後はCSSとかjQueryとか誰でも知っている技術で落ち着いてるんだね。
「ASP.NETの技術者て、“アホ”なんだ」
OS開発している技術者に比べれば高度な物理学や数学を必要としないアプリケーションのエンジニアなんて、アホなのはわかってますが、なんでこの発言を＠ITは許してしまうのでしょうか？MSさんから広告収入もらっているんじゃないの？大丈夫？ 誹謗中傷をコラムに書いてはいけない規則のはずですがね。変です！
2010年12月17日
今年のシステム業界を振り返ってみて、自画自賛なのか、最低の自虐なの か? 「実はオブジェクト指向ってしっくりこないんです！」 この発言のインパクトは結果的に何の製品リリースの話題よりも大きいものになってしまった！！iPadの話題なんて結局一時的なもの！
もともと誰も読んでくれないコラムだろうと思って適当につけたタイトル、それが日本のシステム界最大の「迷言」となった。オブジェクト指向は新しい技術ではない。オブジェクト指向プログラミングに挑んできた人たちは、もう私と同じくらいオヤジの世代になっている。
オブジェクト指向の最大の利点は部品の再利用。最近の開発ツールでは、たくさんのコンポーネント部品を享受できるために、あえて部品を自作するような必然性はそれほど生じなくなった。部品の再利用というオブジェクト指向本来の性格からして、数十年で開発パターンは変わっていく宿命だったのだ。
「ゆく川の流れは絶えずして、しかも元の水にあらず」 大昔の方丈記の時代でも、そうであったのだから、現代の20年の歳月というものは大きく環境が変わるものだ。何かしっくりこないものを感じたら、いつかしっくりくるように変わると期待する。あるいは、しっくりくる手法を自ら提言する。それでも、また将来、新たなしっくりしないものが出現するかもしれないのだが・・・
逆に私はしっくりきたぞ！と思うのが64ビットデータベース。十分メモリを積めばガンガン早くなる。メモリを積んでスペックを上げるなんて下品かもしれないが、64ビットを使いこなすのは結局これが正解なのだ。
2010年8月18日
どこかのブログの影響でなぜかまた「実はオブジェクト指向ってしっくりこないんです！」のコラムのアクセス数が増えているそうだ。「死んじゃえ！」とかまた強烈なご批判の意見もありますが、とにかく私の開発したプログラムはスレッドセーフで問題なく安定稼動している。また社内、取引先のSIerとの関係で何も問題が出ているわけではない。実際に私の設計したシステムを使っているユーザーや私と面識のあるSIerでは誰も私を異常な人間とも思っていない、むしろユーザーやSIerに対して友好的な関係に変わりがない。面識のない人のネットの意見など、もう気にしなくなった。っていうかネットの世界で顔見せしなければ誰でも何でも言えるもんだ（笑）。
クラスを使ったオブジェクト指向プログラムでは、メンバー変数をpublic化したり、publicなメソッド関数を使うことにより、他のクラスからメンバー変数を更新したり呼び出したりすることが自由自在にできる。メンバー変数はクラス内に限定されたグローバル変数のようなものなので、クラスの設計方針を明確にしないと自由自在に設計は他のプログラマーが仕事を引き継いだりするときに、どんでもなくやっかいなことになる。処理手順が追えなくなるのだ。
実際にオブジェクト指向プログラミングが得意な人のコードを見ていると、複数のメンバー変数を呼び出し元のクラスに引き渡すために使われていることが多い。呼び出し元のクラスから呼び出すクラスのメンバー変数に値を入力したり、メソッドでメンバー変数を変更したり、いろいろなことをやってしまうとメンテナンスが大変なことになる。
クラスを作るときはメンバー変数の値の引渡しなどの方針を良く考え、コメントや仕様書をわかりやすく書くなどの注意が必要だ。私が関数やstatic関数を好む理由は引数やリターン値により何が入力で何が出力か明確であるからなのだ。若い人のプログラムを見て思うことだが、データの入出力が煩雑でわかりにくいクラスほどやっかいなものはない。
関数の不便なところはリターン値がひとつしかないことであるが、Visual Studio では DataTable で複数のリターン値を返す方法などがある。複数の値を返したい場合においてはクラスを使うのも有効な手段かと思う(2010年6月16日のリンクの例)。わざわざそのために構造体を使う理由はない。
オブジェクト指向プログラムは、クラスというプログラムの集合体であり、そのクラス同士がデータのやり取りが自由自在にできる。ただ、ポリシーがなくクラス間でのデータのやり取りをしてしまうのは、のちのち失敗をまねく。自分がプログラムを書くだけでなく、数年後に他の人がそのプログラムをメンテナンスすることを考えて欲しい。
システムを開発するだけでなく、会社の業務がいつまでも存続するようにするのが社内SEの責務。匿名のインターネットの世界で無責任な発言をすることは、結局はユーザー企業、社内SEの不審を煽るだけ。オブジェクト指向についてポリモーフィズムやインターフェイスなどの知識をいくら持っていても、動くものを作ることは別。自分では綺麗なプログラムだと思っていても、それは自己満足で、他人がみたらスパゲティプログラムなんて十分にありえる話です。何が綺麗なプログラムなんて客観的指標がないんだもん。
私は社内SEとして一次請けの業者さんの社員としか会ったことはない。だから多重請けの問題とか派遣エンジニア云々の問題とは全く関係がない。どこかのブログの 非常にレベルの低いことを押し付けれてた変な体験と私のコラムを一緒の次元にすることははなはだ迷惑ですね。
2010年6月16日
http://asuka-diary.at.webry.info/201006/article_4.html
クラスのサンプルコードが載っているブログを発見した。この人の作るクラスの特徴は
■コンストラクタで処理を実行している
■メンバー変数に結果を格納する
■インスタンス生成すると、メンバー変数を参照することで結果が得られる
構造体を使うことなく、メンバー変数を参照することで、複数の実行結果を返す機能を実現していることだ。まあ、クラスを構造体的に使っているていう感じかな。プログラミング記法としては美しいと思う。
2010年6月18日
オブジェクト指向に関する考察
オブジェクト指向という技法は、もう四半期以上前からあるものです。私はプログラム作成を専門にしているものではなく、システム全般の最適化を考えるシステムエンジニアという立場ゆえ、それほどオブジェクト指向というものに深入りしたことはない。いまさらどこかのコラムで炎上したことは以外なことであった。いろいろな人の意見はWEBで情報収集したことから私なりにオブジェクト指向というものについて考えてみた。
■クラスはメンバー変数を状態変数とするステートマシンであり、オブジェクト指向はシステムをステートマシンの集合で構築するという思想である。
■インスタンス生成とはメンバー変数に必要なメモリー領域を確保するための行為である。
■多種のクラスを作っていくと、多くのクラスで共通なメンバー変数、メンバー関数が存在する。そのようなコーディングの冗長をなくすために、基底クラスをつくり、それを継承するという手法が導入するのは自然のなりゆきであろう。
■基底クラスを同じくする複数のクラスで似たような動作をするメンバー関数を同じ関数名に定義して扱いやすくしたのがポリモーフィズムである。
オブジェクト指向がステートマシンのコンセプトをもとにしたプログラミング手法だとすれば、業務アプリケーションでは、状態変数など使わずデータベースに状態フィールドを設けることにより制御できる。これが業務アプリケーションではオブジェクト指向を意識する必要がない最大の理由である。継承やポリモーフィズムはオブジェクト指向の目的ではなく結果の産物である。本来のオブジェクト指向の目的はあくまでもステートマシンにあった記述である。
「それでは、私はオブジェクト指向していないのか？」
実はVisual Studio .NETのフォームやWEBページはクラスでできていて、そのなかに開発者はコードを書くフレームワークになっている。
■ボタン１をクリックとテキストボックスに「Hello!」が表示される
■ボタン２をクリックするとテキストボックスに「Good bye!」が表示される
ということをクラス内のボタン１とボタン２のイベント関数に書くことにより、テキストボックスに何が表示されるかという状態の変化が起こる。つまりテキストボックスの表示内容をメンバー変数としたステートマシンを実現したことになり、それで立派なオブジェクト指向的なプログラムを実現したことになる。Visual Basicとまったく変わらないじゃないかという反論はあるかもしれないが、Visual Studio .NETのフレームワークは開発者がオブジェクト指向を意識しないで、オブジェクト指向プログラムを作成してしまうのだ。 イベントドリブンのプログラムをステートマシンを意識し、オブジェクト指向技術を適用することは有効である。GUIアプリケーションの時代になってから、ほとんどの開発環境はオブジェクト指向言語を採用したフレームワークになっている理由はそこにある。
「状態変数」って何？「プログラムの変数ははすべて状態変数と言ってもいいんじゃない？」と質問する人がいる。このように、ステートマシンのコンセプトを十分に理解していない人がクラスを書くことは非常に危険なことである。自己満足なプログラミングをするだけで他人が見たら頭を悩ますコーディングになってしまうのだ。
関数の引数、リターン値、ローカル変数は状態変数ではない。グローバル変数は実は状態変数である。オブジェクト指向はグローバル変数だけでなく、メンバー変数を必要な部分、必要な部分に公開する仕組みである。
すべてローカル変数で構成される関数は、引数、内部変数、リターン値に一過的な値しか保持しない。つまりこれらの変数のメモリ領域は一時的な値の受け皿になっているだけということだ。一過的にしか意味を持たないものをメンバー変数する必要はなく、関数の引数かリターン値にすればよいことなのである。つまり一過的にしか意味を持たないものをメンバー変数にすることは基本原則である構造化プログラミングに反した行為である。これは非オブジェクト指向言語で本来関数の引数やリターン値で値を受け渡すべきなのにグローバル変数で値を受け渡しているようなプログラミングと同じです。
オブジェクト指向を始める前に基本的なステートマシンのコンセプトを理解すべきだ。 私は業務アプリケーション開発しかしていないので、実験レベルでしか継承などのテクニックを使った経験がないです。実践での適用はないので、オブジェクト指向について語る権利はないのかもしれません。でも、ほとんどの開発ツールがオブジェクト指向に対応しているのに「なぜ業務アプリケーションはオブジェクト指向とは縁がないのか？」について意見を言わせてもらいました。
2010年1月26日
インフラジスティックス コンポーネントの本番機実行
インフラジスティックのコンポーネントを使ってVisual Studioの開発環境で動作しても、本番機で動作させるためにはそれなりの準備が必要だ。ヘルプのアプリケーションの配備を見てもわかりずらい。とりあえず共通アセットの配備というものをしてみた
C:\inetpub\wwwroot\aspnet_client\infragistics\20071\Scripts
C:\inetpub\wwwroot\aspnet_client\infragistics\images
のフォルダを作成して開発環境PCのC:\Program Files\Infragistics\NetAdvantage for .NET(JP)2007 Volume1CLR2.0\ASP.NETの下のScriptsとimagesの配下のファイルをすべてコピーし、C:\inetpub\wwwroot\aspnet_client\infragisticsをig_commonという名前の仮想ディレクトリに設定した。さらに配備の概要をみて必要なdllファイルをbinフォルダの下にコピーした。これで動作した。
2009年12月24日
SDDC(Single Device Data Correction)
メモリーのデータ異常をチェックする方法としてはECCがよく知られてます。これはメモリーを冗長化させることによりデータ異常を検出する方法です。ところがECCを使っていてもメモリー自体が異常を起こした場合はお手上げです。チェックビットをそれそれのメモリーに分散させ、一個のメモリーが不良動作してしまってもデータが修復されるのがSDDCです。サーバー購入のときには仕様上SDDCかどうかSDDCが機能するかどうか確認しといたほうがよいでしょう。最近はコストダウン競争でメーカーはなるべく安いメモリーを使う傾向にあるので注意です。
2009年12月17日
Visual Studio 2003 から Visual Studio 2005 へのコード変換 のつづき
InfragisticsのHOTFIXを適用すると、Assemblyのバージョンがかわるので、Register Assemblyを書き換えた。最初のHOTFIXを当てるのが正解だったようだ。ビルドは成功したが、結局Infragistiｃｓコンポーネントは.NET1.1 と .NET2.0では使用するタブが違うので正常に動作しないことがわかった。やはり手作業が必要ということでこれ以上は断念した。
2009年12月16日
Visual Studio 2003 から Visual Studio 2005 へのコード変換
Visual Studio 2005 で Visual Studio 2003 のソースをWEBサイトのフォルダを指定して開く。Visual Stidio 2003のcsprojファイルを開いてVisual Studio 2005 を起動させると変換後はaspxファイルが正常に画面表示されなくなるから注意だ。Infragisticsのコンポーネントを使っているソースなので、.NET Framework2.0用のInfragisticsをPCにインストールした。.NET2.0用のInfragisticsはVSのツールバーにコンポーネントを追加するプログラムがあるのでそれを起動すればよいので設定は簡単だ。しかしInfragisticsのコンポーネントは正常に表示されなかった。新規にページを追加しその後Infrasisticsのコンポーネントを追加すると Register Assembly にバージョンが指定されているのがわかる。そこでRegister Assembly を書き換えてみた。それでもInfragisticsの動作が変なのでHotfixを適用してみた。VSを起動しなおしたが起動に時間がかかるなあ。binの下はすべて消してから変換するのが正攻法なのだろう。
2009年11月27日
WindowsXP、Windows2003は将来なくなるのか？
企業では多数のアプリケーションをWindows7で正常に動作するのか検証するだけでも労力的に困難である。Windows7の通常のインストール、それがだめだったらXP互換モード、さらにXPモードで検証するなんてことはやっかいきわまりない。マイクロソフトはプロダクトライフライフサイクルという独自の理屈で古くなったOSはサポートしないし、古いOSに対応するハードをメーカーに売らせない基本方針であるが、基本的にハードならば老朽化するという点で古いものはサポートしないという理屈は納得できるが、OSはソフトウェアでありデジタルデータであるので、古くなったらサポートせず、新しいOSに対応するように客に労力や費用、リスクを転化するというのは全企業を相手にした訴訟問題に発展する可能性がある。また世界的なCO2削減、エコの観点からしてもWindows7やWindows2008に乗り換えることは何のメリットもなく、古いPCを 捨てるという地球環境破壊活動に他ならない。Windows95が出始めて15年の歳月が流れたがマイクロソフトのOS戦略も発展性がなくなったものだ。しかし自分にとっては、この15年間IT技術の急速な発展の中で仕事ができたのは苦しくもあり楽しくもあり、いろんな経験ができたことで非常に幸運であったのかもしれない。今後は企業で利用されるIT技術はドキュメントやデータの継続的保護、仮想化技術を駆使したシステムの継続的運用を重視した安定成長に方向性を変えるだろう。
2009年11月20日
仮想サーバーの今後
マイクロソフトのHyper-Vは主流になりえるだろうか？仮想サーバーとなると何十台もの仮想マシンのプラットフォームとなるだけに安定稼働で実績のあるVMwareにはなかなか勝てないのではないだろうか？Windowsサーバーではハングアップによる再起動、サービス再起動をせざるを得ない場面が多し、多数のウィルス攻撃から守るために毎月セキュリティパッチの適用をし、ウィルス対策ソフトをインストールする。始末の悪いことにSymantecのウィルス対策ソフトはインストールすると不具合を起こす原因になることもある。VMwareはハングアップもなく非常に安定性の高いプラットフォームである（私の経験では）。VMwareを使っていると可能な限り基幹システムであろうとなかろうと仮想化してしまいたくなるのだ。Windowsはいつまでたってもセキュリティパッチ（実際はバグフィックスではないのか）を毎月適用せねばならない。なんで原因不明の障害がでるのか？またサードパーティの製品についてもバグと思われる不良動作が頻繁に起こる。
最近は仮想化戦争にLINUXのRedHatも名乗りを上げている。マイクロソフトはVMwareとLINUXという非Windows陣営に今後対決していくことになる。インターネットの世界ではセキュリティの観点からすでに非Windows陣営(LUMP)に軍配が上がっている。マイクロソフトがインターネットにかかわっているのは単なるブラウザだけである。企業内においては、認証、アクセス制御でマイクロソフトのドメインコントローラを基盤にし、ファイルサーバー、SQLサーバー、WEBサーバー等を構築する非常に強固なシステム、他のOSの参入がしにくい砦のようになっています。この砦にLINUX陣営がどう攻撃をしかけるのか、またマイクロソフトがその砦を守るのかが今後興味のあるところでしょう。
2009年11月19日
C# デリゲート メソッドを変数のように扱える？機能についてどう説明したらいいのか迷ってしまいます。JAVA Scriptでは関数の引数に関数名を使えるという納得のある記述方法がありますが・・・
delegate void xxx(引数); //デリゲート宣言
デリゲートはまず、この宣言をする。さらに、このデリゲート関数xxxと同じ引数の個数と型をもったメソッド
class classA { // 実際に実行する処理のメソッドをこのクラス内に記述する
public void yyy(引数) ｛処理Y｝;
public void zzz(引数) ｛処理Z｝;
}
を記述する。このようにすると、以下の記述でyyyやｚｚｚの処理が実行される。
classA A = new ClassA(); // 実行したいメソッドのクラスのインスタンスを生成する
xxx インスタンス名 = new xxx(A.メソッド名) //xxxがデリゲート、メソッド名はyyyまたはｚｚｚ
インスタンス名(引数); //ここでｙｙｙまたはｚｚｚが実行される
本来xxx は最初のdelegate宣言で引数があるように記述されているが、xxx でインスタンスを生成するときは、引数にｙｙｙやｚｚｚのようなメソッド名するのが記述上、非常に変わっている。以下の記述では、 + でメソッドｙｙｙとメソッドｚｚｚ の処理を結合することができる。
xxx インスタンス名y = new xxx(A.yyy); //xxxがデリゲート、ｙｙｙがメソッド
xxx インスタンス名z = new xxx(A.zzz); //xxxがデリゲート、ｚｚｚがメソッド
xxx インスタンス名w = インスタンス名y + インスタンス名z ; //yyyとｚｚｚの処理を結合する
インスタンス名w; //yyyとｚｚｚが実行される。
2009年11月18日
C#言語はそろそろ主流になってもいいんじゃない？
.NET TIPSをインターネットで検索するとまだ日本ではVB.NETを使っている人が多いように思えるが、VB.NET も C#.NET もクラスライブラリが同じなので、Visual Basicを長年使ったおじんならばVB.NETを使う理由があるが、JAVA世代の若手がVB.NETを使う理由は乏しい。私はVBスクリプトやEXCELのVBAも書けるが、わざわざ開発環境を使う必要もない仕事にのみ使って、Visual StudioではC#を使っている。もともと若い時代にC言語でプログラムを書いていたため抵抗がないのかもしれない。その後 Visual Basic2.0の時代に簡単にGUIのプログラムが書けるのでVBにはまった。VB.NETというのはVB開発者を.NETに引き込むつなぎのようなもので、プログラミング入門としてJAVAやCを習ったエンジニアが多い現在、C#が急激に主流となるだろう。C#はVisual Studio 2003 で採用された言語だが、もう来年は2010年！七年前プログラミングを始めた若手エンジニアが主力となりつつ時期に来ている。
2009年11月17日
ERP SAP R/3 ABAP その後
最近、ITバブル当時に比べ、ERP、SAPの話題を聞かなくなったような気がする。インターネットで調べてもABAPに関するHPは廃れている。最近のプログラミング言語はCやJAVA言語系のものがほとんどなので、SAPの独自言語というものはかなり浮いた存在になって当然かもしれない。R/3は企業の各部門のデータベースを一元管理するもので、それを実現するには2000年以降のサーバースペックでないと無理であった。その意味でSAPは先駆的であったかもしれない。しかし最近のマルチコアのサーバースペックや大幅なディスク容量の拡大により、データベースの一元管理は容易になってきている。ADDONによってシステムを導入企業向けに拡張するというコンセプトはSAPのユニークですぐれたところであり、とくにバッチインプットプログラムにより、データの入力更新作業を自動化するというアイデアはユニークである。しかし、このバッチインプットはユニークな手法であるために逆にADDONプログラムの開発の足を引っ張ることになる。そのためにSAPではBAPIという関数を用意しているのだが、その使いかたは難解である。ERPのような大規模な業務アプリケーションを構築するには、プログラム実装面でのルールが必要である。
[データの照会]：これはSELECT文で各種のテーブルを抽出し画面に表示する単純なもので問題ない。多少のロジックは必要だが。
[データの追加]：データを追加する関数を用意する。どのような画面にするかは企業によって違いがあるので、画面を作り、画面項目から関数の入力項目にデータを渡せばよい。関数のデータ項目は意味がわかりやすいようにコメントやドキュメントが必要だある。また必須項目であるかどうかも明確にわかるようにしなければならない。
[データの更新]：データを抽出する関数でデータ取得し画面項目にデータ渡しする。データを更新する関数で画面項目から関数にデータ渡しする。これらの関数についてもコメントやドキュメントが必要である。
[データの削除]：これも関数化したほうが望ましい。
SQL文で直接テーブルを更新することはSAPでは禁止されていた事項であった。これは、複数のテーブルの更新を必要としたり、必須項目が抜けている場合にデータの矛盾が生じるためである。そのためには、データの更新処理は関数化しデータの矛盾が生じないようにすべきである。
2009年11月16日
オブジェクト指向について
C++言語が世に出てから数十年経つ。オブジェクト指向言語についての入門書は私も何冊か読んだことがあり、皆さんも学習したことがあるだろう。それにしてもなかなかオブジェクト指向は身につかないものである。GUIのコンポーネントやクラスライブラリを開発しない限り本格的にクラスの機能を使うことはないと思われる。実は私もその手の開発経験がないのでオブジェクト指向については、単なる頭の体操みたいでプログラミングの世界をややっこしくしているように思える。実際のところ私はクラスを作るといっても共通な関数をメンバー関数にしているだけである。インスタンス宣言する必要もないのでstatic関数である。WEBアプリなどはページごとにロジックを組みこんでしまったほうがプログラムがわかりやすく独立性が高い。あえて共通して利用しないようなロジックはクラス化しても意味がない。結局 public 宣言して公開しているメンバー関数やメンバー変数はクラス内で隠蔽化しているとは言えない。したがってやたらにクラスを多様することはナンセンスである。オブジェクト指向言語はあれもできる、これもできるということを売りにしているが、それらの機能をむやみやたらに使うことはプログラム構造をわかりにくくするだけである。
業務アプリケーションではクラスは使えればいい。へたにクラスを作るな。
2009年11月15日
プログラマー、SE 35歳定年説？
実は私は45歳を超えている。来年は歳男である。エンジニアというものは職人であるから、床屋、美容師、大工、芸術家、または医者、税理士、会計士のように、いつリタイアするかは自分が決めるものである。エンジニアとして仕事を長続きさせるには、体力切れや突然死、やっかいな病気にかかならいことが第一の条件である。したがって、
・過度な労働を長期間しいられる会社は辞めましょう
我慢することにより、思考能力が低下し、病気やストレスをため込む原因になります。今の不景気な状況では転職先を探すのが大変ですが、転職先を見つけることを薦めます。ストレスがなく適度な労働時間でスキルアップするための勉強の時間を持てるような会社に勤めることです。エンジニアを長年続けていくことにより、逆に若い人に負けない感や経験、文書の作成能力、文書の理解能力ができてきますから、新技術にたいしても理解や吸収は早くなります。歳をとると新技術についていけないのでベテランは駄目だという通説がありますが、その説については私は正反対です。プログラミングやその他のIT技術はインナーネットを検索すればたくさん記事があるので比較的簡単に知識が習得できます。昔は何千円もする分厚い本を何冊も買ったりしてましたが今は情報収集が本当に楽になりました。
[システムエンジニアのスキルアップへの道のり]
まず、プログラミングとデータベースの設計は得意にならなくてはなりせん。一番基本的で重要なことです
業務知識を身につける
ハードウェアの基本知識の習得、サーバーの設定ができるようになる
ネットワーク機器の知識を習得する
メーカーやベンダーの新製品の情報を収集を怠らない
さらにセキュリティ対策などの知識があればなおさらよし
実際にこれだけのスキルを身についけ安定稼働するシステムを構築できるようになるまで40歳前後になってしまうのではないでしょうか？IT技術は変化が激しいですが勉強すればなんとかなります。意外に業務知識を身につけるほうが大変です。クリエイティブで好奇心が旺盛な人はぜひともエンジニアを続けてほしいものです。残念ながらそうでない人はエンジニアの適正がないので他の仕事を選んでください。
2009年11月13日
Visual Studio 2003 のソースコードを自分の Visual Studio2003の環境にコピーしたところソースは読み込めたが実行ができず、以下のエラーメッセージがIEに表示された。
説明: この要求を処理するために必要な構成ファイルの処理中にエラーが発生しました。以下のエラーの詳細を確認し、構成ファイルに変更を加えてください。
パーサー エラー メッセージ: アプリケーション レベルを超えて allowDefinition='MachineToApplication'
として登録されているセクションを使うことはできません。このエラーは、仮想ディレクトリが IIS でアプリケーションとして構成されなかった場合に発生します。
Visual Studio 2003のソース移植の場合は、通常 プロジェクト名.csweb.infoファイルを見て、正しいフォルダ構成を組みソースをコピーすれば大丈夫なはずでした。インターネットで情報を調べ、IISでweb.cofig が存在するソースのフォルダのプロパティを開き、仮想ディレクトリタブでアプリケーション名の右の作成ボタンをクリックすれば実行できるようになりました。
2009年11月12日
今月もWindows2008 R2のセキュリティパッチがMSより大量にリリースされたのでやっかいである。建前上セキュリティパッチとMSは言っているが、実際はバグフィックスと思われる。Windows2003で満足してしまったので、2008、特にR2に関しては64ビットということでなかなかこの不景気な世の中には受け入れがたいものがある。
2009年9月29日
遅まきながらWindows2008のWindows Serverバックアップを始めて操作してみた。NTBACKUPと違い、ドライブごとにイメージバックアップをするものですね。スケジュール実行の場合は何故かリモートサーバーにバックアップできないようになっていますね。Wbadminというコマンドではこのようなこともできるようです。リカバリは試していませんが、これを使えはSymantecのSystem Recoveryも不要になりそうですね。