zillionプロジェクト開発ブログ soliloquy 忍者ブログ

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

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

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

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

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

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

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

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

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

拍手[0回]

PR

 3月11日の技術的な会議を経て、それ以降開発を開始する予定となっています。
会議の内容としては、3Dの交換フォーマットに何を採用するか(現状、COLLADAが有力)。
あとは、クラス関係の設計でしょうか。どのような決まりの中で作っていくかというのはオブジェクト指向においての開発で非常に重要で、後々使いにくくなって作り直しなんてのはよくある話です。

さて、今後の予定ですが、とりあえずある程度の形ができるまでを第一期、形が見えてきた後の開発を第二期、完成が見えてきたころの開発を第三期とします。


第一期中は、今日から18日まで以降は募集はしません。これは、プロジェクトの基礎となる部分を設計するにあたって、新人が入ってきてしまうと、構造がわかりにくく、教える手間などが出てきてしまうためです。
第一期は、形の見えるまでの設計、そしてドキュメントの充実これが目標です。

その後、第二期のプログラマーを募集する予定です。このころにはアプリケーションの指針が見えているので、より大きくこのプロジェクトの存在を知らせることができます。
ある意味でこの時点でスタートといえます。

第三期では、さらにβテスター、HPデザイナーやヘルプの作成者など、クライアント層のドキュメントなどを編集したりする人を募集します。
あらを捜し、ヘルプファイルなどを充実化させるのが目的です。


現在は、11日からPre第一期であり、18日からPre第一期の反省をもとに開発を進めます。全然進んでいないことが目に見えます。
7回作り直しているので、もう作り直しは最小限にとどめるこれが、大事です。
そのためのドキュメントの充実です。

さて、11日から第一期開発を開始しようと踏んでいるのですが、あと数名プログラマーがほしいところです。
今回は残念ながら、すべての人とは言いません。開発が本格的に始まればプロジェクト内に教える余裕がないからです。

そこで、以下の既定にあう人のみ募集します。18日まででこの募集は締切させていただきます。



[1]C#プログラマー
【内容】アプリケーションのメインの部分を作成します。

【基準】ある程度のC#がわかる人

特にUI周りが得意な人、プラグインアプリケーションの開発に携わったことのある人が望ましいですが、
C#が読める、書けるのであれば問題はありません。

[2]Pythonプログラマー
【内容】サーバー(GAE)用のプログラムを作成します。

【基準】Pythonが書ける、読める人。

特にGAE周りの開発をしたことのある方が望ましいですが、Pythonが読める、書けるなら問題はないです。
なお、チーム内にPythonを書ける人はいますが、僕はわかりません。(今後勉強します・・・)

[3]ドキュメント編集者
【内容】チーム内のドキュメントを保守。編集します。

【基準】Open Ofice Orgを駆使し、ドキュメントを作成できる人。ある程度のコンピューターの知識がある人。

以上の基準においての募集です。
この基準を満たす参加希望の方は、以下のどれかの方法でコンタクトをとってください。
①、メール(zeoniccharkyasbal★yahoo.co.jp ★を@に変えてください。)

②、skypeで直接コンタクト。(Skype ID:lime_streem)

③、ブログのコメント(メールアドレスの欄に自分のメアドを書いて入れてください。なお、メアドは管理人のみ見ることが可能です。)

あと、twitterやってます、開発時にいろいろつぶやいたりするので是非フォローしてください。

http://twitter.com/#!/kyasbal_1994

拍手[0回]

[kyasbal]



試験が近くなってきたので、しばらく作業できません。
来週末から再開します。

ところで、基底となるサンプルプロジェクト作りました。
今回、サンプルプロジェクトを作成して、主に今後議論すべきだと思った項目は、
・ドッキングウィンドウの使用するライブラリ
・スクリプトに使用する言語
・UI構築用のスクリプトに使用する言語1つ

あたりでしょうか、僕自身、C++プログラムばっかやっていたので、C#にはそこまで詳しいわけではないですが、基本的には、完全なオブジェクト指向 になっただけ、と解釈したらいいので、そこまで難しいものではありませんでした。

最も、.Net FrameWorkの構造自体が、つかむのが難しいという現実もありますが、ライブラリのクラスなどは、覚えたところで意味がないので、linqなんか、使えるようになっていきたいと思います。(可読性が下がるので、チーム内で利用するかどうかは別として)

拍手[0回]


今頃ながら抱負です。
プロジェクトのドキュメント書いている段階ですけど、期日と目標を自分(メンバーも!)に課すというのは大事なことです。
なので、ちょっとここに書きます。

3月末
基本的な仕様書全部書き上げる (僕の課題)
 メンバーのプログラム講座全部終わらす。
担当者分け。それぞれが詳細仕様書を書く。
4月中
構想をまとめたPVを発表。
再度作成開始。(事実上のやっとのプロジェクトスタート)

と、言うわけですが・・・
文章にしてみても仕様書というのはなかなか伝わらない物。なんですね。
とりあえずは今1次のメンバー内で校閲(?)をして、不足分などを補う作業をしています。




拍手[2回]

App-008.png



