IPアドレスが枯渇すると→ネット家電が動かない？

IPアドレスが枯渇して、IPV6とLSM（ラージスケールNAT＝キャリアグレードNAT）になったときの話。

LSMでは、UPnPが動かないらしい（という話を今日、OSCで聞いてきた）。

で、UPnPは、多くのネット家電でつかってるわけで・・・

話の最初と最後をあわせると
IPアドレスが枯渇すると→ネット家電が動かない？

　困るのは、たぶん？？IPアドレス枯渇後、LSMでIPV4のアドレスをもらった人が、なんらかのネット家電を動かしたときっていう話になるから、今グローバルアドレスを持っている人にとっては、たいして困らないかもしれない。
　けど、メーカーは、「じゃあ、どうにかしてくれ！」とか言われたり、諸外国から、「なんらかの対策を採らないと輸入してあげないよ！」とか言われると、こまる？？

eclipseのプラグインでメール連携とかあったら、便利？

　eclipseからメールが見れて、メールをソースプログラムにドラッグ＆ドロップすると、ソースにコメントとしてメールのIDが入り、関連づく機能を持たせる。

　そうすると、メールをみてソースを修正、関連付けた場合、
　あとで、そのメールをもとに修正したソースがわかる。
　　　→まだ修正してないソースもわかるので、進捗状況が把握できる

---

　ほかにも、メールにプロジェクト名を指定の形式で書いておくと、自分が開いているeclipseのプロジェクトと関連づいて、メールの添付ファイルと、eclipseのソースの内容を比較してくれたり、置き換えたりしてくれる（置き換えた場合、上記の関連付けが自動的に入る）とか・・・

---

　たいして便利でない？すでにある？？

危ないサイトは、検索エンジンのほうで、表示順位を下げてくれるとありがたいけど・・・

ちょっと古いけど、ここのニュース
ネット検索で危険な有名人、佐藤江梨子、京野ことみ、米倉涼子ら
http://news.goo.ne.jp/article/internet/business/iw2009102709-internet.html
(以下斜体は上記サイトより引用）


　マカフィーは26日、「インターネット検索で最も危険な日本の有名人」についての調査結果を発表した。1位は「佐藤江梨子」。

なるほど・・

2位は「京野ことみ」「米倉涼子」、3位は「相澤仁美」「井上和香」「沢尻エリカ」「福山雅治」「松浦亜弥」、4位は「新垣結衣」「上戸彩」「菅野美穂」「ほしのあき」「矢田亜希子」、5位は「小倉優子」「川村ゆきえ」「長谷川京子」「山本梓」。女性タレントが多数を占める中、男性では福山雅治が唯一ランクインした。

なるほどなるほど・・・
あ、ちなみに、「危険な有名人とは」悪いことをしそうな人という意味ではなく

「佐藤江梨子」「佐藤江梨子 ダウンロード」「佐藤江梨子 壁紙」「佐藤江梨子 スクリーンセーバー」「佐藤江梨子 画像」「佐藤江梨子 動画」などでインターネットを検索すると、SiteAdvisorで脅威があると判定された危険なサイトに誘導される可能性が、他の有名人に比べて高かった

という意味。

これ、

SiteAdvisorでは、検索エンジンの検索結果ページにリストアップされたサイトに対して、危険なサイトを赤、注意が必要なサイトを黄、安全なサイトを緑のアイコンで指摘する。

そうなんだけど、もう、検索した時点で、Googleやyahoo,gooが、「危ないよ！」とマークしてくれたり、表示順位をさげてくれないかなあ・・・

・・・と思ったけど、そーいうことすると、「危険なサイト」とみなされたサイトから、「なんでだー、訴訟起こしてやる、謝罪と賠償を」とかいいだして、うるさいから、出来ないのかなあ・・・

・・・うーん・・・

サーバーで計算するか、クライアントで計算するか

　たとえば、ものすごい数値計算などは、サーバーで計算したほうが速いときとか、クライアントで計算したほうが速い場合など、いろいろある。
　このとき、サーバー側とクライアント側で、計算プログラムを用意すれば、処理しやすいほうで、計算してくれればいいことになる。

　このとき

　　クライアントで計算した場合の計算結果を渡す変数と、
　　サーバー側に計算してもらうためのデータを渡す変数は

　別の変数にしておき、どちらの変数が設定されているかをサーバーがみて、サーバは必要なら（データ側に値が設定されていたら）処理を行う。

　としたとき・・・

---

　クライアント側で処理するかどうかを判断することになる

　判断上、
　クライアントで処理したことが有利となれば
　　　クライアントで処理して、処理結果変数に結果をセット、サーバー呼び出し
　サーバーで処理したほうが有利となれば
　　　サーバーで処理してもらうため、データ変数に結データをセット、サーバー呼び出し

　となる。
　なので、サーバーは、クライアントの判断対象となるデータ、この場合サーバーの混みぐらいをクライアントに教えないと、いけないことになる。

---

　で、ここからが本題。
　そのサーバーの混み具合情報をクライアントのjavascriptに渡すには、

　サーバー側プログラムで、混み具合の値を表示する変数を
　HTML（なりJSP）のHEADタグ内に

＜HEAD＞
＜script type="text/javascript"＞
var komiguai = 「ここに、混み具合の値を書き出す」
＜/script＞
　　：
＜/HEAD＞

のようなかんじで入れておけばよい。
javascriptでは、上記変数（komiguai）を参照し、判断する

---

　おんなじ理屈で、DBアクセスするか、クライアント側で持っている値で処理するかを決めることが出来る。
　その場合、混み具合ではなく、最終更新日時をいれておき、サーバーのほうが新しければ、再度読み直し、クライアントのほうが新しければ、クライアント側のキャッシュを使う。

UML等各種ダイアグラムのエラーチェック体系化（その３７：まとめ）

　ということで（どういうことだ ^^;)、シリーズUML等各種ダイアグラムのエラーチェック体系化のまとめです。

