本書は、統計分析の活躍を語る本である。特に、様々な意思決定に用いられる統計分析を「絶対計算」と呼んで、それらがどれだけ多くの分野で、どれだけ大きな成功を収めてきたかを、実に誇らしげに語っている。何しろ著者自身が、第一級の”絶対計算家”の一人なのだ。その強い自負と責任感が、文の調子からも伝わってくる。

絶対計算の台頭によって、人間の経験や知識や直感、そしてそれらを売りにしていた専門家たちは、意思決定プロセスの現場から弾き出されてしまった（あるいは、弾き出されつつある）。本書は、専門家たちに対する、絶対計算の優位性を、これでもかというくらいに語る。その様は爽快ではあるし、頭では正しいと理解できるけれども、やっぱり、空恐ろしさを感じずにはいられない。なぜなら、ごく普通の意味での「意思決定」とは、「自分の経験や知識や直感をもとに、専門家の意見も聞いて、自分で何かを決定すること」に他ならないからだ。

私は今、この本の感想をiPhoneで書いている。多くの人に読んで欲しいと思って、文章を推敲している。あなたはこの感想を読んでいる。きっと、何か有益な情報が欲しいと思って読んでくれているのだと思う。しかし私たちの行動は、ともに目的に対してベストではない。より適切な行動は、統計分析が知っている。

人間の直感に基づく意思決定は、全く当てにならない。本書にはそんな事例が、山ほど出てくる。「でも、絶対計算の結果を専門家の代わりに利用すれば、より良い判断ができるってことでしょう？」という、”直感的な”期待すら裏切られる。ほとんどの場合、何も考えずに、ただ統計分析に従った方が正しい。

しかし本書は、人間の直感の価値を否定する本ではない。例えばワインの事例。どのような気象条件が揃えばブドウが美味しくなるのかは、昔から経験的に知られていた。その背景にあったのは、ごく自然な、直感に基づく推論だ：「夏の気温が高ければ、実が良く熟して酸味が抜ける。雨が少なければ、果汁が実の中で濃縮される」。著者らが行った無線式車両盗難防止装置の調査も、”根拠に基づく医療”を掲げるバーウィックの根拠も、本書のその他あらゆる事例も、そうした例に加えていいだろう。みんな始まりは、ありきたりな直感からなのだ。

だから絶対計算とは、人間の直感にとっては、いわば淘汰圧のようなものだ。淘汰圧がなかった頃は、どんな役に立たない直感も、生き延びることができた。たまたま最初の事例で偏りがあったとか、言い出した人が業界の権威だったとか、全くの誤解だけど理屈だけはもっともらしいとか……いずれにせよ、誰にも間違いを証明することはできなかったから、根拠がないままに信じられていた。そこに絶対計算が登場した。誰にでも分かる形で、直感の本当の価値が示されるようになった。価値のない直感は淘汰された。そして真に価値ある直感、絶対計算という淘汰の力をも利用する直感だけが、生き延びて大きな繁栄を謳歌するようになった。その繁栄の規模は、かつては考えられなかったほどに巨大だ。

無論、この淘汰の圧力は、今後も強まり続けるだろう。コンピュータの処理能力はますます上がり、より多くのデータを、さらに短時間で解析できるようになっていく。人生の多くの意思決定が、誰かの絶対計算の結果によって覆い尽くされていくのだ。そんな世界では、絶対計算家ではない一般の人たちも、統計の基礎的な素養を身につけなければならない。それは不当な扱いから身を守るためであり、同時に自らがチャンスを掴むためでもある。その手始めとして、誰もが使える統計の武器である「2SDルール」と「ベイズ理論」を紹介して、本書は締めくくられる。

補足：プログレッサ計画はバラマキか？

本書の文庫版には追加の訳者付記があって、そこで翻訳者の山形浩生氏が、3章に登場する「プログレッサ計画」に対し、「バラマキ政策ではないのか」と疑問を投げかけている。

要するに、子供が学校に通ったらお金を（それも通常賃金の三分の二というかなりの金額を）あげるという代物だ。所得水準でいえば、日本で小学生に、月に十万円あげるから学校に行こう、と言うに等しい。（略）それだけのお金をあげれば、就学率が上がったり、学校をやめる子が減ったりするのは当然だ。

