システム開発

サービスを再起動する（フラット）

はなおかじった — Fri, 29 Aug 2008 22:55:00 GMT

サービスを再起動させてみます。唐突ですが、そういう必要が生じたので。

Visual Studio 2008 にて、C++ の Win32 コンソールアプリケーションです。PSDK API を使うので、C++。

説明するのが面倒なので、さくっと行きます。

サービスを制御するには、まず、サービスマネージャにアクセスします。このとき、いくつかの特権が必要です。今回は、考えないことにします。

「再起動」すなわち、「停止してから起動」というコマンドは、無いようです。そこで、「停止する」というコマンドと、「起動する」というコマンドを発行します。

コマンドを発行するには、OpenService 関数で、サービスのハンドラを捕まえ、ControlService 関数を使用します。起動は、StartService 関数です。

サービスは、Windows Service を作成したことがある方ならおわかりだと思いますが、起動指示から30秒以内に起動状態にならなければなりません。逆に言うと、起動を指示したからといってすぐに起動するわけではありません。停止も同じ。よって、停止を指示してから、完全に停止するまで待つ必要があります。また、起動も同じく、完全に起動するまで待ちます。待っている間、QueryServiceStatus 関数で現在のステータスを取ります。

サービスマネージャにアクセスする。
指定のサービスにアクセスする。
停止信号を送る。
停止するまで待つ。
1. 状態を見る。
2. SERVICE_STOPPED でなければ1秒待つ。
  SERVICE_STOPPED なら戻る。
3. 累積で30秒待っていれば、タイムアウトとする。
  そうでなければ繰り返す。
起動する。
起動するまで待つ。
1. 状態を見る。
2. SERVICE_RUNNING でなければ1秒待つ。
  SERVICE_RUNNING なら戻る。
3. 累積で30秒待っていれば、タイムアウトとする。
  そうでなければ繰り返す。

そんなこんなで、次のようなコード。タイトルにカッコがついているのは、これで終われないから。

このコードでは、破棄しなければならないリソースを確保したら、次の関数を呼び出す様にしました。これにより、リソースを使うところ＝次の関数内では、何らかのエラーが発生したら遠慮なしに return することができます。なぜこんな作りにしてあるかというと、本当は .c なコードで使っているから（涙）

で、こいつを元に、「C++（あるいはオブジェクト指向言語）って、C に比べてこんな利点があるんだよ。」ってことが説明できるかな、と。。。セッション資料作った方が面白いような気もしてきた。


// RestartService.cpp : コンソール アプリケーションのエントリ ポイントを定義します。
//

#include "stdafx.h"
#include <locale.h>

DWORD RestartService(LPCTSTR serviceName);
DWORD StopThenStartService(SC_HANDLE manager, LPCTSTR serviceName);
DWORD StopServiceWithWaiting(SC_HANDLE service);
DWORD StartServiceWithWaiting(SC_HANDLE service);
DWORD WaitServiceUntilStatus(SC_HANDLE service, DWORD state, int timeout = 30);

int _tmain(int argc, _TCHAR* argv[])
{
    _tsetlocale(LC_ALL, _T("japanese_japan"));
    if (argc < 2) {
        _putts(_T("引数で、サービス名を指定してください。\n"));
        return ERROR_BAD_ARGUMENTS;
    } else {
        _tprintf(_T("サービス \"%s\" の起動・停止結果 : %d\n")
            , argv[1]
            ,RestartService(argv[1]));
    }
    return 0;
}

// 指定されたサービスを再起動する。
// serviceName : サービス名
DWORD RestartService(LPCTSTR serviceName)
{
    if (serviceName == NULL) { return ERROR_BAD_ARGUMENTS; }

    SC_HANDLE manager;
    manager = OpenSCManager(NULL    /* ローカル コンピュータ */
        , NULL                        /* 規定のマネージャ */
        , SC_MANAGER_CONNECT | SC_MANAGER_ENUMERATE_SERVICE | GENERIC_EXECUTE
        );

    if (manager != NULL) {
        DWORD result;
        result = StopThenStartService(manager, serviceName);
        (void) CloseServiceHandle(manager);
        return result;

    } else {
        return GetLastError();
    }
}

// 指定されたサービスを停止させ、起動する。
// manager : サービス マネージャ
// serviceName : サービス名
DWORD StopThenStartService(SC_HANDLE manager, LPCTSTR serviceName)
{
    if (manager == NULL || serviceName == NULL) { return ERROR_BAD_ARGUMENTS; }

    SC_HANDLE    service;
    service = OpenService(manager, serviceName, GENERIC_EXECUTE | GENERIC_READ);

    if (service != NULL) {
        DWORD result;
        // サービスを停止する
        if ((result = StopServiceWithWaiting(service)) == ERROR_SUCCESS) {
            // サービスを起動する
            result = StartServiceWithWaiting(service);
        }
        (void) CloseServiceHandle(service);
        return result;

    } else {
        return GetLastError();
    }
}