---

■話のまとめ

　もともとは、大学院の修士論文に書こうと思っていたネタを、大学院をやめたので、修士論文を書く必要がなくなり、そこで、ここに書いてみたという話です。

　書いてきた内容は
　ここ　http://www.geocities.jp/xmldtp/index_system.htm
　に一覧としてなっています。

　開発のとき、ダイアグラムを利用しますが、そのダイアグラム間で矛盾が起きることがあります。
　この矛盾をチェックできないか？ということで、

　　１．データベースにダイアグラムを入れて
　　２．ダイアグラム間のエラーチェックを行う

　ということを考えました。

　そして、ダイアグラムをDBに入れるために、要素をノードとエッジにわけて、それぞれテーブルに入れていきました。その後、ダイアグラム間の関係を分析しました。

　結論としては、前回に書いたとおりです。

---

■今後について

　この話のサブテーマである、設計から、プログラムまでの自動化というか、データのつながりに関しては、
　EAとUMLで分けた場合、EAのほうしか話してません。

　UMLでは可能なのか？

　これについては、もうひとつ、シーケンス図についていままでのような分析を行い、そこから話を持っていく必要があります。なので、それを書きます。

　そのあとで、「要求仕様から設計、プログラムまでの自動化の可能性」として、要求仕様からプログラムまでのつながりについて、書きたいと思います。

---

■で、

　これを書き始めたときに、この話は、反響を呼ぶか、残念な結果になるか？という話をしました。

