hogemanのちょっといたい話

KBのハイブリッド翻訳いいね

hogeman — Sun, 09 Nov 2008 22:44:00 GMT

あまりにも素敵過ぎて、「機械語翻訳読むぐらいやったら英語版読んでるほうがマシやね」とかよく言われるKBですが、そこはユーザーの意見を第一にするMS、ハイブリッド翻訳にも力を入れてるようです。たとえばこれ。

http://support.microsoft.com/kb/931279/ja

タイトルが「SQL Server timing values may utilities or change that CPU frequencies technologies use when incorrect be します。」

最後に「します」がついてるせいでぐっと日本語らしさが増しててステキ。

# いや、面白いからOKと本気で思ってますよ。

逃亡者乙

hogeman — Sun, 09 Nov 2008 20:37:00 GMT

みなさまこんにちは。超空気読めてないblog翻訳とかも途中でほったらかしにして逃亡中のhogemanです。実はわたくし、KOF2008と同会場で併催してたFOSS4G OSAKA（地図やGPSとオープンソースツールで遊ぶのが好きな人のイベントです）で発表者として登壇してました。わんくまでブース出してたことをぜんぜん知らなかったのでわんくまの発表を聞きに行けませんでしたm(_ _;)m

ちょっとこっち系の活動も再開させたいし、来年もKOF2008とFOSS4Gは併催のはずなので、2009年の目標は、「わんくまとFOSS4Gに同日ハシゴ登壇すること！」にしてみようかな。（無理かな...）

今日は番外編

hogeman — Fri, 04 Jul 2008 01:44:00 GMT

今週土曜は珍しく大阪でPASSJのイベントがあるらしい。質問事項の仕込みとかぜんぜんしてないことを思い出し、今日やっと自宅のSQL Server 2008を Feb.CTP から RC0 にグレードアップ！しかし今日は入れるだけで力尽きて、この日記を書いてる今はもう金曜ｗ

例によってIsaacさんblogの翻訳の、今日は番外編。

マイクロソフトのWebページで公開されてる(Feb.CTPをベースに書かれた)自習書を読みながらRC0にチャレンジされる方も多いかと思いますが、RC0で地理データの扱いに仕様変更があったため、自習書の地理関係の部分のコードとか、私がはてなの日記のほうに書きなぐったサンプルコードとかはそのままでは動かないですよ、という注意喚起です。

元記事へのリンク：
http://blogs.msdn.com/isaac/archive/2008/03/05/the-upcoming-geography-coordinate-order-swap-a-faq.aspx

地理座標の表現順スワップについてのFAQ

Hi Folks,
地理座標の表現順スワップのことについてはっきりしっかり書いとかなきゃと思ったんで、簡単なFAQを作ってみたよ。

実際のところ何が変わるの？
well-known text(WKT)とwell-known binary(WKB)フォーマットについて、CTPでは[緯度-経度]順だけど[経度-緯度]順に座標の表現順を変えるんだ。たとえば、シアトルの座標表現はWKT形式で"POINT(44 -122)"だが、RC0以降では"POINT(-122 44)"になる。
何でこんな変更すんの？
地理ヲタユーザーからのフィードバックがあったからだ。（欧米文化圏では）一般的には座標は[経度-緯度]の順で表現するもんだし、WKTやWKBのデファクトスタンダードも[経度-緯度]順だからだ。この変更でWKTやWKBのデータをロードしやすくなるよ。
GMLはどうよ？
GMLの標準的な慣例では[経度-緯度]順を使ってるからGMLは変更ないよ。
ディスク上の永続化形式は？
変わらんよ。この変更はデータのインポート、エクスポート処理だけの問題でそれ以外には変わらないよ。
geometry型は？
geometry型はも変わんないよ。 (OGCの)geometryは平面しか扱わないし、STX,STYプロパティの外部の座標表現順なんか知ったこっちゃないよ。
いつ変更されんの？
RC0以降

Cheers,
-Isaac

そろそろモチ上げていかなきゃ

hogeman — Sun, 25 May 2008 22:27:00 GMT

ずーーーっと放置してたIsaacさんのblog翻訳のつづき。

元記事へのリンク：http://blogs.msdn.com/isaac/archive/2008/03/01/basic-multi-level-grids.aspx

基本的な多階層グリッドインデックス「Basic Multi-Level Grids」

