TimberLandChapel's Tech Blog

TimberLandChapel provide Tips, tech note and scribbling.
Updated my site as English site for APAC users.
TLC.com .Metrix 4.0 Beta1 released

サイトの日本語化方法はこちら

Syndication

News

INETAJ

情報処理関係官公庁

SQL Server

TLC.com

Microsoft

クリエイティブ・コモンズ

http://www3.clustrmaps.com/

10月 2005 - Posts

ここのところ,更新をさぼっているのよりももっと長いこと

・開発プロセス

・メトリクス

・マネージメント

・パターンプラクティス

と上流工程に関する本ばかりを読んでいました。そこで「コンストラクション」に回帰してみることに。

※コンストラクション 実際にコードを作る工程。コーディングとテストを包括して言う場合が多い

なのでやっぱりここは

・CODE COMPLETE

http://www.microsoft.com/japan/info/press/JPN_ViewMsPress.asp?Book_id=1005&list_id=1

でしょう。

ということでもう一度読むことに。

そして読み返し始めた初日。せっかくだから最初から最後までCOMPLETEしてみようと。

そこで「電球がともる」フレーズに。

コンストラクションはどんなプロジェクトにも必ず存在する工程である

ごもっとも!!

要求分析,設計,マネージメント。

どれをとっても重要な工程ですし,事実ここでの生産性が後々に響くと思ったからこそ,

ここのところ,それに注力してきました。

でも,

現実のプロジェクトでは

・要求分析がおこなわれないまま,なし崩しに開発に取り掛かる

・設計について議論する前に構築が始まる

・バグ改修に終われるあまり,テストがおろそかになる

どれも,現実をある意味写し取っています。

が!!

それでも,コンストラクションは絶対になくならない。

コンストラクションはソフトウェアを作る作業そのものだから,これなくしてソフトウェアは成り立たない。

あー。

そうだよな。

当たり前なんですけれど,「電球がつきました」

ちょっともう一度読むのがますますたのしくなってきましたなのです。

ポリモーフィズム:多態性,多相性

仮想関数のデザインを利用して,
実装時に仮想関数によるメソッド呼び出しを行っておくと,
将来の仕様拡張が起こったときに,仮想関数呼び出し部分のほとんどを書き換えなくてよくなる。
という,オブジェクト指向言語の利点のひとつ。

が。

これが利用できるのは,
きわめて凝集度が高くて,疎結合なメソッドに限られる。
もしくは,
メソッドを凝集度が高くて,疎結合なメソッドにデザインする必要がある。

無計画にポリモーフィズムを利用しようとしても,
結局は仮想関数では対応できなくなってしまって,
別メソッドを立てなければならなくなってしまう。

これを防ぐためには,
とにかく問題領域のモデリング。
仮想関数を高度に概念化して,モデル時点で機能をしっかり切り分ける。

 これって,未来を予想しているよ?

モデリング時点で,
将来の発展性を把握していないと,そのレベルのモデリングはできない。

・将来このシステムは Web に乗っかるかもしれない。
・将来この課金計算メソッドは,課税情報が変わるかもしれない。

こんな情報も把握していなければ,
その時点での最適なモデリングは望めなくなってしまう。

アーキテクトは,変更管理委員会ではないし,ましてや経営マネージャーではない。

どうするか?
やっぱり,ヒアリングか。

我々情報処理技術者には,
扱っているものが,「情報」というだけで,
それが流れている全てのプロセスに
(受注,生産,把握,経営なんでも,今の時代情報が流れないプロセスはビジネスに存在しない)
ある程度の知識が求められる。

だから,ここは世界の縮図で,中心なのかもしれない。。。

来る23日の Workshop のアジェンダを公開いたしました。

2005/10/23 第2回 TLC.com Workshop@東京
http://blogs.timberlandchapel.com/blogs/workshop/archive/2005/10/01/438.aspx

よろしくどうぞ

 

Posted by timberlandchapel | with no comments

Windows に関する重要な更新やセキュリティパッチをダウンロードして設定するプラットフォームは

今までは,

・Windows Update

・Office Update

など,バラバラに運用されていました。

これが,今は「Microsoft Update」として統合されていっています。

今は,従来の Windows Update の機能と Office Update の統合程度ですが,今後はさまざまな製品の更新を一括で管理していけるようになるのではないでしょうか?

ですが,

SECURITY SUMMIT 2004 ではあれほど熱く主張していた Microsoft Update ですが,

エンドユーザーにはまだまだ知られていないんではないでしょうか?

既定では何もしなければ「Windows Update」に接続してしまいます。

