昨日の日記のちょっとした補足説明。テンプレートエンジンでのエスケープ処理を「テンプレート内でフィルターを使って行う」以外に「タグ付けを使って行い、テンプレートを書く側が HTML エスケープについて意識せずに済ませる」というやり方の可能性について書いたが、これら二つを同時に提供するつもりはない。何故なら前者はデザイナーが最終的な責任を負うやり方なのだが、後者はスーパーバイザーが責任を負うやり方だからだ。全く同じ事を目的とするのに別々のロールで別々のやり方があるというのは、どう考えても Caty の原理原則にはそぐわない。
いっちゃあ何だが、「A というやり方と B というやり方があります」みたいにオプションを用意して、それら二つがまったく同じ結果をもたらすというのは、想像以上に学習コストを上げる結果になる。なので Caty スクリプトの do 記法についても最初はかなり抵抗したんだが、「まあ檜山さんしか使わないだろうし、正式なチュートリアルからは外させよう」ということでギリギリ採用となった経緯がある。
インラインスクリプトとアウトオブラインスクリプトもかなりギリギリの判断で、インラインスクリプトが書けないとデザイナーだけでテンプレートの表示確認がやり難いだろうという事と、はっきりとした用途とワークフローを提示すればこれら二つがこんがらがる事はないだろうという仮説の元に導入していたりする（少なくとも俺は悩んだ）。
ちなみにそのうちリリースされる Caty プロトタイプのバージョン2では、以下のようなディレクトリ構成に固定して動作させるようにしている。ここで $CATY_HOME は Caty のアーカイブを展開した先で、 sites は個々のサイトを配置する先である。
$CATY_HOME/
/python
/common
/sites
/<YOUR_SITE>当初は $CATY_HOME 下以外のディレクトリにサイトやサイトの一部を配置させてもいいという仕様だったが、そういう事をやると弊害しかないのでユーザにとっては欠片たりとも嬉しくない。というか、前の会社で元々そういうディレクトリ構造の（アーカイブを展開した先に全データがある）某 ERP パッケージについて R&D していたときに、上司の趣味でディレクトリ構造に手を入れさせられた結果として開発したパッケージを配布するのが著しく困難になったという苦い経験があるので、この手のサイトの構造を野放図なレベルで柔軟にさせることには断固として反対だったりする。
このオプションを可能な限り制限するアプローチの例外の一つが複数テンプレート構文のサポートであり、これはそれぞれのテンプレート構文に（といっても Smarty 的文法と Kid 的文法で十分な気がするが）実用上のはっきりしたメリット/デメリットがあるし、既に知っているテンプレートの構文が使えるのは非常に大きなメリットなので採用する価値のあるオプションだ。
Caty の開発の副産物である構文解析ライブラリだが、実戦投入で多少はこなれてきたのでこれもそのうち正式に配布ページ作ってリリースしようかな。ドキュメント書くのが恐ろしく面倒なんで、近いうちにやるのは無理だけど。でも年内にはバージョン1.0をリリースしたいところ。
インフルエンザに罹りました。
とりあえず熱は平熱に落ち着いて危機は脱したところ。
昼間寝すぎたせいか全然寝付けねーから数日ぶりに RSS リーダーのチェックしてたら、何か俺の知らない間にリリースされてた事を知った。ってちょっと待て、多分このバージョンは既知のバグが残りっぱなしだ。それもテンプレートエンジンのバグなんで、 Web 部分全般に関わる極めてヤバいバグだ（テスト漏れしてやがった）。ってか多分今の状態だと Wiki が動かないぞ。
あとどうでもいいけど、間違えて Caty のバージョンを prototype-1.0.0 じゃなくて 2.0.0 とかフッタに出してる。ダメじゃん、俺。
というわけで、今回は来週早々にバグフィックスリリースをすることになりそうだ。
一時期「服用すると見えない大名行列の後を付いて行って飛び降り自殺する」などと騒がれた気がしなくもないタミフルだが、当然そんなことはなくインフルエンザは順調に治ってる。どうも副作用としてやたら眠くなって体温が平熱よりも下がるようだが、そんぐらいは仕方がない。
まあそんな事はどうでもいい。それよりみんなは Befunge というプログラミング言語を知っているか?
簡単に言ってしまえばソースコードの読み取られる向きがコロコロ変わる言語なんだが、もうとにかく凶悪極まりない。こいつで書かれたライフゲームのコードがこれだ。
v>>31g> ::51gg:2v++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
9p BXY|-+<v3*89<%+ * * +
21 >98 *7^>+\-0|<+ * * +
*5 ^:+ 1pg15\,:< + * *** +
10^ <>$25*,51g1v+ +
-^ p<| -*46p15:+<+ +
> 31^> 151p>92*4v+ +
^_ ".", ^ vp1<+ +
>v >41p >0 v+ +
:5! vg-1g15-1g14<+ +
+1-+>+41g1-51gg+v+ +
1p-1vg+1g15-1g14<+ +
g61g>+41g51g1-g+v+ +
14*1v4+g+1g15g14<+ * * +
5>^4>1g1+51g1-g+v+ * * +
^ _^v4+gg15+1g14<+ *** +
>v! >1g1+51g1+g+v+ +
g8-v14/*25-*4*88<+ +
19+>g51gg" "- v + +
4*5 v< v-2:_3v+ +
>^ |!-3_$ v<-+ +
^ < < <|<+ ***+
>g51gp ^ >51gp^>v+ +
^14"+"< ^g14"!"<++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++一体何が何だかさっぱりわからない。本気で恐怖と狂気を感じる。というわけで（どういうわけだ） Befunge 93 のインタープリタを実装してみた。
上記のライフゲームの他に robots.bf とかボトルを数える奴、 quine.bf あたりが動いたので多分大丈夫だとは思う。問題点は死ぬほどすっとろいという事なんだが、これで実用コードを書く機会は永久に訪れないだろうからどうでもいい。
あとこの言語は Funge 98 というのが最新の仕様らしいが、そっちはさらに狂気の度合いが加速しており真剣に頭を抱えている。ソースコードが二次元の Befunge だけでなく、ソースコードが一次元になった Unifunge とソースコードが三次元空間内に存在し、当然読み取りの向きも三軸という Trefunge を仕様として定義しているのだからたまらない。ってかどうやって三次元のソースコードとか書くんだ。とてもじゃないが実装する気にならなかったので放置してる（恐らく未来永劫ならないであろう）。
……メモ化使え、以上（ってコメントでも突っ込まれてるか）。ま、とりあえずシンプルな実装例でも出しておくか。
class memoize(object):
def __init__(self, f):
self.__function = f
self.__cache = {}
def __call__(self, *args):
if args in self.__cache:
return self.__cache[args]
else:
self.__cache[args] = self.__function(*args)
return self.__cache[args]
def clear(self):
self.__cache.clear()
@memoize
def get():
data = open('config.yaml').read().decode('utf8')
config = yaml.load(data)
return config俺がこちらの方が望ましい理由と考える理由を以下に述べる。
しかしクロージャの使用の有無に関わらず global が出てくる時点で何か変とは思わんかったのか。
最終局面で放置してた幻ノ塔ト剣ノ掟をようやくクリア。最後の方は完全に惰性になっていたので攻略 Wiki 大活躍だったが。序盤にちょっと感想書いたんだが、結局最後まで UI の悪さとバランスの無茶苦茶さ加減が付いて回るゲームだった。とりあえず UI は前に書いた通りなので、戦闘バランスの方を書いてみる。
このゲームは敵が最大で9体×4グループぐらいの編隊で出現することもあって、普通に殴ってるとキリがない。全8階構成（地上7階+地下1階）のうち、戦士が殴ってどうにかなる階はせいぜい3階までで、残りは魔術師必須。しかも魔術師一人じゃ到底捌ききれないので、大体4階に進む辺りからはメイン魔術師以外にも魔術師技能を覚えさせておく必要がある。装備品の関係上、称号技能を持っていない限りは魔術師の装備できる防具はローブとかその辺だが、どうせ前衛には戦士を一人だけ立たせておけばいいのでそこは問題ない。
大体5階にあがるあたりで敵の数と強さが暴力的に跳ね上がるので、そこで誰も破砕の核撃（ティルトウェイトみたいなもんだ）を使えないとまずい。特に6階以降は最初のターンに破砕の核撃を叩き込んで終了させるのがほぼ唯一の解となる。あまりにもこの辺のバランスが極端なんで、逆に緊張感が無くなってしまっている（プレイヤーがいろいろ諦めて開き直るので）。
エンカウント率も不可思議で、6歩ぐらい歩く間に4回エンカウントしてそのうち2回は敵の先制攻撃などのふざけた事態が実際に起こり得る。先制攻撃時には魔法が使えないので一気に全滅はないかと思いきや、ブレス系の攻撃は平気で使われるので「デスのブレスで即死」「ドラゴンのブレスで全滅」などが極普通に起こってしまう。そのため、6階以降は戦闘が終わる度にセーブ（どこでもセーブ可能）というチキン戦略を使うことになる。
序盤の感想で書いた通り、ヒントが極端に少ないもののダンジョンの謎解きはなかなかのもので、その部分の出来は割とよかったと思う。ただどうも迷宮内のショートカットの類が些か少なすぎで、目的地にたどり着くまでやたらと歩き回る必要があるのが大きなマイナス。一つのダンジョンにアタックをかける都合上仕方ない部分もあるかもしれないが、それでももうちょっとどうにかならなかったか。
他にもいろいろと不満点があるが（開錠がランダムで、失敗すると街に戻らないと再挑戦できないとか、武器防具の性能が表示されないとか）、主要な不満点は「戦闘バランスが悪い」「エンカウント率などがおかしい」「UI が悪い」「深刻なバグがある」あたりか。確かこれファミ通で4点付けたレビュアーがいたらしいけど、その気持ちはわからなくもない。
先に述べた通り、ダンジョンギミックはいろいろ用意されてるし、洋物ファンタジーっぽい画風や愉快なテキストなど雰囲気も良い。それだけに、 UI や戦闘バランスの調整が投げやり過ぎるのが惜しい。
辛うじて今週中に proto-1.1.0 まで漕ぎ着けたので、そのうち Caty を使ってのアプリケーション開発のサンプルを書きたいところ。
事業仕分けで科研費の見直しをする事それ自体は別にいいと思っていたが、あの削り方はどうなんだろ。どうも「基礎研究とか役に立たないから削ろうぜ」な雰囲気を感じてしまって、それはとてもヤバいと思う。仕分けで予算を縮小されたり凍結されたりした研究の中には、まあ確かに問題を抱えてるものもあったのかもしれないけど、でも単に研究内容についての広報が不十分だっただけってのもありうる話だろうしなあ。
基礎研究ってすぐに金になるかどうかまったく不明の純粋研究なわけで、そういった研究の費用を継続的に出す事を約束できるパトロンって国ぐらいしかない。応用研究やその上での技術・製品開発には基礎研究の成果が必須で、仮に日本が基礎研究を怠ってしまったらそれこそ諸外国の研究成果のおこぼれを頂戴するしかないんだけど、それは先進国としてどうなんだ。俺が他の先進国の住人だったら日本にキレるぞ。
そもそもパソコンに電源を入れてインターネットに接続するだけでも無数の基礎研究の成果を享受してるんだから、そういった研究に対して税金を払ってサポートするのはむしろ当たり前に思える。もちろん研究者側も一定の説明責任があるだろうし、予算は限られてるんだから研究成果や途中経過をみて予算の見直しをするのも当たり前といえばそうだ。
でも今回の削り方からは、そういったニュアンスが受け取れなかった。マジでこの先どうなるんだ。
さてそろそろ Caty でのアプリケーション開発のチュートリアルというかサンプルを書いた方がいいとは思うのだが、次期リリースで良くなる部分が多々あるのも事実で、それを踏まえて書きたいなーとか思ってしまうと全然進まない。ってかそういうドキュメントも含めてリリースしろよって話なんだが。