だがこのプロジェクトの中身を考えると、本当に絶対計算を使う必要があったのだろうか？（略）そしてこれは実は（日本の子供手当など問題にならないくらいすごい）ばらまき政策ではないのか？

これはあんまりな誤読だと思うから、要点を論じておこう。以下の議論は、あくまで本文に何と書いてあるかについての議論であって、現実のプログレッサ計画がどんなものだったかとは関係ない。

プログレッサとは、子供の労働力の市場価値に応じて、親に現金を給付する政策だ。本当に貧しい家庭では、親が幼い子供を働きに出す。親が子供の未来を犠牲にしてしまうのだ。それを防ぐための政策が、プログレッサである。この時点で「日本で小学生に10万円」とは全く違う話だ。

さて、直感的には、子の労働力の市場価値を越えるくらいの現金を給付すれば、問題は解決しそうに思われる。それだけなら、訳者の言う通り、絶対計算など使う必要はなかったかもしれない。しかしプログレッサの考案者たちは、もっと別のことも考えたのだ。「予算はできる限り抑えたい」「給付金が、確実に子供たちのために使われることを、保証したい」。これによって、プログレッサの実施条件は、次のようになった：

• 現金支給額は、子供の労働力の市場価値の、約3分の2
• 支給を受けるには、各種の健康診断を受けなければならない
• 支給を受けられるのは母親のみ

ここまで来れば、もはや成功が明らかな政策とは、言えないだろう。仮に成功したとしても、確かにこの政策のお陰だったと断言するのは、難しいだろう。だからこそ、まず無作為抽出テストを行って有効性を明らかにしたことには、大きな意味があったのだ。もちろん、それが次の政権への引き継ぎにも大きな役割を果たしたことは、本文にある通りだ。

まとめると、プログレッサには、貧困の継承を断ち切るという、明確な目標があった。登校率や各種の健康指標という、客観的に成果を測るための指標もあった。無作為抽出テストで有効性が示されてから全国規模に拡大するという、慎重な導入プロセスをも踏んでいた。それをバラマキではないかと言うのは、流石に違うだろう。

書名の”才能”は「じぶん」と読む。その”才能”の、本書における定義は次の通りだ。

才能とは、無意識に繰り返される思考、感情、行動のパターンである

つまり才能それ自体には良し悪しはなく、使い方次第で強みにも弱みにもなる人格的な偏り、ということである。

どんな才能を持っていてどんな才能を持っていないかは（成人の場合は）変えようがないので、持っていない才能にこだわって弱みを克服しようと必死になるよりは、持っている才能を磨いて自らの強みとし、その強みを活かして生きるべきだ、その方が幸せだし企業の生産性も高くなるよ！……というのが本書の基本的な主張である。

さらに著者らの会社では統計分析を基に、この才能を形作る34種類の”資質”を見出したと主張する。人はそれぞれ、その中の5つ前後を特に顕著な資質として持ち、その組み合わせと強弱が人によってバラバラなので、才能もまた人それぞれ異なる形を取るのだ、と。

その”資質”はストレングス・ファインダーというテストを受けることで実際に確かめることができ、本書を買えば無料で1回受けられる。このテスト目当てで本書を買う人も少なくないだろう。ちなみに私の資質は次の5つだった。

1. 収集心
2. 戦略性
3. 内省
4. 着想
5. 学習欲

こうしたテストは単に「当たってるー！」と喜ぶだけでもそれなりに楽しめるわけだが、真剣に自分の人生を見つめ直す一助として本書を活用するのであれば、2つほど注意すべき点がある。

1つ目。この本自体は基本的に企業のマネージャーに向けた内容になっているということ。ある企業の枠内である人材を最大限活用するには、というのが第一の関心事であり、個々人が（それこそ転身転職を含めた）自分の生き方を再考するというテーマについてはあまり突っ込んだことを語ってくれない。いわゆる自己啓発本を期待していると肩透かしを食うだろう。

2つ目。弱みを克服するより強みを活かすべし、という普遍的な哲学と、著者らが独自に提唱する理論とは分けて考える必要があるということ。特にこれを他人に対する見方にも適用し、良くも悪くもその人に対する先入観として利用するのであれば（それが正式なマネージメントの一環であれ、カジュアルな人間観察であれ）、理論的な根拠にはそれなりに注意を払っておくべきである。

