ＲＦＩＤって、エコ的にどーなの？

と、ふと思った。
ＲＦＩＤ使うにも、いろんな金属とか、エネルギー使うよね。
それを商品に貼ったら、超大量に、ＲＦＩＤをつくるための金属とか、エネルギーが必要にならないのかなあ？

　その分、物流などで、配送するエネルギーが効率化されて、見あうとか、あるのかなあ。。

　ま、物流の際の箱に張るとかいうのなら、箱を回収してリサイクルとかあり得そうだけど・・

バーコード作成.NETアプリケーションを作る

これも、将来役に立ちそうなので、メモメモ

バーコード作成.NETアプリケーションを作る
http://codezine.jp/article/detail/3345

グレープシティが出している、有償のコントローラー（制限つきのトライアル版もあるみたい）
PlusPak for Windows Forms 5.0J
を使うようだ。
　そのPlusPak for Windows Forms 5.0Jのダウンロードサイトは、

http://www.grapecity.com/japan/support/database/P7_393.htm

バーコード以外にも、いろいろあるみたい。

Struts 2入門

Strutsは1.3とかと、２では、ぜんぜん違うので、
お勉強しなきゃ！
ということで、忘れないようにメモメモ

Struts 2入門（1）～基本形で理解する仕組みと構造～
http://codezine.jp/article/detail/2296?p=1

「あなたが選ぶオタク川柳大賞」応募開始に思う－そのうち、ＩＴ産業でなく、オタク産業に。。

ここの記事
オタクをテーマに五・七・五--「あなたが選ぶオタク川柳大賞」応募開始
http://japan.cnet.com/news/media/story/0,2000056023,20384421,00.htm
によると（以下斜体は上記サイトより引用）


インターリンクは11月28日、川柳作品コンテスト「第4回あなたが選ぶオタク川柳大賞」の作品応募受付を開始した。

　第4回あなたが選ぶオタク川柳大賞は、2007年まで実施されていた「あなたが選ぶIT川柳大賞」のお題を、「IT関連」という枠から広げたもの。


あらま、ＩＴじゃなくって、オタクなの？
秋葉原も電気街というより、違う感じになってきたし・・・


Ｐ.Ｓちなみに、「第4回あなたが選ぶオタク川柳大賞」は

ここ http://www.575.cc/

Google、携帯絵文字のユニコード化支援プロジェクト「emoji4unicode」を公開

ここの記事
Google、携帯絵文字のユニコード化支援プロジェクト「emoji4unicode」を公開
http://codezine.jp/article/detail/3347
によると（以下斜体は上記サイトより引用）


Googleは27日、日本の携帯絵文字をユニコードとして共通符号化する動きを支援する目的で、オープンソースプロジェクト「emoji4unicode」を公開した。


ここ
emoji4unicode
http://code.google.com/p/emoji4unicode/
ドキュメントは
http://sites.google.com/site/unicodesymbols/Home/emoji-symbols
で、
絵文字全部の対応表は、
ここ　http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
（とっても大きいので、かなり時間かかる）

サーバー側はＲＥＳＴでＤＢ操作だけとなると、ツール化できてしまうんだよね！

　で、昨日の問題。

　ソフト開発は、必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数なので、

　　・画面開発者の単価を減らし
　　・画面と操作部分を完璧に分離し、操作部分をバッチに落とし込めば

価格は安くなることになる。

このとき

サーバー　　　　　　　　　　　　　　　　　　クライアント
・ＧＥＴまたはＰＯＳＴで引数を受け取り
　セッションの引数とあわせて（共通関数で）　　　・画面操作、処理をflashで行い

・ＤＢ操作処理　　　　　　　　　　　　　　←→　・サーバーをflashから呼び出し、　　　
　　　　　　　　　　　　　　　
・結果をセッションに入れたり　　　　　　　　　　・受け取ったＸＭＬをもとに　　
　ＸＭＬで返す（共通関数にセット）　　　　　　　　画面表示させる

　とすると、クライアント側はＦｌａｓｈ処理のみとなり（ブラウザからflashのウィジェットを呼び出すにしても）、サーバーは、ＤＢ操作だけのほぼバッチ処理となる。
　そして、Flash処理は、デザイナーでできるし、デザイナーの単価は安い。

　で、さらに・・・ということで、話は終わっていた。

---

　で、さらに、サーバー側を考えると、

