2012年5月5日土曜日

C# で map とか reduce みたいな楽しいリスト操作をしたい

プログラミング言語がロジックを組むのに向いているかいないかを判断するときの基準に、私はよく「文字列の操作が優れているか否か」「配列・辞書・集合の操作が優れているか否か」を評価点に挙げます。文字列や配列、辞書、集合の操作はほとんどすべてのアプリケーションで必要になり、それらの生産性が高く高速に処理してくれる言語ほど簡単で高速なロジックが組めると思うからです。

そういう意味でObjective-Cを考えると、文字列の操作はまぁまぁ良い(特にUnicode周りがなかなか優れている、正規化もできるし)のですが、配列・辞書・集合の操作がイマイチで、作るの面倒なら操作するのも面倒。さらには良く欲しくなる以下の操作が欠けています。
  • map - 条件式を渡して、もとの集合の各要素に条件式を通した結果を新たな集合として返す。
  • reduce - 条件式を渡して、要素を前から順番に計算して畳み込み、集合から一つの要素にする。
  • any - 一つでも要素が条件式を満たすならtrue, すべての要素が満たさないならfalse
  • all - すべての要素が条件式を満たすならtrue, 一つでも満たさないならfalse
ではMono上のC#ではどうなんだろうということで調べてみたところ、LINQを提供するSystem.Linq名前空間に高度な配列・辞書・集合操作を行うための拡張メソッドが用意されているということがわかりました。

http://docs.go-mono.com/?link=T%3aSystem.Linq.Queryable
http://msdn.microsoft.com/ja-jp/library/system.linq.queryable(v=vs.90).aspx

ということで早速使ってみます。



実行速度が高速なのかどうかはわからないのですが、なかなか面白いです。ラムダ式が使えるのもスマートで素敵ですね。うーん、C#好きになってきたかも。

Mono の System.String と string の違いについて調べてみた

MonoとかC#とか初心者なのでSystem.Stringとstringの違いがよくわからず、気になったので調べてみました。

以下のページのベストアンサーが一番わかり易かったです。
http://okwave.jp/qa/q7225655.html

ちょっと転載します。
string と System.String は型として使われる限り単なる別名なので同じものです。
foo.System.String みたいなものが用意されて foo 名前空間内から使うような場合は異なりますが,特殊例過ぎるのでこれは考えないものとします。
コンパイラは,ソース上の型として string と書かれているものは,System.String とかかれているものとして処理します。
# 正確には "System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" という型 (.NET 4 の場合)

これは,SDK 付属の逆アセンブラでコードを見ると,string を使っても System.String を使っても同じコードになることから確認できます。

同じように,int は System.Int32 の別名ですし,bool は System.Boolean の別名です。


使い分けは,特別決まりはありません。
唯一,メソッド名等に使う場合には言語固有の名称を避ける (CLR の名前を使う),というのはあります。
MSDN: 一般的な名前付け規則
http://msdn.microsoft.com/ja-jp/library/ms229045.aspx
具体的には,
・ToInt
よりも,
・ToInt32
の方が好ましい,ということです。
# 上側の名前付け規則だと,Visual Basic においては ToInteger であるべき,となる。


私は,static メソッドの呼び出しに使う場合は CLR の名前を使い,それ以外では言語固有の名称を使っています。
書籍によっては,常に CLR の名前を使うべき,という物もあったりします。
# が, for (Int32 i = 0; ……みたいなコードはほとんど見ません。

自分なりの物でいいので,統一したルールを用意しておくのがよいでしょう。
# 常に言語固有の名称でもよいと思います。

そもそも.NET Framework (とMono) は実装言語に依存しないような作りになっている (CLRというやつ?) のでこのような仕組みになっているようです。なるほど。 int, bool, string はC#の型で、 System.Int32, System.Boolean, System.String はCLRの型なわけですな。勉強になりました。

Unity でシステムが使用しているリソースを一覧表示したい

簡単なEditor拡張機能を書くときとか、デフォルトでUnityのエディタが使っている画像とか借りて表示したいときが多々あるんですが、これが実は公開されていなくてそのままでは使えないのです。ということでデフォルトでUnityのエディタが使っているリソース一覧を暴くスクリプトを用意してみました。



