「SQLServerのチューニング方法について」の記事

　@ITのこの記事
Dr. K's SQL Serverチューニング研修（1）
SQL Serverというブラックボックスを開いてみる
http://www.atmarkit.co.jp/fdb/rensai/drk01/drk01_1.html

　今回は、具体的な方法を書いてないけど、なかなか、おもしろいかも。。。

　SQLServer自体がOS（つーか、タスクスケジューラーつーか）を持ってるとかいう話や
「Win FS」という、次期Windows OSである「Longhorn」のファイルシステムの一部に取り込まれることが予想されているものの話とか(斜体部は、その記事より引用）。

　次回からの内容に期待。

　そうそう、そこにもあるけど、「メモリーによる処理スピードの違い」って、大きいよね。
　意外とアロケーションに時間がかかるんだよねー
　で、ガベージコレクションとかの話については。。
　長くなりそうだし、SQLServerに何一つ関係なさそうなので、（JavaとサーブレットとDBの話ってとこかな）今日はやめとこっと。

PHPのGCを使うため、減色処理することを考えてみる(その２：代表的な色抽出）

　昨日のブログ（PHPのGCを使うため、減色処理することを考えてみる(その１））おおぼけ書いてましたね（＾＾；）あまりにも、ショーもない間違いなんで、修正しておきました。

　修正して、書き直したけど、うーん、やっぱり、単純に、網点で対応するとすると、大きな網点をつくるか、トーンジャンプ（階調間の幅が大きくなりすぎて、滑らかに見えない、グラデーションなどだと、模様になっちゃう）が起こっちゃいそうな気がします。

---

　つーと、やっぱり、使っている色のうち、一番頻度の多い色を２５６色選んで、それをインデックスにして、あとは、近似する？

　でも、そーすると、あおぞらに、ちょこっと、熊さんがいるとかいうやつの場合、青空の色に多くのインデックスがとられ、くまさんに、ちょこっとしか、色がいかないようになりそうだ。。

　色の違いと頻度について、なんか、数値化して、評価できればいいけど。。
　すぐに思いつかん。

---

とりあえず、階調と、頻度、両方あわせて
１．ある誤差範囲を決めて、その中で同色のものの頻度を数え
２．一番頻度の多い色からえらんで、インデックスカラーにする
３．でも、ある程度の階調は、あらかじめ用意しておく。

ってかんじかなあ。
プログラム的には、
１．Rについて、0,100,200,255,
Gについて、0,100,200,255
Bについて、0,100,200,255　計4X4X4=64階調を登録しておく（今日は、計算、間違えないよ　＾＾）

２．あとで、ソートが簡単になるように、これら、６４階調の頻度に、下駄をはかせて、頻度でソートしたら、かならずこいつらが、上位になるようにする（総ドット数分、頻度を足しこめば、絶対こいつらが上位にくる

３．全部のドットについて、頻度を数える。
　ただし、まったく同じ色というわけでなく、ある程度の誤差範囲を決め、その範囲内だったら、その色とみなして、頻度を数える。

４．そこから、上位２５６色を選び、インデックスカラーとして登録する。

５．PHPには、ここで使っているように、imagecolorclosestっていう関数で、一番近い色を探してくれるので、それを使って、インデックスカラーを選び、描画する。

って、こんなかんじなのかなあ。。。

今日も、時間がないので、確かめられない、ウィリアムのいたずらなのでしたあ。。

BREWでシステムを設計仕様としているSEさんへ、IDataFolderに気をつけろ！

　長井秀和風に

　ケータイの、BREW3.1アプリで、データフォルダにデータを置こうとしているシステムを設計しているSEさんは、気をつけろ！

　IDataFolderのOpenのモードはCreateとReadで、Createに、存在するファイル名を入れると、勝手に新しいファイル名にして、違うファイルが作成される。
　「あ、やば！！」と思ってDeleteってやると、エラーコード２０番（サポートしていない）だ！

　「あれ、これって、ファイル削除とか、上書きとか、どーやるんだ！？」って、気づいたときには、もう、後戻りできないくらい、プロジェクトが進んでいる！間違いない。

業務アプリと、ケータイでのファイル読み込みタイミングの違い(その場で待たせるか、先読みするか）

　業務アプリの場合、ファイルを読み込みをするのに(仮に大量データで、読み込み待ちになっても）、わざわざ、読み込み部分をforkして、バックグラウンドで先読みさせておくということは、あんまりしないと思う。

　しかし、ケータイの場合、データフォルダに読むファイルがある場合や、イメージファイル(JPEGなど)の場合は、ファイルをバックグラウンドで読み込ませ、読み終わったら、コールバックするという手法をとることがある（JPEGでない場合にはそうしなくてもいい。BREW2.1の場合、データフォルダファイルのバック、フォアは、実は端末依存（３１日追加）Ｖ３．１には、問題がある（ここまで））。

　したがって、コールバック関数内で、読み終わったらフラグをあげて、フラグがあがっていたら先に進み、フラグが上がっていなかったら、待ちになる。

　しかし、直前に読んで待ちにするのも、ユーザーレスポンス的に、なんなんで、先読みしておいて、データが必要になる前に、読み込み完了になるようにしておく。

　ただ、じゃあ、先読みはいつからやる？っていわれてもねえ。。

　作ってみて、調整してみないとわかんない。。

---

　つー意味が、業務アプリだけしかやんない人には、通じなかったりする。

　大量データがあり、そいつを、ソートして云々とか、いろいろ時間がかかっても、業務アプリの場合、先読みして、バックでやっておくということは、あまりしないと思う。
　その場で、やる（処理時間中、ユーザーを待たす）。
　なので、どのタイミングで読むというのは、仕様上、明確に書かれる。


　ケータイの場合、そこで、ゲームなり、作業なりが、とまるとまずいので、バックでよんでおく。

　このとき、読み始めのタイミングは、はっきりしない。とにかく、必要なときまでに読んでればいいし、それが間に合わなかったら、いろんなところで、時間稼ぎしたりする。なので、あんまり、仕様上、読み始めのタイミングが明確にかかれなくても、「ここまでに必要」っていうのがわかれば、よかったりする。

　っていうことが、この前、話し通じなかったので、ここに、かいておいてみたりする。

PHPのGCを使うため、減色処理することを考えてみる(その１：３１日修正）

　ＰＨＰで、ＧＣを使って、前に画像をだしたとき、インデックスカラーにしないとうまくいかなかった。

　なので、今日は、減色処理の方法について、しらべてみた。
（はじめは、そのつもりだった・・あとで、減色しなくても、いい気がした）

---

　まず、減色処理一般のお話は、ここ

で、ImageMagicというフリーソフトで減色処理できる
ImageMagicのサイトはここ
http://www.imagemagick.org/script/index.php

使い方はここ

---

プログラムの話。
このひとは、距離を求めている。ただ、この人もかいてるけど、グラデのところだと、トーンジャンプしちゃうよねえ。。
　
うーんと、初めにあげたのを見ると。ディザ法？それって、網点だよねえ・・・

あみてん？？そっか（＠＿＠）！あみてんにすればいいんじゃん（＾＾）

・つまり、１ドットを（かりに）４ドットで表現する。

・元のRが0のときは、４ドットＲは0、
　元のRが1のときは、３ドットＲは0、１ドットＲは４
　元のRが2のときは、２ドットＲは0、２ドットＲは４
　元のRが3のときは、１ドットＲは0、３ドットＲは４
　元のRが4のときは、４ドットＲは４

とすると、
（以下、３１日修正）
Ｒ一色につき、4ドットとびにすると、256/4=64階調、
これが、３色なので、
６４の３乗＞＞２５６（＞＿＜！）

逆に、２５６に収まるようにするとすると、
１色６階調、って、さすがにそれだと、おおきな網点になってしまう。
（あるいは、間引くか？）

　なので、この考えは、無理ですね（＞＿＜！）

　ほかの方法を、気が向いたら、今度書きます

（以上、３１日修正）

　とりあえず、思いついたことを、ここにメモした次第であります！
　（つーことで、これは、やってないのだ）

「青森市が６４００万円相当のシステム破棄、LinuxからWindowsに変更」のニュース

　こういうニュース
青森市が6400万円相当のシステムを廃棄
http://slashdot.jp/articles/06/01/28/0741259.shtml
　がスラッシュドットにでて、話題になっているが、青森市は、無用な批判を受けないために、どうして、そういう経緯になったかの情報公開をしたほーがいいんじゃないかと思う。

---

　ニュースを単純に読んで推測すると

・青森市は、戸籍など住民記録分野の開発を依頼した。

・普通に考えれば、住民票のシステムは、漢字に当て字（つーか、ありえねー文字）を使っていたりするので、フォントを作ったり、かな漢をいじったり、分けわかんないコードをＤＢに格納したり（ここで、漢字チェックが入ると、こけるけど、バイナリにすると検索がたいへん）とかで、そりゃーそりゃー、たいへん。

・その部分を考えないでＬｉｎｕｘで発注した

・そーしたら、難航するわなあ。とうぜん。

・で、その部分の文字は、フォントがないから文字化けするし、その文字は、第二水準のコードを当てているはずなので、ＤＢでも、うまく動かない。
　東奥日報で言っている、文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ、は、この状態を指すんだろう。

・しかし、もし、その部分を考えないで発注したとすれば、とーぜん作らないわけで（つーか、その部分まで考えて６４００万つーのは、こんど安すぎだと思う。フォントもかな漢も検索部分のＤＢのつなぎも、ぜーんぶ１からつくるとしたら、６４人月じゃあ、それだけつくって、終わってしまう）。

・とーぜん、受託会社側は、その話は、別の話ということで、
　　今まで納品した部分を第一次開発、
　その文字化けや情報が正しく呼び出されないなどの対応部分である、
　　フォント、かな漢、ＤＢ部分周りなどを、第二次開発として、
　別発注にするよなあ。。

・で、その交渉がまとまんなかった。。。

・なので、結局、前のシステム開発会社である、富士通のを使うことにした

・そーすると、前のシステムはWindowsなので、
　＝上記の部分はWindowsでできているので、
　Ｌｉｎｕｘから、Windowsにかわることになった。

　っていうだけの、あったしまえの話で、なんか、その記事にある、コメントにいろいろかかれてますが、考えすぎのような気がするんだけどなあ。。

　もし、こういう理由だとすれば、住民票システムでは、こういう問題が起こることは、（官庁アプリは専門外の）ウィリアムのいたずらでも知っている、業界常識なので、発注側は、それすら要件仕様（入札条件？）に入れてなかったとすれば、この記事で、受注会社から言われているように「稼働遅れの主な原因は、アカデミー側の能力不足」（アカデミー側＝発注者側）といわれても、しょーがない気はする。

　でも、その仕様で６４００万で請けちゃう会社も会社といえるけどねえ。。

---

　つーよーに、いろいろ、憶測を呼んでしまうから、こーいう案件は、情報公開したほうがいいと思うけど。。

　もちろん、失敗例は、成功例なんかとは、比べ物にならない、次の大成功のための極秘情報なわけで、青森市は、この失敗事例により、ほかの市が、オープン化で今後失敗するようなことをいち早く察知し、それと富士通の現状の事例と徹底比較することにより、それを回避する方法を知ることができるというメリットはあるので、公開できないっていわれちゃうと、できないんだけどねえ。。。
（青森市の市民の税金を使って、そんなに大事な情報を入手したのに、なんで、公開しなきゃなんないんだ！っていわれたら。。）

---

　ただ、１ついえることは、失敗したから、無駄遣いって考える考え方は、やばすぎると思う。
　もし、こういう小さな失敗すら認めないと、今度、もっと、どえらい失敗をしでかしちゃうよ！

　大きな失敗をしないための授業料程度じゃないのかなあ。。

ケータイアプリにおける、バッチ的な大量データの転送方法（メールっていう手もアリ？）

　ケータイアプリ（iアプリ、BREW,Vアプリいろいろあるけど。。アプリに限らず、i-mode,EZ-Webまでいれてもいいかも）において、少量のリアルタイム的なデータ転送には、ＨＴＴＰプロトコルが用いられると思う。

　つまり、ＣＧＩをＧＥＴないしＰＯＳＴで呼び出し、データを引数で送るとか、ファイルなどのアップロードを行うとか。。

　ただ、もっと大量なデータを送りたい、ただし、バッチ的で良いという場合がある。
　たとえば、マスター更新や、日々データを一括で送り、夜間バッチをかけるとかのケース。ＢＲＥＷなどではＦＴＰに対応している関数があるわけではないし、ＢＲＥＷ以外でも、そもそも、そんな大量データをＦＴＰ（ないしはＨＴＴＰ）で、つなぎっぱなしにして、送るのがいいかどーかという問題もある。

　キャリア的にみれば、反対だろう。ダブル定額にされてしまえば、つなぎっぱなしにして送られても、お金はある一定以上取れないし、そのわりに、回線利用率が高まってしまい、（回線の混雑緩和のための）経費がかかってしまうので。

　ユーザー的にみても、つなぎっぱなしはよくない。アプリのとき、電話がかかって割り込みされたら？
　割り込みされる場合を想定して書くか、割り込み禁止の方策をとらないといけない。
　でも、割り込み禁止って、アプリが動いている時間が短いならいいけど、一日中動いてて割り込み禁止って（＾＾；）？っていうことになる。

---

　このため、「大量なデータを送りたい、ただし、バッチ的で良い」場合、どうするかだけど、ひとつの考えとして、メールを利用するっていうのがあるんじゃないかと思うんですよ（今、思った）。

１．送る必要のあるデータをデータフォルダに入れておく
２．そして、利用者は、１のファイルを添付して、サーバーにメールを送る
３．サーバーはそれを処理して、結果や返信データをケータイに送る
４．ケータイは、３で送られたデータを保存して、利用する必要があれば、添付ファイルをデータに保存する
５．プログラムが起動するとき、４で保存されたファイルがあるとき、それを展開する

みたいなかんじなのかなあ。。（ちょっち思いつきで書いているので、できるかどうかは裏とってない）

---

　まあ、これを自動化するかどうかって言う問題はあるにしろ、データ転送の手段としてのメール利用っていうのは、個人的には「あり」だと思っている。

　システム的に、かっちょわるいんで、ウィリアムのいたずら以外、あんまり、みんな言わないけどね。。

（ケータイ以外で、結構メールで逃げるっていう提案はするんだけど、かっちょ悪いと、否定されること多い。。

　って、システムって、いつからカッコよさ（流行言葉を織り込むこと）を要求されるようになったんだろう。。＾＾）

ペアプログラミングだと、生産性・品質が本当に上がるのかを、認知心理学的に考える（その３）

　今日は、「知らない情報を持ち寄って、物事を解決するということは、効率的に行えるのか？」ということについてのお話です（心理学では、隠れたプロフールというお話になります）。

■■　前回までのお話。

　その１のとき、ペアプログラミングだと、効率的だ！と主張するには、ふつう、４つのことが考えられると書きました。
（１）生産量が上がる
（２）品質があがる
（３）１人では思いつかなかったことが思いつき、できるようになる
（４）専門分野が違う人たちが協力して、１つのことができるようになる。

　で、（１）、（２）については、社会心理学では、「集団的手抜き」という問題で論じられ、これは、集団でやったほうが（個別でやるよりも）、生産性が低くなるということを書きました。
　（３）については、その２で、これはいわゆる文殊の知恵といわれるやつだが、そういうものはおきにくく、むしろ、周りの空気により、正しい考えもつぶされてしまうことがあるというのを、書きました。

　で、今日は（４）です。

---

■■　１人のひとしか知らない情報を皆に提供しあって、物事を解決できるか

（４）の「専門分野が違う人たちが協力して、１つのことができるようになる」は、いいかえると、「１人のひとしか知らない情報を皆に提供しあって、物事を解決できるか」ということになります。そして、「１人のひとしか知らない」＝他の人からは、隠されている属性ということで、「隠れたプロフィール」といいます。

　で、この実験結果が、放送大学大学院の「認知過程研究」のテキストｐ１４６からでているんだけど、結果は衝撃的？つーか、あたりまえっつーか？？

　メンバーの数が増えるほど、そして情報を完全に共有しあおうとすればするほど、１人しか知らない情報（隠れたプロフィール）は共有されず、皆が知っている情報が、より共有されるようになる。

　そりゃーそーっすよねえ。だって、相手しか知らない情報を聞き出すって、難しいよ！

　自分は知らないんだから。。

　つまり、情報を共有するためには、あらかじめ、皆が知っていないと共有できないって言うことになる。
　たとえば、会議なんかするとき、「今度の新しいシステムについて、考えますので、皆さん集まってください」といって、各分野の専門家を集めても。。。皆が知っていることしか意見が出なくて、堂堂巡りになるということ（＞＿＜！）

　この場合、あらかじめ、レジュメをくばって、「これとこれとこれについて話します。これについての資料はこれで、これの資料はこれで。。。」という形で、専門外の人にも、情報を提供しておいて、あらかじめ情報を共有しないと、話にも登らないつーこと。。

　。。って、あたりまえだよねえ。。

　だけど、実際には、たしかに、「専門の人を集めれば、どーにかなるだろう！」で終わってしまったりする。

　つーことで、「専門分野が違う人たちが協力して、１つのことができるようになる」かというと、「人を集めただけでは、情報は共有されず、できない」という結論になるのだ。まずさきに、情報を共有してから、人を集めないと。。

---

　ただ、じゃあ、（１）から（４）まで、ダメだとしても、「じゃあ、ペアプログラミングは生産的ではないですね。やらないでおきましょう」って、それで済む問題ではないのだ。

　ふつう、SEやプログラマには、プロジェクトの進捗方法を決める権限はない。マネージャーやその上の上層部が、「ペアプログラミングで行きましょう！」といったら、非効率だろうがなんだろうが、それでやらなければならない。

　つまり、ペアプログラミングが、効率的かどうかなんていうことが問題ではなく、効率的にペアプログラミングをやる方法が問題になる。

　認知心理学的に言うと、集団による問題解決を、有効に働かせるには、どうしたらよいかが問題である。

　で、そのことだが。。それは、また今度書くことにします。

　もう、けっこう長く書いたし、きりいいので。。

お気に入りのブックマーク更新チェックと整理をPERLでやるとしたら、こんな手順？

　トラックバックいただいた、このかたの、ブログ
FREE DIALY
http://diarybyo.seesaa.net/article/12316405.html
のお話(以下、斜体はそこから引用）


ブラウザ起動時にお気に入りブックマークに入れてあるサイトの更新を調べ、


を、PERLでやるとしたら、こんなかんじなのかなあ。。と思ったので、とりあえずメモ。
（ただし、Windowsの場合）

---

まず、ブラウザの「お気に入り」は、じつはここにある

C:\Documents and Settings\（その人のログイン名）\Favorites

ここに、ショートカットの形で入っている。

（その人のログイン名）は、人によって違う。
C:\Documents and Settingsは、ドキュメントがあるところで、マシン環境によって、ちがうかも。

で、要件は、

（１）このお気に入りのなかにあるプログラムを見て、URLを探し
（２）そこにアクセスして、更新しているかどうかを確認し、
（３）更新していたら、あるいは、サイトがなかったら、表示
（４）ショートカットの最終更新日を設定

だよねえ。で、これをPERLでつくることを考えると、

---

■■　（１）このお気に入りのなかにあるプログラムを見て、URLを探し
　C:\Documents and Settings\（その人のログイン名）\Favoritesにある、お気に入りのショートカットのファイルの中身を見ると

[InternetShortcut]
URL=http://www.paniponi-dash.com/

っていう行がある。この行をみていけばいいのかな（ちなみに上記は「ぱにぽに」のURL)

■■　（２）そこにアクセスして、更新しているかどうかを確認し

（１）で得たURLをもとに、まず、そのサイトにアクセスする。
で、そのとき、レスポンスヘッダのLast-Modifiedが、最終更新日だと思うので、
その日付と、ショートカットの最終更新日を比較（すると、なぜ、更新されている
かがわかるかは（４）を参照）

■■　（３）更新していたら、あるいは、サイトがなかったら、表示
　（２）でレスポンスが４０４になるとか、更新されていたら、エラー表示をてきとーにしてくれ。

■■　（４）ショートカットの最終更新日を設定
　最後に調べたら、ショートカットを上書きあるいは、タッチして、更新日付をその調べたときにする。そーすれば、（２）のとき、ショートカットの日付とHTTPで帰ってきた最終更新日をみれば、更新されたかどうかわかる

---

　このプログラムを、スタートアップかなんかにいれておくなり、タスクに設定しておいて、自動的に、バックで動いてくれるようにしておけばいいのかなあ・・・

　ごめん、今、時間ないので、プログラムで作って確かめる暇ない（＞＿＜！）

P.S　あ、これを書いておかないと。。
PERLのHTTPクライアント（つまり、（２）のプログラム）さんこうれい。
http://x68000.q-e-d.net/~68user/net/http-2.html

BREW携帯端末のメーカーごとのクセから考えると、三洋には、がんばっていただきたーい！！

　ＢＲＥＷの開発をする場合、メーカーごとの端末のクセがあり、それによってプログラムを変えないといけなかったりする。
　このクセだが、大きく２とおり（あるいは３通り？）に分かれるんではないかなあ。。って感じる。
　ちなみに、このクセが一番良く現れるのは、カメラの動作であり、あと、BREW2.1のIFileCpの動きとかでも、そんな感じがする。

　で、カメラで、２とおりというと、お察しのとおり、コプロセッサをつんでいるかどうか。。で影響する。つまり、FPS（だっけ？）のリストで、7FFFを返すかどうか。

　ちなみに、カメラは、このコプロセッサをつんでいるかどうか２とおり＋ソニーエリクソンというかんじになる。コプロセッサをつんでいても、普通の表示のうごきと、ソニーエリクソンはちょっちちがったりする。

---

　で、そんなこんなで分類していくと、三洋のケータイの動きが、ＫＤＤＩ仕様または、あるいは、わかりやすい、かんたんな仕様に基づいていることがわかる（あることだけは変なんだけど、それがＫＤＤＩ仕様みたい。これについては、今度詳しく）。

　ということで、ウィリアムのいたずらの場合、まず、マシンで確認するとき、
１．サンヨーの端末で確認する
２．東芝の端末で確認する
３．ソニーエリクソンで、「そーかんたんにいかねーよクマー」と怒られる
４．日立、京セラとあわせていく
つーかんじで、やるので、サンヨーは、大切な会社なのだ！！ＢＲＥＷ開発においては。。

---

なのになのに、三洋、いろいろ増資とか、いろいろ話題ですねえ。。
ほかの部署はドーデもいいけど、三洋のケータイの部署だけは、のこしてくれ。どっかが買収してもかまわん。ＫＤＤＩ仕様にあった端末を出し続けてくれるなら。。

　まえにＹＡＨＯＯ掲示板で、野中ともよ会長のかわりに、シンボル的な存在のほうがいいなら、いっそのこと原田ともよ（知世）でいいんじゃあーという意見があったが、

うん、原田知世でもＯＫだ。
いや、眞鍋かをりでも、
ＫＤＤＩ仕様ということで、仲間ゆきえでもＯＫだ、

とにかく、三洋のケータイ部門はがんばって、残ってくれ（＾＾；）

楽天に、「ライブドア事件被害株主による集団訴訟」っていうブログができたみたいよ

　本当は、本家の楽天日記に書くネタなんだけど、あちらの日記は、投稿数に制限があるので、とりあえず、この分家に書いておきます（もし、今日一日、ほかに本家でネタがなかったら、本家にもかくかも）

　まあ、どーいう動きをするのか、よくわかんないけど、
　「ライブドア事件被害株主による集団訴訟」
　っていうブログができたみたいよ。

　ここ　 http://plaza.rakuten.co.jp/livedoorsuit/

　ただ、ブログなんで、相手の人がわかんないんで、
　（連絡先がYAHOOメールなのだ。。。
　　で、写真も出てなければ、プロフィールもはっきりしない。。）

　本当に被害を受けた人が、参加したり、コメントつけるべきかどうかは、疑問だけど・・
（それで、不利益をこうむったとしても、一切ウィリアムのいたずらは、しりません。
　自己責任でやってくださいませ）

、まあ、こーいうサイトができはじめたということだけ、書いておきます。

コンピューターウィルスに特徴的な挙動とは？

　富士通が、「未知のウィルスの通信も検知し、情報流出防ぐ装置」というのを、開発した？？らしい。ここのスラッシュドットニュースより。

　で、その記事の中に


富士通研究所が開発したウイルス特有の通信パターンから感染したコンピューターを検知する技術を採用し


　という文があるのだが、そこのコメントに、:「ワームの感染活動時に見られる特徴的な通信」って何？っていう質問があって、その回答として、以下の文があったので、メモ


富士通の研究というわけではないですが、この分野の学会発表を何度か聞いたことがあります。
ワームに特徴付けられる挙動の例としては、

特定のポート番号へのアクセス数の増大
→そのポートがdefaultとなっているアプリケーションの脆弱性をついたワームが広がっている
DNSのMXレコードがたくさんひかれる
→メールで感染するワームが広がっている
みたいなものがあるみたいですね


　ほー、なるほど。でも、「そのポートがdefaultとなっているアプリケーション」を、急に使い出したということもあるんじゃあ。。とか、そーいうツッコミをいれてはいけないんだよね、きっと。
　
　あ、ちなみに、上記の記事に関して


ワーム振る舞い検知 (スコア:5, 参考になる)

Anonymous Coward のコメント: 2006年01月25日 20時06分 (#871026)

ハードウェアによる検知技術だそうです。
TCPポートスキャン、UDPポートスキャン、ホストスキャンなどの種別を最短で10ミリ秒間隔でチェックして検出するんだとか。

ただ、

ブラウザ起動時に複数ページを読み込んだりした場合。
FTPとかtelnet使っててサービスの動作するホストを端末が探索するような場合。
ネットワーク管理装置から端末検索などを行なった場合。
IPマスカレードを行なっている機器からのアクセスの場合。
多数のリンクからなるWebにアクセスが頻発した場合。

なんかだと誤検出することがあるらしいです。
このへんはコマンドを打つことで閾値や検出対象から外すことで対応はできるそうですけど。

なんだかちょっと調べてみると思ったより低機能なきがしてがっかりです。

# がっかりしたのでAC


っていう、コメントも、載っていた。
うーん、そーすると、ポートスキャンとかやるプログラムを書いた場合も、だめってこと。。

って、そんなんやるんじゃねーよ（－＿－）

って、（＾＾；）

「パソコン救助隊」隊長眞鍋さんファン＆メガネっ子大好き必見のＣｈｅｃｋ ＰＣ？

　経済産業省が、眞鍋かをりさんを、「パソコン救助隊」隊長として、眞鍋さんファンには、きっと必見？な、サイトをつくっている模様。

Check PC! マナベにまなべ。／経済産業省
http://www.checkpc.jp/　

っていうサイトなんですけど。。。

　うーん、これって、セキュリティのページというより、セキュリティをネタに、眞鍋さんファン、あるいは、メガネっ子大好き！な人のためのサイトというかんじが。。（＾＾；）

　ま、いいんですけどね。それで。。

ブログや掲示板の風評をチェックする、「CGMマイニング ネットボイス」

　１月２６日版（実際には２５日夕方に出ている）の日本証券新聞の５面に、「ネット上の風評、調査します」という題で、ガイアックスの「CGMマイニング ネットボイス」（新聞ではＣＧになっている）が紹介されてました。

　その「CGMマイニング ネットボイス」についての詳細は
こちら
http://www.gaiax.co.jp/jp/gaiax/press_060120.shtml

そこから引用すると（以下、斜体は上記サイトからの引用）、


　「CGMマイニング ネットボイス」は今日脅威的な影響力を持っている各種ブログサービス、各種有名ＳＮＳ、某匿名巨大掲示板などオンラインコミュニティ各種メディアを風評調査の対象とし、ユーザーから発せられた様々な情報をより詳細に、正確にリサーチし、収集いたします。


ただし、


　また「CGMマイニング ネットボイス」では独自のテクニックを用い、人の手で、人の目で調査するため、検索エンジンや、マイニングシステム※では見つけることの難しいクローズドＳＮＳ内の情報や、オンラインコミュニティ独特の顔文字、アスキーアートなど様々な“言語”に対応することが可能となっております。


だそうな（＾＾）

おー、人力っすかあ。。

で、分析してくれる項目は


基本分析項目は「キーワード」検索語、「ポジティブ・ネガティブ」（好意的か否定的か）分類、「トピックス」（どのような点（主題）に顧客の意見が集中しているのか）収集、の3点です。


で、人力のメリットとして


■「人力」だから可能なカスタマイズ
　速報性とお客様のニーズを十分に満たすリサーチは人の手と人の目で検索するからこそ可能です。「ネガティブな書き込みを特に見つけて欲しい」「書き込みを発見次第報告して欲しい」「改善策になりそうな書き込みを優先して見つけてほしい」といったような検索ロボットでは追いきることの難しい、状況に応じたお客様ごとのご注文に可能な限りお応えいたします。

---

でも、これって、商売になるのかなあ。。。
もし、商売になるんだったら、これをやるアルバイトっていうのも必要だよね。

ウィリアムのいたずらも、暇なときには、アルバイトしたいなあ。。
（最近は忙しいので、ちょっと無理だけど。。）

ニートの人とかも、いいんじゃないかなあ（＾＾）

ライブドアの社長に弥生の社長が就任！弥生もワークスアプリ同様ＳＯＸ法意識するかな？

　ライブドアの社長に弥生の平松社長が、就任することになりましたね！
　ライブドア本体の粉飾決算についても、捜査されているときに、弥生会計の社長が就任って言うのも、なんとも皮肉というか。。（＾＾；）

　ただ、これって、ある意味、ピンチをチャンスに変えることができるかもしれない。。弥生にとっては。。（ライブドアにとっては、しらんが）

　前にも書いたが、アメリカの場合は、このような、粉飾決算として有名なのはエンロンのときの話であって、そのエンロンのとき、企業会計をクリーンにするためにＳＯＸ法（サーベンス・オクスレー法、以下ＳＯＸ法と略す）ができ、そのＳＯＸ法の日本版について、すでに出ているという話は、昔のブログに書いたとおり。

　で、そのとき、アプリケーションの取り組みについては、かいてなかったけど、実は、ワークスアプリケーションは、これに力を入れていて、ＳＯＸ法のセミナーについて、いっぱいやっている（ここ）

　一方、弥生の場合は、中小企業が中心なので、弥生のブログをみるとわかるように、年末調整、確定申告が中心であり、ＳＯＸ法については、あんまり触れていない。ホームページをみても。。

　しかし、中小企業でも、なかには上場を目指す会社もあるし、そうでなくても、会計を透明化、内部統制したいというニーズがあるかもしれない。というか、ＩＴガバナンスの観点を取り入れたいという会社は、中小でもでてくるかもしんない。

　そこで、弥生でもその考えを取り入れるということは、アリだとおもう。
　中小企業向けでも。。

　で、ライブドアの信用回復のために、日本版ＳＯＸ法を先取りするカタチで、ライブドアの企業統制を行い、その成果を弥生に取り入れるとなると、弥生の宣伝に。。。

　ここまで、書いて思った。。

　宣伝には、なんないね（＾＾；）

　（はじめから、ちゃんとやれ！って言われそうだもんね）

---

　メモ
　ＳＯＸ法と、ＩＴガバナンスとかが書いてあるサイト
迫り来る日本版SOX法、IT統制の準備はOK？
http://www.atmarkit.co.jp/fbiz/cbuild/serial/doukou/15/doukou15.html