　かきはじめの基準値(土曜は、急激に減るので除く）
2009.06.12(金) 5822 PV 1641 IP 117 位 / 1244853ブログ
2009.06.11(木) 6992 PV 1809 IP 100 位 / 1244358ブログ

　現在値　
2009.10.27(火) 6208 PV 1606 IP 146 位 / 1315508ブログ
2009.10.26(月) 6138 PV 1593 IP 159 位 / 1315069ブログ

件数は逆に落ちているというだめだめな結果に・・・
やっぱり、面白くないってことなんでしょうね・・・きっと（＾＾；）

ケンコーコム、シンガポールで日本の消費者向け医薬品オンライン通販を開始

ここのスラッシュドットニュース
ケンコーコム、シンガポールで日本の消費者向け医薬品オンライン通販を開始
http://slashdot.jp/it/09/10/27/0426253.shtml

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

医薬品通販大手のケンコーコムが、シンガポールに100％子会社「Kenko.com Singapore Pte. Ltd.」を設立、日本向けの医薬品通販サイト「ケンコーコム シンガポール」を立ち上げた（Internet Watchの記事）。

今年6月の薬事法改正により、医薬品の通販に大きな制限が加えられるようになったが、医薬品の個人輸入については特定の範囲内で個人的に使用する目的であれば許されている。そのためケンコーコムはシンガポールに拠点を作り、日本の第1類および第2類医薬品や排卵日検査薬などを日本の消費者向けに「個人輸入」の形で販売するサイトを立ち上げたそうだ。


その手があったか。
たしかに、ネットは、国境関係ないし・・・

韓国ではないってことは、この手のことをやるのは、シンガポールのほうがいいのかなあ・・
たしか、金融業なんかでもシンガポールが多いよね。
それとも

ケンコーコムは海外向けに日本の医薬品を販売するサービスの提供も予定しているとのこと。


ってことで、インドネシアとか、ベトナムとか、マレーシアに売る気？
それだと、地理的にいいのかも？


送料は一律650円で、8000円以上の購入では無料となる。在庫のある商品については通常1週間程度で届くとのこと。


シンガポールの割には、意外と安い？
っていうか、シンガポールから送ってるかどうか、わかんないのか（＾＾；）

他の薬局も、シンガポールに支社ができそうな予感・・・

UML等各種ダイアグラムのエラーチェック体系化（その３６：エラーチェックの体系化）

　ひさしぶりに、シリーズUML等各種ダイアグラムのエラーチェック体系化です。

　きょうは、いったん中締めです。

　今まで話してきた、ダイアグラムにおける、エラーチェックを体系化します。

　なお、今までの話は、
　　　ここ　http://www.geocities.jp/xmldtp/index_system.htm
　にあります。

---

■ダイアグラムのエラーとは

　２種類のエラーが考えられます。

　　１種類は、１つのダイアグラムにおいて、ダイアグラムの記述ルールに逸脱しているというもの
　　　　たとえば、DFDにおいて、詳細化したプロセスと元のプロセスで入出力データが違うとか

　　もう１つは、２つ以上のダイアグラム間において、矛盾があるというもの
　　　　たとえば、機能構成図（DMM)である機能に対応する、業務流れ図が存在しないとか・・

　前者の場合は、ルールに逸脱しているので、「間違い」と指摘できます。
　しかし、後者の場合は、一致させる必要は、必ずあるわけではないので、エラーとは言い切れない場合もあります（上記の例でも、その機能は一般的なので、業務には出てこないと主張されてしまえば、おしまい）

---

■ダイアグラム間の関連について

　しかし、実際には、ダイアグラム間の関連をつけたほうが、あとで検証しやすいし（ってことは間違いも減るし、間違いチェックできる）、プログラム生成・設計書作成も自動化できる可能性があります。

　なので、ダイアグラムに関連をつけることを考えます。

　この場合、２つのルートが考えられます。

---

■第一ルートEAっぽいの

１つは、EAなどのオブジェクト指向っぽくないもの

