システムエンジニア日記

2016年1月18日

http://www.infoq.com/jp/news/2012/05/DRY-code-duplication-coupling

DRYってオブジェクト指向のパラダイムかと思ってましたが、一般的なコーディングについてのパラダイムなんですね。

重複をなくすため、私たちはそれらが依存する新しいオブジェクトを導入することになるか、よくあることですが、さらにひどくて悲惨なことに、あるオブジェクトをほかのオブジェクトに依存させます。後者のアプローチでは、関係のないオブジェクト間に依存関係を作ってしまうことが多く、やがて進化の妨げになります。

共通メソッドの呼び出し関係で、継承を使うのは推奨されてないみたいですね。結局は共通メソッドの実装なんて自然publicを使えば問題ないってことですかね。データを継承させてこそ継承本来のメリットが享受できるのかも。

常に1つの原則を適用するだけでは十分ではありません。あなたはこれらすべてを考慮して、状況に応じて相対的な価値を検討する必要があります。どの調味料が魚に合うのか、どの調味料がステーキに合うのかを知るようなものです。実際のところ、どちらもうまく合うこともあれば、そうでないときもあります。

この言葉から、場面に応じて適切な手法を使えばよろしいかと。日本人は著名な人の本に書いてあったとか気にし過ぎる。

2016年1月8日

ローカルなメソッドやpublicなメソッドのように関数でまとめたプログラムは可読性が向上し、バクの影響範囲も少なく、メンテナンスがしやすい。関数はリターン値が一つしかないので、オブジェクト指向プログラムならば、複数のデータをまとめた構造体的なクラスを定義して、複数の値をリターンさせる方法が望ましいだろう。そのような構造体的なクラスで生成されたインスタンスは、プログラムの随所でリターン値は引数に利用できる。　staticな関数でクラスのインスタンスをリターンさせてもよいだろう。

しかし実際によくみるサンプルプログラムでは、クラスAのデータとクラスBの関数を分けて提示することは少ないと思う。サンプルプログラムでは、クラスCにデータと関数を一緒に同居させ、これがオブジェクト指向プログラムということを強調しすぎる。実際には、クラスAにデータを定義したことで十分オブジェクト指向だと思う。そのクラスAによって新たなデータタイプが定義されるのだから。

関数の処理自体は、ローカルであろうが、インスタンス関数であろうが、static関数であろうが、たいした問題ではなく、メンバー変数をどう使うかでオブジェクト指向のメリットをうまく享受できるのでは。メンバー変数をテンポラリー変数や、クラスの間の値の引き渡しに使っているのは、クラスをモジュールとして扱っているだけなので、オブジェクト指向とは本筋が違うような気がしてならない。

2015年12月28日

仮に100歩譲って、staticメソッドを使用するなという主張を認め、インスタンスメソッドに書き換えてみても、それって無駄な努力としか思えません。staticメソッドでいけるものならば、それを使うのがよろしいかと。staticメソッドの利用になると、マルチスレッドでは誤動作する可能性を指摘する人がいますが、Webアプリケーションでは、複数ページ間の値の受け渡しにSession変数などの技法を用いれば回避できます。今だにpublic static変数を用いて値を受け渡していたなどtwitterで目にするのが信じがたいです(このような大失敗をしていまうと、「staticはだめ、staticメソッドも禁止」ということになります)。

もちろんロジックを関数の形にまとめるのには、コツがありままして、引数や戻り値にインスタンスを用いています。一見すると、従来型プログラミングですが、目立たずにオブジェクト指向ならでは技法を使っています。派手にクラスをボンボン作ることのみがオブジェクト指向とは考えていません。

福井県はまだ行ったことがないんですよね。今朝のNHKニュースによると、福井県では1500円のコンピュータで子供がプログラミングの学習をしているそうです。VBのプログラムをVisual Studioに再構築する費用って、かなり高額になりそうですね。安い費用で確実にVBから脱却できればいいんですけど。費用を払うユーザー企業の部長さんは、そういったプログラムの書き換えだけでは稟議が通らないので困ってしまうだろなあ。

度重なるstaticについてのディスりについて、実際のソフトウェア開発会社や企業の情報システム部門は何も影響を受けておらず、ネット上で架空の人物像が一人歩きして、まさに現代の怪現象ですね。某ラノベの著者などは、どこかの会社の編集部の人かなと思ってしまったり、「・・・しっくりこないんです」のコメントではしきりに本を買えとか、(staticメソッドを認めると)学生が勉強しなくなる！などの意見がありました。オブジェクト指向本の売れ行きとstaticおじさんの人口は反比例する法則など、この業界では存在するのでしょうか？

逆に、staticメソッドの使いどころがわからないインスタンスおじさんというプログラマーの人たちもこの業界には生息しています。彼らはプログラム上に無意味なインスタンスを大量に生成していき、staticを使うプログラマーを激怒したり、staticを使ったサンプルプログラムを掲載したブロガーを執拗にディスったりします。天災オブジェクト指向プログラマーと呼ばれたい彼らのプログラムのメソッドはすべてインスタンスメソッドです。非オブジェクト指向と呼ばれるstaticメソッドなどひとつも使うわけもないのです。「このインスタンス無意味だよねえ。staticでいいんじゃない？」なんて言ったら大変！彼らは決して人の意見など聞く気は毛頭ないのです。なんてったって自信満々の天災オブジェクト指向プログラマーなんですから・・・

2015年11月11日

http://www.ie.u-ryukyu.ac.jp/~e085739/java.it.22.html

インタフェース　Strategy　と　その派生クラス　ConcreteStrageryA, ConcreteStategyB が出てきますが、それ以外のクラス　Context なるものが出てきます。ポリモーフィズムを例にしたサンプルコードでは、インタフェースを継承した派生クラスでメソッドの動作を切り替える動作をさせるのが定石なのですが、ここではそれ以外の継承関係がないContext というクラスが出てきます。

このサンプルの目的は、main を見ればわかります。クラス Context で生成したインスタンスに対してのみ操作を行えば、派生クラスのインスタンスの生成、メソッドの実行、インスタンスの切替えができることです。クラスContext のメソッドでインタフェースStrategy の生成、切替え、メソッドstragetyMethodを実装することにより、mainプログラムは直接Strateryの生成、メソッドの実行をしていないのです。間接的で遠回しな使い方で、mainプログラムはContexクラスで実装されているメソッドを使うというのが、このプログラム・パターンのポリシーなので、柔軟なプログラミングができるというわけでもないと思います。派生クラスのメソッドの検証が不十分な場合、直接、派生クラスのメソッドを実行させずに、利用を制限したい、などのケースで役に立つかもしれません。

デザインパターンの例では、
　　Context context = new Context(new ConcreteStrategyA());
のように、メソッドの引数に派生クラスのインスタンスやnewによるインスタンス生成を使ったりすることが多いですね。

http://www.itsenka.com/contents/development/designpattern/visitor.html

ここでは、2つの派生クラス群が定義されています。
①　基底クラス Visitor、派生クラス　ConcreteVisitorA, ConcreteVisitorB
②　基底クラス Acceprot 、派生クラス CocreteAcceptorA, CocreteAcceptorB
です。 CocreteAcceptorAとCocreteAcceptorBで
　　　　 public void accept(Visitor visitor) { visitor.visit(this);　}
のようなメソッドを実行することにより、直接継承関係のないVisitorのメソッドに処理を委ねています。this は、このメソッド実行するインスタンスが入ります。ConcreteVisitorA, ConcreteVisitorBではCocreteAcceptorA,またはCocreteAcceptorBのインスタンスを受け取り、getNameというメソッドを実行しています。このパターンの目的は、データ構造とそれに対する処理を分離すること目的、と記載されてますが、ピンとこないというのが実直な感想ではないでしょうか？CocreteAcceptorA, CocreteAcceptorBでは、visitor.visit(this)によって、インスタンス自身を他のクラス渡し、他のクラスで処理を実行させています。そして、処理は①の派生クラスのみで、②の派生クラスはメンバーやメンバーにアクセスするメソッドのみを実装すれば十分です。通常は、ポリモーフィズムを利用する例はメインプログラムであったり、単純なメソッドの場合がほとんどですが、この例では②のポリモーフィズムを利用するクラスのインスタンスが①の派生クラスのメソッドの引数に使われるというパターンです。

