アメリカのWWEの番組の一つ。現地では月曜日の夜にUSA Network(CATV専門局)にて放送されている。日本では日本語字幕が付けられて3週間遅れでJ Sportsにて放送されている。
略称は、通常「RAW」または「ロウ」とされている*1が、ごく一部のスポーツ新聞は「ロー」と表記する。
放送開始は1993年1月11日。「Monday Night Raw」*2のタイトルで、TVスタジオ(マンハッタン・センター・スタジオ)から生放送される1時間番組としてスタートした。1994年には通常の興行を録画し、翌週放送するというスタイルに変更されたが、ほぼ未編集で生放送風の形態は維持されていた。
1994年9月4日より、ライバル団体WCWが同時間帯にタイトルも内容もよく似た番組「Monday Nitro」をぶつけたことから、いわゆる「MONDAY NIGHT WAR」が勃発した。1996年半ばより、「Raw」の視聴率は83週間続けて「Nitro」を下回り、WWEは苦境に立たされた。
そこで、1997年2月3日より放送時間を「Nitro」と同じ2時間に拡大し(その直後「Nitro」は3時間に拡大した)、更に同年3月10日より番組名を「RAW IS WAR」と改題した上で、それまでの「ファミリーエンターテインメント」路線から暴力とお色気を中心とした過激な「アティテュード」路線に転換し、新たな視聴者の獲得を目指した。それ以降WWEは反攻に転じ、1998年4月13日の放送*3で遂に「Nitro」を上回るまでに勢いを盛り返した。1999年2月8日より2001年3月26日の「Nitro」終了まで、「RAW」の視聴率が「Nitro」を下回ることはなかった。
2000年9月25日より、米国での放送局がUSA NetworkからTNN(後のSpike TV)に変更された。
2001年9月11日に発生した米国同時多発テロ事件をきっかけに、番組タイトルから「WAR」(戦争)の文字が外された。
2005年10月3日より、米国での放送局がSpike TVからUSA Networkに戻った。この回は「Homecoming」と銘打たれ、レジェンドが一堂に会したお祭り的イベントとして放送された。
ジョン・シナ
ジェフ・ハーディー
エッジ&ランディ・オートン(R指定のRKO)
ミッキー・ジェームス
アナウンサー:ジム・ロス、ジェリー"ザ・キング"ローラー
会長補佐:ジョナサン・コーチマン
リングアナウンサー:リリアン・ガルシア
たまにビンス・マクマホン自ら出演する。
コンピュータ用語。
厳密な定義はないが、人間がわかる形、数学的に扱いやすい形、規格に沿った形に整理されていないなま*1のデータの一般的な呼称。入出力センサーに一番近いデータ。
RAWデータはその後に行われる変換や解釈による欠損が無いので、後々細かい処理を行うときにはのこしておく必要がある。反面、サイズは膨大であり、一般性にかける。
グラフィック関係のプログラムが出力する画像データの形式のうち、非圧縮でなおかつ画像の縦横のピクセル数や画像フォーマットを定義するヘッダなどを持たず、純粋に各ピクセルの色情報だけを並べて記録したもの。
情報の格納形式としてはピクセルごとに並べる場合
RGBA RGBA RGBA RGBA RGBA RGBA RGBA RGBA RGBA RGBA RGBA RGBA ‥‥ (EOF)
や、チャンネルごとに
RRRR RRRR RRRR RRRR ‥‥ GGGG GGGG GGGG GGGG ‥‥ BBBB BBBB BBBB BBBB ‥‥ AAAA AAAA AAAA AAAA ‥‥ (EOF)
などと並べる場合がある。
「各チャンネルの色深度」「チャンネルの数」「データの並び方」「画像の縦横のピクセル数」などが情報としてファイルに記録されないため、データを取り扱う側が予めこれらを知っていないと画像として表示することができない、というか表示は問題なく行えるが人の目で見て意味のある画像として再現されない。
ただし、それらの情報が漏れなく伝わる限りにおいて、最も汎用性の高い画像データであると言える。
CCDやCMOSなどの撮像素子から得られた信号をそのまま記録したもの。
画像データに変換処理されていないので、加工前に現像処理する必要がある。
撮像素子は普通、明度しか感知できない為、単色のフィルタをかけて擬似的に色情報を取り出す。このとき、複数の色情報を掛け合わせてフルカラーデータを作成するが、この掛け合わせ処理を施す前のデータをRAWと言う。
RAWはそのままでは画像として不完全であるが、一切加工していない情報なので現像時の調整により好みの画像を作り易く、無圧縮である為画像の劣化がない。
また、通常PCで扱われる画像は8bitであるが、RAWは12〜16bitであるので大幅な加工後も階調飛びなどが起こり難いメリットもあり、専門家は好んでRAWを使用する。
関連語 リスト::写真用語
映像作品に字幕をつける前の状態のファイルをraw(生)と呼ぶ。
ファンサブ自体が著作権的にごにょごにょ(以下はてなにより検閲)。
*1:rawは「なま」の意味
名前空間を整備する まず、モノシリックアプリケーションの分解では、その足掛かりとして目指すべきアーキテクチャはサービスベースアーキテクチャである。 コンポーネントドメインを作成することは、サービスベースアーキテクチャへの移行を手助けする。 コンポーネントドメインとは、名前空間の名前のことで物理的に表示される。 そして、コンポーネントを表すドメインは次の4つから構成されるべきだ。 アプリケーション.ドメイン.サブドメイン.コンポーネント.クラス 名前空間のサンプル例 例えば、次の様な条件があるとする アプリケーション:ss ドメイン:customer サブドメイン:billing コンポーネント…
モノシリックなアプリケーションを分散アーキテクチャに移行する際には次の3つの質問に答えられる様にしておく必要がある。 既存のアプリケーションは分解可能なのか? 必要なのはコードの書き直しなのか?それともリファクタリングなのか? 移行にかかる費用はどれくらいなのか? 例えば、CIOから次の様に質問が飛んで来るかもしれない 複雑なモノシリックアプリケーションをマイクロサービスにする移行作業にて、プロジェクトの初日CIOに次のことを尋ねられた。 「このプロジェクトの移行作業はゴルフボールサイズなのか?バスケットボールサイズなのか?旅客機サイズなのか?」 このときに、私はその質問に答えられなかったが、…
コンポーネントの継承のデメリット 例えば、次の二つの名前空間があるとする survey(クラス含む:アンケートの通知やアンケートの作成を行う) survey.templates(クラス含む:アンケートのテンプレートを含む) この二つは、明らかに親子関係が存在する。 また、開発者の立場からすれば、これらの親子関係は理にかなっている様に見える。 しかし、このようなコンポーネントの親子関係はいくつか問題を生む。 これらのコンポーネントは厳密に言えば独立しておらず、これらのコンポーネントから一つのサービスを作ろうとしても、templatesはsurveyサービスに入れるか、別のサービスとして独立させる…
ソースコードの再利用性を高める 前回までの内容 minegishirei.hatenablog.com 前回までの内容で、コンポーネントの機能を増減させて適切なサイズにウェイト調節しました。 今回は、共通のサービスを特定・統合することで、ソースコードの再利用性を高める。 ソースコードの再利用性を高める ソースコードの共通部分とは ソースコードの共通部分を発見する 共通部分発見方法1. 類似コードをVisual Studioで発見する 共通部分発見方法2.類似している名前空間を検出する 共通部品の抜き出しの注意事項 備考 ソースコードの共通部分とは 今回抜き出す「ドメインで共通するコンポーネント…
このサイトの目的:ソースコードのサイズと管理方法 モノシリックなアプリケーションを移行する際には、コンポーネントを特定し、サイズを図ることが最初の手順となる コンポーネントのサイズとは、コンポーネントが保有する機能の数のことである。 例えば、チケットの販売システムで購入ボタンに紐ずくイベントハンドラがSQLの発行を行うのは明らかにコンポーネントが担う役割の上を行っている。 その場合はイベントハンドラとDAOを別のコンポーネントとして分離しウェイトを減らさなければならない。 ここでのコンポーネントとは、Pythonであればディレクトリ構成による名前空間、C#でのnamespace呼び出しによる名…
この記事の内容 アーキテクチャスタイルに幾つかのケースがあるのと同じように、 リファクタリングの手法にも明確な6段階の手順が存在します。 今回の記事の目的はリファクタリングを行う2通りの方法について説明します。 大規模なリファクタリングを行う前に リファクタリングでやってはいけないこと-象の移行アンチパターン コンポーネントベース分解概要 戦術的フォーク コードベースが分解可能であるとは コンポーネントへの入力と出力の数から判断する 抽象度 アーキテクチャを分解する コンポーネントベース分解 戦術的フォーク 戦術的フォークのデメリット 備考 大規模なリファクタリングを行う前に リファクタリング…
この記事について アーキテクチャのモジュール化・リファクタリングのメリット そもそもシステムは常に変化するものである リファクタリングが必要となる具体例 1.システムのパフォーマンスを改善するためにリファクタリングを行う 2.アジャイルなビジネスに対応するためにアジャイルなシステムへリファクタリングを行う リファクタリングをするべき5つの理由 No1,2. スケーラビリティ/保守性 No3,4. 耐障害性/可用性 No5. デプロイ性 補足:マイクロサービスは結合度に注意がいる まとめ:なぜリファクタリングが必要なのか 備考 この記事について システムのリファクタリングはタダでできるモノではあ…