実行するとログに全てのリソースの一覧が表示されますので、あとはそれっぽい名前のやつを適当に拝借すればOKです。

自作の Unity Editor Script を github に公開してみた



最近は仕事の関係でUnityばっかり触っているのですが、中でも今お気に入りなのがEditor拡張機能です。これは自分で簡単なスクリプトを書くだけでUnityのエディタ上の表示を自由にカスタマイズできる機能なのですが、コイツの出来がなかなか素晴らしいのです。これまでいろんな開発環境を触ってきたのですが、ここまで簡単にエディタ上の表示を自在にカスタマイズできる環境は他に類がありません。

ということで調子に乗って自作のEditor拡張機能を書いて公開してみることにしました。まずは簡単なものからということで、シーン上に配置できる定規を作りました。


■機能
  • 原点からの距離(u)、高低差(u)、対象位置地面の水平方向傾き(度)を測定可能 ※1u=Unity上での長さの単位1とします
  • イメージを見ての通り全数値がエディタ上に表示されるので一目でわかる
  • Raycast飛ばしてるので確実に地面位置を基準にして判定してくれる、Raycastが外れても空中の座標がきちんと出る隙を生じぬ二段構え
  • 画面上の色/フォントを自由にインスペクタから変更可能
  • すべてEditorScript/Gizmoなので万が一何かの間違いでリリース版のシーンに残っていてもMesh Rendererが走って画面に表示されるという悲しい思いをしない
  • 操作は原点を選択してAdd Pointボタンを押して出てきた点を任意の位置に移動して配置するだけ
  • Clear Pointボタン付き
ひと通り基本的なのは揃えてみました。


次は高低差メッシュをTerrainの上に表示する機能とか作ってみたいっすね。

2012年5月4日金曜日

Unity の GUIStyle でデフォルトで指定できるスタイル一覧

今回は完全に自分用メモになってしまいますがご了承ください><

UnityのGUIStyleはname文字列を指定して生成する事が可能ですが、Unityがデフォルトで持っているGUIStyleの一覧を見つけたので列挙しておきます。
  • box
  • button
  • toggle
  • label
  • textField
  • textArea
  • window
  • horizontalSlider
  • horizontalSliderThumb
  • verticalSlider
  • verticalSliderThumb
  • horizontalScrollbar
  • horizontalScrollbarThumb
  • horizontalScrollbarLeftButton
  • horizontalScrollbarRightButton
  • verticalScrollbar
  • verticalScrollbarThumb
  • verticalScrollbarUpButton
  • verticalScrollbarDownButton
  • scrollView
大文字小文字は関係ないみたいです。たとえばboxのところをBoxと指定しても問題なくそのまま通ります。

参考URL: http://answers.unity3d.com/questions/9844/copypaste-guistyle-in-the-inspector.html
参考URL: http://unity3d.com/support/documentation/Components/gui-Customization

2012年4月22日日曜日

Unity Asset Serverを導入してみた

先日のiphone_dev_jp東京の勉強会での発表資料に書いた内容と同じなのですが、結局あの場では発表できませんでしたので、改めてUnity Asset Serverを触ってみた感想などを書いてみようかと思います。


■Unity Asset Serverって何?

Unity社が提供している、Unityのエディタと完全に統合されたバージョン管理システムです。
http://unity3d.com/unity/team/assetserver/
ソースコードだけではなく、プレファブやシーンを含めたUnityのプロジェクト全体のリソースを管理してくれます。Unityのエディタと統合されているため、Unityのエディタから一切外に出ることなくバージョン管理ができるというのが売りです。実はUnity Asset Serverは完全に普通のPostgresSQLのサーバーをそのまま利用しているだけになっていますので、SQLを経由してバージョン管理の履歴を操作したりも出来ます。


■Unity Asset Serverを使う理由は?