前回のエントリでは単純なグリッドインデックスにまつわる問題をとりあげたけど、今回はそれらの問題をどうやって回避してるかを説明するよ。

実のところ SQL Server 2008では前回説明したような単純なグリッドインデックスは使ってないんだ。代わりに四分木(quadtree)に見えるような多階層のグリッドインデックスを使っている。（一レベルのグリッドではなく）４段階の入れ子にしたグリッドを使ってるんだ。

ここで例を見てみよう。４階層の各階層が2x2のグリッドで構成されていると仮定すると、下記の図形は最上位階層のグリッドの３つのセルを占めることになる。

上記３つのセルはたしかに図形を覆ってはいるけど、もとの図形と重ならない余計な部分がたくさんある。一次フィルタにこのセルを使うと、かなり余分にヒットしてしまう。そこで、２番目の階層のグリッドインデックスを使ってみる。

第二階層では、第一階層では余分にはみ出てた部分をだいぶ枝刈りできる。対象の図形に対するインデックスは多少重たくなっちゃうんだけどね。で、おなじように第四階層まで分割を進めるとこんな風になる。

これできっちりとカバーできた。でもこれじゃあかなりたくさんセルを作ってしまうし、対象の図形に対するインデックスが重たいよ。実際、すべての図形が同じレベルのグリッドを使う必要はないし、ある図形ののすべての部分で同じレベルのグリッドを使う必要もない。じゃ、グリッドのレベルを混ぜて使えばいいんじゃね？

レベルを混合したグリッドセルを使えるようにすることで２つの最適化ができる。ひとつは、ある特定のセルの下位セルがすべて対象の図形と接触していることがわかったら、もうそれ以下のレベルのセルに分割しない最適化だ。それ以上分割してもメリットがないからね。何を言ってるのかわからないかもしれないが絵を見りゃすぐわかるよ。上の図に、ここで説明した最適化を適用したら下図のようになる。

見ての通り、これでインデックスに使うセルをかなり減らせる。

ふたつめは、セルの数に制限を設ける最適化だ。我々は制限の初期値を１６セルにしてるが、ユーザーが用途に合わせて調整することもできる。対象の図形を幅優先探索でツリー分割していき、この過程で制限数に達したらそこで分割をやめるんだ。結局下図のようになる。

ここまでの説明については言わなきゃいかんことがいろいろあるけれどとりあえず今はこれでおいとく。ひとつだけ言わせてもらえれば、ここで挙げた例では分割を各レベル2x2で行ってるけど現実にはもっと細かく割ってる。どんだけ細かく割るかは調整可能だ。ユーザーによる指定値と分割数の対応は、「low：4x4」、「medium：8x8」、「high：16x16」になる。

ユーザーがこれらのパラメータをどう調整すればいいかについては一般的なアドバイスはしづらい。データやクエリに非常に依存するからね。ただ、僕らが選んだデフォルト値でたいていの場合は上手くいくと思うよ。みんなが空間インデックスを使い始めていろんなレポートが上がってきたらもっといいアドバイスができるようになると思う（だからあなたが発見したことを僕たちにぜひ教えてくれよ）。

次回はマルチレベルグリッドについて少し詳しい話をするよ。

Cheers,
-Isaac

ここからhogemanコメント：
DBMSの記事で４分木ですよ奥さん。我々ＧＩＳプログラマは地図のレンダラ書いたりするのに割とゲーム的な高速化手法とか使ってたりするんですよ。本職の人たちには全然かないませんが。

ところでIsaac氏も言ってるようにインデックスの分割数の指定の最適値は結局はデータと使い方次第でチューニングすべきだけどそれでも目安がないと不安な向きもあるかと思う。大雑把にいえば、非常に広域に地物が分散している場合やひとつひとつが小さい地物が大量にある場合はhighを指定し、反対にデータのエクステントに対して比較的地物が大きい場合や局地的なデータを扱う場合はlowを指定することをお勧めしておく。セルの大きさの幅をイメージするためにGoogleMapsを例に取って説明するとGoogleMapsの実用域は全世界図みたいな縮尺を除くと実質16レベルぐらい。GoogleMapsのタイルは各縮尺ごとに各辺のサイズを倍々にしていってる。つまりlowはGoogleインターバルの2倍なので2*4階層=でGoogle8縮尺分をまたぐようなサイズ差のインデックスが貼られるイメージ、mediumは3*4でGoogle12縮尺分、highは4*4階層で16縮尺分の差、という感じ。

