iOSにはガベージコレクションがありませんね。僕はJava/PHP/Ruby出身でGCに甘やかされてきたので、オブジェクトの開放を意識しながらプログラミングしたのは今回が初めてでした。

iOS Reference Libraryのメモリ管理ドキュメントをさらっと読むと、「とにかく自分でretainしたオブジェクトは自分でreleaseしてね」という感じのことが書かれていますが、ちょっとそれだけではうまくいかないシーンが出てきます。

まず、releaseすべきなのはどういうオブジェクトかですが、これは単純です。

• alloc、new、またはcopyが名前に含まれるメソッドを呼んで手に入れたオブジェクト
• retainしたオブジェクト

それ以外の場合はreleaseする必要はありません。たとえば

// init系メソッドから入手したのでreleaseすべき
NSArray *pets = [[NSArray alloc] initWithObjects:@"iguana", @"prairie dog", nil];
// initでもnewでもcopyでもないし、retainもしていないので、releaseしなくてよい
NSArray *morePets = [NSArray arrayWithObjects:@"christmas beetle", @"chimp", nil];

releaseしなくてもよいってのは、正確には「releaseしてはいけない」ですね。自分が所持してないオブジェクトをreleaseすると参照カウントが想定より早く0に達してしまい、EXC_BAD_ACCESSの原因になります。

では逆にどういう時はreleaseしても大丈夫なのかという疑問が出てきます。特に、別のクラスのメソッドにオブジェクトを渡した直後にreleaseしてしまって大丈夫なのか？答えは「リファレンスを見ろ」です。メソッドによって扱いが違います。

例えばNSArrayのaddObject:メソッドは、渡されたオブジェクトをretainします。したがって渡したあとでreleaseしてしまって構いません。他にもUIViewのaddSubviewなども渡されたオブジェクトをretainしはります。反対に、同じくNSArrayのindexOfObject:メソッドは渡されたオブジェクトをretainしません。どのメソッドがretainしてどのメソッドがしないのかは、なんとなく雰囲気で分かりますね。

ps

オブジェクトが配列なら、ソートした上でカラム上に並べて見やすくしてくれます。

Railsのメソッド一覧をpsしてみた

irb

その場でirbに突入します。後述のautoevalをONにしてればあまり意味はないかも。

Debugger.settingsでオプション設定

require 'ruby-debug'したあとでDebugger.settings[:key]=valueすると各種オプションを設定できます。網羅的なリストはこちら。特に便利なのは以下。

:autoeval

trueにすると、デバッガコマンドが見つからないときは自動的にevalを試してくれます。*** Unknown command: "User.first.name". Try "help".がしばしば出てしまう僕にとっては必須。

ちなみにRailsでは、テストヘルパ（railties/lib/test_help.rb）でautoevalが設定されてます。

:autolist

trueにすると、デバッガに入ったときやステップ実行時などに自動的にlistを実行して周辺コードを表示してくれます。

これもRailsのテストヘルパで設定されてます。

:forcestep

trueにすると、ステップ実行時に必ず別の行へ飛びます。
Rubyは一行で色々書けるので、普通にステップすると同じ行内でステップすることもありますが、このオプションを使えば一行=１ステップになります。

参考：
Debugging with ruby-debug

page.html

<script>
require(["libA"], function(){
  libA.foo();
});
</script>

libA.js

// libB, libC, libD,...など不特定多数多数のライブラリに依存する
require(["libB", "libC", "libD"], function(){
  libA = {
    foo: function(){
      libB.something();
    }
  };
});

libB.js, libC.js, libD.js, libE.js…

libB = {
  // blah blah blah...
};

だがこのコードはほとんどうまく動くことがない（たまに上手くいく）。なぜなら、libAのrequireコールバックが呼ばれたときにまだlibB以降は使えない可能性が高いからだ。

普通ならHTML内のrequireで全部のライブラリを列挙すれば安全にロードできるのだが、ここではlibB以降のライブラリは場合によって必要なものと数が変わるからHTML内では列挙できない。

そこで、libB以降のライブラリの読み込みを保証してからHTML側の処理に入りたい。
どういうやり方が賢いだろうか。

こんな風に書けたらいいな

page.html

<script>
require(["libA"], function(){
  function(){
    libA.foo();
  }
});

libA.js