ずばり、この理論は正しいのか。本当に各人に固有で不変な思考感情行動のパターンなるものが存在し、それが著者らの主張するような資質に分解可能なのか。本書における根拠は大きく分けて二つである:

• 神経細胞の連結構造の一意性と不変性
• ギャラップ社が独自に行った200万人分の統計分析

神経細胞の連結回路が加齢とともに減少し、人それぞれ固有のパターンを形成して、一定の年齢以後は変化しなくなるというのは科学的な事実だろう（本当に本当かまでは調べていないが、科学的手法で容易に正否が判断できる類のものなので、著者らを信用することにする）。ただ、その構造が直接、繰り返し現れる変更不能な感情思考行動パターンに対応しており、故にそのパターン=才能も不変である、という部分は多少科学的に飛躍しているのではないかと私には思われる。

またそれが科学的事実だとしても、そのパターンが「34種類の資質に分解でき」「特に顕著な5種類を持つ」ということ、そしてその資質の具体的な内容については、あくまでこの会社独自の主張である。ギャラップ社がその主張をベースにしてコンサルタント業を営む会社だということも忘れるべきではないだろう。

もちろん、この本で説明されている各資質の説明を読み、実際に自分でストレングス・ファインダーを受けて結果を見、自分の経験則に照らして考えれば、かなりな程度”正しそう”には感じられると思う（個人的には自分の分析結果も含め、大いに納得できる点は多い）。しかし単に確からしさだけを問題にするなら、血液型占いにすら信憑性は宿るのだ。

こうした点を踏まえれば、34の資質だとか5つの強みだとかの具体的な内容にあまり捉われすぎるのは得策ではないだろう。本書で解説されている内容およびストレングス・ファインダーで示された結果は、むしろ日々の実践の中で自らの本当の才能――無意識に繰り返される思考、感情、行動のパターンに目を向けるための補助線として活用すべきものだ。ストレングス・ファインダーの分かりやすさについ目が行きがちだが、それこそが才能を見つける王道であると本書にもある（第3章）。

そしてまた、理論面での精確な根拠はさておくにしても、著者らが主張する哲学の面に関しては、自分の生き方や働き方、他人との関わり方を見つめ直すための一種の「問いかけ」として、誰にとっても役に立つものと思う：

• 自分に向いていないこと、弱みを克服しようともがき苦しむよりは、強みに目を向けてそれを伸ばしていく生き方の方が幸福になれるのではないか
• 自分にできないことを率直に認め、他人と協力し合うべきではないのか
• 理解不能な他人の言動にただ腹を立てるよりは、表裏一体の長所に気を向けるべきではないか

• Mac OS X Lion
• Vim 7.3（Lionに標準で入っているもの）
• CoffeeScript 1.2.0

VimはMac標準のターミナル.app上で使用する。Lionからは256色表示に対応したので実用性が高くなった。

ppathogenのインストール

まずvimのプラグインを管理しやすくするためのプラグインであるpathogenを導入する。手順は配布ページに書いてある通り。

mkdir -p ~/.vim/autoload ~/.vim/bundle
curl 'www.vim.org/scripts/download_script.php?src_id=16224' \
  > ~/.vim/autoload/pathogen.vim

.vimrcに次の1行を追加してインストール完了。

call pathogen#infect()

vim-coffee-scriptプラグインのインストール

インストール自体は.vim/bundle以下にgit cloneするだけで完了。

cd ~/.vim/bundle
git clone https://github.com/kchmck/vim-coffee-script.git

タブの設定をCoffeeScriptの推奨値にあわせて変更。次の1行を ~/.vim/after/ftplugin/coffee.vim に追加する。

setlocal shiftwidth=2 expandtab

さらに最も使用頻度が高い:CoffeeCompileコマンド（編集中のファイルをJavaScriptにコンパイルして、結果を別ウィンドウに表示するコマンド）にはショートカットキーを割り当てる。私はC-cに割り当てることにした。以下の2行を ~/.vim/after/ftplugin/coffee.vim に追加する。