// 指定のサービスを停止させ、停止するまで待つ。
// service : サービスのハンドラ
DWORD StopServiceWithWaiting(SC_HANDLE service)
{
    if (service == NULL) { return ERROR_BAD_ARGUMENTS; }

    SERVICE_STATUS status;
    BOOL ret = ControlService(service, SERVICE_CONTROL_STOP, &status);
    DWORD result = GetLastError();
    if (ret == TRUE || result == ERROR_SERVICE_NOT_ACTIVE) {
        result = WaitServiceUntilStatus(service, SERVICE_STOPPED);
    }
    return result;
}

// 指定のサービスを起動させ、起動するまで待つ。
// service : サービスのハンドラ
DWORD StartServiceWithWaiting(SC_HANDLE service)
{
    if (service == NULL) { return ERROR_BAD_ARGUMENTS; }

    BOOL ret = StartService(service, 0, NULL);
    DWORD result = GetLastError();
    if (ret == TRUE || result == ERROR_SERVICE_ALREADY_RUNNING) {
        result = WaitServiceUntilStatus(service, SERVICE_RUNNING);
    }
    return result;
}

// サービスが、指定の状態になるまで待つ。
// service : サービスのハンドラ
// state : 期待する状態
// timeout : 期待する状態になるまで待機する秒数（既定値 30）
DWORD WaitServiceUntilStatus(SC_HANDLE service, DWORD state, int timeout)
{
    DWORD result;
    SERVICE_STATUS status;
    int count = 0;
    while (TRUE) {
        if (QueryServiceStatus(service, &status)) {
            if (status.dwCurrentState == state) {
                result = ERROR_SUCCESS;
                break;
            }
            if (++count > timeout) {
                result = ERROR_SERVICE_REQUEST_TIMEOUT;
                break;
            }
        } else {
            result = GetLastError();
            break;
        }
        Sleep(1000);
    }
    return result;
}

簡単になるのはいいことなのか？

はなおかじった — Mon, 18 Aug 2008 22:28:00 GMT

また、書いてみようと思う。

LINQ の本を読んでいます。その中で、C# や VB.NET に追加された、ラムダ式、型推論、拡張メソッドといった機能は、LINQ の為に追加された機能で、むやみやたらと使うものではない．．．と、書かれています。

確かに、C# の「型推論」“だけ”が取り上げられたときは、VB の様な「何でも型」が C# に取り入れられるのか！？と、物議を醸し出したように思います。

しかし、実際には、コンパイラが右辺から左辺の型を推論するもので、“コーディングを簡略化する”という説明が、そのときはされていたように思います。

で、実際には、LINQ では、コーディング時にいちいち型を定義しづらい場合があるので、LINQ を実装するために必要な機能だった、ということです。

で、LINQ。（ここから先、オレ理解）これは、データの塊を扱うときに、“どこにあるデータの塊か”ということを、開発者が意識しなくてもいいようにする仕組みです。LINQ to ほにゃららが、どこにあるのかによって最適な形に、コードを展開します。

データベースというと、Oracle, SQL Server, PostgreSQL, MySQL あたりをあげておけばいい？DB2 とか Firebird もあげておく？そんなもんかな？いろいろありまして、SQL99 で標準が決められてはいますが、方言があります。

.NET Framework では、System.Data 名前空間に、いくつかのデータベース用のクラスが用意され、いくつかのインターフェイスが定義されています。この、“いくつかの”ってのがくせ者で、使いにくかったのだけど。

で、接続先ごとに、それら用のクラスを使い、ビジネスロジックではインターフェイスを使うようにすると、複数のデータベースシステムに対応したシステムが作れます。

この方法では、アプリケーション開発者が、SQL のそれぞれの方言を確認し、それぞれにあわせた SQL を組み立て、コーディングします。「ストアードプロシージャでやれ」ってのは、置いておく。

対して LINQ では、アダプター提供者が SQL の方言を吸収するため、開発者はどのターゲットに対しても同じコードを書いておけばよい、ということになります。

確かに、便利です。簡単です。

で、それでいいの？

いえ、問いを変えましょう。「本当に、簡単になったの？」

私は、「いいえ」と思うのです。なぜか。それは、私が「簡単になって欲しい」と思っている対象と、「簡単になる」と言われている対象が違うからです。

LINQ によって、“コーディングは”簡単になりました。しかし、顧客の要望をコードにするところは、簡単にはなっていません。そして、コードを書くことよりも、顧客の要望をコードで表すことのほうが、遙かに難しいと思うのです。

