高次設計なのに、やけに具体的に書きすぎてしまったり、酷いといきなりchar*などが飛び出して実装を意識しすぎたり。とにかく目的を飛ばして手順だけ書く感じ。「何故その処理なのか」が無い。

そりゃあ実装寸前まで考えてからやれる規模ですし、私もそうしてますけれども、ソフトウェア工学的にはあくまで高次なわけで…。実装フリーな抽象化した記述というのが、難しい所なのだろう。

自分で手を出せる規模ではないので、レビューに徹するしかないのが良いのか悪いのか。こんな所で趣味や大学での余分な履修が役にたっています。余技程度とはいえ、好みのままにあれやこれやに手を出しておいて本当によかった。

RubySpecとのからみはどうなっているのだろう。

簡単に言えばHTMLをとことん省略記法で書こうというもの。ただし、難点として少なくともEmacs版(非公式)は行単位なので、inlineで書くのには役に立たない。

色々なエディタに組込めるようなので、マークアップ効率化 – zen-codingでコーディングを倍速にあたりを見るとわかりやすいかも。

上司がいじっているのを見て、気になっている技術の一つ。基本的な仕組みはMap/Reduceということで理解はできるのだが、いざ実際に使おうとするとどういうパターンで使えばいいのかわからず、準備するのが面倒そうというのもあって手を出していない。

作っているとSQLならばこんな風^[1]に、Key-Value系ならこんな風^[2]に、というのはある程度見えたので、これも実例を試してみればいいのだろう。今一適当な題材が決まらないのが難点だ。

要するに即時性なし、大規模、分散可能なデータであればいいんだよな。攻撃パケットを適当に投げて、傾向分析でもすればいいのかしらん。…やっぱり使ってみないと勘所がよくわからなさそうだ。バッチで使ってもいいので、適当にブラウザゲームあたりをでっちあげて解析するのもありか。マッチメーカー系とか自分でもしてみたいし。

何にせよ、ある程度処理オーダーの壁を超えられるので、少しでも手を出しておきたい技術ではある。

…とりあえず、どれだけ資源を費せば最低限できそうなのかから調べてみるか。

1. SQLを通じてDB直や、ORマッピングを介したデータ操作。
2. Core DataなどのCocoa風味。あるいは試していないがmemcached系?

簡単に言えばパッチを組みあわせて作るビジュアルプログラミング。

2Dでも3Dでも適当に貼りつけて動かせるし、なかなかに楽しい。並列操作が得意な分、シーケンス操作が難しそうだが、これはマクロでもつくれというものなのだろう。

わけのわからないパッチが山ほどあるので、もうちょっと触ってみるつもり。

Twitterの発言から、Mecabを試してみようとfinkでインストール。

試してみると、見事に文字化け。どうやら、標準だとEUC-JPで全部処理しているらしい。仕方がないので、本体と辞書をUTF8で作りなおしてインストール。すると、今度はrubyバインディングが動かなくなってしまった。どこか妙なライブラリをひろってしまったんだろうか。

面倒そうなので、一端ここまでで中断。なんというか、暑さで気力が続かない。

とにかく、この過去との互換性を背負った複雑な書式にあいまいな記載のデータをつっこんで、きちんとした結果を出す、そのプロセスの複雑さは想像することすらできない。パーザの仕様を見てみたい。

その一方で不思議なのが、何故書式がｉ言語ではないのか。同言語がゲームを記述する言語であり、ゲーム規則を規定する言語ならば、何故その言語ではないのか。初期に基礎となる規定を精査したけれど、それ意外の部分でも言語として成立しない理由があるように見える。

プログラムの組める人間からの視点だと「公式データが書式違反ばかりだった」につきる。イレギュラーをお手本にして厳密な規定はできない。また編集支援の無い記号山盛りの言語は辛い、ということ。リファレンスパーザが初期にあれば良かったのだろうが、公式データが入らないのにねえ…。

後から色々成立した時には、独自の書式があり、それにあわせるのがプレイヤーも楽だというデ・ファクトの強みが発揮されている。結果、規定を定義するのではなく、データを定義する言語にダウングレードしているように見える。特殊行動はデータ持ちなのである意味ドミニオン的なデザイン。

もっとも、データの大規模修正や一斉転換(今回の大元もその一つ)が行われることはあるので、将来的にはコストが見合えば一つの言語に集結し、メタ規定でメタメタ規定で作り、ユーザがそれにメタメタメタ規定で答えるといった風になるのかもしれない。十分なIT支援が前提だけど。

その上で、今回の大元、私ならこうするというデザイン。現状のプレイヤーから導かれた解であるし、基本的なVCはこのままとする。

まず、内部的にｉ言語で冗長表現の無い厳密解ができているとして、入力をパースして、中間言語のｉ言語に変換する。そして、バイナリ表現に変換した上でオブジェクトごとにハッシュでidをふり、データベース(SQLでもNoSQLでも)に保存する。ここでKEY-VALUEにしておけば、後でmemcachedにでも何にでも乗せやすい。

中間言語に変換するのはフロントエンドを適時交換できるようにするためである。対外的に利用できるｉ言語を内部インタフェースとしておけば、人間ご利用であろうがAPI経由の利用であろうが対応のための変更は少なくすむ。