ところで Spatial Ed の翻訳も書きたいけどここに混ぜたらわけわかんなくなるかな。

もうね、以下略４

hogeman — Mon, 18 Feb 2008 02:10:00 GMT

SQL Server 2008 空間拡張チームのISAACさんBlog超訳のつづき。
まだ出てない製品の話だし興味ねえようぜえよという方は華麗にスルーしてください。

元記事へのリンク：http://blogs.msdn.com/isaac/archive/2008/02/05/picking-up-on-indexing-moving-beyond-the-simple-grid.aspx

空間インデックスの理解「Moving Beyond the Simple Grid」

あー、インデックスについての連載まだ最後まで書いてなかったね。僕も続き書かなきゃと思ってたんだわ。

ここまでのところは準備体操みたいなもんで、空間インデックスの基本的な原理の説明をしてきた。これから先のいくつかの記事では、実際にSQL Serverがやってる内部動作とかを書いていくよ。
まずgeometry型を例にとって説明をし、その後、geometryと割と似てるけとちょと違うgeography型の説明に進んでいく予定だ。

まずいままでのおさらいから。単純なグリッドインデックスを思い出してみてくれ：まず外枠を設定して、これをタイル状に分割して、タイルをてきとうなルールに従ってナンバリングしたわけだ。（例では、単に行方向優先の連番をふってみた）

これにはまだ多少問題がある(*1)：

タイルの分割を実際の図形のサイズぎりぎりに小さくすればするほど一次フィルタの効きはよくなる。でもちょっとまってほしい。（座標点のような）小さい図形に対しては、図形ぎりぎりのサイズまでフィルタを小さくするのはたぶん無理。
大きい図形の場合はまた別の問題がある。大きい図形と重なるタイルのマス目はとても多くなってしまうような。もしこれらのセルを全部永続化しなきゃいけなくなったらインデックスはすごくでっかくなる。
いままでの例で示したインデックスのナンバリング方法はインデックスの局所性の観点からみてよくない。つまりは、位置的に隣り合ったセル同士がとても離れた番号にナンバリングされる場合があるちゅうことで、その結果、局所的な空間クエリをしたいのにインデックスの全走査とか走ってしまうちゅうことだ。

もしタイルのしくみにこだわるつもりなんだったらこれらの問題をなんとかしたいところだ。ひとつ先に言っておくと、上記(3)の問題に対する完璧な解決方法はない。でも、今まで考えた方法よりもうちょっとましな仕組みにはしたいと思ってる。

次回は、「階層化グリッドインデックス」の巻～。

Cheers,
-Isaac

(*1) 他にも粘着するべき問題はいろいろあるけど、とりあえず今から説明しようとしてる問題だけ取り上げてみる(*2)。この連載が進んだら残りの問題も取り上げるつもり。
(*2) 残りの問題を取り上げるのをうっかり忘れるかも。てか「計画的に書けよゴルルァ」って文句言われるかもスマソ。

とりあえずISAACさんblogの最終更新分まで訳した。続きは元blogが更新されてから。それまでは別の雑談でもして引っ張る予定。ていうかこのおっさん、えらい細切れに引っ張りよんなぁ...

X01Tはじまったな。

hogeman — Wed, 13 Feb 2008 23:32:00 GMT

ハードリセット祭り

X01Tのハードリセット方法が見つかった（ショップに通達が来た？）らしい。

87 sage 2008/02/13(水) 12:15:09 ID:ZpcLK/ad0
ハードリセット方法
電源キー、メールキー、ＢＳキー、ボリュームキー下同時押し。

138 白ロムさん sage 2008/02/13(水) 13:58:35 ID:aHlNoxfA0
open、レジストリ上は存在してるから
接続＞接続＞詳細設定＞ネットワークの選択
からプライベートネットワークを社内ネットワークなりなんなりに変えて
OKで復活できる。

X01Tはハードリセット方法が非公開だったので発売されて間もない機種のくせにスレが葬式状態でした。実際ハードリセットと＊メーラーの問題で買い控えてた人も多いと思う（俺様は発売日に買いましたとも、１年未満買い増し料金で）。最大の問題が片付いたので素直にうれしい。これでやっと安心してコード書けるわ。さあ徹夜で環境再構築すっかな。

