 
|
はてなキーワード: リアルタイムとは
昔は現状をちゃんと把握してるブロガーだったと思う。
しかしオタクネタならリアルタイム事情を知らないのは仕方ないとしても
今時の子供事情と言うのはシロクマ先生くらいの世代が一番知ってる筈じゃね？
本人は子供いなくても（いや本当にいないのかどうかは知らんが）
今時「ファミコンが日本を駄目にした」と言ってる人なんて見た事も聞いた事もないのに
（っつーか「ゲーム叩き」自体がもうオワコンかと。ゲーム脳が最後の流行）
今時の子供にとって塾や習い事は友達とコミュニケートする場と言う事も知らないわ…
（「友達が皆塾行ってるから自分も行かないと仲間外れになる」と言う理由で行きたがる子もいるんだぞ…
親側にとっても共働きが当たり前だから親が居ない家に他所んちの子供を入れたくない、かと言って今時は公園も治安が悪い所が多い、
でも子供に塾や習い事やらせてその先で友達と遊ばせる分には楽で安心だし）
そもそもゲームボーイブームだって友達と一緒に遊ぶ事が前提のポケモンが火付け役だろ…
いくら最近ネタ無い（或いは最近の流行についていけない？）からってこれは無茶ぶり過ぎだわ。
結論だけ先に考えて無理やり当てはめたんだろうなあ。
現在、まとめブログの主の引用元である２ちゃんねるニュース速報板、およびニュース速報（VIP）板で
ブログへの引用を禁止している、ニュース速報（嫌儲）、天国板への移住が進行中
それにあわせて、コピペ爆撃等で前板はほとんど機能停止状態に。
背景には複数人での投稿や法人化して金儲けを続けるまとめブログを毛嫌いする人が増え続けたことと、
年末年始に発覚した、ステマ疑惑、一部運営との癒着疑惑が火をつけた
http://hayabusa.2ch.net/test/read.cgi/news4vip/1326140120/
【2:860】なにが起きてるか分かってない奴は来い俺が詳しく説明してやる
beチェック
1 名前：以下、名無しにかわりましてVIPがお送りします 2012/01/10(火) 05:15:20.97 ID:pDS9BceP0
長くなるけどそこは仕方ないぜ？
元々2chでは自分たちの書き込みを（著作権がないとはいえ）勝手に転載して金儲けをするアフィブログを嫌う下地があった
2012年年明け早々アニメ制作会社シャフトの公式サイトの通販商品になぜか
アフィブログやらおん用のアフィリエイトが仕込まれていることが発覚。
やらおんがシャフトのアニメを絶賛する記事を乗せていたことからステルスマーケティング（ステマ）だと祭りになる。
↓
シャフトは公式でコピペしてそのまま貼り付けてしまったミスだったと釈明。
しかし、やらおんでは問題となった商品は一度も扱われていなかったとが発覚。
コピペしようがないと火に油を注ぐ結果に。
↓
シャフトやらおんスレがパート化。しかしなぜかスレが削除されるなど
↓
このあたりでステマ連呼厨が発生。のちの経過からおそらく工作員が
ν速民にステマを飽きさせるためにやったことであると予想される。
↓
「ステマ」「効いてる効いてる」「よほど都合が悪いようだな」などと書き込まれるようになる。
6 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:18:28.39 ID:pDS9BceP0
アフィを踏ませるように誘導することをamazonが禁止していることを逆手にとり、
名前欄やレス内に「広告をクリックしてください」という内容の文章を仕込むという画期的なアフィ殺しが生み出される。
これによりアフィブロガーは転載する際いちいち書き込み内容を一つ一つ編集しなければいけない事態となった。
↓
ν速を巡回先から外すものや編集するのがめんどくさいと言いだすアフィブロガーが多数出現。
ν速ではまともな書き込みが激減。また名前欄が「アフィ駆け出し」、「ステマニア」などに変更され
↓
運用家族＝忍者とアフィブログvipper速報がつながっていたことが発覚。さらに祭りに。
↓
ν速のスレには以前にもましてステマアフィクリックお願いコピペが貼られ
まともな書き込みがほぼ消滅し、スレ立て数は以前の1/3ほどに落ち込む。
が、なぜか板がまともに機能していないにもかかわらず、スレは普通に立てられ続けると言う謎現象が現在も続いている。
↓
18 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:22:34.29 ID:pDS9BceP0
1月9日、大手アフィブログハムスター速報の記事を完全にパクった
アフィ無しサイトハムスタ一（いち）速報つくったったｗｗｗｗｗｗｗｗｗスレが立つ。
日ごろから問題の多いハム速を恨んでいたvipper達により祭りになる。
この時集まったvipperがのちの移民祭りにそのまま移行している。
↓
名前欄を変えられるのはまずいとVIPでもアフィがいやなら嫌儲板へ行けと連呼する工作員が出現。
vipperもν速に習いマジで移民することになってしまう。さすがにν速民と同じ場所へ行くわけにもいかないので、
↓
1月10日0時天国移民祭り発生。同時にVIP焦土化作戦と称しVIPに焼け野原スレが乱立される。
数回に分けて乱立が行われるも水遁を食らうものが続出し勢いが落ちる。
↓
危機感を募らせたアフィブロガーがFOXに嫌儲を転載可能にしてくれと
必死のお願いをするも「頭おかしいんじゃない？」「いやどす」と一蹴。
嫌儲ではν速民お得意の手のひら返しでFOX絶賛レスが多数発生する。←今ここ
大体こんな流れ
リアルタイムで参加したわけじゃないとこもちょくちょくあるから
微妙に間違ってるとこもあるかも知れんが
20 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:24:18.53 ID:ibU0ACgp0
焦土作戦の詳細教えて
22 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:24:42.27 ID:ksqJpU0n0
よって俺には無関係だな
23 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:24:46.68 ID:1oxYNt9UO
24 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:25:39.90 ID:BKjxJE7wO
アフィてなんだよ
36 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:31:39.29 ID:pDS9BceP0
みんなで天国板に移民した上でクソスレ乱立させてVIPを機能しなくしようぜって作戦
22
はてぶでも人気のまとめブログ
現在はアニメ板やニュース速報＋ 、過去ログで記事を書いてるがすでに飛び火の火の粉が
これからどうなる
、
読みやすく記法かえた
下の記事もおすすめ
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
あのアニメの一番すごいところは、データ放送を活用できているところだと思う。
パズルモード（強制的にデータ放送画面に移行してパズルを見せるところ）がRPGで言う全体マップ表示窓みたいな感じで分かりやすい。
アニメという時間軸が強引に進んでいくメディアでも、時間軸に影響されずに重要な情報をデータ放送で提供してもらえるのがいい。
その情報が不必要でストーリーだけ追いたいと思う人はdボタンで引っ込めればいいわけだし。
（知らないだけでそういう番組がもうあったりするのかな？）
でも、作中の問題がリアルタイムで解けるのはいいけど、ボタン操作がしづらくて困るんだよなー。
（反応がもっさり、間違った時に訂正できない）
偶然にも俺はその日起きていてリアルタイムで見ていた。
あの時「これはなにがやばい」とは思っていた。だけど情報が多すぎた。
だから「まぁそれなりの報道をまとめてしてくれるだろう」、そう思って次の日を待っていた。
…何のことかって？聖教新聞だよ。
これはあまり有名ではないかもしれないが、聖教新聞は世界四位の発行部数を誇る新聞である。
だからこんなことを幻想していたんだ、「こんな状況ならさすがに一面トップで報道するだろう」…って。
他の新聞は御存知の通り報道された。たしか一面トップどころかほとんどの紙面をさいたはずだ。
まともにまとまった紙面で俯瞰して見られそうなのが聖教新聞だけだった。
一面は、いつものとおりの―そう、いつものとおりの、創価学会についての記事だった。
たしかに少しは書かれていたが、それだけであった。
社会面にはそれなりに書いてはあったがそれだけ。
それだけだった。
題のとおりの、すべての状況で同じような感じであった。
イラク戦争では反対するかと思ったら消極的賛成。
３・１１も独自取材では会員のことしか書かない。
そろそろTwitterを初めて1年になるのだけど、いまだに何が楽しくて、その人がツイートしているのかわからないことが多い。
もし、①は「〇〇屋のうどんなう。天かす増々して(ﾟдﾟ)ｳﾏｰ」なら、読んだときに〇〇屋のうどんの情報を得てありがたいなと思う。
もし、②は「東京駅の〇〇口、人大杉ワロタ。芋洗いなう。」なら、読んだ時によく解釈すれば、東京駅の〇〇口は待ち合わせ場所に使わないようにしようと考える。
でも実際は、そこまで情報を入れてくれないことが多い。
こういうのは、自己表現ってほどでもないし、読んだ相手がどう思うことを、予想して楽しんでいるのか？
相手に伝えるという位置がないなら、リアルで独り言いえば手間がないのでは？？
他人の状態を知って喜ぶのは肉親・恋人・ストーカーだけな気がするので、それは直接メールでイイと思う。
（2）会話
一般的にTwitterのチャット化は嫌われているようだけど、私は面白いと思う。
状態説明よりも考えられた文になるので、人柄がでるし中身がある。
（3）思想・主張
他の人の考えを読むと、自分とは違う考えであっても、有益な情報である。
意見の食い違いで反論したくなっても、反論したくなるの理由を考えるだけで自分のためになる。
（4）実況・萌え語り
実況はリアルタイムはやや面倒だけど、その人の興奮ポイントを知れて楽しい。
ついでに見ようかなと思う。
※ちなみに、絶対して欲しくないのが、他人の状態説明ツイートである。
たまに「〇〇と▲▲が、渋谷でデートしてた！」とかで写真付きツイートを見かけると最悪な気分になる。
記者気取りで他人の私生活を暴露して、自分は安全圏にいるのは、とても汚い手段に思う。
「お前のためにツイートしてんじゃねーよ」と思う人が多いかもしれない。
http://anond.hatelabo.jp/20111119215745
あー、そっか。
そういうことなのかもね。
わたしも今人間関係に飢えてるから上京組とは需給がマッチしたんだけど、田舎組はそうじゃなかったってことか。
あーリアルタイムで飲み行きたいなー。
せっかくの土曜なのに女友達は既婚者ばかりで誘えない。
人と触れ合いたい。変な意味じゃなくて！
Jpopのリアルタイム世代って、それが流行ってる時に高校~大学だった世代を指すのでは？
中学以下だとまだ早いと思うんだけど。聞いてたとしても「大人の間で流行ってる曲聴いてる自分かっこいい」感覚がメインっつーか。
割と真面目な話をすると、UI次第でタッチパネルでも化け物染みた操作は可能だと思う。
具体的には、インフィニティブレードってゲームがあるんだけど、このゲームは「縦横に剣を振る」って操作以外に「盾を構える」「左右によける」「スーパーモード（ボムみたいなモノを発動する）」と「魔法を使う」って操作があって、リアルタイムだからかなり忙しいんだけど、慣れるとこれらの操作を完全に駆使して自分よりも数十倍の体力と攻撃力を誇るラスボスを駆逐できるようになってたりする。
タッチパネル前提だから優しいゲームバランスになってるだろうって？ そんなことは全くなく、このゲームは周回前提のゲームバランスで、周回するごとに敵の反応速度や強さがレベルアップしていって、なおかつそれは無限に強くなっていく。主人公のレベルは一定で、最高レベルに上げてもラスボスはかなりきつい。（周回するごとにラスボスも強くなると言う鬼仕様）
でも、慣れるとこれらにも結構健闘できるようになって、タッチパネルの操作も人間じゃないレベルにまで高まる。
全てのゲームがそういった方面に走るとは考えにくいが、ストイックなゲームバランスを持つゲームがいくらか出てくることは、このゲームの存在からして保証できる。
人間の可能性は無限大なんだよ。ＦＰＳのWASD操作に慣れてしまう人修羅がいるように、俺らもタッチパネルの11点検出機能でも不足を訴える日は来る。
まだ、それが藻前さんには見えていないだけ。俺には、将来全ての人類がタッチパネルを前に指を触手がごとく動かしながらタッチパネルをこねる人類が見えるぜ？
それがいつになるかは分からないけどな。でも、きっと、いつか。
ひょっとしたらコントローラ操作よりも分かりやすいゲームがあることはある。
タッチパネルをなぞっている間、指で隠された空間から敵が突撃してくる可能性を考えても、まだそう言えるのだろうか？
残念だが、「リアルタイム性」という性質と「操作時に無視できない画面領域が見えなくなる」という性質は相容れないと思うのだ。
大筋で同意ではあるが、一部の主張にちょっと追加
とあるが、タッチパネルのほうがゲーム専用機の専用コントローラに、操作性で優越するジャンルが存在するという点は指摘しておきたい。
もう少し整理すれば絞り込めるとは思うけど、この5点を満たすものは、タッチパネルによる操作性は
例を出すと、カードゲームやテーブルゲーム(麻雀、将棋、チェスなど)が分かりやすいと思う。
特に「多数の中からひとつを選ぶ」、かつ「その場面ではそれしか求められない」場合は、「タッチパネルで選択する」ことは
コントローラであれこれやるよりもよほど分かりやすく操作性も高いだろう。
といいながら、例外的に上記の項目に当てはまらないゲームでありながら、タッチパネル操作のほうが
ひょっとしたらコントローラ操作よりも分かりやすいゲームがあることはある。
狭いスペースにちっこい文字でぎっしりと自分の体験とそこから得られた面白いぼやきが書かれているんですよ（ぼやきだからいいんですよねこういうのって）
特にEDENは、最初は厭世的というか暗いメッセージだったのが、巻が進むごとにだんだん前向きというか明るいものになっていったのがとても印象的でした。
作品自体はひたすらどす黒い上に終末に向かっていく世界を描いているのに、本人は明るくなっていく。その対照ぶりがすごい面白かった。
リアルタイムでこの流れを読んでいて、作品とまではいかなくとも、外に向けて自分の漠然とした悩みとか鬱屈を、何らかのカタチで外に出そうとすること、
そのために真剣に考え詰めるコトってのは、自分をすくうことにつながることもあるのかな、などと思うようになりました。
ぜひ他の皆さんも、単行本「EDEN」や「オールラウンダー廻」を買い求め、単行本を読んでみてコメント部分の感想を聞かせて欲しいと思います。（マテ
というわけで遠藤さんの最新作「オールラウンダー廻」の７巻の単行本コメントを引用してみたり。
世の中の「しくみ」ってわかってる？
俺４０になったけど未だによくわかんね。
かつて我が家の生業は木材店だったのだが、父が具体的にどんな仕事してるのかさっぱり分からなかったので、
高校の頃「手伝わせてくれ。そしてバイト代くれ」と申し出てみたが、何だか現場でひたすら重い角材を担がされただけだった。
次に弁当工場にバイトに行ったが、ひたすら稲荷鮨のシャリにごま油をぶっかけてかきまぜる、という作業を続けるだけで、
これが１パックいくらで売られ、利益がどう分配されるのかさっぱり分からなかった。
さらにイタリア料理店でバイトしてみたが、ひたすら鍋を磨いたり、バジルソースを作ったりしただけで、
なぜ親方が俺の後頭部を包丁の柄で殴ったり、ローキックして来たりするのか分からなかった。
今、漫画家をやっているが、この原稿がどういった行程を経て印刷されて本屋に並ぶのかよく分からないままだ。
若い頃は、世の中のシステムが分からないことが不安だったが、今は何となくわかった振りをしていて、今のところは差し支えない。
まぁ世の中が平和でうまく回っている間は「ボク歯車」でいいんだけど、
どうもここ最近の日本はマイナス成長だの年金問題だの天下りだの沖縄の基地問題だの、
要は「お金」がなくなっただけでこの国はこんなにハリボテだったのね、と思ってたら大震災と原発事故ですよ。
世の中がマズくなったおかげでシステムのポンコツぶりがわかってくるというのは皮肉だなぁ。
とは言え、願わくばこの先もこの国で生きていきたいと思ってる次第なので、
できることといえば「投票する」「デモに参加」みたいな「当たり前」な事しか言えないのが何ともいやはや。
１０代の頃なら、「ブッ壊セェー」とか言ってたかもしれんが、実際は何も壊してなんかなかったし。
「システム」や「制度」が最早ポンコツなら、あまりそれに頼らないで生きられるようにするべきだし、
そのためには相互扶助が欠かせないけど、今度はそこにしがらみが生まれるし、それが嫌で都会に来た奴もいるわけで、やれやれ（春樹風）。
とにかく政府やメディアの言うことは信用できんし、学者だって言ってる事バラバラ。
すべてを疑いながら情報を集めて、自分の哲学に基づいて判断するという、楽じゃないがアタリマエのことをするしかないという、何だこのツマラン結論は。