ホワイトプラン…でなく、ホワイトペーパー

先日、日本ユニシスからNET Framework 1.1環境から
最新版の.NET Framework 3.5への移行方法をアプリケーション構築の観点から検証した
ホワイトペーパーが公開されました。
1.1〜2.0SP1への移行についても言及しているため、非常に参考になります。

私は今年.netframework1.1から2.0SP1に移行しましたが、
そういった情報が少なかったため見積もりが甘くなってしまいました。
これが半年前に公開されていれば・・・

ホワイトペーパーは以下のURLよりダウンロード可能です。
http://www.unisys.co.jp/dotnet/pdf/netFramework_migration_1.1_to_3.5.pdf

C#でも逆コンパイル

先日、オフショア先に自分が修正したソースをメールで送付しました。
修正自体は対したものでは無かったため、当然オフショア先でも動作確認は問題ないだろうと思っていましたが、
「エラーが出て動かない」と連絡がありました。

「そんなはずは無いんだけどなぁ･･･」と思って、
ソースの反映漏れは無いか確認して貰いましたが、
反映している。とのこと。

どう考えてもソースの反映漏れしか思いつかなかったので、
オフショア先のソースを全て送付して日本側で確認しましたが、
確かに全て反映されていました…。

私が修正したソースはオフショア先でも多少の修正があったため、
単純にファイルを上書きしたわけではなく、エディタで反映させたものもあるようでした。

「まさか、修正したソースをセーブする前にビルドしてしまったわけではないよなぁ…」
と思いながら、
オフショア先のexeを逆コンパイルしたところ・・・
逆コンパイルしたソースには一部しか反映されていませんでした。（笑）
修正して最後にセーブしないままビルドしたのかな？