はてなにでも書いてろって内容だけど以下略３

hogeman — Wed, 13 Feb 2008 00:35:00 GMT

ISAACさんBlog超訳のつづき。うざがられてもまだまだいくよ～。
匿名連絡フォームまたはコメント欄からの『巣にカエレ！』とか『くそして寝ろ！』といった熱いエールも歓迎。

元記事へのリンク：http://blogs.msdn.com/isaac/archive/2007/12/01/spatial-indexing-part-3-faster-primary-filtering.aspx

空間インデックスパート３「Faster Primary Filtering」

前回は単純な一次フィルタがどうやって処理を速くできるのか、のところまで説明を終えてたと思う。

前回説明した単純なグリッドインデックス関数 Grid() を思い出してくれ。マス目の数値を返すテーブル値関数(TVF)として実装したやつだ。図を見ると Grid(University Ave) が {5, 9, 10, 11} を返すことがわかるだろう。

「Roads」テーブルは下表のようなスキーマと内容をもってる。[gx]っていうのはgeography型の値を表してると思ってくれ。

Roads
id(pk)	name	shape
1	University	[g1]
2	Mifflin	[g2]
3	Gammon	[g3]

SQLは、こう書き換えられる。

SELECT Name
FROM Roads
WHERE Shape.STIntersects(@x) = 1

as

SELECT Name
FROM Roads
WHERE
   EXISTS (
      SELECT *
      FROM Grid(@x) g1
         JOIN Grid(Roads.Shape) g2 ON g1.cell = g2.cell
   )
AND Shape.STIntersects(@x) = 1

でも、これじゃあそんなに速くなりそうもないので、各行ごとのGrid()関数の結果値を事前計算して内部テーブルにキャッシュしてみる。ついでにこのキャッシュのcell列をクラスタインデックスにしてみる。上記の例の場合、こんな感じになる。

Roadsidx
id	Cell
1	5
2	7
1	9
3	9
1	10
2	11
1	11

このテーブルがあれば、Grid(University Ave) はこんなクエリで調べられる。

SELECT cell
FROM RoadsIdx
WHERE id = 1

このテーブルはこのクエリに最適化されているとは言えないが、クラスタインデックスがあるため(IDでなく)Cellでアクセスするのは速い。指定されたcellにどの空間オブジェクトが入っているかを高速に調べられる。この内部テーブルを使ってEXISTS句を以下のように書き換えられる。

SELECT Name
FROM Roads
WHERE
   EXISTS (
      SELECT *
      FROM Grid(@x) g1
        JOIN RoadsIdx g2 ON g1.cell = g2.cell
      WHERE Roads.Name = RoadsIdx.Name
   )
AND Shape.STIntersects(@x) = 1

（訳注：このSQLは原文まま）

空間DBがどんな処理を行うかを説明するために処理の内容をSQLだけで書いてることに注意してくれ。別の書き方だとこうなる。

SELECT Name
FROM
   (
      SELECT DISTINCT id
      FROM Grid(@x) g1 JOIN RoadsIdx g2 ON g1.cell = g2.cell
   ) as PrimaryFilter
   JOIN Roads ON PrimaryFilter.id = Roads.id
WHERE Shape.STIntersects(@x) = 1

実際には何が起こってるんだ？これらのクエリだけみてもデータフローがよくわからんと思うのでツリー風の図で説明してみる。元のクエリの動きから。

「Roads」テーブルの全表走査が走る。これはデータ量の多い処理なんで太線で表してみた。改善を施したほうのバージョンだと動きはちょっと異なってて、こうなる。

新しい実行プランだと実行ツリーは複雑になってるけど、インデックスが使われることでデータ量の多いフローはなくなってる。パラメータのグリッド化は速く、少しの列しか作らない。もはやテーブルが全表走査もされることもなくなった。ちょっとツリーが複雑になったのに速度は劇的に改善してるんだ。

まあ単純なグリッドインデックスにはいろいろ問題がある。このサンプルでは１６セルしか扱ってないがこれは広域を扱うには少なすぎる。もしもっと細かいグリッドを使ったら作ったで、セルの数や内部テーブルの行数がすごく増えてしまう。

Now that we have these basics out of the way, 次回はSQL Serverの空間インデックスが実際にどう動くかの話をするね。