Windows Update のホームに 「Microsoft Update にアップグレードしてください」の告知が出ていますが,

そもそも更新に無関心な層のユーザーが明示的にこれをクリックするのは稀ではないかと思います。

せっかくの統合ソリューションなので,もっともっと広めていってもいいのかなと思います。(トピックとしては非常に古いですが。。。)

Microsoft Update にアップグレードしてしまうと,Windows Update に接続してもリダイレクトされてしまうのでご注意を。

Posted by timberlandchapel | with no comments
Filed under:

ちょっと前にアップされていたようなんですけど,気づいてませんでした。

Pattern & Practice に SQL Server のパフォーマンスに関するコンテンツがアップされています。

 

第14章 SQL Server のパフォーマンス向上

http://www.microsoft.com/japan/msdn/enterprise/pag/scalenetchapt14.asp

 

ざっと目を通したんですが,

読み応えもあるし,一方でプロジェクトに関係あるところだけ拾い読みするだけでも効果がある

かな,と。

2時間程度のちょっとしたプロセス改善ミーティングなどでいかがでしょう?

Pattern & Practice Home

http://www.microsoft.com/japan/msdn/enterprise/pag/scalenetchapt14.asp

Posted by timberlandchapel | with no comments
Filed under:

PressPass にのりました。

スティーブン シノフスキーが語るOffice “12” における PDF 形式のサポートについて

http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2436

便利になりますなぁ。

がんばって崩れないように変換してほしいです。

 

今月23日に 第2回 Workshop を開催します。

今回は,ASP++ の Moo さんがセッションリーダーを務めてくださることになりました!

詳しくはこちら

 ↓

http://blogs.timberlandchapel.com/blogs/workshop/archive/2005/10/01/438.aspx

Posted by timberlandchapel | with no comments

System Center Data Protection Manager 2006 日本語版が発売されます。

TLC はまだ評価していませんが,デベロッパーとしては非常にわずらわしくて考えたくない

IT インフラの復旧作業が楽になるかな?

 

System Center Data Protection Manager 2006 日本語版ホーム

http://www.microsoft.com/japan/windowsserversystem/dpm/default.mspx

DPM の FAQ

http://www.microsoft.com/japan/windowsserversystem/dpm/evaluation/faq.mspx

評価版の取得

http://www.microsoft.com/japan/windowsserversystem/dpm/evaluation/trial.mspx

 

Posted by timberlandchapel | with no comments
Filed under:

10/4 は SECURITY SUMMIT 2005 に参加してきました。

基調講演は,本社 バイスプレジデントの マイク・ナッシュ 氏が担当されました。

大枠として,

Trustworthy Computing 構想を採用したことによる成果を報告と,

そして,より一層この Trustworthy Computing を推進していくことが訴えられました

 

中でも目を引いたのが

Windows Vista に向けて開発が進められている IE 7 の新機能のデモです

・ActiveX Opt

・Fishing Filter

のデモが行われました。

さらに,日本向けで特に重要なのが,

「Winny」に対するワーム「Antinny」を削除するツールを無償で提供することが発表されました。

これは,10/12 から Windows Update やダウンロードセンタからダウンロードになるようです。

 

SECURITY RESPONSE CENTER にも力を入れていくそうなので,IT Pro の方は要チェックですね。

Posted by timberlandchapel | with no comments
Filed under:

先日,ブログに書いた日本語長音「ー」の問題ですが,

http://blogs.timberlandchapel.com/blogs/timberlandchapel/archive/2005/10/02/443.aspx

MVP の河端さんがさらに細かく検証してくださいました。

SQL Server 2005 Sep CTP: 文字列処理の問題
http://blogs.sqlpassj.org/yoshihirokawabata/archive/2005/10/04/14414.aspx

結果的に,

CTP Sep でも問題は解決されていません。

また,SQL Server 2000 の Japanese_CI_AS のときと同じように 「AA」「Aー」問題などがやはり存在しています。

より多くの検証と,フィードバックが必要になると思います。

引き続きレポートしていきたいと思います。

 

Posted by timberlandchapel | with no comments
Filed under:
この記事は@IT さんの Database Expert 会議室に投稿した記事のフォローアップです。
解決のために
修正が製品版に間に合いますように,より多くの方の検証・投票が必要です。
ご協力ください
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=c540b3c7-fce2-47cc-95e6-fd780172ebea
問題の概要
SQL Server 2005 CTP June において,
Japanese_90_CI_AS,Japanese_CI_AS 照合順序を使用して,
LIKE 演算子に 「ー」(日本語長音)を含む2文字以上の文字列を処理すると
正しく抽出ができなくなる。
問題の再現

