2014-03-28

Mac版SciTE使う時の注意点まとめ

基本Windowsユーザな私だが、値段対スペックがいいという理由で去年MacBook Airを使い始めた。
幸いと、Macにも愛用のテキストエディタSciTEは健在(有料だが)だったので、まあ気まぐれでソース書く時も安心だろうとタカをくくっていたのだが、いざ使ってみるとアレやコレや戸惑うところがあった。なので、忘れる前にいくつか書き記しておこう。

2014-03-07

The Game Crafterを使ってみて

つい先日、The Game Crafter( https://www.thegamecrafter.com/ )というサイトにて、ボードゲームの印刷を依頼してみた。それについてレポートでも書こうかと思ったのだが、しかしまあ、そもそもThe Game Crafterとは何ぞや、という話から始めなければいけないだろう。
The Game Crafterはアメリカのインディーボードゲームの印刷屋兼オンラインショップといったところ。1部からの印刷依頼ができたり、印刷屋かつオンラインショップなので印刷依頼したボードゲームをそのままオンライン販売できたりするのが特徴。もちろんライセンスを売る訳ではないので印刷依頼だけ出すんでもいい。
気になる料金の方は、国内の某印刷所と比べると安い、しかしクオリティが格段に下がる、といったところ。製品のクオリティについてはまた別のポストで気が向いたら書く事にするが、正直家庭用インクジェットプリンタより汚いと感じる程。正直しょっぱい出来。オンラインショップとしては利益の3割を向こうの取り分とする、まあ良くある設定。
納品時期に関しては意外と早く、今回2部だけの印刷依頼で3営業日後には印刷完了。届いたのはおおよそ依頼から2週間後となる。ちなみに送料はプラン次第だが45ドルぐらいした。

以下はどんな感じかスクリーンショットを交えての説明。

2013-10-22

Festival internacional de juegos cordobaに出店してきた件(2)

さて出店までの流れを思い出してみよう。
事の発端はエッセンで毎年行われているボードゲームの祭典、Spiel'13に参加しようと考えたこと。どうせヨーロッパいくんだったら別の場所にも参加すべきだろうと、適当にネットを検索してたところ、いくつかの候補地の中で無難そうなところがここだった。ちょうどスペイン語勉強してたし、友達もいるしいいんじゃねえ、と。
参加してみようとは思ったものの、この公式ホームページ(http://www.festivaldejuegoscordoba.es/)、2013年5月の段階でまったく更新された形跡がない。エントリーフォームもない。ちなみにいうと、エッセンの方はこの5月のあたりでエントリーの期限となっている。
とりあえず公式ページのメアドに適当につたないスペイン語でメールを書いてみたが、しばらく反応はない。8月ぐらいになって出店するにはこんぐらい金かかるよとか、スポンサーとしてはこんなプランがあるよ、といったメールが届く。当然スペイン語。
じゃあ一番小さいブースで、とメールを返すと銀行への振込先なんかの情報がもらえるので、振込を行う。ちなみに、海外への送金って思った以上に面倒で時間もかかるので注意。
その後出店するゲームの情報とか会社の情報、画像なんかちょうだいというメールが9月ぐらいにある。
あとは当日(準備があれば前日も入れるらしいが)に会場へ行けばOKだ、簡単だね。
ボードゲームの輸送に関して、事前に段ボール箱に詰めて友人宅へ送っておいたところ、スペインの郵便局に税金払え、と止められた。手続きとかなんだかんだやってたらほぼ到着まで1ヶ月かかったので、なんというか、面倒ですな。

2013-10-18

Festival internacional de juegos cordobaに出店してきた件(1)

スペインのコルドバにて毎年(多分)行われているボードゲームの祭典、Festival internacional de juegos cordoba 2013というイベントにフラッと出店してきた。日本のゲームマーケットすっ飛ばして出店である。
名前にinternacionalとはあるものの、海外からの出店はかなりレアっぽく、外国人客もそんなには多くない。ボードゲームショップやメーカーからの出店が目立ち、私のように超プライベートな出店は、あー、果たしてあったのだろうか...という感じ。
日本人として気になる「言語に関して」は基本的にスペイン語必須な要素が強い。まずエントリーからしてスペイン語だし(これは機械翻訳でもいける)、接客はほぼスペイン語、もしくは少数(感覚として30%ほど)は英語でもいける。なのでスペイン語がはなせるか、スペイン人の友達がいないと難しい部分は確かにある。
祭典は駅からそう遠くもないPalacio de la Mercedで金曜日の夜から土、日と行われ、出店料は200ユーロぐらい。テーブルとイスは無料でついてくる親切設定。
中庭をブースで囲み、中央の吹き抜けをフリースペースとして解放、ボードゲームの貸し出しがあり、一般の入場料も無料だ。まったく、すばらしい。ついでに金、土は午前2時まで営業している。
私がスペインへ持ち込んだボードゲームAssaultousは20ユーロで販売し、30セット中、最終的には25セットぐらいを売った。(正直に言うとちゃんとカウントしてない。)
噂通り、というか、スペインの現状は厳しく、テストプレイでとても気に入ってくれたにも関わらず、金がない、というケースも何度か。
ちなみに20ユーロでの販売はもとより定価30ユーロからのディスカウントであり、こっちにも全く儲けが出ない価格設定である。2つ買ったらディスカウントしてくれる?って人もいたけど輸送費考えると既に赤字なので無理、と。
それでもテストプレイをやってくれた人が、面白いからって別の友達つれてきてくれたり、気に入って2つも買ってくれる人もいたりするのはデザイナーとしてはとてもうれしかった。
忙しくてメシが食えなかった事をのぞけば、特に何のトラブルもなく、楽しい時が過ごせたので、全体としては良かったんじゃあ無いかと思う。出店料は安いし、期間も短いからまた参加できるかもしれないなあ。
いろいろ手伝ってくれたルイスさん、その友達、本当にありがとうございました。
PS.祭典の最後に主催者からPalacio de Vianaというスペインのボードゲームを頂きました。こちらも本当にありがとうございます。

2013-09-16

JSでパブリックメソッドを作るときの作法

以下はJavaScriptでよく使われるプライベート変数とパブリックメソッドの作り方である。

var glbVar = (function () {
	var privVar;

	return {
		publMethod: function () {}
	};
}());

これは以下のようにも書き直せる。

var glbVar = (function () {
	var privVar,
		//一旦変数に格納
		obj = {
			publMethod: function () {}
		};

	return obj;
}());

どちらも結果は同じで、最初の例の方が無駄な変数宣言もなく、スマートに思える。なので私自身ずっと前者でコードを書いてきたのだが、つい最近、この前者と後者、大きく違う部分があることに気がついた。
publMethodを以下のようにして考えよう。

{
	publMethod: function () {
		this.publAnotherMethod();
	},
	//別のパブリックメソッド
	publAnotherMethod: function () {}
}

publMethodはコンテキストthisを介し、別のパブリックメソッドを呼んでいる。もちろんどちらもパブリックメソッドであるため、glbVar経由で別のメソッドを呼ぶこともできるが、グローバル参照は低速であるため、可能であればさけるべきというのが習わしだ。
これは何の問題もなく動作する。しかし、仮に以下のような方法でpublMethodが呼び出された場合、問題が起きる。

glbVar.publMethod.call(this, someCallBackFunc);

コンテキストの書き換え。特にpublMethodがコールバック関数を用いる場合、上記のような呼び出しは多いにあり得る。この場合、this.publAnotherMethod は undefinedとなり、JSの実行は停止するだろう。
つまり、コンテキストに依存したソースはさけるべきであり、最初の二つの例の後者、一旦変数にパブリックメソッドを格納する方法をとるべきだということである。

var glbVar = (function () {
	var privVar,
		//一旦変数に格納
		obj = {
			publMethod: function () {
				//obj経由で他のパブリックメソッドにアクセスする
				obj.publAnotherMethod();
			},
			//別のパブリックメソッド
			publAnotherMethod: function () {}
		};

	return obj;
}());

JSでは気軽にコンテキストを書き換えられるため(またイベントハンドラの仕様おかげでそうせざるを得ない状況が多々あることで)、ライブラリ開発や共通関数の作成で特に考慮すべきことである。

2013-07-28

JavaScriptの正規表現メソッドはコンテキスト依存？

JSにて、

var rx = /regexp/, t = rx.test;

として

t("unko");

で呼び出そうとするとエラーが起きる。

TypeError: test method called on incompatible undefined
t("unko");

どうもtestがコンテキストに依存しているらしく

t.call(rx, str);

ではエラーが起きない。
http://stackoverflow.com/questions/12536259/regexp-showing-unexpected-type-error-in-javascript
.testで使用される正規表現パターンなんて.test用途以外で使われなさそうだし、コンテキスト依存はしてほしくないのだが…。かといってコンテキストをバインドするのも正規表現の美意識に反する(気がする)。しかし今のところそれ以外方法が思いつかないのも確かで。

2013-06-18

CouchDBのアップデートハンドラのキーって_updatesじゃ..?

CouchDBでドキュメントを更新する際、いちいちバージョン番号を渡して排他処理をするのがウザいと感じることが多々ある。つーか常に後勝ちな、緩い感じでいいじゃん、と。そんなあなた(私)のためにあるのが、こちら。デザインドキュメントによるアップデートハンドラ。デザインドキュメントにあらかじめドキュメント更新用の関数を定義しておいて、その関数経由であえてバージョン番号を無視する更新を行うワケです。
で、最近PCを買い換えたのもあり、せっかくだからと最新のCouchDB(1.3.0)を入れて、早速この便利なアップデートハンドラちゃんを登録しようとしたわけです。

Error: doc_validation

Bad special document member: _updates

OK

お、オウケイ…？って、全然OKじゃあねえ。どういうワケか"_updates"という名前でフィールドが作成できなくなっている。おかしい、現にiriscouchで動作しているオレのアプリは_updatesフィールドにガンガン更新メソッドを詰め込んでいる。_updatesがサポートされなくなった？まさか。どうせオレと同じ問題を抱えている奴がいるだろうとGoogleで、stackoverflowで検索してみるが全然同じような疑問が見当たらない。そして公式のWiki ( http://wiki.apache.org/couchdb/Document_Update_Handlers ) に以下の一文を見つけた。

You can specify any number of update handler functions in a design document, under the "updates" attribute.

"updates"？ "_updates"ではないのか？実際にupdateでアップデートハンドラを登録し動作確認をしてみると、確かに動作する。(ただしアップデートハンドラへのリクエストは //_design//_update/ へ行う)
これは一体…。ま、まさか、過去改変、そしてオレはリーディングシュタイナーの能力に目覚めて…?!
とはいえ、iriscouchの方には"_updates"フィールドでアップデートハンドラを行っているアプリが今も動作しているし、まあ、何だかよくわからないがアップデートハンドラのフィールドは今は"updates"だっつーことで。