" CoffeeCompileコマンドにvertオプションを付けることでウィンドウが縦に分割され、
" splitrightオプションによってコンパイル結果が右側に表示されるようになる
nnoremap <silent> <C-C> :CoffeeCompile vert <CR><C-w>h
setlocal splitright

vim-indent-guidesプラグインのインストール

CoffeeScriptはインデントで構造を表すので、インデント量の違いを見やすくするためにvim-indent-guidesプラグインを導入する。これもインストール自体はgit cloneで完了。

cd ~/.vim/bundle
git clone https://github.com/nathanaelkane/vim-indent-guides.git

gVimで使用する場合はインデントの色も自動で設定されるようだが、私はターミナルで使用したいので手動で色を指定した。色見本はこちらのページを参考にした。

let g:indent_guides_enable_on_vim_startup = 1
let g:indent_guides_auto_colors = 0
 
" indent guides
augroup indentguides
    autocmd!
    autocmd VimEnter,Colorscheme * :hi IndentGuidesEven ctermbg=236
    autocmd VimEnter,Colorscheme * :hi IndentGuidesOdd ctermbg=235
augroup END

最終的な表示は次のようになる。

参考

• vim pluginとgitで強まった開発環境を手に入れよう！〜coffeescript編〜
• Vimテクニックバイブル　～作業効率をカイゼンする150の技

IE8以前でDOMContentLoadedイベントをエミュレートする方法として、doScrollを使ったハックは広く知られている。例として『パーフェクトJavaScript』230ページのリスト8.9より引用。

function IEContentLoaded (callback) {
    (function () {
        try {
            document.documentElement.doScroll('left');
        } catch (error) {
            setTimeout(arguments.callee, 0);
            return;
        }
        callback();
    })();
}

しかし実際に試してみればわかるが、これだとwindow.onloadより実行が遅くなる場合がある。

テスト1（画像なし） テスト2（画像あり）

具体的には

• 画像など外部から読み込まれるリソースが少ない場合
• リロードした時にキャッシュがきいている場合

こういったケースではwindow.onloadとdoScrollハックの実行順序は逆転する場合がある。もちろん逆転しない場合もある。doScrollハックはあくまでハックであって正式なイベントシステムの一部ではないのだから、一貫した動作をしなくても当然だと言える。

この実行順序の逆転を防ぐために、世の中のライブラリではdocument.onreadystatechangeイベントを併用するのが習わしとなっている。例えばdoScrollハックを世に広めたDiego Perini氏の実装を見れば、trying to always fire before onload というコメントとともにreadyStateをチェックするコードが入っているのが分かる。

document.onreadystatechange = function() {
    if (document.readyState == 'complete') {
        //コールバック関数を実行し、以後はdoScrollハックが動かないようにしておく
    }
};

テスト1（画像なし） テスト2（画像あり）

現実問題としては、わざわざ自前でdoScrollハックを書くような状況では、この順序の逆転が問題になることはまずないと思われる。しかし以下のような教訓を読み取ることはできるだろう:

• 広く知られていようがハックはハック。使うときは慎重になろう
• 可能な限り信頼できる既存の実装を使おう
• 自分の手で実験しよう

• UINavigationControllerの中で画面遷移が起こった（戻った・進んだ）
• modalダイアログが開かれた・閉じられた
• UITabBarControllerでタブが切り替えられた

今作っているアプリでは特にUINavigationControllerの中で「進んだ」「戻った」といったイベントを検出したかったので、それらをサポートするための抽象クラスを作ってみた（UIViewControllerのサブクラス）。

NavigationSupportController.h
NavigationSupportController.m
（iOS 4.3と5.0で動作確認）

このNavigationSupportControllerのサブクラスでは、viewWillAppear:、viewDidDisappear:等の代わりに次のメソッドをオーバーライドする。

• viewWillAppear:(BOOL)animated direction:(NavigationDirection)direction
• viewDidAppear:(BOOL)animated direction:(NavigationDirection)direction
• viewWillDisappear:(BOOL)animated direction:(NavigationDirection)direction
• viewDidDisappear:(BOOL)animated direction:(NavigationDirection)direction

NavigationDirectionは列挙型で、次の3種類の値をとる。

こんな感じで判定する。

