mixiが招待なくても登録可能に

ここのニュース
mixiが招待なくても登録可能に　年齢制限も引き下げ　プラットフォーム開放へ
http://headlines.yahoo.co.jp/hl?a=20081127-00000018-oric-ent
によると（以下斜体は上記サイトより引用）


ミクシィは27日（木）、現在18歳以上からの利用となっているソーシャル・ネットワーキングサービス（SNS）サイト『mixi』の年齢制限を12月10日より15歳以上に引き下げ、また登録者からの招待状がないと利用できない「完全招待制」を2009年春に撤廃し、招待なしでの新規登録も可能にすることを発表した。


招待無しでＯＫなら、普通のブログとかと（まあ、アカウント登録はあるかもしれんが）
大して違わない気が・・・

ユーザー拡大しようとして、ＳＮＳビジネスの本質が崩壊してきたような気がするのは、
ウィリアムのいたずらだけ？

サーバーをＲＥＳＴ型のバッチにして、画面をFlashにされると、価格崩壊が起きる

　今、クラウドとかいうと、なんか先のお話みたいに受け取ってくれているので、
　まあ、この業界的に助かっているところがあるけど・・・

　もし、クラウドから発展して考えて、ユーザー企業が

　　サーバーをＲＥＳＴ型のバッチにして、画面をFlashにされると、

とんでもない、価格崩壊が起きるんで、やばいんだよね。

　これだと、別に（発想のもとはクラウドでも）、クラウド関係無しに今でも出来るし・・

---

日本情報システム・ユーザー協会（JUAS）は、工数見積もりを出していて、平均的な工数は、

必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数

としている。画面に掛ける係数は、1.2や0.97とかも見たことがあるかもしれない。
バッチは0.3程度かな・・・年によって違うのかしら・・・

つまり、ここからいえることは

・画面数を減らし、バッチ数を増やしたほうが、工数は大幅に小さくなる
・仮に画面担当者の人月単価が下がれば、開発費用は大きく下がる
　　　→ツールを使って、新人でも・・・

ということだ。そして

・ＳＥ、プログラマより、Webデザイナーのほうが、単価がかなり安い

という事実がある。

---

　現在は、Strutsにしろ、ＰＨＰにしろ、

・サーバー側に、画面のアプリケーションをもち、
・そのアプリが処理を行うという形になっている。

　そこで、単価の高いＳＥを利用し（たとえば、１人月単価６０万のＳＥを使うと、上式のように、１．３X画面数だと、１画面７８万になる。デザイナーで１画面７８万も取るやつはいない－常考）、画面も処理も（仮にファイルとかは分けたとしても）ＳＥが担当することになる。

---

　ところが・・・である。

　もし、こういうフレームワークを考えたら、どうなるだろう。

１．画面は、クライアント側でＦｌａｓｈで作成し、
２．データベース処理は、サーバー側のサービスを呼び出す。
３．サーバー側サービスは、ＲＥＳＴ型で受けて、
４．結果をＸＭＬで返す

この場合、サーバー側のプログラムについて考えると、

（１）データを受け取って、セッションの値も取り出し
（２）そのデータを基に処理をし
（３）結果をセッション、あるいは返り値で返す。

ということになる。

さらにここで、（１）の処理は結局、
・引数データを受け取り、それをＵＲＬデコードし
・セッションの中身を全部取り出して、
・それらをハッシュマップにセットする
という操作になり、これらは全部共通化できる。

また、（３）の操作も、ハッシュマップを２つ用意し、
・１つのハッシュマップのほうはセッションにいれ、
・もうひとつのほうはＸＭＬに変換して、値を返す
としてしまえば、これも共通化できる。

この共通化を行うと、結局

（１）データ受け取り共通メソッドを呼び出し
（２）そのデータを元に処理し
　　　　→ＤＢアクセスのトランザクション処理も共通化しておく
（３）結果を出力共通メソッドに渡す

ということになり、これは、実質バッチ処理である。


　さらに、クライアントの処理は、ＡＪＡＸ（って、Javascriptじゃないから、この表現は不適切かもしれないけど）っぽく、サーバー呼び出し、ＸＭＬ取得した前後に、ちょっとコーディングを入れて。。。となってくると、Ｆｌａｓｈ仕事になる。なら、デザイナーでもよいはずだ。

---

　ちょっと待ってくださいね、そーすると、

１．画面はクライアント側でＦｌａｓｈ
　　→単価の安い、専門学校から大量に供給されるデザイナーさんたちが作ります

