中途半端にDropbox好き

コラボ作業だの納品だの、やたらとhttp://www.dropbox.com:Title=Dropboxを使っていたところ、当然のごとく、標準の2GBでは容量が足りなくなってしまった。結局50GBのプランを契約して、その後もヘビーに使い続けている。

ちなみに50GBのプランは年額$99だ。80GBで年額$20のGoogle Storageと比較すると割高だけれど、Google Storageの方はストレージとしての使い勝手にちょっと問題がある。Dropboxの代わりにはならない。

50GBのDropboxは余裕があって気が楽だ。ただ、最近導入したMacBook Airに50GBのDropboxを同期するのは、ちょっと重荷のような気がする。諸々のアプリやデータを入れて環境を構築すると、ちょうど50GB程度しか残っていないのだ。

そこで、メインとは別のメールアカウントを使って、新たに2GBのアカウントを作成することにした。それと古いアカウントの間で共有ディレクトリを作成し、常に持ち歩きたいデータはそのディレクトリに入れる。それ以外の大きめのデータは、古い方のMacBookから50GBのDropboxに入れる。用途によって2つのDropboxアカウントを使い分けるわけだ。

こんな感じで、自分でもちょっと気持ち悪いほどDropboxを使っている。Google Storageがもうちょっと素直に使えれば、こんな面倒な使い方はしなかったと思うのだけれど。

Unityで作ったiOSアプリを60fpsで動かす

Unityを使ったiOSアプリの制作に手を出す際、まず最初にひとつだけ、覚えておいてほしいことがある。

Unityから出力されたソースのAppController.mmにある定数kFPSを60に変更する

おめでとう。君のアプリは60fpsでなめらかに動くようになったはずだ。

まあ、実際のところは、負荷の具合によって60fpsになったりならなかったりする。ともかく、この値を書き換えない限りは、どんなに頑張っても60fpsでは動かない。60fpsで動く可能性がある場合は、必ず書き換えておくようにしよう。

UnityとC#とJavaScript

UnityのスクリプティングJavaScriptを採用している……というのは、かなり大雑把な表現だ。Unityは.NETフレームワーク互換のMono環境の上で動いている。スクリプトの方も、純粋なJavaScriptというよりかは、JScript .NETに近いものとなっている。

この辺りの仕様の詳細は、今のところマニュアルには記載されていない。数行のスクリプトを書く分にはJavaScriptのマニュアルを読めば済むだろうけども、本格的にがっつりとスクリプトを組む段になると、そういった代替手段では通用しなくなってしまう。

Unityでは、JavaScriptの他にC#でもスクリプトを書くことができる。プログラマー的な視点で考えると、.NET互換環境なんだからむしろC#で書くのがまっとうなんじゃないの、と思ったりするかもしれない。僕もそう思う。しかし実情としてはそうとも限らない。オブジェクトの挙動を記述するにはJavaScriptの方がシンプルにまとまるのだ。

ただ逆に言えば、オブジェクトの挙動に関わらない部分を書くには、C#の方がいい。具体的には、MonoBehaviorを継承しないクラスや構造体を自分で設計するようなケースにおいては、C#の方が書きやすい。むしろ、C#でなければ書きようがないという場合もある。

例えば、構造体(struct)をJavaScriptで書くことはできない。Vectorクラスなどのように、代入で値コピーが発生して欲しいようなデータ構造を作成するには、C#で書くしかない。AIなどもC#で書いた方がすっきりするだろう。

結局、UnityのプロジェクトにはJavaScriptC#が混在することになる。とてもグロい状態だ。グロいプログラミングが好きな人にはたまらない。

これを始めとして、Unityのスクリプティングの運用には若干グロいところがある。現状は、とりあえず使いやすくまとめられているので許される、って感じだけれど、そんなにとっちらかしちゃって大丈夫?という一抹の不安が残らないでもない。

Unityプロジェクトのバージョン管理

GitHubの有料プランを契約して、その非公開リポジトリにはUnityのプロジェクトを格納することにした。

そこで生じる疑問が、Unityのプロジェクトはどこまでがソースファイルなんだろう?ということ。Assetディレクトリにアセットが格納されることはすぐに分かるのだけれど、Libraryディレクトリには、色々と必要そうなファイルと、そうでないファイル(中間生成物的なもの)が混在しているように見える。これのどこまでをバージョン管理システムに入れておけばよいのだろう?

この疑問に対する解答は、リファレンスマニュアルのUsing External Version Control Systems with Unityのページにまとめられている。掻い摘んでまとめると、Editor Settingsの"External Version Control Support"をenableした後に、Assetディレクトリだけをバージョン管理に入れればOKだ。他にセッティング関連のファイルがいくつかLibraryディレクトリの中に存在するので、それもバージョン管理に入れるとなお良い。