　DMM（機能構成図）で、大きな機能から小さな機能に分けていき
　　　　　↓
　その機能に対する業務流れ図を書いていく
　　　　　↓
　業務流れ図では、入出力が明確になるので
　　　　　↓
　入出力から、
　　　永続的データ項目抽出→正規化→ER図→DB項目定義
　　　画面遷移図→画面項目定義→画面レイアウト定義→画面定義
　などが出てきます。
　　　　　↓
　また、業務流れ図のプロセスとデータから、DFDを作成することも可能です

この間の関連をチェックし、エラーチェックすることも可能です。
　

---

■第２ルート　UMLっぽいの

　この場合、アクティビティ図のアクティビティを
　　　　↓
　ユースケースのユースケースとする

(逆もありえる）

　ユースケースには、抽象化した継承関係が書ける。

　で、アクティビティ図のオブジェクトノードを元に
　　　　↓
　ER図に相当するデータ部分のクラス図がかけるし
　ユースケースごとにクラスをまとめることも可能。

---

　ってなかんじで、エラーチェックできる。

　当初の「UML等各種ダイアグラムのエラーチェック体系化」のお話はここで終了。
　で、これからどうするか・・・は、次回のこのコーナーで・・・

DIとクラウド（クラウドのサービス変更に柔軟に対応するためのDI利用)

　DIの場合、実際に実行するプログラムは、（Springの場合のbean-conf.xml,Seasar2のdiconファイルなど）XMLに記述して、ユーザー側で、変更可能なようにしている。これにより、仕様変更を柔軟にしている。

　一方、クラウドコンピューティングの場合は、クラウドの先は、なにやっているか見えない。
　サービスを呼び出すときの引数が変更されてしまうと、ソースに手を加えないと、対応ができない。
　これでは、拡張性がない。というか、リスクがいっぱい。

---

　たとえば、A社とB社で、おなじようなサービスを提供していたとする。
　(スケジュール機能とか）
　いままで、A社を使っていたが、B社のほうが、値段が安いから、こっちを使いたいと思ったとする。
　でも、引数が違えば、（それも、同じ意味なのに、違う名称を使っているような場合）プログラム修正＆テストの開発をしないといけない。影響範囲もわからない。

　DIで、２つの類似サービスを切り替えることを考える場合、この２つのサービスの抽象化されたインターフェースを使ってコーディングしておけば、設定ファイルの変更のみですむ（まあ、テストは必要だけど・・・）

---

　じゃ、今の場合どうするか、つまり、A社とB社のサービスを簡単に切り替えるには？
　それも設定ファイルを変えるかんじで切り替えるには？

　ラッパークラスを使えばいい。

　　１．A社のサービスを呼び出して結果を返すクラス
　　２．B社のサービスを呼び出して結果を返すクラス

　の２つのクラスをつくり、この２つの共通部分をインターフェースにして、他のクラスでは、このインターフェースを使って、操作をすればよい。

　そうすれば、設定ファイルでA社のほうを使うか、B社のほうを使うかを切り替えられる。

　クラウドコンピューティングは、「稼動している」ことは、９９．９９％とかで保障してるけど、すべてのサーボスの呼びし引数、返り値が、変更なく動くかどうかは、保障してるの？っていう状態だと思うので、サービスの呼びし引数、返り値変更とかに対応するためにも、こういう仕組みは、必要かもね？

XMLSchemaやDTD,RELAX のバリデーター、SunのMSV

Sunから出している、
　　・XMLSchemaが正しく書かれているかチェックするバリデーター
　　・あるXMLが、指定されたXMLSchema通りに書かれているかチェックするXMLのバリデーター
　　・上記のことを、DTDやRELAXでもやってくれる

バリデータ、Sun Multi-Schema XML Validator（MSV)というのがあるそうな。

---

■ダウンロード

msvのサイトhttps://msv.dev.java.net/
で、Nightly builds をクリックして、左側のツリーの「releases (2)/ 」をクリックして
出てくる画面の一番上、MSV (2009/04/15)をクリックしてダウンロード

できたmsv.20090415.zipを解凍。