あるいは、この言葉はあまり好きではありませんが、コードを書くことだけに専念する人をコーダーと呼ぶ場合があります。コーダーの仕事は楽になりますが、仕様書を作る人の仕事が楽になるわけではありません。余談：ん～？だからコーダーは安物扱いされるのか？

掲示板などに書き込まれている内容から私が思うのは、仕様書だけを書いている人は、実際に使うものについては無頓着です。何を使おうと、「データベースからデータを参照し、ユーザが編集し、データベースに書き戻す」とだけ書いておけば、自分の仕事は済んだと言わんばかりです一例。それによって、実装者がどれほど苦労しているかも知らずに。。。

で、実装者の方です。これで、本当に簡単になるのでしょうか。

確かに、コードを書くことは軽減されます。しかし、ここで勘違いして欲しくないのは、コードを書くという手作業が軽減されることと、コード化するという頭脳作業が軽減されることは、必ずしも一緒ではない、ということです。

LINQ によって、コード化する手作業は軽減するでしょうが、どのようなデータの取得をしなければならないかという頭脳作業については、軽減されていません。

それどころか、デバッグの時に、どのコードによってどのようなデータが集まってきているのか、わかりにくくなっているかもしれません（実際に動かしたことはないので未確認）。

「簡単になる」のは、いいことなのでしょうか。それはいいことなのでしょう。でも、本当に、簡単になっているのでしょうか。“何を”簡単にしたいのか。そこのところが抜け落ちているような気がします。

作る人。売る人。

はなおかじった — Tue, 05 Aug 2008 22:01:00 GMT

正規社員にコーディングやプログラミングをやらせる意味はあるか？（Coding Edge 会議室）より：

単価の高い正規社員にやらせるとしたらどういう意味があってのことでしょうか？

コーディングは、孫請け以下がやる作業だというイメージが先行しているのでコーダー（プログラマ？）は、社会での地位はあまり高くはないように思えます。
供給過多もありますか？

コーダーが増えれば増えるほど、自社に見返りはなくある業種が儲かるだけのような気がします。

なんつーか。。。

儲かるって、何でしょう？出て行くものより入ってくるものが多いことですね。

出入りしているものって、何でしょう？お金、ですね。

お金って、何でしょう？価値を相対的に表すものではないでしょうか。

では、儲かるって、何でしょう？価値のバランスが崩れている、ってことではないですか？

しかし、ここには、将来的な価値が含まれるとも考えられます。もっとよい商品を作って欲しい。もっとよいサービスを提供して欲しい。そのための、追加された価値です。

しばらく前にも、同じような人いたね。このへん。

極端なことをいうと、作る人は予算以内に作れることを目指せばいい。売る人は、予算以上で売れることを目指せばいい。売る人に作る人と同じ事を求めるのはナンセンスだし、逆もしかり。

しかし、売る人は、売るものを把握しておかなければならない。前にいましたよ。自社製品の名前を正しく覚えていない営業が。そんな営業から「良いものですから、是非」といわれて、信じますか？

作る人、売る人、それぞれに必要とされるものが違います。混同してはいけません。

数字のマジック

はなおかじった — Tue, 05 Aug 2008 21:53:00 GMT

古い記事の焼き直しですが。。。

【セキュリティのずさんな実態】社長は現場の窮状を見ぬふり（ITpro）より：

一般に，経営層がセキュリティ対策にお金を出したがらない理由の一つは，対策を怠ることによって生じ得る損害の大きさを十分に理解できないことにある。だがC社の社長は，これに全く当てはまらない。

もちろん，繰り返し起こる被害に対して，PCの復旧にかかるコスト，PCが使えない間のユーザーの損失などは相当な金額に換算できるはず。しかし，この社長にとっては「通常の人件費」の一部であり，会社の利益を減らさない限り，損失とは考えそうにない。

2005年9月の雑誌記事を、記事としての価値が相当に減った今になってウェブで無料公開している、、、というものでしょうが、3年経ってもあまり変わってないように思えるなぁ。

PC の置き換えにしてもそうなのですが、一時的な費用が発生します。置き換えないと、効率が悪いまま、作業効率が低いままでいるわけですが、その場合費用は長期にわたって分散されます。

この、「分散される」というのがくせ者です。

ローンを組むと、本当は必要な額以上に返さなければならないために損なのですが、月々の金額を見るとそう高いものではないように思えてきます。

ローンより怖いのが、リボ払いですね。毎月一定額と、手数料です。この手数料がくせ者です。ローンによる金利よりも大きな額になります。ローンの“金利”は、法律によって上限が決められています。しかし、リボ払いで払うのは“手数料”です。手数料に上限はありません。「月々一定額」ということが、利用者に対して少ない金額に見せかけるトリックです。

そういえば、手塚治虫の「ブラックジャック」に、こんな話がありましたね。

