で。結論から言うと遅くなります。(というか使用されません) ただし...

1.サンプルデータ作成

まず、データを準備します。100万件のサンプルデータを用意し、"sex"カラムを性別と見立て(0=男性, 1=女性)ランダムに設定します。

2.インデックス付与前

それでは、データの準備が出来たので、インデックスなしの状態でクエリを流してみます。

[インデックス付与前 - 実行計画]

[インデックス付与前 - 実行時間]

3.インデックス付与後

次にインデックスを付与した状態でクエリを流します。
(何か切ないですが、そのままだとインデックスは使用されないのでテーブルヒントを与えます。。。)

[インデックス付与後 - 実行計画]

[インデックス付与後 - 実行時間]

4.理由

ここまで、茶番劇のようですが確かに遅くなりました。なぜでしょうか？
よくインデックスは書籍の索引に例えられますが今回作成したインデックスを例えるとこうなるはずです。

本で例えると1,3,6,10のページをめくる為には必然的に（ブロックサイズを5ページと仮定）1～10ページをめくっているのと変わらないことになります。そこでRDBMSはこう考えます「結局全部めくるんなら、索引とか開くの面倒だからインデックス使うのや～めた」と。

5.本のページをめくる必要がない場合

ここまでで、「性別」にインデックスを付与しても意味がない(使われない。使っても+αの処理が発生するため遅くなる)の理由ですが例外があります。それは、本のページをめくる必要がない場合です。

例えば、件数を取得するだけなら人もRDBMSも同じで索引の男性に書かれているページ番号を数えるだけで事足ります。仮にインデックスがない場合(全データ走査)と比較すると100万件で約25倍の差が出ました。

[インデックス付与前後 - 件数取得(左:付与後, 右:付与前)]

6.本のページをめくらせない

結局、本のページをめくらなければ(データへのアクセスがなく、インデックスで事足りる場合)「性別」のインデックスは有用だということが解りました。だたし、性別毎の平均年齢を調べようものなら、やはり全てのページをめくる必要があります。(「4.理由」の通りインデックスは使われない)

そこで、ページをめくらないようにする方法にカバーリングインデックスと呼ばれるSELECTやWHEREに含まれるフィールドを全て網羅(カバー)するものがあります。「インデックスに年齢も含めてしまえば事足りるよね」の考えで本の索引で例えるとこのようなものです。

[カバーインデックス付与前後 - 性別毎平均年齢(左:付与後, 右:付与前)]

ということで、「性別」のインデックスは一概に意味がないとは言えませんが、インデックスを付与するとデータサイズの肥大化や更新処理の速度低下を招くため用途に応じた適切なインデックスが必要です。

また、今回一般的なB-Treeインデックスについて記載しましたが、ガーディナリティが低い(性別、各種フラグ、カテゴリの様にデータの種類が少ない)フィールドには「ビットマップインデックス」という種類のインデックスが効果的な様です。

以下の様なテキストがあったとします。
下記の文章から３行ほど削除したい場合、vi使いの方なら、該当行にカーソルを移動し、「3dd」と入力します。

ビジュアルモードが利用可能なvimの場合、以下の様にする事で視覚的にもわかりやすく削除する事が可能です。

1. 「shift + v」行選択モードにします。

2. 「j」「k」で範囲選択します。

3. 「d」押下で、選択範囲を削除する事が可能です。

これを応用し、もう少し素早く特定範囲のテキストを削除する事もできます。
今回はJavaScriptのfunction 「hoge」を削除したいと思います。

