500MBの無料オンラインストレージ「Windows Live Folders」日本語版今夏開始予定

ここのＧＩＧＡＺＩＮＥの記事
500MBの無料オンラインストレージ「Windows Live Folders」日本語版今夏開始予定
http://gigazine.net/index.php?/news/comments/20070628_windows_live_folders/

によると（以下斜体は上記サイトより引用）


マイクロソフトの無料オンラインストレージサービス「Windows Live Folders」が今年の夏にはベータ版から正式版になるそうです。

既に日本語版も入り口だけは用意されており、使用できる全容量は500MB。1ファイル当たりの最大サイズは50MBで、Windows Live IDを持っていないユーザーに公開することもできます。そのため、仕事で大きなサイズのファイルを渡す際に便利かも。


会社はもちろん、個人利用でも、USBメモリを持ち歩かないでいいというメリットはアル？？

ウィリアムのいたずらの場合、ここで作ったプログラム（いま、makebrewしかないけど）
なんかを、パブリック フォルダでみんなに公開できるかなあ？って思ってます
ここの文章

パブリック フォルダは、インターネット上のすべてのユーザーがアクセスすることが可能。ただし編集などは不可能。各フォルダとファイルには、それぞれウェブアドレスが割り当てられるので、そのリンクを送信するだけで、他のユーザーにファイルを公開することができるという仕組み。

を読むと。。。
そーすると、いま、＜　＞　￥　を全角にしてるけど、ちゃんとした
ソースをそこにおけるので、いいなあ・・・

ということで、ちょっと注目しています。

一般的な編集ソフトの作り方 その２４：まとめなど。。。

ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　ここでは、主に、

　　・メモリ上に、要素をもつ
　　・イベント発生時の動き
　　・画面の構成

ということで、今まで書いてきました。
　今日は今までのまとめと、触れていなかった、バッチ、コピーなどです。

---

■いままでのまとめ

　大きな流れは、

・画面でイベントが起こると、共有メモリを利用して、イベントを通知するメイン画面を
　探し出し、そこへ通知、さらに、データを変更する必要があれば、データを処理する
　モデル部分のメソッドを呼び出し

・モデル部分では「イベント発生時の動き」に書いたような、
　　　　・印刷
　　　　・保存
　　　　・読み込み
　　　　・カット（切り取り）
　　　　・ペースト（貼り込み）
　　　　・プロパティ（属性設定・変更）
　　　　・表示
　　　　・要素の選択
　　　　・（要素の）移動
　処理があって、それぞれの処理をおこなう。

・その際、データはそれぞれの型に応じて、
　　　　・挿入
　　　　・削除
　　　　・位置変更
　　　　・表示
　などの処理が記述してあり、モデルからの指示で、それぞれの処理を行う。

・その結果、再表示が必要なら、再表示などを行う

という流れでした。そして、それぞれの処理については、今まで書いてきました。

---

■バッチ

　で、ＤＴＰソフトの中には、バッチ処理ができるモノがあります。
　これは、画面表示をせずに、モデル部分を動かすものになります。

---

■コピー

　コピーは、
　　　・データ部分のメモリを保持し、それを挿入削除する
　　　・コマンドの形にしてしまい、それを実行する
　など、さまざまです。
　（デザインパターンでも、こー言うのがあった気がするが。。。）

　この保持の仕方によっては、「元に戻す」をしたときに、どこまで戻るかの
差になったり。。。するのかな（＾＾；）

---

っていうことで、このシリーズはいったんおしまいです。
もしかしたら、連結リストの形でのソース（前に示したのは配列・ベクター型だったので）
とかも示すかもしれない（しめさないかもしれない）けど、ま、とりあえず、このシリーズ
は、いったんここまでです（＾＾）ｖ

プロセス中心に画面割りした場合の、仕様変更による修正とマスタ保守抜け

　前に、プロセス中心に画面割りすると、オブジェクト中心にやるより、画面数が膨大に増えるという話題を書いたけど、それ以外のプロセス中心に画面割したときの問題について。

　プロセス中心、つまり、申請書作成とか、申請書編集、申請書削除などの、１業務で１画面で持ってしまった場合、画面は、その業務に必要な変数をもつことになる。
　したがってここで、申請書の項目が増えた、減ったなど、オブジェクト（＝申請書などの”もの”）の項目が変更になった場合、そのものを入力、出力にもつ、すべてのプロセスの画面を修正しないといけない。
　これは、修正量が多い

　まあ、もともと、前の話で、画面が増えると書いたのだから、修正が増えるのは、当然なのだが。。

---

　さらに、DOAが出てきた背景を考えると、データ構造以上に、プロセス、つまり業務というのは、変わりやすいということだった。

　まあ、本当にそうかどうかは？だけど、仮にそうだとすると、プロセスごとに画面割をしていると、変わりやすいっていうことになる。

