Fluctuat nec Mergitur (FR) -- “たゆたえど沈まず” (JP)

以下、引用。
/**
悪天候で、船が荒波にもまれ、舵が折れ、帆がさけて制御できない状態になったとしても船を沈ませることだけはしない!
という船乗りの人の願いと心意気を表している言葉であり、花の都、パリの市の紋章に刻まれているフランスの人が最も好きな言葉でもあります。

「今の自分は不安や悩みで揺れに揺れまくっているけど、どんな状況になっても諦めず、前に進む気持ちだけはしっかり持てば、最後には必ず目的地に辿り着く。
なぜなら、自分という船を支えてくれている仲間たちがいるのだから。」という意味です。

生きている限り、不安や悩みは尽きることが無いけれど、そんなときに頭をよぎるのが、「たゆたえど沈まず」です。

ふんわり包み込んでくれるような力強さがある言葉です。

「たゆたえど、沈まず」自分を支えてくれている仲間たちの存在と感謝を忘れなければ、「船」はまた前に進み始めます。

*/
//引用元:
このガジェットでエラーが発生しました

2011年12月17日土曜日

Devlove1210のHangerFlightを通して考えたこと。

どもども。
お久しぶりなリルムです。
今回は12/10に開催されたDevLove Hanger Flight -Snow Baragge-
に参加して現場について考えたことをひたすら書き出しました。
以下、本文です。

現場って何だろうと。
場というぐらいなんだから、色んな力が相互作用して出来る一種の状態なのかなと。

この世界にある全ての現場については知ることも語ることも出来ません。
ですので、私のカバー出来る範囲のリーダーシップやマネジメントという側面を通して現場について考えたことを書いていきます。

世の中に色んな組織があって、その最前線が現場。
現場が組織の中にある以上は組織としての現場に縛られる事も多々あります。
少し箇条書きします。

1.組織としての現場にあるもの(以降は、1.として表記)
・役職による評価や人事権などのトップダウン型の影響力(業績評価システムや論功行賞など)
・組織図という静的構成による部署管理(社内ポリティクス)
・組織であるが故に生じる書類手続き
ステークホルダーの意志や社内コンプライアンス

こんな感じでしょうか。
こういった厳密な規則や命令系統による静的な管理。
これが組織としての現場にはあります。

この組織としての管理を追求した最たる例は軍です。
軍には、細かな階級制度、厳密な軍規、それから生じる強力かつ短時間で実行される命令系統があります。

武勲や能力は適切に評価され、その度合いに応じて階級は上がります。
任務内容を超えた功績には名誉勲章の賞与があります。

頑張ればその分だけ評価される。
その点では最も努力に対して平等な組織であるとも言えます。
また、愛国心や家族が住む国を守りたいという共通のビジョンやコンセプト(以降は、目標と表記します)も共有しているはずです。

そして、軍ではない組織にも必ず会社の設立当初には起業者が掲げる明確な目標が共有されていたはずです。

ここを過去形で表現したのは、会社が大きくなったり時の経過により、組織全体での目標が共有されなくなったり、全く別の方向を向いてしまう事が少なからず起きている組織が多くあると思ったからです。

どれだけ時が経とうと、どれほど会社が大きくなろうと、その目標を常に共有し実現していくためには、強力なリーダーシップが必要です。
しかし、トップダウン型の特性を示す組織をまとめる人が必ずしも、純粋なリーダシップを発揮し続ける事は保証されません。

命令や既得権を例にとります。トップダウン構造から発生する権益は、かなり複雑な影響力を持つものだと私は思っています。

上司からの命令に従う部下が、上司が持つ人事権や給与などの評価のために命令に従うという場合があります。
その場合、部下は命令をこなした結果得られる副産物のために動いたとも言えます。

そして上司は、(上司の持つ人事権や給与のために)部下が動いた結果を自身が持つリーダーシップと勘違いしてしまう。

そこで、基本的に50:50であるはずの人間同士の関係が歪んでしまいます。
その結果、現場では不満が募るが、そのシステムにより反感などは黙殺されてしまう。

さらに役職などは一度手に入れると、よっぽどの事がない限りはその管理システムにより失われる事がなく、その構造の上にいくほど強力になります。
時には、その機会は均等ではなく、ほぼ手に入れることが不可能な場合もあるでしょう。

つまり、
A: 組織としての目標の共有
B: 平等な評価
C: 本来50:50であるはずの人間関係
の3つの要因が失われると組織の形は歪み始め、現場が辛いものになっていくのです。



そこで、少しでも現場を変えていこうという変革期が今現在であると私は思います。

XP, アジャイル, スクラムなどのプロジェクト管理の手法を変えることも多くなってきています。
トップダウン式のウォータフォールに変わって、少しでも目標への動的な影響力を残すための試みといえるでしょう。
アジャイルでは、イテレーションと呼ばれる期間で時間を区切ります。
前の期間の反省点や日々変わっていく状況が次のイテレーションでは考慮されます。

つまり、1.に示したような組織管理としての現場という認識が変わってきているのです。

本来は表面化されない、目標に対し持ちうる意志や感情の繋がりの相互作用によって出来る現場が(以降、2:と表記)ようやく認識され始めたのです。
プロジェクト管理については、ここでは掘り下げないことにします。

誤解を与えるような書き方だったかもしれませんが、マネジメントは組織に一定の均一化をもたらす事が本来の目的でありメリットです。
副作用の影響の方が大きくなったために現場が機能不全になっているのです。


そこで、管理システムによるマネジメントの対極にあるものを考えてみます。

2: 相互作用によって出来る現場
・現場は組織本来の目標を実現する重要な最前線
・この人と一緒に働きたい思う魅力などのプロジェクトへの帰属性
・人々の相互接触による動態的な場。
・メンバの自発性や行動力の重視による柔軟な発想
・個々を最大限に活かすためのコーチングやメンタリング

こんな感じでしょうか。

ここに表れているのは、"互助・互恵の精神"や"奉仕と献身"の精神でしょうか。
本来の目標意識を共有し、メンバそれぞれが自発性を持ってプロジェクトを進めていく。

一つの考え方としては、
”マネジメントは手段の一つであり、2:によって生じる副作用を軽減させるもの”
と考えてみてはどうでしょうか。

つまり、メンバ全体の協調性や個々人の個性を著しく崩すスタンドプレーを防ぐための自浄作用としてマネジメントを認識するのです。

一つ事例を挙げます。
@IT自分戦略研究所のコラムで

”プロジェクトのプログラマからマネージャになり、メンバとの関係が悪化した。
以前は、誰かがミスしても自分がカバーすればいいと思っていた。
しかし、自分がマネージャになったら、マネージングやその役職の責任が邪魔で、前と同じようにプログラミングでカバーすれば良いとは思えなくなった。"

という話しを読みました。
この話しには、現場への認識が2.から1.へと変化していく様が表れています。

このコラムでは、”スーパープログラマとしてプログラマに技術的役職を設けている企業もある”という話しをコンサルタントから聞き、最終的にそういった企業への転職と話しが進みました。

この事例では、その現場を離れる以外にどのような選択肢が考えられたでしょうか。

私がこのような境遇に立ったときの一例を考えてみます。

マネージャになったときこそ、プロジェクトを変えるチャンスなのです。
自分がプログラミングは得意だが、人を取り纏めたりするのは苦手なのであれば、
自身の責任とそのプロジェクトへの裁量権を持って、そのような事を担う人をサブリーダとしてメンバを選出してはどうでしょうか。

