 
|
はてなキーワード: ストリームとは
第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 練習問題
この努力は僕が Google に来る為に Amazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてサービスをまず最初に考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれが全てのデザインというものに対しての基本的なアプローチになっている。
その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解したから、サービスを提供しているんだ。確かに SOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。
これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし（今もそうかも）、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、 Amazon 社員の大多数が理解する前に、 Amazon はプラットフォームにならなければならないということを悟っていたんだ。
だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルなプラットフォームになる必要がある、なんてことを考える？。そうだろ？
ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。だから今、彼らには Amazon Elastic Compute Cloud があるし、 Amazon Elastic MapReduce があるし、 Amazon Relational Database Service があるし、その他たくさんの aws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービスは大成功した企業のバックエンドを努めていたりもする。 reddit なんか僕のお気に入りだね。
もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママがこのくそったれサイトを全く使えないと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ（訳注：アドバイス thx ！）。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。
とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法は問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式な名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティングの世界で最も重要なものだ。
君は思うかも知れないね。「はあ？つまりそれって、目が見えない人や耳が聞こえない人のあれ？あのアクセシビリティ？」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だから、アクセシビリティを理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが（この場合アイデアウェアといった方が正しいかもしれない）何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのものに責任があるんだ。それがアクセシビリティの失敗というやつなんだ。
人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪な双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね（もちろんアクセシビリティには宿敵はたくさんいる）。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい？
でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だって、アクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう？ Playstation Network みたいにさ。
まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーのエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。
Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォームを理解していない。僕らはプラットフォームを自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手のプレッシャー、 Microsoft や Amazon や最近じゃ Facebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。
でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも？。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。
多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。 Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ？（訳注：この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます）
プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。
Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから（やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ）枝葉の使いっ走りまで（やあ、君だよ）、全くプラットフォームを理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカー用 API？」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一の API は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか？
Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパにドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点が必要なんだよ。
Google+ は脊髄反射の代物さ。 Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だから Facebook はみんなにとってそれぞれ違うものだ。 Mafia Wars に全ての時間を費やす人もいれば、 Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。
僕らの Google+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲームが必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい？。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。
そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティングの歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。 Steve Jobs がそうだろう。でも、僕らの処には Steve Jobs はいない。悪いけど、いないんだよ。
Larry Tesler は、 Bezos が Steve Jobs じゃないってことを口説いたかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼が Steve Jobs になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
いや、あなたの言ってることは合ってるし、自分も基本的に同じことを主張したつもりだが。
を、わざわざ砕いて”リッチなインターネットコンテンツを、非常に簡潔にスマートに記述できる”と文系チックに書いたのに、なぜ、わかりにくいバズワードで言いなおすのか。
そもそも「セマンティックな記述」って意味がわからない。文章の意味構造を記述できるようにして外見と分離する事を指すのなら、それは「非常に簡潔にスマートに記述できる」という事じゃないのか（さすがにあいまいに書きすぎてるとは自分でも思うが）。「実現できることが格段に増えた」事は、リッチなインターネットコンテンツを記述できるって事じゃないのか（意味構造を記述によって検索エンジンに適した情報になるってメリットは、論旨がブレるので書いてない）。
その当たり前の事ができなかったHTML4。HTML5になればできるようになるとでも言いたいのなら、あなたもネットに向いてない。
問いかけてる以上、答えがあるようなので、ぜひ模範解答をご教授頂きたい。「無限の可能性があります」という厨二病な答えしか思いつかない。
ちゃんと書いたつもりけど、代表格は2D描画。あと複雑な処理（クラスのおかげ）。ブラウザ間OS間の互換性。ネイティブなXML処理。プリミティブな音ストリームの操作なんてのもある。
現状、Flashを必要としてるのは何処？ 誰？
Flashを必要としてる人なんていないと思ってる。ただFlashの方が制作環境とかも含めて使いやすいから使ってるだけのこと。
いやいやいやいや。iPhoneで表示されない広告に何の意味があるのか。ゲームは一理あるけどFlashは外部コントローラに対応してない。3Dなら現状Unity。一概に言えない。
http://anond.hatelabo.jp/20110707195830
ボーカロイドの海外進出に将来性はあるのか。そういう視点から初音ミクのLAライブを見ている外国人は結構いる。今回紹介するのは、その中でも明確に「ビジネスとしての初音ミク」のあり方について論じている事例だ。日本人が読むと高すぎるハードルを設定されているような気がしないでもないが、確かに商売としての初音ミクを考えるべき時が来ているとの指摘には一理ある。日本でもまだ確立したとは言えないビジネスモデルをどのように海外で成功させるか考えるうえで、一つの材料になる。
urlは以下の通り。
http://cjblackwing.wordpress.com/2011/07/08/mikunopolis-christmas-in-july-and-world-conquest/
数日前、私はロサンゼルスのアニメ・エキスポ2011から戻ってきた。私の旅行のうち、すぐ後悔するに決まっているレベルの買い物を物販コーナーでしでかしたこと以外のハイライトと言えば、初音ミク関連全部だと言わざるを得ない。ミクがらみ全ての中で頂点はどう見てもミクノポリスだったが、週末のあらゆるパネルを通じてミクに関するたくさんのことを知ったのは楽しい経験だった。ロサンゼルスに向かう前から私はもちろんヴァーチャルアイドルのファンだったが、週末に入るまで私は何を予期すべきかについて実は知らなかった。出立後、ミクのファンになることがいくつかの理由でサンタを信じることに極めて似ているのに気づき、私は衝撃を受けた。
まず、クリスマスが持つ意義と同様、ミクは君が何をしたいかによって君が望むどのような存在にもなれる。世の中にいるあらゆる変態のために彼女が無限の衣装を持っているかのように見える点について話しているんじゃない。いや、それも一部かもしれない。今なおファンはミクに関する新しい歌、アニメーション、あるいはキャラデザをつくり、他の者がインターネット使用を通じて楽しめるようそれを世の中に送り出すことができる。けどクリスマスが単にキャンディー棒と橇の鈴だけではないのと同様、ミクも音楽だけじゃない。この週末、ほぼすぐ私にとって完璧に明らかになったのは、ミクがごく簡単に商業主義の同義語になり得るということ。色々な意味でこれはいいことだ。こうした起業家精神こそが、ゲームやフィギュアに登場するミクをファンにデザインさせることになるし、たとえ分権的なビジネスモデルを通じることになるとしてもなお企業がミク製品に資金を使うのを許すのだから。そして商業主義に関するあらゆるものの真実の意味において、ミクはしばしば決して純粋とはいえない姿に描き出されている。
クリスマスの比喩を続けよう。子供はしばしば小さいうちはクリスマスという概念を理解するのが困難だ。２歳児がただの贈り物を受け取る意味を理解する必要はないが、数年内にそれは子供の世界における中心的イベントになる。この週末、私はミクを理解するうえでそれと同じ感覚を味わった。明らかにアニメ・エキスポに来た大勢の人はミクが何であるかについていくらかの考えを持っていたが、大多数にとってこれはミクに関するあらゆる知識を大量に服用した最初の経験だった。ヴァーチャルアイドルに対する興味は週末を通じてゆっくり増大していくように見えたが、私が思うに大半の人が本当にミクの真価を認め始めたのは彼女のコンサートの間だった。当初、選ばれた一団の人々のみが歓声を上げさらに少ない人だけが立っていたようだった。だがコンサートが進むに連れより多くの人々が言わばグルーヴに身を任せるようになり、そしてその夜の終わりにはノキア・シアターのほぼ全員が立ち上がり、ミクにアンコールのため戻ってくるよう肺の中から叫んでいたかに思えた。サンタ・クロースとミクを含む人生における多くのこと同様、何が起きているかを理解するには多少の時間がかかるが、ひとたび理解すればそれは何か特別なことになるのだろう。
私は日本企業がミクの人気を増すために行ったこと、つまりクリエーター個人がその製品の中で比較的自由にミクを使えるようにすることでファンのデザインをコンサートやフィギュアに実装したところからこの週末のコンサートまで、その全てに敬服している。そして成功するためには他の国民もミクに関する彼らのモデルに追随すべきだと日本人が感じていることも何となく分かるが、それは正しい方法ではないと私は思う。世界中の人々が異なるやり方でクリスマスとサンタを祝っているのと同じように、我々はミクと他のボーカロイドを祝すべきだ。将来において他の言語でもソフトが使えるようにするのは正しい方向性だが、それは分かりきったことに過ぎない。心配なのは、ミクが米国あるいは他の西洋諸国のより幅広い聴衆に必ずしも利用されず、あるいはよく知られないままになるのではという点だ。現状、普通のアニメ、J-ポップ、その他のファン以外の人々が本当にミクのファンになるのは不可能だと思うが、米国で例えばniconico.comといった感じの新たなサイトを作っても、米国が中東に民主主義を紹介しようと試みているのと同じような前進しか期待できないだろう。
ミク（及び彼女の調教師）が本当に世界を征服したいと思っているのなら、まず彼らがオタクのファンベースを幅広く、Narutards［NARUTOの熱狂的ファン、キモオタの代名詞？］からミクを見るために国中から集まってくる人々に至るまで全ての人を（支持母体として）征服することが完全に必要である。エキスポで参加したいくつかのパネル及び私が過去に話した人々を見る限り、アニメ業界が彼らのオンライン製品をよく知らしめるためにいい仕事をしてきたようには思えない。コンベンションで出会った何人かの人はCrunchyrollが無料アニメを提供していることを知らなかった（はっきり言えば、合法違法を含めオンラインでアニメのストリーム上映を見られることを知っている人は極めて少ない集団にとどまっていた）。つまりniconico.comや新たに告知されたMikubookを習慣的に人々が見ることは決して所与の前提ではないし、まして部屋の中にユーチューブという名の500ポンドのゴリラがいる状態ではそんな事態は期待できない。
私がビジネスコンサルティングの授業から学んだ一つの教訓は、製品を作り出すのを手助けするのに必要なリソースを既に持っている企業と一緒に働く能力を君が備えているのなら、自らチャレンジして必要な能力を発達させるよりも、その企業と一緒に仕事をした方がいいってことだ。もし製品を外国に紹介しようとしているのなら、ジョイントベンチャーの利用はより重要である。確かに私はミク関係の人々がアメリカに拠点を置くウェブ企業とある種のジョイントベンチャーを作ろうと試みたのかどうか知らない。だがもしやったことがないのなら、それは彼らの犯した重大ミスだろう。普通のアニメ/J-ポップファンがniconicoやMikubookに気づくまでに使われる時間と金にはそれだけの価値があるようには思われず、そしておそらく普通のアメリカの消費者の注意を惹きつけることなど忘れてしまうほどかかるだろう。その代わり、既に有名なアメリカのネット媒体でミクの特別販促を行うことを日本企業が本気で考えたのなら、ミクは既に彼女を知っている者にのみ検索されることもなくなるだろう。
ミクが日本以外では失敗を運命づけられていると言っているのではない。日本で発展したビジネスモデルは間違いなく機能しているように見えるし、彼らはそのための偉大な製品を持っている。ミクがもっと一般的になるのを見たい人間として、米国でのトヨタCMである程度はやったように、彼女を宣伝するため日本企業がもっと米国企業と一緒に働くのを見てみたい。さらに、これらの取り組みは単なる単発的仕掛けにとどまってはいけない。既に確立したテレビメディアを通じてミクを人々に知ってもらおうとする取り組みを継続する必要がある。さもなくば最終的にビジネスのコストが高くなりすぎ、慌てて逃げ出さざるを得なくなるだろう。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その２「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その３「ミクノポリスのボカレタリアートたちよ、団結せよ！」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その４「仮想の歌姫：初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その５「オレはAXには行ってないけど、まあとにかく……」
http://anond.hatelabo.jp/20110711212701
初音ミクLAライブ、外国人感想その７「AX11：ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その８「ミクノポリス：コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その９「アニメ・エキスポ：初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011（抄訳）」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの：初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://anond.hatelabo.jp/20110719031316
初音ミクLAライブ、外国人感想その13「ミク：日本のヴァーチャル・アイドルとメディア・プラットフォーム」
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人の感想その５。これまで紹介した感想は「ヴァーチャル・アイドルとしての初音ミク」を論じていたが、今回はミクの本来の姿、即ち「歌声合成ソフトとしての初音ミク」に注目しているのが特徴だ。また外国における歌声合成ソフトの将来性についてかなり厳しい見方をしているが、その指摘には耳を傾けるべきところも多い。初音ミクの海外進出に関する先行きを占ううえでも目を通しておく価値はあるだろう。
urlは以下の通り。
http://lelangiric.wordpress.com/2011/07/07/i-didnt-go-to-ax-but-yeah-anyway/
ミクのイベント後にはいつもヴァーチャルスターの構成要素は何かって議論が巻き起こる。クラウドソースな人格か？ touhou［東方］っぽさ？ オリジナルのないdoujin［同人］？ それともインターネットとDTMの力に関するフリードマン風の熱狂か？
確かに日本じゃ大うけだが、アメリカではこれからどう成長するんだ？ オレは英語のVocaloid3が発売されるのを待っている。いいものであってほしい。アメリカでのボーカロイドの発展には英語Vocaloid3の性能が極めて重要なんだ。けどな、アニメ産業とボーカロイドとの結びつきについては、オレは戸惑っている。つまりAXがミクノポリス会場になったことにな。今後も長期にわたって、アメリカではボカロオンリーのイベントはないだろう。アメリカに拠点を置く企業製のボーカロイドすら未だにない。オレが知っている［英語ボカロの］２つの会社はPower FX（スウェーデン）とZero-G（英国）だ。
でもな、そこでオレは考えてみたんだ。
ボーカロイドはvst［ヴァーチャル・スタジオ・テクノロジー］（とかその他のapi［アプリケーションプログラミングインタフェース］）といくつかの重要で理論的な方法は似ているんだが、極めて重要な具体的手法は根本的に違っている、とオレは理解している。基本的に（ある人間の）音声ソースを取ってきてあらゆる音素と音程を録音し、ボイスバンクを作った後で、ヤマハのVocaloid2プログラムがボイスバンクを「読む」ことができるようアプリケーションをコードする必要がある。オレはヤマハがこの部分で相当用心していると思っている。なぜなら公式のボーカロイドは（もしオレが間違っているなら訂正してほしいが）全部ヤマハのVocaloid2エディターと一緒に販売されているからだ。この意味でvstとは根本的な差異が存在する。（１）vstは通常daw［デジタル・オーディオ・ワークステーション］と一緒に流通することはない（２）vstの開発者であるスタインバーグは、vstプラグインを規格として作成しており、従って誰もがvstプラグインを作り出せる。
http://en.wikipedia.org/wiki/Virtual_Studio_Technology
http://en.wikipedia.org/wiki/Digital_Audio_Workstation
http://en.wikipedia.org/wiki/Steinberg
つまり、誰もがボイスバンクを作れるってことだ。UTAU現象がそれを示している。UTAUは違うソフトで動くボーカロイドの単なる「代替手段」（本当の意味でではないがオレは耐えられる）のフリーウエアに過ぎない。自家製ボーカロイドが登場するには（『ファンの作ったボーカロイド』はあるが、本物の商業ベースのボーカロイドとは違う）２つの条件を満たさなければならない。ある団体が充分な資本を集めて（１）高品質のボイスバンクを作成し（２）ヤマハからそのVocaloidエディターを頒布する許諾を得ることが必要なんだ。既に言った通り、紛らわしいのはボイスバンクをプログラムに「読ませる」ためのアプリをヤマハとサードパーティのどっちがコードしているのかってこと。思うに、もしおれがAXの会場にいてこの質問をしていたら、特にヤマハからVocaloid2の許諾を得るのにいくらかかるかを聞いていたら、オレは殺されていただろうな。日本のdoujin歌手を使えば高品質なボーカルを作るのはそんなに難しくないだろう。必要なのはインターフェイスと集音マイク。ダチを作ってそいつらに作業をさせる。そしてUTAUのファンダム全体を見れば分かるが、自分自身を体現したボイスバンクを作ろうとするモチベーションの持ち主は山ほどいるぜ。
http://utau.wikia.com/wiki/UTAU_wiki
オレが何を言おうとしているか分かるだろう。つまり、アメリカ製のインディー・ボーカロイド・スタジオの実現性ってのはどのくらいあるんだ？
少なくとももっと注意深く考え抜く必要がある４つの条件があると思う。
１． アメリカのアニメ業界とボーカロイドの関係。オレが思うに、ブランドイメージと、それからボーカロイドとアニメを結び付けているメーンストリームの連中のことを考えれば、こいつは最も重要な問題だ。「アニメ」はアメリカでその「あるべきもの」（つまりdirty japanese hentai shit）より遥かに大きな概念/カテゴリーになるべきだ。でもまあオレが見てきた限り、日本のボーカロイドにも同じ混同の問題があるようだけどな。とにかく、メーンストリームが一般的にアニメをどう見ているかがボーカロイド関連商品の売れ行きに影響するってことなんだが、この問題はオレには重過ぎる。omoやalexが考えてくれんじゃねーの、多分。
http://twitter.com/#!/alexleavitt
２． 誰か英語ボーカロイド使ってるヤツいる？ 西洋ボーカロイドファンダム総体の認識として、１人だけすげえアメリカ野郎がいて、そいつがボーカロイドランキング（ニコニコのやつで毎週ボーカロイドの歌/動画をコメント/再生数/マイリストに従ってランク付けしている）に［英語ボカロを］ぶち込んだことがあった。でもそいつは突然自分の動画を全削除しちまった。この一度こっきりの出来事を除けば、ボーカロイドは完全に日本のものだ。他にも英語が母国語の作り手はいるんだが、皮肉なことに英語話者のボーカロイド製作者が基礎を置く発生核となりそうな連中の大部分は、日本語ボーカロイドにengrishをしゃべらせようとしている有様だ（大笑い）。
この問題にはさらに深い根がある。
３． そんな真面目な議論じゃないんだが、ある文化の労働的な基底はどうして特定の製品に同調し他の製品には抵抗するのかについて話がなされている。歴史的かつ社会経済的な問いだ。どうしてチリは銅を掘っているのか？ なぜならそれがくそったれなほど沢山あるからだ。結果として採鉱は（おそらく）経済的な基盤が上部構造へと波及していくのと同じように（違うか？）文化的な行為となる。なぜアメリカは基底からやって来る沢山のボーカロイド曲を持っていないのか？ その理由はもう挙げているな……（１）なぜならdirty anime hentaiだから（２）アメリカにいるデスクトップミュージック人種はテレビゲームと映像作品に集中してやがるから。
http://www.imdb.com/title/tt0132477/
http://en.wikipedia.org/wiki/Base_and_superstructure
４． ２番目に上げたデスクトップミュージックの問題は重要だぜ。もしお前が独立した作曲家としてメシを食っていきたいのなら、お前の時間と貴重な音楽的アイデアをボーカロイドのように不安で子供じみた音に賭けてみようなんて考えは二度と起こさないだろう。そいつは正直、新しすぎる。西洋諸国は上出来なデスクトップミュージックを作っている。問題は、ボーカロイドは今も、そしておそらくは長期にわたって、もしかしたら決して、独立したアーティストにとって頼れる収入源にはならないってこと。たとえそれで生計を立てる気がないとしてもだ。アメリカでボーカロイドは、他のデジタル関連のインディー業界のように花開くことはできるのか？ アメリカのボーカロイドが日本のdoujin業界のようになるにはどうしたらいいんだ？
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その２「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その３「ミクノポリスのボカレタリアートたちよ、団結せよ！」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その４「仮想の歌姫：初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その６「ミクノポリス：７月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その７「AX11：ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その８「ミクノポリス：コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その９「アニメ・エキスポ：初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011（抄訳）」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの：初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://anond.hatelabo.jp/20110719031316
初音ミクLAライブ、外国人感想その13「ミク：日本のヴァーチャル・アイドルとメディア・プラットフォーム」
アクセル・ワールド8巻がとても面白かったのですが、未解決の伏線が多すぎてよくわからなくなってきたのでまとめてみました。
同じ作者さんのソードアート・オンラインも含めて思い切りネタバレしてますので、未読の方は注意です。また、多分に私の推測を含んでいます。
4巻で「フルダイブを実現したヘッドギア型VRマシンが開発されたのは2022年の5月」という記述があるが、これはソードアート・オンラインの世界でナーブギアが開発された時期と完全に一致する。ということで、作者がこの二作品に何らかの関係性を持たせようとしているのは確かだと言える。
あくまでも別の作品なので、ソードアート・オンラインの方のネタバレになってしまうようなことは書かれないと思うが、今後も分かる人にはわかる、というレベルの繋がりは出てくるかもしれない。
コメント見てると「申し訳ありませんが絵描きさん以外の申請はお断りさせていただきます」 を叩いてる意図を分かってないやつが多すぎ。
別に、「絵描き以外お断り」それ自体に文句言ってるわけじゃない。
「絵を描く努力も苦労も楽しみも知らない知ろうとしない奴は来るな」ってこと
こういうようなことを言うのに対して、絵を描くということでそれ以外の人間に対して階層意識を持っていることをわざわざ表明するなんて不愉快すぎると言ってるわけ。
どっかの週刊少年漫画家が偉そうに物抜かしてたのと同じこと。努力とか何いってんだか。
努力して絵を描いてる自分が偉い、してないやつは偉くない、俺は偉い奴としか会話したくない。
こう言ってるように見える。絵を描くことには努力を向けてなくても、他のことで努力してる人間なんていくらでもいるのにな。
単に「絵が描けないやつお断り」だったら、何も思わなかったよ。絵を描くということが共感できる人と話したいってだけなんだろうなと思ってたよ。
そういう話をしてるのにコメント見てりゃ「絵を描ける人と話したいのは当然だろ」みたいな言い方ばっかり。
俺はそんな話してるんじゃないから。
それから無断転載に切れるなって話をしてるんじゃなくて、無断転載されてキレた様をいちいち自慢するかのようにTwitterに書くなって言ってんの。地獄のミサワにしか見えんわ。
んで、そんなこと言ってるお前はふたばや２ちゃんで作られたものの無断転載画像のツイートをリツイートしてんじゃねえかってことを言ってるだけ。
文章の無断転載も平気だしな。商業用の音楽を流しながら絵描きのストリーム配信とかやってたり。マジで笑える。
http://anond.hatelabo.jp/20110115003843
の記事を書いた増田です。（以下、「上の記事」ってなってるのはこのURLのことね）
上の記事は、要は年末年始に12時間ほどでサイトを作ったよという話で、作ったはいいがユーザーをどうやって楽しませればいいのか？というところで悩んでます、誰かアドバイスくださいといった内容でした。
サイトは子育て関連のツイートを集めてランキングするサイトです。コミュニティではなく、ツイートのストリームでもなく、ツイート単体でもなく、なんとなく有用なツイートが集まったサイト、というポジションを目指しています。2chまとめサイトのTwitter版みたいな感じ。
個人的にはサイトを作るのは楽しいから、作ってるときとかコードを書いてるときは面白くやれてるんだけど、毎日の運用をもっとモチベーション高くやれたらなあ、と思って上の記事を書きました。
で、あれから１ヶ月ほどたちました。この１ヶ月でやったこととサイトの今について書いていきます。
まずEasyBotter（上記記事参照）の設定で、autoFollowというのがあるんですがそれを使いました。この設定は自動でフォロー返しするというものらしく、ツイッターのプロフィールにも「フォローされたら必ずフォロー返します！」と書いた。
さらに、サイトに関連する人（子育てしているママパパ）を探してフォローしまくりました。Twitterは2000人までしか最初はフォローできないので1900人ほどを何日かに分けてフォローしていきました。そうすると１ヶ月でフォロワーが1000人くらいになりました。毎日20から30人くらいにフォローされていく感じ。
フォローしている人はほとんどママパパなので、基本的に朝は早いです。なので「おはよう」に反応しておは返しするようにしました。でも毎日だと飽きられるのでときどきにしておきました。おはあり、と返事が来たらやっぱりこっちも嬉しいし。
サイト立ち上げのときは、ツイートを自動収集して自動投稿するサイトだったんですが、これだと毎日100ツイート以上を投稿してしまうし、ランキングするにはノイズが多すぎることが分かりました。そもそもランキングは「いいね！」というボタンのクリック数でカウントしてたんですが、これを「わかる！」に変えました。いいねだと何がいいのかよくわからないから。それと、上の記事にコメントいただいてたので、こっちに変えてみました。わかるボタン。
それにあわせて自動投稿をやめて、自動下書き投稿にしました。なので毎日、管理人（私）が100件以上の投稿を見て、リプライとRTをのぞいて、「わかる！」が付きそうなものだけを選ぶようにしました。そうすることで記事投稿数は１日に5本前後まで減ってしまったけど、わかるされる率が1/100から1/10くらいまで上がったような気がしています。個人的にも、意味があるツイートを集めているサイトになってきたなという実感があります。
Googleアドワーズに出してみました。ディスプレイネットワーク（ブロガーから見たらアドセンス）とキーワード検索広告。キーワードのほうはあんまりクリックがよくなくて、表示件数は10万件くらいあってもクリック数は数十件という有様でした。逆にディスプレイのほうがクリックがよくて、１クリック50から100円くらいかかったけど、それで何十人？かがアクセスしてくれました。でも、わかるボタンはほとんど押されなかったです。なので出稿をやめました。１日5000円とか上限を設定してもすぐに使い切っちゃうんだね。
anond.hatelabo.jpに書いたのに、次の日には増田まとめみたいなブログにコメントごと転載されてました。そのおかげもあり、書いた次の日（日曜日）は1600PVくらいありました。でもその翌日にはほぼ０までPVが下がり、増田まとめみたいなブログから毎日1-2PVくらいある程度。あとはTwitterからのリンクで毎日2-3PV程度。広告をしてなかったらほぼPVが０というひどい現状に、自分でも気持ち悪くなってきました。
１月に「おかあさんといっしょ」で流れていた今月の歌のタイトルで検索してサイトに来てくれる人がけっこういて、100PVくらいになりました。あとは「辻ちゃん」とか「離乳食」とか、ニッチなのかよくわからない検索からも少しPVがありますが、ほとんど直帰ユーザでした。たぶん他の探し物をしているときにたまたまうちのサイトが目についてアクセスしてみたけど目的と違ったから離脱したんだろうね。ここをもうちょっとアクセスを増やしたいと思ってます。
いまは、PVはほとんどないけどサイトは一応完成しているから、もっとアクセスを増やしてサイトを活性化したいと思っているところです。
独身男性は、専業主婦って毎日暇してるんでしょって思ってる人もたくさんいますが、子育てしてる人（赤ちゃんとか小さい子どもがいるママ）は毎日忙しいんです。そんな人たちをターゲットにしてるサイトだから、ダラダラ時間を使わせるよりも効率よく有用なツイートを探せるサイトにしたいなあ、と思っています。
さて、なんでこの記事を今更書いてるのかというと、Webサービスを作りたい人が集まってる「はてな」だけど、作っても私みたいに失敗に終わる（アクセスがほとんど集まらない）ケースもあるんだよっていうことを伝えたかったんです。まだ１ヶ月だからこれからだよ、という意見もあると思うけど、１年以内に10000PV/日を目標にしているので、その目標を達成できなかったらサイトを閉じよう、と決めているので、どうにかしてアクセスアップの方法を模索しているところです。
アクセスアップ、で検索すると「トラフィックエクスチェンジ」というサービスがいくつか見つかりましたが、これはBOT巡回みたいなもので良質なアクセスは望めそうもありません。あとは記事数を増やすか、広告にお金をつぎ込むかだと思うんですが、なにせ個人でやってるのであんまりお金もありません。
聞いたところによると、Twitterで影響力がある人にRTされるとアクセスが増えるらしいです。が、私のフォロワーにはなかなかそういう人がいないらしく、Twitterからのアクセスはほとんど期待できません。感覚値では、フォロワーが100人だろうと1000人だろうとあんまり変わらないです。いくつRTされるか、にすべてがかかっていると思います。
ということで、いまはRTを増やすこと（＝アクセスアップ）を目指しています。そのためにコンテンツを用意しました。ママや主婦や女の子が簡単に使える顔文字ペースターです。
http://kosodate-now.com/kaomoji
「ヾ(๑╹◡╹)ﾉ" かわいい顔文字でツイートできるよ ♥ ☺」
といったツイートを、辞書登録とかコピペなしで作れるページです。これもいまいちウケがよくないので、私はWebサービスを作る才能がないのかなあ、と思ってる今日このごろです。
あ、ちなみにサイトはPC専用です。私はケータイを持っていないので(iPhone使ってる）ケータイからの画面確認はしてません。そのせいかな？
あと、HDMIの中を通っているオーディオはビットストリームで送っていない大抵の符号化の場合アナログなのでアナログ劣化はする。
音声がアナログってところ詳しく
テレビに繋ぐ場合 テレビ側がHDMIなのでDVIケーブルでもHDMIケーブルでも同じだが
モニターに繋ぐ場合 モニター側がデュアルリンクの可能性があるので
うかつにHDMIとDVIケーブルが同じ というのはやめてくれという話。
言うならばせめて、シングルリンクで使う場合と枕詞をつけて欲しい。
テレビに映る画質が異なるという話に対するツッコミではなくて、
DVIケーブルとHDMIケーブルが同じという発言に対するツッコミ。
あと、ケーブルの話については
異なるケーブルを使った場合、DeepColorでリンクしていたものが、ケーブルのつなぎ替え時の何らかの障害でDeepColorじゃなくなる可能性
などは起き得るので かならずしも色劣化が置きないとは言えない。EDIBの交換にバグで失敗するソフトも極稀にあるのでなんとも言えない。
また、中継装置（ｗ）のおかげで変なリンクになっている可能性も多々ある。
DVIはアナログでつながることもあるし・・・HDMIはどうなんだろ。アナログOverHDMIもたしかできるよね。過渡期制限で。
あと、HDMIの中を通っているオーディオはビットストリームで送っていない大抵の符号化の場合アナログなのでアナログ劣化はする。
そういう意味では、オーディオマニアというなら、オーディオは光で別ケーブルで送れ。と思わないこともないが AD変換２回やるか？という疑問もあるので微妙。
でもでない。
やべーわー。盛り上がりがやべーわー。
やべー。超絶少女だわ。
腹いっぱいに何かを食う。
いやーVIPとここの相性がよすぎて笑えてくるぜぇ。
なんたって、気分屋だからね。僕は。
マジでクソ面倒なことをするよ。さすがに俺も切れるよ。
ぶち切れるよ。闇に抱いたこの気持が爆発するよ。
加減を知らないことがぶち壊れるほど届くよ。
きっと、だれにも分からないパワーだよ。パワフルだよ。
だれにも分からないパワーで弾けるパワーでゴーゴゴー！
叫び倒すよ。闇に紛れたその正体。
俺はまだまだ生きている。慣れてくりゃ楽なもんだな。
叫んでも叫んでも届かないこの想い
パソコンもってどこへいくの。歩き続けてどこまでいくの。
君に敗北を。敗北を知りたい・・。
はい僕。やるせなさがトップサーティーンを越えていくぜ。
理想の結婚は誰の手に？
俺はただ己の幸福を追求するぜ。誰がなんといおうとな！！
ハイテンション！！！！！！！！！ザッツハイテンション！！！！！！！
ﾔﾚﾔﾚ… ヽ(ﾟ～ﾟo)ﾉ ｱｷﾏﾍﾝﾜ
ヽ(´▽｀)/呆れるほどに！！！！！
構わないぜ、ロックンロールだぜ。
チャンスメイキングがしっかりされてるぜ。
びっくりするほどユートピア！ピュアな初心が神様のごとく現れては消えて、ぶち飛ばす。
闇に消えていく理解もその月も果てのないワールドに迷いこんでしまった。ザ・ワールド！！
とにかくとにかくハッピーでたまらない。元気でいいね。まさにそのとおりだよ！！
もう目の前には希望しか見えない！我慢ベールチーズ！！！！！！！！！！！！！！！！！
真っ暗だ！！！！！！！！！！！！！！！！！！！！！！！！！！！
すごくすごく幸せだ！！！！！ベールに包まれた「それ」がむき出しになるとき！
テクニシャンが多すぎる！！！！！！！好きなメロディーに乗せて。君をどこまでも飛ばしていくよ。
楽しみにしてるのはジョジョ会。痴女会。相談あんだセクフレに「バカヤリチン変態エロ！」
それいけアソパソマソ！ぐっばい昨日の僕！！！！！！！！！！！！！！！！
ジャストフィット！どこまでも続いてくこのレールに乗っかっちゃってもいいのかい？
続く歴史に涙はあるのかい？勇気を振り絞って出た答えが「NO」ならば俺は一体なんのために生まれてきたんだい？
決してとどまることを知らない世界！！！！！！！！！！！！！！！！
一気に駆け巡るぜ脳みそ。
早速公式サイトをチェックだ！
チェケラッチョ！
どうでもいいよ！どうでもいいことだらけだよ！
もう沢山！って気持ちでうんざりするのは簡単なのさ
走り続ける意味はあるか？
人生楽しすぎわろたwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
だれかいるなにかある争って愛しあう
本気でア・イ・シ・テ・ル。この世界を愛してる。
世界が面白いwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
フォロー返しだけはやっていこうと想っている。
フラッシュモーニングwwwwwwwwwwwwwwwwwwwwwwwwwwwww
take to onewwwwwwwwwwwwwwwwwwwwwwwww
ナイスなナイスなキャパシティwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
返事の仕方が良くわからなかったので。
ちゃんと出来ているかな。
楽に死にたいな、出来れば綺麗に。
ユーストリームをする服が無いので……
文字に落とすのは楽だけど喋るのって大変ですよね。
首吊りが成功するまで吊ってましたが、
一回失敗するとリアルな死が見えてくるのに良くやったなぁ……と。
事故のように馬に蹴られて死ねれば良いですけど楽に死ねないかな。
そして湯浅ってなんでしょうか。
はたから見たらキチガイなのかもしれませんけれど。
奥様？特に書く必要も無かったのですが彼女を作ったことはありません。
魅力も作るモチベーションも維持もできそうにないです。
死にたい理由をもう一度思い返してみました。
生きている事に苦痛を感じているから、ですね。
将来の事を考えるのも嫌ですね。
残る物は不自由な身体と精々少しのお金だけ。
親には悪いけどつまらない人生だなあ。
ユーストリームでそれ喋ってみたら？
最もポピュラーな陣形の一つ。
ベア役の人柄の良さを前面に押し出し矢面に立ってもらうと共に、
両サイドから会話のぶった切りや飛び道具(関係のない資料の提示など)での撹乱を行う。
新人は最も安全な後ろから議事録を取っているフリをするだけで良い。
お察しの通り生産性はないに等しいので会議を進めたくない時に重宝される。
ただしベア役には提出された資料等を片っ端から「バリィ」と破く程度の精神力が必要。
とにかく言いたい事をいうだけの陣形。
相手が発言する前に言いたいことを言って終わり。
後から相手に何を言われようと聞く耳を持たない。
■ムー・フェンス
相手の言い分を辛抱強く聞く陣形と思いきや、
相手のあら捜しに終始し、相手の発言が終わった先から重箱の隅をつつくように
反論を始める陣形。
一見するときちんと議論しているように見えるが、生産性はほぼない。
自己満足の為の陣形。
■龍陣
最初から誰がどういった順番で何を発言するか決めておく陣形。
結論をコントロールする技法も使われる。
出来レースともいう。
■鳳天舞の陣
本来は、反論能力の高い人間を真ん中に配置してカウンターを取る陣形だが、
敢えて反論能力のない人間を真ん中に配置することで、合法的に吊るし上げる事が可能。
何度もこの陣形を用いることで、対象人物を社会的に抹殺するというケースが多々見られる。
目的に合った陣形を適切にチョイスすることで、
～250年後～
TVshack.net, Movies-Links.tv, FilesPump.com, Now-Movies.com, PlanetMoviez.com, ThePirateCity.org and ZML.com.
アメリカでこれらのサイトが著作権を侵害しているとして閉鎖されました。
閉鎖されたサイトはいずれもいずれもネット上にアップロードされているファイルを検索できるサイトです。
アクセスすると連邦捜査局のものと思われる「このドメインは映画や音楽,ソフトウェアなどの著作権を侵害していたため閉鎖されました」という画像に差し替えられています。
実際には違法に映画のファイルがアクセス出来るサイトを閉鎖したようです。(例えばトイ・ストーリー3)
このニュースを扱った記事はたくさんあったのでその内1つを置いておきます。
http://www.theregister.co.uk/2010/07/01/us_movie_piracy_crackdown/
上の記事のコメント欄
http://forums.theregister.co.uk/forum/1/2010/07/01/us_movie_piracy_crackdown/
コメント欄には
「著作権を侵害するサイトへのリンクだけで閉鎖されたならどうしてGoogleは閉鎖されないんだ？」
「結局アメリカの法律はロビイストのために造られるんだよ」などといったコメントが並んでいます。
取り消し 下記参照今回閉鎖されたサイトには違法ファイルは置いてありません。あくまでもファイルの場所を検索するだけのサイトです。
それらのサイトを閉鎖させるというのはけっこう踏み込んだ判断だったのではないでしょうか。
WinnyやShare使用者を逮捕した日本でもそうですが最近はインターネットへの規制も強まって来ている感じですね。
一時の無法地帯ぶりがまるで嘘のようです。
日本語版の記事もありました。こちらの方が上の記事より新しくて詳しいです。
この記事によると閉鎖されたサイトは映画を違法に配信していたらしいですね。
それなら閉鎖されるのも当然かも。
21Mbpsのサービス契約ならブロードバンドインターネットがさくさく使い放題！とヨドバシの店員に言われて加入しちゃった人いますか？
こんどイーモバの大域制限が開始されます。有限の電波を極端に使いすぎる迷惑な人に制裁をするんですよ。
制裁の内容は翌日えらい回線速度が制限されるらしいです。でも、どの程度になるのかは未発表。使い物にならないぐらい重たくなっちゃうかも。
ニコニコ動画などの高画質な動画の場合、1Mbpsのストリーム放送を49分間視聴すると制限オーバーです。
動画の見すぎには気をつけましょう。
Skypeの動画通話(384kbps)では２時間ちょいで制限オーバーです。
友達や彼女とついつい長話してしまうひとは気をつけましょう。あなたは迷惑ユーザーですよ。
UStreamTV の放送なら1時間半見れますよ。それ以上は駄目、制限オーバーです。
イーモバもって屋外から生放送したいって考えている人も、気をつけてくださいね。
イーモバの言い分では、楽曲ファイルを９０曲も落とせますとか言っているけど、つまり高圧縮の音楽データだけに使ってなさいってことです。
普通のCDの場合１枚分しか落とせないので気をつけてくださいね。
オンラインゲームも動画サイトと大体同じぐらいのイメージでいいですよ。ゲームは一日１時間！
高速21Mbpsが本当にこの速度が出た場合、2分20秒で制限オーバーです。固定料金で使いたい放題といっても１日２分ちょいしか使えないので気をつけましょうね。
事件は３月２２日、深夜に起きた。
NHKのネット検証番組の裏番組として激笑というＵＳＴ番組をやろうという企画。
番組を見て切込隊長やホリエモン、津田氏がつっこみをいれるという番組。
それまでも切込隊長は登場者にハゲだバカだなどと言いたい放題だった。
番組始まって２時間ほどのこと、ドワンゴの代表取締役川上氏の携帯にエイベックス松浦社長が電話をかけてきたとき
聞こえるように「シャブ野郎！シャブ野郎！」といったのだった。
おそらく小室哲哉の擁護に
尽力したことを指したのだろう。
まわりの人達は勿論慌てふためく。
登場人物kirik が切込隊長、masatomatsuura がエイベックス代表取締役松浦勝人
残念、その人は良く知りません～
RT @stageplayer エイベックスの松浦社長のことです
RT @kirik: MAXさんって誰ですか？
RT @otsune あととりあえず面白いからMAX松浦さんは山本一郎を名誉毀損で訴えるべき
http://twitter.com/kirik/status/10886448012
http://twitter.com/masatomatsuura/status/10910526040
RT @yusha0: @masatomatsuura 昨晩ドワンゴ川上さんに応援の電話を入れた松浦さんに
USTREAMで浴びせかけられたあまりにもひどい暴言に我が耳を疑いました。
正式に抗議なさるべきではないでしょうか？ 約14時間前 TweetDeckから 2人がリツイート
masatomatsuura
http://twitter.com/masatomatsuura/status/10928445507
http://twitter.com/masatomatsuura/status/10928709198
まぁ、面識もないのにいきなり「しゃ◯゛野郎」はひどいなあぁ。完璧、名誉毀損成立かなぁ・・
@yusha0: 昨晩ドワンゴ川上さんに応援の電話を入れた松浦さんに
USTREAMで浴びせかけられたあまりにもひどい暴言に我が耳を疑いました。
暴言を吐いたのは山本一郎というブロガーのようです。 約4時間前 TweetDeckから 3人がリツイート
masatomatsuura
2chと勘違いして、何言ってもばれないと思ったんじゃないの(笑) RT @shingo_1015: @masatomatsuura ネットは匿名だからこそモラルが大切なのですがねぇ…
http://twitter.com/masatomatsuura/status/10931923253
もちろんですが、お灸を据えないとね。みんなのために(笑)
RT @TokyoSport: そういった輩は松浦さんのような有名人が
なにかのリアクションをすると、それはそれで喜んじゃいますから、
ほっとけばいいのでは!?
11分前 TweetDeckから
http://twitter.com/kirik/status/10933083076
@masatomatsuura 不穏当な発言をしてしまったようで、申し訳ございませんでした。
深くお詫び申し上げます。 約2時間前 webから masatomatsuura宛
kirik
やまもといちろう
この間わずか１時間。切込隊長の高速土下座としてまたも伝説が生まれたのだった・・・
ちなみに松浦氏はこのツイートに返信していない。名誉毀損訴訟が起こされるか今後の展開を見守りたい。
参考URL http://headlines.yahoo.co.jp/hl?a=20100323-00000044-zdn_n-sci
追記
http://twitter.com/masatomatsuura/status/11027153701
そんなの気にせんといて！「松浦！し◯ぶやろー」とユーストリームで叫んだわけじゃ亡いし(笑)RT @Realize8rala: @masatomatsuura 松浦さん!!ただいま☆朝のツイート見てたら、１度松浦さんを呼び捨てにしてしまってました(>_<)失礼しましたm(__)m
5分前 Echofonから
全然許してないらしい
さらに追記
進展があったので別記事にしました。
<概要>
2010/3/13(土) 11:10～14:00の間
北側屋上駐車場(イトーヨーカドー側)B列6(被害車)、7台目(加害者)
運転席側ドアをかなりの勢いでぶつけた模様(被害車の左側)
<調査状況から>
白いワゴン車で(ミニバン含)、35～40歳位の夫婦、小さな子供一人の家族
ということまでは、判明しております。
※心当たりの方は、
ららぽーと TEL 045-931-1000
イトーヨーカドーTEL 045-931-9911
までご連絡頂けると幸いです。
★こちら絶対に泣き寝入りしませんので、
こんな悪質な犯人は、必ず見つけ出します。
まとめて日割りにしてみた。
2009/10/27-2010/1/8 3481 47 ヤフー星占い「鏡リュウジの星に願いを」
2009/12/15-2010/1/5 12000 545 ハウス食品採用ホームページ
2009/12/28-2009/12/30 450 150 ローソン採用ホームページ
2009/12/25-2010/1/3 4300 430 民主都連政策紹介
2010/1/4-2010/1/5 3800 1900 モロゾフ
2009/12/16-2010/1/4 1900 95 京王電鉄高尾山観光キャンペーン
2009/12/18-2009/12/21 5000 1250 ホンダミニバン「ストリーム」
2009/12/8-2009/12/22 50000 3333 JR東日本
2009/12/26-2009/12/28 5400 1800 信越放送
別に匿名で書きたいわけじゃないんだけど、便利だからココに書かせてもらおうと思う。
少しおっぱいの話をさせてくれ。あんたも好きだろ？おっぱい。乳。
今日、とある友人がこんな事を言っていた。
- 起伏のない胸など男の胸と同じだ。
- 揉めない乳は乳じゃない。
正直、暴論だと思った。
だから今このエントリを書いている。
どうやら友人はおっきなおっぱいがお好きで
ちぃさなおっぱいにはおっぱいとしての価値が全くないと考えているらしい。
では私はどうかというと「どちらかと言えば貧乳が好き」程度の貧乳好きだ。
もちろん巨乳だって心から愛せる。
そんな中途半端な趣向の持ち主である私でも分かることがある。
それは、彼の展開する「貧乳は揉めないから乳ではない」という理論は、世の貧乳好きには全く通用しないということだ。
従って「揉めないこと」は貧乳好きにとってはなんら問題無しなのだ（ただし一部例外もある）
「揉めない乳は乳ではない」という発言を撤回してもらうにはどうしたら良いだろう。
一言に「貧乳好き」と言っても、中には多様な価値観が存在するのだ。
貧乳好きの主な派閥
- 手に収まるサイズ感が良いんだよ：ハンディサイズ派
- もっと大きくしたいと悩む姿に萌えるんだよ：コンプレックス派
- 控え目なところに可愛らしさがあるんだよ：シャイ派
- 貧しさ・質素さこそ美徳だよ：ストイック派
- 自分の身体にも引け目があるから調度良いんだよ：シンパシー派
- 俺が育てていくんだよ：プロデュース派
- 流れるような流線型のフォルムこそ美しいよ：ストリームライン派
- 乳首と乳輪さえあればそれで十分だよ：ミニマルデザイン派
- なだらかな起伏はとても神秘的な風景だよ：ゴビ砂漠派
- 柔らかいのより固いのが好きだよ：ウェルダン派
- スポーツのためにはおっぱいなんて邪魔だよ：スポーツ派
- ファッションのためにはおっぱいなんて邪魔だよ：モード派
- 少女体型に萌えるんだよ：ロリ派
- 発展途上のふくらみが最も美しいんだよ：ツボミ派（ロリ過激派）
- 少しでも膨らんでいたらババアだよ：ペド派
- 中性的なところが素敵だよ：ボーイッシュ派
- 無駄な脂肪はいらないよ：ヘルシア派
- 掴めそうで掴めないから追い続けるんだよ：ドリーマー派
- 好きになった人のおっぱいが小さかったから、それを受け入れただけだよ：運命愛派
- 歳をとっても垂れないから長い目で見るとお得だよ：ライフイズロング派
- 弧の大きさを考えると貧乳ほど巨乳になる可能性を秘めてるよ：ポテンシャル派
- 見えぬけれどあるんだよ：ダークマター派
とまぁ素人が栄養足りてない頭で30分程度考えただけで20以上の派閥が思い浮かぶわけで。
本当はもっともっと細かい分類が出来るだろうし、ここに当てはまらない派閥も沢山あるはずだ。
もし友人が「揉めない乳は乳ではない」と言い切るならば
少なくとも上記の各派閥を相手に持論を展開し、打ち倒さなければならない。
だがそれは不可能だろう。
もちろん、貧乳側が理論で友人を説き伏せることも出来ないはずだ。
（実践的なやり方で中長期的に対処すれば、多少は趣向を変える事は可能かもしれない）
つまり「巨乳こそ乳だ」「いや、貧乳こそ乳だ」という議論は全くもって不毛なのだ。
だから私はそんな話をするつもりもないし、したくもない。
ただ、コレだけは言いたい。
「乳でない乳はないよ」
巨乳が素晴らしいのではない。
貧乳が素晴らしいのではない。
ただそこにある乳が素晴らしいのだ。
揉める乳も揉めない乳も、愛すべき乳だ。
汝の前の乳を愛せよ。
この思いよ彼に届け！