Cheers,
-Isaac

（で、この続きは乞うご期待なんだが、この先はBOLとかwebcastとか見りゃわかる（身も蓋もねえな）。某E社製品のチューニングノウハウとか流用できそうな雰囲気。）

空気読まずにBlog翻訳２

hogeman — Tue, 12 Feb 2008 01:54:00 GMT

SQL Server 2008 空間拡張チームのISAACさんBlog超訳のつづき。興味ねえようぜえよという方は華麗にスルーしてください。（そこ頼まなくてもスルーされてるとか言うな）

元記事へのリンク：http://blogs.msdn.com/isaac/archive/2007/11/27/spatial-indexing-part-2-a-simple-spatial-indexing-scheme.aspx

空間インデックスパート２「A Simple Spatial Indexing Scheme」

前回に引き続いて空間インデックの話をつづけるね。君が空間インデックスについて知ってたら、はじめのほうの数回の記事は基本的なバックグラウンドの説明になると思う。--あんまり間違えないようにしなきゃね(｀・ω・´)

マジソンに注目して説明を続ける。ちょっと質問に答えてみてくれ。どの道路がUniversity Avenueと交差してると思う？（問題が少し変わってるのに気付いたかもしれないが、作図を簡単にしたかっただけなんだ。手続きに違いはないから気にしないでくれ。） Virtual Earth上にクエリーを表示したらこうなる。

(訳注：MadisonからMiddletonにかけて水色になってる通りが University Avenue。土地勘ないからわかんねー)
この問題をSQLにしてみよう。「Roads」テーブル (id int, g geography) があると思ってくれ。そしてクエリー引数となるオブジェクト（ここでは University Avenue）が @x に入っていると仮定すると、SQLはこう表現できる。

SELECT id
FROM Roads
WHERE g.STIntersects(@x) = 1

空間インデックスがない場合は「Roads」テーブルを全走査することになってしまう。どうやったら一次フィルタ、二次フィルタを使ったクエリにできるだろうか。
まずは単純な手法、グリッドインデックスから考えてみよう。（これはSQL Serverの中で実際に行われている動きとは多少違うが、原理を理解する助けにはなる）
グリッドインデックスはその名の通り、空間を格子状に区切るものだ。説明のためにマジソン周辺に限定してグリッドに区切るとこんな感じになる。

こうすることで、それぞれの地理オブジェクトに対して、グリッドと交差して（重なって）いるマス目の数字を割り当てることができる。別の言い方をすれば、グリッドは空間オブジェクトとそれが交差する各マス目の値を関連付けるテーブル値関数を定義する。たとえば @x がクエリオブジェクトとすれば、Grid(@x) = {5, 9, 10, 11}; といった具合。

「Roads」テーブルのどの道路に対してでも同じような結果が得られる。さらに、２つの道路が交差する場合は必ずマス目を共有するので、一次フィルタの実装にこのグリッドを使うことができる。さきほどのクエリーは概念的にはこんな風に書き換えられる。

SELECT id
FROM Roads
WHERE
   EXISTS (
      SELECT *
      FROM Grid(@x) g1 JOIN Grid(Roads.g) g2 on g1.cell = g2.cell
   )
AND g.STIntersects(@x) = 1

これは説明用の疑似コードであることに注意してくれ。実際にはSQLを書き換えたりしなくてもDBエンジンが内部的によしなにしてくれる。このSQLは単にクエリの背後でどんな処理がおこなわれているのかを説明するためのものなんだ。
いま実際に行なったのは元のクエリに単にEXIST句を加えたことだけだ、ということは言っておきたい。一次フィルタを使ってみましょう。そして二次フィルタを呼び、EXIST句が前回説明した一次フィルタの３つの特徴を満たすクエリになっているかを見てみよう。

ふたつの空間オブジェクトが一つのマス目を共有していても実際には交差していない場合もあるので、「交差していないが結果に含まれる」ものがでてくる可能性がある。一方、２つの空間オブジェクトがマス目を共有しないが交差する、ということはありえない。つまり「交差しているが結果に含まれない」ということはない。
ここで示した例は説明のために多少概念的な話になってる。実際には１６マスではタイトな絞り込みをするには少なすぎる。まあ馬鹿みたいに誤判断するわけでもないからこれはいいとしておこう.
あー、これは問題だわ：ここで書いたような一次フィルタ実装ではたいして速くなるわけじゃない。テーブルの各行の交差をそれぞれ計算する代わりに、各要素に対してグリッド関数の計算をしなければならない。これで速いわけがない。