再現方法は C# MVP の中さんが簡潔にまとめてくださっています。 http://blogs.wankuma.com/naka/archive/2005/09/29/18540.aspx

ここでは,簡単におさらいを

varchar または,nvarchar を格納するテーブルを作成して,
「ー」(日本語長音)を含む2文字以上の文字列(ここでは「クー」)を条件とするクエリを発行します。

クエリは,実験するためのテーブルを準備して,実験コードを実行した後,後処理を実行します。

再現コード
create database CollateTest
go
 
use CollateTest
go
 
create table JpnTest ( [Data] nvarchar(50) collate Japanese_CI_AS);
 
go
 
insert into JpnTest([Data]) values('クーリング')
insert into JpnTest([Data]) values('カーリング')
insert into JpnTest([Data]) values('ケビン')
 
select * from JpnTest where [Data] like '%クー%'
go
 
drop table JpnTest
go
 
create table JpnTest ([Data] nvarchar(50) collate Japanese_bin);
 
go
 
insert into JpnTest([Data]) values('クーリング')
insert into JpnTest([Data]) values('カーリング')
insert into JpnTest([Data]) values('ケビン')
 
select * from JpnTest where [Data] like '%クー%'
go
 
drop table JpnTest
go

期待される結果は,両方とも「クーリング」が返されることですが,
[Japanese_CI_AS] では期待する結果が返ってきません。

「ー」ではなく「〇」(漢数字の零)が長音文字になっている

結果的に,[Japanese_CI_AS] で,「クーリング」をヒットさせるには,

WHERE [Data] LIKE '%ク〇%'

として,「漢数字の〇」を長音文字としてあててあげなければなりません。
これは日本語の処理としては非常に不適切です。

再現コード
SELECT [DATA]
    FROM [CollateTest].[dbo].[JpnTest]
    WHERE [DATA] LIKE '%ク〇%' COLLATE Japanese_90_CI_AS
 
SELECT [DATA]
    FROM [CollateTest].[dbo].[JpnTest]
    WHERE [DATA] LIKE '%ク〇%' COLLATE Japanese_BIN
GO

検証での考え方

さて,ここからはちょっと趣向を変えて,

「漢数字の零」が長音文字の代わりにヒットしてしまっている

ということを発見するまでに,TLC が何を考えたのか?
について書いてみたいと思います。
このなんでもない探求法を使ってみれば,みなさんでもおかしな動きの検証ができるようになるのではないでしょうか?

まず始めに,

[Japanese_CI_IS] は [SQL Server 2000] でもおかしな動きをしていた

という知識がありました。
特に長音記号に関する部分は,アルファベットなどの文字と組み合わせると不思議な動きをしてくれます。
この時から,「特定の文字」と「特定の文字」を組み合わせる状況によって「不審な動作をする」という経験的な知識が出来上がっていたのです。

この前提に立つと,

今回の動作も「ー」の代わりに何かの文字が代わりにヒットするのではないか?

という疑いが浮かんできます。
このアイデアが浮かびさえすれば,後は総当り的に文字を試してみることで検証ができるのです。

実行したいことは,

「クー」の「ー」の部分をいろいろな文字に置き換えて,実際にクエリを投げてみてみることです

そうすると,
SQL ステートメントの nchar() 関数が使えそうだと思いつきます。
後は,nchar() 関数を使用して総当たり戦をうまく挑むだけですね。

実は,この辺は,それぞれの得意分野に持ち込んでもいいかも知れません。
つまり,ADO.NET を使用してクエリを組み立てるほうが,T-SQL ステートメントを操作するよりも得意な場合は,
通常のプログラミングの世界でループを組めばいいわけです。
ただし,このときには「追加で使用するテクノロジとのつなぎ目の部分で検証の範囲が広がってしまう」ということを念頭においておくことが必須です。
なるべくシンプルに検証できた方がよいわけですね。

さて,それでは実際に使用したコードです。

「クー」の代わりにヒットする文字を探す
DECLARE @count int
DECLARE @limit int
DECLARE @CMD nvarchar(1000)
 
SET @count = 0
SET @limit = @count + 65535
 
WHILE @count < @limit
BEGIN
SET @count = @count + 1
 
SET @CMD = 'SELECT [DATA],'
    + CAST(@count AS nvarchar) +
    ' AS [char] FROM [TestDB].[dbo].[JpnTest] WHERE [DATA] LIKE ''%ク'
    + nchar(@count) + '%'' COLLATE Japanese_CI_AS'
 