[kyasbal]





やはり、以前と同じくアプリケーションの設計不足と言ったところか、いろんな構造上の欠陥が・・・
仕様書なんて2,3枚しかなかったのは論外だと、設計を学んで思いました。
もう一度仕様を書き直し、使えるコードを使いまわす、そんな感じでやっていこうかと思っている中、やっぱり.Netを使用すべきだという意見が多数。

僕自身、.Netの知識は、少なく、だったらマネージコードにすれば・・・とか簡単にできるものと考えていました。
しかし、全然違う!

やはり、設計は大事!とはいえ、抽象すぎて、仕様書に具体化できないんです。


そんなわけで、基底部分の設計は、そういうのが得意そうな人に任せたわけで、C#において電子署名クラスを作成しました。

ところで、電子署名って何か知っていますか?

AIRをいじったことのある人やPDFのちょっと奥深い機能を使えば、電子署名ってのがあると思います。
さて、電子署名というのは、その人が本当に作られたものか、その人からクライアントにそのファイルが渡る前に第三者によって改変されていないかをチェックするものです。

もちろん、改変されていれば、ウイルスなどという可能性もあるので、これはチェックすべきです。

では、どうやってチェックしているのでしょう?

RSA暗号化というものを利用します。

まず、ファイル自身からハッシュ値を計算します。

ハッシュ値とは、短い文字列で、ファイルの中身が1文字でも違えば、別の値になるという特徴があります。

[http://itpro.nikkeibp.co.jp/article/COLUMN/20060628/241960/]
MD5やSHA-1,SHA-512などいろいろなアルゴリズムによって、ファイルからハッシュ値を取得します。
つまり、このハッシュ値をあらかじめ記憶しておいて、起動時にファイルのハッシュ値を再度計算、このファイルと異なる場合、途中の経路で改変が行われたことがわかります。




しかし、もともとのハッシュ値をそのまま保存していたら、そのハッシュ値をファイルの改変後のものにすり替えられたら元も子もありません。




そこで、RSA暗号化をはじめとする、公開鍵方式の暗号化を使用します。
公開鍵方式の暗号化は、秘密鍵、公開鍵の2によって成り立ちます。

いきなりですが、1553179961を素因数分解してください。
.........
.....
...
..
無理ですね。
ちなみに17807*87223に分解できます。
じゃあ、85を素因数分解してください。
......
....
...
17*5に分解できます。
じゃあ、なんでそうだと言い切れますか?どうして17*5だと分かったのでしょう?
このように、勘で素因数分解しているだけであって、大きな数の素因数分解をさせるアルゴリズムは存在しないのです。
これを利用して、秘密鍵(素数)から、公開鍵(素数*素数の数)を生成します。
こうすると、不思議なことに、秘密鍵で暗号化したファイルは公開鍵で複合できますが、同じように公開鍵では暗号化できないのです。

あえて、公開鍵を公開します。
作者は、ハッシュ値を秘密鍵を使用して暗号化し、同梱します。公開鍵を使用して、複合化を試みます。
公開鍵は対応した秘密鍵で暗号化したものでしか複合化できないので、つまり、正常に複合化できれば作者しか知らない秘密鍵で作成された暗号だということが保障されます。

ハッシュ値を改竄するには、この秘密鍵がなければ無理です。
では、このRSA暗号化ですが、どれほどの強度があるのでしょう?

映画「サマーウォーズ」の主人公、健二が解いた暗号化は、劇中でShorの因数分解アルゴリズムの本を読んでいたことから、因数分解に関係した暗号化、つまりRSAであったと予想されます。
solve me!というタイトルで送られてきたメールは2056桁の公開鍵だと思われます。
つまり、これは2056桁の秘密鍵*秘密鍵で作成されたものであり、素因数分解をすることで、これを解くことができます。
これを、2.2Ghzのノイマン型コンピューターに解かすと、1000,000,000,000,000,000,000,000,000,000,000,000,000年(1の後に0が39個)がかかることになります。
手計算で1夜で解いてしまうなんてなんて頭がいいんでしょうか。(笑)
ペンタゴンは、侘助を引き抜いたが、多分健二のほうを引き抜くべきだったのではないだろうか。

最も、量子コンピューターが完成したら、こんなもの、数時間で解いてしまうと言われていますが・・・
RSAは世界中の暗号化でかなりよく利用されています。
そんなことになったら・・・世界中大混乱でしょうね。




拍手[0回]

◎ カウンター
◎ カレンダー
04 2024/05 06
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
◎ 最新CM
[10/24 名無しの権兵衛]
[08/30 名無しの権兵衛]
[08/14 no name no future]
[08/05 ゲームサークルEaSt]
[07/28 リオウ]
◎ プロフィール
HN:
solilpquy
年齢:
29
性別:
男性
誕生日:
1994/09/22
職業:
人間
趣味:
趣味ねぇ~~う~ん・・・
◎ ブログ内検索
◎ バーコード
◎ アクセス解析
◎ フリーエリア
◎ フリーエリア
Script: Ninja Blog 
Design by: タイムカプセル
忍者ブログ 
[PR]