・データチェック
　　・存在チェックとか、ＤＢアクセスが必要なもの
・ＤＢ操作
・値入出力

が主な仕事になる。
上記の記述は業務に関係ない（受注とか、給与とか、販売とかの言葉が入ってないことから分かるように）
ということは、

ツール化できる。

---

　つまり、

・どっかのプロバイダがＤＢを提供し、（ロリポップはMySQLが使えるようになっているように）

・そのＤＢの操作サービスを提供して、
　　　そのサービスでは、ＤＢにテーブルが作成できて、
　　　テーブル操作用のサーバーアプリ（ＲＥＳＴ型の）が作れるようにする
　　　　　・アプリの内容は、ＤＢ操作、値チェックなどなど

・作ったサービスを一般の人がアクセスできるようにする
　　　認証は、ＳＳＯで、ＯｐｅｎＩＤとか使ってかな？

ってすると、

　サーバー側プログラムは、そのツールを使って、（ＲＥＳＴ型、出力はＸＭＬ）サービスを作ってしまって、
　あとは、画面側を作ればよいだけになる。

---

　現時点では、画面とＤＢ操作が分離されていない（Ｓｔｒｕｔｓでは、ＪＳＰ内にタグづけをしないといけないし、ＰＨＰは、ＤＢアクセスのためのソースを書かないといけない）

　しかし、上記のように、クライアントはＡＪＡＸまたはＦｌａｓｈとすると、クライアントとサーバーが完全に分離して、その上、サーバー側はバッチ処理になり、バッチ処理はだいたいやることが決まっているため、それをツール化できてしまうっていう、ストーリーなわけだ・・・

　そして、もっと悪いことがある。

　クライアント側も、あるプログラム（それも、多分、経験１～２年の人ですらかけてしまう）を作ると、クライアント側もバッチレベルに落としこめる可能性があるのだ。

　そのプログラムについては、またこんど

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

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

日本ＩＢＭが１０００人削減－問題はやめた人がどこへ行くかだ・・

ここのニュース
1000人規模の人員削減へ＝正規雇用にもリストラの波－日本IBM
http://headlines.yahoo.co.jp/hl?a=20081125-00000210-jij-bus_all

問題は、このやめた人たちが、どこへ行くかだ・・・

ほかの会社って言ったって、ほかの会社もリストラしてるわけだし・・・

ま、ＩＢＭに勤めていたような人は、人生勝ち組、お金いっぱい持ってるから・・・

会社でも、経営してやる？
でも、お客さんも、不況で仕事を出せないだろうし・・・

やっぱ、ここは、その有り余る財産を使って、デイトレーディングでもしていただくと、株式市場も活況になって、株価上がる？？

Ｐ．Ｓ　でもね、仮に会社やったとしても、勝ち組みなんだろうな・・・
　って話は、今度また書きますね

SaaS＋運用を販売となると・・・

　で、さっきの話。

　ＳａａＳのＣＲＭソフトなどは、形式的な共通化、つまり、どんな業務でも、オブジェクトを作って載せられますよ、だけど、ユーザーインターフェースとか、オブジェクトの実装の仕方は、共通化しましょうね！という形になっている／なっていくように思われる。

---

　でもそうなると、どんな業務でも載せられる反面、その業務を、ＳａａＳ上に実装するには、だれかがオブジェクトを作ってカスタマイズしなきゃいけなくなる（プログラムを作るほどではないけれど・・・）

　さらに、ＳａａＳ＋カスタマイズ、カスタマイズした部分の教育が必要になってくる。教育が多く必要なら、めんどっちいから、運用までしてよ・・・っていうことになって、ＳａａＳのサービスだけでなく、そのサービスを使う運用までアウトソーシングになってくるかもしれない。

---

　しかし、ここで問題になってくるのは、ＳａａＳ＋運用にした場合、中小だと、誰が売りに行くのか？という話。

　すぐに思いつくのは、内田洋行、大塚商会などなど・・だけど、

　そーいうところは、むしろ、ハード売り、ＳａａＳまでは売ったとしても、運用を販売するかどうかまでは。。。？？

---

　なぜ？かというと、利益構造が違うから。

　たしかに、運用は安定した収入が入ってくるんだけど、人をアサインしないといけない。

　そして、運用契約解除された場合、その人は解雇・・・といけばいいけど、正社員だと、そうやすやすと解雇できない。一方、人は、どれくらい必要かがはっきりしない。