libA = {};
require(["libB", "libC", "libD"], function(){
  libA = {
    // blah blah blah...
  };
  loaded("libA");
});

要はファイルが読み込まれただけじゃなく、初期化が完了して使える状態にあることをローダーに対して伝えたいわけだな。ちょっと実装してみる。

参考：Ruby-GetText-Package API Reference – YotaLab Storage

ウガンダで子どもの生贄の現状が明らかに
BBC News – Newsnight – Witch-doctors reveal extent of child sacrifice in Uganda

A BBC investigation into human sacrifice in Uganda has heard first-hand accounts which suggest ritual killings of children may be more common than authorities have acknowledged.

[... A] former witch-doctor who now campaigns to end child sacrifice confessed for the first time to having murdered about 70 people, including his own son.

ウガンダではこれまで知られていた以上に多くの子ども達が生贄として殺されているらしいことが、BBCの調査により分かった。

現在は子供の人身供犠反対運動を行っている元ウィッチ・ドクターは、自分自身の子どもを含めこれまでにおよそ70人を殺害していることを明かした。

話はさらに現実味を増す。

“They capture other people’s children. They bring the heart and the blood directly here to take to the spirits… They bring them in small tins [...],” he said.

Asked how often clients brought blood and body parts, the witch-doctor said they came “on average three times a week – with all that the spirits demand from them.”

「患者たちは子どもをさらって、心臓などを小さな缶に入れて持ってきます。」
[...]
どれくらいの頻度で血液や臓物などが持ち込まれるのかとの質問には、「平均して週三回ほどです。持ち込まれるのは精霊が求めたもの全てです。」と答えた。

なんという…。生贄なんてインディ・ジョーンズの世界でしか知らなかっただけに、これはショッキングだ。そりゃあ世界のどこかでそんなことが起こってるらしい、ぐらいは想像できるが、こんな風に言われると「そんなに！？」と思ってしまう。

さらに記事内では、この証言者が反対運動で回っただけでも2400人の呪術師がいる事、全国レベルの呪術師連合があって末端の呪術師の儲けは連合の偉いさんに上納するシステムになっている事などが明かされている。

平均して週三回とはにわかには信じがたい数だ。2400人の呪術師に週イチで臓物が持ち込まれるとしても年間約12万人の子どもたちが体の一部を切り取られていて、おそらくその大部分が死んでいることになる。ほんまか。しかも2009年に警察で生贄殺人として調査したのがたったの26件だというから、警察などほとんど役に立っていないようだ。

呪術治療なりカウンセリングなどの料金は一回あたり260USDほどだというのも驚きだ。ウガンダの推定一人当たりGDP（2008）が1300USDだから、その比で日本円にすると60万円以上と滅茶苦茶に高い。それを吸い取る連合の後ろには大きなヤクザ組織のようなものがあるような気がする。

想像だが、患者は強制されて子どもを殺すわけではないんだろうな。効果があると信じてしまうんだろう。寝が深そうな問題だ。素人考えではやはり教育によって改善すべきことのような気がするが、どうなんだろうか。

申し訳ないけど、このブログエントリの著者が学生さんだと知りつつ、きつく批判します。

「なんたらノート」さんは、僕の狭い視点と一方的にCodeIgniterを酷評するスタンスをよくないと批判してくださっています。

僕の表現が至らないところがあって、大いに誤解を招くような記事を書いた事については反省しています。今更ながら元記事について補足しておきますが、僕はCodeIgniterに対してネガキャンを張りたかったわけではありません。あくまで自分の利用目的に合わない部分を書いただけです。

トラックバック元で指摘された各項目について反論を書こうかと思いましたが、おおむね好みや状況によるものなのでやめておきます。僕が指摘した点、向こうで指摘されている点は立場によっては両方正しかったり、どちらかが正しかったりするものだと思います。PHPを使うのもCodeIgniterを使うのも様々な目的とバックグラウンドがあってのことですから、僕が「使いにくい」と感じた点について「それは間違ってる」と指摘されても仕方がありません。

ですので、「きつく批判」される筋合いはないと今も感じてます。

最後に一言だけ。

CIに限らず、他人の方法に自分が違和感を覚えるとき、単に「おかしい」とだけ考えて切り捨てていると真実を見逃す。おかしな仕様だと思えば思うほど、「なぜそうなったか」を考えることは重要。