これについてもvisitor.visit(this）のような派生クラスのインスタンスの受け渡しを利用しています。普通は②の派生クラスに処理を書き、mainにインスタンス名に受入者、引数に訪問者としてメソッドを書くほうが一般的で単純でしょう。どうしても①と②のポリモーフィズムを絡め合わせたコード例を提示したかったのでしょうか？　　

http://www.ie.u-ryukyu.ac.jp/~e085739/java.it.1.html

クラス構造は、
①　基底クラス　Product、派生クラス ConcreteProduct
②　基底クラス　Creator、派生クラス ConcreteCreator
であり、②の派生クラス ConcreteCreatorのメソッド factoryMethod()で①の派生クラスConcreteProductのインスタンスを生成する、というパターンです。Visitorパターンが２種類の派生クラスのインスタンス生成が絡み合っている例ですが、この例は、そのような絡み合いがなく素直なケースです。利用目的については意味不明な説明が多いですが、特に深く考えなくてもいいと思います。派生クラスのインスタンス生成によるプログラムの一例です。

http://www.ie.u-ryukyu.ac.jp/~e085739/java.it.18.html

①　基底クラス　Mediator、派生クラス ConcreteMediator
②　基底クラス　Colleague、派生クラス　ConcreteColloeagueA, ConcreteColloeagueB
mainプログラムを見ると、mediaor, colA, colB の３つのインスタンスが生成されていて、colA, colBのメソッドの処理をmediatoのメソッドに委任させる方法です。
　　
　　　public abstract class Colleague{
   　　 protected Mediator mediator;
　　　　　・・・・・・
    　　public void setMediator(Mediator mediator){
　　　this.mediator = mediator;
    　　}
　　}
②の基底クラスColleagueで、①の基底クラスのインスタンスをメンバーとし、そのインスタンスを書き換えるsetMediatorというメソッドが実装されています。メッソドrunを実行させると以下のコードのmediator.consultation(this)が実行されます。mediator.は基底クラスのColleagueで宣言せれているインスタンスで、runを実行させる前の処理setMediatorでmainで生成されたmediatorが代入されています。それにより、colA.run, colB.runはmediatorインスタンスのconsultationを実行することになります。

　　public class ConcreteColleagueB extends Colleague{
   　　　・・・・・・
   　 public void run(){
　　　　 mediator.consultation(this);
  　 }
　}

Strategyパターンを拡張したもので、複数の派生クラスのメソッドの処理を他のクラスのメソッドに委任する方法です。

2015年11月6日

以下の記事結構秀作かなあ～と思いきや最後、転職会社の紹介になっているのがちょっと残念な気がします。

オブジェクト指向の悟りを開く！初心者でも分かるOOPの最重要技術ポリモーフィズムの使い方！
http://mikumikuplay.com/it/oop_polymorphism/

まつもとゆきゆろさんの立場からするとオブジェクト指向言語を提唱する上でポリモーフィズムの機能を実現するのは必須で、もちろんこれがないオブジェクト指向言語など貶されるのは目に見えている、ってことです。先生にとってはポリモーフィズムは重要なことでしょう。
しかし、言語がオブジェクト指向であっても、ポリモーフィズムを知らなくても何らなのプログラムを組むとは可能です。オブジェクト指向で最も重要なことは、数や文字列、ポインタだけではなくクラスで生成されるオブジェクトが扱えることだと私は思います。「ポリモーフィズムが重要」というのは、言語を提唱する立場の人にとっては最重要課題であって、言語を使う立場としては、クラスライブラリやフレームワークを構築する、または抽象化を使って開発ルールを検討する等の目的でないかぎりは役に立ちません。なかなかいい説明や使う理由を明確に書かれた著書がないので、ポリモーフィズムを理解することは困難でが、確かにコンポーネントなど独自の仕様にカスタマイズしたいときは、オーバーライドなど使うわけで、必要になったら仕様書を読めば、ポリモーフィズムを使うことになるわけです。ポリモーフィズムを使う場面がないから・・・という理由だけでわざわざ転職する必要はないでしょう。

『抽象メソッドはサブクラスで実装するのでサブクラスが何かによって、「なんらかの処理」が具体的な処理に決まります。このような設計をTemplate Methodパターンと言います』

抽象メソッドそのものずばりを説明した明快な一文ですね。なるほどと思ってしまします。

ポリモーフィズムを説明する上でよいサンプルコードを提示していただいていると思います。それでは実践でポリモーフィズムは有効に使われるでしょうか？
もし、ファイルアクセスで一般的に有用な基底クラスが存在すれば、そのクラスは開発ツールのクラスライブラリに組み入れられたり、誰かがブログサイトでそのクラスを紹介してくれるでしょう。結局はポリモーフィズムが有効に活用されるのは、クラスライブラリを構築する場合がメインですかね。あとはクラス設計とメソッド実装が別担当者など、開発体制やソースコード管理面理由で、抽象化を利用している等、ありがちがことだと思います。

public staticメソッドの利用を薦めない理由にポリモーフィズムが使えないという意見が多いです。ポリモーフィズムは違う派生クラスでインスタンスを生成することにより実現できるので、インスタンスの生成を必要とないstaticメソッドの使用は相容れないものがあります。しかし、継承やポリモーフィズムはクラスライブラリを構築する場合に共通なメソッドやメンバーを基底クラスに設定することでライブラリ全体のコード数を減らすのに対し、public staticメソッドはプログラム単体で見たときに共有な処理を一つのメソッドで実現できる効果があるもので、ポリモーフィズムとstatic、実装する観点が違います。

ご存じのとおり、staticメソッドは構造化プログラミングの影響を受けています。オブジェク指向プログラミングでは古い構造化プログラミングの影響を受けたstaticメソッドのような遺物は使うべきでなく、共通ルーチンはクラスを作成して実装すべきだとの声もあるかと思いますが、未だにstaticメソッドで実装されたものはコードが読みやすいです。またオブジェクト指向言語では、引数やリターン時に数値や文字列、ポインタだけではなくインスタンスも使えるので、オブジェクト言語でも構造化プログラミングで培われた「関数でまとめる」という技術がふんだんに使えるわけです。

自称オブジェクト指向プログラマーの人のコードを見ると、モジュールとしてクラスを利用しているわけで、他の開発者が再利用することを意識してクラスを作っているとはいい難いです。

　　パブリックなメンバーに値を代入　→　メソッドで処理を実行しパブリックなメンバーに結果を書き込む　→　パブリックなメンバーから値を取り出す

このような処理をするためにクラスを作っていますが、そのようなことはメソッドの引数とリターン値を使えばできることですし、複数の値を返す場合は、構造体ようなメンバーのみの簡単なクラスを作れば済むことです。

以前は、「おはよう」「こんにちわ」「おやすみなさい」などという挨拶をメッセージを表示させるメソッドを含んだ派生クラスを作り、次々にそれらの派生クラスでインスタンスを生成し、ループでメソッドを実行することにより条件分岐がないポリモーフィズムのサンプルプログラム例が多かったです。しかしこのような例は、べた書きでインスタンス生成しているからできることであって、機能的にはあらかじめ決められた順番の挨拶を表示すれば、同等のプログラムはできてしまいます。多量のデータを扱う実践的なデータ処理では、データのタイプを判別する条件分岐は必須であって、いわゆる条件分岐なしのポリモーフィズム・プログラムは役にたちません。

http://d.hatena.ne.jp/cnaos/20091125/1259136404

この例では実践的な例を提案していますが、bank = new A銀行　、bank = new B銀行のように条件に応じてそれぞれのインスタンスを生成しても、インスタンスが有効なのはメソッド内だけですので、実際やってみると、それほど単純にはリファクタリングはできないと思います。ポリモーフィズムとは抽象化した基底クラスと派生クラスの組み合わせのクラスライブラリの構造であって、メインプログラムの書き方がかわることは副次的なことです。実践的なプログラムでは、派生クラスのメソッドをオーバーライドすることにより、OSやデバイス、ビジネスロジックをカスタマイズすることがでます。つまり実践では動的に派生クラスを切り替えるケースは少ないと思います。しかし、架空の例であるサンプルプログラムは、ダイナミックに派生クラスを切り替えるものが多いです。なぜか知りませんが、オブジェクト指向の先生たちは、ポリモーフィズムを使えば、このような素晴らしいことができますよ！と強調したいのでしょう。しかしオブジェクト指向を学ぶ側からすれば理解の妨げとなります。多くの先生たちはポリモーフィズムを条件分岐をなくす優れた魔法のように語り、それは多くの生徒を幻想の世界に連れて行きます。しかし、よくよく考えてみると、ポリモーフィズムは従来クラス内部にあった記述をクラス外部に書く開発手法であると割り切ることができます。

大容量のトランザクションデータのインポートでは差分でインポートするのが効率的です.。SQL　Serverのストアドプロシージャで差分インポートが可能かどうか検討してみました。

① インポート先のテーブルと同じ構造の一時テーブルの作成

③ 一時テーブルに存在するレコードと同じキーのレコードを対象テーブルより削除

という手順でやってみました。もっといい方法がありましたら連絡ください。ぜひとも情報交換したいです。

DELETE FROM TestTable WHERE EXISTS (SELECT 1 from #tmp where TestTable.番号 = #tmp.番号);

2015年8月26日

マトリクス表のような画面で作って欲しいという依頼があって、悩んだ末、やはりEXCELで作るのが無難なので、VBA書いて作った。そのときはマトリクス表にデータを表示するのみであったが、今回、マトリクス表でデータを入力したいとう要望があり、VBAをいじくってます。

マトリクス表でデータ入力となると、データ入力以外の部分はプロテクトしなくてはいけないので、めんどうですね。

Dim x1, x2, y1, y2

x1 = 2
x2 = 3
y1 = 2
y2 = 4

'データ入力規則
    Range(Cells(x1, y1), Cells(x2, y2)).Select
      With Selection.Validation
        .Delete
        .Add Type:=xlValidateList, AlertStyle:=xlValidAlertStop, Operator:= _
        xlBetween, Formula1:="　,〇"
        .IgnoreBlank = True
        .InCellDropdown = True
        .InputTitle = ""
        .ErrorTitle = ""
        .InputMessage = ""
        .ErrorMessage = ""
        .IMEMode = xlIMEModeNoControl
        .ShowInput = True
        .ShowError = True
    End With

'ロック解除
Range(Cells(x1, y1), Cells(x2, y2)).Locked = False

'シート保護
Sheet1.Protect Password:="Hello"

これで、特定の範囲のみ「〇」の入力ができ、その他の領域は入力保護状態になります。

最近はExchange Online関係の仕事がメインでした。前回の更新が７月でした。暑い季節が終わると一気に年末になってしまいますね。

C#でプログラミングしていて凄い発見をした。すべてstaticメソッドにするとアホみたいに捗る

このおっさんが言ってるのって、staticなメンバ変数だからな。

全部グローバル変数にしちゃえばいいじゃんとか、アホだろ。

メンバ変数は常にprivate、外部からアクセスする時はプロパティ(setter,getter)を使う。

そうしないと、各インスタンス扱う度にstaticな変数の影響を気にしなきゃならん。

public staticなメンバ変数とか、Javaの言語仕様として定義出来なくしていいくらい。

staticはダメ　駆逐せよみたいな優生学になっちゃうのがダメなとこよねオブジェクト指向の

99%のケースでswitch文のほうが分かりやすくて早くて修正しやすくて汎用性の高いコードになる

クラスの書き方のお手本を、学校や技術書で学び、プロパティとメソッドにより構成されている典型的なクラスのお手本というものを優等生は学ぶわけです。メンバー変数を使って、別のクラスからも値の受け渡しができるようになります。しかし、それってメソッドの引数やリターン値でも別クラスへの値の受け渡しができますよね。しかもメンバー変数って、そのクラス内ではグローバル変数と同じ役割です。メンバー変数は少ないほど、可読性はよくなります。背景色、フォントの色、タイムアウト値などのパラメータはメンバー変数でプロパティにしたほうがよろしいのですが、処理対象となるデータをプロパティとしてしまうのは、可読性という面でディメリットがあります。この辺は、自分でコードを書くだけではなく、人の書いたコードをメンテナンスするような作業をしてみないとわからないことなのです。最近、「staticおじさんになりつつある」というつぶやきが多いのですが、これは加齢のためではなく、実際社会人になって開発作業を経験し、生産性やメンテンナス性を考慮した結果、必ずしもオブジェクト指向のお手本のようなプログラミングをすることが、実践に適しているとは言えない！という悟りなのかもしれません。

それから、変数を全部 public static に宣言するなんて、常識から考えてダメに決まってますよね。私はグローバル変数的なものを public static宣言していると当初のコラムで書いているだけです。もちろん、そのようなグローバル変数的なものに書き込み更新をする場合は注意が必要ですから、あまりライトはしません。あとから見直すと public static const にしといてもよかったものも多いです。また、私はイントラネットのWEBアプリケーションを主体に開発していますので、ページ間にまたがる値の受け渡しは、QueryString などのテクニックやセッション変数を使っています。値の受け渡しに共有変数を使うことはほとんどないんですね。

これによると、バグとの噂。仕様ではパブリックフォルダの総量は1.25TGBとなるはずであった。はやく解決してもらいたいものだ。

Exchange Online のWEB管理画面では、コマンドレットなど入力する方法など見当たらない。Exchange Onlineでコマンドレットを実行するには、ユーザーが使っているマシン上でPower Shellを立ち上げ、そこからExchange Onlineに接続する。

現時点で最新の情報によると、Windows2012, Windows8では何もインストールすることはなく、Windows2008R2やWindows7では、.NET Framework4.0とWindows Management Framework 3.0をインストールする。

Windows6.0や6.1といった馴染みのないOSのバージョンが記載されているが、以下のようなインストール・インストラクションを参考にダウンロードする。

•Windows 7 Service Pack 1
•64-bit versions: Windows6.1-KB2506143-x64.msu
•32-bit versions: Windows6.1-KB2506143-x86.msu
•Windows Server 2008 R2 SP1
•64-bit versions: Windows6.1-KB2506143-x64.msu
•Windows Server 2008 Service Pack 2
•64-bit versions: Windows6.0-KB2506146-x64.msu
•32-bit versions: Windows6.0-KB2506146-x86.msu
　

インストールしてからパワーシェルの画面を立ち上げ、以下のコマンドを入力すると、コマンドレットが使える。

ここでセキュリティポリシーを変える　「y」と入力

>$UserCredential = Get-Credential

ポップアップ画面に、Exchange Online のアカウントとパスワードを入れる

>$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $UserCredential -Authentication Basic -AllowRedirection

最後に終了するときは、以下のコマンドでセッションを切る
>Remove-PSSession $Session
　

ずっと使い方しっくりこないんで、使わないでいまししたが、必要にせまられて使ってみました。

Get-PublicFolderStatistics | Sort-Object -Property FolderPath | select-object FolderPath,DatabaseName,TotalItemSize,ItemCount,LastAccessTime,LastModificationTime,CreationTime | Export-Csv -NoTypeInformation -Encoding utf8 ファイル名

このコマンドをExchange管理シェルで実行すれば、パブリックフォルダのサイズ、アイテム数、作成日などがわかります。

を実行するとGet-PublicFolderStatistics で取得できるパブリックフォルダの項目すべてが出てきます。その中のいくつかの項目を表形式で表示したい場合に、select-object　を使います。さらにExport-Csvでファイル出力すると便利です。

「実はオブジェクト指向ってしっくりこないんです」から三年

三年前にVisual StudioというMS社の開発ツールを使って開発についての感想を思いついたままに書いたコラムである。実際にこのような開発をしていて開発効率が極めていいし、不具合も少ない。

当時多くのプログラマー、ソフトウェア技術者が、継承、ポリモーフィズム、フレームワーク技術、デザインパターンなどに夢や幻想を持っていた。そのような技術が業務アプリーケーションのビジネスロジックで多用されるものだと信じ切っていた。

しかし今の時点で、デザインパターンは死語。単なる基底クラスと派生クラスの関係を使ったサンプルプログラム。オブジェクト指向プログラミングでは、こういうこともできるよ！っということを示しただけで、出版当初としてはショッキングかもしれないが、実践では役にたつ場面は非常に少ない。

オブジェクト指向の高度な技術は、クラスライブラリや開発ツールでも開発しなければ、使わない技術で、一般の業務アプリケーション開発ではクラスライブラリを使うだけで十分事足りる。

もうオブジェクト指向という言葉さえ、輝きを失い、くすみを帯びている。もうオブジェクト指向は枯れた技術であり、私が提唱する開発手法は世の中に定着しているのが現実である。

「確かに、開発現場では、OOp開発者が不遇な目に合っているのは事実ですし、非OOPや、継承禁止などトンデモな開発標準があるのも事実です」

真のOOP開発者が実力を発揮できる場って、クラスライブラリの開発や開発ツールのようなフレームワーク開発なのだから、アプリケーション開発は、用意されたクラスを使えばほとんどのケースで十分なのです。

共有ルーチンとしてのstaticメソッド活用など、私が提案する開発手法の効率性やメンテナンス性が世間の開発標準として認めれらた、という事実に他ならないのです。

「オブジェクト指向は、非オブジェクト指向より進化したものであるから、staticメソッドを使うというのは、古臭いものを押しつけている」という異論がまだ経験の浅いプログラマーの方に多いです。学校で習ったOOPの知識が使えない。

しかし、転職した前任者や先輩の書いたプログラムをメンテナンスすることになったら、スタンスが１８０度変わります。

　クラスを見てさっぱりわからない
　こんなものを今後メンテナンスするなんて耐えられない
　転職したい
　この業界から足を洗いたい

なんて思うわけです。
私も転職去って行ったエンジニアのプログラムのメンテナンスを担当していますが、いわゆるオレオレクラス、オレオレオブジェクト指向ってもので、ドキュメントもコメントもなくひどいものです。ですから私の主張する開発手法は、そういったクラス開発の濫用の弊害の反省を踏まえて、考案したものであり、開発効率、デバック効率、メンテンンス効率が優れ、世間に認められるわけです。

多くのオブジェクト指向の先生方は、「staticメソッドばっかり使っているとOOP技術者にはなれない」と語っていると思います。しかし、staticメソッドできちんとした構造型プログラミングができない人が作ったプログラムの品質は良いとは思えません。前日の述べましたが、ある程度のクラス粒度というものを定め、短いルーチンはstaticメソッドで済ませてしまうのが効率的な開発手法です。

どちらかというと私よりの意見なので、一部を除き、ほぼ、同意できます。

クラスライブラリのような、大規模な部品化技術や開発ツールのような、フレームワークを作る目的がなければ、高度なオブジェクト指向技術（継承やポリモーフィズム）は使いません。
ただし、クラスライブラリを使ってプログラミングすることは多いですよ。学校で学んだこをは基礎理論の位置づけでよろしいのじゃないでしょうか？

「長期的にはOOPの方が保守性が高いのは事実だろうが、開発要員にOOPを周到教育するには相当なコストを要する。そのコスト負担が期間的に無理なのも現実です」

→　ドキュメント作成能力が低い人が書いたクラスなんて、さっぱり仕様がわかりません。メンテナンスは難しいんです。
クラス粒度みたいなガイドラインを決めといたほうがよろしいのでは・・・
数百行程度までのルーチンならばstaticメソッドで十分ですよ。
staticメソッドのほうが引数を入力とし、リターン値を出力する規則になっているので第三者からみても可読性がいいのです。
長期間プログラム保守を継続するには、構造型プログラミングを重視するのは、昔から変わらないと思います。
　

コンポーネントをいろいろなアプリで使う目的で、汎用性を重視したい場合に、OOP開発手法を使えばいいのです。

→　今までの本や教育が適切でないだけで、本サイトを見てもらえば、OOPのメリット、ディメリットがわかっていただけると思います。

●　クラスって単にサブプログラムと思えばいい
●　インスタンスってコンポーネントを区別する識別子だと思えばいい
●　いくつかのクラスがあって、共通する部分は基底クラスにして継承したほうが冗長性がなくなる
●　カスタマイズが必要なコンポーネントは基底クラスに仮想関数を定義しておき、派生クラスでオーバーライド

OOPの肝って、こんなもんでしょう。とにかくプログラムを作る、デバックする、動かすというOOP以前の努力と比べれば、OOPの概念を知ることは、それほど大変なことではないです。さらに、

なんてことも知っていれば、かなりOOPらしいプログラムができるのではないでしょうか？数値型や文字列型、配列で値の受け渡しをしているクラスを見たことがありますが、それはOOPとは言い難いものです。
　

//MultiLineの文字数チェック
function Count(text,long)
{
var maxlength = new Number(long); // Change number to your max length.
var l = text.value.length ;

if(l > maxlength)
{
alert(long + " 文字以下にしてくだい");
text.value = text.value.substring(0,maxlength);

}
}
　

//C#プログラム　Page_Load
TextBox1.Attributes.Add("onkeyup", "javascript: Count(this,100);");

ASP.NETでMultilineのテキストボックスに対して文字数制限を設けた。当初、ユーザーより制限文字数以上文字入力すると、今まで入力していた文字がテキストボックスからなくなってしまう、とのクレームあり。ちゃんとWEBで調べた方法なので、「まさか～」と思ってましたが、制限がうまく動作するのは英数字だけで、日本語はユーザーの言った通りの結果であった。かな漢変換が「未確定」という中途半端な状態を作り出すので、scriptが正常の動作しない模様。

いろいろ調べた結果、substringで制限文字数をカットする前にalertを入れるとonkeｙupイベントでうまくいくことが分かった。alertをsubstringの後に入れるとダメなようです。

最も年収が多い女優、綾瀬はるか主演の八重の桜。普段はドラマなど見ないので綾瀬はるかってどんな女優なのか全く知らなかった。正月からNHKで八重の桜を宣伝している。話題になりそうと思い、1回目、2回目を見てみた。八重の鉄砲に対する興味と、良く知られたペリー来航の話だけで2回もたすだけでもタルかった。2回目は八重の子役に変わって綾瀬はるかが登場するにもかかわらず、巷では視聴率が落ちたという。オープニングが派手なだけで、美人でスタイルもいい女優を出したところで、女性らしい華やかさがない役で、なんか宝の持ち腐れ、役柄に合ってない感じがしました。こういう男っぽい役は米倉涼子のほうがハマり役だと思うな。でも米倉さん以前、大河に出て海老蔵と話題になったから、しばらくは大河に出られないんだろうな。

私は、インドリさんとネット上でからんだことがないので、詳しい情報は知らないのです。

それにしても　玄米茶さんのコラムに出てくるAさんって、訴訟されても裁判で勝つ自信があるんでしょうかね。

私は、インドリさんとネット上でからんだことがないので、詳しい情報は知らないのです。

それにしても　玄米茶さんのコラムに出てくるAさんって、訴訟されても裁判で勝つ自信があるんでしょうかね。

本の著者が、思慮に欠けた、簡単に矛盾点を指摘されるようなコメントを書いてしまうのが炎上の原因ですな。

それから「↑」とか、他のコメンテーターの名前も記載しないなんて、儀礼に欠けた態度なんで、その著者の書籍を出版している会社にとっては、いくら必死になっても、フォローしようがないですな。

>太郎冠者 2012年12月26日 (水) 01:03
>みながわけんじさん
>玄米茶さんもおっしゃていますが、いい加減にして下さい。
>ご自身の発言が、いかに人として恥ずかしいものなのか理解されていますか？
>他の人も無駄に煽るような書き込みは控えて頂きたいです。
>みながわさんやAさん自身に対して言いたい事があるなら、彼らのサイトかブログにお願いします。（みながわさんは掲示板付のサイトを、Aさんはブログを持って>います）

要するに、けんかは外でやって欲しいという意見ですな。「太郎冠者」って能で出てくる主人公の名前らしいです。そんなこと知っているなんて、この人理系じゃなくて文系なのかな、ひょっとしてどこかの編集部の人かな思っちゃいます。まず他の人の誹謗、中傷をやめさせていただきたいものですな。

「いかに人として恥ずかしいものなのか理解されていますか」

まるで、私が犯罪でもしているかの書き方ですね。太郎冠者さんも必死ですね。私が掲示板付のサイトを持っていることまで知っているなんて！Aさんはブログ持ってないと言ってましたが、IPからAさんを特定したんですね。コメント者のIPがわかるのは、コラム執筆者か@IT編集部の人しかいないはずです。

19 ：仕様書無しさん：2010/07/05(月) 23:06:46
「オブジェクト指向的日常」ってなんだよ。
金返せ！！！
　

>A 2012年12月19日 (水) 09:36
>
>@ITを読んでいると、よくεπιστημηさんが仲間を引き連れて（プロバイダを複数契約しているのかな）暴言や自画自賛を交えて、他の読者を攻撃している光景が向けられます。普通に一人で議論できないのでしょうか？不快です。
　

やっぱり、そういうことがあるんですかね。朝早い時間帯　８時代に違う人が続いて投稿するなんて、珍しいですよね。

「小原圭 ‏@ooharak
Javaでオールstaticおじさんでも、設計や仕様の文書化がきっちりしてれば、まともに動くものを理屈上は作れるはず。けど現実では、そういう作りのものは大体設計とかドキュメントもむちゃくちゃだね」

私は、JavaではなくVisual Studio C#をやってますが、現代の開発ツールってフレームワーク技術やクラスライブラリが整備されているので、、本当のオールstaticってあるんですか？あったとしても単に数値を計算するだけのプログラムとしが思えないのですが・・・最近の開発環境を使って、フォームやWEBサイトを作ると自動的にクラスができますよね。また、クラスライブラリのクラスもほとんど、インスタンス生成が必要とされるものですよね。オールstaticってどういう開発環境の使い方をしているのか逆に興味がわきます。

staticのメンバー関数は引数を入力値、リターン値を出力としてますので、コメントがあれば、さほどドキュメントなどなくても再利用できるのですよ。むしろクラスのほうがメッセージパッシングなので、わかりやすいドキュメントを作らないと再利用できず、オレオレ・クラス、オレオレ・オブジェクト指向のような自己満に陥りやすいんです。

筆者の玄米茶さんからコメントをいただきました。いつも＠ITのオブジェクト指向ネタって炎上しちゃいますけど、今回は大丈夫みたいですね。

>実際のところこんなの簡単で、複数の似た処理を作る際に、同じ部分があったら共通クラスを作ってそちらにメソッドを定義するだけ。
>異なる部分は抽象メソッド（処理本体は記述しないメソッド。C++でいう純粋仮想関数）にして個別の具象クラスで書く。
>オブジェクト指向の用語で言えば多態だのポリモーフィズムだのという機能を使っていることになるが、そんなの知らなくても出来るしｗ
>staticおじさんプログラムを作る人達は、こういったフレームワークの概念も知らないんだろうなぁ。

と記載されてます。私は2011/2/26に、にゃん太郎さんというプロマネの人が、クラスライブラリとフレームワークという用語を混同して使っているのではないかという指摘をしています。

>NET FRAMEWOK という言葉で、フレームワークとクラスライブラリが、ごっちゃの意味に捉えられていますが、私はグーグルで「フレームワークとクラスライブラリの違い」について調べたことがあります。クラスライブラリは、ライブラリのオブジェクトを使って、その周りにユーザーがコードを記述するもので、フレームワークは用意されたテンプレートの中にユーザーがコードを記述するもので、ユーザーがやることは反対なんだという説明でした。

>フレームワークを作っているなんていうと、開発ツールを作っているか、オーバーライドできる関数を用意しておき、あとでカスタマイズするような設計をしているのかな？なんて勘違いするので、その辺の用語は適切にしたほうがいいんじゃないでしょうか？にゃん太郎さんのようなかたは、すごいオブジェクト指向技術を使っているだろうなあなんて思ってましたけど、意外に私でも納得がいくような技術なんで、なんか安心してしまいました。

staticメソッドを使うメリットはバグが出にくい。単体テストがしやすいというメリットがあります。多くの現在の開発ツールがフレームワーク技術を使っていますので、staticメソッドを使う人がフレームワークを知らないということはなく、フレームワーク技術について、きちんと説明できないプログラマーがほとんどなのです。最初にリンクした記事はわかりやすく、的確に説明されていると思います。ただフレームワークを使うメリットがはっきりと見えてこないのが、この説明の欠点です。ただ単に受注開発するならばフレームワークをわざわざ使うメリットは少ししかありません。主力メーカーがソフトウェワのコアの部分を使い、パートナー会社が周辺のロジックを開発するならば、これは協力なソフトウェア・アーキテクチャとなりえます。そのようなビジネス的観点が欠如していると日本のソフトウェア業界は未来がないといっても過言ではないでしょうか？

最近では、自分は「staticおじさんである」とツイートする人も出てきて、静的おじさんは市民権を得ています(というか老害という棺桶の中から生き返っている)。しかしまだ、インターネット上では、誹謗中傷のコメント、つぶやきが繁茂しているのが現状です。

単に若い方は、「オブジェクト指向パラダイム」という言葉からオブジェクト指向をやっていればパラダイスに行けると思っているんじゃないの！実際は地獄に行くひとが多いのだが・・・

このブログで紹介されているReadable　Codeという本、実はまだ読んでいません。

>クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけ
>static にすることだ

>えええーとはいえ前からstaticおじさんのアンチテーゼとして全部objectおじさんなことは自覚してるので正しく使いたいなあ。結局状態持ちたいんじゃね?持たざるをえないんじゃね?とは思ってる。

「メンバー変数というものは、クラス内のグローバル変数であり、それらを使わず、staticメソッドを使ったほうが、不具合が出にくい」ということは、世界的に認識されているってことか・・・

ブログの筆者としては、状態変数マシンという意味で、メンバー変数は必要だとお考えであるが、ステート（状態）マシンを作る必要がなければ、メンバー変数はないほうが、不具合は少なくなりますよね。

SAP　R/3は世界的に使われているERPパッケージです。しかし実際に企業の業務というものは、まったく同じ形態ではなく、独自の業務形態というものが存在する。それにたいおうするために、SAPでは、EXITという空の関数を用意し、必要ならば、それにロジックを記述します。

なんか仮想関数みたいですね。以前からR/3にはそのような手法が存在するのですよ。SAP　ABAPもオブジェクト指向技術が取り入れられ、ここで紹介されているBADIというものは、それこそ仮想関数をオーバーライドするようなものかもしれませんね。ビジネスロジックで使われるオブジェクト指向技術なんてこのようなオーバーライドにつきるといっても過言ではないでしょう。

ビジネスロジックの分野において、「オブジェクト指向で条件分岐が減る」なんてことは、まさに四暗刻、たまたま運がよかっただけ！

>通りすがりより
>2012-11-14 15:29:58
>メインの話題とは全く関係無いんですが。

>> 未だに、業務アプリのビジネスロジックにオブジェクト指向をうまく適用できた具体例を聞いた事がありません。あれば教えてください。

>なぜ、「業務アプリのビジネスロジック」という限定をするのか良くわかりませんが、"業務システム"でJavaが採用されているのをどうお考えですか？それらは、すべてうまく適用できていないと思いますか？

この人は「業務アプリのビジネスロジック」の意味がわかっていませんね。Javaで書かれているからオブジェクト指向というのも非常に短絡的な考えです。Javaでも手続き型的プログラミングはできますよね。

>POSAやPoEAAという言葉はご存じですか？ご存じの場合、それらは"業務システム"には全く適用できないものなんでしょうか。
　

知りません。インターネットで調べてみましたが、単なるよいプログラムの書きかた、模範のようなものであって、レイヤーを意識してシステム構築せよとの指針です。オブジェクト指向に限定したデザインパターンではないですよね。トランザクション処理などの例も提示されています。

>なお、私の少ない経験の中でも、EJBを使った銀行系の超大規模システム(5000人月超え）は成功しましたし、NTTDがやったNTTの料金システムなどでもJavaが使われていたはずです。
　

ですから、Javaが使われれいるから、継承とかポリモーフィズムなどのオブジェクト指向の高度な技術が使われているということには全くなりません。クラスを作っても、それは単なるモジュールです。それらのクラスのやっていることはCOBOLの関数と大差ないです。

>通りすがりより
>2012-11-14 15:34:23
>書き忘れましたが、富士通やNTTDなどは、業務ロジックを構築するための「なんちゃらframework」というのを結構製品化してます>よ。（その他の大手の動向は知りませんが）

>それらを採用するのは意味が無いことなんでしょうか。
>また、採用したところは全て失敗（というと言い過ぎですが）してるのでしょうか。

>私はそうは思いません。
　

なんちゃらframeworkって開発ツールですよね。業務アプリケーションでないですよね。

なんちゃらframeworkっていう製品があるから、業務ロジックでフレームワーク技術が使われている、っていう論旨は検討違いです。もちろん開発ツールで高度なオブジェクト指向技術がふんだんに使われていることは、私も誰でも知っていることですがね。

>通りすがりより
>2012-11-15 10:41:27
>通りすがりなので、私からのコメントはこれで終了です。

>> 無いと業務アプリが作れない（RDBのよう
>> に、それを使うと劇的にコストが下がるとか信頼性が高まるとか）ということでもないでしょう

>私は1,000人月を超える中～大規模プロジェクトで、かつJavaかC++を使っているプロジェクトに参加したことは3,4回しかなく、また>業界の動向を常に探っているわけではありませんが、その狭い視野で言えば、劇的にコストは下がり、信頼性は高まります。
　

劇的にコストが下がった理由を言って欲しいなあ。理由が述べられていないと、「劇的に」とか言っても説得性がないんですよ。

>大規模プロジェクトになると、製造工程では数社入りみだれ100～300人ほどが同時にコーディングしてたりしますが、それぞれなんの「基盤」もなくコーディングした方が低コストで高信頼性のものができると思いますか？
普通に考えれば、まず「基盤」となる部分を、既に製品化されているなんちゃらFramewrokなり、そのプロジェクト独自のものなりを先行して開発し、それをみんなで使う方が低コストで高信頼性のものができると思います。

「基盤」、要するに部品を作って効率化！ということでしょ。そんなこと誰でも考えますよ。昔からある考え方です。

>一方、中～小規模なプロジェクトでは、それはもう空気のようにオブジェクト指向が使われているというのが私の感触で、「オブジェクト指向をうまく適用できた具体例を聞いた事がありません」と言われると、それはあなたが知らないだけなんじゃ無いの？と思う次第です。

「空気のように」とまたごまかしてますけど、ようするに、クラスを単なるモジュールとして、ぼこぼこ作ってるわけでしょ。無意識でポリモーフィズムやってるなんていう人って天才かつ変態かと思っちゃいます。

>またTIOBEによれば、JavaやC++は非常に人気が高いです。それらの人達の大半がプロジェクトでオブジェクト指向をうまく適用できず、炎上したりプロジェクトが失敗したりしているとは思えません。もしそうであるなら、もっとシェアが低くなるはずです。

ですからJava、C++を使っているからといっても、継承、ポリモーフィズムを使う場面はごく一部の対象です。この人はどんなプログラミングをオブジェクト指向といっているのか自分で示していないわけです。このような文字だけ、上辺だけの意見は技術の世界では認めがたいな。しかも匿名「通りすがり」さんの単なるコメントですからね。

これらの記事が掲載されている掲示板で、「通りすがり」さんよりコメント削除依頼が記載されました。

通りすがりより
2012-11-19 14:17:01
> 先にコメントしましたとおり、本題とは関係がなくかつ論争となりそうな部分については削除しました。

でしたら、私からの「通りすがり」名義の以下の発言も、全て削除をお願いします。
2012-11-14 15:29:58
2012-11-14 15:34:23
2012-11-15 10:41:27

以下の記事でStateパターンとFactoryパターンらしきテクニックを使って条件分岐をなくすという内容の記事が書かれている。

private void buttonNormal_Click(object sender, EventArgs e)
{
　this.ChangeTextBox("Normal");
}

private void buttonWarning_Click(object sender, EventArgs e)
{
　this.ChangeTextBox("Warning");
}

private void buttonError_Click(object sender, EventArgs e)
{
　this.ChangeTextBox("Error");
}

private void ChangeTextBox(string state)
{
　this.textBox1.Text = state;
　switch (state)
　{
　　case "Normal":
　　　this.textBox1.BackColor = SystemColors.Window;
　　　this.textBox1.ForeColor = SystemColors.WindowText;
　　　break;
　　case "Warning":
　　　this.textBox1.BackColor = Color.Yellow;
　　　this.textBox1.ForeColor = SystemColors.WindowText;
　　　break;
　　case "Error":
　　　this.textBox1.BackColor = Color.Red;
　　　this.textBox1.ForeColor = Color.White;
　　　break;
　　　default:
　　　break;
　}
}
　

このようなコードサンプルでポリモーフィズム使い、ChangeTextBoxのswitch文をなくす方法について記載されているのだが、これって、本当にポリモーフィズムの恩恵？？？と思っていしまうのだ。

一回条件分岐で　instanceX を生成した後、instanceX.Method1()、 instanceX.Method2() 、 instanceX.Method3()、・・・・　は条件分岐で選択された派生クラスのメソッドを実行する振る舞いになるというのが、ポリモーフィズムの基本のはず。だから条件分岐を一切なくすというのは府に落ちない。なぜだろう？？？

これって以下の実に簡単で素直なコードでも動作するはずなのだ。しかも条件分岐なし。

private void buttonNormal_Click(object sender, EventArgs e)
{
　textBox1.Text = "Normal";
　textBox1.BackColor = SystemColors.Window;
　textBox1.ForeColor = SystemColors.WindowText;
}

private void buttonWarning_Click(object sender, EventArgs e)
{
　textBox1.Text = "Warning";
　textBox1.BackColor = Color.Yellow;
　textBox1.ForeColor = SystemColors.WindowText;
}

private void buttonError_Click(object sender, EventArgs e)
{
　textBox1.Text = "Error";
　textBox1.BackColor = Color.Red;
　textBox1.ForeColor = Color.White;
}

条件分岐というと、if文やswitch文だけという思い込みがあるが、ボタンをクリックするイベントも実は人間が条件選択する条件分岐なのだ。ポリモーフィズムを使うまでもなくリファクタリング？っていうか、最初から素直に単純なコードを書けばいい。

どうしてもポリモーフィズムを使いたいならば、以下のような基本的なものでもいいかもしれない。

private void buttonNormal_Click(object sender, EventArgs e)
{
　基底クラス　instatnceX = new 派生クラスA（）;
　関数(instatnceX );

}

private void buttonWarning_Click(object sender, EventArgs e)
{
　基底クラス　instatnceX = new 派生クラスB（）;
　関数(instatnceX );
}

関数(基底クラス instanceY) {

instatnceY.method1();

instatnceY.method2();

}

また、イベント関数内は、以下のように書けるかもしれない。

private void buttonNormal_Click(object sender, EventArgs e)
{

　関数(new 派生クラスA（）);

}

この記事では、読者のコメントにswitch文が多いなら、ポリモーフィズムを使えと指示しているが、同じパターンの条件分岐が沢山あるならば、ポリモーフィズムは使えるが、ただ単に条件分岐が出てきたら、即、ポリモーフィズムは筆者の指摘の通り、多大な工数がかかるだけとしか思えないのだが・・・ delegateはコードの中身を分離する抽象化っぽい面があるが、条件分岐の減らす効果があるのかは、そのような例を知らないので、どうかなあ？

ポリモーフィズムは、プロジェクトメンバーがよく知っているクラスライブラリの派生クラスを使わないと、やはりオレオレっぽい(ポリモなしで、素直に書いたほうが行数が少なくメンテも楽)。なかなか教科書やWEBのサンプルコードのしょぼいクラスでは便利であるという実感がわかない。I/Oインターフェイスを切り替える、DB接続をSQL Serverとオラクルで切り替えるような場面でないと利用価値が少ないのでは・・・　あえてオーバーライドしてカスタマイズするメリットがあるならば、ポリモは使えると思うのだが・・・

InkscapeなるHP製作に役立つソフトを初めて使ってみた。デザインのことはまったくわらないので苦労する。とりあえずメモっておく。

おそらく、この筆者も文系なのだろう。いかにテクニカルな知識や経験がなくても出世するかの方法である。米国では様々なベンチャー企業が生まれ育つが、その多くは大手に吸収合併されてしまう。古今東西、結局長年経営が安定している大手企業の一員として出世の道を歩むのが文系出身者の夢じゃないでしょうか？

筆者の企業はおそらくIT系の企業ではないでしょう。なぜならIT系企業では、優秀なエンジニアは社内SEなどにはならず、製品開発をするはずだから・・・

内容としては、エンジニアの道ではなく、まるで総務人事の出世術です。企業の幹部は、最先端の技術なんて疎くなっているから、現役バリバリ人の言っていることがわからないから、その人たちの通訳になれ、その人たちを統制をする、と言った内容に近いです。決して新たなコンセプトでもなんでもなく、あまり価値のない評論だと思います。「多くの大手企業で高く評価されるソフトスキル」というタイトルならばいいですが、これはIT業界では評価されません。

基本は、システム部内ならば専門用語をただしく使い、エンドユーザー、経営幹部には、専門用語をむやみに口走ったりせず、相手のレベルに合わせて話すことです。それがソフトスキルだと思います。

また、ドキュメントの読解力や手順書を書く能力は大事だと思います。特にデータ移行の失敗などは、このスキルの不足によるものが多いです。またその前提となる基本的なIT技術を知らなかったりすることが多いのです。今ならば、インターネットでわからないことがあったらすぐに調べることができるのですが、そういった当たり前の努力を行わない人が中高年では多く、単に経営幹部の犬になっている人が多いのではないでしょうか？

この筆者は経営幹部から気に入られているから、いくらでもお金を引き出せるし、ベンダーに金を積めば、なんでもやってくれるはずなので、これも一つの道かもしれませんが・・・　IT業界にお金をばらまくという観点からは、IT業界に非常に貢献しているのかもしれません。

以前からjQueryには興味を持っていたのだが、この歳になって、社内の業務アプリには使うのには、ちょいと派手というか、遊んでいるというか、なんか恥ずかしいものがあって使わなかった。それでも、エンジニアとしてはjQueryは使ってみたい技術である。お気づきの通り、本サイトのトップページにjQueryを入れ込んだ。

人気のある技術だけにjQueryに関する本、サイトはすでに沢山ある。しかし、何の技術を実際のWEBサイトに取り込むのかとなると悩んでしまうのです。クリックして画像や文字が動くというのは、本来見てもらいたい、読んでもらいたいというサイトの趣旨から外れている。ゲームサイトではないし、ゲームサイトを今さら作ってみても、ゲームソフトの専門家ではないのだから、いいものができるはずない。

「何か装飾的なものであって、動きのあるもの」という趣旨でjQueryを取り込むのがいいのではないか？本サイトは技術的内容のサイトであるから、装飾性のあるIT技術として読者に感じてもらえればよいのではないか？まあ、今までレガシーなサイトと言われ続けたので、それに対する反動ということかな。

いきなりトップにイメージギャラリーのようなものが出てくるが、よくある例題としては、サムネイルをクリックしたら拡大した画像が出てくるものだ。しかし、技術サイトで、わざわざ読者が画像をクリックしてくれるだろうか？そんなわけで、自動で画像が入れ替わるイメージギャラリーを作った。画像自体は何でもいいのだが、著作権の関係で、自分で取った写真にしてみた。花の写真で、技術とは関係ないのだが、家の庭やバルコニーを花で飾るように、ホームページを花で飾ってみたわけだ。

hover、つまりマウスオーバーで効果は、ただ、動く変化するだけではなく、背景画像とか背景色、フォントにはこだわったほうがいいな。へたな装飾はダサく見えるものだ。

jQeury入門に関する記事などでは、CSSに精通していることが前提などと記載されていることが多いが、私の場合は、表のフォントの調整などでしかCSSは使ったことがなかった。CSSをちょっとでも使ったことがあれば、調べながらでもjQueryはできる。ただし見栄えのいいものを作るにはCSSの知識とかいい背景素材、ボーダーの適切な配色など美的センスが必要(私の美的センスは決しておすすめできるようなものではありませんが・・・)。HTMLは前提条件として知らないとだめです。

などを先に覚えておくと便利だ。サンプルコードなどで、$("ｐ")　などのセレクタで書かれていて、自分のサイトにそのサンプルを適用したら、すべての<p>タグに効果が適用されてしまう。それでは困るのでidセレクタやクラスセレクタを使い、対象オブジェクトを限定するわけだ。単にjQueryの効果を自分で楽しむｔのと、インターネットで公開して見てもらうには、コンテンツの内容に対して、何の対象に効果を与えるかが課題になるのだ。
その意味で、クラスセレクタを使いjQuery効果を与える対象オブジェクトを限定するなどの工夫は重要だ。

サーバーを仮想化、プライベートクラウドの構築などで、サーバーを集中統合する動向が活発化している。最近の通信業者のWAN帯域も手頃な契約価格でも十分広くなっている。しかし、そこには落とし穴がある。データセンターから近い拠点からの通信は円滑に行われるが、データセンターから遠い拠点は同じ帯域のWAN契約でも通信速度はTCP/IP通信では低くなることがあり得る。

データセンターから近い拠点のpingレスポンスタイムと遠い拠点のpingレスポンスタイムは違う。特に関東と関西以西間でのpingレスポンスタイムは非常に大きい。これは、データを送ってから、送信先からACKが返ってくるまでに時間がかかるということを意味している。以下の記事では、WindowsXPではデフォルトのTCPウィンドウサイズ(一回のデータ送信量)は64KBであることが記載されている。仮にデータセンターを遠隔地の拠点のpingレスポンスタイムが50ms であるとすると、通信速度は、64K * 8 /0.05 =　10.24 Mbps が上限となってしまう。WindowsVista、Windows2008移行では、可変TCPウィンドウサイズなので、この上限は回避できる。まだ、試したことはないのだが、WindowsXPでもレジストリを追加することにより、TCPウィンドウサイズ大きさを変えられるそうだ。
　

まだ多くの企業ではWindowsXPが使われているが、プライベートクラウド構築には、Windows7、Windows2008にクライアント、サーバーを整備してから行った方がよろしいだろう。

WindowsXPのウィンドウサイズというと、アプリケーションの画面の大きさのことかと思ってしまうのだが、実際にTCP/IPのヘッダにはウィンドウサイズという項目がある。　

副問い合わせについては、レスポンスが遅くなるなど気にされている方が多いそうだが、SQL　Serverに関しては、そのようなことはないと思う。むしろDBですべて処理をしてしまった方が、アプリケーションサーバーとの通信が少ないので、システム全体としては効率がよいのではないかと思う。もしレスポンスに不満があったなら64ビットOSを使い、メモリを十分に搭載することを薦める。

ある案件で、ASPプログラム内に以下のようなSQL文を書いた。このSQLは、

a　得意先マスタ
b 今月未出荷の受注金額
c 前年の売上金額
d 今月出荷済みの受注金額

を得意先別に一発で一覧できるものだ。副問い合わせの受注データの抽出条件をプログラムでリアルタイムに変えることができるのがミソだ。

SQL = "select a.得意先コード, b.月間販売予測, c.前期実績,d.今期実績, a.得意先名 from ("
SQL = SQL & " SELECT 得意先コード,得意先名 FROM 得意先"

SQL = SQL & " GROUP by 得意先コード,得意先名"
SQL = SQL & " ) a"

SQL = SQL & " Left Outer Join ( SELECT 得意先コード,SUM(販売額) AS 月間販売予測 from 受注伝票"
SQL = SQL & " where (得意先コード is not null)"
SQL = SQL & " And 出荷日 >'" & Now & "'"
SQL = SQL & " And 出荷日 <'" & EndDay & "'"
SQL = SQL & " GROUP BY 得意先コード) b"
SQL = SQL & " ON a.得意先コード = b.得意先コード"

SQL = SQL & " Left Outer Join ( SELECT SUM(販売金額の合計) AS 前期実績 , 得意先コード FROM 前年売上"
SQL = SQL & " WHERE 月=" & Tsuki & " GROUP by 得意先コード) c"
SQL = SQL & " ON a.得意先コード = c.得意先コード"

SQL = SQL & " Left Outer Join ( SELECT 得意先コード,SUM(販売額) AS 今期実績 from 受注伝票"
SQL = SQL & " where (得意先コード is not null)"
SQL = SQL & " And 出荷日 >='" & StartDay & "'"
SQL = SQL & " And 出荷日 <='" & Now & "'"
SQL = SQL & " GROUP BY 得意先コード) d"
SQL = SQL & " ON a.得意先コード = d.得意先コード"

※注意　本例題は抽出条件が日付型に限定されてています。しかしSQL文をプログラミング言語により合成する場合、SQLインジェクションの危険性があります。使用するプログラミング言語の指示にしたがって脆弱性をなくしてください。

以下のようなエラーが1週間に一回ほど発生する。このバージョンになってから、バックアップLANを使う場合、ジョブの「ネットワーク」の、ネットワークインタフェイス、サブネットにバックアップLANを指定し、「このネットワークインターフェース、プロトコルまたはサブネットをバインドできない Remote Agent には、利用可能な任意のネットワークインターフェース、プロトコルまたはサブネットを使用する」のチェックをいれる。

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

最終エラー: 0xe0000f02 - メディアサーバーがリモートコンピュータに接続できま

せんでした。リモートコンピュータは選択されたサブネットに存在していない可能

性があります。代替ネットワークインターフェースを試行するか、または Backup Exec で利用可能なネットワークインターフェースを選択してください。

このエラーについて詳しくはリンクを参照してください。V-79-57344-3842

バックアップ機リプレースのため今までトライしたことがない、BEのExchageリモートエージェントのインストールをやってみた。Exchageがクラスタ構成でバックアップLANを利用してバックアップをしている。

①　BEの選択リストには、EXCHANGEの実機のサーバー名が出てくるのみで、仮想のクラスタマシン名が見えない。オンライン状態のEXCHANGEのリモートエージェントで公開のタブでバックアップサーバーのバックアップLANアドレスを追加することで、仮想のクラスタマシン名が選択リストに公開された

②　それでも仮想のクラスタマシンの配下にInformation Store が選択リストに見えてこない。マニュアルをよく読むとEXCHANGE管理ツールのインストールが必要だとのことで、それをインストール。それでもInformation Storeが見えてこない。翌日EXCHAGEサーバーと同じレベルのロールアップを適用したら、古いバージョン(BE11d)のリモートエージェントではInformation Stroreが選択リストに見えていることを確認。

③　再度、BE2010R3のEXCHANGEリモートエージェントをEXCHANGEにインストール。またInformation Strore が見えなくなった。

結局、BEのサービスアカウントをアクティブディレクトリでExchange Organization Administrators Groupに所属するように設定することで選択リストにInfomation Storeが見えていることを確認。BE2010R3のメニューの「ネットワーク」-「ログオンアカウント」の「ログオンアカウント」の管理画面で「システムログオンアカウント」というものがあるが、これがデフォルトではBEのサービスアカウントになっている。最近のBEではこのシステムログオンアカウントがExchange Organization Administrators Groupに所属しないとEXCHANGEがバックアップできないらしい。

インターネットで英語の情報まで調べて、それらしき情報を入手して、確認のためサポートに連絡したのですが、サポートの検証でも当初はInformation Storeが見えないとのことで、サービスアカウントをExchange Organization Administrators Groupに所属して検証してくれとの依頼をしたほどで、結構苦労しました。

「実はオブジェクト指向ってしっくりこないんです！」から2年

といっても、最近 VMware ESXi5 を購入してから、仮想サーバー移行のことばっかり考えている。まったくプログラミングのことなんて眼中にないのだ。プログラミングなんてバグが見つかれば直せばいい程度だけど、サーバー移行の失敗はサービス停止に至ることもあるので深刻だよ。

インターネット上ではOOについて、「フレームワーク技術」とか「疎結合」とかいろいろな能書きを論じている日本人がいるが、結果として世界的につかわれているクラスライブラリを作った奴だけが偉そうな事を言っていいってことだよ。それが「再利用」ってことじゃん。

ってなことで、あんまりプログラミングなんて足どっぷりつかっても時間の無駄。いま面白いのはインフラだよ。

vCenter Converter Standalone5.0を使って、ESX3.0.2からESXi5.0へのV2V変換をしても、「選択したマシンのハードウェア情報を取得できません」というエラーが出てしまう。国内のサポートを頼ってもあてにならなかったので、しぶしぶ英語の VMware Communityサイトで質問したところ以下のような回答が得られた。これで解決です。

[NEW] On ESX 3.0, you cannot select a managed source because querying the source information fails Selecting a managed source on ESX 3.0 fails while querying the source information. The reason is that ESX 3.0 does not support encrypted data transfer.

1.Open the converter-worker.xml configuration file. It is usually located in C:\ProgramData\VMware\VMware vCenter Converter Standalone folder.

3.11 Ya Ya あの日を忘れない

　私は実は昨年の2月、つまり震災の前月に　東京スカイツリーでクラウド・コンピューティング　というコラムを書いている。

「毎年のように、日本ではどこかで大地震が起こる。関東大震災が起こってからしばらく立つが、もうそろそろ東京直下型地震が起こってもおかしくない。もしかしたら、数秒後に起きるかもしれない。それにもかかわらず、東京スカイツリーの建設を決定したことに、現代の建築技術がいかに優れたものであるかを感じる。」

・・・　と、私は東京スカイツリーに代表される優れた現代の建築技術があれば大地震の災から逃れられることを述べた。ある意味、地震が単なる大きな振動だけのものであれば、これは当たっている。しかし一年前の災害では、「揺れ」の問題だけではなく、東北北部から千葉まで非常に広い範囲で壊滅的な津波の被害を受けたことが、まったくの想定外であった。電力不足がもたらした計画停電は、我々社内SEはシステム管理体制を大きく見直す転機となった。

■　地震が起きた当日の話

　一発目の大きく長い揺れの後、サーバー室のラックが倒れていないことを確認し、各拠点に電話をした。しかし電話が通じない拠点があったのだ。その拠点の近隣市町村のホームページはすべてアクセスできない。また、その拠点のサーバーにping してみても応答がない。夕方になると歩いて帰宅する人が道にあふれている。また帰宅をあきらめてアルコールを飲みだす人もいた。結局私は帰宅をあきらめ、会社で一夜を過ごした。翌日はターミナル駅までは電車が運行していが、ローカル線は動いていないので、かなりの距離を歩いて帰宅した。穏やかな春の日だったのが幸いだった。

■　その後・・・リスク回避のユーザー企業の動向

　あれから一年、お金を銀行に預けると同様に、システムをデータセンターに預けるのが一般的になりつつある。しかしデータセンターへのシステム作業には以下のようなリスクがある。

　　　　①　ネットワーク体系を変えたことに起因する障害

　　　　②　結線ミスに起因する障害の発生

　　　　③　運搬中の機器破損

　　　　④　IPアドレスの設定ミス

など・・・。自然災害から守るためにしたデータセンター移設が、うっかりミスによる人災にならないように・・・気を付けてください。またデータセンタービジネスも、立地条件がよく、発電機設備などがなければ、利用者の獲得は難しく、サーバーの集積度も驚異的に向上しているので、莫大な投資が回収が大変だと思います。１００年は持つデータセンタービルを作っても、20年後のサーバーは今のノートパソコンの大きさになってしまいガラ空き状態！なんてことは十分にあり得ますよね（笑）。

「部品間の疎結合とは、部品（例えばクラス）と別の部品の間での通信、平たく言えば部品Aから部品Bの某メソッドを呼び出すことを、徹底的に減らすと言うことです」

とこの記事には書いてあります。このようなことがオブジェクト指向技術で可能なのか？と疑問を抱いてしまうのです。クラスAからクラスBのメソッドを何回か呼び出している。それでは、クラスAからクラスBのメソッドをインタフェイスを通じて呼び出したところで、ただたんにメソッドの呼び出しという紐が長くなっただけで、結合度が減るわけではないのです。

「具体的には、あるJavaクラスでprivate宣言したメソッドやフィールドは、たとえサブクラスであってもアクセスできません」

この一文は、ただ単にアクセスできる可能性をなくしているだけで、本当にサブクラスからアクセスが必要な場合は、何の意味も持ちません。オブジェクト間の通信を減らすということと、オブジェクト指向の実装技術は関係がないと思います。

この文章の疎結合論は説得性に欠けるものがあります。もし筆者が自己の主張が正しいと思うのなら、もっとわかり易く論じて欲しいものです。この書き方では、単に「privateでよいものはpublicにするな！」という程度にしか解釈できないのがもっともだと思います。

私どものような実践でアプリケーションを開発している者としては、WEBアプリケーションは非常に画面ごとの独立性が高く、QueryStringやsession変数を使わなければ、WEBページ間のデータの受け渡しができないことを知っています。WEBページごとに開発することは、ユーザーにとっても開発者にとってもわかりやすく、かつ修正などのメンテナンスもしやすいのです。ですからWEBアプリケーションは疎結合であるといってもいいかもしれません。実際にVisual Studioというフレームワーク環境を利用すると、WEBページごとにクラスができあがるのですから・・・

むしろオブジェクト指向の疎結合というものは、以下の記事のような例がいいと思います。

オーバーライドによって、オブジェクトをカスタマイズしています。オーバーライドの処理は、派生クラスの中に書かれていて、基底クラスとは分離しています。オブジェクト指向においては、このようなコアとなるコードとカスタマイズコードとの分離が疎結合だといえるかもしれません。それによる利点は何か？それは、コアの部分だけ作っておけば、ディストリビューターが、オーバーライドによりカスタマイズコートとなる派生オブジェクトを次々に作ってくれることです。純粋な技術論だけでなく、ビジネス的な成功を目的としているのです。

「ちなみに、staticおじさんに支配された世界での開発がどのようなものなのかについては以下のまとめが参考になります。
派遣PG時代の思い出 - Togetter」

なんてことが書かれてます。今のこの記事を読み返してみると、かなり失礼な記事ですね。私はこんな低レベルな開発手法を提唱しているものではありません。そもそも私は社内SEであって、SIerではない。多重請負問題はSIerサイドの問題で私には一切かかわりのないこと。こういう的外れな言いがかりは、名誉棄損行為じゃないの？

「機能ごとに似たようなコードをコピーし、独立したプログラムとして開発すれば、それぞれ独立して変更できるからメンテナンスが楽。
コピペを中心とした開発であれば開発担当のPGのスキルも低くてすみ、外注コストも削減できる。」

そんなこと、私はまったく提唱していません。むしろ、いろいろなクラスメソッドで共通のルーチンがあるならば、staticメソッドを使うとメンテナンスが楽だと提唱しているのです。この記事の著者、かなり勉強されているそうですが、本当に理解されて、自分の中で消化されているのか疑問があります。

「これは、StrutsやSpringなどのフレームワークで必ずと言っていいほど利用されている発想であり、依存関係逆転の原則（Dependency Inversion Principle、DIP）と呼ばれています」

この人がStrutsやSpringを作ったわけではないですよね。オージス総研がStrutsやSpringを作ったなんて話は聞いたことがないのです。人がやったことを自慢してもしかたなく、自分で適用法を考えなければ、技術者とはいえず、それは技術評論家でしかないのです。

「フレームワークの定義はユーザーがクラスや関数の中にコードを書き込むものです。それに対しクラスライブラリは、クラスが多数用意されて、ユーザーがそのクラスを利用するものです」

と説明されています。基本的な用語の定義なのすが、それを知っていれば、クラスライブラリを使うのが「依存」、フレームワークを使うのが「依存関係逆転」と簡単に推測できます。

一見レベルが高そうなことで、実は前世紀からある考え方を書けば、読者から尊敬されるだろうとでも思っているのでしょうか？この記事こそが、「上から目線」とでも言えるのではないでしょうか？

Visual Studioを使っている人ならば、WEBページを作成すると自動的に、

というクラスができ、その中にメソッドを書けば、WEBアプリケーションが作成できるということを経験しています。理屈ではなく、技術者は実際にものを作ることでVisual Studioというフレームワークの恩恵を得ることができます。また、C#の partial class は、開発環境とユーザーコードの分離という面で威力を発揮し、よりよいフレームワークを作っているわけです。

主人公の川島みな子は契約社員で、契約が切れてしまうのです。川島さんが作ったクラスは他のメンバーはわかっていないんです。平良くんなんて、知ったかオブジェクト指向信者もいいとろです。今後、川島さんの作ったクラスを使い続けるのは危険なのですよ。そこのところ、皆さん読めてませんね。

これも面白いツイートなのでメモっとく。前の記事によると、５年後でなく、もう既に、そうなのかもしれません・・・

オブジェクト指向しか知らないと、あと5年くらい経ったら「オブジェクトおじさん」的な立ち位置になって老害扱いされる。
　

「ここら辺はホントオブジェクト指向が中途半端にみんなが使う弊害なんだなーと痛感してます。正直この世にオブジェクト指向は、大半の人にとってはいらなかった。本気で。継承とか自作クラスで使う意義なんて9割9分ありませんよ。」

モジュール指向云々の後半の部分は、実際に著者に質問してみないとわからない意味不明のブログが、「オブジェクト指向を使えば再利用性が高まる」ということはよく聞くことである。何故か？については記載されていないことが多いことは確かだ。それだけで、世のオブジェクト指向本って胡散臭いものを感じる。

関数でロジックを実現したとする。しかし、それはそのプログラムだけとか、その人だけとか使う関数でです。しかし、いろいろな用途でいろいろな人が使う場合は、いろいろなパラメータを指定しなければならない。それらのパラメータを引数で指定すると、引数の数が非常に多くなってしまい、コーディングしにくくなるから。そんなアホくさい理由がオブジェクトを使えば再利用性が高まるという第一の理由です。あまりにもアホ臭くて、どこの著書にも恥ずかしくて書けなかったというのが本音かもしれません。C#などではデータベースアクセスオブジェクトのタイムアウト値を変えたい場合はプロパティを指定して変えますよね。

もうひとつの「オブジェクト指向を使えば再利用性が高まる」という理由はメソッドをオーバーライドすることにより、ユーザーの要件に合ったように、オブジェクトのカスタマイズができるという点です。もちろん、そのプログラムとか、そのプロジェクト、その会社しか使わないクラスライブラリで、オーバーライドは、あまり意味のないことなのですが・・・そのメソッドのソースを書き換えればいいのです。

　今更ながら教科書的な内容にもかかわらず、これだけ読んでくれる人が多いのはasaiさんが人気があることの証拠かな。

>intやfloatといった基本型の値だけでなく、文字列、日付、注文書といったさまざまなオブジェクトを利用することで目的に応じてあらゆるデータを変数から参照したり、メソッドのパラメータや戻り値としてやり取りできるようになります。

>さまざまなデータを扱えることの便利さを理解することが、staticな世界を卒業する最初の一歩として重要なのではないでしょうか。

staticな世界を卒業する第一歩ではないと思います。非オブジェクト指向プログラムから脱出する第一歩なのです。実際私は以下のようなstatic関数を愛用している。

//ドロップダウンリスト表示メソッド
public static void DropDownBind(DropDownList ddl,string Table, string Field)
{
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・

}

static関数の引数にドロップダウンリストオブジェクトを使用しているのだ。これにより、データベースから読み込まれた値がドロップダウンリストの選択肢となり初期化されます。

asaiさんの世界と私の世界は、クラスを作るか、クラスを使うかの紙一重のことで、オブジェクトを型の拡張としてとらえ、関数の引数やリターン値に有益につかいこなすことが、強力なプログラミングテクニックの鍵だと思います。私がなんで、構造体のような、しょぼいクラスも作らないのか・・・それはC#ではDataTableのようなクラスがすでにあるので、それでデータの受け渡しができるためなんです。

asaiさんのオブジェクト指向に対する深い造詣には感服しますが、わたしはどうもプログラミングというものは、実践で役に立つのが重要で、哲学や思想というものを持っていません。子供がおもちゃを動かして遊ぶのと同じなのです。この記事で出てくる参照という考え方もC言語のポインタと同じで、コンピュータなら同じアドレスのメモリを参照すれば同じものが見えるという、年寄にとってはあたりまえのようなことなのです。

オブジェクト指向は、端的に言えば、「部品化指向」ということです。いちからプログラミングするよりも、クラスライブラリで部品を揃え、それを使った方が数十倍開発効率がよくなるよ、ということです。状態を保持する部品は、インスタンス生成（つまりオブジェクトを作ること）し状態を保存するメモリ領域を確保する必要があります。実はこの「状態」というものがメンバー変数です。メンバー変数がないクラスのメソッドはstaticです。つまりインスタンス生成する必要がないし、オブジェクトなんてないんです。

>1. 使われるローカル変数をすべてメソッドの最初に宣言する。

確かにこれはやる。プログラムの途中に int i とか　int j　なんて宣言があると落ち着かない。メソッドを各最初の段階で、どんな変数を使うか頭の中で考えてからコーディングする。たまに変数が想定外に必要になったときに途中でローカル変数を宣言したりする。どうもロジックと宣言が入り混じっているというのは、行き当たりばったり的で落ち着きませんなぁ・・・

>2. ローカル変数の宣言時に空文字("")や新しいオブジェクト(new Xxx())で初期化する。その後にすぐ別の値をセットする。

通常の変数型の宣言ならば別に初期化する必要ないんじゃない。new でインスタンス生成の場合は必要ですよね。レガシーかレガシーにかかわらず、場合によりけりじゃないですか？これは意味不明でした。

>3. メソッドの戻り値がすべて成功・失敗を表す 0 か -1 になっている。

そんなアホな！何のためのメソッド、何のための関数なのですか？この人昔はグローバル変数で値を返してたなんて言ってますけど、それはこの人周辺だけの話だろ。

>4. 複数のデータをまとめて扱う際は毎回配列を使う。配列の上限数はありえなさそうな数を指定する(1000とか)。

C言語ではそういうの結構あったな。C#ではほとんどそういう配列の使い方って見かけないな。

>5. 基本データ型(stringやint)と配列だけでデータ構造を表現しようとする。

この人、クラスを使うことを推奨しているみたいだが、C#はDataTable, DataSet, DataRow を使うほうが効率的だろ！

これはかつての名残としてよく使う。GUIで、テキスト、ドロップダウンリスト、ラベルなど数十項目あると、なんのタイプのオブジェクトかすぐわかるようにしないと、やっかいですよ。ハンガリアン記法は役に立つこともあるんです。GUIオブジェクト以外は、別にハンガリアンでなくてもいいんじゃないでしょうか？

>7. クラスのフィールド変数をグローバル変数のように利用する。

この手の人ってレガシーな人ではなく、多数の自称オブジェクト指向プログラマーの特徴ですね。フィールド変数の濫用ということで私はフィールド変数を使わないstaticメソッドをお薦めします。

>8. 配列やリストを毎回forループで処理する(例: for (int i = 0; i < array.Length; i++))。

必ずしも悪いとはおもえないのだが・・・　forearch を使うか　for , while を使うかは場合による。

>9. クラスやクラスメンバの可視性を意識していない(privateメソッドがpublicになっている等)。

これは、その人がレガシーかどうかの問題ではなくて、その人が怠慢であるかどうかの問題だろ。

>10. 変更履歴をコード中にコメントとして残す (ADDやDELみたいなコメントがたくさん付いている)。

程度問題だろ。普通は残す。ただそれが沢山あると、バグフィックスや仕様変更が何回も行われたことになるので、プログラマーか上位レベルの設計者が悪い。レガシーかどうかの問題ではない。

略さなくても、Getナントカ、とか Setナントカ　なんていうメソッド名って安易だと思わんか？逆にいい変数名、メソッド名の命名方法があったら自ら提案してもらいたいものだ。

結局、この記事読んでいて、プログラマーの世界なんて、どうでもいいセコいことをネチネチこだわっているように思えてきた。筆者の言っていることは確かにそうすれば、見かけだけ古臭くないコードになる。だからと言って、それが数倍以上のパフォーマンスや生産性を生み出せるものとも思わない。

VMware vSphere コンソールを開いても黒画面のまま。Could not create lock for vmware-vmkauthd　というエラーメッセージが画面上部に表示される。

を読んで、/var/log の使用率を確認したところ、100%であった。TTY_00000000.log.1" ～ "TTY_00000000.log.14"のファイルを削除したら。無事コンソールが開けるようになった。

SQLサーバー　単純モデルでもトランザクションログが増える

SQLサーバーでデータ量が５GB程度なのにトランザクションログ領域が１５GB以上、しかも本来トランザクションログ不要な単純モデルのデータベースを発見し唖然としてしまった。どうも単純モデルでも更新データ量の多いSQLコマンドを実行すると、それらのログがトランザクションログファイルに書き込まれるようである。

DELETEでテーブルの全データを消すようなものは、TRUNCATE　TABLEコマンドに変えればこれは解決する。INSERT INTO テーブル　 SELECT ... やSELECT　INOTO　テーブル　などのSQL文の場合はやっかいだ。一定量のレコード追加をループで実行するストアドプロシージャを作っている人もいるようだ。

BULK INSERT テーブル　 FROM '\\サーバー名\パス\タブ区切りテキスト’"
WITH (FIELDTERMINATOR='\t', ROWTERMINATOR='\n', BATCHSIZE=10000)

というBATCHSIZEを指定した　BULK　INSERT　でトランザクションログの増大を抑制できないかどうか検証している。このBATCHSIZEというもは、指定されたレコードずつINSERTを行うものである。

OFFICE2002からOFFICE2010にバージョンアップする件で、今ユーザーがつくったマクロ評価を行っている。現在、以下のような問題点が発生している

①　今までのカレンダーコントロールが使えない。OFFICE2010では、テキスト入力については、型を日付型にすれば勝手にカレンダー入力ができるので、今までのカレンダーコントロールを削除すればよい。

②　おそらくこれは、Windows7特有の問題かもしれないが、差し込み文書のワードをリンクすると、リンク元の文書の裏に、「この文書を開くと、次のSQLコマンドが実行されます」の警告がでる。ユーザーにとってはフリーズしたと同じ状況になる。

③　FileSearchオブジェクトが使えなくなった。ファイルの再帰的検索はオーソドックスなVBAプログラムを書かなければならない

④　ACCESSでコントロールリソースのレコードセットに値をセットするような凝ったものがあった。現象としてはハイパーリンク型のデータをフォーム表示した場合にリンク先に飛んで行かない。対応としては、Set cnn = CurrentProject.Connectionを Set cnn = CurrentProject.AccessConnectionに変更する。インターネットで調べたものだが、英語の文献にとにかくコントロールリソースのレコードセットを使うにはこのような書き方をすると書かれてあった。

⑤　エクセルのシートに対してクエリを実行しているもので、｢2147217833：指定されたデータ量がフィールドサイズを超えています。データ量を減らし、挿入または貼り付けを行ってください｣のエラーが出るものがあった。このクエリって SELECT * FROM 範囲　のような書き方をしているもので、まともに範囲の指定がされているかどうかがあやしあった。WHERE キー　IS NOT NULL を追加して、必要以上にレコードを取得しないようにしたら、このエラーは回避された。

⑥　エクセルのシート名に空白スペースがあり、それをACCESS2010にリンクする。それでクエリを作るとクエリが壊れる

⑦　フィールドにTrimなどを使用しているクエリを結合するとエラーが出る。

あとEXCEL2010で保存時に互換性チェックの警告がでるもの。このようなEXCELファイルを開いて書き込み保存しようとすると従来のマクロでは止まってしまう。

staticおじさんとまつもとゆきひろ、どうして差がついたのか....慢心、環境の違い

はっきり言って、まつもと先生と比較されること自体光栄なことなんですけど（笑）

今さら新しいコンピュータ言語を創出すると言っても、企業活動ではあまり利益が期待できませんし、多くの大学の研究活動でも、新しいアルゴリズムが実現できるわけでもないので、否定的で足をひっぱられることがほとんどでしょう。たぶん、まつもと先生の大学は自由な雰囲気だったのだろうし、まつもと先生が根回しがうまいのでしょう。

私は実践的なシステム構築、効率的な手法を追求する企業人です。まつもと先生とは、住む世界がもちろん違いますよ。慢心ではなく、開き直りです。そもそもプログラミングといものは、必要以上に理屈こねるものではなく、シンプルに書いたほうがいいでしょう！ということです。

前日引用したリンクの記事で、さらにリンクされているこれ。

まあ、こういう考え方もあるのかあ・・・・2006年の記事ですが、今だにVBやってる人、.NET できない人いますよね。

実際のことろVBを使っている人はVBプログラムのメンテナンス作業に携わっている人が多いので、VBから足が洗えない人が多いのではないか？おっさんが今さら.NET プログラミングを学習しても結局若い人にはかなわないっってことあなあ？

おっさんの私の場合、当初VS2003が出たとき、レガシーASPに比べても、かなり使い勝手がわるいものだった。ちょっとは勉強したが、実践では使わず。

VS2005が出たとき、これは使いやすくなった。実際に実践で使い始めた。.NETってGUIのコーディングって、あんまりVBと大差ないですね。しかしデータベースアクセスのADO.NETがやたら難解です。これが.NETに移行できない一番の原因だと思います。それにもかかわらず、多くの講師さんはクラスとか継承とかオブジェクト指向の教育ばかりに力点を置く。継承なんてクラスライブラリでも開発しないかぎり使わないです。使う必要性が感じられないのに教えるからいつまでたってもマスターできないんです。

クラスのコンストラクタに処理を書いて、publicなメンバー変数に結果を書き込んで、呼び出し元のクラスに値を返す、なんていうコードを書けばオブジェクト指向プログラマー！と自称している人もいるかもしれません。しかし、たかがそれだけのことで、.NETが実践で使えるほど甘くないですよ。そんなクラスはCOBOLの関数と変わりませんよ。 .NET FRAMEWORK のライブラリを上手く使いこなし、多くのアプリケーションを効率的に開発してこそ、いいエンジニアと呼べるのではないでしょうか？

オブジェクト指向教育、はっきり言ってくどすぎ。Visual Studio.NET ではWEBページやフォームを作ったら自動的にクラスができ、その中に関数を書けばよいのだから。それほよりもADO.NET を使ったデータベースアクセスのサンプルコードを掲載した本サイトを見たほうが、実務で.NETが使えるようになる。

確かに、リンクの意見やコメントのようにVB2.0のときは、まともな情報処理教育を受けていないひとがVB組んでいる時代もあったあ。素人の人が作ってもとりあえず動作してしまう。しかし、それは、かなり趣味のわるいコードで、品質に問題がありましたよ。私は素人が行うエンドユーザーコンピューティングについては賛成ですが、すくなくとも、Σの計算をするコードパターンやサブルーチン（関数）、ローカル変数とグローバル変数ぐらいの最低限のプログラミング原則は知らないとまずいと思います。この最低限のことって、別にシステム関係の仕事をした人でなく、趣味でちょっとでもプログラミングをしたことのある人ならば、すぐわかるはずなんです。

実はローカル変数とグローバル変数、オブジェクト指向プログラミングをやっている人には、そんなの低レベルなこと聞かなくて結構と思うかもしれません。しかし、メンバー変数で、そのクラス内ではグローバル変数と同様、クラス内のすべてのメンバー関数からアクセスできてしまいます。メソッド内のローカル変数を使わずに、すべてメンバー変数で処理してしまっても、動作しますが・・・・やっぱ、それはやめてほしいのです。

私はCOBOL自体は扱ったことがないが、COBOLベースの言語である、R/3のABAP言語を使ったことがある。以下の記事を見つけた。この記事の筆者、かなりCOBOLについて誤解していて、よっし～さんに反論されてしまう・・・

(ognacの知る少ない例ですが)企業の電算室の実体は,とてつもなく,旧態依然としている箇所があります。
COBOL言語はまだ大手を振って存在し, COBOL的発想のシステム作りが脈々と続いています。
　(代表的な例としては) COBOL言語は,広域変数しかないので, ローカル変数の概念がわからない。
サブルーチンは Perform( 旧Basicの gosub的なもの ) しかなく,関数化という発想も乏しい。

2006/09/15 19:49 よっしー

SQLですがプリコンパイラを使用すれば使えないSQLスクリプトはありません
当然SUMだって使えます
## INSERT,UPDATE,DELETE なんて当たり前ですよね

因みに最新のCOBOLでしたらクラスも使えます
当然オブジェクト、メソッドもあります
変数はローカル変数・・・
　

もちろんABAPでも関数にローカル変数を使えるのです。だからといって、やはりC#はCOBOLやABAPに比べてDataSetやDataTableのような便利なオブジェクトを使えるし、これらのオブジェクトを関数でリターンさせることができる強力な言語ですのでお奨めです。

また「実はオブジェクト指向ってしっくりこないんです！」では、すべての変数をstatic宣言しろなんて書いてないですよ。そんなこと書いたら、そんなヘボな記事では反論どころか読む人もいないでしょう。本サイトのASP.NETのサンプルコードを見ればわかるように、関数内でローカル変数の宣言をしたり、インスタンス生成することを積極的に行っています。static変数を使うのは限られたものだけですよ。逆にstatic変数の利用を限定的にすることにより、static関数を幅広く用いることができます。static変数の書き込みを行わなければスレッドセーフになりますので・・・

Visual Studioの場合WEBアプリでもWindowsアプリでもフォーム間で値を受け渡す方法がいくつか推奨されていますが、static変数でフォーム間で値を受け渡すというのは、お奨めできませんね。特にWEBアプリではご法度です。

ってなわけで、私は関数を好むので、必然的にローカル変数を推奨する立場です。その辺、誤解されている方がいましたら、当サイトのASP.NET のコードを見てください。

Windowsフォームの場合は、以下の記事のように、ある程度、コンストラクタなどのオブジェクト指向の知識がないとフォーム間の値の受け渡しに苦労することになります。

それから私の書く記事は、社内SEに限定されたものではないですよ。IT全般のエンジニアに参考になる記事です。

●　2011年8月24日のメモにあるように、static変数なのかstatic関数なのか、区別して記事を書いてほしい。多々単にstatic, static と騒ぐな！

●　私は、グローバル変数、static変数の使用は最低限が望ましいと思っているし、そんなことは言わなくても世間のプログラマーの常識だと思っている。極力、いやむしろ全部、ローカル変数にしてこそ関数の威力が発揮するのだ。だから私は関数の利用を薦めている。古典的な考え方かもしれないが、プログラムというものの本質的な性格上、この原則に反するとメンテナンス上、大変な苦労を強いられる。

スレッドセーフについて、よく説明してあるサイトを見つけた。かなり世間的にレベルが高いと思われてる人でも、staticメソッドはデータが共有されるから、WEBアプリケーションのようなマルチメソッドで動作させると問題が起こると信じているらしい・・・以下の説明を見れば、何がスレッドセーフなのか？なんで、ライブラリ関数のようなものでも使用して問題が出ないのかよくわかる。WEBアプリケーションの場合は、static変数使わずに、session変数やQueryString でページ間のデータ受け渡しをするのが原則ですから、よほど不自然なコードを書かない限り、staticメソッドで問題になるスレッド・アンセーフとなるケースはほとんどないですね。

static データ変数などを（lock 処理などをせずに）無造作に操作しているメンバメソッドは、マルチスレッド動作させた場合にトラブルが出る危険性がある。
ローカル変数しか操作していないようなメソッドは、マルチスレッド動作せても問題がない。（※ ローカル変数が参照型で、そのオブジェクトインスタンスを別スレッドからも操作しせてたらダメですが；）

一般に、マルチスレッドアプリケーションにおいて複数スレッドから同時に呼び出されたとしても問題が発生しないメソッドのことを、スレッドセーフなメソッドと呼びます。Java や .NET の基本的なクラスライブラリの多くはスレッドセーフに設計されていますが、すべてがスレッドセーフとは限りません。このため、安易にマルチスレッド動作アプリケーション（例えば Web アプリケーションや Web サービス）からクラスライブラリを使うと、トラブルが起こる危険性があるわけです。

とはいえ、.NET の中でも我々が普段使うようなメソッドについてはほとんどがスレッドセーフに作られています。例えば Int32 型のドキュメントを見てみると、すべてのメンバがスレッドセーフに作られている、と明記されています。このため、例えば Int32.Parse() メソッドなどを無造作に呼び出しても、トラブルは発生しません。

鼻をかんだチリ紙のオブジェクト再利用方法？であります！

　　　「穴のあいた靴下でボール捨てたらもったいないんです。まるめてボールで遊ぼうよ♪」
　　　「鼻をかんだチリ紙を捨てたらもったいないんです。枕にいれたらフッカフッカ♪」

　これはケロロ軍曹のオープニングの歌の歌詞！であります。

　今の時代のめぐまれた子供達に、このようなお金のかからない楽しみ方を人気アニメで伝えるのは非常に結構なことでござる！

　しかし、君は婦女子に、鼻をかんだチリ紙の入った枕で寝ることを薦められるか？これができる奴はグレートとしか言いようがない。

　昔の日本人はなるべく物を捨てないでリサイクルしていた。極端なところで、倹約家はチリ紙を買わない。子供の習字紙（もちろん墨で字がすでに書かれたもの）をとっておいて鼻をかんだもんだ。

　我々よく使うリサイクルの手としては、保守期限が過ぎた古いサーバーを開発用、検証用のサーバーに使ったりする。まめなシステム部員は故障して使えなくなった古いパソコンから使える部品だけを取り出して、その部品をリサイクルしたりする。しかし、そこまでするとあっさり廃棄して新品を買うのとリサイクルするための人件費どっちが高いの？と疑問を持つのだ。
　
　ハードウェアのリサイクルと同様、ソフトウェアのリサイクルという考えも昔からあった。昔っていうのは非オブジェクト指向言語の時代から。

　関数を作るたびにドキュメントを書くことと毎朝のミーティングで報告するなんていう規則が古くからある会社ってあるんじゃないの？カイゼンは世界に知られた日本企業の良い習慣ですが、「自分でコードをスクラッチから作らずに人の作ったものを借りてくれば合理化になる」なんていう改善提案は誰でもできます。どこの会社でもそういった改善提案を採用してしまうのだから、しぶしぶ、数十行の関数でも作ってしまったらドキュメントを作るハメになる。

　人の作った関数やクラスを再利用すれば、効率的に開発ができる！ただし、それは何万の関数やクラスの詳細仕様を頭に詰め込める人だろう。そのような特殊能力を持ったひとよりも、一般的なポピュラーなクラスライブラリだけを使って、スクラッチから驚くほどの生産性でプログラミングしてしまう人のほうがエンジニアとしてはクリエイティブで望まれる人材だ。

　「再利用」という言葉に惑わされるべからず。アメリカ人は雑巾なんて使わない。ペーパータオルをガンガン使い捨てる。クリスマスが終わったらモミの木がゴミ箱に大量に捨ててある。彼らが「再利用」なんていうこと自体が白々しく感じる。プロダクトライフサイクルという、しっくりこない大義名文をかかげ、一方的にOSの保守を打ち切り、結果としてジャンクPCを大量に生み出している。

　ソフトウェアを効率的に生産するのには、行き当たりばったりに人の作った関数やクラスを使いまわして再利用するのではなく、最初から、チームメンバーが共通に使えるクラスライブライブラリを採用したり、十分に構想を練って多くの人が使えるクラスライブラリを構築するのがよいのかと・・・

しっくりきてますか？６４ビットアーキテクチャ

　Windows2003の時代から64ビットOSをマイクロソフトはリリースしている。しかし、一昔前はもしインストールしたいソフトがあっても64ビットに対応するものが少なかったので、なかなか64ビットOSをインストールする勇気はなかった。しかし、最近になってからメモリを大量に搭載できるハードが当たり前になり、32ビットOSでは期待的なかったスペックを実現しようという動向が本格化している。

実のところ、いままでに64ビットOSを使ったことはあった。しかしそれは仮想環境でない実機であり、メモリは８Gほどしか搭載しておらず、メモリを使っているにもかかわらず、それはある特定のサービスプロセスがメモリーリークしているもであり、そのサービスを再起動するとメモリ消費が減るようなものだった。

　マイクロソフトのドキュメント管理システム Microsoft Office Sharepoint Server 通称MOSSを導入するときであった。既存のドキュメントを移行するのにMOSS独自の特殊な技術を要するため移行作業を業者に依頼したのだが、業者サイドも多忙のため、仮想サーバー上で64ビットOSを私がインストールしたのだ。MOSSにはドキュメント検索機能もあり、SQL Server も使用する。実際のドキュメント量で試用してみたところ、しっくりしないようなパフォーマンスしか出ない。全社員が使うようなシステムではないので、メモリは４Gで十分だと思っていたのだが・・・・

　しかたがないので、いったんSQL Server のサービスを落としデフラグをしてみたり、業者にインデックスの再構築の方法を聞いてみたのだが効果があまりない。悩んでみたあげくの解決方法はメモリを８Gや１６Gに上げてみること！仮想サーバー自体のメモリー量は、もともと多数のゲストOSを動作させることを前提に実装しているので数十GBとある。他のゲストOSで利用しているメモリ量はまだすくなかっため、MOSSのためにメモリを使用しても問題はないはずだ。いったんMOSSの仮想マシンをシャットダウンしメモリを増やして起動しなおした。そうしたら、「おお、早い！」

　ってなわけで、64ビットSQL Serverは最低でも８Gのメモリはあったほうがいいなあ・・・もっと規模が大きいシステムでは16G、32Gは必要だろう・・・なんてことを思うようになった。　

　その後MOSSの本番稼働はパフォーマンスの問題がなく、現在も健在に動作している。

　しばらくしてR/3で64ビットSQL Serverに移行するという案件があり、私は担当者ではないが、数回ミーティングに出席した。

業者さん：「パラメータは既存のR/3サーバーと同じものを適用します」

私：「64ビットSQL Server は多くのメモリを搭載しないとパフォーマンス出ませんよ」

業者さん：「本番稼働して、しばらくしてからボブ・サップさんチェックしてもらいます」

　本番稼働初日で私のいやな予感は的中した。マシンを新しくしたのにもかかわらず、実際に使っているユーザーから遅くて業務効率が悪化しているという怒りのクレームが来たのだ。私はタスクマネージャを見たてみた。こんなことは素人のパソコンユーザーでもわかる話である。物理メモリ量よりはるかに上回る数値をコミットチャージが示していた。明らかにメモリ不足である。幸いなことに仮想サーバー上でR/3を構築していたので、これは簡単にメモリ設定値を増やすことができた。メモリ増設後は、今まで頻繁に発生していたディスクアクセスが激減した！

　業者さんの説明によると、「ボブ・サップさんが推奨するメモリ設定しましたので・・・。」私は心の中で「そんなこと言うとボブ・サップさんにパンチ食らわされてノックアウトしちゃうぞ！」と思いましたが・・・
　

今日で九月も終わり。読書の秋ということで小話を書いてみた。

プロジェクト「忠臣蔵」

　君主、浅野内匠頭（あさのたくみのかみ）が江戸城中で吉良上野介（きらこうずけのすけ）を切りつけた事件で、君主切腹、赤穂藩お家取り潰しとなった。浪人の身となった元赤穂藩、家老大石内蔵助（おおいしくらのすけ）は暇をもてあましていた。毎朝、メールを見たり、ネットサーフィンしたり、人気ブログにコメントを書いたりする日々が数週間ほど続いていた。いつものように届いたメールをチェックしていたが、元赤穂藩家臣から以下のようなメールを受け取った。

[元家臣からのメール]

「大石さん、このような事態になったのは家老であるあなたの責任によるところが多いのではないでしょうか？　何故、殿に短気を起こさないように、事前に適切な助言をしなかったんですか？
幕府の政策としては、なにかと理由をついて、お家取り潰しにしちゃうのは、家老ともある大石さんならばわかってて当然ですよ。江戸幕府での言動でさえも最新の注意が必要だし、まして、刀を抜くようなことは、論外ですよ。何で、殿に『吉良をうまくかわせ』って助言しなかったの！！大石さん、責任をとって、我々の再就職口を探してもらえませんか？」

　家老にまでなった大石としては、しばらく毎日が日曜日の生活を楽しんでから、赤穂の地場産業である塩田経営でもしようかと考えていた。しかし、金のない下級の家臣にとっては、再就職口が見つからないと大変だろう・・・浪人の身になってから自分のことしか考えない。お家取り潰しってことは、会社倒産と同じで、もう同じ藩士としての絆はなくなったってことで、「再就職口は自分で探せばいいじゃん」と簡単に考えていたのだが・・・

　近隣の藩の家老にメールを出してみたが、どの藩も財政難で採用は無理とのこと。取引先の上方の商人もボディーガードとして家臣を雇ってくれないかとメールを出してみた。

[上方商人からのメール]　

「大石さん、今の時代ボディーガードは鉄砲が使えないと話にならんわ。いくら剣術ができるといっても鉄砲にはかなわへん！お侍さんはプライドが高いから、わしらの世界には合わんのや。江戸の新宿にシティーハンターってやつがいるだろ。あいつと互角にやりあえるならば、雇いますわ！」　

　大石は赤穂藩の家臣は忠誠心が高く優秀だと思っていた。しかし世間の見方は厳しいのを実感した。何か再就職口がないかと毎日ネットサーフィンしていた。諸藩のHPのリクルート欄はすべて閉鎖されていた。今頃武士には用がないってことか。結局癒しを求めて京都祇園の舞子のブログを見に行く。自分が書いたコメントに返事があったりすると一気にいやなことが吹き飛んでしまう。

そうこうしているうち、また元家臣からの一通のショッキングなメールが大石に届いた。

[元家臣からのメール]

「大石さん、この炎上ブログ見ましたか？『本来喧嘩両成敗なのだから吉良にお咎めがないのがおかしい』『浪人となった赤穂浅野家家臣は吉良に仇討をするべきだ』なんてことが延々と読者のコメントに書かれてますよ。私もバイト先の蕎麦屋の親父から『敵討ちやるんだろうな』なんて言われちゃって返答に困ってます。

　戦国時代ならともかく、今の天下泰平の世で敵討ちというのはナンセンスだな。元家臣の言うとおり、君主である殿が場所柄をわきまえずに刀を抜いたのがアホ。殿は我々家臣のことを全然考えてなかったってことなんだからなあ。そんな殿のために敵討ちなんてとんでもない。敵討ちってことは、当然殺人の罪に問われて死刑だもんな。

　なんとかして赤穂浅野家復活できないもんだろうか？大石は考えた。浪人となってからネットオタクと化している大石は、江戸幕府のＨＰに「相談・問い合わせ窓口」というものがあるので、そこに浅野家再興の嘆願書を出してみた。

　数日が過ぎても何も返事が来ない。そんな早く返答をくれるわけないし。何回も嘆願しないとダメだろうなあ・・・江戸幕府のＨＰをまた見てみると「よくある質問」というコーナーがあった。それを読んでみたら、なんとこんな質問と回答がすでにあった。

[質問]

お家取り潰しになって、再就職口が見つかりません。お家再興していただけませんでしょうか？

[回答]

一旦取り潰しになったお家は再興いたしません。再就職口はご自身で探してください。

　ゲロ～。大石は自分の考えはやっぱり甘かったのかと反省してしまった。そしてまた元家臣からのメールが届いた。

[元家臣からのメール]

「大石さん、この『ＩＴかわらばん』っていうニュースサイトみましたか？赤穂浪士敵討ちはいつか？なんて記事が載ってます。バイト先のおやじから『仇討ちの資金はだすから、もう来なくていい、あんた蕎麦屋には向いてない』って言われちゃいましたよ。このままでは、私も同士も生活できなくなってしまいます。最後に後世に残るような花を咲かせて散るしかないんじゃないでしょうか？」

　大石は、おいおい冗談かよ。とりあえず、このメール無視しとこうなんて思っていたら、またまた炎上ブログのコメントで、『大石、はよ～仇討せんかい』『腑抜け家老大石、武士として最低』などという自分を名指して非難するコメントがぎっしり書いてある！

よく朝、またいつものようにメールをチェックした。また元家臣からのメールが来ている。メールの送受信アドレスを見ると、自分がなんらかのメーリングリストに参加させられている。メールの内容を見ると仇討プロジェクトの計画書がエクセルファイルで添付されていた。

　　本仇討プロジェクトの執行責任者

　　　　家老　大石内蔵助

　メンバー

　　　　　堀部安兵衛、・・・・・

　自分を入れて４７名の名前が連ねて記載されていた。本人の承諾なしに執行責任者にするなんてありかよ！

　連日twitterで、『主君の敵を討たぬダメ家老』なんていう罵倒がささやかれてた。その後大石は家族、親戚からも「武士の恥さらし」と非難され、赤穂を追い出された。そして、他の浪士と共に江戸に向かい、しぶしぶ仇討を果たすことになる。自分は死刑になりたくなかったが、他の４６人が死ぬ覚悟で企画したプロジェクトなのだから成功して当然だよなあ。

　この仇討プロジェクトが後に「忠臣蔵」と呼ばれ、何百年も語り継がれるとなるなんてことは、大石は思ってもいなかった。

　　ＴＨＥ　ＥＮＤ

ファイルサーバーのデータ肥大は悩みの種だ。システム部としては、バックアップ時間の短縮、データ移行を簡素化したいので、なんとか容量を減らしたいところだ。ユーザーに不要なファイルや古いファイルを消せと促しても、なかなか真摯に対応してくれない。

というDOSコマンドで、特定のフォルダ以下のファイルの更新日がすべてファイル出力される。この出力ファイルをスクリプトで整形し、ＤＢにインポートする。さらに、このＤＢを検索するツールを開発すれば、古い更新日時のファイルや、容量の大きなファイルなどが検索できるようになる。

SQL Serverでリモートサーバーへのディスクバックアップの失敗する

　暑さ寒さも彼岸までと言われるが、例年より夜の冷え込みが厳しい。これは今年の夏暑い時期に悩まされた障害の話である。

　SQL Serverのコマンドで、BACKUP DATABASE というコマンドがある。このコマンド、テープだけではなく、他のサーバーのディスクにバックアップファイルを保存できる。中規模のデータベースには非常に便利なコマンドである。

　夜間バッチでこのBACKUP DATABASE コマンドを実行してバックアップを実行していたのだが、ある日から得体の知れない障害によりバックアップが失敗するようになった。SQL Serverのイベントログでは、

　　　　「指定されたネットワーク名は利用できません」

と記録されていたので、バックアップデータの経路をサービスＬＡＮ、バックアップＬＡＮといろいろ切り替えてみたり、ハブのポートを切り替えてみたりした。思考錯誤する内にバックアップの再取得ができるようになったが、また数日すると夜間バッチのバックアップが失敗する。原因がわからないので、もし症状が悪化してバックアップが取れなくなったら・・・非常に不安な日々が続いた。あくまでもネットワークの問題だと思い込んでいたのだが、どうしてもバックアップの再取得できないとき、バックアップ先のサーバーを再起動したらバックアップが再取得できた。

　それから、バックアップ先のサーバーのウィルスソフトやサードパーティソフトの再インストールを行っても改善せず、再起動後、数日でやはりSQL Serverのバックアップに失敗する。サーバーのハード障害が検知されたら自動的にメールが送られてくる仕組みになっているはずなのに・・・これは検知されないハード障害なのかもしれない。

　というわけで、サーバーメーカーのサポートに電話しみた。診断ログを送ってみたが異常なしとのことであった。この手のSQL Serverのネットワークバックアップについての障害については、インターネットで調べてみたのだが、世界中のＳＥが悩んでいるみたいで、原因はネットワークアダプタであったりすることも情報を私は事前に入手していた。そこでサポート員にネットワークアダプタに原因がないかどうか聞いてみたら、確かにドライバのバージョンが古いのでアップデートしてみろとのこと。

　さっそくネットワークアダプタのドライバをアップデートしてみた。しかし、その夜のSQL Serverのバックアップバッチは失敗してしまった。こうなると自力で調べるしかない！

　問題のサーバーのイベントログをじっとながめ、不可解なことに気付いた。それは、ディスクで「Write Back」と「Write Through」のモードが数時間ごとに切り替わっている。
　
　ハードの知識が少しでもある人ならば、

■「Write Through」はデータを書き込む際、そのデータをメモリとディスクに書き込むこと
■「Write Back」はデータを書き込む際、とりあえず、メモリにデータを書き、アイドル状態のときに、メモリ上のデータをディスクに書き込み整合性をあわせると

ということは知っている。Write Back のほうが効率はいいので、Write Through　モードに切り替わってしまうのは不可解だ。私は再びサポートに電話してみた。電話する前に私の主張をわかってもらえるかどうか疑問だったが・・・

　今度電話に出たサポート員は、「それはRAIDコントローラの交換が必要ですね」と言いあっさりと修理交換に応じてくれた。修理作業に来たエンジニアの調査によると、RAIDコントローラのバッテリーが毎日電圧低下で充電が行われているので、想定された部品交換が必要。Write Though モードに切り替わるのは、バッテリーの電圧低下により、電力のかかるWrite Backモードから自動的にWrite Thoughモードに変わる仕組みになっているそうです。

　要は携帯電話が古くなれば、バッテリーが悪化し、頻繁にチャージが必要になったり、使い物にならなくなってしまうことではないか！　RAIDコントローラを取り換えてから、そのサーバーはWrite Backモードを維持するようになり、SQL Serverのバックアップも確実に取得できるようになった。
　
　車でも車検というものがあるのだから、保守契約料金をしているサーバーなどは、内蔵バッテリーくらいのヘルスチェックはして欲しいものだ。

SQL Server2008R2へリンクサーバーのDBを使ったストアドプロシージャを移行

リンクサーバーの設定をしても、ストアドプロシージャでリンクサーバーのDBを使っている場合は「サーバーはRPCに対して構成されていません」というエラーメッセージが出る。その場合はリンクサーバーのプロパティをRPC、RPC出力をTrueに設定する必要がある。

LEFT等の関数でフィールドを加工している場合、COLLATEと呼ばれる照会順序を使うが、SQL Server 2008R2はSQL Server2000に比べ制約が厳しいようだ。COLLOATEに関するエラーが出た場合は、COLLATEの抜けがないかどうか確認しみることだ。

本日はカプセルホテルからの出勤となった。たいていカプセルホテル利用するときは夜遅くまで飲んだ時だが、今回は台風で帰宅が困難となったため。昨晩、カプセルホテルに電話をかけてらまだ空きが多いから大丈夫だって言ってたので、会社からカプセルホテルに直行。行ったら普段、カプセルホテルを利用したことがない人が戸惑っていて店員にいろんなこと聞いてたよ。

今まで台風でホテル利用ってなかったな。今回が初めてだ。震災のときは、カプセルホテルって防災面で不安があったから会社で徹夜したけど。カプセルホテルって酔ってるときとか、疲れているときしか利用しないから結局よく眠れちゃう。あのカプセルの寝心地いいもんです。朝起きて頭ぶつけることなんて、まずないです。そんな寝起きからテンションが高い人はいないですから。

RISCチップとかDSPとか懐かしいことがいろいろ書かれているが、これ書いた人こそobsolete な存在になってないか？という疑問がわいてしまう！

繰り返すが、私は引退したくても、させてくれない。だって今の開発環境のフレームワークってWEBページを作成すると自動的にクラスができて、その中に関数をかけばよいのだから・・・便利なもんです。開発生産性がいいので、仕事の依頼が来てしまうのです。決して私はobsolete な存在ではないです。私がオブジェクト指向プログラミングっていいなあって思うことは、関数の引数やリターン値にオブジェクトが使えることです。この手法は積極的に使わないと損ですよ。そうしないと本当にグローバル変数だらけ、static変数だらけとかになってしまうから（笑）。

確かにコンピュータ技術は日進月歩で、我々社内SEはプログラミングは仕事の一部で仮想化やクラウド化についても取り組んでいます。いい意味で、SEは守備範囲が広いで生き残れるのです。

いつまでたってもファクトリー・メソッド・パターンなどと喚いている人がこの業界の一部にはいますが、あのような著書は昔流行ったミステリー小説でと同じようなものです。今でもコナン・ドイル・ファン、アガサ・クリスティー・ファン、横溝正史ファンがいるのと同じです。「関数を用いて派生クラスのインスタンスを基底クラスのインスタンスに返す」という手法に名前をつけただけです。わかりやすい説明をしてしまうと種あかしをしてしまうことになるので、わざと謎めいたまま出版された著作なのです。

２０年後、３０年後も活躍できるかどうかは、やっぱ賢さや運の良さ、転職するなど決断力、努力によるのではないでしょうか？変に、はまってしまう人、必要以上に自分を賢く見せたがる人、あっさり人を信用してしまう人は要注意です。この世界、ビジネスです。その人の技術に対して、ユーザーからニーズがなくなればおしまいなのです。

このブログの内容だと、ただ単に、グローバル変数を多く使うことが悪い、という大昔から言われていることが書かれているだけです。グローバル変数全盛時代なんてありませんよ。関数の引数に渡し、リターンで返すのが昔からの基本です。staticといってもこれはstatic変数濫用の弊害というあたりまえのことを述べてるだけです。

これの元ネタが、static変数なのかstaticメソッドなのか限定せずに、ただ単にstaticは多用していいか？という質問なんで、多用すべきではないと、いきなり結論を出しているものの、

「いずれにせよ，それは初心者の下手くそな設計が悪いだけで，static変数やstaticメソッドが悪いわけではない」

とも書かれています。私の意見としては、static変数はなるべく使わない。staticメソッドではスレッドセーフにするため、static変数に書き込むことだけ避ける。それだけです。そうでなければ、下手くそな設計です。

「static static」って、ただ喚いているだけで、static変数なのか、staticメソッドなのか、はっきり限定して議論してもらいたいものです。staticという言葉に踊らされてる人が多いですよね。これでは議論がかみ合いません。

またstatic変数やstaticメソッドを使わなくても、メンバー変数を沢山使えば、可読性は悪くなります。変数はメソッド内に定義するようにして、メンバーは最小限する。もしメンバー変数が沢山あれば、グローバル変数が沢山あるのと同じことです。

私は２つのクラスに同じメソッドをコピペするようなことは嫌いなのです。だから他のクラスに、staticメソッドを定義し、２つのクラスで使えるようにしたいだけなんです。当たり前すぎることでしょう。社内SEはわざわざコピペしてステップ数を多くしても金が多くもらえるわけではないんです。

結論からして、おじさんか、若いか？に関係なく、へたかうまいかの違いだけだと思います。

おじさん達は引退してもらい、その分の給料を上乗せしてもらいたい！という若い人たちの気持ちはよくわかります。おじさんも実は引退したいのです。うまい人がたくさんいれば、私も引退できるのだと思います。

「staticおじさんもオブジェクトおじさんも技術の細部に入りすぎて相手の話をあんまり聴かないという点で同類になりえる」

私はオブジェクトおじさんがどのような人かは知らない。SEという仕事上、いろいろな調査をしているし、システム業者との打ち合わせなども度々ある。相手の話を聞くときは、相手の話の根拠や論理を知りたがるというのが、このエンジニアという職業の習性なのだ。WEBサイトや技術的なブログの記事などはよく読むが、コメントとかツイートなどというものは根拠や論理が乏しい。相手の話をあまり聴かないのではなく、相手の言っていることの根拠や論理が乏しいので、まともにとりあうべきでない！といのが私だけではなく一般のベテランエンジニアの意見ではないだろうか？

これぞ正しい解釈！オブジェクト指向はクラスライブラリを使うことにより生産性が上がる。けっして自分でインスタンスクラスをガンガン作って自己満足することではない。

>1年経って意見を変えたのかもしれないが、「static関数を使い、かつstatic変数を使わないこと！」というのは別に変じゃない。

static変数なんて、めちゃくちゃ使っていいわけがないのは、常識的な感覚を持っている人ならば、言わなくてもわかるだろ。ただオブジェクト指向入門書に見られる隠ぺい性云々という説明から、オブジェクト指向言語ではグローバル変数は全く使えないという印象を受ける！よって多くの手続き型言語のプログラマーはつまづいてしまう、ということを昔語っただけのこと。正しい読解力を身に着けてくれ。

>クラスライブラリを使いこなすのに労力なんかいらないだろ……

たぶん、こういう人は他人が作ったプログラムをパクっている人。人にクラスライブラリの使い方を教えてもらっている人。最初にライブラリを使いこなす人は苦労する。

SAP　R/3 のABAPという言語は、COBOLベースでSQL文も実行できるように拡張されています。やっかいなバクが出にくいという点で、金融系や基幹系業務でCOBOLを使うというのは現状では最適なのかもしれない。ポリモーフィズムを駆使したシステムを運用している銀行には、決して預金したくありません！歴史が古い言語だからダメというのは、クラシック音楽がすべてダメだと言っているようなもの。まだまだ残っているということは、それなりの大きな利点があると思いませんか？

本日も、誤解、早とちりに満ち溢れたインターネットの世界を見てしまった。

オブジェクト指向入門書では、まずクラスとインスタンスを覚えましょう！と書いてあります。それで簡単なクラスのサンプルプログラムを目にするものです。しかし、国内、国外、実践的なプログラミングをしている人のサイトを見ていると、staticメソッドが非常に多い。日本の多くのプログラマーはオブジェクト指向言語はインスタンスクラスを作成するのが原則だと考えいている。それはあくまでもオブジェクト指向入門書の影響であって、入門書に書いてあるそんな簡単なロジックのレベルで、実践で使えるクラスを作るわけがない。実践のクラスライブラリで使われているクラスと入門書のサンプルクラスでは全然プログラム規模が違う。もちろん今の多くの開発環境ではクラスライブラリをうまく使いこなすのがベストであり、私もそうである。だからといって、優秀なプログラマーが示す、実践で使えるプログラム例は、それらのクラスライブラリを使ったstaticメソッドが多い。

なんで、そうなるのか？　やはりクラスというものは、public メンバーの値の受け渡しとかpublicメソッドによるメンバー変数の書き込みなど、書き方が自由すぎて、プログラムをわかりにくくする傾向にある。実践で使えるプログラムTIPSというものは、関数の形に納めてしまうのがコンピュータ言語の基本とも言える。

オブジェクト指向フリークの人のほとんどは自分が書くプログラムがベストだと思い、他の人のプログラムを読むことメンテナンスすることを拒否する。今開発中のインスタンスクラスオンリーのシステムは、やがて、そのメンテナンスを引き継いだ人からは強烈な批判を浴びることになる。メンテナンス不能な負のソフトウェア遺産を背負うことにほかならない。こうして入門書をまともに信じる良い子の日本人は世界から取り残されることになる。

じわじわ浸透してきてますな。最上位のレイヤーはstaticでいい！なんて結構最近、ささやかれてますね。

staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて

レイヤーつまりソフトウェアアーキテクチャについて正しい認識、センスを持つということで彼に同意です。

いいクラスライブラリ、いいライブラリ関数というレイヤーの上で、いい業務アプリケーションが開発できるというのが素直な考え方です。多くのかたがレイヤーという概念というかセンスを持っていないことに日本のプログラム開発の悲劇がありそうです。レイヤーという概念を把握せずに、クラス分け、つまりプログラムをクラスというサブプログラムに分割してしまうことにより、趣味の悪いメンテナンス性の悪いプログラムができあがってしまう。

私の自論としては、最上位のレイヤーは関数やstatic関数でかなりいけてしまう、その下のレイヤーは現代の開発ツールですとクラスライブラリ化、コンポーネント化されているのでオブジェクト指向となります。だからと言って、業務アプリケーション開発者はオブジェクト指向の勉強をしなくていいということにはなりません。クラスライブラリを使いこなすには、かなりの努力が必要です。

昨今のアジア市場の成長により、最近、簡体字で印字できるかとか、簡体字で出力できるとか、結構今までにはない要求が来る。

実際に、中国の人民日報などは簡体字でかかれている。それをコピペでノートパットにコピーすることはできるのだ。しかし、ASPで書かれた、WEB画面から簡体字を入力して、ファイルに簡体字を書かせるには・・・・

まず、*.asp ファイルだが通常ANSIだが、これをUTF-8形式で保存しなければならない。unicodeではダメ。コンテンツに簡体字を入れて正常に表示されるか試してみるといい。

Filesystemobject の　OpenTextFileでunicodeのファイルを作成するように引数を設定する。一番最後の引数を　True。通常、日本語では、最後の引数は記述しない。

Set objFs = Server.CreateObject("Scripting.FileSystemObject")
Set objTs = objFs.OpenTextFile(Server.MapPath("Test.txt"), 8, True,True)

よんでますよ、モテるstatic女子力を磨くための４つの心得

これを書いた人が、本当に女子なのかどうかはわかりません。

意図もよくわかりませんので・・・・ノーコメントです！

あえていえば、static関数を使うことになれてしまうと、引数やリターン値で他のクラスに値を受け渡しする基本的な習慣が身に付きます。それからインスタンスメンバー使っても本当にnewするのがアホらしくなるだけです。状態を扱うときにインスタンスクラスを作ればいいのです。

なんとこのシステムエンジニア日記というメモ書きが、海外にまで伝わっている！！

OSやイメージ処理の開発を行っているエンジニアは、業務システムなんて、なんも知らないでしょうね。私もメーカーにいたころは業務システムや業務知識の難解さ、ユーザーとの折衝のやっかいさなんて、何も知りませんでした。アメリカでも社内SEや金融システムの開発を行っている方がいますので、日本とアメリカとの違いではなく、メーカーとSEとの違いをよく理解していないようですね。優秀であっても職種による経験の違いがかなりありますので、安易なtweetでの発言はいかがなものかと。

メーカーの人は、その技術に特化したことを行いますが、SEはユーザーが必要となれば、なんでもします。世界が狭いとか広いとか一概に言うべきではないのです。特化した技術というものは、自分を超える若い人が出現すれば、陳腐化されてしまうのなのです。私は単にネット上で老害と言われているだけで、まだまだ私がいないと会社が露頭に迷うくらい重要な仕事をしています。アプリケーション開発は仕事の一部分で、ネットワーク、仮想サーバーなどいろいろな仕事をしているのですよ！

私も若いころ　Mountain View にある　Adobe社の近くの SGI にいたことがあります。もうSGIはなくなってしまったけど・・・

「実はオブジェクト指向ってしっくりこないんです！」から一年

先日、マイクロソフト社からアンケートの電話がかかってた。

「まだVisual Basic使っているところが多いんですよね。御社の場合はVisual Studio 2010 を使うことをお薦めします」

プログラムやシステムというものは、とにかく動くのが第一。業務ソフトの場合、わざわざ多額のコストをかけ開発ツールをバージョンアップする稟議などは通らないものだ。震災以来、東日本では計画停電を味わっている。電気がこなくてシステムが動かないというのが、いかに最悪かということを実感している。

プログラマーの方のブログを見ていると、オブジェクト指向的実装について考察しているものが多い。しかし、ほんとに仕事で稼いでいる人は言語はVisual　Basicで、業務知識に精通している人かもしれない。仕事で稼いでいる人は、ブログなんて書く暇もないし、そんなことをしても金もらえないもん。プログラムってプログラミングしたい対象があって、その対象となる業務知識や科学技術の知識のほうが価値があり、プログラミング実装は、手軽で簡単でバグが少ないものにつきる。

プログラミング実装が一番価値があると言えた時代は、次第に終焉を迎えている。便利なクラスライブラリが開発ツールがあるのだから、それらを使えばいい。クラスライブラリやコンポーネントの使い方がわからなければ、インターネットで検索すれば手軽に情報入手できる。

業務システムのアルゴリズムを実現させるには、static関数を使い、かつstatic変数を使わないこと！オブジェクト指向実装というものは、複雑なアルゴリズムの実現に対しては、役に立たない技術である。多くの自分はプログラミングの天才だと思っている人は参考書どおりのオブジェクト指向プログラミングのパターンを知っているだけで、実践の業務システムが構築できるだけの創造性を持っているわけではない。本当に勝てる人はアルゴリズムを作る人であり、ユーザーに支持されるものを作る人である。本に書いてある実装方法でプログラムを作成し、「動いた！」と自己満足している人ではない。

私の言っていることが老害っだと中傷している人、すべてに言えることは、あなたたちはユーザーに支持されるものを作っているという証拠を示してない！そんな人たちの言っていることは信じる価値がないということです。

以前からよく聞く言葉だったが、今回あるきっかけで気になったので、Wikipediaで、どういう意味が調べてみた。

漫画の悪役像ステレオタイプは、物語やフィクションなどで造形される人物像にその典型的な形が見られる。勧善懲悪の物語では、善役はいかにも善役らしい姿や言動があり、他方、悪役は同様にいかにも悪役らしい姿や言動で表現される。

大衆向けの娯楽目的の小説や映画、ドラマなどでは、人物造形がステレオタイプなだけではなく、物語の構成やプロット、展開・結末などもステレオタイプになっているのが一般である。漫画やアニメなどでは、「Boy meets girl, and fall in love」という言葉があるが、これは最近の物語におけるステレオタイプではなく、古代の青春恋愛物語である『ダフニスとクロエー』においても同じような構成になっている。

これらはステレオタイプというより寧ろ、神話類型（Cat:神話類型）にも通じる、物語の基本的な類型構造で、人間心理の普遍的・先天的なありようとも関係すると考えられる。しかし近代において、大衆社会、マスコミュニケーションが成立すると、政治的、経済的、あるいは社会的な目的において、過剰に単純化され類型化されたイメージが広く一般の人にも流布するようになり、文字通り、紋切り型な把握や観念や思考となって定着するようになった。

ステレオティピカルな観念の特徴

ステレオタイプは、現代では多くの人が持つ観念に、その代表的な例が存在する。これらの観念は偏見や差別意識と関係し、先入観やタブロイド思考とも関連している。「紋切り型」という言葉が示すように、個々人が抱く考え方・観念に個性が乏しく、同じような考え方やものの見方が、多数の人において類型化されて共有されている。

何故、そういうステレオタイプな思考やものの見方が妥当と確信するのか、ということについても、メディアがそう述べているとか、まわりの人がみなそう言っているとか、自分自身で主体的に反省して吟味することが殆どなく、外部の意見やものの見方をそのまま無批判に取り入れ、鵜呑みにしていることが一般である。その為、観念や確信に客観的根拠がなく、底が浅く、また複雑なものごとを単純化している結果、当人は十分に理解しているとの錯覚を持っているが、迷妄であって、固定観念になっている場合も多々ある。
　

tweet を見ると、三浦マネージャのファンが多いみたいですね。「銀魂」のよろずや銀さんみたいに、ワルで絶対自分の非を認めないってタイプが人気があるからなあ。

「疎結合」とか「具象クラスの中まで調査したのか？」なんて筆者のコラムにコメントをネタにしているのがスゴいですね～。

常道なシステム構築って、どこのクライアント企業にも使えるような汎用的なロジックとクライアント企業ごとに違うロジックを切り離すために、抽象化を用いて、クライアント企業ごとに仕様が違うロジック疎結合にし、具象クラスにコードを記述するのが普通だと思うんだけど・・・仕様変更が多いのは具象クラスのコードのほうだと思うのです。なんで具象クラスは変更なしで済んじゃうの？

どうも三浦マネージャが来る前から、このクライアント企業のシステムって普通と逆の設計思想だったのか？なんて変なことを思ってしまします。

まるで、最初からこのクライアント企業の業務ロジックはクラスライブラリ化されていたみたいな印象です。まあフィクションですからあまり深いことは考えないようにしましょう。

「staticだらけのコードを自動でリファクタリング」というのは、かなりおもしろいテーマですね。
ちょっとつくってみたいです。

ところで、「ポリリズムなコード」ってなんかかわいいですね。
踊りだしたくなるような感じです。

高慢と偏見(9) 誰がスケジュールを遅らせた？それはあなたとプロマネは言った

＞三浦マネージャに教育された新人みたいな人も良いものを読めば何かが変わるかもしれない。

オブジェクト指向教育、特にポリモーフィズムに関しては、デザインパターン本や大学の先生の講義まで、ビジネスになってますよね。デザインパターンの話をすれば人から尊敬されると思っているプライドが高いかたもいます。誰も簡単にわかる本とかレクチャーなんてしませんよ。むしろ簡単に説明してしまったら皆さん困るでしょうね。良い本がなく、本当にわかる人なんていないと思ったほうがよろしい。

まず基底クラスとそれを継承する数個の派生クラスをつくります。読者が興味を持てる例だといいのですが、なかなか私も例が浮かばない。たとえば、

このように多態性を持たせるように派生クラスでは同じメソッド名「値段を聞く」を定義しておく。さらに他のクラスを作り、その中のメンバー関数の引数やリターン値に派生クラスのインスタンスを使えば、それなりにデザパタっぽいサンプルプログラムになります。チャレンジャーの人は、もう一つ違う基底クラスを作り、それを継承する派生クラスを複数個つくり、そのクラスのメソッドで、上記の例のような派生クラスのインスタンスを生成したりしてみましょう。メソッドの代わりに、クラスのコンストラクタの引数に派生クラスのインスタンスを入れたりすることもできます。

引数やリターン値の型が基底クラスとなっている関数に派生クラスのインスタンスをぶち込む。そして派生クラスのメソッドを実行すればデザパタになるんです。自分なりにできたサンプルプログラムに名前をつけてみるのもいいと思います。たとえば「お買いものパターン」とか。

こんなことをして自分オリジナルのデザインパターン本を書いたら、著名なデザインパターン本を読んでみましょう。きっと自分のデザインパターンと似ているものを発見すると思いますよ（笑）

まあ、私の意見としては、ポリモーフィズムを使ったデザインパターンは、あくまでもサンプルコードであって、実践で役に立つかどうかわからん！としか言いようがないです。ただ、デザパタっぽいサンプルプログラムを作ることは暇人ならばできるということです。

チェックイン・チェックアウトではなくチェックアウト・チェックインだ！

　かつてはプログラムのソースコード管理で行われていた排他制御技術、チェックイン・チェックアウトは、シェアポイントサーバーなどで一般の文書編纂作業にも用いられるようになった。技術者でさえも、どっちがチェックインで、どっちがチェックアウトだっけ？　まあ、ツールの使い方を体で覚えてるからいいや！なんて思ってる。しかしSEは文書管理システムを導入する場合、ユーザーに使い方を教えなければならない。そこでチェックインとチェックアウトを混同しちゃったら、ユーザーが不機嫌な顔をするだろう。

　普通ホテルを利用する場合、ホテルに入るのがチェックイン、ホテルから出るのがチェックアウトとなっている。だから皆さん文書管理システムでも「チェックイン・チェックアウト」なんて説明しちゃう。だけど文書を修正追加するとき、チェックアウト、編集、チェックインですよね。だから私は「チェックアウト・チェックイン」といういいまわしをします。このほうがしっくりくるんです！
利用者からすれば、最初は文書を作成してチェックインします。しかし、その後はチェックイン状態が長くて、文書を変更したいときだけ、チェックアウトし、文書編集後にチェックインします。つまりチェックイン状態の方が長いのが通常ではないかと・・・　ホテルの場合は、チェックインしてから数泊後にチェックアウトです。だからホテルで毎日生活する大金持ち以外は、チェックアウト状態が長いんです。ホテルとファイル管理、文書管理を同じ利用形態と考えるは無理があるんです。
　

エンジニアのキャリアパターン

　職業はと聞かれたら、「エンジニア」と答えればいい。昔は学生時代にコンピュータ実習というものがあったのだが、ハードとかソフトとか言われてもなんだかわからなかった。カードを鉛筆で塗りつぶしてフォートランプログラムを動かすなんて、そんなことできるわなかった。大学の研究室にPC98があったので、それでBASICのプログラムを書いて、電磁波のシュミレーションを始めたのが私の情報処理システムとの本格的な出会いだ。

　今の人たちは恵まれている。家庭にPCがある。そのPCを使えば何も大学生になるまでもなく、子供でもプログラミングができてしまう。

　はやかれ遅かれ、IT系のエンジニアの最初はプログラミングで始まるのではないか？それがまったくできない人はインフラ系エンジニアになっても失敗すると思う。だってインフラはアプリケーション・プログラムやOSを動かすためにあるのだから・・・

●　非IT分野のキャリアパターン

　これからのエンジニアとして望まれるのは、ITエンジニアだけではなく、IT以外の分野でプログラミングやサーバーの運用をやってしまうのがやりがいがあるのではないだろうか？例えば農業試験場とか水産試験場のような第一次産業の分野で、専門分野とITに詳しい人材。

●　業務アプリケーション分野のキャリアパターン

　最初は人が書いた仕様書や要件定義書を理解して、プログラムを書くが、そのうち対象の業務分野の業務知識が身に付き、自分で要件定義からプログラム作成までやってしまう。大規模なシステムならばプロジェクトリーダーになる。金融、会計、生産、在庫管理などの企業活動として必要な知識が要求される。またプログラムの生産性を常に意識する努力も必要。

●　インフラエンジニアのキャリアパターン

　おもにサーバーのサイジング、導入、設定、バックアップ検証を行う。しかしサーバーの移行などでデータ移行プログラムの開発する必要もあるし、マニュアル、時には英語のドキュメントまで読む読解力も要求される。本来、システムエンジニアと呼ばれる人たち。　

●　プログラミング教育者のキャリアパターン

　本当にプログラミングしか興味が持てない人。業務に対しての知識や資格もないし、サーバーソフトのインストールもしたことがない人の場合。いくつもの言語をマスターし将来的プログラミング教育者となる

●　勝ち組のキャリアパターン

　最初は自分でプログラミングしていたが、会社が発展し、３０歳程度で多くの部下を持ち、部下の
指導とコスト管理をするだけでよい。

●　エンジニアとはいえないキャリアパターン

　すべて外注丸投げの会社に就職した人。

なぜ、ずっとプログラマーという道がないのか？

理由１　さすがに５０歳前後で老眼になり業務効率が落ちます（笑）。

理由２　プログラミングは疲れるから３０歳以上になると管理職になりたいとか、独立企業したいと夢見ている人が多い。
　
理由３　プログラミングはできるけど、ユーザー要件定義ができない人は効率が悪いです。いわゆるウォーターフォール型の開発しかできない人です。スパイラルやアジャイル開発を行うには、何よりも業務に対する理解がないと難しいのではないでしょうか？
　

新説オブジェクト思考

　いろいろなブログでオブジェクト指向技術について解説しているが、なかなかわかりいやすい説明って難しいみたいですね。犬や猫のたとえが悪いといいながら、ピンとこない用語が羅列していて、やっぱりわかりにくい解説が多いです。私はSEですからソフトウェアの専門家とは言えませんが、私なりに理解しているオブジェクト指向について解説してみましょう。

[直球勝負のオブジェクト指向]

もう何かの例えとか、哲学的な前置きなんてしません。

●　クラスは単にプログラム全体のサブプログラムと考えればよい
●　クラスはメンバー変数とメンバー関数（メソッド）により構成される。メンバー変数はクラス内に限定されたスコープでのグローバル変数である
●　メンバー変数やメンバー関数をパブリック宣言することにより、他のクラスからメンバー変数に値の受け渡しができたり、メンバー関数を実行することができる
●　インスタンスを生成することにより、インスタンスごとに違うメンバー変数値を保持することができる。インスタンスはつまり、クラスによって生成されるオブジェクトの識別子のようなポインタである。これにより、同じクラスで違う状態値を持つオブジェクトを生成することができる。

　これらのことから、クラス生成されるインスタンスはステートマシンを実現し、メンバー変数の値は状態値となります。プログラム全体としては、複数のステートマシンが通信（メッセージパッシング）するシステムとして構成されます。

　オブジェクト思考とイベントドリブンは別の技術ですが、現代のGUIフレームワークでは、イベント制御を行うのに都合がよいシステムとなっているわけです。フレームワークの代表的なもには開発ツールです。フレームワークの定義はユーザーがクラスや関数の中にコードを書き込むものです。それに対しクラスライブラリは、クラスが多数用意されて、ユーザーがそのクラスを利用するものです。最近の.NET FRAMEWORK という言葉からフレームワークはクラスライブラリではないかと思っている方も多いと思いますが、フレームワークとクラスライブラリは違います。

　クラスをたくさん作ってクラスライブラリのようなものを作ると、自然に似たようなクラスは同じメンバー変数、同じメンバー関数を使うことが多くなってきます。そこでクラスの共通するメンバー変数やメンバー関数を基底クラスとして定義して、それを継承してクラスを作ったほうが冗長化されずに効率的なコードとなります。基底クラスを継承して作ったクラスは派生クラスと呼ばれます。

　同じ基底クラスから派生して作ったクラスで、似たようなメンバー関数がある場合、同じメソッド名にしてユーザーに扱いやすくなります。これが多態性です。基底クラスを使って派生クラスのインスタンスを生成することができるのが多態性の特徴です。

　オブジェクト指向言語では、関数の引数やリターン値またはコンストラクタの引数にオブジェクト（インスタンス）が使えます。関数のオブジェクト引き渡しに派生クラスをつかうとさらにバリエーションのあるプログラムが生まれます。この例がデザインパターンとも言えます。

　これがオブジェクト指向の要点です。現在でも論争の焦点となっているのは次の点です。

●　メッセージバッシングの多用はプログラムの動作が追いにくい原因となる。関数でできるものは関数で実現するのがよいのではないか？
●　デザインパターン本では派生クラスを多用しているサンプルプログラムが多いが、実際の開発でこのようなケースが有効につかえるのか？

クラスを使うメリットはメンバー変数に状態を保持することであり、そのような必要のない、引数から単純にリターン値が演繹されるものは関数が適しています。それに対し、ファイルを一行ずつ読むようなプログラムでは、何行までファイルを読んだか状態を保持する必要がありますので、ファイルを読むようなことをする場合、ファイルオブジェクトクラス使うことが適切であります。例えば、ボタンをクリックするごとにファイルを一行ずつ読むような動作も可能なようにするには、ファイルの読み出しに適したクラスを作る必要があります。

　しかし、状態保持としてメンバー変数を使わずに、データベースやセッション変数を使っている場合は、クラスではなく関数でプログラムを作成しても問題ありません。結果として業務ロジックではメッセージパッシングは使わないほうが、メンテナンス面で有利となります。

　デザインパターン本ではオブジェクト指向のメッセージパッシングよりも、多態性が強調されています。

　　　return(new 派生クラス()):

のような関数のリターン方法などデザパタでは「決めの一手」といった印象を受けます。現実の業務ロジックでは、綺麗なタイプ分類により、派生クラスのメソッドの挙動が変わるようなケースは少なく、「一般的な処理と例外的な処理」でコーディングされるのが通常です。
　たとえば、5つの派生クラスと5つの関数を記述することなると、25個の関数を記述することになります。このようなプログラム構造はいくらデバッグしてもバグが残存する原因となります。

　条件分岐がバグの温床になり、多態性を使ったほうがいいというのが一般論ですが、if文の　== と書くべきところを　= で書いてしまったり、switch 文の　break を抜かしてまったりするポケミスが多いことは多くの人が経験しています。。ユーザー要件としては、あくまでも条件として定義されてくるものなです。それから本当に複雑な条件文では多態性は役にに立ちません。

　それでは、どのようなケースで多態性は有用なのでしょうか？それは違うI/Oインターフェイスを切り替えるような場合です。またデザパタでは基底クラスの仮想関数に派生クラスのメンバー関数をオーバーライドを行うような例がありますが、これはユーザーごとにプログラムをカスタマイズし、違う動作を実現するのには有用な技術となます。パッケージソフトのアドインなどには応用できます。

　これからもオブジェクト指向を学ぶ人は、サンプルコードを見た時に、漫然と見るのではなく、どの一行が「決めの一手」なのかを考えてくださいね。
　

「xxxConfigFactory.createメンバーで、違うタイプの派生クラスのインスタンス生成して、それをcofngAccessor に代入する。そうするとcofigAccessor.getResult() メンバー関数はタイプによって違う派生クラスのgetResult()メソッドを実行してresultList オブジェクトを返すようになる・・・・」

とか。今のところ、このコラムコメントがないけどどうなることやら。

これすげ～な。ありとあらゆる技術の羅列。こんなにガンガン書かれたら本当かどうか信じません。こんないろんなことをやっていたらコラムなんて書く時間もったいないもん。最後はCSSとかjQueryとか誰でも知っている技術で落ち着いてるんだね。

OS開発している技術者に比べれば高度な物理学や数学を必要としないアプリケーションのエンジニアなんて、アホなのはわかってますが、なんでこの発言を＠ITは許してしまうのでしょうか？MSさんから広告収入もらっているんじゃないの？大丈夫？　誹謗中傷をコラムに書いてはいけない規則のはずですがね。変です！

今年のシステム業界を振り返ってみて、自画自賛なのか、最低の自虐なのか?　「実はオブジェクト指向ってしっくりこないんです！」　この発言のインパクトは結果的に何の製品リリースの話題よりも大きいものになってしまった！！iPadの話題なんて結局一時的なもの！　

もともと誰も読んでくれないコラムだろうと思って適当につけたタイトル、それが日本のシステム界最大の「迷言」となった。オブジェクト指向は新しい技術ではない。オブジェクト指向プログラミングに挑んできた人たちは、もう私と同じくらいオヤジの世代になっている。

オブジェクト指向の最大の利点は部品の再利用。最近の開発ツールでは、たくさんのコンポーネント部品を享受できるために、あえて部品を自作するような必然性はそれほど生じなくなった。部品の再利用というオブジェクト指向本来の性格からして、数十年で開発パターンは変わっていく宿命だったのだ。

「ゆく川の流れは絶えずして、しかも元の水にあらず」　大昔の方丈記の時代でも、そうであったのだから、現代の20年の歳月というものは大きく環境が変わるものだ。何かしっくりこないものを感じたら、いつかしっくりくるように変わると期待する。あるいは、しっくりくる手法を自ら提言する。それでも、また将来、新たなしっくりしないものが出現するかもしれないのだが・・・

逆に私はしっくりきたぞ！と思うのが64ビットデータベース。十分メモリを積めばガンガン早くなる。メモリを積んでスペックを上げるなんて下品かもしれないが、64ビットを使いこなすのは結局これが正解なのだ。

どこかのブログの影響でなぜかまた「実はオブジェクト指向ってしっくりこないんです！」のコラムのアクセス数が増えているそうだ。「死んじゃえ！」とかまた強烈なご批判の意見もありますが、とにかく私の開発したプログラムはスレッドセーフで問題なく安定稼動している。また社内、取引先のSIerとの関係で何も問題が出ているわけではない。実際に私の設計したシステムを使っているユーザーや私と面識のあるSIerでは誰も私を異常な人間とも思っていない、むしろユーザーやSIerに対して友好的な関係に変わりがない。面識のない人のネットの意見など、もう気にしなくなった。っていうかネットの世界で顔見せしなければ誰でも何でも言えるもんだ（笑）。

クラスを使ったオブジェクト指向プログラムでは、メンバー変数をpublic化したり、publicなメソッド関数を使うことにより、他のクラスからメンバー変数を更新したり呼び出したりすることが自由自在にできる。メンバー変数はクラス内に限定されたグローバル変数のようなものなので、クラスの設計方針を明確にしないと自由自在に設計は他のプログラマーが仕事を引き継いだりするときに、どんでもなくやっかいなことになる。処理手順が追えなくなるのだ。

実際にオブジェクト指向プログラミングが得意な人のコードを見ていると、複数のメンバー変数を呼び出し元のクラスに引き渡すために使われていることが多い。呼び出し元のクラスから呼び出すクラスのメンバー変数に値を入力したり、メソッドでメンバー変数を変更したり、いろいろなことをやってしまうとメンテナンスが大変なことになる。

クラスを作るときはメンバー変数の値の引渡しなどの方針を良く考え、コメントや仕様書をわかりやすく書くなどの注意が必要だ。私が関数やstatic関数を好む理由は引数やリターン値により何が入力で何が出力か明確であるからなのだ。若い人のプログラムを見て思うことだが、データの入出力が煩雑でわかりにくいクラスほどやっかいなものはない。

関数の不便なところはリターン値がひとつしかないことであるが、Visual Studio では DataTable で複数のリターン値を返す方法などがある。複数の値を返したい場合においてはクラスを使うのも有効な手段かと思う(2010年6月16日のリンクの例)。わざわざそのために構造体を使う理由はない。

オブジェクト指向プログラムは、クラスというプログラムの集合体であり、そのクラス同士がデータのやり取りが自由自在にできる。ただ、ポリシーがなくクラス間でのデータのやり取りをしてしまうのは、のちのち失敗をまねく。自分がプログラムを書くだけでなく、数年後に他の人がそのプログラムをメンテナンスすることを考えて欲しい。

システムを開発するだけでなく、会社の業務がいつまでも存続するようにするのが社内SEの責務。匿名のインターネットの世界で無責任な発言をすることは、結局はユーザー企業、社内SEの不審を煽るだけ。オブジェクト指向についてポリモーフィズムやインターフェイスなどの知識をいくら持っていても、動くものを作ることは別。自分では綺麗なプログラムだと思っていても、それは自己満足で、他人がみたらスパゲティプログラムなんて十分にありえる話です。何が綺麗なプログラムなんて客観的指標がないんだもん。

私は社内SEとして一次請けの業者さんの社員としか会ったことはない。だから多重請けの問題とか派遣エンジニア云々の問題とは全く関係がない。どこかのブログの非常にレベルの低いことを押し付けれてた変な体験と私のコラムを一緒の次元にすることははなはだ迷惑ですね。

クラスのサンプルコードが載っているブログを発見した。この人の作るクラスの特徴は

■インスタンス生成すると、メンバー変数を参照することで結果が得られる

構造体を使うことなく、メンバー変数を参照することで、複数の実行結果を返す機能を実現していることだ。まあ、クラスを構造体的に使っているていう感じかな。プログラミング記法としては美しいと思う。

オブジェクト指向という技法は、もう四半期以上前からあるものです。私はプログラム作成を専門にしているものではなく、システム全般の最適化を考えるシステムエンジニアという立場ゆえ、それほどオブジェクト指向というものに深入りしたことはない。いまさらどこかのコラムで炎上したことは以外なことであった。いろいろな人の意見はWEBで情報収集したことから私なりにオブジェクト指向というものについて考えてみた。

■クラスはメンバー変数を状態変数とするステートマシンであり、オブジェクト指向はシステムをステートマシンの集合で構築するという思想である。

■インスタンス生成とはメンバー変数に必要なメモリー領域を確保するための行為である。

■多種のクラスを作っていくと、多くのクラスで共通なメンバー変数、メンバー関数が存在する。そのようなコーディングの冗長をなくすために、基底クラスをつくり、それを継承するという手法が導入するのは自然のなりゆきであろう。

■基底クラスを同じくする複数のクラスで似たような動作をするメンバー関数を同じ関数名に定義して扱いやすくしたのがポリモーフィズムである。

オブジェクト指向がステートマシンのコンセプトをもとにしたプログラミング手法だとすれば、業務アプリケーションでは、状態変数など使わずデータベースに状態フィールドを設けることにより制御できる。これが業務アプリケーションではオブジェクト指向を意識する必要がない最大の理由である。継承やポリモーフィズムはオブジェクト指向の目的ではなく結果の産物である。本来のオブジェクト指向の目的はあくまでもステートマシンにあった記述である。

実はVisual Studio .NETのフォームやWEBページはクラスでできていて、そのなかに開発者はコードを書くフレームワークになっている。

■ボタン１をクリックとテキストボックスに「Hello!」が表示される

■ボタン２をクリックするとテキストボックスに「Good bye!」が表示される

ということをクラス内のボタン１とボタン２のイベント関数に書くことにより、テキストボックスに何が表示されるかという状態の変化が起こる。つまりテキストボックスの表示内容をメンバー変数としたステートマシンを実現したことになり、それで立派なオブジェクト指向的なプログラムを実現したことになる。Visual Basicとまったく変わらないじゃないかという反論はあるかもしれないが、Visual Studio .NETのフレームワークは開発者がオブジェクト指向を意識しないで、オブジェクト指向プログラムを作成してしまうのだ。イベントドリブンのプログラムをステートマシンを意識し、オブジェクト指向技術を適用することは有効である。GUIアプリケーションの時代になってから、ほとんどの開発環境はオブジェクト指向言語を採用したフレームワークになっている理由はそこにある。

「状態変数」って何？「プログラムの変数ははすべて状態変数と言ってもいいんじゃない？」と質問する人がいる。このように、ステートマシンのコンセプトを十分に理解していない人がクラスを書くことは非常に危険なことである。自己満足なプログラミングをするだけで他人が見たら頭を悩ますコーディングになってしまうのだ。

関数の引数、リターン値、ローカル変数は状態変数ではない。グローバル変数は実は状態変数である。オブジェクト指向はグローバル変数だけでなく、メンバー変数を必要な部分、必要な部分に公開する仕組みである。

すべてローカル変数で構成される関数は、引数、内部変数、リターン値に一過的な値しか保持しない。つまりこれらの変数のメモリ領域は一時的な値の受け皿になっているだけということだ。一過的にしか意味を持たないものをメンバー変数する必要はなく、関数の引数かリターン値にすればよいことなのである。つまり一過的にしか意味を持たないものをメンバー変数にすることは基本原則である構造化プログラミングに反した行為である。これは非オブジェクト指向言語で本来関数の引数やリターン値で値を受け渡すべきなのにグローバル変数で値を受け渡しているようなプログラミングと同じです。

オブジェクト指向を始める前に基本的なステートマシンのコンセプトを理解すべきだ。私は業務アプリケーション開発しかしていないので、実験レベルでしか継承などのテクニックを使った経験がないです。実践での適用はないので、オブジェクト指向について語る権利はないのかもしれません。でも、ほとんどの開発ツールがオブジェクト指向に対応しているのに「なぜ業務アプリケーションはオブジェクト指向とは縁がないのか？」について意見を言わせてもらいました。

インフラジスティックのコンポーネントを使ってVisual Studioの開発環境で動作しても、本番機で動作させるためにはそれなりの準備が必要だ。ヘルプのアプリケーションの配備を見てもわかりずらい。とりあえず共通アセットの配備というものをしてみた

のフォルダを作成して開発環境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フォルダの下にコピーした。これで動作した。

メモリーのデータ異常をチェックする方法としてはECCがよく知られてます。これはメモリーを冗長化させることによりデータ異常を検出する方法です。ところがECCを使っていてもメモリー自体が異常を起こした場合はお手上げです。チェックビットをそれそれのメモリーに分散させ、一個のメモリーが不良動作してしまってもデータが修復されるのがSDDCです。サーバー購入のときには仕様上SDDCかどうかSDDCが機能するかどうか確認しといたほうがよいでしょう。最近はコストダウン競争でメーカーはなるべく安いメモリーを使う傾向にあるので注意です。

Visual Studio 2003 から　Visual Studio 2005　へのコード変換のつづき

InfragisticsのHOTFIXを適用すると、Assemblyのバージョンがかわるので、Register　Assemblyを書き換えた。最初のHOTFIXを当てるのが正解だったようだ。ビルドは成功したが、結局Infragistiｃｓコンポーネントは.NET1.1 と .NET2.0では使用するタブが違うので正常に動作しないことがわかった。やはり手作業が必要ということでこれ以上は断念した。

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の下はすべて消してから変換するのが正攻法なのだろう。

企業では多数のアプリケーションをWindows7で正常に動作するのか検証するだけでも労力的に困難である。Windows7の通常のインストール、それがだめだったらXP互換モード、さらにXPモードで検証するなんてことはやっかいきわまりない。マイクロソフトはプロダクトライフライフサイクルという独自の理屈で古くなったOSはサポートしないし、古いOSに対応するハードをメーカーに売らせない基本方針であるが、基本的にハードならば老朽化するという点で古いものはサポートしないという理屈は納得できるが、OSはソフトウェアでありデジタルデータであるので、古くなったらサポートせず、新しいOSに対応するように客に労力や費用、リスクを転化するというのは全企業を相手にした訴訟問題に発展する可能性がある。また世界的なCO2削減、エコの観点からしてもWindows7やWindows2008に乗り換えることは何のメリットもなく、古いPCを捨てるという地球環境破壊活動に他ならない。Windows95が出始めて15年の歳月が流れたがマイクロソフトのOS戦略も発展性がなくなったものだ。しかし自分にとっては、この15年間IT技術の急速な発展の中で仕事ができたのは苦しくもあり楽しくもあり、いろんな経験ができたことで非常に幸運であったのかもしれない。今後は企業で利用されるIT技術はドキュメントやデータの継続的保護、仮想化技術を駆使したシステムの継続的運用を重視した安定成長に方向性を変えるだろう。

マイクロソフトのHyper-Vは主流になりえるだろうか？仮想サーバーとなると何十台もの仮想マシンのプラットフォームとなるだけに安定稼働で実績のあるVMwareにはなかなか勝てないのではないだろうか？Windowsサーバーではハングアップによる再起動、サービス再起動をせざるを得ない場面が多し、多数のウィルス攻撃から守るために毎月セキュリティパッチの適用をし、ウィルス対策ソフトをインストールする。始末の悪いことにSymantecのウィルス対策ソフトはインストールすると不具合を起こす原因になることもある。VMwareはハングアップもなく非常に安定性の高いプラットフォームである（私の経験では）。VMwareを使っていると可能な限り基幹システムであろうとなかろうと仮想化してしまいたくなるのだ。Windowsはいつまでたってもセキュリティパッチ（実際はバグフィックスではないのか）を毎月適用せねばならない。なんで原因不明の障害がでるのか？またサードパーティの製品についてもバグと思われる不良動作が頻繁に起こる。

最近は仮想化戦争にLINUXのRedHatも名乗りを上げている。マイクロソフトはVMwareとLINUXという非Windows陣営に今後対決していくことになる。インターネットの世界ではセキュリティの観点からすでに非Windows陣営(LUMP)に軍配が上がっている。マイクロソフトがインターネットにかかわっているのは単なるブラウザだけである。企業内においては、認証、アクセス制御でマイクロソフトのドメインコントローラを基盤にし、ファイルサーバー、SQLサーバー、WEBサーバー等を構築する非常に強固なシステム、他のOSの参入がしにくい砦のようになっています。この砦にLINUX陣営がどう攻撃をしかけるのか、またマイクロソフトがその砦を守るのかが今後興味のあるところでしょう。

C# デリゲート　　メソッドを変数のように扱える？機能についてどう説明したらいいのか迷ってしまいます。JAVA Scriptでは関数の引数に関数名を使えるという納得のある記述方法がありますが・・・

デリゲートはまず、この宣言をする。さらに、このデリゲート関数xxxと同じ引数の個数と型をもったメソッド

class classA {　// 実際に実行する処理のメソッドをこのクラス内に記述する

を記述する。このようにすると、以下の記述で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とｚｚｚの処理を結合する

.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年！七年前プログラミングを始めた若手エンジニアが主力となりつつ時期に来ている。

最近、ITバブル当時に比べ、ERP、SAPの話題を聞かなくなったような気がする。インターネットで調べてもABAPに関するHPは廃れている。最近のプログラミング言語はCやJAVA言語系のものがほとんどなので、SAPの独自言語というものはかなり浮いた存在になって当然かもしれない。R/3は企業の各部門のデータベースを一元管理するもので、それを実現するには2000年以降のサーバースペックでないと無理であった。その意味でSAPは先駆的であったかもしれない。しかし最近のマルチコアのサーバースペックや大幅なディスク容量の拡大により、データベースの一元管理は容易になってきている。ADDONによってシステムを導入企業向けに拡張するというコンセプトはSAPのユニークですぐれたところであり、とくにバッチインプットプログラムにより、データの入力更新作業を自動化するというアイデアはユニークである。しかし、このバッチインプットはユニークな手法であるために逆にADDONプログラムの開発の足を引っ張ることになる。そのためにSAPではBAPIという関数を用意しているのだが、その使いかたは難解である。ERPのような大規模な業務アプリケーションを構築するには、プログラム実装面でのルールが必要である。

[データの照会]：これはSELECT文で各種のテーブルを抽出し画面に表示する単純なもので問題ない。多少のロジックは必要だが。
[データの追加]：データを追加する関数を用意する。どのような画面にするかは企業によって違いがあるので、画面を作り、画面項目から関数の入力項目にデータを渡せばよい。関数のデータ項目は意味がわかりやすいようにコメントやドキュメントが必要だある。また必須項目であるかどうかも明確にわかるようにしなければならない。
[データの更新]：データを抽出する関数でデータ取得し画面項目にデータ渡しする。データを更新する関数で画面項目から関数にデータ渡しする。これらの関数についてもコメントやドキュメントが必要である。
[データの削除]：これも関数化したほうが望ましい。

SQL文で直接テーブルを更新することはSAPでは禁止されていた事項であった。これは、複数のテーブルの更新を必要としたり、必須項目が抜けている場合にデータの矛盾が生じるためである。そのためには、データの更新処理は関数化しデータの矛盾が生じないようにすべきである。

C++言語が世に出てから数十年経つ。オブジェクト指向言語についての入門書は私も何冊か読んだことがあり、皆さんも学習したことがあるだろう。それにしてもなかなかオブジェクト指向は身につかないものである。GUIのコンポーネントやクラスライブラリを開発しない限り本格的にクラスの機能を使うことはないと思われる。実は私もその手の開発経験がないのでオブジェクト指向については、単なる頭の体操みたいでプログラミングの世界をややっこしくしているように思える。実際のところ私はクラスを作るといっても共通な関数をメンバー関数にしているだけである。インスタンス宣言する必要もないのでstatic関数である。WEBアプリなどはページごとにロジックを組みこんでしまったほうがプログラムがわかりやすく独立性が高い。あえて共通して利用しないようなロジックはクラス化しても意味がない。結局 public　宣言して公開しているメンバー関数やメンバー変数はクラス内で隠蔽化しているとは言えない。したがってやたらにクラスを多様することはナンセンスである。オブジェクト指向言語はあれもできる、これもできるということを売りにしているが、それらの機能をむやみやたらに使うことはプログラム構造をわかりにくくするだけである。

業務アプリケーションではクラスは使えればいい。へたにクラスを作るな。

実は私は45歳を超えている。来年は歳男である。エンジニアというものは職人であるから、床屋、美容師、大工、芸術家、または医者、税理士、会計士のように、いつリタイアするかは自分が決めるものである。エンジニアとして仕事を長続きさせるには、体力切れや突然死、やっかいな病気にかかならいことが第一の条件である。したがって、

我慢することにより、思考能力が低下し、病気やストレスをため込む原因になります。今の不景気な状況では転職先を探すのが大変ですが、転職先を見つけることを薦めます。ストレスがなく適度な労働時間でスキルアップするための勉強の時間を持てるような会社に勤めることです。エンジニアを長年続けていくことにより、逆に若い人に負けない感や経験、文書の作成能力、文書の理解能力ができてきますから、新技術にたいしても理解や吸収は早くなります。歳をとると新技術についていけないのでベテランは駄目だという通説がありますが、その説については私は正反対です。プログラミングやその他のIT技術はインナーネットを検索すればたくさん記事があるので比較的簡単に知識が習得できます。昔は何千円もする分厚い本を何冊も買ったりしてましたが今は情報収集が本当に楽になりました。

まず、プログラミングとデータベースの設計は得意にならなくてはなりせん。一番基本的で重要なことです
業務知識を身につける
ハードウェアの基本知識の習得、サーバーの設定ができるようになる
ネットワーク機器の知識を習得する
メーカーやベンダーの新製品の情報を収集を怠らない
さらにセキュリティ対策などの知識があればなおさらよし

実際にこれだけのスキルを身についけ安定稼働するシステムを構築できるようになるまで40歳前後になってしまうのではないでしょうか？IT技術は変化が激しいですが勉強すればなんとかなります。意外に業務知識を身につけるほうが大変です。クリエイティブで好奇心が旺盛な人はぜひともエンジニアを続けてほしいものです。残念ながらそうでない人はエンジニアの適正がないので他の仕事を選んでください。

Visual Studio 2003 のソースコードを自分の Visual Studio2003の環境にコピーしたところソースは読み込めたが実行ができず、以下のエラーメッセージがIEに表示された。

説明: この要求を処理するために必要な構成ファイルの処理中にエラーが発生しました。以下のエラーの詳細を確認し、構成ファイルに変更を加えてください。
パーサーエラーメッセージ: アプリケーションレベルを超えて allowDefinition='MachineToApplication' として登録されているセクションを使うことはできません。このエラーは、仮想ディレクトリが IIS でアプリケーションとして構成されなかった場合に発生します。

Visual Studio 2003のソース移植の場合は、通常プロジェクト名.csweb.infoファイルを見て、正しいフォルダ構成を組みソースをコピーすれば大丈夫なはずでした。インターネットで情報を調べ、IISでweb.cofig が存在するソースのフォルダのプロパティを開き、仮想ディレクトリタブでアプリケーション名の右の作成ボタンをクリックすれば実行できるようになりました。

今月もWindows2008 R2のセキュリティパッチがMSより大量にリリースされたのでやっかいである。建前上セキュリティパッチとMSは言っているが、実際はバグフィックスと思われる。Windows2003で満足してしまったので、2008、特にR2に関しては64ビットということでなかなかこの不景気な世の中には受け入れがたいものがある。

遅まきながらWindows2008のWindows Serverバックアップを始めて操作してみた。NTBACKUPと違い、ドライブごとにイメージバックアップをするものですね。スケジュール実行の場合は何故かリモートサーバーにバックアップできないようになっていますね。Wbadminというコマンドではこのようなこともできるようです。リカバリは試していませんが、これを使えはSymantecのSystem Recoveryも不要になりそうですね。