- (void)viewWillAppear:(BOOL)animated direction:(NavigationDirection)direction
{
    if (direction == NavigationBack) {
        //「戻る（= pop）」の場合
    } else if (direction == NavigationForward) {
        //「進む（ = push）」の場合
    } else if (direction == NavigationNone) {
        //NavigationControllerによらない画面遷移の場合
    }
 
    //共通の処理はここに書く
    //つまり viewWillAppear:(BOOL)animated の方はオーバーライドすべきではない
}

検出ロジックの都合上、コントローラのインスタンスはpushするときに作成され、popされるときに破棄されることを前提としている。普通はこれで問題ないはず。

もっと確実・簡単な方法があれば教えてください。

必要なもの：

• mod_dosdetector-forkのapache-2.0ブランチ
• Apache 2.2 のソースコード Download – The Apache HTTP Server Project
• ソースコードを編集するためのエディタ（手動で編集する場合）
• Linux（他のUNIX系のOSでも動くかも）

一応、自動で編集するスクリプトも作ってみたが、先に手動で編集する場合の手順をざっと説明しておく。

手順1.

mod_dosdetector.c をエディタで開き、/* code for apache 2.0 */ というコメントが書いてある部分に次の1行を書き加える。

#include "apache20.h"

手順2.

Apache 2.2のソースを展開して srclib/apr/shmem/unix/shm.c をエディタで開き、関数apr_shm_removeの定義部分をコピーして、手順1で編集した部分の直後にペーストする。最終的にこんな感じになる。

/* code for apache 2.0 */
#include "apache20.h"
APR_DECLARE(apr_status_t) apr_shm_remove(const char *filename,
                                         apr_pool_t *pool)
{
//..略..
}

以上で必要な編集作業は終わり。ここまでの手順を自動化するスクリプトがapache20.plという名前で入っているので、これを実行してもいい。

# 展開したApache 2.2のソースディレクトリを指定する
perl apache20.pl path/to/httpd-2.2.x

あとは通常通りのインストール手順でOK。

#apxsが/usr/sbinに入っている場合
#コンパイル
make PATH=/usr/sbin:$PATH
 
#インストール
make PATH=/usr/sbin:$PATH install

動作確認は次の環境で行った。

• ソースコードのコピー元: Apache 2.2.21
• 動作: Apache 2.0.64 on CentOS 5
• 動作: Apache 2.0.52 on CentOS 4

今後どの程度メンテナンスを行っていくかは不明なので、そこは予めご了承いただきたい。あと2.2側のコード変更によっては自動化スクリプトは動かなくなる可能性があるので、そのときは適宜手動で対応のこと。

前回の続き。

GTD本を読んで、OmniFocusを買ったら、いよいよGTDの実践。今回のテーマは実践にあたっての心構えと、OmniFocusへの向き合い方。

全ては行動するためにある

まずGTDの全ては行動するためにあるという大原則を忘れないこと。決して整理分類マニアになってはいけない。GTDもOmniFocusも「気になること」を行動に移すための手段に過ぎない。もしうまく行動に移せていないと感じたら、躊躇わず自分のやり方を見直そう。

OmniFocus一つで全てをまかなおうとしてはいけない

OmniFocusはGTDを念頭に作られた、非常に多機能なソフトだが、決して万能ではない。これ一つで全てをまかなおうとはしないこと。例えば以下のような用途には使えない:

• カレンダー/スケジューラ
• 大量の資料の整理・保存
• 「旅行に持っていくもの一覧」のようなリスト

こういった用途には別のアプリ（もしくはアナログなリスト）を使うべきである。GTDは複数の異なるリストを使い分けることを前提としているので、全てを一箇所で管理する必要はない。

OmniFocusの機能とGTD本の関係

OmniFocusではGTD本に出てくる概念を多少アレンジしているので、 本に登場する各種リストと、OmniFocusの機能は完全には一致しない。本に従ってGTDを実践するなら、この差異をうまく埋める必要がある。

以下に対応関係の例を示す。あくまで私が考えた対応関係なので、他にもあり得ると思う。

この分類に従うなら、OmniFocus を買って最初にやることは

• コンテキスト「連絡待ち 」を追加
• プロジェクト「いつかやる、多分やる」を追加

この2つになる。

「連絡待ち」「いつかやる・多分やる」について