中に降りていくと、msv.jarっていうjarが出てくる。ここに、いくつかのjarがあるので、
それを適当なフォルダを作って(★）いれる。

---

■サンプル実行

そこに、examplesというフォルダがあるので、それをクリック
下にschemaLookupというフォルダがあるので、それをクリック

bar.xsd(foo.xsdでもいい）とtest.xmlをコピーして上記jarを入れたフォルダ（★のところ）にいれる

コマンドラインを開き、cdコマンドで、その(★の）フォルダにいったら、

java -jar msv.jar スキーマファイル名
（例だとjava -jar msv.jar bar.xsd)
で、スキーマを読み込み、スキーマのxmlのチェックが出来ます。

java -jar msv.jar スキーマファイル名　xmlファイル名
（例だとjava -jar msv.jar bar.xsd test.xml)
で、XMLのバリデーションができます。エラーがあると、エラーを表示してくれます。

コネクションを次々渡すか、コネクションを一元管理するか？

　そうそう、ハンドルで思い出した。
　前に聞かれたことがあるので、ちょっと書いておきますね。

　DBのコネクションでも、なんでもいいんだけど、コネクションとかコンテキスト情報（以下、コネクションと書きますね）を渡すときに２つの渡し方が考えられます。

　　１．コネクションを、呼び出し元から呼び出し先に、どんどん渡していく
　　２．コネクションを一元管理するクラスをつくり、そいつが管理する。

---

たとえば、あるプログラムが、

トランザクションStart
・受注クラスで受注更新し、受注明細呼び出し
　　・受注明細クラスで明細更新
トランザクションCommit

とかあったとき、

１の方法は、
　・メインのクラスで、DBとコネクションを張り、
　　　トランザクションスタート
　　　受注クラスにコネクションを渡す（コンストラクタの引数やセッターで）

　・受注クラスではそのコネクションを使い、
　　　受注明細クラスにコネクションを渡す

　・受注明細は受け取ったコネクションを使う

と、つぎつぎコネクションを渡していく方法

２の方法は、あらかじめ、
　セッションID：コネクションを格納するstaticなハッシュマップを用意し、
　このハッシュマップに入出力するメソッドをstaticで用意する。

　・メインのクラスでDBとコネクションを張ったら、
　　そのハッシュマップにセッションID：コネクションを格納(set)

　・受注クラス、受注明細クラスでは、
　　　　セッションIDを受け取り、
　　　　そのセッションIDから、コネクションを獲得(get）

　もちろん、セッションIDでなくてもいい。
　ってか、セッションIDのわけないか。セッションIDをもってる＝セッション持ってる＝セッションの中にコネクションを入れればいい（１と２の中間）ってことになるから。

---

　２のほうは、staticなので、システムに１個にできる（Singleton パターン ）。
　また、コネクション全体を管理するので、コネクションプールみたいなこともできる（Flyweight パターン）
　ただ、全体で１つを管理するので、機能変更があったときに、全体に波及する（ってことで、全体のテストをもう一度しないといけないことに理論上なる）


　１のほうは、仕様変更の場合、全体でなく、一部の変更であれば、コネクションを継承して、仕様変更用のコネクションクラスを使えば、理論上、旧来のコネクションは影響を受けないので、仕様変更分をテストすることになり、テストは楽。

　それと、２のほうでも、結局IDを親から渡すとしてしまうと、実質１と同じく、親で値をセットしないといけなくなる（ハンドラか実体化の違いだけ）なら、管理が必要な２より、値を渡しちゃう１のほうが楽とも考えられる。

---

　ま、どっちにするかはときと場合によるけど、
　混ぜるな危険ではあるね。

　(混ぜると、いいとこどりにはならず、両方の悪い面が出る。たいてい、いいとこどりというのは、できないものだよね）

ドライバによる多態性、オブジェクト指向による多態性、printcapでフィルタ定義による多態性

　Japan Linux Symposiumの、まつもとゆきひろさんの講演の中で、まつもとさんは、ファイルディスクリプタが好きで、ハンドルさえもらえば、どんなものにも同じように出力できるのがいいとおっしゃってました。

---

　さらに、「それって、オブジェクト指向みたいなかんじ」だったか、どーだったか、そんな意味のようなこと言ってましたけど、たしかに、この前

JavaBeansと多態性を使って、入出力デバイスを柔軟に切り替える
http://blog.goo.ne.jp/xmldtp/e/fc2cf630e1732c4dee0cba5a42662716

に書いたように、インターフェースを使って入出力を抽象的に定義、具体的な出力先は、実行直前でも決められるようにしたのと、同じ効果を持たせられます。ファイルディスクリプタは。

---

　ただ、ファイルディスクリプタで多態性を持たせようとすると、デバイスドライバレベルで、何らかの対応をしないといけないわけで・・・・、そうすると、プログラミングとしては面倒だし、気楽に修正は出来ませんよね。

　ハードディスクとCD-ROMのような物理的デバイスの違いなら、たしかに、それはアリだけど、
　受注出力と発注でデバイスを分けてというのは（＾＾；）・・・

---

　むしろ、そー言う意味で、Linuxがいいのは、　
　lpdの設定、/etc/printcapでフィルタが指定できることじゃないかしら？

7. どうやって設定するのか、基本
7.1 伝統的な lpd の設定方法
http://www.linux.or.jp/JF/JFdocs/Printing-HOWTO-7.html

とあるように、プリンタごとにフィルタ（プログラム）が設定できる。

　そこで、受注用と発注用で、出力プリンタをわけて、出力する。
　そして、

　　　受注用プリンタではXML→受注票フォーマットで出力
　　　発注用プリンタではXML→発注票フォーマットで出力

　になるよう、それぞれフィルタを作っておけば、
　出力先を切り替えるだけで、どちらもXML形式でデータを送れば、適切に処理してくれる。

　仕様変更の場合、業務プログラムに手を入れるのではなく、そのフィルタに手をいれればいいだけ。

　さらに、さまざまな帳票に対して、共通な仕様変更（＝横断的関心事）、たとえば外字の出し方を変えるとかについては、その共通仕様変更部分のプログラムを作って、フィルタを通せばいいだけの場合もありえるかもしれない（プログラム修正必要なし、printcap修正で）。

---

　ってことでLinuxなら、printcapの設定でフィルタが使えるために

　　・抽象的、かつ汎用的な形で出力でき、
　　・出力に関しては、フィルタ修正のみでOKという局所化が利く

　といったメリットがあると思いますね。こっちのほうが、オブジェクト指向っぽいかな？

Googleのスマートグリッドだけど。。。うん？？

さっきやってたNHKスペシャルの
自動車革命　第２回
スモール・ハンドレッド　新たな挑戦者たちhttp://www.nhk.or.jp/special/onair/091025.html
で、Googleのスマートグリッドの説明があった。

昼間、太陽発電で、電気自動車に充電し、
夜、電気自動車から、家電に電気を供給する。

電力不足のところはコンピュータ制御して補い合う

って言ってるけど・・・

---

うん？？ちょっと、まって！

いま、その電力不足にならないように制御してるのって、
今、東京電力がやってるわけだけど（東京では）
東京電力が、電気が足りない！って言っているのって、昼間じゃない？？
パソコンとか、ガンガンについていて、その上、クーラーがかかるわけで・・・

さらに、昼間は、電気自動車は会社にあるわけだから、家の太陽電池からは、充電できなくね？（会社に太陽電池があるとしたら、作った電気は会社が利用するだろうし）

　そして、家に帰ってから電気を提供するったって、お父さんの帰りより前に、家族は電気を使ってるわけで・・・
　素直に、太陽電池の発電を家の蓄電池に変えたほうが早くね？

---

　使う電気も集中管理し、東京電力が電気を買い取り、必要な人が、東京電力から電力を供給してもらったほうが、電気が足りなくなった時、誰がどうコントロールするかが明確になり、はやくね？

　なんか、へん・・・

NECも網膜走査ディスプレイなの？

ブラザーが網膜走査ディスプレイをだすことは、
ブラザー、2010年度に「網膜走査ディスプレイ」を実用化予定
http://slashdot.jp/hardware/09/10/24/0116207.shtml
に載ってたけど、

ここのニュース
会話の翻訳、視界に表示…メガネ型装置開発
http://news.goo.ne.jp/article/yomiuri/business/20091024-567-OYT1T00565.html
をみると、NECも開発、事業化するのかしら？

　題名は、メガネ型となっているけど(以下斜体は上記サイトより引用）

表示法は、光を目の網膜に直接当てて画像を映す方式を世界で初めて採用した。

って書いてあるので、これって、結局網膜走査ディスプレイのことでなくて？

翻訳となっているけど、

　ＮＥＣは２０１０年中に、このシステムを製品化する計画だ。ただ、翻訳の精度など改良の余地もあるため、当初は翻訳機としてではなく、工場や店舗の従業員向けディスプレーとして販売する方向だ。

ってことなので、ディスプレイだけで売り出すのかな？

１１月５日に東京・有楽町で開くＮＥＣの展示会で発表する。


とのことなので、ここで真相がわかる？
１１月５日からということは
C＆Cユーザーフォーラム＆iEXPO2009
http://www.nec.co.jp/uf-iexpo/?cid=necbn030
のことかしらね（＾＾）？

Windows７のネガティブキャンペーン？フジテレビ

ここの痛いニュース
とくダネ！で放送事故…「Windows7」紹介で動かず
http://blog.livedoor.jp/dqnplus/archives/1327786.html

とくダネ！で、Windows７のタッチパネル機能が、おやおや・・・うごかない（＾＾；）
ここのYouTube
win7 demo (japanese tv show)
http://www.youtube.com/watch?v=DbJGzyYV_X8
（リンク先クリックすると、読み込み後、すぐ音が出るので注意）

中野アナのつっこみもすごいっすよね！
「これ中国版ってことはないですよね」
お、おい、中国版って、海賊版っていう意味っすか？
じゃあ、海賊版つかってるんっすか（＾＾；）
なわけないっしょ・・・（＾＾；）（＾＾；）

どうも(以下斜体は上記痛いニュースより引用）

VPCL11*「Touch Screen Driver Ver.2.1.7.0」アップデートプログラム [Updated 2009/10/21]
※タッチパネル搭載機種に限る
スリープ復帰後などにまれにタッチパネルが動作しないことがある問題を解決する
アップデートプログラムを提供します。
http://vcl.vaio.sony.co.jp/product/vpc/vpcl11zhj.html


ってことらしいけど、まーこんなの見たら、

とりあえず、おちつくまでXPでいいか・・・

って思っちゃうよね！！

Windows７のネガティブキャンペーン？フジテレビ

「STOPやめてください」と「OSはやめてください」空耳アワー（＾＾；）

Japan Linux Symposiumのトーバルスさんの話を書いたけど、そのときの様子、以下のサイトにも出ているようだ・・・

「自分の好きなことをやっているだけ」─第1回 Japan Linux Symposium基調講演にLinus Torvalds氏，まつもとゆきひろ氏が登場［前編］
http://gihyo.jp/news/report/2009/10/2202

で、ウィリアムのいたずらが、

　　「OSは、やめてください（＾＾）ｖ」

ときいたところ、

　　「STOP、今すぐやめてください(笑）」

になっていた・・・

いや、トーバルス氏だとおもって、OSと聞き間違えてしまったのね（＾＾；）

空耳でした・・・

P.S　あ、で、問題発言は、「Linuxが生物のように進化する」とあっさりかかれてますね（＾＾；）