そして,自分自身はサブリーダにパイプとして管理を任せ、自分はその役職の責任を請け負う。最低限の管理だけをする代わりにプログラマとして最大限に開発に貢献する。

自分の上司は私がマネージャとして、しっかりとプロジェクトが進められているのであれば、その功績は上司の功績にも繋がるので、よっぽどの事が無い限りは文句を言わないでしょう。

組織としての現場環境が強い所では、権限は思いの外、強い傾向にあります。
そうやって、自分の権限でもって小さい所から少しずつ変えていくのです。

人には、その人にしかないパーソナルアセットがあります。
パーソナルアセットとは、その人の持ち味です。
1. パーソナリティ
2. 能力
3. 価値観
4. エネルギー基準(どういった事に精力を注ぎたいか)
等から構成されます。

これら個々の魅力は、所属している会社の特性や職能、男女の違いであったり、時には世代に起因するものです。
その人にはその人にしかないパーソナルアセットがあります。

DevLoveでHangerFlightという概念を知ったとき、頭によぎったのが、このパーソナルアセッツを活かすサーバントリーダーシップというものです。

HangerFlightは、他者との経験の違いを自分なりの形に昇華させるものです。
これを、他者とのパーソナルアセットの違いに目を向ける事に活用してみてはどうか。

メンバ一人ひとりが他者とのパーソナルアセッツの違いを認識し、その目的に対して、どうすれば自分と他者で共通の利益を得ることができるか。



ここでいうサーバントは召使いといった意味ではなく、献身的なという意味です。

サーバントリーダーシップでは、逆ピラミッドの構造が例としてよく挙げられます。
最下層にいるのは、組織の長であり、最上に位置するのは組織の大部分を占める現場のメンバです。
立場が上にある人ほど、自分のビジョンやコンセプトに共感してついてきてくれるメンバ一人ひとりを支えて、持ち味を最大限に引き出す。

従来の現場に足りないのは、本来の目的を共有し、支え合う精神ではないのか。
こういった精神の元では、プロジェクトのメンバが起こすアクションに、無駄なものなど無く、それは共通の目的に対する個々人の使命でもある。

自身がやり遂げる仕事に対する達成感を得るために全メンバが持ち味を引き出せるように、組織全体で動く。

そうした持ち味を活かせば、個々のアクションはその人にしかない+αを持った唯一のものとなり、そうすると個々が得る達成感も遙かに違ってきます。

他者との違いを受け止め、それを自分自身の能動的なアクションに活かす。
そうすると、支配的な力ではなく、パーソナルアセッツを最大限に活かすためにある組織の自浄作用としてのマネジメントを捉えることも出来るのではないかと考えました。

長くなりましたが、これらの多くは私が”サーバントリーダーシップ入門”という本を読んで得たことを書いています。
参考になれば幸いです。

☆~~~~~~~~~~~~
Written by
Yasushi Taguri ( 田栗 靖 )
relmyring or relmy.ring
_Relm ( Twitter )
~~~~~~~~~~~~~☆


2011年7月3日日曜日

SSD with MacBookPro Early 2011 (その2)

SSD with MacBookPro Early 2011 (その1)
の続きです。

1:SSDの特性と販売されている主要なSSDの紹介(前の記事)
2:MacBookProの(主にEarly2011)SSDの換装について。(この記事)
の2について書いていきます。



/**


ーーーーー注意ーーーーー
SSDとメモリの換装は、行った時点でAppleの正規のサポートは失効します。
ですので、修理も有償扱いや断られる事もあります。
自己責任の上での行為となりますので、ご了承ください。


*/


SSDの特性と主に市販されてる主要なSSDの紹介を行いました。
次は、SSDの性能をフルに活かすための設定について。

SSDは、その性能ゆえに、SATA2(3Gbps)を簡単に使い切ってしまうものも少なくありません。
ですので、最近、発売されるSSDはSATA3(6Gbps)対応を謳っています。
また、MacBookProにおいては、2011 early モデルにて、6Gbpsのバンド幅を持つSATA3のportを搭載しました。

メインベイ、光学ベイ共に6Gbpsのものもあれば、メインベイだけ6Gbpsのものもあるようです。(私個人で未検証です。)
私のMBP E2011では、両方とも6Gbpsの確立リンクとリンク速度を確認しました。

SATA3 (6Gbps) 対応のSSDMac Book Pro Early 2011に搭載したときに起こる問題については後述します。
まずは、SSDを有効活用するAHCIモードを紹介します。

シリアルATAのデバイスを使用するには、パラレルATA時代の名残であるIDE互換モードと後にシリアルATA2用に実装されたAHCIモード( AHCI: IT用語辞典 e-word )の二種類の動作があります。
こちらのモード切替はマザーボードBIOSのSerial ATAの項目で設定出来ます。

システムが前述したTRIMコマンドを発行するには、SSDをAHCIモードで動かす必要があります。

Mac Book Pro Early 2011においては、(10.6.6ー10.6.8で検証済み 10.6.5以前においては私個人では未検証です。)


/System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage


ファイルAHCIをコントロールしています。

ですので、こちらのファイルをバイナリエディタで開き、"APPLE SSD"に関する箇所(2箇所あります)をnull 埋め。

その後、OnyX(こちらをオススメします)やディスクユーティリティを用いて、
アクセス権の修復とカーネルキャッシュの再構築を行います。

再起動をすると、システムプロファイラのシリアルATAの項目でAHCIモードで動作し、NCQやTRIMが有効になっているのを確認出来ます。(TRIM対応SSDのみ)

しかしながら、バイナリエディタを使ったことがない、もしくは、バイナリを直接いじるのは勇気がない方も少なくないと思います。

2つめの手段として、
" TRIM Support Enabler "
を使う手があります。こちらは前述の、

/System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage

AHCI設定のファイル(IOAHCIFamilly.kext全体)丸々、置き換えます。
そのため、MACのFirmwareのVerが上がったときに、古いVerの設定ファイルを抱えることになります。

これらの行為は公式なものではなく自己責任ですので、
多少のデメリットはご愛嬌です。

英語ですが、こちらでも1つめの手段と同様の内容が解説されています
How to Enable TRIM on Your Mac's SSD in OS X 10.6.7 | Rafeed.me



さて、次はMacBookPro Early2011 のSATA3 (6Gbps) ポートの問題について。
MBP E2011 では、SATA3をサポートしました。
新たに採用されたSandy BridgeアーキテクチャのマザーボードのICH6は、発売初期からSATAポートが正常に動かない等の問題を抱えリコールされました。

MacBookPro Early 2011も例外ではなく、SATA3 (6Gbps) のSSDを接続する場合にのみケーブルが磁気干渉を受け速度が十分に出ない事例や、そもそも認識が出来ない、始めは繋がったが後に大量の不良セクタが出てフォーマットが出来なくなる等、問題が発生します。
追記(11/11/28):
/**
Mac Book Pro Late2011 でも同様の報告があることからケーブル自体改善されていないようです。
この症状用のEFIアップデートがありましたが、改善するしないは、やはり個体差が大きいようです。
*/

しかし、これらは、Appleサポート外の6Gbpsに換装した場合にのみ起こります。
ですので、Appleのサポート等に問い合わせなどなさらないようにお願いします。

さて、この問題ですが、OWCやANAND TECH,2chにおいても同様の問題が報告されています。
これらは、ケーブルにバッテリやマザーボードからの磁気干渉によって起こるとされています。

ANAND TECH - The Source of Intel's Cougar Point SATA Bug -