次回以降に詳しく説明する予定。

OmniFocus は誰にも見せない

最後に、とても大切なこと。OmniFocusは誰にも見せてはいけない。

昨今は何でも共有するのが流行りだが、OmniFocusは誰にも見せないものだと常に意識しよう。他人の目を気にするとつい格好つけて、本当は大してやりたくないことを入れてしまったり、本当はやりたいんだけどみっともなような気がするアレやソレを省いてしまったりする。それではGTD本で言う「水のように澄んだ心」にはなれない。

GTDで扱うのは気になること全て。どんなに大それた野望も、ちょっと公にはしたくないような望みも、全てを集めよう。

続きます。

OmniFocusを使ったGTDを始めて1年近くが経った。自分なりに使いこなすコツが集まってきたので、ブログにまとめていこうと思う。これからGTDを始める方、OmniFocusを買おうか迷っている方、OmniFocusのより良い使い方を探している方などの参考になれば幸い。

最初はなるべく大きな話題、基本的な話題から始めて、徐々に細かい使い方の話に移っていく予定。

OmniFocusまたはその他の専用アプリを買うべき？

まずGTDを始めるにあたって、OmniFocusなど専用アプリを買うべきか？結論からいえば、絶対に買うべき。根拠は二つ。

• GTDは、まともに取り組もうとすれば、かなり複雑な方法論である
• GTDの本質は習慣付けや精神論ではなく、システムを構築して運用することである

GTDが複雑であることは否定し難い。GTDでは役割の違う「リスト」を何種類も使い分けて、それぞれを適切に運用して、しかも全体を秩序だったシステムとして維持していかなければならない。各リスト間の整合性を保つ作業などは、典型的な「人間には難しいが、コンピュータには易しい」仕事だ。スマホ全盛のこの世の中で、手元のコンピュータ資源を活用しない手はない。

実際、GTDの原著ではこの「リスト」を作るのにアナログなツールを使うことを基本の想定としているため、デスクの再構築までがセットになっている。それこそGTD本の著者デビッド・アレンさんをコンサルとして雇うならともかく、普通の人はいきなりそこまでやりたくはないというか、できないだろう。

それにGTDとは本質的にシステムの運用論であり、テクニックである。だから「形から入る」ことに罪悪感を覚える必要はない。形を作って維持するのがGTDなのだから、出来合い品を買って使い方を覚えれば、それで十分機能する。

逆にいうと、GTDのコツと使っているアプリの使い方のコツとはほとんど不可分になる。私はOmniFocusを使っているので、 このブログに書く内容もOmniFocusの使用を前提としている。

どのOmniFocusを買うべき？

OmniFocusにはMac版、iPhone版、iPad版がある。いつでもどこでも使えるという意味でiPhone版は必須、あとは個人の好みだろう(私はMac版も持っている)。このブログでもiPhone版をメインにまとめていく。

原著Getting Things Done（邦訳『ストレスフリーの仕事術』）は読むべき？

もちろん読むべきだが、はっきり言ってわかりにくい本だということは覚悟した方がいい。この本は体系だった方法論を説明するというより、著者が自分のクライアントに対する時の説明の手順をそのままなぞっているようなところがある。

私がこうやってブログにまとめようと思ったのも、本の内容がわかりにくくて、自分なりに体系付けたいと思ったからだ。だからGTDの本に書いてある内容と重複する内容も多くなると思う。

続き: OmniFocusを使い始める

• 何か意味のあるサンプルを作りたかったわけではなく、単に動作の性質が知りたかっただけです
• 実装は読んでないので多分に憶測混じりです
• dartlang.org上のDartboardでテストしています

DartのIsolateはErlangのプロセスに似ていると評価されることがあるが（確かに似たところもあるが）、使用感は全く別物と思った方が良いと思う。最も大きな違いは「receiveがブロックしない」つまり「メッセージを受信するまで待つ」ことができないこと。

class IsolateA extends Isolate {
  main() {
    port.receive((msg, replyTo) {
      //受信したメッセージの処理
    });
    //ここに書いたコードはメッセージの受信を待たず実行される
    print("hoge");
  }
}

