このブログを見て下さった皆様に、心より感謝申し上げます。名前はゲームブログですが、色々な話題を書かせて頂きたいと思います(大好きな写真/映像/カメラ、ペン、コンピュータ、食べ物、映画、クルマ、家電製品などなど)。 なにとぞ、これからもよろしくお願いいたします。皆様あってのブログです。
2009年12月31日木曜日
EF 100mm F2.8L MACRO IS USM一本勝負!! 仙台光のページェント
年末ぎりぎりでしたが、ようやく仙台光のページェントに行って来る事が出来ました。
結局、今年は今回の一回きりでしたねぇ・・・。
色々なレンズは持って行ったものの、EF 100mm F2.8L MACRO IS USMレンズの一本勝負となりました。
通行の邪魔にならないように、誰も通らないすみっことかに三脚をすえて撮影。
EOS KISS X2と100mmレンズの組み合わせだと、そこそこの望遠になるので、混雑から離れた場所から撮影が可能でした。
撮影は例によって全てマニュアルモード撮影。
機材は、カメラとレンズと三脚のみで、ソフトフィルターとかは一切使ってません。というか、持っていないです。
光がブワーッとなっている写真は、手動でわざとピントを狂わせる事で、アクセントをつけてみました。
スローシャッターで撮影中に、手でピントリングを強制的に回す事で光がブワーッと拡散したような効果が出せるんですよ!!
ただ、シャッターを開ける時間や、ピントリングを回す按配で劇的に写真が変化してしまうので、同じものは二度と撮影できないかなぁ・・・と。
アクセントをつけない写真も、思い切って露出をどかんとオーバー気味にしてみました。
今年のクリスマス料理
2009年12月26日土曜日
SQL-Serverと.NET Frameworkの型の違いについて
SQL-Server 2008には、(2005の時代からですが)SQL CLRという極めて強力な機能がありますけれど、SQL-Serverと.NET Frameworkという二つの違う環境を結びつける都合上、どうしても「型の違い」という悩みが発生してしまいます。
たとえば、SQL-ServerのFloat型に該当する.NET Framework側の型はDouble型ですし、SQL-ServerのNVarChar型は、.NET Framework側ではString型になりますが、VarChar型も同じString型になってしまいます。
しかもこの型の違いは、単にキャストしてもうまくいかないんで、変換配列みたいなものを作っておいて力技で変換かけてあげないといけない・・・のかな?
今後のために、型の対応表の意味も含めて、変換「用の」配列作成プログラムを書いてみました。
単なる配列データを作るだけで、実際に変換処理をするわけではないです。
この配列を利用して変換処理を別途作成する・・・という材料的なものですね。
SQL CLRでの利用を前提としています。また、ズラズラと長いのでスクリーンショットではなくてテキストで直接記述してます。
まだこの材料を具体的には使ってはいないのですが、SQL CLRでストアドプロシージャを書く時、たとえば・・・そうですね、特に、DataTableオブジェクトの内容をSQL-Serverに返す時なんかは、型の違いを吸収しないといけないので必要かも。
両環境での型の違いを知らないと、ストアドプロシージャではかなり厳しいです。
へたをすると、SqlDataRecordを作れないという事態に発展してしまいます。
//*******************************************************
//* (SQL-Server)SqlDbTypeと(ADO.NET)DbTypeの比較構造体
//*******************************************************
private struct stc_SQLADOTypes
{
public SqlDbType SQL; //SQL型
public DbType ADO; //ADO.NET型
public Int16 STYLE; //文字型スタイル
}
//*******************************************************************************
//* 関数
//*******************************************************************************
private static stc_SQLADOTypes[] fnc_GetSQLADOTypes()
{
stc_SQLADOTypes[] useArr_result = new stc_SQLADOTypes[28];
Int32 i = 0;
try
{
//@@@@@@@@@@[LOOP-START]@@@@@@@@@@
for (i = 0; i < useArr_result.Length-1; i++)
{
switch (i)
{
case 0:
useArr_result[i].SQL = SqlDbType.Binary;
useArr_result[i].ADO = DbType.Binary;
break;
case 1:
useArr_result[i].SQL = SqlDbType.Timestamp;
useArr_result[i].ADO = DbType.Binary;
break;
case 2:
useArr_result[i].SQL = SqlDbType.VarBinary;
useArr_result[i].ADO = DbType.Binary;
break;
case 3:
useArr_result[i].SQL = SqlDbType.Bit;
useArr_result[i].ADO = DbType.Boolean;
break;
case 4:
useArr_result[i].SQL = SqlDbType.TinyInt;
useArr_result[i].ADO = DbType.Byte;
break;
case 5:
useArr_result[i].SQL = SqlDbType.Date;
useArr_result[i].ADO = DbType.Date;
break;
case 6:
useArr_result[i].SQL = SqlDbType.DateTime;
useArr_result[i].ADO = DbType.DateTime;
break;
case 7:
useArr_result[i].SQL = SqlDbType.DateTime2;
useArr_result[i].ADO = DbType.DateTime2;
break;
case 8:
useArr_result[i].SQL = SqlDbType.DateTimeOffset;
useArr_result[i].ADO = DbType.DateTimeOffset;
break;
case 9:
useArr_result[i].SQL = SqlDbType.Decimal;
useArr_result[i].ADO = DbType.Decimal;
break;
case 10:
useArr_result[i].SQL = SqlDbType.Money;
useArr_result[i].ADO = DbType.Decimal;
break;
case 11:
useArr_result[i].SQL = SqlDbType.SmallMoney;
useArr_result[i].ADO = DbType.Decimal;
break;
case 12:
useArr_result[i].SQL = SqlDbType.Float;
useArr_result[i].ADO = DbType.Double;
break;
case 13:
useArr_result[i].SQL = SqlDbType.UniqueIdentifier;
useArr_result[i].ADO = DbType.Guid;
break;
case 14:
useArr_result[i].SQL = SqlDbType.SmallInt;
useArr_result[i].ADO = DbType.Int16;
break;
case 15:
useArr_result[i].SQL = SqlDbType.Int;
useArr_result[i].ADO = DbType.Int32;
break;
case 16:
useArr_result[i].SQL = SqlDbType.BigInt;
useArr_result[i].ADO = DbType.Int64;
break;
case 17:
useArr_result[i].SQL = SqlDbType.Variant;
useArr_result[i].ADO = DbType.Object;
break;
case 18:
useArr_result[i].SQL = SqlDbType.Real;
useArr_result[i].ADO = DbType.Single;
break;
case 19:
useArr_result[i].SQL = SqlDbType.VarChar;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 20:
useArr_result[i].SQL = SqlDbType.Char;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 21:
useArr_result[i].SQL = SqlDbType.NChar;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 22:
useArr_result[i].SQL = SqlDbType.NText;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 23:
useArr_result[i].SQL = SqlDbType.NChar;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 24:
useArr_result[i].SQL = SqlDbType.Text;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 25:
useArr_result[i].SQL = SqlDbType.NVarChar;
useArr_result[i].ADO = DbType.String;
useArr_result[i].STYLE = 1;
break;
case 26:
useArr_result[i].SQL = SqlDbType.Time;
useArr_result[i].ADO = DbType.Time;
break;
case 27:
useArr_result[i].SQL = SqlDbType.Xml;
useArr_result[i].ADO = DbType.Xml;
break;
}
}
//@@@@@@@@@@[LOOP-END ]@@@@@@@@@@
}
catch (System.Exception obj_err)
{
throw obj_err;
}
return useArr_result;
}
2009年12月25日金曜日
クリスマスプレゼントにNintendo DS
皆さんはもうクリスマスパーティーなど、しましたでしょうか。
私は、23日と24日でした・・・。
クリスマスプレゼントに、ソフト付きでNintendo DSを頂いてしまいました。感謝。
ソフトは何故か、セガの「君のためなら死ねる」。
なんというインパクト。私にどうしろと・・・?
プライベートな話はおいておいて、さすがはDS。ソフトの起動が速いです。このあたりは、PSPより確実に快適。
PSPは、たとえフルメモリのゲームアーカイブスでも、起動時にいちいちPSロゴ表示デモ画面が流れるのでロスタイムがデカいんですよね。
パッパと始まるDSを見れば、確かに(アーカイブスどころの騒ぎじゃない)低速なUMDに不満が出るのも納得かも・・・。まぁ、今までならば超大容量とのトレードオフで済みましたが、ダウンロード販売時代では大容量はハッキリ言って大迷惑という時代になり、PS系には不利になるというドンデン返し展開になってしまった。
メモリスティックを圧迫する数百メガバイトものソフトだと、オープニングムービーをカットして購入というオプションが本気で欲しくなりますね。R-TYPESなんかは絶対にムービー不要。DSはカードですが、容量は128MB前後、最大でも256MBみたいなので、将来的にダウンロード販売になっても計算出来るレベルで良いかも。PSだと容量の単位がMBじゃなくて、GBだったりして、とても本体のメモリカードでは不安な超大容量だったりしますからね。
ちょっと前までは大容量は自慢の種だったのに、流れ一つ来ただけでカンタンにひっくり返っちゃいます。これは何事もそうですけど。
さて、操作系です。タッチパネルは、絶対に無いよりはあった方が良いですね。
キーが良い時もあれば、タッチでダイレクトが良い時があって、ソフトの設計いかんによりますが、両方の選択肢があるDSは、(メーカーが判断した)最適な方でゲームが出せるわけです。
特に、文字入力みたいな事は、ビジネスにも対応するWindows MobileやiPhone並みの事がタッチパネルさえあれば出来るわけです。このように、DSが獲得してる快適性と比べてしまうと、PSPはどうか・・・
PSPは、タッチパネルが無いゆえの割り切りメリットはあります。
タッチが存在しないので、袋をかぶせて防滴処理してお風呂でネットとか、歯磨きしながら片手で操作して音楽とか。
それはそれとして、選択肢が限られているのはやはり寂しいものです。使えないのと、使わないのとでは、言うまでもなく天と地ほども違いますからね。
メディアプレイヤーとして性能の高いPSPですが、文字入力シーンは、今も昔も面倒過ぎ。PSPがまだ売れていない時代に方向転換してタッチパネル搭載すれば・・・とは簡単には言えないでしょうけれど、人情としてどうしても思ってはしまいますね。
家電やカメラなら、ライバルが売れた新機能があれば、血眼で、それこそ特許の壁があっても乗り越えて搭載してくるのに、PSPは、DSが爆発的に普及しても全くマイペースなのはスゴイ。悪い意味で。
2009年12月22日火曜日
HYBLID W-ZERO3は、買わない方向です・・・
やはり、フルキーボード無しのWindows Mobileは辛いです。
せっかく、WILLCOM 03では、サイズもタッチも非常に良く研究したフルキーボード装備だったのに。
それと、Windows Mobileには、ARM系CPUの528MHzhじゃ遅いと思います。
私のWILLCOM 03が実際に遅いので・・・
メールソフトのモッサリは、普通の携帯電話に慣れてる人なら一分くらいでブチ切れるでしょうねー・・・
解像度800x480以上を全部CPUが世話するんだから、1GHzか、まぁそこまでは無理でも、せめて667MHzくらいは欲しいところですね・・・
Windowsである以上、見かけを電話ルックにしても、最後はパソコン的な使い方が出来ないユーザーには決しておいしいとは言えない感じになるはず。
割り切って、とてもスタイリッシュな超小型パソコンを目指した方が良いのかも・・・
WILLCOM 04を、もっと小さくして、ADVANCED/W-ZERO3[es]くらいにしてしまうとか。
そうこうしているうちに、パソコン系電話は、GoogleのAndroid機にもっていかれそうな予感がしますね。
新機種は、とにかく、次世代のWindows Mobile7搭載か、Android搭載のW-ZERO3まで待つか・・・
あと一年くらいでしょう???
2009年12月21日月曜日
SQL CLRがあれば、SQL-Serverで自由に正規表現を扱える!!
SQL-Serverにおいて、「文字列を検索する際に、望みの検索パターンにヒットしたデータだけを抽出したいなぁ」と思ったら、条件式にlikeを使用するのが一般的かと思います。
likeは良いのですが、とにかく指定出来る検索パターンが少ないのが弱み。
そこで、正規化表現を使いたくなるわけですが、一番の早道はSQL CLR関数を自作してしまう事ではないかと思います。
なぜならば、.NET Frameworkライブラリには、そのものずばりの正規化表現を取り扱うクラス「Regex」があるからです。
また、プログラマブルの長所として、likeのように単にヒットしたかしないかだけを判断するだけでなく、ヒットしたのならば、そのヒットした文字列を全て抽出するような造りにする事も容易です。
今回の記事で作ってみた「SQLCLR_GetLike()」関数は、正規化パターンにヒットした文字列を、CSV形式で全て並べて取得し、ヒットしなければnullを返すようになっています。
例外が発生した場合は、例外オブジェクトをSQL-Serverに投げつけて(throw)、実行をクラッシュさせて強制的にストップさせます。
ただ、likeのように、ヒットしたかしないかだけを判断出来れば良いという場合に備えて、より高速に実行できるSQLCLR_Like()関数も作ってみました。
いちいちヒットした文字列を返そうとしないので、場合によっては二倍くらい高速にはなるはずです。
正規化表現といっても、いつでも複雑な検索パターンを指定しなければならないというわけでもなく、likeで指定するよりもずっとシンプルな検索パターンを書く事も可能です。
正規化表現に限らず、とにかくSQL CLRは、SQL-Serverの必殺技ですね。
SQL CLRさえあれば、SQL-Serverに存在していない機能や不足している機能あれば、とにかく自分で作ってしまって解決してしまえるわけで、その威力はまさに天井知らずと言って良いのではないでしょうか。
私は全てフリーソフト版のSQL-Server 2008 Express(64bit)でやってるわけですが、企業向けの高額エディションに限定せずに(その代わり手動部分が多いですが)サポートしてくれたマイクロソフトには、本当に感謝感激であります。
SQL-Server 2000では、まだまだ機能不足な感が否めなかったですが、2008になったらもう文句なしですね。SQL CLRもあるし、本当にSQL-Serverが好きになりまくりです。
2009年12月20日日曜日
これからプレイしたいレトロゲームの数々
それどころか、新作さえも超えるのではないかと思えるタイトルだって数多いのです。思い出の「美化補正」という、新作に無いアドバンテージを持つソフトだってありますし。
私は、実のところ、あまりタイトル数はこなしていないのです。だからこそ、これから初めてプレイ出来る名作のタイトル数も多いです。今プレイしている作品、これから是非ともプレイしたい作品を合わせると、新作ゲームソフトを買っている暇が無いほどの充実・・・いや、充実というか過剰なまでの分量ですよ。
■ファミコン■
(特徴)とにもかくにも、強烈なオリジナル作品ばかりです。最新鋭ハードでもミリオンヒットを飛ばす人気シリーズの「始祖」を多数抱えるゲーム機でもあり、多分、あと20年後でも復刻されてプレイされているんじゃないでしょうか。スーパーマリオブラザーズなんて、たとえPS3の1億倍の性能のハードウェアが登場したとしても、「あのスーパーマリオがそのまんま移植!!ファミコン名作シリーズ」とかいって復刻され、何十万本も売れるんだろうなぁ・・・。
・グーニーズ(当時クリア済み)
・スーパーマリオブラザーズ(永遠の名作)
・グーニーズ2/フラッテリー最後の挑戦
・サラダの国のトマト姫
・さんまの名探偵
・スウィートホーム
・スクウェアのトムソーヤの冒険
・スペランカー
・ファイナルファンタジー3
・ラグランジェポイント
・スターフォース
・スーパースターフォース
・ワルキューレの冒険/時の鍵伝説
・がんばれゴエモン/からくり道中
・ドラゴンクエスト4
■ファミコンディスク■
(特徴)ハードの最先端期間がファミコン本体よりも短かったため、ソフト本数のボリュームはややおとなし目ですが、ゼルダの伝説やメトロイドなどを始めとする超人気シリーズがここから始まっており、歴史的にも最重要ハードの一台でしょうね。カセットには無い「ディスク入れ替え」が特徴で、カセットが32KBの時代には確かに大容量でした。この大容量を分かりやすくアピールするためか、RPGやAVGが比較的充実しているのも嬉しいところです。
・ゼルダの伝説(当時クリア済み)
・リンクの冒険(当時クリア済み)
・メトロイド(当時クリア済み)
・ファミコン昔話/新鬼ケ島(前編/後編)
・ファミコン昔話/遊々記(前編/後編)
・ファミコン探偵倶楽部/消えた後継者(前編/後編)
・タイムツイスト/歴史の片隅で(前編/後編)
■スーパーファミコン■
なんといっても、アドベンチャーゲームのスタイルを激変させた「サウンドノベル」生誕のハード。カセットの容量も大幅に増え、いわゆる大作ゲームがこぞって登場。全体的に見てRPGやSLGといったプレイ時間が長大になりがちなジャンルが手厚く、このハードに今からハマってしまうと、新世代ハードの出番が無くなりそうな勢いがあります。
・マーヴェラス/もう一つの宝島
・はじまりの森(ニンテンドウパワー書き換え専用)
・スーパーマリオワールド(当時クリア済み)
・クロノトリガー
・スーパーマリオRPG
・セプテントリオン
・学校であった怖い話
・つきこもり
・ドラゴンクエスト6/幻の大地
・ドラゴンクエスト3/そして伝説へ・・・
・ファイナルファンタジー4
・ファイナルファンタジー5
・ファイナルファンタジー6
・弟切草
・メタルマックスリターンズ
・メタルマックス2
・夜光虫
・無人島物語
・タクティクスオウガ
・ゼルダの伝説/神々のトライフォース(当時クリア済み)
■PCエンジン■
(特徴)とにかく、これでもか、これでもかというくらいアクションが中心。アーケードゲームからの高レベル移植が多く、短時間で楽しみたいという時にはかなり向いている印象。
・ビックリマンワールド(当時クリア済み)
・超絶倫人ベラボーマン
・妖怪道中記
・プロテニスワールドコート(なんとテニスRPG付き!!知ってましたか!! 当時クリア済み)
・ワルキューレの伝説
■ニンテンドウ64■
(特徴)プレイステーションやセガサターンなどと並ぶ「第一期の3D対応ゲーム機」の中では、文句無く最強の性能を持ち、今プレイしてもその性能の高さには驚きます。メディアがカセットであるため、容量がほど良くてアクセス速度は最高速レベル。任天堂のソフトのクオリティが異様に高いのも特徴。スーパーマリオ64は3Dゲームの中でも特に歴史に残る名作だと思うし、スマッシュブラザーズやどうぶつの森もこのハードから生まれています。ゼルダの伝説/時のオカリナは、プレイの終わりが見えないくらいに大ボリューム。ゆっくりプレイしたら一年くらいかかりそう・・・。
・スーパーマリオ64
・ゼルダの伝説/時のオカリナ
・ゼルダの伝説/ムジュラの仮面
・罪と罰/星の継承者
・マリオストーリー
・ヨッシーストーリー
・どうぶつの森
・任天堂オールスターズ!!大乱闘スマッシュブラザーズ
・マリオカート64
・マリオテニス
・がんばれゴエモン/でろでろ道中
・夜光虫2
■MSX■
(特徴)8ビットパソコン草創期の空気を残したテレビパソコン。ハードウェアの性能はさすがに物足りないものの、アドベンチャーゲーム初期の名作が楽しめる貴重なハード。特に大きいのは「軽井沢誘拐案内」で、堀井雄二氏のアドベンチャーゲームシリーズ3部作(ポートピア、オホーツク、軽井沢)では唯一ファミコンで発売されていない貴重タイトル。私は全くの未プレイ。
・はーりぃふぉっくすMSX Special
・はーりぃふぉっくす雪の魔王
・軽井沢誘拐案内
■MSX-2■
テレビを使うという構造から解像度的には制約があるものの、本格的なパソコンソフトラインナップを楽しめるのはあまりにも大きいです。当時としては大容量のFDを使えたため、RPGやAVGのボリュームがハンパではないし、ゲーム機ではお目にかかれない、キーボードを活用するスタイルのゲームと遭遇すると、さすがに世界が違う感じがして嬉しくなりますね。タイトル的にも、ソーサリアンやザナドゥといったパソコンの名作中の名作がズラリ。名作アドベンチャーゲームも多数味わえる夢のようなハード。
・サイ・オ・ブレード
・アンジェラス
・ザナドゥ
・ソーサリアン
・スナッチャー(プレイステーション版はクリア済み)
・ハイドライド(ファミコン版はクリア済み)
・ハイドライド2
・ハイドライド3
・ブライ
・ブライ完結編
・メタルギア
・メタルギア2
・原宿AfterDark
・神の聖都(まち)
・破邪の封印
・レリクス
■X68000■
アーケードゲームの異様なまでの高レベル移植が有名ですが、性能が当時のパソコンの中でも突出して優れていたマシンだけに、パソコンの名作ソフトの数々が、最高度クオリティで堪能できるのが何より大きいです。ただし、ソフトラインナップは少々波があり、ソーサリアンなど定番の名作が発売されていなかったりするなど「ラインナップ抜け」は我慢が必要か。ただ、X68000の高性能に奮起したメーカーが、手間をかけてX68000用に特別仕様で作り直したタイトルまである(マーダークラブDXのクオリティは特に必見)など、一本あたりの品質が極めて高いため、少々の弱みは十分に覆す魅力に溢れております。
アーケードとパソコンという、当時の家庭用ゲーム機が夢見た二大環境が、頂点レベルで共存していた稀有な環境と言えるでしょうね。とてもモトローラ68000プロセッサの10MHzで動作しているとは思えないですが、当時は、C言語を使っているメーカーは大変レベルが低いと見なされて忌避され、マシン語プログラムでバキバキに組めて当たり前、10MHzで何でも出来て一人前と見られた世界ですから、現在とは基準が違うと言えるでしょうね。
・38万キロの虚空
・カサブランカに愛を/殺人者は時空を超えて(当時クリア済み。壊れたので定価で2本購入)
・第4のユニット1から5
・道化師殺人事件
・琥珀色の遺言
・黄金の羅針盤
・マーダークラブDX(当時クリア済み)
・マンハッタンレクイエム
・キス・オブ・マーダー
・ドーム
・ガウディ/バルセロナの風
・シグナトリー
・スペースハリアー
・ねじ式
・ノスタルジア
・ロードス島戦記
・ラプラスの魔
・悪魔城ドラキュラ
・桃太郎伝説
・・・書いていてクラクラ来るくらいの分量ですねー・・・何本プレイ出来るんだろう・・・?
2010年のゲーム予定
まだちょっと早いかも知れませんが、今回の記事は、2010年のゲームの事を考えてみたいなぁと思います。
■最新世代ハードについて■
2010年における私の最新世代ハードは、やっぱりPSPオンリーでしょうね。
PSPは、その性能がさらに使いこなされており、既に次世代携帯ゲーム機に近い性能を実現済みだし、ゲームソフトそのもの品質も尻上がりになっているので大満足。
これから発売される予定の新製品では、PSP系列のPSP-4000が一番星。それが待望のゲームスリープ対応なら、買い増ししたいなぁという気持ちはあります。また、小型PSPとして大変便利そうなPSP goにも、まだ未練が残っているところです。
ソニー以外では、任天堂とマイクロソフトの新型携帯ゲーム機が気になります。PSPと比べても負けない魅力があるのであれば、場合によっては購入したいですね。
マイクロソフトの真の恐ろしさは、実はXbox360の先を見据えている点です。マイクロソフトのこだわりは、ソフトの開発・実行環境であるXNA Framework。
Xbox360は、あくまでもこのXNA Frameworkファミリーの一員であり、ここでの対応ゲーム開発を覚えれば、今後色々なハードに知識を展開出来るわけです。
とにかく、PSP系列をどんどん固めて欲しいです。ネットでは、前世代のパソコンGPUクラスの性能を持ったPSP2が噂されていますが、はっきり言って性能的には今のPSPが既に次世代クラスなのですから、発熱と電力に苦しみながら新しいチップを無理に搭載するよりも、今のチップをよりいっそう使いこなし、メモリを潤沢に搭載して使わせるだけでも良いんじゃないかなーという気がします。
メモリと言えば、ソニーは、PS2、PS3でもそうでしたが、妙にメインメモリを少なく搭載しようとする悪癖が抜けません。PSPだって、最初はメインメモリ8MBで発売しようとしたのは有名な話なはずです。(初代PSPは32MB。PSP-2000からは64MB=初代のXboxと同等レベルまで拡張。)
個人的には、PSPが大好きですし、PSP系には大きな期待をしています。がんばれソニー。PSPを伸ばして欲しい。
ただ、一般的に見れば、PSP系は、今のように性能に頼りきっている路線な限り、任天堂DSが性能を高めてきたら売れなくなって普通に即死という気はします。好き嫌いは別として、冷静に考えるとそうなんですよね。PSPはたまたま高性能が任天堂DSとの差別化を成功させましたが、それはあくまでもたまたま。
PSP goで、タッチパネルを搭載しようと思ったら出来たがしなかったとか言っている場合じゃないソニー・・・。
2009年12月19日土曜日
SQL CLRで、一時テーブルのデータをCSVファイルに出力する関数を作ってみます。
今回の記事では、SQL-Server 2008 の一時テーブルに格納されたデータを、CSVファイルに出力するSQL CLR関数を作ってみます。
SQL CLR関数に一時テーブルのデータを渡す方法ですが、パラメータによるデータの受け渡しは一切やりません。
パラメータで受け渡しをするのではなくて、関数の内部において、直接、一時テーブルにアクセスして読み取るようにします。
そう、ここが、SQL CLRならではの威力であり重要なポイントです。
通常のSQL-Server関数は、内部で一時テーブルの使用って不可能ですが、SQL CLRならば、それが可能なわけです。これはあまりにもデカイ。
一時テーブルを使うにあたり、SqlConnectionクラスの接続文字列に大きなポイントがあります。"context connection = true"と記述すると、関数を呼び出したSQL-Server 2008のセッションをそのまま引き継いでくれるため、一時テーブルが消滅する事なしに継続して利用出来てしまうわけです。
ちなみに、今回作る関数は、特に一時テーブルだけという制限を設けてはいないので、通常のテーブルも指定出来ます。
関数の内部では、読み取ったテーブルを、一旦DataTableクラスのオブジェクトに格納してから、好きな文字コードでもってCSVファイルに出力します。
テーブルのフィールド名は、そのままCSVのヘッダになります。
CSVを扱うと言えば、SQL-Serverには、標準でOpenRowSet()という非常に便利な関数が用意されていて、CSVファイルもコレで確かに扱えます。しかし、フォーマットやファイル名に制約があったり、64bitではそもそもCSVファイルを扱うプロバイダMicrosoft.JET.OLEDB.4.0がうまく動作しなかったり(現時点では)、色々とやっかいな点が山積みというのが現実です。
やっぱり、自作出来るというのは何よりも大きいです。
オートだと、想定外の不都合が発生した時に、最悪の場合はどうにも出来なくなって途方に暮れるという恐怖と隣り合わせですもんね。
自分で作った処理ならば、何とかなりそうという安心感があります。
2009年12月18日金曜日
ゲームは、ますますレトロにはまる。ついにX68000とニンテンドウ64も復活。
■X68000用RPG「デスブリンガー」■
デスブリンガーは、私がX68000用として初めて購入したゲームなのです。
オープニングでは、サンプリングされた本物のカラスの鳴き声が響いて来るのですが、当時はこれがかなり衝撃でした。今であれば、手のひらサイズのPSPが、フルコーラスで歌ったりしゃべったり当然の時代ですけれど、電子サウンドが当たり前の当時は、サンプリング音声というのはそれだけで強かった!!
このゲームは、とにかく戦闘の難易度が高くて、辛かったです。
とにかく、プレイヤー側のキャラが(戦闘能力的に)弱い気がする。薄氷の上を歩くように進んで行ったなぁ・・・。
デモシーンみたいなものは少なくて、語るべきはゲームプレイさせて知らせるというタイプ。
かようにストーリー性は希薄なんですが、「キミが主人公だ!」的な性格の強いゲームだったので特に気にならないのが偉いところ。
フィールドは全て3Dなんですが、当時の3Dというのは、イコール迷路。どこもかしこも徹底的に迷路。
しょうがないんで、方眼紙にマッピングしながら歩いてました。いやープレイ時間が延びる延びる。
グラフィックスは、X68000の6万5536色パワーが遺憾なく発揮されていて、今見ても文句なしに美しいし、音楽は情感タップリで、なかなかの名曲揃い。
何とかクリアしたんですが・・・。よくクリアしたなコレ・・・ってタイプですね。
■操作してるだけで楽しいスーパーマリオ64■
ニンテンドウ64ともなると、さすがにハードウェアそのものが最新世代に近い性能なので、美しいポリゴンキャラクターが軽快に動く動く。
スーパーマリオ64は、ゲームクリアとかを度外視で、マリオを動かしているだけで楽しい傑作ですね。
サンディースティックをぐりぐり回してマリオでスラロームしてるだけでも時間が過ぎてしまうくらい。
側転や三段跳び、幅跳び、ヒップアタック。なんかもうスポーツゲームみたいな感じです。
ニンテンドウ64は、さらにゼルダの伝説/時のオカリナもあるので、末永く楽しめそうです。
2009年12月17日木曜日
SQL CLRで、CSVファイルを直接読み取る関数を作ってみます。 テーブル型で結果を返す方法の学習にもなります。
今夜は、仙台でもいきなり雪が降ってきました。ううむ・・・明日の通勤が心配です・・・。
それはそれとして、今回の記事では、SQL CLRでCSVファイルを直接読み取る関数を作ってみます。
CSVファイルと言えば、データは複数行で構成されますから、通常のスカラ型関数では扱いきれません。
いよいよテーブル型で値を返す関数となります。
また、先日の記事で書かせていただきましたが、CSVファイル(テキストファイル)を読み取るためには、アセンブリを通常のSAFE権限ではなくて、EXTERNAL ACCESS権限で登録しなければなりません。
このテーブル型関数は、スカラ型関数と比べるとかなり複雑であり、取り決めも数多く存在します。
この取り決めは、一つでも無視すると途端にエラーに直結してしまうので、面倒でも丁寧に覚えていかないといけないです。
■テーブル型関数を組むにあたって■
(1)独特な構造を把握する必要があります。
SQL CLR関数を宣言する[Microsoft.SqlServer.Server.SqlFunction]部ですが、スカラ型関数と違って、テーブル型関数の場合はもっと詳細な記述が必要です。今回は以下のようになります。
[Microsoft.SqlServer.Server.SqlFunction(
FillRowMethodName="SQLCLR_GetCSV_StreamRow",
TableDefinition="CSV_SEQ int,CSV_ITEM nvarchar(max),CSV_ELEMENT_COUNT int",
DataAccess=DataAccessKind.None
)]
特にFillRowMethodName="XXXX"というのは、超重要ポイントです。
テーブル型のSQL CLR関数は、かなり独特な構造を持っておりまして、作成した結果データは、SQL-Serverにreturnで直接戻したりしないのです。
returnされたデータは、SQL-Serverではなくて、FillRowMethodName="XXX"で指定した処理に送信されます。
この処理が、一行づつ、まるでストリーミングのようにSQL-Serverに戻してくれます。
自分でループ処理をプログラミングする必要は無く、FillRowMethodNameに処理名を記述するだけで、データの終了まで当該処理を繰り返してくれる仕組みになっています。最初は「えっ?」てなるかも知れませんが、何しろそういう取り決めなので慣れないといけないですね。
このように、テーブル型関数を作る時は、関数の本体と併せて、データを一行づつSQL-Serverに戻す「ストリーミング部分」の、二部構成で作るわけです。
この独特な構造を踏まえる事が、テーブル型関数のプログラミングを理解する事になる・・・と言えるかも知れませんね。
(2)関数本体の型は、クラスではなくてIEnamerableインターフェース
関数本体の型なのですが、クラスではなくて、IEnamerableインターフェースなのが大きな特徴になっています。このインターフェースにしないとエラーになってしまいます。
IEnamerableインターフェースを実装したオブジェクトならば何でも戻せるわけですが、今回は、List型のオブジェクトにデータをどんどん積んで行ってます。
(3)ストリーミング部分について
実際にコードのスクリーンショットを見ていただくと分かると思うのですが、ストリーミング部分は、関数本体から戻されたデータの、一行あたりの受信とSQL-Serverへの出力を定義しています。
型は無く、必ずstatic voidにします。
どこにもループ処理のプログラミングが存在していないので、いきなりコードを読んでも「一行あたりの処理」という部分は見えにくい点かと思います。
くどいようですが、処理の宣言部分にあるFillRowMethodName=""に名前を記述するだけで、繰り返しは自動でやってもらえるんですよ。
ここでも数々の取り決めがあります。まず、関数本体から送信されて来たデータは、必ずobject型で受信しなければなりません。object型以外ではコンパイルエラーになってしまうのです。
このように、テーブル型関数は、スカラ型関数と比べて驚くほどに様相が違っていますね。
2009年12月15日火曜日
2009年を振り返るシリーズ:メーカーや商品の好感度編
■好感度大アップの商品・メーカー■
今年を振り返ってみて、好感度アップしたメーカーは、まずパナソニック。
ホームベーカリーSD-BM102は、パンを焼く楽しさを教えてくれたし、完全に私の食生活を変えてしまった大ブレイク商品でもありました。
キヤノンは、最強クラスの中級カメラ「EOS 7D」を発売してくれてましたが、これそのものよりも、これがキッカケとなり、過去に発売されたEOS KISS X2の良さが再認識され、寿命が短いとされるデジタル製品でも、ずっと使い続けられる寿命の長さがあるのを再認識。全く予想外の方向からの好感度アップでした。
また、レンズのEF 100mm F2.8L MACRO IS USMがあまりにも素晴らしい出来。キヤノンは何だかんだやってても、最後は決めてくれる印象。
怒涛の突き押しで、好感度アップの度合いが飛躍的に高まったといえば、マイクロソフトです。
なんといっても、実のところ最初はあまり大きな期待をしていなかった「Windows7」が、使い勝手、デザイン、機能と三拍子揃った傑作な仕上がりに感動。ついにパソコン用OSがここまで来たか・・・。
また、同時購入の低価格ノートパソコン「Aspire 1410」の印象が素晴らしく良かったです。
私が過去に購入した数々のモバイル機器の中でも、Aspire 1410は、「何でも出来る」という意味において比類が無く、まさに頂点クラスの満足度。
Aspire 1410とWindows7のコンビネーションは、まさに何年かに一回しか起きない、奇跡のダブルパンチを私に食らわせたのです。
マイクロソフトは、さらに、SQL-Server 2008 Express、Visual Studio 2008 Expressなど、フリーソフトのExpressシリーズで魅力を振りまき続けています。好感度は止まらずにさらに上昇中。
ゲーム面でも、自分でソフト開発が可能というXNA Game Studioの存在を知りました。
Linuxを捨てたソニーを尻目に、マイクロソフトが独走するのか・・・?
興味が一気に出てきた感じです。
ソニーは、ゲーム部門では好感度ダウン。やはり、何度も書いて恐縮ですが、Linuxを捨ててキャラクターが大幅に変質したPS3と、またしても見切り発車の悪夢を再現してしまったPSP goのダブルダメージが大きい・・・。PSP goは、ハードそのものは良質なのに、他ならない生みの親たるソニーが、生んだハードに対して援護せずに見殺しにする「新型ハード出しっぱなし症候群」を繰り返している感があり、PSP goだけの問題ではなくて、大本命たる「PSP2」でも、さらに繰り返す不安がいっぱいです。
せっかくソニーが長い時間をかけて頑張ってきたPSPなんですから、一世代だけで終わりにならない事を祈るばかりです。
ゲーム部門のダウンに相殺された面もありますが、ソニーは、それで終わるメーカーではないです。
ちゃんと、ビデオカメラで大幅な好感度アップ。
裏面照射センサー(エクスモアR)と、虹彩絞りの採用によって、長年家庭用ビデオカメラに強いていた「暗さに弱い点」「ボケ味が汚い点」を一気に解決し、革命を起こしてくれました。
ソニーは、相変わらず力があっちこっちに分散している感じ・・・。
2009年12月13日日曜日
64bitのWindows7で、PS3のコントローラーを使う事が出来ました!!
あらゆる用途に大満足のノートパソコン「Aspire 1410」ですが、悩みはゲームプレイ時のコントローラー・・・。
市販のUSBコントローラーは、フィーリングや造りの面等で厳しいものがあるんで、こうなったら、手持ちのPS3のコントローラーを使えないかなぁ・・・と、色々調べてやってみました。
結論から言うと、64bitのWindows7でも、PS3コントローラーが使用可能でした!!
ただし、現在のところ、正攻法では不可能なのです。うーん・・・。想像以上に敷居が高いです。
まず、PS3のコントローラーは、何はともあれUSB接続しさえすれば認識だけはしてくれますが、それだけではゲームコントローラーとしては動作しないというのが、やっかいな点。
PS3本体との接続時からしてそうなんですが、接続した後にペアリングという作業をクリアして、自分は一体、1番から4番までのどのコントローラーとして振舞えば良いのか?というのを、本体から認識してもらわないとならないのです。ここが出来ないので、単に接続しただけでは使えないわけです。
64bit Windows7では、この点をどうクリアするかというと、ネットでMotionJoyというソフトをダウンロードして来て、PS3コントローラーUSB接続用のドライバをインストールして解決します。
しかし、64bit Windows7は、ユーザーが勝手に作ったドライバを拒否する仕様になっていて、インストールが出来ないのです。
これを回避する方法はただ一つだけ、起動の時に、F8キーを押してシステムのブートメニューを表示して、そこで「ドライバー署名の強制を無効にする」を選択してからWindows7を起動するという作業が必要です。
こういう事情ですから、この作業は正攻法とは言えず、安全性は全く保障できないのです。
この記事は、あくまでも、参考程度にしていただければと思います。
(1)MotionJoyをダウンロードする(正攻法では無いという事情から、リンクはあえてしません)
(2)Windows7を「ドライバー署名の強制を無効にする」モードで起動しておく。
(3)MotionJoyをインストール。これがユーティリティソフトになります。まだドライバは入っていない状態です。
(4)スタートメニュー「すべてのプログラム」から、MotionJoyのフォルダを開き、Install USB driverを「管理者として実行する」モードで実行して、ドライバインストール。
---これで、準備はOKです。
(5)念のためWindows7を再起動。その時必ず(2)の方法で起動するのを忘れない。
(6)再起動すると、Windows7から、MotionJoyがシステムに変更しようとしているけど大丈夫か?という主旨の警告が出てくるので、ここはOKする(しかない)。
(5)PS3のコントローラーをUSBケーブルで接続。
(6)PS3のコントローラーのLEDランプが1つだけ点灯していればOK。
LEDランプが4つ点灯した状態では、ペアリングされてない印なのでNG。
ぶっちゃけ、安定性とか安全性とか、このあたりの話はこの先どうなるのか分かりませんから、果たして喜んで良いものかどうか非常に悩みます。
何はともあれ、これでPS3のコントローラーがAspire 1410で、造りもタッチも申し分のないPS3用コントローラーが使えるようになったわけで、快適さはバッチリです。
2009年12月12日土曜日
SQLCLRで、アセンブリの権限を「SAFE」以上の権限に昇格する方法。
このブログでも度々SQL CLRのプログラムを書かせて頂いておりますが、それらは全て、最低限の権限である「SAFE」権限で動作しておりました。これをもっと上に昇格すると、クエリーの中から外部リソースへのアクセスまで可能になります。
SAFEの上は、「EXTERNAL ACCESS」権限と「UNSAFE」権限となります。
つまり、何が出来るのかというと、パッと思いつくだけでも、CSVファイルへの読み書きがクエリーから直接可能になったりするわけです。それだけを取ってみても価値は絶大と言えるでしょうね。
クエリーからCSVを読み込むと言えば、標準のSQL-Server関数ではOpenRowSet()関数があるのですが、現在のところ、64bit Windows7と64bit SQL-Server 2008 Expressの組み合わせでは、MICROSOFT.JET.OLEDB.4.0がうまく動作しないので使えないし、そもそも使えたとしても、拡張子は.TXTでなければならない、フォーマットを別に管理しないと数字と文字列を誤認する危険があるなど、自動ならではのやっかいさが残存してしまいます。
自力で関数が作れる道が開かれるわけで、何にせよ、もろ手を挙げて大歓迎ではないでしょうか。
さて、その方法ですが、例によって詳しくはスクリーンショットを見ていただければと思いますが、ちょっとだけ面倒です。
まず、話の流れから当然ですが、いきなり自分の作ったSQL CLRのアセンブリ(DLL)を登録しようとしても、権限がSAFE以外はエラーになります。
この壁を突破するには、以下の手順で事を進めていただく必要があります。
(1)自分のログオンIDではなくて、saユーザーでログオンします。
(saでなくとも良いのですが、分かりやすいようにsaとしました。自分で自分の権限は、いくらやっても変更できないのに注意が必要です。)
(2)作業用のカレントデータベースは必ずmasterにしておきます。
しないとエラーになってしまいます。
(3)SQL CLR関数を登録するデータベースに、以下のコマンドで信頼性を与えます。
私の場合は「SPDB」というデータベースにしているので以下のようになりますが、必要に応じてデータベース名は変更する事になりますね。
ALTER DATABASE SPDB SET TRUSTWORTHY ON;
(3)権限を与えたいユーザー(私の場合はmorimori)に対して、GRANTコマンドでもって権限を昇格します。私の場合は以下のようになりますが、ユーザー名は適宜変更する事になります。
GRANT EXTERNAL ACCESS ASSEMBLY TO morimori;
または
GRANT UNSAFE ASSEMBLY TO morimori;
として権限昇格。
(4)saではなく、今度は権限を与えたユーザーでログオン(私はmorimori)します。
うっかり忘れてsaのままで作業すると、(5)のアセンブリの登録でエラーになってしまいますのでご注意下さい。
(5)いよいよ、アセンブリを登録。
すると、以前はPERMISSION_SET = SAFE以外はエラーになっていたのに、
PERMISSION_SET = EXTERNAL_ACCESS
もしくは
PERMISSION_SET = UNSAFE
が成功します。
これで、いよいよ、たとえば、SQL-Server 2008 Expressから直接CSVファイルを読み込む関数などを自作する道が開けたわけです。
本日の記事はここまでにさせて頂いて、後日、CSVファイルを読み込む関数を作りたいなぁ・・・と思います。
ただ、テーブル型の値を返すSQL CLR関数になるのですが、通常のスカラ型関数と比較して、記述がかなり独特で複雑になってしまいますが、例によって、その価値は極めて高いものだと思いますので、やっておくと大吉でしょうね。
やはりパジェロミニは奇跡の名車かも知れない
まず、絶対に言えるのは、オートマは嫌。絶対に嫌。
主義・主張ではなくて、純粋に運転がつまらないのです。
人様のをお借りするなら、運転楽チンで良いんですが、自分で購入して、何年も乗るのかと思うと、まるで刑務所に入れられるような絶望感で、嘔吐しそうにすらなります。
車の運転の楽しさはマニュアル操作と一体なので、これを失うのは、個人的には車を捨てて何か別の移動手段を選ぶに等しい。
休み中に結構良いクラスのスポーツカーを運転する機会がありましたが、オートマだったので全く暇臭くてNGでした。
ただ、マニュアルなら何でも良いわけでもなく、理想は、エンジンが縦置きで、トランスミッションとシフトレバーが直結しているFRベースのマニュアル車。
このダイレクト感は、ちょっと筆舌に尽くしがたい、というやつです。
そう、生粋のスポーツカーのレイアウトであり、今の愛車のパジェロミニのレイアウトであります。
このブログでも繰り返し書かせて頂いておりますが、パジェロミニは普段はFRなのです。
必要な時だけ4WDに切り替える方式です。
パジェロミニは、絶対的なスピードは出ませんが、FRとマニュアルによる運転の楽しさは、馬鹿に出来ない物があります。
エンジンも、普通、軽といえば三気筒のイメージですが、パジェロミニは四気筒ですよ!
直列四気筒DOHC 20バルブツインスクロールターボエンジンを縦にレイアウトした五速マニュアル車。
後輪駆動ならではの、後ろから押されるフィーリングが楽しめ、悪路の突破をもこなす。
スタイリングは個人的にも最高ですし、まさに奇跡の名車かと思います。
逆に、新型になってしまうと怖い。
後輪駆動の楽しさは消えるのか、四気筒エンジンの上質なフィーリングは消えるのか、マニュアルの楽しさが剥奪されるのか、悪い事しか思い浮かばない・・・
ただ、ホンダが、後輪駆動では無いものの、ハイブリッドカーで6速マニュアルのCR-Xを発売してくれるのです。
何はともあれ、オートマに全てを叩き潰される世の中だけは回避して欲しい。
それだけが、新型のクルマに望む事です。
オートマは嫌。絶対に嫌。
死んでも嫌。
(追記)オートマは個人的に嫌なだけで、決して否定するものではないし、速さを求めるならスムーズな分、今やむしろ有利だし、色々なメリットがあるのも理解できます。ただ、選択肢がオートマのみというクルマばかりになってしまい、ディーラーさんから買え買えと言われても、応えたいけれどもそうはいかないという、何か変なプレッシャーに苛まれてしまって、おっつけオートマがますます嫌いになるという悪循環に陥ってます。オートマを乗っている方には、謝罪します。
レトロなアドベンチャーゲーム最高かも?
さすがに、アドベンチャーゲーム発祥時代の作品は雰囲気が違う。
王道かつ原初のアドベンチャーゲームばかり入手出来たので、この時代に憧れていた私にとっては、宝の山ばかりというところです。
今の時代だと、もはやアドベンチャーゲームと言えばサウンドノベル形式メインか、他のジャンルの要素が強かったりするゲームばかりで、王道なコマンド選択式アドベンチャーなんかにゃ、もはや出会えないんですよね。
■「ジーザス」クリアしました■
長年プレイしたかった「(ゲーム機版じゃないという意味で)本物のジーザス」。
MSX2版でその願いがかないましたが、さらに、クリアする事も出来ました。
過去にファミコン版(ジーザス/恐怖のバイオモンスター)はクリアしていたのですが、どちらも「探索」シーンでの手こずりがそのままプレイ時間につながるスタイルでしたね。
たとえば、コマンド選択結果が「正解」をサクサク引き当てれば、早く進めて早く終わるし、逆に重要アイテムが見つからなかったり、シーン切り替えのフラグを立てられずに、同じシーン間をウロウロしてしまうとプレイ時間がダラダラと長くなるわけです。
このあたりは、ゲーム容量が自由にならない時代の空気があって、これはこれで良い感じですね。
レトロ時代のパソコンゲームらしいなぁと思うのは、コマンド内容にヘンテコなのが出てくる点。
ジーザスと言えばシリアスなSFサスペンスだというのに、女性キャラクターが登場するたびに「みる 胸」とか、今の時代だったらありえないコマンドが当たり前のように登場するのも時代のなせるワザ?か。
時代と言えば、昔のハリウッドの名画なんかでも、今見ると、女性の評価基準が顔の美しさばっかりだったり、男は空気のようにタバコを吸いまくりだったりしますからねー。おそるべし時代の壁。
まぁ、とにかく、ジーザスは大満足です。
操作性についても、MSXだと、ゲーム機ではありえない、テンキーでのコマンド選択式なのも新鮮でしたね。
ストーリーについては、申し分なしですが、主人公のサポートをする人工知能「フォジー」の扱いの悪さは、気になりました。ちょっとかわいそう。
特段、良き相棒ってエピソードもないし・・・。ここまで中途半端に仲の悪い相棒も滅多にいないのじゃないかなー。
それと、バルカスが食べていたハンバーガー。おいしそうでした。
バルカスは、ハンバーガーが大好きな男で、なんと宇宙船に大量に持ち込んでます。
このハンバーガーネタが頭にあったせいで、昨日は久しぶりにマクドナルドのハンバーガー食べたのかも知れないなぁ・・・。マック非常においしかったです。
■ファミコン探偵倶楽部/消えた後継者は前編クリアしました■
ジーザスと平行して、ファミコン探偵倶楽部もプレイしてましたが、ようやく前編クリアしました。
こちらは、選択コマンド数が少ないのですが、決して簡単ではないのがミソ。このコマンドはこのシーンでは使い物にならないだろうな、と勝手に思い込んで使わないと行き詰まるようになってます。
ファミコンディスクは片面しか読めないので、自然とディスクのA面とB面の取替えが発生するのですが、試行錯誤であちこち移動してるって時に、移動するシーン先によって面の入れ替え指示が出る場面は結構きつかったですね・・・。
ただ、MSXもそうなんですが、当時のマシンのディスクというのは、今のBD-ROM以上に代わるものが無い大容量メディアだったはずなのです。
そのイメージは、時代を超えた今でもかなり強くて、たとえば、小指の先くらいのメモリカードが16GBとか32GBの時代になった今から見ても、片面56KBしか無いはずのファミコンディスクが大容量だと錯覚してしまいそうになるんで面白いです。
■次は何をプレイしようかな■
ファミコンディスクは、まだまだファミコン探偵倶楽部やファミコン昔話シリーズがあるし、MSXと来たら、もう名作が大量過ぎて何をプレイしようか分からないくらいですね。
ジーザスと同じエニックスが発売したソフトだけでも、考えられるのは、ファミコンには移植されずじまいだった堀井雄二氏のAVG「軽井沢誘拐案内」(MSX-1カセット)、アンジェラスあたりは磐石のタイトルか・・・。どっちもプレイしたくてしょうがなかったけれど、今日まで雑誌でしか知らない・・・。
早くソフト遊びたいなぁ・・・。
しかし、不思議なもんです。今年の前半のうちは、まぁ今頃はPS3を買い直してハイビジョンゲームしてるだろうなと思ったら、そっちには興味が失せてしまって、ファミコンやMSXで名作タイトルにハマっているとは・・・。でもこれでいいんだ。
■PSPは・・・■
PSPは、あいかわらずゲーム機より音楽プレイヤーとして活躍中。
ゲームでは、先日購入した、傑作と名高い「ときめきメモリアル2」ですが、これ、まだPSストアからダウンロードしてません。約3GB分のメモリカードを空けることが出来てない・・・。面倒なので、別な4GBのメモリカードにインストールしてしまって、差し替え式でプレイしてしまおうかとか考えてます。
UMD版の新作ソフトでは、やっぱり「ときめきメモリアル4」買おうかどうか迷ってます。
いや、友達も大プッシュしていて面白いのは間違いないでしょうが、まだ2が未プレイなのに買うのはどうかなぁという所です。
来年は、やっぱり「鉄拳6」でしょうね。この2本かな。
その後は、もしかしたら2010年に出てくる可能性もある「PSP2」への準備をしたいなーと。
2009年12月11日金曜日
激うま!!バーガータイム
先日、家族が「マリネルバーガー」から、カツとねぎ味噌バーガーを買って来てくれました。
マリネルバーガーは、バーガーといっても肉じゃなくて、新たなる仙台名物を目指してか、ヘルシーな揚げかまぼこバーガー専門店。
確かに、味付けはヘルシー系。
うん。組み合わせ的には、揚げかまとパンは悪くは無い。開発している方の苦労や知恵がしのばれるおいしさ。だけど、たとえば、マクドナルドやケンタッキーフライドチキンみたいな、企業秘密クラスの秘伝の味・・・みたいなパンチは無い気がする。
パンと揚げかまの組み合わせだね!!以上のモノがあればなお良かったかも!
そこまで要求するなと言われたら、すみません。
バーガーと言えば、正直、マクドナルドのハンバーガーが猛烈に食べたくなる味だったかも。
そして今夜、仕事帰り。なんかいつにも増してエネルギー切れが酷かったので、夜中で人もまばらなマクドナルドに駆け込み、久しぶりにハンバーガーを注文してみました。100円のやつ。
久しぶりだったからか、むっちゃくちゃにおいしかった!!
まさにバーガータイム。鼻に抜けるマクドナルド独特の強い匂い。う・・・パンチが効いている。
夜中だけど、かなり空いていたからなのか、ハンバーガーに使った油も汚れていない感じで好感度アップ。持ち帰りで5個注文してしまいました。
スーパーとかでラップかけて売られているバーガーと比較して、作りたてという事を考えたら、やはりマクドナルドの100円バーガーは、かなり安いなぁ。
私は、体形は、どっちかというとヤセ形なんですが、バーガーはカロリーとか太るとか気にしてちゃだめ。
ドカーンと食べて後で運動しまくればいいや。
SQL CLRで、文字数単位ではなくてバイト単位で文字列を扱う関数を作る
さて、最新世代のコンピュータは、文字列を扱う時に、もはや半角・全角という概念を持ったバイト数単位ではなくて、単なる文字数単位で扱うようになりました。
英語圏では都合が良いでしょうが、日本では、全角=2バイト、半角=1バイトが絶対の前提条件という場合が極めて多いわけです。
SQL-Server 2008 Expressもその例にもれず、文字列の扱いを文字数単位で行います。
そこで、SQL CLRによって、文字列をバイト数で扱う関数を作ることとしました。
ちなみに、帰宅してから、ウンウン言いながらAspire 1410で作ったばかりなので、テストは十分に出来ていません。
もしこんなコードでも参考にしていただけるなら、そのあたりはご容赦下さいませ・・・。
さて、文字列関数というと、任意の位置を切り出すSubString()、右側から文字数分切り出すRight()、左側から文字数分切り出すLeft()関数の三つがメジャーですが、これら三つのバイト単位処理のプログラムを実現します。
まず、全ての関数の中心となるプライベートなコア関数、直接は外部から呼び出せない「fnc_Core_StringB()」関数を作り、全ての関数はこれをコールして動作する・・・という仕組みにします。
コア関数一つ作っておいて、あとは簡単にSQL CLRのバリエーション展開で済ませたいなと。
■バイト単位=Shift JISで文字列を扱う!!■
バイト単位ということで、通常のUnicode形式の文字列のままではどうにもならないので、文字列をShift JISのバイナリ配列に変換して操作します。
実のところ、変換するだけなら、非常に簡単にコトが済むのです。
しかし、バイト単位で絶対に忘れてはならない点は、全角の文字を半分に断ち割ってしまうケースがあるということです。
たとえば、「あいうえお」という文字列があったとして、0バイト目から2バイトを切り出すなら結果は「あ」でOKですが、これが1バイト目から2バイトなんてやってしまうと、「あ」の半分を断ち割ってスタートしてしまいますよね。こういうのがマズイのです。
全角の前半分を1バイト目、後ろ半分を2バイト目と呼称しますが、どっちかを断ち割った状態で、そのまんま変換すると、文字化けしてしまって使い物になりません。
たとえば、半角の空白(16進数で0x20)に置き換える処理をしてあげないといけないです。
しかし、Shift JISコードの恐ろしさはここからなんですよね。
Shift JISコードは、全角の1バイト目と、全角の2バイト目が、単体では識別が出来ないという全く恐怖の仕様になってます。
バイナリを先頭から1バイトづつ順番に見て行き、全角の1バイト目を示す値だったら、次に来るバイトは必ず全角の2バイト目としてペアにする・・・という見方をしないとうまくいかないのです。
全角の1バイト目を示す値というのは、16進数「0x81」から「0x9F」、または、「0xE0」から「0xFF」の範囲に該当する、ということです。
じゃ、単体でこれ見れば済む話じゃないか!!先頭からズラズラ見る必要なし!!って思いますよね。
問題は、全角の2バイト目であっても、平気でこの1バイト目を示す範囲に入って来るという点です。知らないとヤバイくらいハマる危険アリ!!
だから、先頭から順番に見ないと、うまくないのです。単体のバイトを取り上げてチェックしてもだめなんです。この事実を知った時は、結構途方に暮れますよね。
というわけで、多少強引ではありますが、今回の記事では、文字列のバイト配列と1:1で対応したステータスの配列を作って並べて使う事にしてみました。
このあたりの処理は、もはやSQL-Serverの標準関数では作る気が失せてしまうくらいなのですが、SQL CLRがあってくれて、本当に良かったー・・・としか言いようがないです。
マイクロソフトの担当者には足を向けて寝られない気持ちですね。
詳しくは、プログラムコードのスクリーンショットを見ていただきたいのですが、C#言語で関数が組める幸せを噛み締めるしかないくらい、好きなように作れますよね。
パフォーマンスも、データ内容によりますが、単純な切り出しならば1万件程度ではパフォーマンスもほとんど悪化しなかったです。単純なテストデータをパパッと作っただけなんで、限定的な話でしょうけれど。
さて、今回の関数ですが、コア関数のfnc_Core_StringB()関数は、外部から直接は呼び出せませんがも、内部にあって全ての処理を行う文字通りのコア、メインです。
任意の位置で文字列をバイト単位で切り出すSQLCLR_SubStringB()
右側から文字列をバイト単位で切り出すSQLCLR_RightB()
左側から文字列をバイト単位で切り出すSQLCLR_LeftB()
の三つは、このコア関数をささっとコールしてるだけで実現してます。
ちなみに、List
かならずobject型になり、object型から実際に使用する型への変換オーバーヘッドの存在したArrayListと違って、
でもでも、古いバージョンの.NET Frameworkではコンパイルエラーになるので注意が必要です。
2009年12月8日火曜日
SQL CLRで、JANコードのチェックデジットを算出する関数を作る
今回は、バーコードのチェックデジットを算出するスカラ型関数です。
よく、商品のパッケージなどにバーコードが印刷されていますけれど、あれは多くがJANコードと呼ばれる種類のバーコードで、13桁もしくは8桁の数字で構成されております。
あの数字は、ただ並べられているだけはありません。
特にその最後の一桁の数字は、チェックデジットと言って、「モジュラス10ウェイト3」という計算方法で算出された暗号となっています。
暗号と一致しない数列は無効となってバーコードリーダーなどの機器で読み取る事が出来ない仕組みになっているのです。
チェックデジットの算出は物流系の仕事をやるのなら、必須知識だったりします。
今回の関数(SQL CLR)は、そのチェックデジットを算出するものです。
一応、JANコードのチェックデジットという事にしていますが、今回作った関数は、求めたいコードの桁数に制限を入れていません。オーバーフローするまで何桁でもOKです。
手入力で
SELECT SPDB.dbo.SLQCLR_GetCd(498704520564,0);
と入力すると、コード498704520564のチェックデジットである4が算出されます。
でも本来の目的は、チェックデジットを求めたい数列を大量にテーブルに格納しておいて、全行のチェックデジットを一発で求めるというやり方です。
このようなやり方においては、SQL CLRの処理速度の速さが決定的に効いて来ますね。
試しに30万件程度のテストデータを作って回してみた所、純粋にTransact SQLで作った関数でやってみたら結果が出るまでに50秒かかったところ、SQL CLRでは、なんとたった4秒で結果が表示されました。
やはりSQL CLRのパフォーマンスは高いですし、C#言語でプログラムが組めるメリットはあまりにも大きいものがありますね。
しかし、最近、帰宅してからというもの、SQL-Server 2008 Expressにハマリまくってます・・・。
買ったばかりのAspire 1410のキーボードですが、打ち過ぎて?? 早くもキートップがテカテカして来てしまった。うう・・・やだなー。
ちなみに、せっかく買ったPSP等のゲームが全くプレイしないまま積み上がっているので、もうしばらく新作ソフトは買わないようにしようかな。
「SQL CLR」SQL-Server 2008 Expressの関数をC#言語で作る!!
SQL-Serverは、SQL-Server 2000の時代から関数を作る事が出来るのですが、それは、あくまでもSQL(Microsoft Transact SQL)の範囲内でのプログラムになってしまいます。
本来ならば、データベースを操作するための言語であるSQLですから、通常のプログラミング言語と同等の処理を組み上げるのは独特の苦労がありますし、一行ごとに値を返すスカラ型関数を使う場合は、パフォーマンスの厳しい低下も想定しなければなりません。
こうなったら、関数をC#言語で作れたら良いのになぁって、やっぱり思いますよね。
それをズバリ実現したのが、SQL CLRと呼ばれる仕組みです。
しかも、SQL CLRは、高価な製品版のVisual Studio 2008を買う必要はなく、フリーのVisual C# 2008 Expressでバッチリ作る事が出来てしまうのが嬉しいところ。
ただ、SQL CLRには、非常に厳しいセキュリティの壁が立ちはだかっています。
C#言語でプログラムが作れるということは、何でも出来てしまうわけで、そもそもSQL-Server 2008 Expressは、インストールしただけではSQL CLRの機能が封印されています。
SQL-Server 2008 Expressのポリシー管理などで、封印されているSQL CLRを使えるように設定するのが第一歩です。
とりあえず、これで、一番厳しいランクのセキュリティである「SAFE」で動く関数だけは記述できるようになります。「SAFE」以上の権限である「EXTERNAL ACCESS」と「UNSAFE」は、今回は取り上げず、また後日の記事で書かせて頂きたいと思います。
SQL CLRを使えるようになったら、以下の手順でSQL関数を作る事が出来ます。
今回は、サンプルプログラムとして、一行のCSVデータから、指定した順番(0スタート)の要素を抽出するという関数を作ってみました。
こういう処理は、確かに通常のSQL関数でも作れますが、コードが非常に複雑になる上にパフォーマンスが厳しいものになりがちです。しかし、SQL CLRならばその心配がほぼ解消されております。
さて、作成・登録の手順ですね。
(1)Visual C# 2008 Expressのプロジェクトは、「クラスライブラリ」を指定。
SQL関数の文法に沿ってプログラムを記述します。これがSQL CLRとなります。
(2)作ったプログラムをビルドすると、DLLが出来上がります。
このDLLを、SQL-Server 2008 Express側で「CREATE ASSEMBLY文」でもって登録。
これを「アセンブリを登録する」と言います。DLLはアセンブリと呼ばれるのがポイント。
(3)SQL-Server 2008側で、SQL CLRと一対一で対応した、インターフェースだけのSQL関数を記述して、両者を紐付けます。
(4)実際の使用は、(3)でSQL CLRと紐付けたSQL関数を使います。
しかし、中身はC#言語ですから、パフォーマンスは桁違いに高まる可能性があります。
詳しくは、実際のプログラムコードのスクリーンショットをご覧いただきたいのですが、C#言語側には、SQL CLRならではの部位が色々と出てきます。
大きなポイントは、関数の前に[Microsoft.SqlServer.Server.SqlFunction]を宣言している点です。
忘れやすいのですが、これが無いと、SQL-Serverは、関数が見つからないと言ってきますので注意が必要です。
型に関しては、Sqlxxx型を使っていますが、これはSQL-Serverとのやりとりでパフォーマンスがアップするので使っていますが、通常の型でもエラーにはなりません。
注意が必要なのは、SQL-Server側で対応する型です。
文字列は、必ずUnicode型でなければエラーになってしまいます。C#言語側のSqlString型やstring型に対応するのは、SQL-Server側ではnvarchar型であり、nの付かないvarchar型などでは、エラーになってしまいます。この点に気が付かないと、正しいはずなのにエラーが消えないという苦しい展開になってしまいますので注意が必要です。
また、登録の解除ですが、アセンブリ(DLL)の削除をするには、登録した全ての関数を削除してからじゃないと駄目です。1つのアセンブリ(DLL)に沢山の関数を抱えていると、再登録が大変かも知れませんが、そこはうまくスクリプトを組んでおくなどすれば、大丈夫だと思われます。
登録はちょっと面倒ですが、こればっかりは何回か作業をしてみて慣れるしかありません。
しかし、その面倒を遥かに超えるメリットが、SQL CLRには存在します。
とにかく、SQL-Server単体では絶対に不可能だった機能が作れるようになるし、既存の関数をSQL CLRで作り変えるだけで、劇的なパフォーマンスアップをする可能性もあります。
今回のサンプルコードではありませんが、実際に私が普通のSQL-Server関数と、SQL CLRで作った同等機能の関数を使った時、30万件程度のデータに対するスカラ型関数の使用において、12倍もの速度差が付いたものがあります。
また、Visual C# 2008のソリューション管理を使って、DLLをデバッグするためのプロジェクトを作っておく事も可能です。
Visual C# 2008 Expressによるデバッグが可能というのは、生産性という面からも絶大なメリットがあります。
このSQL CLRは、大げさでも何でもなく、まさにSQL-Server 2008 Expressの必殺技と言っても過言ではない、極めて極めて大きな機能です。
SQL-Server 2008 Expressをやるのならば、絶対に覚えておいて損は無いはずです。
私もまだまだ勉強中ですが、頑張りたい機能です。