OWC BLOG - -OWC BLOG - MacBook Pro 2011 Models and SATA 3.0 (6Gbps) - Update 5/27/2011 - -

構造上、17インチではほぼ例外なく起きるようです。
13,15インチも確率の程度は低いですが、起きます。

私のMacBookPro 13インチにおいても例外ではなく、Corsair P3 をメインベイに繋いだところ、日に100kほどのオーダで不良セクタが発生し、1週間程度でフォーマット及びマウントすら出来なくなりました。
初期不良扱いでCrucial m4と差額交換をしてもらいました。
しかし、m4でもOSのインストールに失敗します。

OWC BLOG - OWC Offers Fix For 2011 17" MBP SATA Problems -

OWC BLOG - OWC SATA Cable Shielding KIT -

上記のシールドキットで改善するとの報告も2chではありましたが、私の場合ダメでした。
なので、やむなく1台目を買い換え2台目を買いました。

2台目のMBP13インチに、m4をメインベイに繋いだところ、インストールは一度で成功しました。
しかし、思うような速度が出なかったのと、プチフリが結構頻繁に起こるため、再び上記のKITでシールドしました。

すると、SATA2( SATA2: IT用語辞典 e-word より)の3Gbps超えのベンチ結果がなんとか出ました。
SATA2で300MB/sが最高速度となっているのは、エラー訂正のため1Byteのデータ転送に10Bit を使用するためです。

17インチでは、ほぼ確実に磁気干渉が起こるため、ケーブルのシールドユーザにより様々な試行がなされているようです。
コバルト基アモルファス磁気シールドテープ MS-A

を薦められたり、メインベイ/光学ベイ共に6Gbpsのリンク/リンク速度を確立した強者の中には、以下のような報告もありました。

【WUXGA】MacBook Pro Part2【17inch専用】の765, 766, 767, 770 より部分的に引用。

/**
OWC Mercury Extreme Pro 6G 240GB SSDを換装報告です。
MacはGW後購入。HDD,ドライブ、6Gbps仕様。
17インチは、SATA3.0は運次第とあったので
OWCのシールド施行例を参考にSATAケーブルを物量に任せ、シールド。

0.1mm 無酸素銅板でSATAケーブルを上下サンドイッチ
→3M導電テープで銅板上下テーピング
→更にサンハヤト磁気ガードアルミ箔テープ貼り。
→カプトンテープを貼りシールド板をくまなく絶縁。
導電テープでシールド板アース取り出し。
→シールド板アースは純正SATAケーブルのシールドが
接地されているパンチングメタルに接地。

ノイズか、電源が弱いのか、相性か、サッパリですが、
SATA3→2ケーブルに替えただけで転送速度が落ちる世界ですので
何かすれば変化を期待できるかもです。
銅板はハンズ。その他は秋葉で揃えました。
縦横約70×60mm、高さ7mmのL字に整形した銅板2枚に
ケーブル挟んだのですが、SSD下にピッタリ入るよう
現物合わせが大変だった。

ベンチ結果
Xbench Version 1.3
Drive Type Mercury EXTREME Pro 6G SSD
Disk Test 469.93
Sequential 276.97
Uncached Write 571.37 350.81MB/sec(4K blocks)
Uncached Write 517.83 292.99MB/sec(256K blocks)
Uncached Read 110.19 32.25MB/sec(4K blocks)
Uncached Read 593.38 298.23MB/sec(256K blocks)
Random 1549.37
Uncached Write 2383.09 252.28MB/sec(4K blocks)
Uncached Write 843.86 270.15MB/sec(256K blocks)
Uncached Read 2864.18 20.30MB/sec(4K blocks)
Uncached Read 1592.61 295.52MB/sec(256K blocks)

*/
というように、シールドを施せば17インチでも動く場合もあるようです。
ここまで来ると、意地とロマンですね。
私のケーブルもシールド例として挙げておきます。

1枚目はシールド後のケーブル全体図。
シールドは静電遮蔽(静電シールド:Wikipedia)の原理を用いて行います。

まずは空気の代わりにカプトンテープで絶縁層を作ります。

ケーブル本体をカプトンテープを幅半分ずつ重ねながらケーブルを包みます。厚みは結果として2枚分になります。


その後、銅箔テープでケーブルの上下を挟み込むように包みます。

再度カプトンテープ巻きます。
この層で必要なものはアースです。
銅箔とMBPのアルミが直接接触している必要があります。
少しだけ銅箔部分を露出させるのは面倒ですが
、小さい隙間を作り、アルミと接触させます。



その後、外部からの静電気を出来るだけ避けるために、再度カプトンテープで包みます。

途中に保護されてない部分がありますが、全体の95%以上ぐらいは保護出来ているので、磁束に対する影響は少ないと思います。

現にこれぐらいの単純なシールドでも、転送速度は安定しました。
ちょっと不格好ですが、これはどうしようもないですw


さて、ここまでSATAケーブルの問題とシールドについて述べてきましたが、結論です。
手間をかけないで、
現状MacBookPro Early2011でSSDを使うのであれば、CTOで選べる東芝製SSD、もしくは自力で換装する場合にも、SATA2(3Gbps)のSSDを使うことをオススメします。

SATA3 (6Gbps) を載せたいという方は、相当の運と覚悟と努力をもって臨まれてくださいw

最後になりますが、私の環境のSSを何枚か貼っておきます。
OSは、10.6.8です。

Crucial m4 256GB 、AHCIモード1.3でリンク/確立リンク6Gbps、TRIM/NCQオン、X-Benchでの転送速度300MB/s超えが確認出来ます。

編集(2011.07.28)Lion をクリーンインストールしましたが紹介した方法でTRIMの有効化も確認しました。



X-Bench Disk Score (10.6.8)













X-Bench Disk Score (10.7.0)














256GBのm4 *2 から512GBに買い換えたため再Upです。













m4のFirmware0009が出てReadが恐ろしく向上しました。
Seq256 でReadは435MB/s出ています。








参考までに、2011early2.7GHz8GBの構成での、
GeekBenchResultです。




















最後になりますが、MacBookPro13inchが大好きだーーーー!!!(* ̄∇ ̄*)

参考URL: Wikipedia: TRIM, Wikipedia: Gabage_collection
             




SSD with MacBookPro Early 2011 (その1)


どもども。
お久しぶりなリルムです:)

ええと。季節の変わり目は毎年、体調を崩します…。
そして、夏は荒ぶる天候についていけず、ひきこもり真っ最中です…orz

前置きは、このぐらいにしてw


1:SSDの特性と販売されている主要なSSDの紹介(この記事)
2:MacBookProの(主にEarly2011)SSDの換装について。(次の記事)
SSD with MacBookPro Early 2011 (その2)
にて、進めていきます。

新しくMacBookProを買う際は、
CTOで選択する東芝SSDと純正メモリの割高感が強く、自力で換装する方も多いかと思います。

そこで、主要なSSDの紹介と、換装の際に起こる(Early2011のみ)問題について書いていきます。

/**

ーーーーー注意ーーーーー
SSDとメモリの換装は、行った時点でAppleの正規のサポートは失効します。
ですので、修理も有償扱いや断られる事もあります。
自己責任の上での行為となりますので、ご了承ください。

*/

始めに、SSDの種類について。
SSDは、NANDフラッシュメモリメモリコントローラで構成されるストレージデバイスです。
フラッシュメモリの高速性を武器にHDDとは桁違いのI/Oスループットを簡単に得ることが出来ます。