ある男の子が、交通事故で四肢が不自由になります。そのため、超能力を身につけてしまいます。ブラックジャックは、四肢が元通りになれば、超能力を使う必要がなくなり、元通りになるだろうと言います。そして、手術費用を提示します。その額はとても大きいのですが、「毎日10円ずつ返してもらおう。おまえさんに子供が生まれれば、その子供からも毎日10円だ。」

返す額は変わらないのに、「1日10円」というところで、「そんなに安いの！？」と思ってしまいます。

こんな昔話もありますね。雇われものが、「1日目は1円、2日目は2円というように、前の日の倍の金額でいいです」といって雇われる話。数日間は3桁4桁という金額でしかありませんが、30日目には2^30=1,073,741,824になっています。日払いですから、(2^31)-12=2,147,483,647の収入が得られている、ということになります。あれ？その数の米粒をくれ、という話だったかな？

とにかく、数字のマジックです。少ない額を長い期間をかけて徴収することで、「安い」と見誤らせながら、多くの額を徴収しています。

セキュリティにかけるお金も、これと同じなのでしょうね。いつ、どのような形で支払いが発生するのか。それが、出せる、出せないの分かれ目なのかもしれません。

セキュアな環境を阻むものを考えてみる

はなおかじった — Mon, 07 Jul 2008 21:58:00 GMT

本題の前に、フンワリ考えてみる。

re: Vista UAC の未来をモワモワ考えるより：

「○○してもいいですか？」とセキュリティソフトが聞いてくる。俺もKasperskyを使ってますが、ぶっちゃけ、それをするとどんなリスクがあって、それをしないとなにができないのか、人並み以上にPC知識があるだろうと思う俺でも判断できません。

一応、詳細を読んだりしていますが、わかりません。つまり、情報の提示量に問題があると思います。

また、Kaspersky については、もうちっと調査をしておいてくれてもいいんじゃないの？とも思います。Symantec も同じような機能を実装していますが、標準で Windows に入っている機能については、聞いてきません。すでにルールが組み込まれています。また、どういう基準で選んでいるかわかりませんが、オンラインソフトを含む多くのソフトで、やはりルールが組み込まれています。

# re: Vista UAC の未来をモワモワ考えるより：

User へ選択を委譲しても責任の回避にしかなりません。
そんなんだったら、専門家が定めた policy で厳しく制限を課し利用させる方がよいかと。

ええ、そうですね。Vista の UAC は、その方向へ向かうのではないかと思います。あるいは、「向かって欲しい」と思います。

re: だいめいなし。より：

だったら、インストール可不可チェックの代行業者がいてもいーんじゃないかと。
＃ウィルスチェッカーと同じノリで。
で、業者ごとにブラックリストとホワイトリストを持ってて、それに基づいてインストールの可否を判断する。
個々のソフトについてのインストールの可否はユーザが判断できないけど、その代行業者に対して信頼できるかどうかで判断する。

で、本題。本題の元ネタが、これ↑。

「Windows ロゴプログラム」という、プログラムがあります。「Windows ロゴプログラム : 概要」とか、「Windows Vista ロゴプログラム」とか。Windows Application のロゴプログラム要件に、「最小特権の原則」があります。日本語の資料を探せなかったのですが、英語の資料はこちら→Developer Best Practices and Guidelines for Applications in a Least Privileged Environment

テスト要件も、ダウンロードできますね。いきなりダウンロードしちゃうので、リンクにはしません。→ http://download.microsoft.com/download/a/4/c/a4c003f7-76be-444b-a3b7-4e74b7d5767f/Certifiedfor_ProgramTestCases_1.3J.doc

この中に、「TEST CASE 2. 最小特権ユーザーが他のユーザの文書やファイルを変更できないことを検証する」、「TEST CASE 3. 最小特権ユーザーが Windows System ディレクトリにファイルを保存できないことを検証する」というのがあります。「最小特権ユーザが」という制約がありますが、Windows ロゴプログラムをパスしているアプリケーションは、勝手にシステムファイルを書き換えないことが、第三者機関によって保証されているわけです。かつ、署名されていることも検査されますので、ウィルスなどによる改ざんを検出することもできます。

つまり、Windows ロゴのついているソフトウェアは、比較的安心してインストールできると言っていいでしょう。言い切りませんよ。レジストリに関して、テストケースが見あたりませんから。

100％の安心を保証するものではないにしろ、危険な要素が少ないことは保証してくれるものであります。しかし、大企業を含め、日本企業のソフトウェアの多くは、ロゴプログラムに参加していません。なぜでしょう？

「費用の問題」であったり、「他社の動向を見て」であったりします。

自社製品を使って下さるお客様に「安心・安全」を付加することより、コスト（そりゃ、コストがかかるとそもそも選んでもらえない可能性も出てくるけどね）や周りの目の方が気になる様です。セキュアな環境を阻んでいる要因は、案外、こういう事だったりするのかもしれない。