なんといっても以下の3つがUnity Asset Serverの魅力でしょう。
  • 導入するのが非常に簡単。サーバー側はインストーラーをぽちぽちするだけでWindows, Mac, Linuxどの環境でも一発です。クライアント側はUnityにそのまま付属されてくるためインストールなんぞ一切不要です。Team Licenseをアクティベーションしたらすぐに使えます。
  • 運用するのが非常に簡単。管理者側もユーザー側も、バージョン管理未経験の人でもUnityエディタのGUIを経由して誰でも簡単に使用することができます。
  • 動作がそこそこ高速。バックエンドがPostgresSQLなおかげだと思うのですが、LAN環境で最大10MB/s程度の速度でコミットしたりアップデートしたりできています。これはテクスチャや音楽、3Dモデルなどの巨大なバイナリファイルを大量に扱うゲーム開発においてはかなり重要です。

■でもお高いんでしょう?

はい。お一人様5万円となっております。

お一人様、5万円です。

マジです。

なかなかボッタクリ挑戦的な価格設定だと思います。


■よかったところ

実際に2ヶ月間ほど運用してみてよかったところはこんな感じです。
  • だれでも超簡単に使えます。とにかく超簡単。これはプログラムなんて全くわからないデザイナーさんや、バージョン管理未経験の人、はたまた入社2日目の人でもなんの問題もなく使えている事実から裏付けされています。Asset Server導入前はgitを使っていたのですが、GUIクライアント付きでもトラブルだらけの毎日でした。これがAsset Serverになるやいなや全く教育もトラブルシュートもしないまま一日80コミット以上をコンスタントに記録するような素晴らしいバージョン管理体制が構築できたのです。
  • Unityのプロジェクトをバージョン管理するとき固有で発生するトラブルが一切ありません。まぁ具体的には先日書いた記事の通り、metaファイルなんですけど。前にも書きましたが、とにかくトラブルが発生しづらいです。簡単で単純なので。

■いけてないところ

さてもちろん良いところがあれば悪いところもあるわけで。以下のような点が問題点としてあげられます。
  • 高い
  • 高い
  • 高い
  • 高い
  • バージョン管理に必須とも言える機能が大幅に欠落しています。Subversion以下程度の機能しかありません。
  • 具体的にはブランチがない、タグがない、外部ツールがないのでJenkinsみたいないUnity以外から触ろうとすると超面倒くさいかPostgreSQLに直接SQL発行するしかない、基本コミットとアップデートとlog見てrevertするぐらいしかできることがないです。
  • みんなが一番期待するであろう、シーンやプレファブのマージですが、出来ません。一切できません。したがって作業範囲が衝突した時のトラブルはSubversionやgitと何ら変わりません。むしろスクリプトのマージを自動解決してくれるぶん、gitやhgのほうが優れています。
  • Unityのプロジェクト固有の問題は一切ないのですが、一般的なバージョン管理システム的にありえないバグが時々(週に1度程度)発生します。
  • 具体的にはファイルを変更したのに変更差分が認識されない(特にスクリプトを外部ツールでマージした際に顕著に発生)、updateしたのにローカルのファイルが古いまま、Historyから復元しようとしたら復元元のディレクトリが無いとか言われて復元できなくて死亡して愚痴愚痴愚痴愚痴愚痴...
  • 大人数で使うことを開発元が想定していないフシが多々あって、一番わかり易い例が最大同時接続数。これ最初の設定だと20人が限界です。PostgresのデフォルトがTCP接続40本までで、Asset Server Clientは1クライアントあたり2本TCPを貼るので。更に悪いことにこの設定を変更するにはPostgresSQLの設定ファイルを自分で操作する必要があります。簡単だからという理由で導入してここで躓いたチームは地獄を見る(むしろほぼ解決不可能になる)ことになります。
  • ところどころ完成度の低い機能があったりします。例えば既存リポジトリのコピーが可能なんですが、誰か一人でもどこかのリポジトリにクライアントが接続していたらコピーが出来ないと言われてしまいます。・・・えーと、全員帰った後にコピーしてくださいってことでしょうか><

■結論

Unity Asset Serverは、状況次第では非常に強力な選択肢になりえます。例えばチームメンバーのほとんどがバージョン管理システムを使ったことがないとか、グラフィックやサウンド担当の人が多くて彼らがSubversionやgitを覚えるのは不可能というとき、社内でSubversionやgitのサーバーを運用するノウハウがない少人数のチームのとき。こういう時にはAsset Serverの導入しさえすれば誰でも使える簡単さが大いに役立ちます。

