情報処理学会、電子投票ミスで、役員・代表を再選挙。そのミスというのが、

これまたローテクなミス。。
（以下斜体は、今情報処理学会から送られてきたメールより引用）

電子投票用パスワードについて、
発送業者の作業ミスにより一部の方々にパスワードが複数送付されて
いることが判明いたしました。


はあ（＾＾；）？

投票用紙、あけてなかったよ、みてみよっと。
ウィリアムのいたずらは、一個しかかいてなかったけど。。

それって、複数書いてある人は、２回投票できるのかなあ（＾＾；）

で、

皆様には大変ご迷惑をおかけして申し訳ありませんが、今回の事態は
選挙の信頼性に関わりますため「平成１９年度役員・代表会員選挙」
の「再選挙」を実施させていただくことといたしました。


おいおい、大丈夫か、情報処理学会！
情報処理学会って、大手メーカーさんとか、すんごい頭のいい大学の教授とかが、所属してるわけでしょ。。。

その学会で、「パスワードを複数発行してしまったために、再投票　＾＾；」

いやー、選挙の信頼性もあるけど、
学会の権威ってやつも（＾＾；；）

Ｐ．Ｓ　やっぱ、一度失敗してもこりずに、電子投票にこだわるってのは、情報処理をやっている学会としての意地でしょうかねえ　（＾＾；）

Wikipediaを運営するのに必要なお金、少なくとも３ヶ月で１億円だって（＠＿＠！）

ここのGIGAZINEの話
Wikipediaを閉鎖させないために必要な金額はいくらなのか？
http://gigazine.net/index.php?/news/comments/20070212_wikipedia_need_money/
によると（以下斜体は上記サイトより引用）

Wikipediaを運営する非営利団体ウィキメディア財団理事長フロランス・デヴォアールから衝撃的な発表が行われた。それは、このまま寄付が順調に伸びなかった場合、あと3ヶ月から4ヶ月以内にWikipediaは資金不足からサーバが維持できなくなり、閉鎖するかもしれない、というもの。つまり、Wikipediaがネット上から消滅する可能性がある、と。

しかし、Wikimediaのスポークスパーソンである広報担当のサンドラ・オードネスによると、Wikipediaはすぐに閉鎖するわけではないし、その前にさらに多くの資金調達の努力を可能な限り行うとのこと。


ひ、ひえー（＠＿＠！）
でね、GIGAZINEでは


では、一体どれぐらいのコストがWikipediaの運営にはかかっているのかを見てみましょう。


を計算したらしい。その結果、
（いろいろ話は長いので省略。興味ある人はリンク先を見てね！）


要するにいくら必要なのかというと、少なくとも3ヶ月で87万5000ドル（約1億円）を集めなくてはならず、6ヶ月では165万ドル（約2億円）を集めなくてはならない、と。


ひ、ひ、ひえー（＠＿＠！）

３ヶ月で１億円ですか。。
そりゃー、マイクロソフトのビルゲイツさんとかに、
OfficeソフトのヘルプからWikipediaがみれるようにするかわりに、
いっぱいいっぱい、寄付してもらえるように、
おねがいしないと。。。

大丈夫なんでしょうか。。。

（とか、書いていながら、自分は寄付しないんだけどね　＾＾；）

ＤＢやネットワークのレスポンスタイムから分散にした場合の集配信。

　この前の非機能要件の話。
　ルックアンドフィールの話はしたので、今回はDBやネットワークのレスポンスの話。

　たしかに、DBは、１事実１箇所っていうことで、データは１箇所に書くのが原則なんだけど、現実的には、そうは行かないものも多い。

　とくに、マスタ関係は、データが多いものが多く、これを、いちいちアクセスしていた場合、たいへんなことになってしまう。たとえば、商品の価格は、商品マスタに入っているからといって、これを、いちいち、本部まで問い合わせていたら、たまったもんじゃない。通信回線が。。