---

　ということで、内田洋行、大塚商会などなどが、ＳａａＳはまだしも、その運用までを販売するみたいなことがあるのか？その場合、自社で人を抱えるのか、エコシステムをつくって、中小運用会社と連携して販売するのか？なーんていうことは、まだ見えてこない。

　しかし、形式的な共通化としてのＳａａＳ・ＡＳＰを考えた場合、そういうビジネスも可能になってくるっていうところが、ビジネス的に、面白いところ・・・

Ｐ．Ｓ「中小運用会社と連携して」って、そんな、中小のＳＩさん、ソフトハウスが急に増えるのか？ってはなしは、また今度。

ＳｕｇａｒＣＲＭは、５．０で意味的共通化から形式的共通化に変わり、利用範囲が広がった

　このまえの、意味的共通化と形式的共通化の話だけど、

　SaaS・ＡＳＰなどの場合、オブジェクトと属性を自分が作れるかどうかで、話が変わってくる。

　オブジェクトを生成できないと、かりに属性がいじれても（追加、削除できても）、事物の関係は、そのオブジェクトに拘束されてしまう。なので、そのオブジェクトを利用するストーリー（業務）しか展開できず、新たなオブジェクトを作成しないとできないような業務は利用できない。

　したがって、オブジェクトを生成できない場合のＳａａＳ・ＡＳＰなどは、意味的な共通化をして、ＳａａＳ・ＡＳＰが提供するストーリーにあっていないと利用できない。

---

　一方、オブジェクトが作れる場合、自分たちの業務に合わせて、オブジェクトを作成し、そのオブジェクト間の関連を引き、属性を設定できる。つまり、この場合、表示方法など、形式的な共通化をしているに過ぎず、自分たちの業務、ストーリーに合わせて、オブジェクトを作って作成できる。

---

　ＳｕｇａｒＣＲＭの場合、５．０までは、オブジェクト（Ｓｕｇａｒの場合はモジュール）を作成するには、自分でプログラムを書くしかなかった。なので、画面操作だけでやる場合は、意味的共通化のレベルだった。となると、Ｓｕｇａｒの体系（つまり、リード→取引先と発展していくような関係）に沿った業務でしか利用できず、それ以外で利用しようとすると、大幅なカスタマイズを必要とした。

　ＳｕｇａｒＣＲＭの５．０になって、モジュールビルダーが登場し、自分たちでオブジェクトを作れるようになったので、業務に沿ったオブジェクト（モジュール）を作成し、属性を設定することが出来るようになった（Ｓｕｇａｒの体系がいやなら、全部それを隠してしまって、自分たちのモジュールだけを表示するのも可能だし）。

　表示方法などは統一されるため、形式的な共通化となるが、業務的な共通化の束縛からは解放されたため、利用範囲が広がったといえる。

---

　ただし、意味的共通化から形式的共通化になると、ちょっとした困ったことがあり、そこが商機につながるわけだが、それについては、また今度。

C#で、階層構造を表示したいときに。。。

目の前にある紙を処分したいので、元ネタのＵＲＬをメモメモ

C#で、階層構造を表示したいときには、TreeViewコントロールを使うと思う。

このとき、項目を追加するには、
TreeViewコントロールへ項目を追加するには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/259treeviewadd/treeviewadd.html

ノードが選択されたとき、イメージを切り替えるには
06.ノードの選択/非選択時にイメージを切り替える
http://hiros-dot.net/CS2005/Control/TreeView/TreeView06.htm

さらにそこから、ＤＬＬを呼び出したいとき
Win32 APIやDLL関数を呼び出すには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/024w32api/w32api.html

ついでにＣ＃とは、関係ないけど・・・
二村射影について
MyC言語からOCamlへの「コンパイラ」
http://itpro.nikkeibp.co.jp/article/COLUMN/20070410/267632/?P=2
これだけで、何をやりたいか、気づいたあなたはすごい！

一方ＰＨＰは、Zendが、Flex／AIRと連携なのね・・・

前に、「C/C++でFlashアプリが開発できるAdobe Alchemy」ってまじ！。。。ってことで、ＣとＣ＋＋の話を書いたんだけど、ＰＨＰは、

Zend、AdobeのFlex／AIRと連携可能な「Zend Framework 1.7」をリリース
http://sourceforge.jp/magazine/08/11/21/0224200
ということで、Flex／AIRと連携なのね・・・