---

　さらに、大きな問題になりそうなのは、マスタ関係の機能が抜ける危険があることかも。。

　クラス図で書いて行き、そのメソッドを元に、画面のアクションを作っていく場合、クラス図上に、CRUD（作成・検索・編集・削除）に相当する、ぞれぞれのメソッドがあるかないかチェックし、なかったら、付け足す。
　したがって、クラス図上にあるマスタにたいしても、保守機能は入る。

　しかし、業務プロセスごとに画面を作る場合を考えると、その業務プロセスは、要求から来る。要求は、基本的に、業務に関することしか出てこない。

　しかし、マスタファイル、マスタテーブルというのは、業務を行う前から存在しているファイル、テーブルをさすのが普通。ということは、業務のヒアリングにおいては、すでにあるものとして思われていて、それを作成する方法や画面については、一切考えていない可能性がある。

　そうすると、ヒアリングした業務プロセスを元に画面を作ると・・・
　マスタ保守関連が、ごっそり抜ける危険がある。

---

　いや、そーいう人がいたので、今回書いてみた。
（ウィリアムのいたずらではないよ。ウィリアムのいたずらは、たいてい、オブジェクトを下に画面割するので。。）

軍事利用して、ロボットがロボットに教える軍隊作ったら、すごいかも！

いやー、前田（みんみん）アナのトレンドたまごもすごいです。

ロボットが、動作も学習できるそうです。
TTF:2,092 どんどん賢くなる[07/6/27]
http://www.tv-tokyo.co.jp/wbs/toretama/070627.html

こうなってくると、軍事利用も考えられますよね。
ロボットが射撃隊になって、一斉射撃とか、海岸線を警備とか・・
ロボットなので、防弾チョッキ・・・というよりか、ロボット自体を強く作る？
それに、人とちがって、壊れても、大きく壊れなければ、修理できるし、
戦車などで、ロボットを破壊しても、こんどはその破壊されたロボットが
障害物となって行く手を阻み・・・

うーん、ロボットの軍隊、なかなか手ごわそうです。

---

きっと、そうなってくると、ロボットがロボットを教えることになるのかもしれません。

　まず、人間が教えて教育用ロボットを作り、
　（ここでは、仮に、ビリーという名前にしましょう）
　その教育用ロボット・ビリーが、他のロボットを教えると・・・

　こうなってくると、ロボットのビリーは２４時間教え続けることも
　可能だから・・すごい量のロボットを教育でき、ものすごい量の
　（ロボット隊員による）軍隊を作ることも可能になってくる・・

---

そう、賢明な読者には、気が付かれたかもしれませんが、
ビリーを使って、ブートストラップ式に軍隊（キャンプ）を作っていく、

まさに、

　ビリーズブートキャンプ

って、そーいうオチかい（＾＾；）

プロセス中心に画面割りすると、オブジェクト中心にやるより、画面数が膨大に増える

　画面割りについて。

　以前ここに書いたときは、画面割りは、主語、目的語というもの＝オブジェクトをベースに画面にして、その画面に対して、動詞部分のアクションをボタン等のイベントに対応させて、配置している。

　この方法とは別に、業務、プロセスを中心に画面を立てることもできる。
　　　申請書削除で１画面
　　　申請書作成で１画面
　　　申請書編集で１画面
　　　申請書検索で１画面
　といった具合だ。

　（前に書いた、オブジェクトベースだと、申請書一覧と詳細の２画面。一覧側に削除、新規作成、編集、一覧の上に検索部分があり、検索実行ボタンが横にあり、詳細画面に、登録ボタンがある。どちらの画面にも「戻る」ボタンがある）。

　で、どっちがいいとか、そーいうのは思想的問題になるので、別にいいんだけど、
　ただ、プロセス中心に画面割りをすると、画面数は膨大になる。

　たとえば、上記の場合、申請書が１０種類あったとしたら、その１０種類に対して、ＣＲＵＤ（作成、検索、編集、削除）と４０画面作ることになる。

　オブジェクトベースで考えると、申請書という画面から、個々の画面が派生しているといえる。
　この場合、申請書一覧は１画面にして、コンボボックス(selectのサイズ＝１）で申請書を切り替えて表示させることもできそう。さすがに個々の詳細画面は必要そうだけど。。

　そうすると、一覧画面＋詳細１０個＝１１画面と、２９画面もこの時点で少ない。

　それだけではなく、ＣＲＵＤの機能は一覧画面側についているので、新規に申請書を追加されても、詳細を作って登録するくらいなのに対し、プロセス中心だと、４画面作んないといけない。
　そして、画面数が多いと、適当にメニューを途中に入れてあげないと、わけわかんなくなるので、メニューも必要になる。

　という違いはある。

　他に、もっと大きな違いがあるのだが、話が変わるので、とりあえず、ここできります。