基礎的な用語と仕組みだけ紹介しておきます。
ここにあるモデルでは、512Byteの容量を持つデータは一つのセクタから読み出されます。
これが、1KBになると2つのセクタから同時に読み書きします。
これがSSDの面白いところで、連続したデータであれば、容量が大きくなるほど、速くなります。
理論的には、つまり…、512Byte * x のデータではx個のセクタから同時に読み込みをし、x倍の読み書き速度となります。

限界は、同時読み書きの可能数を決めるController側にあるので、Contorollerの性能がSSDの性能を決めると言っても過言ではありません。
つまり、連続した空き領域とデータの確保が速いSSDには必要なのです。


ランダムリードライトの場合は、ファイル領域の最初の部分から、シーケンシャルの原理で読み書きが行われます。
ですので、ファイル領域がバラバラと散っている状態ではSSDの速度はどんどん遅くなります。

これによる速度低下を防ぐのがTRIM(DOS/V PowerReportの記事)です。

ファイル削除は、多くのFSの場合、論理削除ファイルヘッダのみが消えます。
SSDは、ブロックと呼ばれる単位でしか読み書きが出来ないため、ブロックを確保出来ない場合は、既にあるデータをコピーして別の領域に書き込み(ブロックコピーと呼ばれる)、その後、目的のデータを書き込みます。

TRIMコマンドは、ファイルの削除の際に、Contorollerに空き領域となるセクタを伝えます。
それにより、ファイル上書きの際にコピーの必要のない領域を把握し、ブロックコピーが不要となります。
TRIMコマンドをサポートしている機器では、経年使用による速度低下をある程度、防げます

また、SSDには自社製のメンテナンスソフト(Intel ToolBox, OCZ ToolBox等)を開発しているところもあり、SecureEraseを行うとSSDを劣化をさせずに、速度低下前の状態に戻せます。(但し、全てのデータが消えます)

さて、SSDの仕組みはここまでで、ここからは主要なSSDの紹介です。
MacBookProへの換装を主な目的とするため、PCI-Express接続のものは除外し、2.5インチSATAII/III 接続のSSD(MLC)のみとなります。

以下、2ch自作PC板
【Flash】SSD Part126【SLC/MLC】スレテンプレより引用。

/**

INDILINX : コントローラベンダ
Barefoot/Amigos(3G/現行) JetStream(6G/開発中)
性能は良好、速度低下を起こしにくく、回復も早め
Barefootは黎明期より息が長くこなれて来たが、地雷バージョンも有るので注意
OCZに買収されたが、コントローラは今後も各社に提供予定
追記(110829):OCZ Vertex Pro, SEKITOBA TM110A-* シリーズ等 

intel : SSD(OEM採用例有) / 自社コントローラ有 バランスの良い製品と保証が魅力
510(6G/Marvell) 310(3G/自社) 710(6G/開発中)
自社コントローラの性能は良好、速度低下しやすいが回復も容易
X25-M/G2はTrim対応、G1はTrim未対応、intel ToolBoxで対処可能
Marvell採用品はランダム性能を犠牲にGCの頻度を向上させ、速度回復も早い

JMicron : コントローラベンダ プチフリという造語を生んだJMF601/602の遺した罪は大きい
JMF612/616(3G/現行) JMF66x(6G/開発中)
性能は平凡、JMF612で大幅に方向転換したが既に競合が多く、採用製品は少ない
速度低下を起こしにくく、回復も早め

Marvell : コントローラベンダ 初のSATA3/6Gコントローラで人気を博した
88SS9174シリーズ(6G/現行)
性能は良好、速度低下を起こしやく各SSDでの差は大きい、回復は容易
現状対抗が少なく採用例が多い(Crucial/intel/Plextor等)

5 名前:Socket774[sage] 投稿日:2011/06/19(日) 20:44:23.93 ID:1odeIc5R [5/6]
SAMSUNG : SSD(OEM採用例有) / 自社コントローラ有 自社で全て調達できるのが強み
470(3G/現行)
性能は平凡、取扱店が少ない、NAND自体は採用例が多い
速度低下を起こすが回復は早め、ファームウェアでの改善点は良好

SandForce : コントローラベンダ 独自の尖った機能でエンタープライズ採用を目指す
SF-1XXXシリーズ(3G/現行) SF-2XXXシリーズ(6G/現行)
性能は良好、速度低下を起こしやすく回復は少ない、SecureErase or OCZ Toolboxで回復
未知を含むバグの多さが不安点、採用例は多い(adata/Corsair/OCZ等)

SIGLEAD : コントローラベンダ 国内ベンチャー
Spring(6G/開発中?)
性能は未知数、Photofast GMonster XV2に搭載予定

TOSHIBA : SSD(OEM採用例多) / 自社コントローラ有 日本ならではの安定志向
HG2(3G/現行) SG2(3G/現行) HG3(3G/現行)
性能は平凡、速度低下を起こしにくい、コンシューマ用でのOEM採用例が多い
リードオンリーモードを備えるが、過信は禁物

☆目立った活動が見られないベンダ

eastWho : コントローラベンダ IDE用ランダムが苦手

INITIO : コントローラベンダ 全領域に書き込み後は性能が落ちる、Trim必須

PHISON : コントローラベンダ ランダムが極端に遅い超地雷品、FWUPで改善したがやっぱり地雷

SanDisk : SSD(OEM採用例多) / 自社コントローラ有 堅実な設計だがパフォーマンスは時代遅れ


6 名前:Socket774[sage] 投稿日:2011/06/19(日) 20:45:45.61 ID:1odeIc5R [6/6]
★要注意★JMF601/602搭載製品(生産終了、投売り対象)★プチフリ★

Photofast 型番末尾がSSD V1/V2(内部RAID)
Buffalo SHD-NSUMxxG
CFD 型番末尾がNJ/NT/NL
G.Skill 型番末尾がGB/GBT1/Titan(内部RAID)
Transcend TSxxGSSD25D-M以外
SiliconPower SPxxxGBSSD650S25/SPxxxGBSSDM10S25(M10)
OCZ OCZSSD2-1CxxxG(Core)/-2CxxxG(Core V2)/-1APXxxxG(Apex 内部RAID)
SuperTalent FTMxxGK25H(MasterDrive MX)/FTMxxGL25H(MasterDrive OX)
PATRIOT PExxGS25SSDR(WARP) etc...




*/

私、個人としては、

安定性速度バランスが良いのは、

SATAII (3Gbps)
  Intel 320 (40, 80, 120, 160, 300, 600GB)(Intel 自社製Controller)
  東芝 HG2, HG3 (64, 128, 256, 512GB) (東芝 自社製 Contorller)
SATAIII (6Gbps)
  Intel 510 (120, 240GB)(Marvell製 Controller) 


自力でファームウェアのアップデートや、英語のサポートフォーラムを読めるのであれば、
さらにコストパフォーマンスの良い、

Plextor M2S(128, 256GB),

Crucial m4(128, 256GB, 512GB)

等が視野に入ります。
これら2製品は、安定性や速度の質も上がってきたMarvell製コントローラを採用しています。


/**
追記(11/11/28)
最近では、Marvellコントローラ搭載製品が採用例も多く、価格・速度・実用性共にメインストリームを担ってきています。
Plexstor M2P(中でもWrite性能が高い), M3S(Crucail m4 対抗製品)
Crucial m4, Real SSD p400e
Sandforce コントローラ製品は、個人的にはMarvell主流の現在で選択肢に入りません。*/