セキュリティに関しては、リスクです。リスクは、顕在化するか、しないか、わかりません。問題として顕在化しないのであれば、つっこむ金は少なくしておこう、という考え方なのでしょうか。でも、顕在化したときにかかる費用は、顕在化回避のために費やすお金の比じゃないと思うのです。でも顕在化しなければ、無駄金になる・・・これだぁ！！「無駄金」という考え方だ！！

どうにかなりませんかね？

システムハンガリアンを養護してみるテスト

はなおかじった — Mon, 07 Jul 2008 21:54:00 GMT

とか書きながら、養護するつもりはない。しかし、歴史を知っておく必要はあると思います。

Win32 API のリファレンスを見ていてよく見かける（無理矢理組み合わせた、かも）、「lpctstr」という表記。これを、分解してみようかと思います。

まず、「p」から。これは、Pointer の p です。C 言語において、「文字配列」と「文字列へのポインタ」は、同じように扱えてしまえますが、実は違うものです。そのため、「ポインタであること」を明示するのは、読むとき、保守するときに有用です。

次、「l」。これ、よくわかりません。いろいろ読んでいるうちに「これかな？」と思ったのは、「local」か、「long」の「l」です。大昔、扱えるメモリ量が少なかったり、少ない故に小さいバイト数でいろいろ扱うために、DLL や EXE の境界を越えてポインタを渡せなかったようです。「ポインタ」に、「起点からの距離」を表すものと、「絶対距離」を表すものがあった様です。このうち、「起点からの距離」は、起点が違えば指す場所が変わってしまいます。あるいは、「GlobalHeap」という関数がありましたが、特定のプロセスのみで使えるアドレスと、Windows 全体で使えるアドレスか。そのため、これらを分けるために付けられたようです。はい、そこの人！！鵜呑みにしない。自分で確認すること。なんにしても、Windows 2000 の頃には、分ける必要がなくなっています。

次、「c」。これは、Const の c です。関数の引数に対して、「この引数の値は、関数内で変化させない」事を示すために付けられます。関数の入力、出力を明示するために使うわけです。これも、C++ になって const で修飾した場合、コンパイラがエラーを出します。このため、変数の修飾に使用して明示する必要はなくなっています。

次、「t」。これは、Multi-byte charactor set と、wide charactor set の、どちらにでも変化するよ、を表しています。そのため、文字(列)にしかつきません。Win32 API 関数の最後につく、A とか W と同じカテゴリです。

そして、「str」。これは String です。C では、char は「文字」だけでなく、「1バイトの数値」の意味も持っています。このため、「char a[10];」だと、「10バイトのデータ」なのか、「最大9文字の文字列」なのか、わかりません。そこで、str を付け、「文字列」であることを明示したわけです。

他に、整数値につく「i」があります。これは、整数といえど、割り算をすると浮動小数点型に変換されることがあります。こういった、暗黙の変換を防ぐ（注意を向ける）意図を持ちます。

また、short の場合、演算結果がオーバーフローする可能性が高くなりますから、これをレビューで検出できるようにすることもあります。

あとは、符号のあるなしについても、ありますかね？signed char の 0x80 と、unsigned char の 0x81 を比べると、どちらが大きいか。これは、最近だとコンパイラが警告を出してくれます。また、符号の有無と同じように、縮小変換についても警告、あるいはエラーとなるようにコンパイラが修正されています。したがって、変数名に明示する必要はなくなっています。

このように、単に型を示していたのではなく、目視レビューで間違いを検出しやすくするための工夫だったわけです。で、コンパイラが検出するようになったからか、Visual Studio 2008 に付属する SDK のドキュメント（英語）では、これらのシステムハンガリアンな記述がなくなっています（作業中かもしれない）。

このように、C/C++ では、意味がある事でした。しかし、すべての言語で意味があることではない、あるいは、同じ記号であっていいわけではありません。

VB や C# のコードで、型名を明示する必要はありません。特に、「クラスだから」と、「cls」を頭に付けているようなものは、全く意味がありません。

そんな無駄なことをするより、なぜそのような符号を付ける必要があるのかを知り、その上で、使用している言語にそれが必要なのか、同じようにしていいのか、他に追加することがあるか、といったことを考える事の方が重要ではないでしょうか。「システムハンガリアン使うな」とは言いません。しかし、使う前に、それにどんな意味があるか、知って欲しいと思います。

エントリへのコメント紹介

はなおかじった — Thu, 19 Jun 2008 22:32:00 GMT

少し昔のエントリに、コメントをいただきました。その内容が、あまりにも「う～む？」だったので、紹介させていただきます。

re: VB 使うな、開発者なら。

