zillionプロジェクト開発ブログ

[Kyasbal}

プロジェクト名の変更をすることになりました。決して制作物の内容が変わるわけではないことを注意してください。
名前が変わっただけです。変更の理由は、システム名が決まっていない、グループ名も有ってないようなものになっている。以上の事から、以下のように決まりました。

システム名：zillion　【由来】このシステムを使って無数の人々が分かり合えるようになるという願いから

プロジェクト名：zilionプロジェクト

グループ名：soliloquy 【由来】「『すべて世界のため』そんなこと言って『自分の行動が本当に役立ってる？』そうやって自分に問う、そんな不器用な様子を表したもの」

名前が変わっただけですが、今後ともより一層プロジェクトの繁栄に尽力していきたいと思います。よろしくお願いします。

[1回]

[Kyasbal]
http://www.m-tea.info/2011/02/kinectc-2.html
C++でOpenNIを操作するプログラムを書いたがうまくいかなかった。というのも、スレッドの処理に戸惑ったせいで、描画がおかしくなってしまったのだ、でも、C#だったらトラックバック先のようにかなり簡単に組むことができるみたい。
こりゃあKinect扱うの楽そうでいいな。

ちょっと実験してみようかな。

さて、プラグイン周辺の機能を実装しました、とりあえずチームメンバーとコードレビューを以下のように済ましました。
・重篤なバグ 2
＊終了時に不明な例外が起きるバグ
＊勝手にウィンドウの色が変わる(カラフルで良い！？） 

・仕様とも取れるようなバグ　1
＊アプリケーションコンソールのウィンドウを非表示してから表示すると、キャッシュがすべて消える。再描画に時間がかかるので、これはこれでもいいかもしれない。

・リファクタリング　18
名前の修正や、小規模な構造の変更など。

[2回]

 








[Kyasbal]

本来であれば、そろそろ、一度プロジェクトをリセットし、今までアプリケーションテスト期間でよくない部分を作り直すという計画だったのですが、案外小規模な改善点が上がっただけなので、このまま開発がすすめられそうです。

少々、ファイルシステム周りの例外処理（ファイルがない！フォルダがない！等考えられる様々な想定外の出来事に対応すること）が弱いようで、一つの改善点になったこと。

フォルダ階層分けがバラバラになっているのを修正しようという事。

その程度でしょうか、多少汚いソースがありメンテナンスに苦労しそうな部分は毎回後からリファクタリング（動作は変えずに読みやすいよう、汎用性に優れたものに書き換えること）しているので、一貫した品質のコードができているようにも見えます。

仕様書のほうも、大分固定化されてきたようにも見えます。プラグイン周辺の仕様書ができて、残りのちょっとした機能さえもプラグインで実装していく予定なので、そこらの仕様書が必要でしょうか。
実際に作成するときの処理などの大きな単位での仕様書が必要でしょう。

どちらにせよ、アプリケーションレベルでの仕様書という点で見ればそれなりにまとまってきているようにも見えます。
オープンソースプロジェクトなので、できる限りこのような仕様書も公開していきますが、やっていることを明確化することでより一層入ってくれる人が増えるといいと思っています。

[0回]

[kyasbal]
世間では地震がありましたが、プロジェクトメンバーは全員無事のようです。(東北在住の人もいますが・・）
地震での被災者は日々上昇しており、痛ましい出来事ではありますが、ニュースを見て世間話をチーム内でしていたところで、被災者を救えるわけではありません。であるならば、私たちは普段通りプロジェクトを進めるのみです。
興味を持たな過ぎるのはよくはありませんが、だからといってこのプロジェクトを一時停止する予定はありません。

---

今までC++を使ってきたのにC#を最近使い始めたのですが、やはり便利です。
C++に比べると開発速度の短縮がかなり見えます。
とはいえ、今までC++を使用していたからこそ、C#の文法が早く理解できるわけですが、実行速度のほうも、今のところ特に目立ってる場所はありません。

なお、プロジェクト内の会議で、対応する環境の前提条件が決まりました。
・.Net FrameWork 4.0がインストールされているPC(Client Profile ではありません。)
・解像度　1024*768以上の画面を有するPC(これ以下だとUIがはみ出る可能性があります。)
・OS Windows Vista SP1以降。(XPは切り捨てる方向の話で進みました。)
・グラフィックボード　GTX型番もしくはGT型番のグラフィックボード
(nvidia製を前提としたのは物理衝突演算にPhysXの使用を前提としたためです。正確な性能については、完成後でなければ計れません。)


以上の条件を満たすというのが、前提です。環境については、将来的に基準を上げる可能性があります。

また、前回の会議で、対応するファイルフォーマットも決まりました。
ただし、このフォーマットはモデルのエクスポート、インポートに使うためのファイルフォーマットで、プラグインで簡単に拡張できるように設計します。
COLLADA 1.5 format
SCEが提唱したフォーマットで、3Dモデリングソフトなどのファイル交換方式として一般化されつつある方式です。




 

[0回]

[Kyasbal]
全部が全部、機能をこちらで実装するのは無理だと思われるので、アドイン(プラグイン、アドオンなどとも言われる・・)機能を実装しようと思うのです。

さて、アドイン機能は後回しでいいかといわれると、どうでしょう、インターフェースを準備するのが大変ですから、忘れたころに『ここをアドイン対応にしよう』なんて言ったとき、『あれ、ここ何の処理してたっけ？』なんてことにならないかが不安です。

そのための仕様書なのですが・・・

さて、.Net FrameWork4.0+C#4.0 で開発する際に、アドイン開発として取れる可能性は２つ。
①リフレクションを使った実装。
②System.Addin名前空間内のクラスを使用した実装。

前者は、かなり実装がしやすいです。C#のほうの経験がそこまで深くない僕でもなんでこのコードになるのか、わかって実装できます。
しかし、後者は正直難しいです。１種類のアドインに５つのアセンブリが必要になります。(ここでのアセンブリとはC#でいうアセンブリの事です。)増して、いろんな警告が出たりとかして、もうわけわかんない。そんな感じになるわけです。

それでも、②には非常に大きな利点があって、アプリケーションドメインが分離できるという利点を持ちます。
それはつまり、わかりやすく言えば、アドインに悪意のあるプログラムを作り、アプリケーションをフリーズさせるというアドインがあった時、アプリケーションドメインの分離がされているので、フリーズするのは結局そのアドイン側となるのです。

プラグイン機能を作れば、当然そこからの脆弱性を考えなければいけません。
しかしながら、System.Addinを使用すれば少しはその危険は少なくなります。(最も公開するインターフェースにかなり左右されますが)

いずれにせよよく考えなければいけない項目です。
もう少し考えて実装してみます。

[0回]