ただ大変残念なことに、このExternal Version Control Supportの機能はUnity Proのみの拡張機能になっている。無料のUnity Freeでは、Libraryディレクトリ内のファイルもごちゃっと一緒くたにして、プロジェクト全体でのスナップショットを取るしかないようだ。

これはちょっと残念なことだと思う。バージョン管理はコラボレーションを行うのに必要なインフラだから、コミュニティを育てるという意味では無料版でもバージョン管理を使えるようにした方が良いと思うのだけれど……

GitHubの有料プランを使う

仕事用のリポジトリを作成するために、GitHubの有料プランを契約した。契約したプランは最小規模の"Micro"だ。月$7で5つの非公開リポジトリを作成することができる。また、1人の非公開コラボレーターを招待することも可能だ。

実はGitを本格的に使うのは今回が初めて。Git以外にもMercurialがあるよ、とか、GitHub以外にもホスティングサービスは色々あるよ、とか、他の選択肢は存在したのだけれど、あまり迷っているヒマは無いということもあり、恐らく現状で最も無難と思われるGitとGitHubの組み合わせに決めた。

GitHubのサービスにはほぼ満足している。今回契約したMicroプラン以外にも小規模向けのバリエーションが充実しているので、個人で受託開発するようなケースでは最適なソリューションかもしれない。

GitHubで一点だけつまずいた点がある。GitHubではHTTPSでのリポジトリアクセスにも対応していることになっているのだけれど、そこでのpushがほぼ確実に失敗する。この問題はgitのコンフィグでhttp.postbufferを大きなサイズに変更することで解決できる。詳しくはStackOverflowのやりとりを参考にするといい。

Git自体の使い勝手については、最初は戸惑うことも多かったけれど、次第に慣れてきた。Mark LodatoさんのA Visual Git Referenceがとても分かりやすいので、これで仕組みを理解してから使うと習得が早いかもしれない(僕はだいぶあとになってからこのページを知った)。

MacBook Airで開発

SSDを導入してSpotlightが快適になった……というのは、実はMacBook Airを購入したのでした。少し迷ったものの、現在の仕事で移動が多いというのと、メインで使っているMacBookが型落ち気味だったということもあり、思い切って購入。本気で仕事に使うことを考えていたので、11 inchモデルで選択できる最大のスペック(Core2 Duo 1.6GHz、4GBメモリ、128GBフラッシュドライブ)にしました。

これはかなりの賭けだったのですが(最大スペックでも仕事では使い物にならないかもと考えていた)、いちおう今のところは問題無く使えています。UnityとXcodeを行き来しながらビルドを走らせたり、Ableton Liveでソフトウェアシンセを走らせたり。動画編集以外はこれ一台で済ませることも可能かと思います。

以前のMacBookと比較して速くなった部分はあまり無く、むしろスペック相応に遅くなっている感じですが、メモリの多さとSSDのおかげで引っかかるポイントが無くなり、総合的な快適度としては若干向上しているかな……といったところ。

まあ、間違いなく移動は楽になったので、基本的にはそれで満足です。

Spotlight検索

以前から、SSDを導入するとSpotlight検索が滅法快適になるという話を聞いていたのだけれど、実際にSSDを導入してみるとこれが本当だということに気付いた。

まず、アプリを起動するのにSpotlightを使うようになる。「CTRL+スペース」でSpotlightを開いてから、アプリ名を直接入力するか、「app アプリ名」でOKだ。例えば「ターミナル」を起動するなら"app term"などと打ち込めばいい。

次に、フォルダを開くのにSpotlightを使うようになる。Finderでフォルダ構造を深く辿っていくのではなく、フォルダ名を入力するか、あるいは開きたいファイルの名前を直に入力する。これに慣れると、フォルダ管理はかなり大まかに行うだけでよくなり、各々のファイルやフォルダの名前をユニークにすることが重要になってくる。

あとは、ブラウザ履歴からウェブページを開くのにもSpotlightは使える。例えばPicasaのウェブアルバムを開くなら"picasa"と、githubダッシュボードを開くなら"github"と打ち込めばいい。これに慣れるとブックマークはほぼ使わなくても済むようになる。

このように、キーボード操作が主体の人にはとても便利なSpotlight検索なのだけれど、SSDと余裕のあるメモリ構成でなければ使い物にならないのが残念だ。今でも前のマシンに戻ったときなど、レスポンスの悪さに戸惑うことがある。