追記(110829):Crucial m4のFirmware0009の公開により、Marvell製コントローラのm4でも、Seq:500Mbps越えのスペックをたたき出せるようになりました。


そして、これから紹介するのは、SandForce製のControllerを採用しているものです。
まだまだ、FirmwareやControler自身も手探りの製品が多くベンチマークでは高性能を叩き出しますが、速度低下も激しく安定性に関しては未知数です。
ここから先は玉砕覚悟でお願いします…。
ただし、現状最速を謳うSSDSandForce製Controllerを採用する傾向にあります。

OCZ Agility3, Solid3(60,120,240GB)
(Firmware Update 必須 。さらにFW verによって安定性も異なる。上げたら戻せないので、それぞれの環境で安定したFirware使用する。)

OCZ Vertex3 (64, 128, 256, 512GB)
(上記と基本的に同じ。下記Vertex3 MIが出るまでは、激しく速度低下した後でも、最速を誇った。 )

OCZ Vertex3 MAX IOPS(64, 128, 256, 512GB)
(上記の上位品であり現状最速であり、再高値のSSD。GBあたりの単価も恐ろしく高く、ヘビーユーザ&&資金に余裕のある方向け。)

Corsair Force 3(120, 240GB)
(120GBはContollerに不具合があり、リコールされた。今は修正品が出回っているが、一度、 植え付けられたショックは中々、拭えない)

Corsair Force GT(120, 240GB)
(上記Forceシリーズ上位品。価格がようやく決定。スペックは未知数。)

OCZ, CorsairはSandForce製Controllerを採用の中でも頻繁にFirmware更新がある(不具合や性能の改善の余地がある)


SSDの特性と販売されている主要なSSDの紹介は以上です。
新規SSD購入の際に参考になれば幸いです。

次の記事は、
MacBookProの(主にEarly2011)SSDの換装について。
次記事=> 
SSD with MacBookPro Early 2011 (その2)








2011年3月9日水曜日

U2PLUSプロジェクトに参加することになりました!

(追記:2012/0606
U2plusβ版のリリース後にプロジェクトから離脱しました。)


どもども。
最近、また少しずつ体調が良くなってきて活動再開してきてるリルムです;)
どうしても病気の性質上、体調の変化の波が大きいので活動出来たり出来なかったりが大きいです。

さて、今日はU2PLUS代表の@toudou_U2plus
 さんとU2PLUSのサービスについてお話してきました。


☆〜〜〜

U2PLUS:
Webを介した認知行動療法で、うつからの社会復帰を支援するサービスです。
通院による薬物治療、メンタル面のカウンセリングを受けている方を対象に、
認知行動療法による思考回路のブレや歪みを改善していく手助けをするものです。

職種は、臨床心理士,コンサルタント、プログラマー、Webデザイナー等で、
現在うつ状態もしくは元うつの方で構成されています。

代表の東藤さんは、
”「うつ病経験のある人が大勢のうつ病の人を助ける」というサイクルを作るのが将来の目標”
で、その社会的意義も評価され、
スカイライトコンサルティング主催の”起業チャレンジ2011”の最優秀賞チームにも選ばれています。

参考URL:
起業チャレンジ2011、最優秀賞チームは うつからの社会復帰支援「U2plus」


〜〜〜☆


公式RTでメンバー募集の旨が流れてきたときにすごく共感が持てました。

私自身はと言うと、まだ病気(SAD,複雑性PTSD)から回復しきれてませんが、うつ状態やその他の合併症は何とか克服しました。

ここまで恢復してくるのにも、様々な方の支えがありましたし、言葉にはし辛い苦労も多くありました。
また、うつ状態に関する情報は病気の特性もあり、情報が少なく、適当な情報を見つけるのでさえ大変です。
私も経験したことを何かしらの形で還元出来ればと思っていたので、プロジェクトに参加させて頂きました。

構成されるメンバーには役割があり、私は元うつとしての経験とプログラマとして開発を行います。
Ruby on Railsでの開発となるので、IntelliJのRubyプラグインが火を噴く時が来そうです。苦笑

編入試験の勉強もやりながらなので、少し忙しくなりますが、無理のない程度に精一杯頑張りたいと思います。

取り急ぎ報告まで:)


☆~~~~~~~~~~~~
Written by
Yasushi Taguri ( 田栗 靖 )
relmyring( Other Sevices )
_Relm ( Twitter )
~~~~~~~~~~~~~☆

2010年12月17日金曜日

”Top reasons why IntelliJ IDEA is my favorite IDE ”を訳してみた!


どもども!
またまた、ブログ書くのが久しぶりになったリルムです;)

に書かれている内容を引用して日訳してみました。
英語で読んでいて良い内容だなって思ったのがきっかけです。

3〜4時間くらいで駆け足で訳したので、
至らない点があるかもしれませんが、
参考になれば幸いです;)

ここの訳、間違ってるよ!ここはこう訳した方が良いよ!
とかあれば、どしどしとコメントで指摘してくださると助かりますw

以下、訳文です。(原文はフォーカスしています。)


IntelliJ IDEA rocks (revisited)!
IntelliJ IDEA を支える基盤達(再訪)


 Many people ask me why I prefer IntelliJ over any other IDE.
I switched to IntelliJ about 3 years ago so I cannot compare current IntelliJ 10 vs. other current IDEs Eclipse 3.6 or Netbeans 6.9.

’なぜ私がIntelliJを他のIDEより好きなのか’ と言う事を多くの人に聞かれます。
私は3年前にIntelliJに切り替えたので、現在のIntelliJ10と(Eclipse3.6やNetbeans6.9)を比べる事は出来ません。

 Still pair programming with colleagues who use different IDE and sometimes having to skip back to Eclipse I feel confirmed that IntelliJ is best IDE on market (my opinion is primarily based on Java-Apps). 
IntelliJ has recently released version 10 and improved a lot of things.

同僚達とのペアプログラミングでは、現在でも別のIDEを使っているので、時々はEclipseを使う必要に迫られます。
そういう機会で、やはりIntelliJは(主にJavaアプリケーションに基づく)市場で最高のIDEだと確信を感じ得ます。



Performance(パフォーマンス):

IntelliJ strikes in performance.
まずIntelliJでは、パフォーマンスにおいて心を打たれます。

It keeps all the files in an index. Access to and searching through all files is extremely fast, also compilation is instant (you don’t even sense it).

IntelliJは全てのファイルに対しindexを作成します。
それにより、どんなファイルでも呼び出しや検索が高速です。

 Only the initial indexing process sometimes feels a bit slow, but version 10 shows big performance improvements on the initial index-process. I subjectively think that version 10 feels faster and UI is better responding.

初回起動時のindexの作成はかなり遅く感じます。
しかし、それもバージョン10ではかなり改善され、私の主観では高速で、UIのレスポンスも悪くありません。


Automatic in-memory compilation(自動メモリ内コンパイル):

Whereas for Eclipse you have to do a manual for saving a file, IntelliJ is doing it for you. 
Some people say, that this is “just” another shortcut to press, but I remember that it was a big relief not to do it. It really makes your fingers faster to go on with another task.

ファイル保存の際、Eclipseでは手動です。
IntelliJの場合、(メモリ内のデータを逐次コンパイルするため)自動で行ってくれます。
ショートカットキーを押すだけじゃないかという方々もいるでしょうが、この安堵感は手を別のタスクへ早々と移してくれます。



Auto-Completion + Intentions(オートコンプリートとインテンション):

The autocompletions and intentions are very clever (general code improvement, refactorings, type-completion, varables names, refactorings etc.).

