 
|
はてなキーワード: アクティブとは
第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 練習問題
ステータスとかそんなんじゃなくて、「良好な労働条件」「そこそこの給料がもらえる」「本人にずば抜けた能力無くてもＯＫ」ということであれば、「市役所職員同士で結婚して共働き」が今でも最強。
【良好な労働条件】
・それなりにヒマな部署なら大体9時5時の勤務だったりする。ただしこれは部署によって全然違っていて、例えば財政の部署は一ヶ月泊り込みとかあるから、忙しい部署は死ぬほど忙しい。
・転勤が市内で引越しいらない。というか、転勤があまり無いし。（当然、国家みたいに全国転勤、県職員みたいに県内転勤てことも無い）。
・部署によるけど、有休もとりやすいし、産休も取れる。育児休暇もバッチリ取れる。まあ、本来それが当たり前であるべきなんだけど。民間で子育てして仕事もバリバリというと、川本裕子さんクラスの（もしくはそれに準じる）能力が必要だけど、市役所ではそんなもの必要ない。
【そこそこの給料がもらえる】
今の若手公務員はかなり給料が削減されてしまっているが、中高年は十分に高いから、共働きだとかなりリッチな生活が可能。
ボーナスは削減され続けているが、ある日いきなり無くなる可能性は低い（法令で決められてるから）。
あと労組が良くも悪くも超強い。一時に比べると大分弱くなったけど。
【本人にずば抜けた能力無くてもＯＫ】
市役所に入るための試験は別に超楽勝というわけじゃないが（このご時世だし）、特に難関と言うわけでもない。フツーの人を採用するんだし。
一方、労働条件が良くて給料がいいということであれば資格職が思いつくが、最近は弁護士もソクドクやら０９０弁護士が出てきて大変だし、会計士は試験受かっても監査法人に就職できないから会計士になれないケースが多くなってきた。
官僚（一般の公務員とは区別する）だって東大法卒じゃないとそもそも出世競争に入りにくいし、それ以前に本来もらうべき報酬を後でいただくという「天下り」への風当たりが強いからカネとしては割りに合わない。
外資系金融でガツガツ稼ぐ人もいるけど、とっても頭良くて精神的にタフじゃないと続かない（大学の友人で某外銀で年収4000万円もらってる人がいるけど、自他共に認める超秀才だったし、労働環境が苛酷だから長期的に働ける仕事じゃないと聞いている）。
ただ、医者はモンスター患者とか苛酷な労働条件とかあるけど、上記の資格とかに比べると全然いいと思う。なるのが大変だけど。
【感想】
僕は市役所職員ではないが、市役所職員を批判する気は全く無くて、本来世の中みんなそこそこ働いてそこそこ給料もらえるのがいいよね、と思う（そういえば共働き公務員は給料カットとかいうバカ条例を出そうとした自治体があったな。内閣法制局にこっぴどく叱られて止めたけど）。
定時で帰れて、育児休暇もちろん取れて、ちゃんとした給料もらえて。
あと、「バブル崩壊以降のデフレ経済下で一番賢い投資家はアクティブに投信やら株やらを買ってる人じゃなくて（もちろん市場ポートフォリオに投資してる人でもなくて）、銀行に預金預けっぱなしのじいちゃんばあちゃんだった」という話と同じで、あれこれジタバタするよりも地元市役所行ってのんびり暮らしている人が一番コストパフォーマンスが良かったんだなあって思う。
だが出会いが全く言っていいほどない。
アクティブに動いているつもりではある。
家に引きこもってばかりではけしてないのだ。
だからこそ私が居るわけだが、彼らは出会い、そして結婚したのである。
私にも彼女が先日まで居たのだ。
しかし結果は虚しく、3ヶ月で振られてしまった。未だに童貞である。
そして私はその女性と添い遂げることができるのであろうか。
その時私は何歳で、まだ童貞なのだろうか。
正直焦りを感じている。
私は一般的で、まっとうな人生を送りたいと考えている。
しかし出会いというものだけは、受験勉強のようには行かないのだ。
仮に互いを思い合える関係になったとして、果たしてそれが人生の最後まで続くのかどうかという話だ。
私は一途な男なので、それをやり遂げる自信はあるのだが。
果たして人間はどのように出会い、どのように愛しあうのだろうか。
そして私に出会いは訪れるのだろうか。
ザ・インタビューズというサービスが流行ってますが、今後起こりそうなことを考えてみた。すでに起こっていることもあると思う。
これはまあアカウント制のサービスなら基本。ネタなら後述する「なりきり」になるが、ガチで本人になりすますケースが出てくるでしょう。
単に目立ちたいから、ネット住民を騒がせたいから、くらいの理由でやるならかわいいもんですが、なりすます対象に悪意をもって行うケースというのも出てくると思われる。
運営側の対策としては、TwitterやFacebookなどの既存SNSアカウントとの連携機能をつけるのが効果的なんじゃないかと。
現在はIDのみ設定可能ですがこれは片方向なので、OAuth認証で双方向の連携を。
少なくともTwitterなどで本人であることが確認されていれば、紐づいたアカウントも本人のものであることが明らかになる。
なりすましとは違って、本人ではないことを明記した上で名前を使う場合、あるいは物語の登場人物など実在しない人物の名前を使う場合、なりきりアカウントになる。
Twitterでも結構みかけるので、流行る土壌はあるように思える。
加えてFacebookやGoogle+では規約上不可能なので、規約の緩いザ・インタビューズに流れる可能性がある。ていうか規約ってあるの？
元ネタが実在人物の場合はその人物に怒られる可能性は高いです。非実在でも版権元に怒られる可能性はありますね。
参考：コナミが「ラブプラス」２次創作規制へ？Twitter「姉ヶ崎寧々」のなりきりに削除依頼 - ゴールデンタイムズ
ザ・インタビューズでは回答に画像を貼れるので、ここに著作権上問題になる絵を貼って、それが問題を大きくしそう。
これは、あるのか？
すでにネットでの活動が顕著な有名人がアカウントを取る事例は見受けられるので、ないとはいえない。
答えたくない質問はスルーできるので、ブログの承認制コメント欄くらいのノリで使われるかも。
いろんな意味で緩い系の企業や自治体とかは使うかもね。あと某与党の若手議員とか。
まあこれはなさそうだけど一応。
リークといえば昔は2ch（「○○だけど何か質問ある？」的な）がほとんどだったけど、今は2chが使われることが減ってる気がする。
理由は色々あるだろうけど単に衰退してオワコンだからってのが一番の理由だと思う。
あとアカウント制じゃないのでどれが本人か分かりづらいってのもあるでしょう。IDとかトリップとかは限界あるし。
変な規制が増えたせいで一人が同じスレにたくさん書き込めなくなったってのも大きい。
その点ザ・インタビューズは回答者と質問者がはっきり分かれてるし、たぶんまともに回答ができなくなるような制限もない。
ブログ、Youtube、ニコ動なんかと違って双方向コミュニケーションを容易に取れるので、リークも捗るかもしれません。
ただまあ、ザ・インタビューズの運営がどこまで信用されるかにもよるかと。国内のサービスだからね…
今まで挙げたようなアカウントは特に、当然炎上の危険性を大きくはらみます。
ただ2chやTwitterとかと違って、回答者が答える質問を選べるし、選ばれなかった質問が表に出ることもないので、炎上はある程度コントロールできます。
が、ついかっとなって答えなくてもいい質問に余計な回答を入れて炎上というのはありそう。
なんせ質問者は匿名なのでどんだけ回答者を煽るようなことを書いても批判を直接受けることはないし完全に安全。ここは2chと同じ。
そしてユーザーは大抵Twitterもやってるので、炎上はよりダイレクトに意思疎通ができるそちらに波及するでしょうね。
燃え上がると言えばこっちも発生するでしょう。
既出、あるいは同じような質問、心をえぐる質問、やたらと長文を要求する質問、モラルのない質問、質問爆撃（同じ人が同じ人に嫌がらせを目的として無難で陳腐な質問を大量投下。これシステム上防がれてるのかな？）、バトン（これ今は多分ないけどそのうち出てくると思う。mixiで流行ったアレね）、馴れ合い、等々でだんだん疲れてくるでしょう。
そのうちに質問者ひいては自分の周囲の人物への疑心暗鬼なども生まれることでしょう。
おそらく多くのアクティブユーザー、特に質問がたくさんつく有名人のアカウントは1年以内に放置、休眠状態になると思います。
これは燃え尽き症候群の逆。要するに誰も質問してくれなくてつまらないからやめちゃうというパターン。
このサービスは確かに、誰もが誰もに質問できるサービスではあるけれども、きっと何者にもなれない誰かに質問して楽しいか、という話です。
有名人や友達がたくさんいる人、ぶっちゃければTwitterのフォロワー数が多い人以外はあんまり質問つかないんではないでしょうか。
もちろん面白い回答をつけまくってファンを増やすのはありでしょう。でもそんなことができる人物は大抵すでに他のコミュニティで人気者なんですよ…
といって、システム上自分自身に質問はつけられないので自作自演はできない。複垢とってまで自演してもむなしいだけ。
まあバトンみたいな質問量産体制ができたら質問数は増えるかもだけど、mixiと違うのは質問者が誰か分からない点。
誰だかわからない人物の汎用質問なんて答えて楽しくないんじゃないかね。たぶん3つのデフォ質問に回答するのと同じ気分になると思うよ。
ザ・インタビューズは3か月～半年くらいは他のSNSがたどった道をたどることで盛り上がるけど、やはり同じようにその後は徐々にさびれるんじゃないでしょうか。
まず、ある学年の子供の数は大体100万人くらい
女の子は半数(0.5)
女の子全体の内、まぁAVで見れるかな、というレベルの娘が、低めに見積もっても、5分(0.05)
これは、小学校とか中学校のとき、学年で可愛い娘が1,2人だったことからも分かるね
可愛い娘じゃなくても、隣の席になったら惚れてるレベルの娘はもっと多いだろ
次に、この可愛い娘の内、多く見積もっても、まぁ1%が、何らかの理由でAVに出るとしよう
AV以外にも、キャバ・ソープなど色々あるけど、ここでは考えない
最後に、AV女優の年齢を18歳から25歳とする。つまり、だいたい7学年分
1,000,000* 0.5 * 0.05 * 0.01 * 7 = 1,750
なんと、驚いたことに、アクティブに活動する可愛いAV女優（クラスに一人か二人のレベル）は、今現在日本に1,500人以上もいることが分かる。
これだけいれば、そりゃ可愛い娘もいるよね
つまり知り合いに紹介して貰うとか合コン行くとか出会いを増やす為に社会人サークル入るとか全てを指していたし
別に女に限った事でもないけど、
だってもともと「婚活」の提唱者って、一貫して女相手の商売してる業者だったし
最終的に「女が相談業者・マッチング業者に駆け込む」って形になるのは予定通りの漁の網だよ。
なんか「みっともない」「焦ってる」みたいな扱いする風潮、あったじゃない。
そこに「婚活」っていうまるで最先端概念みたいな流行語をつくって、
男女ともにやってることって風にして、
抵抗感をなくしたのが手柄。
だから「婚活」については、変質したんではなく元が業者のキャンペーン。
最後はまるまる女の不安や願望を売上回収するとこまで怖いほど狙い通りの追い込み漁だよ。
twitterをバカ発見器とかはてブで言ってる奴らがいるけど、
twitterよりも遥かにアクティブユーザー数が少ないはてブが
それを勢いづけたはてブ。
はてなブックマーク - Nuclear engineers urging IAEA to create “Level 8″ on INES scale for Fukushima ? Energy News
twitter拡散の元になるのがはてブってのが多いわけだよ。
はてブ→twitter拡散となる。twitter拡散デマとか言ってるが、
それって、デマの元になっているのは、はてブだろってのも多い。
まぁ、はてブの高知性様は「知性は我にあり！」とか本気で思っているから、
「マスゴミ報道よりもはてブのほうが信頼できるのは間違いない！」
飛ばしているという記事をどんどん書けよ。
ネット言論で最もヤバイ奴ら。
2chやミクシィやtwitterを高知性のはてな様がよく批判しているわけだが、
まぁ、冷静に考えれば、はてブなんかが信頼できるメディア（笑）なることを
思う奴のほうが頭がイカれている。
一昨日の夜はスタクラ２のスーパートーナメントを見た後、AVA関連のブログを読んでいた
寝る前に音楽ファイルの整理をしてDAPに一つ音楽を移して枕上のアクティブスピーカーに接続して子守唄にした
昨日は１４時過ぎに起きて、PCをスリープから復帰させようとしたら休止状態になっていたのでWindosの電源オプションを確認するとPCの物理電源ボタンの設定がスリープではなくて休止状態だった
子守唄に効いていたアーティスト？アレンジャーの曲を１曲しか持っていなかったのでAmazonMP3で全て視聴しながら気にとまった曲をカートに追加していった。
グーグルリーダーでブログをチェックしていたら９,11 3,11の次のことが書いてあった。つまり6,11だ
おそらく１６時ごろ、食事をとるために家の２階に上がり、自分の食事の前にトイプードルをしばらく抱いてやった。
１８時ごろまで本屋に散歩に行き精神世界カテゴリーの本を二、三冊立ち読みした。
ホビー雑誌やスポーツ雑誌の棚に置かれている月刊ムーに個人用シェルターの記事があった。
シェルターは地下に作るようなタイプではなく部屋を改造するタイプとのことで２５０万円程度で提供しているらしい。厚さ１５CMの壁や、空気清浄機、ガイガーカウンターなど。
帰ってお風呂に入る前にGSLスーパートーナメントを１試合観る。
お風呂から出て二階に上がりご飯をお盆に載せて一階の部屋で試合を見ながら食べる。２１時半頃までかけて食べた。
そら豆ご飯、かなり濃い味噌汁、ポテトサラダ、卵豆腐、エビフライ、クリームコロッケとレタス、マックポテトよりも美味しい何かを頂いた。
レメロンを飲んで、眠くなるまでAmazonで曲の視聴をしていた。
買う前に確認をしていると１５秒ほどの曲と知らずに１５０円で買おうとしていたことが分かった。
今日の１時３５分ごろ起きた。
暗い部屋で豆乳を飲んだ。
PCの前に座ってラジオを聞いたあとスリープから復帰させてローカルのVideoと海外動画サイトでビデオを見た。
プロチームのEvilGeniusとFnaticの１時間ほどの試合を見て、JustinTVのStrategyカテゴリーでViewer数TOPが何かの大会だったのでそれを見ている途中だ。
これは多分単純な数の問題だけど。
数の利を用いれば
同じような考えの仲間が徒党を組んで殺到するとか
互いに星をつけて慰撫しあうとか
同調しない人間のブックマークに中傷タグいっぱいのブックマークで罵倒を残していくとか
（アレ本当に幼稚なみっともない習慣だと思うんだけど、どうなんだろう。
アレだけはやめたほうがいいと思う、口喧嘩はいくらしてもいいけど。）
そういう気勢の挙げ方がブックマークでは出来る。
けど
全く匿名のフリートークである増田だと論理＆口八丁の世界なので
ブクマでやってるような集団戦や圧力に頼む人間はたいがい無力になる。
どっちが正しいってことも無いけど。
あと最後に
原発の賛成反対が右とか左とかのタームだっつうのは理解不能なんだけど。
群れの気分ではなく個人として、ちゃんと自分の頭で考える人ほど
この記事（http://www.drk7.jp/MT/archives/001769.html）が話題になっているので、自分も書いてみます。まずは自分の属性。
そもそもNexusSは国内で販売されてないので、NexusSとiPhone4のどちらがイイですか？と人に聞かれることは全くないですが、
NexusSの方が圧倒的によいと"私は思う"と（もし聞かれたら）答えます。今後の機種変も間違いなくGalaxy S2、3？、と買い続け
ていくと思います。一方で別の技術はもうわかったのでiPhone4は手放そうと思っており、iPhone5が出たら誰かに触らせてもらい
たいです。※NexusSは技適未通過端末なので、帰国前の使用感レポとなります
元記事に異論なし。音質は音楽聞かないから知らない。AndroidはiPhoneよりもっさりしてるし、落ちるし、電池減る。
Nexus Sの解像度はWVGA(800x480)とiPhone4(960x640)より劣るのに、画面自体が大きい分広く感じる。Nexus Sは4インチ、iPhone4
は3.5インチで、だいぶミスタイプが減った。Xperia arcは4.2インチなので確かに大きすぎるかも。Nexus Sはちょうど良い。
だいたい元記事通り。ランキングサイトを見て色々試すのが自分は楽しい。iPhoneでスクエニのゲーム買ったけど、結局スマホで
ゲームなんてやりにくいし放置。ゲームは3DSかPSPで良い。
で、大事なのはここから！速度・安定・電池を差し引いても自分がAndroidを選ぶ理由。
Androidアプリの良いところは、アプリ間の連携がシームレスなところ。写真とる→ギャラリー(iPhoneでいうアルバム)→共有から
直接twitterなどにうｐ、が可能。(http://www.gazo.cc/up/37699.jpg)iPhoneは写真とる→アルバムは移動出来るけど、うｐする
には各アプリを立ち上げないといけない。ブラウザもメニュー→共有で、そのページを色んな方法でシェアできる。アプリ連携し
すぎ。あとページ内検索とかも地味に便利。
他にも良いアプリとしてはIMEのSimeji。←→キーとソーシャルIMEが便利すぎ。iPhoneだとiとiの間にカーソル合わせるとかほぼ
無理。ツイートする時に少し戻りたいとかもよくあるので、←→は不可欠。ソーシャルIMEの効果は
(http://www.gazo.cc/up/37694.jpg)参照。スマホは数字・記号が混ざった入力がだるいので助かる。
GoogleMapは拡大・縮小した時にコンパスが元に戻らないのが良い。(ブラウザにもついてる)- +ボタン便利。本来はマルチタッチ
非対応端末用だけど、片手で縮小出来るのが十分便利。iPhoneだと縮小時に左手に持ち替えるとかよくやってた。他にマイマップ
とか様々なレイヤが重ねられる。Latitudeは友人0だから意味無いんだけど、mixiのAndroidアプリ(上の画像の)みたいな感じで4sq
iPhoneは他のアプリが起動すると投げっぱなしで戻れないし、1つのアプリ内でも戻れなくて迷子になることがよくある。
だいたい左上が「戻る」系ボタンがあることが多いけどそうでないアプリもあるし、左上とか遠くて画面を覆い隠してしまう。
今では「戻るボタンが無いなんて、ブラウザバック禁止でブラウザ見るぐらいストレスだろ…」と思っている。
色んなアプリの新着がステータスバーに表示される通知機能が死ぬほど便利。twitterにおける通知（とウィジェット）の良さはこ
れ(http://ran.private.coocan.jp/omusubi/log/2010/12/android-twicca-beta.html)あたりを参照。iPhoneにもPush通知はあるけ
どすぐ見なくて良いものを保留、とかが出来ない。強制的にアクティブになるのが鬱陶しい。インテントと組み合わさると最強で
、こんなこと(http://www.gazo.cc/up/37695.jpg)が出来る。
上のtwitterクライアントのエントリでもあるようにウィジェットが便利で、ホームから色々設定変更が出来る。自分は家帰ったら
NoLockウィジェットでロックオフしてすぐ操作出来るようにしてるし、布団でごろごろ使う時にはScreenFilterウィジェットで好
みの程度暗くする。あと計画停電があった時はホームに付箋メモ貼ってすぐ確認出来るようにしてた。この辺はiPhoneでもJBすれ
ば出来る範囲なのかな。
他にもFLASHが動くとか、NFCがついてるとか、電源ボタンがサイドについてて使いやすいとか、丸っこくて可愛いとか、Macがなく
てもアプリ作れるとか、色々良いところはある。代わりに先に述べた体感速度、OSの安定度、充電池の悪さの他に、フォントが変
元々NexusSはAndroidアプリ開発用にと買っただけで、予想以上に気に入ってしまったのは誤算。久しぶりにiPhone使ったら「戻れ
ない」「←→ない」「通知ない」が死活問題だし、最近Softbankの電波はさらに悪化したのか屋外ですら300～500Kbpsしか出てい
ないことも多く、人が多いと100Kbpsも出てない。（前は1Mbpsとか普通に出てたので、ここ最近何かあったのか、場所・時間帯に
"自分は" Nexus S ＞ iPhone4だが、我慢してiPhone4を使っている。iPhoneにはAndroidのようなワクワク感が無いのが残念だが、
カスタム面倒な人・初心者にはiPhoneを勧めているし、無難だとは思う。2.2か2.3以降のAndroidなら、用途や好みによってはオス
スメ。色々出来るから本当楽しい！アプリをアドオンで強化出来るとか感動したし！個人的には「iPhoneに貼る電子マネーシール
」「iPhoneでも音の組み合わせで決済」「iPhoneでFlash」「iPhoneで赤外線」とかにエネルギー使うのは勿体無いので、より自由
なAndroidが普及して技術が発展すると良いと思っている。
じゃあ何を使うべきか迷っている。Softbankは解約して本体売るつもり。回線はdocomoか、b-mobile+WiMaxか、auのEVO WiMax
(CDMA+WiMax)が良い気がしている。EVO WiMaxはかなり魅力的だけど、CDMA通信時の安定性が不安なのと、端末がHTC EVO一択にな
ってしまう。docomoの最新はXperia arcだけど、なんかぺりあってダサい感あるしGalaxy Sの方がNexus Sと似てて良さげ。ただ来
この記事（http://weekly.ascii.jp/elem/000/000/038/38214/）のように、SIMフリーの技適通過済みAndroid端末をデータ通信の
みで使うのが安いし早いのは魅力。でもIDEOSは小さいしスペックが…
この辺（http://gpad.tv/phone/docomo-sc02c-samsung-galaxy-s2/）を見るに、Galaxy S2の発売とレポを待つのが良いと思うので
、たぶんそうする。本当はすぐにでも変えたいので辛い。
原文： http://sites.google.com/site/ytpartnercommunications/Announcements/youtubelive
パートナーのみなさん。
すでに最近のブログのポストをお読みになられたかもしれませんが、本日私たちは自前で運営するライブストリーミングのプラットフォームのベータバージョンを、アカウントの状態が良好（著作権に違反していない）なパートナーに段階的に公開を始めました。このベータ版を使えばパートナーの方はご自身のチャンネルから好きなときにいつでも生配信をはじめたり、あるいは事前にスケジューリングすることで購読者に放送の開始をお知らせすることができます。生配信視聴の素晴らしい体験を保証するために、この機能の提供は少しづつ進めていくつもりです。もしあなたのアカウントが生配信が可能になったならば、あなたがログインしチャンネルページをみたときに、その旨が表示されます。
多くのパートナーがYoutube上での生配信に興奮していることでしょう。もし、あなたのアカウントがまだ有効になってないのなら、あなたの熱意は心から歓迎するところですが、どうか辛抱なさってくださいませ。アカウントを生配信が可能にするためにリクエスト出せるような仕組みはありません。ただ、あなたのアカウントの状態を良好に保ち、Youtubeコミュニティーガイドラインをリスペクトするアクティブな動画投稿者で居続けてください。我々は、２０１１年のあいだ中、可能な限り多くのパートナーに対してこの機能を有効にするよう努力を続けています。
皆様の熱意と忍耐とご理解予め感謝を述べさせていただきます。もしあなたが有効化されたパートナーで何かこの製品に質問がございましたら、どうぞ、ヘルプセンターかライブストリーミングフォーラムを訪れてください。
完全な妄想レベルで全く根拠はない与太話なのだが。ハイクに書こうと思ったらえらく長くなったので増田に書いてみる。
突っ込みどころは山ほどあると思うがまぁ与太話として聞いてくれ。
様々議論はあるだろうが、今後国内では原発は向こう数十年は推進される事はなくなるのではないかと思う。少なくとも国政選挙が2回ぐらいは原発支持・不支持が論点になり、原発推進候補は勝てないだろう。当然ながらこの福島原発の処理が終了するまでは先に進めないだろうし、毎年毎年、3月11日が来るたびに思い出され、忘れられずに残っていくだろう。あるいは残らなければならないと思う。
また、一緒にするなと言う話になるかもしれないが、スリーマイル島事故のあと米国は反原発に舵を切って長年原発を作ってこなかった。それが解除されたのはつい最近で、きっかけは確かカリフォルニアでの大規模停電だったように記憶しているが、そういった再び世論を動かす事故が起きなければ敢えて寝た子を起こすような政治家は出てこないと思う。（ただ…チェルノブイリ発電所は2002年まで動いていたとか、そういうことを考えると残る可能性も十分あるし、今回の経験から日本の原子力技術はさらに成熟されるだろうし、国際的にはどうだろとか、いろいろな議論はあるとおもうけど発散しちゃうのでここではこういう前提にする）
という夢は日本が今後成長していく上では捨ててはならない。捨てた瞬間日本の経済は終わる、と言うレベルで捨ててはまずいと思う。エネルギーはすべての生産活動の基本なのでここが下がらないことにはコスト競争に勝てないからだ。
まずエネルギーコストがあがると、エネルギーコストが原材料費に占める割合が大きな産業からやられてくる。たとえば製鉄業などがこれに当たるが、実はすでに鉱石からのアルミニウムの生成など一部の産業では国内企業はエネルギーコストの上昇によって競争力を失っているものがある。（日本では独自に水力発電所を持っていてエネルギーを極端に安く入手できる企業しか残っていない。国内のアルミニウム工業はインゴットを輸入している。このためアルミニウム合金そのものについては国内より外国の方が進んでいる）これらの産業が外国に流出しても別にかまわないという考え方も十分あるが、これは全体的にコストの上昇を意味することとなる。
さらに、エネルギーを輸入に頼らなければならない日本では、エネルギーは即座に外国に金が流失する事を意味する。（国内でエネルギーを生産できる国はエネルギーコストが上がっても国内需要として残る）故にエネルギーコストが原材料費に占める割合が増えると産業競争力が落ちるばかりでなく、国内の金の巡りが悪くなり、経済はかなり厳しくなる事すら予想される。
全ての産業がこう言った事に追い込まれないためにも、永遠にエネルギーコストを削減していく技術は追い求めなければならない。
ただ、原発はもう少なくとも政治的・社会的にもう限界だし、コスト的にも議論はある。個人的にも消極的容認派から積極的収束派に意見が変わった。原子力推進でこの夢を追うのは無理だ。
では、どうするか。
原子力によって叶えようとした夢は、自然エネルギーが引き継ぎ、夢へと動くべきだと思う。自然エネルギーは原子力と非常によく似ており、正統な後継者だからだ。
「おい貴様何を言ってる水と油じゃないか」「かわいそうに、酸素欠乏症にかかって…」「ばーかばーか」等と言う声が聞こえてきそうだが、かなりマジである。原子力と自然エネルギーは、少なくともチェルノブイリ以前の認識ではかなり共通点があったと思うんだ。
後ろの利権（産業としての裾野の広がり、影響力）の話なんかも下手すりゃ同じである。原子炉の仕組みが考え出された当時は火を燃やすよりずっと安全だと考えられており、今でも単純な死亡者の数では火力より安全だという議論すらあるくらいである。故に、今の自然エネルギーの一種のような認識だったのではないか。さらに言えば発明された当初は「こんなもの制限が多すぎて使い物にならない」と考えられていた…かもしれない。
原発というのはあくまでも手段であって目的ではない。大規模な原子力災害が発生し、その他様々限界が見えてきた中で手段を変えるのはそんなに悪いことじゃない。目的が達成できればいのだから。
故に、自然エネルギーは原子力の正当なる後継者じゃないかと思う。だから原発は今後尻すぼみになるなら、同じ夢を追う自然エネルギーに原発に振り向けていた投資のうち、維持費以外を振り向けて推進するべきだと思うんだ。原発反対の反動としての自然エネルギーではなく、原発の正当なる後継者としての自然エネルギーに。
ただ、よく知られているように自然エネルギーは
などなど、山ほど問題を抱えていて実際の所うまくいく保証はない。というか、代替エネルギーとして今すぐ原発の後を継げるような存在ではないのは間違いない。今原子力の直近の代替エネルギーになり得るのは火力しかないと思っている。（夢は継げるかもしれないが。さらには原子力が火力を駆逐できなかったように、火力も依然として必要とされるだろう）ただ個人的にはそれぞれ、以下のようなブレイクスルーがあって、研究されさえすれば解決に進むのではないかと思っている。
最後の送電網の組み替えだけは、物理的な問題があるのでブレイクスルーのような物はちょっと考えつかない。ただ、これはたとえ原発事故がなくても設備の更新などは必要だったわけだし、おそらく原発がこのまま推進される事になってもこの流れは必要になってくると思われるので、と言う事にしておく。
また…。これは完全に不謹慎であるし、お怒りをいただいてもしょうがない思考ではあるのだが、怒られそうな事を敢えて言うと、今回の被災地は壊滅的な打撃を受けほとんど丸ごと町を作り直さなければならなくなってしまったところがかなりあり、政府はここに莫大な公金をつぎ込み新たな町を作り上げるつもりのようだが（そして世論もそれに賛成している）、これは新エネルギーのための町をある程度採算度外視で作る事ができる条件がそろっていることを意味している。
ご存じの方も多いと思うが都市計画は、再開発よりも一から作った方がよほど簡単なのである。たとえば中国では大規模造成によって作られているのはものすごいスピードで発展しているが、何もないところ（あるいは何もないに等しいところ）を造成しているから早いのである。（日本の高度経済成長期のニュータウン造成も似たような話）一つずつ立ち退かせるところから始めなければならない再開発より早いのは当然である。
だから、災害に遭ってまっさらになってしまったところがある、というのは、未来のエネルギー産業を育てるためのモデル都市を作る事ができると言う事も意味する。きっかけは不幸な災害であったが、この災害を次へと繋げる事も可能になると言えるのだ。（ただ、外野だからこういうことをいるのだ、とも言えるのであるが…うまくいけば世界に名だたるモデル都市になり、産業たり得るだろう）
前掲した以外にも様々な技術的な問題はある。これらの実現・解決にはかなりの時間がかかる。ではどうするか。個人的にはそれでもとりあえず問題はないのではないかと思っている。何故かと言えば、原発は今すぐ停止できる物ではなく、どちらかというと安楽死というか引退させると言った緩やかな停止になり、自然エネルギーの成長を待つだけの余裕は十分にあるのではないかと思うからだ。
今後、原子力は引退させようという動きになっていくと思うが、一部の過激派の言うように「今すぐ撤去せよ！」というのは暴論も暴論で、とても無理だと思う。確かにエネルギー問題を無視あるいは過激派の言うとおり節電などでやりくりすることが可能であれば、異常な状態である福島第一原発を除けば原発を今すぐ止めることは物理的には可能だろう。しかし停止状態になっているのに問題になっている、あるいは使用済み燃料であるにもかかわらずきちんと管理が必要なことを考えれば、いきなり停止させても自己満足以外の意味は、それほどないのではないか。むしろゆっくり運転させ経済的に重要である状況に置いておいた方が、追い込みすぎて安全対策にまで金が回らなくなることに比べればずいぶん安全かもしれない。
さらに、原発の解体は年単位で時間がかかるし、日本国内できちんとした技術は確立されていないから、そこら辺の技術をきっちり固めてからではないと危険であるし不可能だ。
また解体した原発の放射性のゴミをどこに捨てるかという問題も当然発生するだろうが、場所はすぐに見つかる物でもないので（今でも地層処分の場所が見つからず難儀している）、そこも確保してから停止しなければならない。もちろん一度にたくさんの数の解体を進めることも、現実的ではない。すると、古い順番から廃炉へと動いていく事になって、原発の廃止にはどうやっても時間がかかる。自分は少なくともどんなに急いでも二十年はかかるとおもう。
だからまさに原発から自然エネルギーへ夢を引き継いでいく素地は十分にあると思うのだがどうだろう。
根拠らしい根拠はない。また「未来の可能性は無限だから何でもできます」みたいな不毛な話なのも自覚している。今の短期的な電力不足・技術的課題が残るであろう中期的な問題を解決するような話ではない。
さらには原子力がクリーンな夢のエネルギーとみられていた時代と同じで自然エネルギーも今後おそらく確実に様々な今知られていない問題も出てきて、場合によっては今回のような致命的な問題は出て来て頓挫するかもしれない。
また、設備以外にも、ライフスタイルは大幅に変えなければならないだろう。少なくとも
等は考えつくところだ。さらには原子力産業で食っていた人たちをどうするかと言う事もある。電力会社は徐々に電気を作って売る会社ではなく、電力送電網を所有する企業へと変貌を迫られるだろう。末端の電力網を維持管理する作業者は技術的に大きな変更はなくあまり関係ないだろうが、そうでは無い電力会社本体の、発電に携わる今まで日本を支えてきた技術者の方々には削減の並が及んでしまうだろう。
しかし、原子力が数十年原子力産業と日本を食わして来たように、数十年は日本を食わせてくれる原動力になるポテンシャルは十分にあると思うがどうだろうか？
また、困難であるため他者が参入してこないと言う状態であるならばより高い見返りを得る事ができるのではないか？うまくすれば、日本がはじめてエネルギーの世界で優位に立つ事ができるようになるやもしれない。
今こんな事を言うと怒られるかもしれないが、原子力は敵、自然エネルギーは味方、あるいはその逆でも良いが、そういった思考では未来は開けない。
現実原子力の力によってできあがってきた社会を直視し、原子力に携わる人々に「なんて物を作ってくれたんだ！」と言い放つのではなく「今までありがとう」と言い（これは無論原子力災害に見舞われている現地の方々ではなく、そのエネルギーを享受してきた我々の立場である。原子力災害のただ中にいる人は怒っても良いし、保証の話は別だ）原子力で見た夢は自然エネルギーが引き継ぎます、と告げ、方向転換を図る時だと思う。