これが何を意味するかと言うと、メッセージを受信した後で実行したい処理は全てクロージャの中に入れて、イベント駆動で動作させる必要があるということ。複数のIsolateを扱ったり、処理の前後関係が発生したりするとかなり面倒なことになる。Dart組み込みのPromiseを駆使することが必須になるだろう（最後に例を載せています）。

それと別のIsolateにデータを送るには厳密にメッセージ送信しか手段がない。コンストラクタやプロパティ経由で値を送ってもIsolateインスタンスの中からは参照できない。

class IsolateB extends Isolate {
  int x = 0;
 
  main() {
    port.receive((msg, replyTo) {
      print(x + msg);
    });
  }
}
 
main() {
  IsolateB iso = new IsolateB();
  //ここで値を設定しても消える
  iso.x = 5;
 
  //表示されるのは 105 ではなく 100
  iso.spawn().then((port) {
    port.send(100); 
  });
}

では初期化が必要な場合はどうするのかというと、初期化専用のメッセージ構造を決めておいて、その中に値を込める。例えば配列や辞書を使って。

class IsolateC extends Isolate {
  int x = 0;
 
  main() {
    port.receive((msg, replyTo) {
      if(msg[0] == "init") {
        x = msg[1];
      } else {
        print(x + msg[1]);
      }
    });
  }
}
 
main() {
  new IsolateC().spawn().then((port) {
    port.send(["init", 5]);
    port.send(["print", 100]);
  });
}

こういったやり方はErlangでもお馴染みだけど、Erlangと違ってパターンマッチはないしapplyもないし文字列からメソッドを得ることもできないし、そもそも静的型付け思想と全然相容れないしで、はっきりいって、ひどい。このIsolateという機能がどうにもDart言語に最適化されていない、練り込みが足りない感じがするのはこの辺りだ。

そしてメッセージ送信を用いても、制約なくどんなオブジェクトでも送れるわけではない。リファレンスに説明がない＆実装を読んでないので詳しい条件は不明だが、独自に定義したクラスのインスタンスは送れない。組み込みのRegExpやPromise等も駄目（Dartboardにはエラーすら出ない）。intやStringといった基本的な値の他には、ListとMapくらいしか送れないと考えた方が良いかもしれない。

class Xyz {
  String toString() => "xyz";
}
 
class IsolateD extends Isolate {
  main() {
    port.receive((msg, replyTo) {
      print(msg);
    });
  }
}
 
main() {
  new IsolateD().spawn().then((port) {
    //エラーすら出ずに無視される
    port.send(new Xyz());
  });
}

それはそれとして、新たに起動したIsolateに対してメッセージを送るサンプルは多いが、別のIsolateから送られたメッセージを”メインIsolate”で受け取る方法があまり紹介されていないので触れておくと、ReceivePortを普通にnewして、toSendPortで対応するSendPortを生成、sendの第二引数で送信元Isolateに通知すれば良い。

class EchoIsolate extends Isolate {
  SendPort mainPort;
 
  main() {
    //第2引数でSendPortが送られてくる
    port.receive((msg, replyTo) {
      if(msg == "init") {
        mainPort = replyTo;
      } else {
        mainPort.send("echo: " + msg);
      }
    });
  }
}
 
main() {
  ReceivePort p = new ReceivePort();
 
  new EchoIsolate().spawn().then((port) {
    port.send("init", p.toSendPort());
    port.send("foo");
    port.send("bar");
  });
 
  //echo: foo, echo bar
  p.receive((msg, replyTo) => print(msg));
}

特定のIsolateと単発でやり取りする場合はsendの代わりにcallを使うとこの過程を自動化してくれる。

class EchoIsolate extends Isolate {
  main() {
    port.receive((msg, replyTo) {
      replyTo.send("echo: " + msg);
    });
  }
}
 
main() {
  new EchoIsolate().spawn().then((port) {
    port.call("foo").receive((msg, replyTo) => print(msg));
  });
}

また特例として、メッセージの中にReceivePortを入れると自動でSendPortに変換されるので、次のようにも書ける。

class EchoIsolate extends Isolate {
  SendPort mainPort;
 
  main() {
    port.receive((msg, replyTo) {
      if(msg is SendPort) {
        mainPort = msg;
      } else {
        mainPort.send("echo: " + msg);
      }
    });
  }
}
 