オートコンプリートとインテンションによる入力補助機能はとても優秀です。
(雑多なコード改善、リファクタリング、入力補完、変数名などなど。)

 I sometimes feel that they read my mind. Since version 10 another major improvement got live: Instant auto-completion, you get suggestions as you type. I like this very much on Microsoft Visual-Studio IDEs, now finally there for IntelliJ.

時には心を読んでるのではと感じるほどです。
またバージョン10からは、入力に応じてその都度、簡単なオートコンプリートを行います。
MicrosoftのVisualStudioで気に入ってるこの機能もついにIntelliJに実装されました。



Refactoring Support(リファクタリングサポート):

Codebases should be continously improved. Structural improvements impose a risk that you break code, therefore automatic safe refactorings are extremely important.
Here IntelliJ has the best toolset. It also plays nice with SCM support, when moving around files or renaming packages.

コード基盤は常に改善され続けるべきです。プログラム構造の改善には整合性を崩す危険が付きものです。
それ故に、リファクタリングの安全性が保証されるのは特に重要なのです。
IntelliJには最高のツールセットが用意されています。
ツールセットは、至る所へのファイル移動やパッケージ名の変更などSCM(Software Configuration Management)と共に使う事でも高い効果を発揮します。



Prepackaged tool support(パッケージ同封のツールによるサポート):

On other IDEs you have to install many plugins manually. On IntelliJ the most important ones are already there (maven, nearly alls SCMs) and are integrated well. I can’t remember one case where plugins got conflicted with each other.

他のIDEでは多くのプラグインを自身でインストールする必要があります。
IntelliJでは重要であろうもの(mavenや同じような全てのSCM)は既にパッケージングされ、IDEにうまく統合されています。
互いにコンフリクトを起こしたプラグインがあったのですが、それが何だったのか覚えてません。



The small things...(他の細かい点について):


IntelliJ shows many little gimmicks, which put together make “the” big difference. Here an excerpt:

IntelliJには共に使う事で大きな変化を生む、多くの細かな工夫が施されています。その例はこちらで:

■ Run Unit-Tests on package basis (package focus in Project Window and <shift>+<ctrl>+F10)
パッケージ毎のユニットテストを実行
(プロジェクトウィンドウ内のパッケージをフォーカスして、<shift>+ <ctrl>+ F10)

■ Instant code execution on breakpoint (Debug-Window <alt>+F8)
ブレークポイント上での、簡易的なコード実行
(デバッグウィンドウ内で、<alt>+ F8)

■ Instant copy file path so you can quickly jump to path on command-line (focus file/directory and <ctrl>+C)
コマンドライン上ですぐに移動できるようにする、ファイルパスの簡易コピー。
(File/Directryをフォーカスして、<ctrl> +C)

■ File comparisons: Excellent Diff-View.
 Compare with clipboard.
 Compare with other branch.
ファイル比較: 優れたDiff(erence)-View
クリップボードとの比較
他のブランチとの比較

■ Coloring of files on tab and lines inside editor if they where changed by you without having committed. Instant notification inside editor, when file got out of synch with SCM repository (shows the commit-time and author of change).
変更された箇所がコミットされてない時の、エディタ内のタブや行の色づけ

■ Show SCM history of selection/marked codelines.
選択もしくはマークされたコード行数の履歴表示

■ Working with resource-bundles. Inside code hover over a message-key and it shows you the translation instantly (like foo.bar.logout would give you little text-box “Logout”). Also refactoring the message-keys is safe (messages.properties gets upated).
リソースバンドルを用いた作業。
メッセージキー上にポップした内部コードの簡易変換
(foo.bar.logoutのようなコードから、"Logout"のテキストボックスを作成)
メッセージキーを安全にリファクタリング
(messages/properties の更新)

■ Quick jump to Run/Debug settings (<alt>+<shift>+F10).
Run/Debugの設定へのクイックジャンプ。

■ Automatic Code quality checks + report before SCM commit.
コミット前のコード品質の自動チェックとレポート

■ Intention ‘Create Test-Class’
’Create Test-Class(テストクラス作成)’の提案

■ Automatic files refresh. When switching to command line and doing SCM or maven actions, switching to IntelliJ back all files are refreshed automatically. No danger of stale data inside IDE.
自動ファイル更新。
コマンドラインに移ってSCMやmevenを操作すると、IntelliJの全てのファイルもそれにしたがって自動更新されます。

■ General search for plain text or structural search.
プレーンテキストのための一般的な検索や構造検索

■ Auto collapsing tool windows on losing focus. Very convenient on smaller notebook screens or generally increasing editor space.
フォーカスの無いウィンドウの自動破棄。
ノートPCの小さなスクリーンではとても便利でエディタスペースの増加を促します。

■ Stable editor, even for very large files, e.g. it can show 5MB large XML-docs and even diffs between them (Eclipse always crashed here).
大きなファイルを扱うときも安定しているエディタ
e.g.(exepli gratia)例えば、
5MBもの大きさになるXMLドキュメント間の比較
(Eclipseはいつもこの作業で落ちてしまう。)

■ etc. (list goes on forever) ….
他にもたくさん。書けばキリ無い…



Minor annoyances(小さな悩みの種):

Of course with the praise from above there are still some drawbacks.
 I often had problems with SCM merging facilities (especially subversion), I now always do merging on command-line. 
When upgrading or changing plugins restart has to be done manually (at least on Linux version). 

もちろん欠点より先に利点の方を書きました。
SCMでのファシリティのマージの際によく問題が起きるので、そこはコマンドラインで手動でしています。
プラグインの変更や更新の際は手動での再起動が必要です。
(少なくともLinux版では必要です)

Also some intentions could be added (when adding @Override above a method +Enter, Pull-Up method, Extract Superclass or Introduce Interface should be suggested). For other IDE converts the different types of autocompletions are a bit confusing (<ctrl>+Space, <ctrl>+<shift>+Space, <ctrl>+<shift>+<alt>+Space).

いくつかのサジェストも追加されるべきです。
(@Overrideアノテーションを付加において、(<ctrl>+Enter)でスーパークラスからメソッドを選んで抽出する際や、インタフェースを導入する際には、サジェストされるべきです。)
他のIDEとは違ったタイプのオートコンプリートは少し混乱します。



Price considerations(価格面での考慮):
The Community Edition is free. 
For Ultimate Edition which I use you have to pay some money, but regarding the productivity boosts this is simply peanuts. 

CommunityEditionは無料です。
私が使っているUltimateエディションは幾らかお金を支払う必要がありますが生産性を飛躍的に上げると見なせば、ピーナッツを買うような出費です。

Budget people, please do the math: Depending New User vs. Upgrade (~1.50EUR vs. ~0.75EUR per day) how much does a developer cost an hour? Apart from making the developer happier you will also save money if only a fraction of the IDE related idle/waiting time is reduced.

予算を計算してみてください。
新規と更新とでは1日辺りに、1.5ユーロと0.75ユーロ必要です。
開発者が1時間辺りに使うお金はいくらでしょうか?
IDEを使っていない時間を考えると時間の分母は小さくなるよとか、お金を節約することで開発者は幸せになるよと言うのであれば別ですけどね;)



☆~~~~~~~~~~~~
Written by
Yasushi Taguri ( 田栗 靖 )
relmyring( Other Sevices )
_Relm ( Twitter )
~~~~~~~~~~~~~☆

2010年8月5日木曜日

まっちゃ445勉強会でJSOC見学に行ってきました。