1. カーソルをhoge末尾の「{」に移動します。

2. 「shift + v」行選択モードにします。

3. 「%(shift + 5)」押下します。

「{」に対応する「}」にカーソルが移動します。
行選択モード上記の操作を行う事で、「{」から「}」までを選択する事ができます。

4. 「d」押下で、選択範囲を削除する事が可能です。

以上、ちょっと便利な小技（４）でした

• enchant.jsの概説
• GIMPでドット絵を加工する
• ゲームで使う数字の遊び方

準備

解説用ファイル

以下のファイルをダウンロードしてください。
今回の解説用に手を加えたソースファイルです。

【添付ファイル】enchant.zip

添付ファイルの内容

/enchant.js

enchantエンジン本体です。(今回は触れません)

/plugins

利用しているプラグインファイルが入っています。(今回は触れません)

/examples/action/index.html
/examples/action/game.js

今回参考にするサンプルのオリジナルです

/examples/action/index.comment.html
/examples/action/game.comment.js

今回参考にするサンプルにコメントのみを加えたファイルです。

/examples/action/index.fix.html
/examples/action/game.fix.js

今回参考にするサンプルを改造したファイルです。

/examples/action配下には上で説明しているファイル以外が含まれています。
これらはゲームやプラグインから呼び出されるものなので、今のところ気にしないでください。

ドキュメント

以下のドキュメントが読めるようになれば、enchant.jsを使ったゲーム開発で困ることはないと思います。

Reference

enchant.jsを大まかに知るのに適しています。
私の解説が足りないとき、こちらを参考にすると良いと思います。

Class Index

enchant.jsの各クラスに関する詳細です。

オリジナルソースの解説

オリジナルのソースコードにコメントのみを追加した添付ファイルを元に解説します。
以降、特に断りなくコードと言う場合は[/examples/action/game.comment.js]を指してます。

enchant.jsは、ツリー状にゲームオブジェクトを保持しています。
Game-Scene-Node(の派生オブジェクト)という階層を作った上でGameオブジェクトのstartメソッドを呼び出します。
各オブジェクトはenterframeイベントを持っており、パラパラ漫画のようにゲーム中の各コマで実行されます。
キャラクタの動きやスクロール、ゲームオーバーの判定などはそれぞれのオブジェクトのenterframeイベントで処理されます。

今回の解説にアクションゲームを選んだのは、ソースコードが一番読みやすいからです。
上から読んでいけば理解できる順序でコーディングされています。

基本的な流れは

1. Gameオブジェクトの宣言と設定
2. Gameオブジェクトに追加する各オブジェクトの宣言と設定、enterframeイベントの実装（の繰り返し）
3. ゲーム開始

というシンプルなものですが、2点ほど注意が必要です。
ひとつはスコープ、もう一つはクロージャです。

スコープ

ほぼすべての処理がイベントとして定義するFunctionの宣言として記述されています。
「window.onload→game.onload→bear.enterframe」といったイベント用のFunction中にさらにイベント用のFunctionが定義されています。
コード中に各スコープの開始と終了をコメントしています。
各スコープの中での「this」が何を指しているか、混乱しないように注意が必要です。

クロージャ

クロージャ - Wikipedia

enterframeイベント内のコードを読んでいると、イベントスコープの外で宣言されているgameやbearが普通に出てきます。
これがいわゆるクロージャで、gameやbearが宣言されたスコープ(onloadイベントなど)を外れた後にも参照され続けます。

当然gameやbearが宣言される前に参照できないので、コードを整理する際に順番を間違えて動かなくなったりします。
場合によっては便利なのですが、何でもかんでもクロージャで解決していると、どんどん可読性が落ちて行きます。
まずはきちんとオブジェクト構造を整えることが大切です。

改造ソースの解説

ここまでの説明と公式のドキュメントでオリジナルのコードは大体読めると思います。
添付の[/examples/action/game.fix.js]にも少し触れます。

オリジナルのアクションゲームは読みやすい半面、これを元に規模を大きくしていくには向いていない部分があります。
ある程度の規模のプログラムになってくると、別の読みやすさが必要になってきます。
オブジェクトの定義と利用がキレイに分かれている方がゲーム全体の流れを追いやすくなるのです。

サンプルソースを読みにくくさせているのは他の部分に比べて極端に長いクマの定義とマップデータですので、これを外に出します。
ついでなのでRectangleオブジェクトも外に出してしまいます。
ここで注目したいのは長い宣言を外に出したおかげでgame.onloadイベント内がすっきりして読みやすくなったことです。

鍵を持っていれば扉が開く、といったゲーム中の出来事をわかりやすく記述するために、それ以外のコードはそれ以外の場所に記述すると良いと思います。

次に読むべきコード

enchant.jsを使ったゲームの作り方の入り口を簡単に解説しました。
小さなゲームならもう作れるのではないかと思います。

まだ少し不安が残る場合には、enchant.jsにサンプルとして同梱されているシューティングゲームのソースコードを読むことをおすすめします。
今回の解説は何だったんだと怒られてしまいそうですが、シューティングゲームのコードは最初から各オブジェクトの定義が外だしされています。
また、コメント内で詳しく実装の解説がなされているので、実際にゲームを作る際のenchant.jsの使い方がとても良く分かります。

まずは公式ドキュメントに慣れることが大事と思い、今回シューティングゲームではなくアクションゲームを題材に選んでみました。

今回はそういった細々とした情報を扱う際の数字遊びを紹介します。
enchant.jsでゲームを作ることを想定しているのでjavascriptで書きますが、基本的には言語を問いません。

三項演算子

要はIF-ELSEの条件式と同じような動きですが、式の中にかけます。
多用すると読みにくくなりますが、IF文や一次変数が増えた方が読みにくくなってしまうこともあります。
ちょっとした条件をスマートに書きたいときに便利です。

次の例はキー入力を管理するオブジェクトの宣言部分です。
イベント時などゲームは止めたくないけど入力はさせたくないときに空のオブジェクトを渡して操作できなくしています。

次の例はジャンプ中の落下加速度の計算部分です。
落下スピードをマップの単位よりも大きくすると当たり判定が面倒になるので必要以上に加速しないようにしています。

剰余(%演算子)

ある数をある数で割ったときの余りを計算します。
知っていれば普通、知らなければナルホドなのですが、アニメーションや当たり判定の時に重宝します。

次の例ではアニメーション画像３枚を切り替えるオフセット値を設定しています。
加算、剰余、代入をまとめて書いてあるのでちょっと分かりにくい例ですね。

次の例はキャラクタとマップの(Y方向の)当たり判定部分です。
enchant.MapのhitTestメソッドは、当たっているかどうかしか判定してくれません。
なので、壁にめり込んだ部分を何ドット戻せば「接触している」状態になるかを自分で計算する必要があります。
めり込んでいることが分かっている座標をマップの単位（タイルの大きさ）で割った余りがめり込んでいるドット数です。

切り捨て

ある数をある数で割ったときに整数で結果が欲しいときがあります。
言語によっては整数型は整数型でしか結果が返ってこないものもありますが、Javascriptでは明示的に切り捨てる必要があります。
算数的にはごく普通なのですが、言語仕様としてはマイナス方向の切り捨てには注意が必要な部分です。

Math.floorの場合、「もっとも小さい整数値」を返します。
マイナスの時、整数部の値が変わることに注意が必要です。

Math.roundの場合、「四捨五入した整数値」を返します。
少数部が0.5以上の時、整数部の値が変わることに注意が必要です。

【参考】剰余と切り捨てで2次元を表現する

剰余と切り捨てを使うことで、平面座標を表現することができます。
enchant.Spriteの画像位置計算でも使われていると思います。

カウンタ各種

最後に
特にゲームではちょっとした場合にちょっとした値を使いたいことがよくあります。
これらすべてに宣言、代入、条件分岐を書いているとコードが膨らんでしまって肝心な部分が読みにくくなります。
簡潔にかけそうな式を紹介します。

0～Xを繰り返す
上の剰余で説明しているので省略します。

1と-1を繰り返す

0とXを繰り返す(例は0と1の繰り返し)

ほとんどの素材はそれぞれの用途を想定した形で配布されていますが、必ずしも自分の思った通りに配布されているものでもありません。
今回はGIMPを使ってそんな素材のうちドット絵を自分の用途に合わせて加工する方法を紹介します。

※使用と加工の際には配布元のライセンスにご注意ください！
※サンプル画像としてenchant.jsに同梱されているものを利用しています。

グリッドを表示する

ドット絵は同じサイズの画像を複数枚入れ替えてアニメーションを実現します。
加工の際には画像の配置がずれてしまわないように注意が必要です。
その労力を軽減するために、画像サイズに合わせてグリッドを表示しましょう。

メニューから「表示 > グリッドを表示」でグリッドが表示できますが、そのままでは画像のサイズと合っていないことがあります。

メニューから「画像 > グリッドの設定」でグリッドのサイズなどを変更することができます。

これでグリッドが画像にぴったり合いました。

画像の切り抜き

配置を変えたり、1枚の画像を複数枚に分割したりしたい場合には画像の切り抜きを行います。

ツールボックスから切り抜きツールを選択して、切り取りたい部分をドラッグすれば範囲が選択できます。

選択した範囲の上下左右はマウスで微調整できます。

Enterキーで切り抜きを実行します。

ちなみに、範囲選択ツールでも同様に選択できますので、切り抜きではなく、コピーを行いたい場合はこちらを使います。

背景色の透明化

配布されている素材の背景が透過されていないものも少なくありません。
これを綺麗に取り除くには以下のようにします。

ツールボックスからファジー選択ツールを選択して、切り取りたい背景色をクリックすると、同じ色がすべて選択されます。

背景色が選択されている状態でDeleteキーを押せば取り除けます。

なお、連続していない背景色部分はこの操作だけでは取り除けません。
これは仕方ないので丁寧に消していきます。

少し触ってみましたが、シンプルさとJavascriptの柔軟性、妥当なフレームワーク構成でちょっとしたゲームならすぐに作れます。
凝ったゲームを作る場合のクラス拡張がとても簡単で、設計にセンスを感じます。

すでに発表から時間が経っていること、日本初のフレームワークであることから、ネット上に情報はたくさんあります。
ですが、本家の情報がとてもわかりやすいので、本家の情報とサンプルコードで学ぶのがよいと思います。

Reference enchant.js

enchant.jsを構成する、ゲーム作りに必要なクラスについて、ひと通りざっくりと説明しています。
サンプルコードを読み進める際にはこのぐらいの情報がちょうどよいと思います。

公式ドキュメント（JSDoc）

ソースコードから抽出したドキュメントと思われるリファレンスです。
説明は少なめですが機能が網羅されているので、詳しく調べたいときに重宝します。
enchant.jsにも付属していますので、通常はそちら（付属版）をみることになります。

9leap

enchant.jsの投稿サイトです。
主に若い人向けにゲームコンテストを開催しているようですが、参考になるゲームやハマってしまうゲーム、便利なプラグインが発表されていたりと見ていて飽きません。

以上、enchant.jsに関する情報を紹介しました。
次回以降で実際にゲームを作る作業を紹介したいと思います。

・ちょっと前にも同じようなことを記述した記憶がある。
・似たような機能(画面)が既に存在したので、コピー＆ペーストでコードを複製した。
・コードの中にコメントを記載しないと意味が解らない変数やマジックナンバーが沢山ある。
・バグが入り込んだ際に、原因の特定に時間を要する(修正が困難)又は、途中でトレースするのが嫌になった。
・仕様変更による影響が多岐に及び、対応/評価に莫大な時間を要した。

この様な経験があれば、リファクタリングが必要なのかもしれません。

リファクタリングとは機能を変更することなく、コードの組み換え等を行い仕様変更への耐性、保守性の向上を行う技術です。
この技術の根本には、仕様というのは変動的であり、多くの場合に漏れ(抜け)があるという考えのもと行われます。
例えば、同様のコードが見つかった際に、共通化する小さな努力を怠ったり複製を行うと、修正が発生した場合に対象が多岐に及ぶことは避けられません。

ただ、このリファクタリングを行う際に、一番注意しなければならないことは
『リファクタリング前後で動作が変わらないこと』です。
ただ闇雲に行なってしまうと、正常に動作していた機能が動作しなくなるばかりか、芋づる式に修正範囲が広がってしまい、逆に手が付けれないことにもなりかねません。
大きなリファクタリングを行う際は、テスト方法も併せて十分検討する必要があります。

次は小さなリファクタリングのサンプルです。この処理は何を意味するのでしょうか？

int work = 100 / 37.5782;

マジックナンバー"37.5782"がよくわからないので隠蔽するために、処理をメソッド化しました。(※37.5782は100m世界記録の時速)

int hour = this.getNecessaryHourForRunning(100);

function int getEstimateHour(int km){
return km / 37.5782;
}

行数は増えてしまいましたが、処理を共通化することだけがリファクタリングの目的ではありません。
このメソッドを見れば、走るために必要な時間(h)が取得できることが一目でわかります。
もし仮に、ヒトが走ると疲れることを考慮に入れる仕様が追加された場合も、このメソッドを修正すれば非常に小さなスコープで影響が収まります。

まず、この様な小さなことから始めてみると良いのかもしれません。

http://www.playframework.org/

JavaによるWebアプリケーション開発を容易にすることを目的とした、
Ruby on RailsライクのOSSフレームワークです。

概要や特徴などは公式サイトで分かりやすく説明されているので、そちらを参照してください。今回紹介する環境構築手順や開発フローが見られる10分程度のムービーもあります。
公式ではありませんが、翻訳サイトもあります。

http://playdocja.appspot.com/

早速、ローカル環境(WindowsXP)に開発環境を構築してみます。
なお、Java5以降がインストールされている前提です。

1.最新バージョン(v1.2.4)をダウンロードします。

http://www.playframework.org/download

ファイル：play-1.2.4.zip

2.ダウンロードしたファイルを任意のフォルダに展開します。

今回は以下のディレクトリに展開
D:\work\play-1.2.4

3.コマンドプロンプトを起動して、新規アプリケーション作成用のコマンドを実行します。

# cd D:\work\play-1.2.4
# play new myapp

途中でアプリケーション名を聞かれるので適当に入力します。

4.アプリケーションの起動コマンドを実行します。

# play run myapp

5.ブラウザを開いて、URLを入力します。

http://localhost:9000/

基本的な環境構築は以上です。

Tomcatなどのアプリケーションサーバ上で動作させることもできますが、スタンドアロンで動作するので、すぐにアプリケーションの開発に取り掛かれます。
テキストエディタをはじめ、Eclipseなどお好みのIDEで開発できるのもGoodです。

環境構築だけでなく、アプリケーションの開発においても、効率的に開発できる機能がたくさん含まれているので、順次試していきたいと思います。

• DocTest 1.0 For Ruby リリース

なので使ってみた結果をここに記録しておきます。

呼び出しに関すること

微妙なパス指定

ファイル名の指定に"*(任意の文字列)","?(任意の文字)"が使えるようですが、"**(任意の階層)"は使えないようです。
なので、

• ./aaa/astk.rb
• ./aaa/bbb/msptmy.rb
• ./xxx/inds.rb

上のような構成で"rubydoctest **/*.rb"とタイプしてもmsptmy.rbはテストされません。

rubydoctest **/*.rb
=== Testing 'xxx/hoge.rb'...
OK  | Default Test
1 comparisons, 1 doctests, 0 failures, 0 errors
=== Testing 'aaa/astk.rb'...
OK  | Default Test
1 comparisons, 1 doctests, 0 failures, 0 errors

ここはトップレベルの指定だけで全部テストしてほしいところです。

シンプルなirbセッションを貼り付ける

irbの結果を張り付けるだけでテストコードが作成できるのは便利なのですが、シンプルなirbセッションを張り付けないと怒られてしまいます。
「シンプルなirbセッション」とは、「--simple-prompt」オプションを指定して起動したirbセッションのプロンプトのことを意味しています。

シンプルでない（デフォルト）の場合

$ irb
irb(main):001:0> 1+1
=> 2
irb(main):002:0>

シンプルなirbセッションの場合

$ /usr/bin/irb --simple-prompt
>> 1*1
=> 1
>>

なので「.bashrc」にエイリアスをつけておくのがいいと思います。

alias irb='irb --simple-prompt'

テストに関すること

まず、挙動確認に使ったソースと動作結果を示します。

ソース「doctest.rb」

テスト結果

$ rubydoctest doctest.rb
=== Testing 'doctest.rb'...
OK  | テスト中の変数は最後まで生き残る
なのでクラスのインスタンスを最初に作れば
以降のメソッドで使いまわせる
OK  | 足し算
OK  | ここでdoメソッドを試す
!!!ディレクティブで止める
>> d.do "1+2+3"
=> 6
>> exit
>> exit
OK  | !!!ディレクティブはexitで抜ける
抜けた後はrubydoctestのセッションに戻る
2回"exit"とタイプしないといけないのはなぜ？
4 comparisons, 6 doctests, 0 failures, 0 errors
$

事前に宣言したオブジェクトを使える

ソースの先頭でDoctesttestクラスのインスタンスを作成しています。
テスト中はこのインスタンスが生きているので使い回すことができます。
クラスのメソッドを確認するのに毎回オブジェクトを作る必要はありません。

doctestディレクティブ

doctestディレクティブが記述されていないテストは「OK | メッセージ」という形式で結果が出力されませんが、テストとしてはカウントされているようです。
（最後の「4 comparisons, 6 doctests」に注目）

クラスのテストの場合には、1メソッドに1doctestディレクティブで記述するのが読みやすそうです。

!!!ディレクティブ

テストの途中でirbセッションを触ることができます。
大量の自動テストの途中で止まってしまうことを考えると不便ですが、デバッグ中に毎回入力する内容までを自動化すると便利です。
ただし、エラーが発生した場合、通常のirbセッションと違って変なスタックトレースが出力されてしまって問題のある箇所が特定できません。。。

テストにセッションを返す際は「exit」と入力すればよいとドキュメントにあるのですが、なぜか2回入力しないと戻りませんでした。

結論

便利そうで意外と不便なのですが、それでも使いたくなる魅力を感じるのは私だけでしょうか？
何を重視するかによっても評価は変わってくると思いますが、

• ソースファイルの中に一緒に記述できるので、忘れたころにソースを触る必要が合った場合にテストコード紛失の恐れがない
• コメントとして記述するのでrdoc等のドキュメントにもテストコードが出力され、一粒で二度おいしい（これもソースファイルだけの管理で紛失の心配がない）

この二点にたまらない魅力を感じるのは、私の「作っては放置し、久しぶりに触っては苦労する」という習慣のせいなのでしょうが。。。

以上です。

で、、、この手のコードを書いたときに、ちょっとしたテストも書いときたいなあ、と思うんですよね。Python だと、doctest っていうコメントにテストを埋め込める便利なのがあるんですが、ruby にもないものかと思って探したらありました。rubydoctestってやつが。

Ruby DocTest

気になりすぎて調査したかったので前回はあえて触れず、今回紹介されているrubydoctestの使用例のページ（Example Usage）を訳してみました。
ほとんどコードでかつコード中の文は訳していないのですが、雰囲気はつかめると思います。

Example Usage
使用例

Create a .doctest document, for example, “simple.doctest”, and begin documenting your application, like this:

例えば"simple.doctest"のような、拡張子"doctest"のドキュメントを生成します。
そして以下のようにあなたのアプリケーションについて記述します。

Or, put your pastes in as comments within your ruby code, say, factorial.rb, like this:

もしくは以下のようにあなたのアプリケーション"factorial.rb"のコードにコメントとして記述することもできます。

When the above code is run, i.e. with the command “rubydoctest factorial.rb”, it shows the following results:

上記のコードを"rubydoctest factorial.rb"というコマンドで実行させると、以下のような結果が得られます。

You can do multiline statements like this, as long as the indentation level is greater than the >> start line (note that ‘end’ is at an unnatural indentation level):

インデントの階層をテスト開始行の">>"よりも深くしておけば、複数行にまたがってテストコードを記述することもできます。
(メモ:インデントの階層が条件に合わないとき、複数行コードの終了とみなします)

Here’s a more advanced usage example, in a Rails model, book.rb:

以下にRailsのモデルクラス"book.rb"を使ってさらに進んだ使用例を示します。

See the Rails Usage page for more information about the rubydoctest_helper script mentioned above.

上記のコード中で参照しているスクリプト"rubydoctest_helper"についての詳しい説明はページ"Rails Usage"を参照してください。

In each case, you run your tests using the rubydoctest command-line tool, e.g.:

どちらの場合においても、コマンドラインツール"rubydoctest"を使ってテストを実行します。

Note also that you can use =begin and =end to suround the tests, ex: factorial.rb

埋め込みドキュメント(rubyコード中、=beginと=endに囲まれている部分)内に記述できる事を、先ほどのアプリケーション"factorial.rb"を例に付記しておきます。
訳注:埋め込みドキュメントについては下記を参照してください。
埋め込みドキュメント < 字句構造 < Ruby 1.9.2 リファレンスマニュアル

And that tests can be interspersed with comments, a la

そしてこのテストコードには、以下のようにコメントをちりばめることができます。

And since your test code and comments will appear in the rdocs, you’ve made instant documentation for parameters to your functions.

そして、あなたのテストコードはRDoc上にも出力されるため、メソッド(など)についての使用例のドキュメントを作成したことにもなるのです。

And all it cost was a copy and past from an irb session.

そのドキュメントはirbセッションからコピーペーストする労力しかかかっていないのです。

Last edited by canadaduane, September 15, 2010

最終更新： 2010/09/15 canadaduane