「まぁ　おかしいと思っていても実は正しくなってんじゃん。XPで動いていたんだし」
なんていわれました。
あまりにあっけにとられて　こんな話してると「あれ。これって別に問題ないんだっけ？」
思わず考えてしまったほど・・・

もちろん、「う～む？」なのは、コメントをくださった通りすがりさんではなく、お話の中に出てくる「他の開発者」さんです。

やはりこの手の問題は開発ツールうんぬんではなくて
ちゃんとした知識を持っているか、理解が出来ているか　この一点と言えるのではないでしょうか。

確かに。

私の意見は、「VB の開発環境は、無知でいることを助長するので、開発者なら VB の開発環境を使うな」と書くべきだったのですが、「無知で居続けようとする」人にとっては、開発環境が何であっても関係ないのですねorz

最後になりましたが、通りすがりさん、コメントありがとうございます。また、反応が鈍くてごめんなさい。

コメントの間違いは、プログラムのバグに等しい

はなおかじった — Fri, 06 Jun 2008 23:27:00 GMT

再帰によるスタックオーバーフロー？（C# と VB.NET の質問掲示板）より：


//再帰処理部分。
private bool checkloop(string grp, string ffiscalyr, int fperiod)
{
    int Row;
    string wkKOgrp;

    //パラメタで渡されたコードが親コードとしてもつ行の行数を取得。ない場合は-1
    Row = Find(dtSet, grp, ffiscalyr, fperiod
        , 0 ,int.Parse(dtSet.Tables[0].Rows.Count.ToString())-1);

    while (Row > -1)
    {
        wkKOgrp = dtSet.Tables[0].Rows[Row].ItemArray[1].ToString();

        //一番おおもとの比較値と比較
        if (SerchTarget == wkKOgrp)
        {
            return true;
        }
        else
        {
            //自身を再度呼び出す
            if(checkloop(wkKOgrp,ffiscalyr,fperiod) == false)
            {
                //現在の行数以降で、パラメタで渡されたコードが親コードとしてもつ行の行数を取得。ない場合は-1
                Row = Find(dtSet, grp, ffiscalyr, fperiod
                    , Row + 1, dtSet.Tables[0].Rows.Count - 1);
            }
            else
            {
                return true;
            }
        }
    }

    return false;
}

//子コードが一致したデータの行数を返す関数
private int Find(DataSet ds, string GRP, string ffiscalyr, int fperiod
    , int startrow, int endrow)
{
    int i;

    for (i = startrow ; i <= endrow ; i++)
    {
        if ((ds.Tables[0].Rows[i].ItemArray[0].ToString() == GRP)
            && (ds.Tables[0].Rows[i].ItemArray[2].ToString() == ffiscalyr)
            && (int.Parse( ds.Tables[0].Rows[i].ItemArray[3].ToString()) == fperiod))
        {
            return i;
        }
    }

    return -1;
}

ん。。。呼び出し側に書かれたコメントは、親コードとしてもつ行の行数。実際の定義に書かれたコメントは、子コードが一致したデータの行数。

親コードが一致するのか、子コードが一致するのか？

人間、自分が読めるもの、つまり日本語にまず目がいく。すると、呼び出し側と定義側で違うことが書いてある。まず、とまどう。

そうすると、コードを読まないといけない。ここが、本当にしたいことをしているのかわからないから。日本語を読むのと、コードを読むのと。どっちが時間がかかるだろう？あるいは、1行の日本語を読むのと、数行のコードを読むのと、どっちが時間がかかるだろう？

そして、Find メソッドがしていること。

引数 ds の0番目に定義されているテーブルを、startrow 番目（0起点）から検索を初めて、endrow 番目までに、0列が GRP、2列が ffiscalyr、3列が fperiod である行があれば、その行番号を返す。

「行数」を返しているわけではない、と。

コメントに「行数」と書いてあるので、「行の数」が返ると思って「行数」と、「行番号」は、一致しないですよね？とコメントしたのだけれど、「行番号」を期待して、「行番号」が返っている。コードを、すこ～ししか読んでいなかったので、間違った返信をしてしまった。

質問に対する返信だから、まだいい。私がこのコードを直す役を負っていたら、間違いなく呼び出し側に修正をかけている。そして、バグを作り込み、慌てて元に戻すことになっている。あるいは、コードを読んで違いに気がつき、「どっちやねん！」と叫ぶことになる。これもまた大変で、他から呼びされていないか確認し、呼び出されていればそれらが期待しているものをコードから読み取る羽目になる。「global って、便利なの？」も参照。

たま～～～に、メンテナンスされていないコメントを見かけます。メンテしてください。コメントの間違いは、バグに等しいのです。

global って、便利なの？

はなおかじった — Thu, 05 Jun 2008 22:12:00 GMT

元ネタ→【PHP】変数の受け渡しについて！