ども!
ブログ書くときはいっつもお久しぶりになってしまうリルムです:(

Inputが極端に多いときは、頭の中の既存のデータ、考え方と紐付けるのに時間がかかります…><
タイトル通りJSOC見学会にて得たことを書いていきます;)

1. 攻撃者の根底にあるコピーレフトの概念。
2. JSOCの経営理念と業務内容。

今回は大きく分けてこの2つについて。

1. ☆ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ☆

さて、JSOCの見学会に述べる前に、その根底にある構造について考えます。
まず、病院はなぜ成り立ってるのでしょうか?この答えは簡単で病人がいて医療業界が成り立っています。
この構図は情報セキュリティの分野にも当てはまり、攻撃者と被攻撃者がいることで同じく成り立ちます。

ここで、3つ例を挙げます。(大きく分けると2例です。)

まず、" iTunes U " とLinuxについて。
iTunes U は、大学教授の講義を無料で受講できるサービスです。
次に、Linux。これは技術者なら一度は耳にしたことがあるでしょう。
Linuxカーネルはオープンソースで公開されており、コピーレフトの代表的なものです。 
そして、ウイルス・スパムの作成者について。
ウイルス・スパムは、亜種を作るのはスクリプトで簡単に生成出来ます。
また、新種においてもセキュリティホールがある限り存在は消えることはありません。


ここからは、その中にある構図を掘り下げます。

" iTunes U " ( "Linux" ) の構図。

1. 大学教授は講義を公開することによる直接的な収入は限りなく少ない。
( Linux はカーネルをオープンソースで共有する。)
2. しかし、自身の講義を公開することにより、実力に基づく信頼・名声という知名度を得る。
( それによるソフトウェア業界の発展と開発者の知名度の上昇。)
3. すると、知名度の高さに応じた、講演・セミナー等の高額の依頼を得ることが出来る。

次に、
ウイルス・スパム作成者の構図。
1. ウイルス・スパムを作る行為自体に利益は生じない。
2. しかし、攻撃に使われたウイルス・スパムが新種の場合は対応策が取られていない事が多く、
攻撃者は相手のコンピュータから何らかの情報を得ることが出来る。
3. そして、得た情報を売買する。
( 後進国では物価が極端に低いため、
攻撃の結果得られた情報の価値が雀の涙ほどでも、数をこなせば多大な利益に繋がるのです。)


さて、この3つの構図に共通するのは、コピーレフトの概念が根底にあることです。

1. " iTunes U " おいては、講義の共有による人材の育成・教育。
2. Linuxでは、オープンソースソフトウェアの共有、その業界の発展。
3. ウイルス・スパムでは、攻撃手段・対象の共有、情報売買の市場拡大。

このようにコピーレフトの概念を根底においたパターンが、これらの業界を支えています。


2. ☆ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ☆
ここからは、2部。JSOCでの見学体験を中心に書きます。
2010.0802.19:00 LACのある永田町・平河町森タワーのロビーに集合しました。
今回の見学会は、”まっちゃだいふく” さん主催のまっちゃ445勉強会でのものです。

そして、予定の人数が揃った所でLACのJSOC入り口である6Fに移動。
まず見たものはその荘厳たる入り口。

その様は…、
まるで、あのNERVに入るときのようなwktk感…!!
まるで、ダン・ブラウン著 『パズル・パレス』に出てくるNSAの暗号解読科、通称 "クリプト" の脳内イメージと寸分の狂いもなく合いましたw





LACのホームページ、JSOCの説明によると、この入口は通路を城塞にかかる橋をイメージして作られたそうです。
エントランスの先には「お客様をお守りする」というJSOC最大のミッションを象徴した扉がありました。

左の写真はJSOCの受付。
ここから先は撮影禁止なので写真はありません。









この先で通された場所は、
天井から大きなスクリーンプロジェクトが前面にある部屋。
そこで、JSOCの業務についての説明を受けたり、質疑応答を行ないました。
その後の見学会では、プロジェクタを天井にしまい移動するかと思いきや…!!

背面は、恐らくアクリル樹脂(引用:Wikipedia)を用いたガラスで、
中に界面活性剤(引用:Wikipedia)として、シリコンオイルを満たした、
リオトロピック液晶(引用:Wikipedia)です。
電位負荷の有無により、白濁したり透明になったり状態を変えます。

見学会のスタートはこのガラスの透過から始まりました!


それはさておきw
JSOCの業務について。
JSOCが主に行うのは何か?という質問が見学者全員に向けてありました。

1. セルフサービス
2. ネットワークサービス
3. リソースプール
4. プロビジョニング
5. 従量課金

の何れか?
答えは、5.の従量課金でした。

クラウドからの攻撃阻止、及び対策案の提案・実施のトータルケアを適正価格で提供する。
これこそがJSOCです。

ここでJSOCを車に例えられ、車で言うとベンツ等の高級車の立ち位置。
中小企業向けではなく、それより大きい会社に前述のサービスを適正価格で提供するとのこと。

そして、LACが誇るJSOC( Japan Security Operation Center )では、
FW, IDC, IPSを通して得られる1日に3億リクエストもの情報を得ます。
それをフィルタリングし、アナリストが分析します。

約7000件のログファイルを6人で分析。(3人1組のチームが2交代制の勤務で分担)
つまり、
12時間あたりに、約1166件のログファイル。
そして、
60分では、約97件。

つまり、1人のアナリストが1分間で1つ強のログファイルを分析しているのです。
その様は、みかん職人が傷んだものとそうでないものを秒単位で振り分ける様のようだと例えられました。


そして、そのアナリストを支えるのが巨大なインフラ。
稼働率は99.99% 。
スケールアウトは自社のインフラエンジニアが行なってきたとのこと。
今でも莫大な規模ですが、それでも最初は30台程の物理サーバがあったそうです。

やはり、インフラのスケールアウトは巨大なデータを扱う業務には切っても切れない関係ですね :p

そして、JSOCは医療チームの様な存在だということも聞きました。
・アナリスト(ヒューマンエラー以外の情報の分析)
・メンテナンス(インフラ保守・インシデント対応)
・サポート(被攻撃後の対策プランの提案・実施)
の3グループです。


まずは、アナリストグループについて。

アナリストはログの分析、
シニアアナリストはログのフィルタリングルールの作成やソフトウェア作成等の、
ヒューマンエラー抑制のための事前対策を中心に行ないます。
インシデントは、重要度毎に下記のように振り分けられます。

緊急度: 高
↑  Emergency:
定義: 重大なセキュリティイベント。
(明らかな攻撃の成功。踏み台、及びホームページ改竄。)

|   Critical:
定義: 攻撃が成功した可能性が高い。
もしくは、失敗を確認できない場合。        
|  これら2つへの対応:
電話, SII, メールによる、
重大なセキュリティ脅威の発生を通知。  
− − − − − − − − − − − − − − − − − −  
|   Warning:
定義: 安全なイベント。                  
(実害を狙った攻撃だが明らかな失敗が確認出来る。)    
|   Informational:                    
定義: 安全なイベント。
|    (実害が発生しない行為。定常的な検査通信。)       
 これら2つへの対応:
|  SII, メールによる、
環境への脅威があったことを通知。                 
− − − − − − − − − − − − − − − − − −  
| 欄外として、
通常通信・誤検知イベント

緊急度: 低

Emergency & Critical は、約10-20件 /day
Warning は、 約420件 /day
Informationalは、 約1100件 /day
通常・誤検知イベントは、 約5500件 /day

となります。
これを見ても分かる通り、イベントの大半はヒューマンエラーによるものです。