データを保存するのはキャッシュとして再利用するためである。利用形態からも、突発的に出るデータは少なく同じデータの試行錯誤が多いと想定でき、データの局所性が十分に期待できる。

組み合わせについては、まあ頑張る。流石に深く見ていないのでここに関しては断言できない。おそらくは言語におけるevalにようにややこしく、山のような特殊処理が入るのだろう。

出力についてはｉ言語で出す。その上で、APIなりウェブなりテキストなりに変換する。

…やっぱり肝心要の部分がややこしすぎる。本当によく大元ではまとめたものだ。そして普通に開発すると、まず顧客からの要求仕様が足りなくて、ほぼ確実に設計者以降が泣く。

画像に音楽AIに職業状況等多彩な情報が盛り込まれたいたが、一番の興味を引いたところは矢張りAI。近年のAIは知覚系-体-思考を完全に分離した上で、対応する状況の粒度を変えた階層構造を持ち、メタAIやメタメタAIが連携してタスクをこなす構造がスタンダードらしい。

それで思い出したのがGPMや絢爛舞踏祭なのだが、言及が無かったのは資料の開示があるかどうかが大きいのかな。絢爛は一応攻略本にAIの概説程度は書いてあったけれども、確か欲求ベースのモデルで、The Simsで示された例に近い構造を持っていたはず。あれは観察していてなかなか愉快なAIっぷりだった。

きまぐれ日記: MeCabがiPhone,OSXに載っていると言うのは止めようと思う

違和感が何か見えてきた気がする。iPhoneは家電であって家電でないということかな。これがプログラムの外挿自体が特別な機器であるテレビや冷蔵庫やビデオレコーダ等…例えばApple TV上のガジェットならそう言われなかったのだろう。

携帯電話だとしても言語縛りは別に今まで問題とはなってこなかった。BREWでしか作れないと言われてもそんなものか、ですんでしまう。いわゆる従来からのスマートフォンの系譜にあるバイナリさえあれば言語は何でもいいというのと、今まで解放していたのが制限された、というのが反発しやすい条件になっているのだろう。自由の制限、というのはわかりやすいし。

私自身としては、libc相当から自前で書きおこしているdjb ware的なものを皆が使うと何か不安だよね、という程度の違和感なので、ミドルウェアは何だっていいじゃない、とは思う。一方で、市場が縮小する判断をしてまで安定性を重視したアップルの姿勢もわからなくはない。多分短期的には悪い方向に行くんだろうなあと思いつつ様子見といったところ。

通勤中にヒレガス本を読んで、帰ってから課題の一つである文字列の入力とその文字数を数えるメッセージを出すというのをやってみた。場所でいうと「5.6 チャレンジ」(日本語版の場合p96、英語はp90)。

まずは素直に IBOutlet/IBAction を使うバージョン。NSTextField の outlet を二つ用意して、ボタンの押下を IBAction のメソッドで受ける。ついでに awakeFromNIB メソッドを定義してラベルの初期値を設定してみた。これは課題のページのすぐ前あたりでやっていることなので簡単。

さらに作りなおしてみる。Key-Value コーディングが面白そうだったので、がらっと違う方法で挑戦。

NSString を二つ(テキスト入力用、テキスト出力用)用意して、@property と @synthesize で setter/getter を自動定義。文字列の入力即文字数カウントとしたかったので、IBで入力テキストフィールドのContinuesを有効にして、setter だけ自前で書く。このへんでどハマり。

まず、NSString の更新ってどうなるんだっけ、と延々マニュアルをあさってみたりする。結局 textField = t; と単純なポインタ代入でよかったようだ。本当はその前にt を retainしたりtextField を release したり必要なはずだが、しばらくはメモリ管理は忘れたままでおきたいので、ガーベージコレクションをビルドオプションでつけて逃げる。

そして、あんのじょう値を直接更新したのに更新通知を飛ばしてしまい、willChangeValueKey と didChangeValueKeyに辿りつくまで長々と悩んでしまう。出力側のテキストの更新も少々悩んだが、こちらは self 経由で [self setLengthMessage:msg]; と @synthesize がつくってくれた setter を指定することで逃げた。

なんだかんだで2,3時間かけて課題完了。少しは勘所がわかってきた気がする。

NIBがないとわからないが、一応二番目の課題でつくったクラス AppController.h。

#import 

@interface AppController : NSObject {
	NSString *textField;
	NSString *lengthMessage;
}
- (id)setTextField:(NSString *)t;
- (int)countLength:(NSString *)t;
@property (readwrite, copy) NSString *lengthMessage;
@property (readonly) NSString *textField;
@end

ついでに AppController.m。

#import "AppController.h"

@implementation AppController
- (id)setTextField:(NSString *)t
{
	// set new textField
	[self willChangeValueForKey:@"textField"];
	textField = t;
	[self didChangeValueForKey:@"textField"];

	NSLog(@"%@ -> %@", textField, t);

	// update length message
	[self countLength: t];

	return self;
}

- (int)countLength:(NSString *)t
{
	NSString *msg;
	int length;

	// make message from textfield's length
	length = textField.length;
	msg = [[NSString alloc] initWithFormat:@"'%@' has %d characters.",
		   textField,
		   length];

	// set value using self-setter(automated)
	[self setLengthMessage:msg];
	NSLog(@"%@", msg);

	return length;
}

@synthesize textField;
@synthesize lengthMessage;
@end