で、昨日の問題。
ソフト開発は、必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数なので、
・画面開発者の単価を減らし
・画面と操作部分を完璧に分離し、操作部分をバッチに落とし込めば
価格は安くなることになる。
このとき
サーバー クライアント
・ＧＥＴまたはＰＯＳＴで引数を受け取り
セッションの引数とあわせて（共通関数で） ・画面操作、処理をflashで行い
・ＤＢ操作処理 ←→ ・サーバーをflashから呼び出し、
・結果をセッションに入れたり ・受け取ったＸＭＬをもとに
ＸＭＬで返す（共通関数にセット） 画面表示させる
とすると、クライアント側はＦｌａｓｈ処理のみとなり（ブラウザからflashのウィジェットを呼び出すにしても）、サーバーは、ＤＢ操作だけのほぼバッチ処理となる。
そして、Flash処理は、デザイナーでできるし、デザイナーの単価は安い。
で、さらに・・・ということで、話は終わっていた。
で、さらに、サーバー側を考えると、
・データチェック
・存在チェックとか、ＤＢアクセスが必要なもの
・ＤＢ操作
・値入出力
が主な仕事になる。
上記の記述は業務に関係ない（受注とか、給与とか、販売とかの言葉が入ってないことから分かるように）
ということは、
ツール化できる。
つまり、
・どっかのプロバイダがＤＢを提供し、（ロリポップはMySQLが使えるようになっているように）
・そのＤＢの操作サービスを提供して、
そのサービスでは、ＤＢにテーブルが作成できて、
テーブル操作用のサーバーアプリ（ＲＥＳＴ型の）が作れるようにする
・アプリの内容は、ＤＢ操作、値チェックなどなど
・作ったサービスを一般の人がアクセスできるようにする
認証は、ＳＳＯで、ＯｐｅｎＩＤとか使ってかな？
ってすると、
サーバー側プログラムは、そのツールを使って、（ＲＥＳＴ型、出力はＸＭＬ）サービスを作ってしまって、
あとは、画面側を作ればよいだけになる。
現時点では、画面とＤＢ操作が分離されていない（Ｓｔｒｕｔｓでは、ＪＳＰ内にタグづけをしないといけないし、ＰＨＰは、ＤＢアクセスのためのソースを書かないといけない）
しかし、上記のように、クライアントはＡＪＡＸまたはＦｌａｓｈとすると、クライアントとサーバーが完全に分離して、その上、サーバー側はバッチ処理になり、バッチ処理はだいたいやることが決まっているため、それをツール化できてしまうっていう、ストーリーなわけだ・・・
そして、もっと悪いことがある。
クライアント側も、あるプログラム（それも、多分、経験１～２年の人ですらかけてしまう）を作ると、クライアント側もバッチレベルに落としこめる可能性があるのだ。
そのプログラムについては、またこんど
アクセス
トータル
ランキング