平均的に、アナリストは 1 /10,000 , シニアアナリストは 1 /100,000 の頻度でヒューマンエラーを起こしうるとのこと。
シニアアナリストは、こういったヒューマンエラーを処理するルールやソフト(HE後の処理対策)を作ります。


次に、メンテナンスグループについて。
これにはシニアアナリストの分析ルール作成を含むLAC研究部門の業務,インシデント対応,インフラ整備です。
アナリストの業務が健常者を、病気が怪我から守るものと例えると、
メンテナンスは、病気・怪我を負ったお客様をERからICUに移すまでのケアを行うとのこと。


最後に、サポートグループ。
サポートは、ICUに入られたお客様のシステムの今後のセキュリティプランの提案・実施を行ないます。

この3つのグループのチームワークの集大成こそが、地球防衛軍 "JSOC" なのです!


個人的には、
使徒襲来によるインシデントの発生で何時ビルが地下にもぐるのかとwktkしながら
終始、高揚感を覚えながら見学を終えました;)

長くなりましたが、とても良い体験をさせて頂きました。
以上です。

最後になりますが、この機会を与えてくださった、
” LACのJSOCの関係者 ” 様方
” まっちゃ445勉強会主催のまっちゃだいふく ” 様

への謝辞でしめさせて頂きます。

ありがとうございました!!!


☆~~~~~~~~~~~~
Written by
Yasushi Taguri ( 田栗 靖 )
relmyring( Other Sevices )
_Relm ( Twitter )
~~~~~~~~~~~~~☆

2010年6月20日日曜日

自分なりの感情の形。

【眠りにつくと思い出すもの
目覚めている時に忘れるもの
記憶の深層は夢の表層

そのどちらが現実で
どちらが虚構なのか
目覚めてみなければ分からない】

SQUARE(現SQUARE ENIX)作”ゼノギアス”、フェイの台詞より引用。

どもども!
お久しぶなリルムです;)
冒頭は最近、没頭していたゲーム、ゼノギアスから引用しました。

ゼノギアスは、シミュレーテッドリアリティ(Wikipedia)アカシックレコード(Wikipedia)を題材にして、キリスト教を思想的背景に作られたものです。

作中の人の心理描写、感情がとてもよく表現されているので、自分なりの感情を探す一環として、再プレイしていましたw
ブレインマシンインタフェースに似たものも作中には出てきます。

さて、今回はタイトル通り、感性の形について述べます。

1:感情の定義
2:共感、感情の主観性/客観性、シミュレーション
3:感情と言葉、論理構造
4:まとめ
の四部構成です。

始めに、この記事では、
インタフェースを、”ヒューマンインタフェース” の略記で、

主として、
”動物が持っている躰とその知覚の事”
を指すものとします。

1: 私は感情に対し、
”感情とは、現実をヒューマンインタフェースを用いて観測した際の成果物である”
という認識を持っています。

現実を五感(あるときは六感)を使って投影したものの集合体。(スナップショットの重ね合わせ)
それこそが感情だと考えます。

2:次に感情を考える上で、共感について考えます。
人といくつかの共通のインタフェースをもつ動物は人と同じように一部の感情を持ち得ます。
それが人であれば、感じたものは誰もが持ち得る感情となります。

共通の過程もしくは、それと酷似した過程から生まれる感情は人々の間で共通のモノとなります。
それが共感なのです。

さて、ここで同じ感情が生まれるのは何故でしょうか。
それは、共通のインタフェースによって得られたモノであるからです。

人と人であれば、その五感。
人と犬であれば、感度は違えど、共通した知覚によって得られるのです。

ここで強調したいのは共通インタフェースが必要な事です。


さて、基本的な知覚以外を通して得られる感情は前述したものと同じでしょうか。

この例として、BMI(ブレインマシンインタフェース)で得る感情を考えてみます。
脳に直接、信号を送るBMIは、五感を用いない現実の観測手段です。

人から見れば、脳に直接入ってきた情報と五感によって知覚して得た情報は区別出来ません。
結果的に、電気信号となり脳に伝わるからです。

しかし、明らかに後者の場合は得られる感情がより人本来のものに近いのではないでしょうか。
普段から慣れ親しんだインタフェースは経験によって最適化されています。

前者の場合は、得られた感情は後者の感情とはかけ離れているかもしれません。
もしくは、直接的に結びつけにくいモノになっている可能性があります。

ところで、ブレインマシンインタフェースによって得られる感情はどのようなものか。
私は、自身の主観が入らない客観的な感情であると考えます。

ブレインマシンインタフェースを用いる場合、脳に情報を送る際に連続的なデータは全て離散的な有限のデータとなります。
もちろん、その感情を認識するのは自分自身なので、結果的に意識をフィルターとしてバイアスはかかります。

しかし、認識したものは有限のデータ列に基づくので、それを分析する事が容易であったり、主観の介入を限りなく少なく出来ます。

つまり、感情にも主観/客観性の2種類があるのです。


また逆に、客観的な感情を得たければ、シミュレーションするのが最良の手段であるとも考えます。
私はシミュレーションをこのように捉えています。

/ * *シミュレーション                                                                                                                   *
  * シミュレーションを行う人は自身の主観を排除した客観的な世界観を得るために、それを行う。  *
  * データを元に構築された世界はそのデータのみに依存し、自分の主観が入らない。                      *
  * そのため、絶対的な指標と成り得ることが多い。                                                                       */


そして、このようにして得られた結果は、人が自分以外の動物とのコミュニケーションにおいて、客観的な指標として用いられます。



3:さて、ここからは前述した共感について、掘り下げてみます。
感情が現実世界をインタフェースを通して得られる投影である事は前述しました。

ところで、もし世界が自分以外に何もなかったら感情は生まれるでしょうか?
私は何かを感じる事さえ出来ないと考えます。

次に、あるモノと自分だけの世界を考えます。
自分では、そのモノを認識し自分なりの解釈を与えることが出来ます。
しかし、自分1人の世界のため、その解釈に名前を付けることは必要ありません。

最後に、モノと自分自身、そして他人の3つで構成される世界を考えます。
この世界においては、自分と他者は同じような感情を持つことが出来ます。
しかし、共有しようとしてもそれを表現出来ないので言葉が生まれます。

すると、互いに言葉でやり取りし、共感を得ることが出来ます。
感情は言葉をやり取りすることにより共有出来るものである事が分かります。

ここで言語化について考えます。
言語化するときは、その言語の定義にそった形式でモノを表現します。
つまり、言語化は抽象的な物を言語による論理構造に落としこみます。

ここで、言語化したいものに構造がなかったらどうなるか。
それは、何も感じていないのです。

何かを感じる時は抽象的なモノを得てそれを論理構造に落し込み、そして表現する。
相手も論理構造から何かを感じ、相手に返すときには自分の感情を論理構造に落とし込む。

これから言えることは、感情とはある論理構造をもった抽象物なのです。


4:まとめに入ります。
つまり、その論理構造を突き詰めていく事が感情を研究する一つの形であると考えます。
対となるインタフェース、インタフェースの種類、言語化、構造化。
感情にはこの辺りが深く関連していそうです。

最後に…
研究とは自分なりの”モノ”の形を求めることから始まる。(by _Relm)

で〆させて頂きました;)


☆~~~~~~~~~~~~
Written by
 Yasushi Taguri ( 田栗 靖 )
 relmyring or relmy.ring
 _Relm ( Twitter )
~~~~~~~~~~~~~☆