しかしながらこの内容で1ユーザー5万円という値段はどう考えても暴利と言わざるを得ません。またできることが浅く、機能が少なすぎる弊害が簡単さによる生産性向上度をだんだん上回っていきます。とくにJenkinsと組み合わせる際の相性の悪さが辛いです。シーンやプレファブのマージができるのであればまだ5万円の価値はあったのですが・・・ということで、すでに他のバージョン管理システムを使えているチームでしたら、ぶっちゃけそのバージョン管理システムを使ったほうが良いと思います。


■こぼれ話

Unity Asia Bootcamp Tour東京で聞いた話など。まずGREE(というか@splhackさんの部署)はバージョン管理にgithubを使っているそうです。gitでは無理だと思っていたのですが、チーム全体の習熟度が高ければ問題なく回せるものなのかと感動しました。それからUnity Japanの大前さんにUnity Asset Serverに関する不満を申し上げたところ、やはりUnity側でもそのあたりは問題点として認識されているとのことでした。改善に期待するしかないですね><

2012年4月15日日曜日

iphone_dev_jp 東京iPhone/Mac勉強会でしゃべってきた & 反省

昨日開催されましたiphone_dev_jp 東京iPhone/Mac勉強会で1セッションほどお話しさせて頂きました。
http://atnd.org/events/26946

当日の様子がニコ生で配信されていて、現在タイムシフトで視聴することができます。一週間視聴できるので、4/20までですかね。
http://live.nicovideo.jp/watch/lv88663921

このタイムシフト視聴であとから録画されたプレゼンが見られるというのが実に素晴らしくて、具体的には以下のようなご利益があるわけです。
  • 遠隔地の人(今回は大阪の人)が同時に勉強会に参加できる
  • 参加できなかった人があとから当日の雰囲気を見るのに使える
  • 発表者があとから自分のプレゼンを見て反省するのに使える
主催していただいた岸川さん、機材を準備していただいたshachiさんをはじめ運営の方々、ありがとうございます!この仕組が他の勉強会でも流行ればなぁとか思ってます。(自分で主催する気がなくてすんません><)

さてここからは反省会です。タイムシフトのお陰で普段できない「自分のプレゼンはどんな具合だったか」をあとから客観的に見直すことができるので、これは大いに捗るぞと思いちょっと見てみました。2時間30分ちょいぐらいから出てくる一番煩いのが私なのですが。

うん。これはひどい><
ともかく、悪かったところとまぁ良かったんじゃないってところを列挙してみます。
  • 喋るの早すぎ。テンションが上がると更に早くなって困る。
  • 落ち着きなさすぎ。動きがなさすぎるのもつまらないので動くの自体は良いと思っているけれども、動きに変な癖があってそれが煩い。
  • プレゼンの資料で前提知識というか説明が抜け落ちている箇所が多々ある。急ぎで作ったBlocksの資料とかが顕著で、なぜ最初にアプリをクラッシュさせてるのとか説明がない。唐突すぎる。
  • 超テンションで超フランクにやったおかげかツッコミがいただけた、ネタ議論っぽくなったのはすごく良かった。だが、うまく広げられてないのがもったいない。テンパりすぎ。
逆にプレゼンが非常にうまかったsonsonさんやfladdictさんのプレゼンを見て、自分のプレゼンと比較して気づいたところを列挙してみます。
  • 発表に安心感というか安定感というか落ち着きがある。このあたりは場慣れしていきたい。
  • 図の使い方、図による説明の仕方が上手い。直前まで作っていたとか手書きで仕上げたのはやっぱダメですね><
  • デモの回数・実施方法が適切。最もキモとなる1回か2回程度に抑え、あまり資料から離れないため、流れが中断されない。ちょっと自分のプレゼンはコードとデモに逃げすぎたため流れが悪くなっていた。必要であればコードは資料の方に書いておいて流れを切らないようにする(要するに手抜き資料を作ってはならない)

あとはこれを踏まえてどんどん場数を踏んで上達していきたいですね。ということでiOSの勉強会とかで発表者募集している方がいらっしゃいましたら是非宜しければ喋らせてください!