　そこで、実際には、SC(ストアコントローラー：お店全体のコンピューター）の中に価格が入っている（PLU：プライスルックアップという）のが普通です（バーコードの中に入れてしまうNON-PLUっていうのも、生鮮などでは、ある場合もある）。

　で、それはそれでいいんだけど、じゃあ、本部とSCのデータ交換はどうするのか？っていう問題が出てくる。ここで、集配信が必要になる。

つまり　
集信：各店舗のSCから、販売状況をあつめ、本部が受け取る
配信：本部からの商品データその他もろもろなどを、配信する。

---

　で、ここまでは問題ない。

　さて問題は、じゃあ、各店舗のSCの商品データを削除するタイミングは？
　（削除すべきでない。参照例外が問題になるからというSEがいるが、そーすると、PLUを行った場合、処理スピードが日増しに遅くなることになる）。

　とかとか、マスタメンテナンスまで、考えないといけなくなってくる。

　なんで、同じデータを時間的な関係から、分散して（かつ重複して）置いてしまうと、業務上でも、そのデータを同期とるのにどうするんだとかいう問題が出てくる。

　とくに、営業マンの携帯端末（PDAやケータイなど）との同期は？とかいうと、問題になる場合もある（ならないケースも多いけどね）。

URLの１６進変換にencodeURIとencodeURIComponentを使った場合の違い

　Javascriptで、URLの１６進変換に、encodeURI、encodeURIComponentを使った場合の違いなどについて。
　自分へのメモなので、たいした話じゃあーありません。

---

■仕様

以下のように、

実行ボタンをおすと、入力に入れた文字が、
escapeして、１６進変換
encodeURIして、１６進変換
encodeURIComponentして、１６進変換
するようにして、入力に


　　　　タカ&トシ


と入れる（&は半角）

---

■結果
IE6 SP1での結果は、上記の写真のとおり。
encodeURIとencodeURIComponentでは、&のところが違う
escapeは、uがつくけど、ぜんぜん違うコードになる。

FireFox1.5.0.4でも、同じ結果になりました。

---

■ソース
こんなかんじ

＜?xml version="1.0" encoding="utf-8"?＞
＜!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"＞
＜html xmlns="http://www.w3.org/1999/xhtml"＞
＜HEAD＞
＜META HTTP-EQUIV="content-type" CONTENT="text/html; charset=utf-8"＞
＜TITLE＞テスト画面＜/TITLE＞
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
//*==============================================//
//*	関数：test1()				*//
//*	内容：エンコード			*//
//*==============================================//
function test1()
{
  str = document.getElementById('test1_t1').value;
  document.getElementById('test1_t2').value = escape(str);
  document.getElementById('test1_t3').value = encodeURI(str);
  document.getElementById('test1_t4').value = encodeURIComponent(str);
}
// --＞

＜/SCRIPT＞
＜/HEAD＞
＜BODY＞
エンコードの調査
＜table border=1＞
＜tr＞＜th＞種類＜/th＞＜th＞値＜/th＞＜/tr＞
＜tr＞＜td＞入力＜/td＞＜td＞＜input type=text name="test1_t1" id="test1_t1" /＞＜/td＞＜/tr＞
＜tr＞＜td＞escape＜/td＞＜td＞＜input type=text name="test1_t2" id="test1_t2" size=70 

/＞＜/td＞＜/tr＞
＜tr＞＜td＞encodeURI＜/td＞＜td＞＜input type=text name="test1_t3" id="test1_t3" size=70 

/＞＜/td＞＜/tr＞
＜tr＞＜td＞encodeURIComponent＜/td＞＜td＞＜input type=text name="test1_t4" id="test1_t4" 

size=70 /＞＜/td＞＜/tr＞
＜/table＞
＜BR /＞
＜input type=button name="test1_b1" id="test1_b1" value="実行" onClick="test1()"/＞ 
＜/BODY＞
＜/HTML＞

（上記＜　＞　￥は、本当は半角です）

---

■参考
●JavaScriptにおけるURLエンコードの処理
http://www.cresc.co.jp/tech/java/URLencoding/JavaScript_URLEncoding.htm#_Toc25488573
encodeURIとencodeURIComponentで違う所についてなど

●JavaScript の文字コード処理に関する覚書
http://www2.wbs.ne.jp/~kanegon/doc/code.txt

石井裕氏 VS コーチング

　前に石井裕氏のことを書いた。
　その前後、石井裕氏のことを書いたブログがいっぱい出てきたけど、多くのブログは、その放送に関して、肯定的な内容のものが多かったので、ちょっと一言だけ。。

---

　メディアラボの石井裕氏は、そのメディアラボの研究員に向かって、なぜ(Why)ということを問い続けるのだそうだ。その理由は、その問いに答えられなければ、アイデアは十分に練られていないと思うからだそうだ。


　一方、Whyというのを、聞いてはいけないというように、コーチングのときは教わる気がする（というか、少なくともウィリアムのいたずらは、そう教わった）理由は、Whyと聞いた途端に、責められていると感じてしまい、答えることができなくなってしまうからだ。

---

　簡単な話、石井裕氏は、なぜ「Whyとたずねて、問いに答えられなければ、アイデアは十分に練られていないと思う」のであろうか（これは、論理が飛躍しすぎている。Whyというのは目的であって、アイデアはWhatやHowである。Whyに答えられてもWhatやHowに答えられないので、SDLC（SLCP)の断層というのが起こるというのが、コンピューターのCASEツールの問題の１つだった）。