一次フィルタをもっと速い実装にしなくちゃね。読者のみんなは僕がどう話をもっていこうとしてるかわかってるような気がするけど、続きは次回ということで。

Cheers,
-Isaac

PASSJにでも書いてろって内容だけど...わんくまでやるお！

hogeman — Mon, 11 Feb 2008 15:29:00 GMT

blogスペース要求しといていい感じに放置状態。ごめんなさい。

今週末の大阪勉強会には一応初参加の予定。知ってる人誰もいないだろうし勉強会のテーマ的にもアウェイ全開っぽいのに懇親会にも登録とかしてるし。まあＭなだけなんすけどね。

今日の本題：空気読まずにBlog翻訳
最初のエントリとして SQL Server 2008 空間拡張チームのISAACさんBlogを※未承諾超訳※していってみる。誤訳してたらすまそ。そこはかとなく私自身が書く予定のエントリへのネタフリも兼ねてるわけですが。

空間インデックスパート１「Why a Spatial Index?」

やあ、きみたち。

もし、僕が空間データベースについて説明してるのをみたことがあるなら、空間インデックスの基本的な動きについての僕の話も聞いてるだろう。ここでの一連のブログ記事でも同じような説明を少し詳しいところまでしていこうとおもう。まずは基本的な話から始めて、だんだんと実際の動きについての話にすすめていくつもりだ。

空間演算に際し、どの空間データベースもだいたい同じような基本的戦略を使っている：（たとえば図形の交差を調べるような）空間演算を処理する場合、実際には二段階に処理をする。一次フィルタと二次フィルタの２段階だ。一次フィルタは粗く絞りこみ、二次フィルタで正確な判断をする。一次フィルタは以下の３つの特性をもってるべき。

偽の結果を含む。つまり、指定した条件式とマッチしない空間オブジェクトも結果に含めることがある。だが逆に、マッチするはずのものを誤ってふるい落とすことはない。
偽の結果を含みすぎることはない。（一次フィルタが全然仕事をしないのも意味がないので）
高速！

具体的に説明する。まず全米の道路網データがあるとしよう。ウィスコンシン州マジソンと重なる道路を取り出したいとする。まず一次フィルタ（雑だけど処理が速い）がウィスコンシン州以外のデータをおおざっぱに枝刈りするわけだ。しかしこの結果セットにはマジソンとは重ならないデータも含まれてしまっている（逆はない）。正確な結果をもとめるためには、この結果セットに対して（二次フィルタで）本来の意味の重なり判定演算を行うという寸法だ。

なんでこんな面倒なことをするかって？そりゃ二次フィルタ（正確な空間演算）が遅いからだよ。複雑な空間演算呼び出しをできる限り排除できたらとても速くなるんだ。もうひとつは、我々はリニアな挙動を望んでいるからだ。ひとつひとつの図形に対していちいち厳密な空間演算してたらそんなの達成できないからね。

よくわからない？単純に言うと、空間インデックスていうのは一時フィルタのことだよ。

Cheers,
-Isaac

元記事へのリンク：http://blogs.msdn.com/isaac/archive/2007/11/24/spatial-indexing-part-1-why-a-spatial-index.aspx

注：一般的にはここに書いてるような使い方だけでなく一次フィルタで完結するような使い方をするケースもあり。たとえばある地図の表示範囲矩形にＰＯＩを出すためのクエリーをする場合には二次フィルタをかける必要はない。しかしながらどの演算子がどのフィルタを使うかを意識しながらSQLを書く必要がある、というのもどうかと思うが。一次フィルタが余分に取ってくる部分の特性は各空間データベースによって割と違うので見比べると面白いっすよ。

わんくまのアカウント作ってみた。

hogeman — Wed, 06 Feb 2008 00:26:00 GMT

こんばんはhogemanです。

はてな日記のほうで与太とか技術話とかチラ裏とかごちゃまぜに書いてたんだけど、わんくまのアカウントとったのを機にMicrosoftネタはこっちに書いてみるテスト。

とりあえずこっちは技術情報とかblog翻訳とかを中心にした、誰かの役に立つかもしれない感じのネタ中心にやってみるのでよろ。