難しポイント

• restrict: 'E'
  • この directive は要素として使うよってこと
• directive の scope の定義がむずかしい
  • プロパティ名には自分のスコープで見える名前、値には謎の書式で親スコープから見える名前が書いてある属性名を書く
• controller に渡される $scope
  • 親スコープなどからは分離されているスコープが与えられる。directive が何度も出現することもあるからね!
• transclude: true の意味。これは dialog 要素内に内包される変数が、外側のスコープをさすようにするもの。例では $scope.message を外側のスコープで代入している

こういう謎の構造体を返すのってわっかりにくいので気持ち悪いなあて思いました。全部メソッドになっているべきなのでは????

directive のプロパティの説明がどこにあるかわかりにくいけど、 http://docs.angularjs.org/api/ng.$compile#description_comprehensive-directive-api_directive-definition-object にある

Raspberry Pi

Type A と Type B があり、Type A はイーサネットポートと組込みUSBハブがなくメモリが少ない分少しだけ安い。

BeagleBoard Black

本体は Raspberry Pi と同じぐらいの価格だけど、

• CPU がより高速
• オンボードなフラッシュメモリがある (SDカードもつけれる)
• 消費電力がより低い
• GPIO が多い

という特徴がある。内蔵フラッシュメモリがあるので、(それにおさまるなら) SDカードがいらない分、Raspberry Pi よりコスト面でも有利。一方で欠点は

• 入手性
  • Raspbery Pi はかなり安定して手に入る感じだけど、BeagleBoard Black はそうでもない感じ
• 情報源
  • やはりちょっと少ない

Intel Galileo

価格的に上であげたものの1.2〜1.5倍ぐらいする。現時点ではまだ日本未発売。1月中旬らしいのでそろそろかな。2A のAC アダプタとケーブルが一部付属っぽいので、(それらが必要な人なら) そんなに割高とはいえないかもしれない。

Linux が動いてるけど、Arduino 互換を謳ってる。ピン互換があって Arduino 用にでまわっているシールドがつかえるのと、開発環境も Arduino のものが使える。

気になるのは

• グラフィック出力がない (HDMI とか)
• 消費電力 (詳しいスペックがわからないけど、2A のアダプタが付属ってことは結構あるのかな)

Arduino

Arduino は AVR というマイコンを使って動いているので、Linux は載っていない。本当にローレベルなことしかできないし、CPU クロックも20MHz程度。2000円〜3000円ぐらいで買えるみたいだけど、できることと、実装方法の苦楽の差を考えると Raspberry Pi や BeagleBoard Black のほうが圧倒的にコストパフォーマンスは高い。

個人の見解のまとめ

最初に手をとるなら Raspberry Pi がよさそう。もっと要求がでてきたら BeagleBoard Black がよさそう。Intel Galileo はなんともいえない。

さらに別の回路を複雑に繋げたり、役割分担をさせたくなったら、Arduino 的なものを導入してもよさそう。

しかし AVR 使うなら、普通にチップ買えば1個あたり50円〜300円程度 (チップによる) なので、個人的にはそのほうがいいと思う。ただ、Arduino はオールインワンな感じの開発環境がキモなので、それが欲しいなら Arduino はいいかもしれない。(自分で互換のブートローダーを書きこんでもいいけど)

つかいかた

glint(
	function (port) {
		// ここは外部プロセスで実行される
		// ただし文字列化して関数が渡されるので外のスコープの変数は使えない。
		// node.js の exec, execFile はいわゆる exec ではないので1つプロセスが余分にできる。我慢するしかない。
		console.log('starting memcached with port: ' + port);
		require('child_process').execFile('memcached', ['-p', port]);
	},

	function (error, server) {
		if (error) throw error;

		// server は起動が確認済み
		// server.port でポート番号がとれる。
		// server.kill() でこのプロセスだけ殺せる

		console.log(server);
		var s = net.connect(server.port, function () {
			s.write("version\r\n");
		});
		s.on('data', function (data) {
			console.log(data.toString('UTF-8'));
			s.end();
		});

		// この関数を抜けても exit されるまで server は (明示的にkillしない限り) kill されない
	}
);

しくみ

他のモジュールとやってることは一緒なのですが、node.js だと面倒な点がいくつかあります

• fork / exec はいわゆる *nix の fork/exec ではない
• オブジェクトファイナライザ的な仕組みがない
  • 特定のオブジェクトが破棄されるタイミングで処理を行うことができない

node の fork / exec (execFile) は *nix の fork / exec とは全く違うので、細かいプロセスの制御ができません。特に exec 単体相当はないので、現在のプロセス自体を置き換えるということができません。そんなわけで1つ別プロセスを経由している関係で、無駄に1プロセスを消費しています。

オブジェクトのファイナライザがないので、node-glint では process.on('exit') で起動したサーバを終了しています。ただし、普通に外部プロセスを起動すると、そのプロセスの終了を待つ挙動になり、exit されません。が、spawn() のオプションに detach: true を指定した上で、unref() を呼んであげることで、外部プロセスの終了に関わらず起動元の node プロセスを exit させることができます。

まとめ

一応形にはなりましたが、細かい挙動の検証がめんどうなので npm にあげてません。特に現在の実装はシグナルまわりのハンドリングがいい加減です。node マスターの皆様におかれましては、よりよい方法をご教示頂ければと思う所存です。

Time Machine をオフに

まず既存 Time Machine を OFF にする。

現状のバックアップディスクをバックアップ

HDDを新しく買ってくるならこんなことしなくていいんだけど、買いたくないので、一旦現状のバックアップディスクを、別にディスクに .dmg としてバックアップした。

バックアップディスクとなるスパースバンドルファイルをつくる

ディスクユーティリティでスパースバンドルファイルをつくる

• サイズはとりあえずデフォルトのまま
  • 手元のディスク容量よりも大きいサイズには作れないため
• フォーマットは Mac OS 拡張 (ジャーナリング)
• イメージフォーマットはスパースバンドル・ディスクイメージ

作成したらアンマウントして、NASに繋げるディスクにコピーする。最初のバックアップまでは USB で直接繋いで作業する。

コピーしてからもう一度そのイメージをディスクユーティリティで開いて、「イメージのサイズを変更」を行い、2TB ほど容量を確保する。

バックアップをスパースバンドルイメージに復元

スパースバンドルファイルに対して、既存のバックアップの dmg を復元する。死ぬほど時間がかる。

NAS に繋げてバックアップ開始

ディスクをNASに繋げ、共有フォルダを開き、イメージをマウントする。

イメージをマウントして、マウント済みディレクトリに対し、以下のコマンドを実行。GUI を使わないので強制的に設定できる。

sudo tmutil setdestination /Volumes/Time\ Machine 

これでバックアップを再開するとネットワーク経由でバックアップが開始される。履歴も引き継がれ、差分バックアップになる。