main() {
  ReceivePort p = new ReceivePort();
 
  new EchoIsolate().spawn().then((port) {
    port.send(p);
    port.send("foo");
    port.send("bar");
  });
 
  //echo: foo, echo bar
  p.receive((msg, replyTo) => print(msg));
}

最後にFizzBuzzを題材として、2つのIsolateを起動し、”メインIsolate”を含む3つをリング状に連結してメッセージを回す例を載せておく。main => Fizz => Buzz => main とメッセージが回って、mainでprintする。それぞれの起動と初期化が非同期になるので、盛大にPromiseを使うことになった。

class FizzBuzzIsolate extends Isolate {
  static final MSG_INIT = "init";
 
  Promise<SendPort> _nextPromise;
  String _word;
  int _divisor;
 
  _senderFunc(i, s) => (SendPort nextPort) {
    if(i % _divisor == 0) s += _word;
    nextPort.send([i, s]);
  };
 
  static init(SendPort port, SendPort nextPort, String word, int divisor) =>
    port.send([MSG_INIT, [word, divisor]], nextPort);
 
  main() {
    _nextPromise = new Promise<SendPort>();
 
    port.receive((msg, replyTo) {
      if(msg == null) {
        port.close();
      } else if(msg[0] === MSG_INIT) {
        _word = msg[1][0];
        _divisor = msg[1][1];
        _nextPromise.complete(replyTo);
      } else {
        _nextPromise.then(_senderFunc(msg[0], msg[1]));
      }
    });
  }
}
 
main() {
  ReceivePort mainPort = new ReceivePort();
  Promise<SendPort>
    fizz = new FizzBuzzIsolate().spawn(),
    buzz = new FizzBuzzIsolate().spawn(),
    p = new Promise();
  p.waitFor([fizz, buzz], 2);
  p.then((val) {
    FizzBuzzIsolate.init(fizz.value, buzz.value, "Fizz", 3);
    FizzBuzzIsolate.init(buzz.value, mainPort.toSendPort(), "Buzz", 5);
  });
 
  _sender(i) => (port) => port.send([i, ""]);
  for(int i=1; i<=100; ++i) fizz.then(_sender(i));
 
  mainPort.receive((message, replyTo) {
    print(message[1] == "" ? message[0] : message[1]);
  });
}

アプリ内でiPhone（iOSデバイス）の機種を判別するには sysctlbyname というC言語の関数を使うのだが、結果は “iPhone3,1″ のような文字列で返ってくるため、そのままでは扱いづらい。これをわかりやすい形に変換してくれるUIDevice Extensionというオープンソースのライブラリが存在する。

UIDevice Extensionには多くの機能があるが、機種判別を行うだけなら UIDevice-Hardware.{h,m} のみ自分のプロジェクトにコピーすれば良い。いずれもUIDeviceクラスに対するカテゴリとして構成されているので、使用したい箇所で .h をインクルードすれば、UIDeviceに専用のメソッドが追加される。

機種名を文字列として取得するには platformString メソッドを使う。このメソッドが適しているのはユーザがどの機種を使っているか集計したい場合等だろう。なお2011年9月25日現在、未発表のiPhone 5まで対応している（この情報が確実に正しいとまでは言えないはずだが）。

//@"iPhone 3GS" や @"iPhone 4" といった文字列が返る
NSString *iosDevice = [[UIDevice currentDevice] platformString];
 
//おまけ: iOSのバージョンとアプリのバージョンを取得する
NSString *osVersion = [[UIDevice currentDevice] systemVersion];
NSString *appVersion = [[[NSBundle mainBundle] infoDictionary]
                                        objectForKey:(NSString*)kCFBundleVersionKey];

機種に応じてロジックを切り替える必要がある場合には platformType メソッドが適している。戻り値はヘッダファイル内で定義された列挙型 UIDevicePlatform である。

if([[UIDevice currentDevice] platformType] == UIDevice4iPhone) {
    //iPhone4 の場合の処理
}

ただ大雑把に機種を振り分ける場合にはコードが煩雑になりがちなので、jorgenptさんのforkで定義されているような包括的なマクロを利用するのが良いかもしれない。いずれにせよこの種の判定でロジックを切り替える場合、前方互換性に注意する必要がある。