２．処理部分はＲＥＳＴで、サーバー
　　→実質、バッチで工数が減ります。

っていうことになっちゃいますよねえ。。

大変です。はじめの話に戻ると・・・
工数、単価へって、価格崩壊です（＞＿＜！）

　今、ちょっとしたシステムでも、数百万、１千万規模で開発できるけど、
　これに気づかれると、３百万とか、１００万とか、
　ひどいとデザイナーが受けて、数十万で請合うとかも、出てきそうでしょ・・・　

---

　いま、ユーザーさんが、この開発方法に気がついていないから（たぶん。あ、このブログは多くは大学・研究所とか、メーカーとかＳＩerさんとか、ソフトハウスの人が見ていて、ユーザーの人はあんまり見てないみたいよ）、こーいう話にはなってないけど、メーカー、ソフトハウス、SIerさんで、大量退職者が出ると、だれか、この手のビジネスを考えて、たとえば、暇な女子大生とかを集めて、Flash教えて、ユーザーと一緒に画面周りを作って、あとはバッチ部分を作って納品、女子大生なら、月２０万くらい払えば、アルバイトならいい商売だから、月８０万くらいで１システム受けて、のこり６０万まるもうけ・・・とか、考え出してくるやついそうだよねー。

　とくに、金持ちＩＢＭの退職者とか・・・

　会社辞めて、女子大生と楽しくやったほうがいいとか思い始めて・・・

---

　で、こうなると、やばいのは、こーいうビジネスがかなり出た後で、不況を抜けると、ユーザーは安い開発費用に慣れちゃうので、今みたいな、価格はとれないってことだよね。。。

　さらに悪いことに・・・（この話、つづく）

自分の死去をオンラインに知らせる方法・・・遺書となると、行政書士とかＦＰとか。。。

ここの痛いニュース
「今はもういない私から」…自分の死去をオンラインにどう知らせる？
http://slashdot.jp/askslashdot/08/11/26/0713204.shtml

まあ、普通に考えると、

１．ダイヤル式の金庫とかに、死後知らせなきゃいけないリスト、
　　削除すべきリスト、操作方法などなどをいれておいて、

２．遺書にその金庫のコトと、ダイヤルの番号を書いておき

３．その遺書を「秘密証書遺言」にしておけば、

・遺言の存在は明確なので、必ず開封してくれる。
・変更がある場合、そのダイヤル式の金庫の中に入っている紙を書き換えればいい
　→遺書を書き換える必要はないので、簡単
・「秘密証書遺言」なので、遺言の存在はわかっても、中身は見られない

なのがいいっていうことになりますかにょ。
ＡＪＡＸが発達すれば、プログラム的に登録解除出来るようになるので、
ＵＳＢにはいってるプログラム（バイナリ、ソース無し）を起動してくれれば、
どこに登録したか分からずに解除、削除できるなんていう形になるかも・・・

---

でも、そーなってくると、遺書に、コンピューターのコトも書かないといけなくなるわけで・・・
めんどっちいいから、そーいうことまでまとめて面倒を見てくれる（ワンストップな）、
信託銀行とか・・・っていうとおおげさなので、
ＦＰさんとか、行政書士さんが、人気になってくるかもしれません。

単純に削除するだけでなく、ブログの著作権をどうするとか
（著名ブログだと、本にして・・とかいうと、その遺産は？とか、問題になりそうだ）
リアルな部分の遺書と、その執行、書き換えの話もあるし・・・

っていうことで、ＦＰさん・行政書士さんに、成年後見人＋遺書関係を一括で見てもらう、
その中のサービスの１つとして、こーいう連絡の話もでてくるかもしれませんね。

---

え、じゃあ、ウィリアムのいたずら、ＦＰなんだから、やったらって？
いやー、だめっす。

貧乏人のＦＰの言うことなんて、誰も聞かないでしょう（＾＾；）

やっぱ、こーいうのは、ＩＢＭをやめたお金持ちの人がＦＰになって・・・
とかいうはなしですかにょ。

無料の「擬似」個人情報

　テストなんかに使うものらしい。
　無料の「擬似」個人情報（住所氏名は埋まっているけど、そこに、架空の人っていうやつ）があるそうな。

ここ　http://www.start-ppd.jp/free/lisence.php

　まだ、ダウンロードしていないけど（というか、必要なとき以外しないと思うけど）
　とりあえず、メモメモ