確かにその通りですね。批判したいと思ったらもう一歩、なぜそうなっているかを考えてみることは重要ですね。ただ、それだけだと例えばWindowsの使いにくさを批判することなど至難の業となってしまいますから、「自分ならこう作るのに！」という視点とは別に「自分にとっては使いにくい」という視点もありなんだろうとは思っています。

もう一年くらいブログを書いていなかったのですが、今はプライベートな日記をつけているので、時間があればそこからピックアップして記事にしていくつもりです。

それと、CodeIgniterが急激に嫌になってきたという記事についてかなり真剣なコメントをもらっているのですが、今まで対処できずにいました。これからトラックバック元をしっかり読んで対応したいと思います。

タイトル：「カブロボグリッド実現方法の検討」

カブロボグリッドとは

カブロボは、自動株取引きプログラム。選択した売買アルゴリズムによって儲かったり儲からなかったりするため、良いアルゴリズムを発見することが大きな課題になる。

カブロボのアルゴリズムは売買ルールとパラメータで表現されるが、ルール同士を組み合わせることも可能なため、その数は膨大。グリッドの力でこれを片っ端から探索しようというのがカブロボグリッドだ。

だが、本当に片っ端からやるだけでは効率が良くない。そこで、より良いアルゴリズムをより短時間で見つけるために、行う仕事の選択と、クライアントへの仕事の割り振り方に関していくつかの方策を提案する。

仕事の選択

片っ端から試すより、良いアルゴリズムの周辺を重点的に試行するほうがおそらく効率が良い。さらに、たとえばユーザが希望した部分を優先的に試行するような仕組みが欲しい。

そこで、仕事の生成をオーディションラインとトレーニングラインの二つに分ける。

オーディションラインは、基本的にはユーザが指定した部分の仕事を生成する。

トレーニングラインは、オーディション出身で比較的性能が良かったアルゴリズムの周辺へ手を伸ばしていく。

加えて、トレーニングラインから確率的にジャンプを起こし、少しだけ離れた部分のアルゴリズムをオーディションさせる。これは焼きなまし法に似ている。

仕事の割り振り方

ま ず前提として、カブロボグリッドではエラー耐性のために同じ仕事を複数のクライアントに割り当てる。同じ仕事を4つのクライアントに振る、というのは「冗 長性」として自由に設定可能だ。また、このうち最低3つの結果が一致していればそれを正しい結果とみなす、というような設定が可能で、この値を「クオラ ム」と呼ぶ。

さて、いまのカブロボグリッドでは冗長性を一律で設定できるが、仕事ごとに設定できない。だが冗長性をその時々のクライアントたちの能力によって動的に変更することで無駄が減らせるはずだ。

そ こで、何通りか考えられる冗長性rに対して、期待値Erを定義する。これはEr = 1/(jr * lr) で表される。jrは冗長性rのときに一回でコンセンサスが得られない確率。lrはそのときに失われる時間。これらは仕事を受け取るクライアントの能力に よって決まる。常にこのErが最大になるようなrをその仕事の冗長性として設定することで、常にもっとも効率が良いと見込める冗長性設定が可能になる。

次 に、最低限必要でない仕事をどのクライアントに割り振るべきかを考える。これは、たとえば冗長性4、クオラム3の場合の4つ目の仕事だ。前の3つが同じ結 果で返って来たときにこの4つ目の仕事は無駄になるわけで、それを例えばものすごく能力の高いクライアントに渡してしまうのはもったいない。そのクライア ントは無駄にならない別の仕事をすべきだ。

そこで、ある仕事wuを受け取れるそれぞれのクライアントiについて、もったいなさMiを定義す る。これはMi = w/(j * ei) で表される。wは仕事wuの計算量、jは自分と同じ仕事をしているほかのクライアントたちがエラーを起こす確率、eiは自分自身がエラーを起こす確率。こ れらの値は同じ仕事をしているクライアントたちと、手の空いているクライアントたちの能力によって決まる。常にこのMiが最小になるようなクライアントi に仕事を振ることで、もっとも無駄のない割り振りが可能になる。

これから考えるべきこと

• 「期待値」という言葉は厳密にはふさわしくないので、他の分かりやすい言葉を考える。
• もったいなさの式にjが含まれていていいのか怪しい気がしてきたので、もう一度よく考える。
• 先着順でないということはクライアントを待たせるということ。これの意味と影響を考える。