　さらに、なぜ、Whyでなくてはいけないのか？WhatやHowでは、どうしていけないのか（アイデアはWhatやHowを聞くのが普通）。

　これ、石井裕氏に、だれもたずねてないのではないかと思う。

---

　実際、これを、ずーっとたずねていくと、答えられないところにたどり着いてしまうはずである。なぜなら、「”なぜ”という質問を、どうしてしないといけないのか？」ということに答えるには、「なぜ」という言葉を定義できないといけないが、言葉の定義というのは、実は、必ずしもはっきりしない。

　というのも、人間は、論理的に考えて、言葉を発しているのではないからだ。類推で考えている（これは、４枚カード問題などで証明されている）。

　これは、言葉の世界だけではなく、一般的に人間の思考はそうで、だからこそ、直感的に、ばーん！と新しいものが目の前に出てくるのであって、論理的に考えたら、推論できる程度にしか、新しいものは出てこない。

---

　じゃあ、WhyWhyWhyとたずねていくと、どうなるかというと、結局は、尋ねている人の思い通りの答えが出てきてしまう（思いどおりならWhyとたずねられない。違っていれば、なぜ私と違う考えをするのかと永遠とたずねることができるから、この議論を終わらせるには、尋ねている人の思い通りの答えをするしかない）。

　このように、相手の発言を封じ込め、自分の思い通りの結論を導いていくテクニックは、ヒモが、女性をソープに沈めるときに使うテクニックとして有名だけど、コーチングでは当然禁止している。

---

　ということで、Whyとたずねて、追い詰めるのは一般的には危険だし、ヒアリングではあまり使わないほうがいいと思う。とくに、その人は理由を知らなくても、全体から見るとやる理由があり、それは全業務を解析しないと分からないこともあるので、Whyという質問は、あまり聞かず、WhatとHowを中心に（Whatは、入出力に関して、Howは業務手順などにかんして）聞いていくのがいいと思う。

　その点はコーチングの考えに近い。

---

　たぶん、Whyと石井氏がおいつめるのは、学生が、あさっての方向に行かないために使っているのだと思う。WhatやHowを聞いていくと、どこまでも、独創的な考えが出てきてしまう。そーすると、周りの人（＝お金を出す会社）はついていけない。
　そのためWhyと聞いてしまい、あさっての方向の考えをつぶしているのだと思う。

　そうすると、学生は、先生に受け入れられる考えをしめす。

　そこで、独自性がないといわれると、考えは潰れる。

　結局このようにして、平凡よりちょっと上の部分を狙うことにより、企業に受け入れられ、お金が入ってくる。。。ってかんじじゃないかなあ。。だからわざとWhyを使っているんだと思う。

　業務ヒアリングでも、あさっての方向に行かないためにつぶす手段としてのWhyは、ありだけどね（くっだらない自慢話をしてるとき、「なぜ、そんなことを話すんですか」と聞く。これは、明らかに責めているわけで、こういうときのWhyはOK!)