ソースファイルに、ヘッダコメントを残すルールになっていてリリースファイルの際バージョンがチェックされるんだけど、今回これが不正だった。
で、見てみると、
/*
Ver.01.00 20090701 担当者A 新規作成
Ver.01.01 20090805 担当者B ○○対応
Ver.01.02 20090813 私の名前 ○×対応
Ver.01.03 20090908 私の名前 ○×対応
Ver.01.03 20090913 私の名前 ○×対応
*/
で、今回01.03でバージョンがあがっていない変更ソースファイルがあるというエラー。
そもそも、私は、01.02しか触っていないのに・・・。他の担当者がヘッダをコピペして内容を変えいないままとなってる。
名前も修正内容もコピペ。さらに今回のはバージョンも変更していないためエラーになっちゃった。
修正担当者がいなくなったので01.03と(01.04)の修正は何だったのかははわからず、リリースまで時間がなかったためソースコメントはそのままでリリース。
間違ったコメントよりもコメントが少ないほうがまだマシなので、バージョンと日付だけ残してあとは消してくれればよかったのに。。。
2009年9月19日土曜日
2009年9月15日火曜日
リンクサーバのトランザクション設定有効化ってどうやるんだったっけ？
SQL Server 2005でリモートサーバへ、DBリンクを張って、
select * from [リモートサーバ名].[データベース名].[スキーマ名].[テーブル名]
で、アクセスすることはできた。また、insert文
insert [テーブル名]
select * from [リモートサーバ名].[データベース名].[スキーマ名].[テーブル名]
で、リモートサーバにある同名のテーブル名をローカルにコピーすることもできた。
ただ、
begin tran
insert [テーブル名]
select * from [リモートサーバ名].[データベース名].[スキーマ名].[テーブル名]
とやると、エラーとなった。（エラーメッセージは覚えていないが、nliが、とかトランザクションがなんとかとかいうメッセージだった。）
たぶん、リモートサーバのMSDTCの設定の問題だと思うのだけれど、なんだろう？
まさかリンクサーバアクセスではトランザクション処理ができないってことはないとと思うんだけど。
select * from [リモートサーバ名].[データベース名].[スキーマ名].[テーブル名]
で、アクセスすることはできた。また、insert文
insert [テーブル名]
select * from [リモートサーバ名].[データベース名].[スキーマ名].[テーブル名]
で、リモートサーバにある同名のテーブル名をローカルにコピーすることもできた。
ただ、
begin tran
insert [テーブル名]
select * from [リモートサーバ名].[データベース名].[スキーマ名].[テーブル名]
とやると、エラーとなった。（エラーメッセージは覚えていないが、nliが、とかトランザクションがなんとかとかいうメッセージだった。）
たぶん、リモートサーバのMSDTCの設定の問題だと思うのだけれど、なんだろう？
まさかリンクサーバアクセスではトランザクション処理ができないってことはないとと思うんだけど。
2009年9月13日日曜日
バッチの作り
月末までに引き継がなきゃいけないものの１つに、C#で作られたバッチがあります。（バッチの部分については、実際に携わったのは1日ぐらいですが、他に知っている人がいないもので。。）
で、このバッチプログラムはメイン処理では、テンプレートメソッドっぽい作り、機能群では、ストラテジっぽい作りでした。テンプレートメソッドはis-a,継承とオーバーライドによる処理の変更、ストラテジはhas-a,インターフェースとコンポジションによる処理の変更の意味で話していますが、デザインパターンは使ったことがないのでデザインパターンの理解が間違っているかも。。。
で、後任がオブジェクト指向の言語に慣れていないとちょっと戸惑うかも。
非オブジェクト指向の言語では、静的解析でも、充分に追跡可能だけども、オブジェクト指向言語だと、静的解析では追跡不可能になってしまう。
具体的に言うと、非オブジェクト指向言語では、問題のプログラムの最初から、呼び出し先に移動→呼び出し元に戻るという操作を繰り返していけば、最後まで到達可能だけれど、オブジェクト指向言語で作られている場合、呼び出し先に移動したところでベースクラスのメソッドやインターフェースのメソッド宣言に移動してしまい、ベースクラスの処理の中で(サブクラスでオーバーライドする処理でも)、ベースクラスのメソッドに移動してしまう。静的解析の場合は、これが限界のような気がします。
トラブルが起きたときに、普通にピンポイントで見たり、流れを順に追っていくとつらいことになりそう。
スーパークラスの役割を理解しておかないと何をやっているかさっぱり分からなくなるからね。
だから、デザインパターンは私にとって使うメリットがさっぱり理解できないです。私はアンチオブジェクト指向派です。
さらにこのスーパークラスで、サブクラスから呼び出すメソッドがあったりして、間違ったデザインパターンの作りになっています。
（テンプレートメソッドでは、スーパークラスに処理の流れが書いてあって、処理の流れの一部、他と違う処理をする機能のメソッドだけをサブクラスでオーバーライドする形で作りこむんだけど、今回のはスーパークラスに何故かユーティリティクラスみたいな機能を追加しています。ユーティリティの機能については、継承関係は全くないので、保守時の混乱を取り除くために別途ユーティリティクラスを起こすべきなのに。。。）
・・・わたくし、コピペ万歳の人なので。。。でも、コピペの作法を間違っているプログラムの作りをしてあって、さらにコピペ処理を失敗しているのを見るともっといらいらしてしまうのだけれど。。。
コピペの作法について、
コピペって、極力変更しないで使うもので、コピー元のプログラムの作りに工夫しておかなきゃいけないのに、その辺の工夫を全くしていないと酷いことになってしまう。（さらに変更しなきゃいけなくなった部分で変更していなかったりしてね。）
で、このバッチプログラムはメイン処理では、テンプレートメソッドっぽい作り、機能群では、ストラテジっぽい作りでした。テンプレートメソッドはis-a,継承とオーバーライドによる処理の変更、ストラテジはhas-a,インターフェースとコンポジションによる処理の変更の意味で話していますが、デザインパターンは使ったことがないのでデザインパターンの理解が間違っているかも。。。
で、後任がオブジェクト指向の言語に慣れていないとちょっと戸惑うかも。
非オブジェクト指向の言語では、静的解析でも、充分に追跡可能だけども、オブジェクト指向言語だと、静的解析では追跡不可能になってしまう。
具体的に言うと、非オブジェクト指向言語では、問題のプログラムの最初から、呼び出し先に移動→呼び出し元に戻るという操作を繰り返していけば、最後まで到達可能だけれど、オブジェクト指向言語で作られている場合、呼び出し先に移動したところでベースクラスのメソッドやインターフェースのメソッド宣言に移動してしまい、ベースクラスの処理の中で(サブクラスでオーバーライドする処理でも)、ベースクラスのメソッドに移動してしまう。静的解析の場合は、これが限界のような気がします。
トラブルが起きたときに、普通にピンポイントで見たり、流れを順に追っていくとつらいことになりそう。
スーパークラスの役割を理解しておかないと何をやっているかさっぱり分からなくなるからね。
だから、デザインパターンは私にとって使うメリットがさっぱり理解できないです。私はアンチオブジェクト指向派です。
さらにこのスーパークラスで、サブクラスから呼び出すメソッドがあったりして、間違ったデザインパターンの作りになっています。
（テンプレートメソッドでは、スーパークラスに処理の流れが書いてあって、処理の流れの一部、他と違う処理をする機能のメソッドだけをサブクラスでオーバーライドする形で作りこむんだけど、今回のはスーパークラスに何故かユーティリティクラスみたいな機能を追加しています。ユーティリティの機能については、継承関係は全くないので、保守時の混乱を取り除くために別途ユーティリティクラスを起こすべきなのに。。。）
・・・わたくし、コピペ万歳の人なので。。。でも、コピペの作法を間違っているプログラムの作りをしてあって、さらにコピペ処理を失敗しているのを見るともっといらいらしてしまうのだけれど。。。
コピペの作法について、
コピペって、極力変更しないで使うもので、コピー元のプログラムの作りに工夫しておかなきゃいけないのに、その辺の工夫を全くしていないと酷いことになってしまう。（さらに変更しなきゃいけなくなった部分で変更していなかったりしてね。）
登録:
投稿 (Atom)