ブログ炎上情報を共有するサイト「炎ジョイ」開始

えんじょい（「炎ジョイ」）ですか（＾＾；）

ここのニュース
ブログ炎上情報を共有するサイト「炎ジョイ」開始
http://headlines.yahoo.co.jp/hl?a=20071121-00000935-san-ind
によると（以下斜体は上記サイトより引用）

大量のコメントが殺到する、いわゆる「炎上」状態となったブログやホームページ（ＨＰ）の情報を共有するソーシャルブックマークサービス「炎ジョイ」が２０日、公開された。炎上しているＨＰの情報をユーザーが投稿できるほか、ＨＰ上に動画共有サイト「ニコニコ動画」風のコメントを書き込むことができる。


ちなみに、そのサイトは、
ここ　http://enjoy.mocovideo.jp/

今日の大火事って（＾＾；）

CCNA1のお勉強をゆるーくやってみる。その１１：クロストークなど

　シリーズ「CCNA1のお勉強をゆるーくやってみる」です。
　今、物理層の、ケーブルテストのお話です。
　ケーブルのテスト項目は、

　　　・ワイヤマップ
　　　・挿入損失
　　　・近端クロストーク（NEXT)
　　　・パワーサム近端クロストーク（PSNEXT）
　　　・等レベル遠端クロストーク（ELFEXT)
　　　・パワーサム等レベル遠端クロストーク（PSELFEXT)
　　　・反射減衰量
　　　・伝播遅延
　　　・ケーブル長
　　　・遅延時間差

とあって、前回ワイヤマップをやりました。今回は、それ以降です。

---

■挿入損失と反射減衰量

　２つのパソコン間に、ケーブルを入れると、信号が減衰します。
　長ければ長いほど、また伝えるものの周波数が高いほど、減衰します。

　で、さらに、このケーブルにコネクタを付けた場合、インピーダンス（交流における抵抗のようなもの）の不整合が起きる場合があります。インピーダンス不整合が起きると、反射されてしまい、それが問題を起こします（これをジッタといいます）。

　さてこのとき、パソコンにこのように、ケーブルをいれて、コネクタを付けたおかげで生まれた（上記のような）減衰を、挿入したからおきた減衰ということで、挿入損失、また、反射することによる減衰を反射減衰量とよびます。

---

■クロストーク（漏話）

　クロストークは、いくつかの電線がまとめてあったとき、自分の線以外の周りの線の信号の影響を受けてしまうことを言います。で、その方向その他から、いくつかの種類があります。

いま、A地点からB地点まで、電気信号を送ることを考えたとき、

・近端クロストーク
　A地点から信号を出して、A地点からクロストークを測定する。
　（なので、近いほうなので近端）
　AからBへ信号を出したら、反対側（BからAへ）信号を出してきたものが、雑音を発したりすると、この近端クロストークとなったりします。
　で、これは、UTPリンクのある対から別の対と、リンクの両端から測定する必要があるそうです(良く分かってません^^;)。

・遠端クロストーク
　A地点から信号を出して、B地点からクロストークを測定する。
　減衰した信号がのるため、遠端クロストーク(FEXT)は近端クロストーク(NEXT)ほど、問題にならないそうです？？

・パワーサム～

　近端クロストーク、遠端クロストークで、「パワーサム」という言葉がつくものは、自分以外のほかのケーブルすべてからの影響をまとめて計ったものです（上記のクロストークは、自分と他のもう１本との関係を書いたが、そうではなく、他の複数本というか、すべてとの関係）

---

■伝播遅延、ケーブル長、遅延時間差

　これらは、読んで字のごとくです。
　UTPの場合、より線が４対８本はいっています。この８本の線の長さが、普通はおなじですが、びみょーに、(切り方や加工のまずさなどにより）違ってしまうこともありえるわけです。そーすると、　ケーブル長がかわって、伝播遅延、遅延時間差などが怒ってくることになります。

　ほんとうに、ごく短い長さなので、問題ないって言えば、問題なさそうに見えます・・が、しかし、送っている伝送量もすごいわけで、（１０GBPSとか）そーすると、ほんのごく小さい遅れでも、大問題になってしまうようです。

---

ということで、ケーブルテストっていうか、ケーブルおわりです。
次回は、ケーブル以外の機器、まずはコネクタからみていきます。

動詞の名詞化と、オブジェクト指向におけるクラスとメソッド。

　サ変名詞ということばがあります（サ変動詞ではなく、サ変「名詞」）

　受注、注文のように、「する」をつけて（サ変）動詞にすることができるものをさすのですが、このようなものは、機能でもあるし（つまりメソッドにもできるし）、データにもなる（クラスとしても扱える）という話になってます。

　具体的に言うと、商品クラスで「受注する」というメソッドもありえるし、「受注クラス」というかたちでまとめることも考えられます。

　で、サ変名詞をどう扱えばいいかなのですが・・

　サ変名詞が仕様書上にでてくる（「受注金額」のように）場合、サ変名詞（ここでは受注）をデータ（クラス）にして、保存しておかないと、他のプロセスで、(直後に連続して起きない限り）使えません。

　たとえば、納品時、「受注商品、受注数量をピッキングして」という場合、受注データを保存しないと、ピッキングができません。ということは、クラスとして存在し、そのデータを保存させているっていうことです。

　で、データを保存するためには、その機能を実現しているってことです。
　受注しないのに、受注商品があるわけはないので、受注という機能があるはずです。
　ちなみに、オブジェクト指向の場合、商品のメソッドのなかに受注があっちゃ悪いって言うわけじゃないですけど、こういうサ変名詞の場合、サ変名詞のクラス（受注クラス）を用意し、その機能(受注）を実行するときには、メソッドとしてコンストラクタを呼び出せば、解決します。

　ということで、サ変名詞は、クラスとして扱い、それをサ変動詞として扱うときには、コンストラクタなど、そのサ変名詞のメソッドとして扱えばOKになります。

　で、問題は、このサ変名詞があって使っているということは、サ変動詞である機能（＝コンストラクタ）がどこかにないといけないのですが、仕様上、抜けても気がつかないということです。