同じ場所で開発をしていればすぐに分かる物ですが、
違う場所で開発をしているためか、最初はそういったことは疑いもしませんでした。
特に実行環境がVistaであったため、
Vistaの設定がオフショア先と日本側で違うのではと思ってしまったのです。
(修正した箇所がWEBサービスであったため、
ネットワークの設定を疑ってしまった）
お陰でこんなことで半日も時間を費やしてしまいました。

その時使用した逆コンパイルツールは「Reflector for .NET」です。
説明は下記を参照
.NET逆コンパイラと
コードを難読化するDotfuscator

ツール自体は知っていましたが、まさかこんな時に役に立つとは思っても見ませんでした（笑）。

その時のやり取りは下記のとおり。

中国側：頂いたソースでは正常に動きません。
私　　：何かエラーは発生していますか？
中国側：SoapException〜が発生しています。
私　　：(SoapException〜？
        WEBサービスを修正したから、ネットーワーク関連のエラーか？
　　　　いや、しかしそのエラーはクライアントからサーバにWEBサービスの実行要求を行った時に、
　　　　該当のWEBサービスメソッドが存在しない場合に発生したエラーと全く同じだな。
　　　　追加したWEBメソッドが反映されていない可能性が高そうだ。）
中国側：日本側では正常に動作しているのですか？
私　　：日本側では正常に動作しています。
中国側：それでは環境の違いでしょうか？
私　　：うーん。どうでしょうね。私が送ったソースは全て反映していますか？
中国側：（ブリッジSEと担当者がここでソースを確認・・・）
中国側：全て反映しています。
私　　：（本当かなぁ。ちょっと自分で確認してみたいなぁ）
私　　：念のため中国側のソースを送ってもらえますか？
中国側：了解しました。
私　　：（ソース受領後）
　　　　（あれぇ。たしかに全て反映されてある。
　　　　　それではネットワークやPCの設定等の環境の違いなのか？
　　　　　念のため動作しないと言っているexeも送ってもらうか。）
私　　：すみません。念のためコンパイル後のExeも送って頂けますか？
中国側：了解しました。
私　　：（確認したソースは問題無かったから、
　　　　　ソースを上書き保存しないでビルドしたってことはさすがにないよなぁ。
　　　　　まぁ。駄目元で逆コンパイルしたソースも確認しておくか・・・）
私　　：（逆コンパイルのソース確認後）
　　　　 ガハッ。修正したソース反映されてないじゃないか（笑）。
私　　：すみません。もう一度ビルドして試して頂けますか？
中国側：了解しました。
中国側：（数分経過）すみません。こちらにミスがあったようです。
　　　　正常に動作しました。
私　　：安心しました。（苦笑）

（実際のやり取りはお互いに環境周りの調査等行ったため、
　こんな数分のやり取りではなく、半日以上掛かりました）

うーん。正常に動作しなかったらせめて一度はリビルドして試して欲しかった。

同じ場所で開発していれば、

相手：正常に動作しません。
私　：えっ！本当ですか。念のためリビルドしてもらっていいですか？
相手：了解です。
相手：あっ。正常に動きました。すみません。セーブし忘れていました。
私　：よかった。

といった感じで数分で解決すると思います。

オフショア開発ということで、
全然違う場所で開発しているため、
そういったこと（再確認）は既に行っていると思っていました。
それで環境周りの確認も行って無駄に時間をついやしてしまいました。

今回のまとめ？

■少しでも疑問に思ったことは、すぐ確認。
■口頭だけの確認では無く、エビデンスも確認する。
　（今回の例では、オフショア先のソースとExe)
■自分（日本側）の考え、手順等を当たり前だと思わない。

といっても当たり前のことですね。
その当たり前のことがなかなかできていないです。
反省、反省。

コメントのつけ方について

ソースのコメントの付け方は賛否両論ありますが。
オフショア開発についてはどうすべきでしょうか。
現在中国に実装を依頼していますが、
出来上がったものはコメントが皆無、もしくは微妙な内容です。

私はコメントは積極的に記述して良いと思っています。
特にコードから読み取りにくい実装背景等はコメントとして記述して欲しいです。

例１．netframeworkのこのクラスはバグがあるためこのクラスに変更
例２．実行環境が〜の場合、〜となる場合があるため、〜の処理を行う。
（例としては微妙ですが）

実装理由を書いてあると修正する場合に影響範囲の調査漏れや、
勘違いということを防ぐこともできます。
また、工数も若干ながら少なくなります。

コーディング規約にコメントのことは記載しておらず、
良いコメント例というのが思いつかなかったため、
特にコメントを書けとは指示していない状況です。
このままでは保守も大変だなぁと感じています。
日本側でコメントを付けるのもあまりいいやり方では無いと思っています。

実装者が会社にいればその人に修正を頼めますが、
中国では人が辞めやすいです。
実際に他のプロジェクトではオフショア先の中国人で会社を辞めた人がいます。
日本では会社を辞める場合は、数ヶ月前に上司に伝えるのが多いと思いますが、
辞めた中国人は上司に伝えて1週間後には辞めてしまいました。
そのため引継ぎも十分に行われていません。

最初は中国側も担当者が慣れていないため時間を掛けて担当者を育てていく必要があると思いますが、
すぐに辞められては困る。
どうすべきか・・・。すぐに辞められても困らない状況を作るべきか・・・。
（日本側で実装内容も詳しく知っておくには、そのための工数も掛かってしまいます。）

中国とのオフショア開発

現在仕事で中国人とオフショア開発を行っています。
体制としては、中国側がブリッジSE1人、PM1人、PG2〜3人（PGについては詳しくは分かりません）
という体制で、
構造設計（基本設計）、詳細設計、コーディング、単体テストを依頼しています。

そのため殆どの作業を依頼しており、
日本側の作業は中国からの仕様や技術的な部分についての問い合わせを対応しています。
後は進捗確認ですね。

よく、文化の違いやコミュニケーションについて大変だと言われますが、
実際に大変だと言われても「どう大変なのか」ということが分からなかったため、
前もって対策を行わなかった結果、
成果物の品質が悪いということが判明して日本側のチェック作業が増えて
日本側の作業で予想以上の工数を使用している状況です。

そんな中オフショア開発のことを取り上げているメールマガジンを発見しました。
オフショア開発専門メールマガジン

このメルマガでは、失敗例等を具体的に取り上げているため参考になっています。
読んでいて「あるあるｗ。」と思うこともしばしば。

オフショアでは前もって注意しなければならないこと具体的に知って、
対策をする必要があるためこういったメルマガやWEBを使用して普段から情報収集をしなければ、
オフショアは難しいためオフショア開発にはご注意を。

メール送信テスト

※2008/07/07に記事の内容を修正しました。
　(メール送信時はSMTP Serviceをインストールすることが必須だと勘違いしていたため、
　 一部の内容修正しました。）

C# & WindowsXPでは、
簡単にメール送信プログラムを作成することが出来るということで
メール送信プログラムを作成してみました。

使用したクラスは
System.Net.Mail.SmtpClient クラスを使用します。
使用方法は下記を参照
NET Framework 2.0で電子メールを送信するには？

なお、SMTP Serviceをインストールすることによって自前でSMTP Serverを立ち上げることができます。
その場合の注意事項としては、プロバイダ等の外部のSMTPサーバに対してメールを送信する場合は、
SMTP Serviceの設定が必要です。
ローカルなSMTPなら問題無いのですが、外部ドメインを使用したメールへの送信は禁止されているとのこと。

この設定方法は、下記の通り
SMTPメール・サービスの中継機能を有効にする

※普通にメール送信を行うだけならSMTP Serviceのインストールは不要です。
SmtpClientクラスのHostプロパティにプロバイダのSMTPサーバ名を設定するだけでＯＫです。

まとめ

■Windows XPでメール送信プログラムを容易に作成可能。

■IISのSMTP Serverを使用して自前のSMTP Serverを用意する場合で、
　外部ドメインのメールアドレスに送信する際にはSMTP Serviceの設定で、
　「中継の制限」で、外部ドメインを許可する必要がある。

既存アプリのVistaでの動作

.netframework1.1で作成されたアプリをVistaに対応させることになりました。
XPとVistaではアーキテクトが違っている部分が多々あるため、
どれくらい動作するかは実際にテストするまで分かりません。
予定では1ヶ月を目処に行う予定ですが、
全然動作しないようなら非常にまずい状況です。

そんな中実際に動作させてところ・・・。
ほとんど問題動きました。（ホッ）。
今のところ動作しない部分は下記の通り。

SMTP Service　を使用している処理。

また動作はするために設定が必要な処理は、

Microsoft MessageQueue(MSMQ)

MSMQは「コンピュータの管理」より、
アクセス権限の設定をする必要があります。
最初は動作しませんでしたが、
使用しているユーザにフルコントール許可のアクセス権限を設定したところ
問題なく動作しました。

まだテスト中ですが、一通り動作はします。

補足：Vistaではセキュリティが非常に厳しいです。
何か動作しない時にはセキュリティの権限をまず疑うのが良いかもしれません。
SQLServer2005Expressをインストールした時も、
デフォルトではセキュリティの権限が設定されていません。

■

仕事でASP.netで作成されたWEBアプリケーションで、
Session変数を使用してページ間のデータの受渡しをしているのですが、
そのSession変数が消えるということが発生しました。

問題が無い時と問題が発生する時があり、
以下の状況で発生していました。

■framesetを使用している。
■IEのCookieの設定の「自動Cookie処理を上書きする」をOFf

いろいろ調査したところ、Microsoftのページにこんな内容が、

Internet Explorer 6.0 で FRAMESET を使用するとセッション変数が失われる

なるほど、framesetを使用するときのsession変数の使用には注意する必要がありますね。

要約としては、

■ASP.netでframesetを使用した場合にsession変数を使用すると
　session変数は保存できるが
　ページが遷移して別のページに移った時にsession変数が消えてしまう場合がある。

■回避方法は以下の2通り
　1.IEのインターネットオプションから、
　「プライバシー」−「詳細設定」−「自動Cookie処理を上書きする」をOnにする。

　2.IEのインターネットオプションから、　
　「プライバシー」−「サイト」から、ページ遷移先のアドレスを追加する。

1.の方法ではセキュリティ面に不安があるため、
2の方法が良いですね。

Microsoftではバグではなく仕様であるとのことです。
まぁ、もともとframesetを使用してのフレーム分割は推奨されていないため、
極力使用しないようにしたいですね。