グローバルにスコープを持たせる方法をご存じでなかったらしい。それは、今回関係ない。関係あるのは、この言葉。（グローバルって）便利ですねこれは！

便利なのか？

確かに、「便利！」と思うかもしれない。

C 言語から C++ に以降したての頃・・・いや、移行していないな。移行しようとしていた頃、クラスの中に定義すると、インスタンスを作成しないと見えない、クラスの外から見えない、というのが、非常に使いづらかった。

で、まぁ、C++ だから、みんながインクルードするヘッダファイルに書いちゃうわけだ。

ん。。。今考えると、C でも、とっても怖いことしていたなぁ。。。

「あれも、これも、あっちでもこっちでも使いたい。でも、見えない。だから不便。」そんな風に思っていた。

オブジェクト指向の「カプセル化」に慣れてくると、それがいつの間にか、「あっちからもこっちからも変更できてしまう。なんて危険！！」に変わっている。。。

ん～！おもしろい！！

まぁ、確かに、作るときは、作るときは、作るときは、…これくらい強調しておけばいい？作るときは、どこからでも参照できるのは、便利。でも、デバッグするとき、機能追加するときに、地獄が見られる。かもしれない。

修正するときに一番気を使うのは、「他の機能に影響を及ぼさないか」ということです。どこでも参照できる変数というのは、保守するときには「どこで参照されているかわからない変数」に変わります。そして、「作っている期間」より、「保守している期間」の方が、遙かに長いです。

つまり、「この、global スコープで定義されている変数の内容を、ここで変えていいのだろうか？」ということをず～～～～っと考えながら保守しなければなりません。

「どこで使われているか、grep かければわかる」ですって？

確かに、どこで使われているかは、わかります。でも、「いつ使われているか」までは、わかりません。

「cflow かけて（まだあるのか？）呼び出し図つくればええやん」ですって？

あれ？cflow となんだっけ？よくお世話になったのに、忘れちまった...

で、結局、コードを読まないと、変更していいのかどうかは、わからないわけです。

この辺でね、地獄になるのですよ。

DLL-Hell といい、怖いもの見たさはいいと思います。見るのは、いいと思います。でも、体験する必要は、ないと思いますよ？

基本、菠薐草

はなおかじった — Wed, 28 May 2008 23:49:00 GMT

元ネタ→件名：プログラムを修正してデバッグしても、修正した結果が反映されません。（Insider.NET 会議室）

しょっちゅう書いているけど、ウェブコミュニティって、最終手段だと思います。

理由は簡単。単位時間当たりの情報の濃さが違う。

まず、問題が解決できる過程をおさらいしましょう。

ほぼすべての問題は、時間が解決してくれたりしません。解決に向けて何らかの行動を起こして初めて、解決に向けて動き出し、解決できます。

では、「解決できる」ために、どうすればいいのでしょうか。

問題を把握する
まずは、問題を把握しなければなりません。「問題を把握する」とは、ある事象を「問題である」と認識するところから始まります。
1. 問題を認識する
  当たり前ですね。「問題だ」と認識しなければ、問題ではないのです。つまり、「見なかったことにしよう」「なかったことにしよう」というのは、問題を「問題である」との認識を捨てると言うことです。認識を捨てると、問題ではなくなります。したがって、問題を解決するためには、「問題である」と認識するところから始まります。
2. 問題である事象を認識する
  問題であると認識ができれば、次はその問題の具体的な事象を認識します。人に話すとき、「問題なんです」としか言わなければ、「何が問題なの？」と聞かれるでしょう。その「何が？」を明らかにします。
  
  問題である事象を認識するとは、問題である事象と、問題でない事象の差異を明確にすることです。
  
  たとえば、我々が医者に行くとき、「何となくしんどい」とか、「何となく気分が悪い」という、不明瞭な不調を訴えます。医者は問診や検温、時には検尿なども行い、何が問題であるのかを明らかにします。この行為に相当する行為を、行うわけです。
3. 事象の再現手順を確認する
  どんなことが発生しているのか、確認ができました。次は、その事象が必ず発生するのか、確認します。そして、必ず発生する条件、手順を明確にします。この、手順と条件が明確でなければ、もし修正しても、修正が正しく行えたのかどうかを確かめることができません。
4. 問題を報告する
  多くの人が、何らかの組織に所属して、その組織の「仕事」として、問題解決に当たっていると思います。
  
  私は、仕事をする上で「報告」することが重要だと思っています。
  
  なぜか？
  
  報告するためには、上記のように明らかにしたことを、短くまとめなければなりません。この、「まとめる」という作業が、問題を把握するために役に立つからです。
  
  漠然と「知っている」ことを、明確に「理解している」に進めます。問題を理解していないと、次の解決策を練るときに苦労するからです。
  
  そのために、上役に報告します。上役が理解できなければ、理解できなかったことを補足するように求めてくるはずです。そこが説明できるかどうかで、問題を「理解している」かどうかがわかります。
解決策を考える
問題の把握ができると、今度はその問題の解決策を考えることになります。
1. 問題である事象の差異を埋める
  先に、「問題である事象」と、「問題ではない事象」の差異を明らかにしました。この差異を埋める方法を考えるわけです。
  
  先に、問題が発生する条件と手順を明らかにしました。その条件と手順の時に、なにが、どうなっているのが問題かわかっているわけですから、そうならない方法を考えればいいわけです。
2. 差異を埋めることで発生する影響を調べる
  あまり行われていないのではないか、と思われる事です。
  
  ある条件、ある手順の時のみ問題が発生しているのであれば、その他の条件では問題は発生していないわけです。では、今、その問題を修正することで、他の部分に悪影響が出ないでしょうか？
  
  あるバグを直すために別のバグを作り込む。そのバグを直すために、前のバグを取るために行った修正を元に戻す。なぜか、よくあることです。なぜ、よくあるのでしょう？修正が及ぼす影響範囲の調査が不十分であったり、そもそも問題を把握できていないためです。こんな事がないように、影響範囲を調べなければなりません。
3. 試験してみる
  影響範囲の洗い出しを行って、その他のところに影響しないとわかったら、本当にそうか、試してみます。ここは、試すだけです。まだ、本当に修正を行うわけではありません。
4. 解決策を相談する
  やはり、上役に報告です。しかし、今回は、「相談」です。これは、問題の解決のために何を行うか、どんな影響が考えられるか、実際に修正した結果どうだったかを報告することで、修正を行ってよいかどうかを尋ねます。決して、「解決策を尋ねる」わけではありません。
修正する
問題を把握し、解決策を出し、その解決策に Go! が出たので、修正を行います。修正を行った場合は、退行試験、デグレッションテスト、整合性確認を行います。今行った修正で、本当に他のところに影響がなかったのか、確認します。

そして、やはり最後も報告です。どの問題について、どのように修正を行い、どんな確認をしたのか、報告します。

さて、元に返って。

ウェブコミュニティで尋ねることは、上記の「解決策を考える」、その中でも特に「問題である事象の差異を埋める」になります。したがって、ウェブコミュニティに出す「質問文」には、把握している問題の報告ができなければならない、と思います。

ここにあげた「問題解決の手順」は、ウェブコミュニティで問題を解決するためには不十分です。

なぜでしょう？

上記は、「自己解決の手順」だからです。他の人と協力して解決にあたる場合、互いの認識をあわせる必要があります。この「互いの認識」とは、相手がどれくらいのことを知っているのか、相手がどのような制約を持っているのか、相手がどのような経緯をたどってきたのか、などです。

私が、「ウェブコミュニティで聞く前に、周りの人に聞いてよ」というのは、この、「互いの認識をあわせる」ためなのです。あなたの周りの人は、ウェブの向こうの人よりあなたのことを知っているはずです。その人でさえわからないから尋ねることは、ウェブの向こうの人もほぼ間違いなくわからないのです。この、「伝わると思って伝えようとしなかったこと」を少なくするために、まず、周りの人に聞いて欲しいのです。

もう一つ、私は「損得」という言葉を使います。この言葉をなぜ用いるか、理解されていないようです。

10年ほど前。私の時給は、月給を標準時間数で割ると、1100円ほどでした。しかし、会社は、私が1時間働くと、4500円ほどの費用を費やしていました。私が「損」といっているのは、答えが得られる、得られないではありません。この、4500円というお金のことです。

このお金、開発者原価について、わんくま勉強会で「意識していますか？」と聞いたことがあります。個人で事業をされている方は意識されているのですが、会社勤めで給料をもらっている方は、意識されていない方がほとんどでした。

このお金を意識してください。10年ほど前にいた企業では、開発者一人につき、1ヶ月1百万円でした。人月です。ことあるごとに否定したい人月単価ですが、それで動いている（いた）以上、否定しても仕方ありません。1日の標準労働時間が8時間、週5日で40時間。月21日として168時間。1百万円を168時間で割ると、約5950円。

問題解決のために、1時間につき約6千円を消費しているのです。

私は、損だと思います。

私がそれを意識するようになった10年前にいた会社は、逆ザヤでした。時間当たり、本当は4500円ほどかかっているのに、見積単価は4400円だったのです。見積もった時間通りに実施すると、損が出るのです。

そのようなところにいたので、問題が解決できるかどうかを、他の時間で動いている人をアテにするウェブコミュニティで尋ねるというのが、とてももったいなく思います。自分でコントロールできないのですから。

あ、タイトルは、「ほうれん草」、すなわち「報告連絡相談」です。「連絡」が出てこなかったな。これは、適切なタイミングで進捗状況を連絡することです。