EXEC sp_Executesql @CMD
 
END
GO

実行していることは,
クの直後の文字を総当り的に置き換えて,結果を返させているだけです。

結果の検証

このクエリを実行すると,クーリングをヒットさせる文字が3種類あることがわかります。
その3種類とは,

  • 「_」(アンダーバー)
  • 「%」(パーセント)
  • 「〇」(漢数字の零)
です。

前半2つはなんてことはありません
単純にク「ー」リングが「任意の一文字」か「任意の文字列」にヒットしているだけです。
探していた問題の文字は漢数字の零だった,ということになりますね。

しかし,この検証には一つ問題がありまして,

クエリが先頭の100結果セットしか画面表示しない

ことです。
このため,100以上の結果セットでは,結果の件数しかわからないんですね。
(この場合は返ってくるかこないかがわかればよいので,さほど問題にはなりませんが)
よって,最初のクエリを投げた後,結果が返ってきている大まかな場所にあたりをつけて
もうすこし限定したクエリを投げます。
結果セットの表示文字列の 25000 行あたりに「(1行処理しました)」がありますから,問題は12000ぐらいだろうと予想するわけです。

本来必要な部分だけを取得する
DECLARE @count int
DECLARE @limit int
DECLARE @CMD nvarchar(1000)
 
SET @count = 12200
SET @limit = @count + 100
 
WHILE @count < @limit
BEGIN
SET @count = @count + 1
 
SET @CMD = 'SELECT [DATA],'
    + CAST(@count AS nvarchar) +
    ' AS [char] FROM [TestDB].[dbo].[JpnTest] WHERE [DATA] LIKE ''%ク'
    + nchar(@count) + '%'' COLLATE Japanese_CI_AS'
 
EXEC sp_Executesql @CMD
 
END
GO

こうすることで,問題の部分の結果を得ることができました。

このように,わりとシンプルなアイデアを実現することによって,実現できる部分が多くあると思います。
みなさんもぜひトライしてみてください。

この記事は Microsoft SQL Server 2005 CTP June
に基づいて記述しています。

Posted by timberlandchapel | 4 comment(s)
Filed under:
この記事は@IT さんの Database Expert 会議室に投稿した記事のフォローアップです。
シナリオと要件
T-SQL ステートメントのエラー状態によって処理を分岐させ,その状態をイベントログに記録します。
今回は [RAISERROR],[IF~BEGIN~ELSE] を使用します。
[アドホックメッセージ] を利用する

[RAISERROR] の機能だけを利用して,メッセージを記録します。
この機能では SQL エラー番号 50000 としてログ記録されます。

@@ERROR の値によって,ログ記録を分岐させるクエリ
USE TestDB
 
DECLARE @DBID INT
DECLARE @DBNAME NVARCHAR(128)
 
SET @DBID = DB_ID()
SET @DBNAME = DB_NAME()
 
BACKUP DATABASE TESTDB TO DISK = 'E:\test.bak'
 
IF @@ERROR = 0
    BEGIN
        RAISERROR ('ID :%d, NAME:%s Backup success.', 1, 1, @DBID, @DBNAME) WITH LOG
    END
ELSE
    BEGIN
        RAISERROR ('ID :%d, NAME:%s Backup fail.', 1, 1, @DBID, @DBNAME) WITH LOG
    END
GO

事前に [sp_addmessage] でメッセージを定義しておく。

この機能では SQL エラー番号 やログ記録のオン/オフなどを事前に定義しておくことができます。

メッセージを事前定義するクエリ
EXEC sp_addmessage @msgnum = 50001, @severity =1,
    @msgtext ='ID :%d, NAME:%s Backup success.',@with_log=True
 
EXEC sp_addmessage @msgnum =50002, @severity =1,
    @msgtext ='ID :%d, NAME:%s Backup fail.',@with_log=True
GO
定義済みのメッセージを使用してログ記録するクエリ
USE TestDB
 
DECLARE @DBID INT
DECLARE @DBNAME NVARCHAR(128)
 
SET @DBID = DB_ID()
SET @DBNAME = DB_NAME()
 
BACKUP DATABASE TESTDB TO DISK = 'E:\test.bak'
 
IF @@ERROR = 0
    BEGIN
        RAISERROR (50001, 1, 1, @DBID, @DBNAME)
    END
ELSE
    BEGIN
        RAISERROR (50002, 1, 1, @DBID, @DBNAME)
    END
GO

この記事は Microsoft SQL Server 2000
Developer Edition Service Pack 4 に基づいて記述しています。

Posted by timberlandchapel | with no comments
Filed under: